Related
So after playing with my Surface for 5 days now, it is obvious there is a lot of capability in the back end through the Desktop. II have networked printers, and drives at both home and office going, streaming content etc. It is very capable for what it is, way beyond any other Ipad and Android tablet out there. So it seems to me it is just a matter of time before some XDAer figures out a way to unleash it and possibly load other programs (non-RT) programs some way. We know the official MS word is no, but it seems to me it is a fully capable Win8 machine that just has some goierners on it and limited processing power, just waiting to be cracked.
Am I just dreaming?
I would love to see this happen. The one thing holding me back from purchasing one. I'd love a Windows 8 Pro version tablet at the Surface RT pricing but wouldn't we all...
I dont think rt can run x86 app properly. Because the cpu is not as good as x86 core. I am interested in porting rt to compatiable device such as tergra 2 and 3 pad.
Sent from my GT-N7000 using xda app-developers app
liu2002 said:
I dont think rt can run x86 app properly. Because the cpu is not as good as x86 core. I am interested in porting rt to compatiable device such as tergra 2 and 3 pad.
Sent from my GT-N7000 using xda app-developers app
Click to expand...
Click to collapse
I don't think it's necessarily about the Tegra being "as good" as an x86 - the issue is that you'd need an emulator, or the source for the x86 app which you'd then need to re-compile for ARM. I believe MS made a developer toolkit available that allows simpler conversion from x86 to ARM but it's still up to the app vendors to do it.
In theory, the same code could compile for both x86/64 and ARM (RT), but VS2012 will not allow you to compile an ARM desktop app. There is no legit way to write/compile a desktop app on RT. Its an arbitrary BS limitation put in place by MS. You cannot side load apps, everything must come through the MS store, RT enterprise being an exception... which doesn't help us. And the MS store will only offer Metro apps. MS office shows that's desktop apps are fully possible, albeit recoded/recompiled for ARM, but MS will not allow it. In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Skitals said:
In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Why do you say that?
Because its not allowed, only metro style apps published through the app store are allowed. Even if you compile compatible desktop software, the OS won't run it. Its a closed sandbox.
At best we can hope for a "homebrew" community to compile open source software, and find some hacks to get it running.
Sent from my Galaxy Nexus using Tapatalk 2
Hello,
I’m a happy owner of the Surface RT and I just wanted to add my 2c.
I think that Metro UI is great for tablet, but lacks apps !
So I cannot understand why Microsoft didn’t include .Net on this platform ! I think the main goal and the first “Homebrew” must be recompilation of Mono for ARM. As this will allow us develop a lot of programs, quickly and using “good” tools (Visual )
I just started to study WinRT and I’m already hitting a lot of blocks (For instance, I cannot find a way to open Shared Socket ! So if any other app listen on 1900 port, I lose my SSDP discovery... )
But I think recompilation of Mono is definitely a way to go ! I think i’ll try it this week-end, if I have some time, but It’s sure I will not be able install on my surface As for now it seems to be impossible to enter Testing Mode on it.
Jurion
jurion said:
So I cannot understand why Microsoft didn’t include .Net on this platform !
Click to expand...
Click to collapse
I think people seem to be missing something here (well, not just here, on other threads/forums.blogs too). MS have essentially (it’s really quite impressive) ported over the entire Windows OS to run on ARM – and this includes all of .NET v4 with supporting libraries/DLLs.
You only have to pop to C:\Windows\Microsoft.NET\Framework\v4.0.30319 on your Surface RT to see – all the same libraries for the same version of .NET a x86 desktop seem to be there - including Linq, SQL, reflection etc.
Now, this could be really great news! I’d bet that it would be entirely possible for standard .NET applications (by standard, I mean programs that only use managed code and nothing legacy) to be reasonably easily recompiled to run on ARM - ideally as easyily as changing a drop-down!
Furthermore, this is all supported in Visual Studio, it’s just locked down a bit - I’ve been able to compile, with VS2012 (and a minor tweak to remove the ARM compile block) a simple command line EXE for ARM (using .NET calls – though only in C++ which is a shame). The problem is, as soon I open it on Surface, I get an error saying the ‘digital certificate’ couldn't be validated – a common issue which has a simple fix documented online. The catch... that the instructions to remove this block don’t work with secure boot enabled, and - at present - we can’t disable this on the Surface (on normal PCs this can be turned off in the bios).
So – the key to all this, is for MS to open it up (not impossible, but who knows if or when) or for someone to get round this secure boot/certificate requirement. I’m sure there’s some smart people on here with abilities to work on, and hopefully succeed in doing this. Even if people aren't able to work a way round this block, I'm hopefully that eventually MS may release some firmware update tools that someone can hack to switch off UEFI secure boot. Or perhaps someone at MS or a partner may leak some file/app/boot that unlocks this for dev/enterprise purposes.
I look forward to it happening!
T
Skitals said:
In theory, the same code could compile for both x86/64 and ARM (RT), but VS2012 will not allow you to compile an ARM desktop app. There is no legit way to write/compile a desktop app on RT. Its an arbitrary BS limitation put in place by MS. You cannot side load apps, everything must come through the MS store, RT enterprise being an exception... which doesn't help us. And the MS store will only offer Metro apps. MS office shows that's desktop apps are fully possible, albeit recoded/recompiled for ARM, but MS will not allow it. In an ideal world, RT would be a fully supported OS, and the likes of Adobe and others could release desktop apps for RT, but sadly it won't happen.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Everything doesn't have to come through the MS store, you can install applications that you build in Visual Studio 2012 for Windows Store, create an appx package and choose not to publish it in Windows Store. VS2012 then creates an appx package as well as a PowerShell script that you can run on Surface, accept security warning, get the developer's license on the device (it's free) and that's it!
It is fairly obvious why MS does not allow installation of "Desktop" apps on ARM tablets. Otherwise dev's would get lazy and just recompile desktop apps for ARM. The experience on a touch tablet would not be great on (unmodified) Desktop apps, hence Microsoft set this constraint on Windows RT in order to push dev's towards making a proper touch friendly app. The result is of course the lack of apps initially, but in the long run the benefits will be a greater experience as the apps would be optimized for touch.
Sure there are obvious downsides to this strategy, but the decision itself makes a lot of sense from a useability standpoint. You already read the complaints in reviews about "Office" not being Metro-style and unfriendly to touch. However this is naturally a decision due to time constraints, because MS would have also preferred to not include a desktop on RT. Office is the selling point now, to gravitate people towards RT and when there is enough demand, the touch friendly (Metro) apps will flow in eventually
Backflipping said:
I think people seem to be missing something here (well, not just here, on other threads/forums.blogs too). MS have essentially (it’s really quite impressive) ported over the entire Windows OS to run on ARM – and this includes all of .NET v4 with supporting libraries/DLLs.
You only have to pop to C:\Windows\Microsoft.NET\Framework\v4.0.30319 on your Surface RT to see – all the same libraries for the same version of .NET a x86 desktop seem to be there - including Linq, SQL, reflection etc.
Now, this could be really great news! I’d bet that it would be entirely possible for standard .NET applications (by standard, I mean programs that only use managed code and nothing legacy) to be reasonably easily recompiled to run on ARM - ideally as easyily as changing a drop-down!
Furthermore, this is all supported in Visual Studio, it’s just locked down a bit - I’ve been able to compile, with VS2012 (and a minor tweak to remove the ARM compile block) a simple command line EXE for ARM (using .NET calls – though only in C++ which is a shame). The problem is, as soon I open it on Surface, I get an error saying the ‘digital certificate’ couldn't be validated – a common issue which has a simple fix documented online. The catch... that the instructions to remove this block don’t work with secure boot enabled, and - at present - we can’t disable this on the Surface (on normal PCs this can be turned off in the bios).
So – the key to all this, is for MS to open it up (not impossible, but who knows if or when) or for someone to get round this secure boot/certificate requirement. I’m sure there’s some smart people on here with abilities to work on, and hopefully succeed in doing this. Even if people aren't able to work a way round this block, I'm hopefully that eventually MS may release some firmware update tools that someone can hack to switch off UEFI secure boot. Or perhaps someone at MS or a partner may leak some file/app/boot that unlocks this for dev/enterprise purposes.
I look forward to it happening!
T
Click to expand...
Click to collapse
Hmmm, sorry my bad, didn't look enougth to find .Net assemblies.
As for open it for MS, may be, maaaay be it's the same scheme which they followed with Windows Phone 7.
No native developpment for 7.0 -- 7.8
But they open it for 8.0
May be they just want to force people developp Metro app to populate the store first.
So where's the best place to get one?
I'm looking into buying one very very soon, I found some on ebay for $585 with the cover, That sounds like a win to me. I wish QVC had it, That'd be lovely.
I'm praying we get a work around for all this, But still If the device isn't made for it, I can't be mad that it doesn't do it, That's like being angry that my car doesn't fly.
But it's such a tease, it worries me that I'll have an entire desktop, Sitting, Obselete, With nothing but Office, which I wont even use.
Can't_Live_Without_My_Evo said:
I'm looking into buying one very very soon, I found some on ebay for $585 with the cover, That sounds like a win to me. I wish QVC had it, That'd be lovely.
I'm praying we get a work around for all this, But still If the device isn't made for it, I can't be mad that it doesn't do it, That's like being angry that my car doesn't fly.
But it's such a tease, it worries me that I'll have an entire desktop, Sitting, Obselete, With nothing but Office, which I wont even use.
Click to expand...
Click to collapse
It is made for it. It has the full desktop, and the full desktop Office suite. Its a big tease. The whole "do more" campaign advertises you can "click in" and have full laptop productivity with touchpad and mouse/keyboard. Except the only software to take advantage of it is desktop IE and Office.
Sent from my Galaxy Nexus using Tapatalk 2
I brought up some thoughts about Dropbox in mamaich's thread and netham45 was nice enough to bring up some interesting facts about Dropbox, namely that it's compiled in Python.
I'm totally unqualified and have no idea how to actually do the tough stuff, but i'm just going to leave all my notes so far in this thread so someone perhaps more knowledgeable with Python can take it from here. I will try to play it around to get it working though.
Basically after extracting Python from the .exe I got left with a bunch of .pycs that need to be recompiled into the .py that made up the file. I have no idea how to do this. See here http://nixforums.org/about81754.html - if this can be built into some sort of functional program, then it may be very well possible to take this one step further and recompile an .exe for ARM that runs dropbox - or even more easily just compile a working python file for Dropbox
this also might be interesting http://kyl191.net/2012/04/dropbox-api-python-to-sync-a-folder/
I also thought it's worth pointing out this https://github.com/mdornseif/dropbox-client-python
last but not least http://stackoverflow.com/questions/2678180/how-does-dropbox-use-python-on-windows-and-os-x
Maybe someone will have a better idea about what's going on here
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Another thing that could be done is implement a client in .net. I played with doing just that a couple weeks ago, I had a semi functional (it worked, but had some issues still) offline client in not very many lines of code using a .net library for Dropbox. I'll see if I can get my code up sometime soon.
netham45 said:
The compiled python -should- be platform independent. I honestly don't know much about Python, but we should be able to just reverse whatever dropbox.exe is doing (which should be just a launcher), mimic it, and get a rather functional dropbox.
Click to expand...
Click to collapse
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
DarkoLord said:
The Python-to-exe packers I know basically include a native loader that unpacks the python dll and loads it either from temporary location or directly from memory and then passes the script to that dll.
It's probably just a matter of figuring out which packer they used and/or porting one of the packers and repackaging it again for RT
Click to expand...
Click to collapse
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
SixSixSevenSeven said:
Wrong track completely. The compiled python being referred to above is not python packed into an exe. It is a .pyc file. Contrary to popular belief python is not interpreted line by line. Instead it is compiled into bytecode and then a virtual machine executes that. The bytecode can be saved into a .pyc file (there is a tool included in the standard python install for it somewhere, alternately if you try importing any script as a python module then python will automatically make a .pyc for it which you can use), it has a smaller file size and is not human readable. This is the file being referred to.
It is possible to reverse engineer .pyc files. I remember seeing a tool which is capable of making a pretty good attempt of reverse engineering non obfuscated bytecode, thats the disadvantage to python being open source, the bytecode specification is publicly viewable can't remember the tools name and I would think dropbox have obfuscated their pyc files.
Click to expand...
Click to collapse
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
DarkoLord said:
I'm aware of that (by script file I meant pyc, of course), but what would be the reason for trying to reverse engineer the pyc files since the bytecode itself is platform independent?
For starters someone should just try running the unpacked .pcy files on the RT or are we past that and there is some platform specific stuff inside that prevents it from working?
Click to expand...
Click to collapse
The pycs are getting magic number errors when I try to look at them because i'm not running it through the interpreter - because I dont know what the interpreter is. I think the first step is to find a way to get it compiled and running to find out if its platform independent or if there are dependencies.
I also have no idea which .pyc to start with
Ah, magic number.
Apparently Dropbox uses a bit modified version of python interpreter with some encryption and mixed opcodes.
Here are some details: http://blog.codepainters.com/2012/09/17/python-care-and-feeding-the-dropbox-way/. It looks like it could be done
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
https://www.dropbox.com/developers/sync
Any idea if this would be helpful?
userno69 said:
Wow, if we could have legit dropbox on RT, that would be AMAZING!!
Click to expand...
Click to collapse
I really agree, is this project still alive??
maxxie85 said:
I really agree, is this project still alive??
Click to expand...
Click to collapse
It's been six months since this thread was posted in. I doubt it.
netham45 said:
It's been six months since this thread was posted in. I doubt it.
Click to expand...
Click to collapse
yeah I noticed that to, never hurts to ask.
And by the way, maybe now the life in this project is getting resparkeld.
Sent fromy my ASUS Transformer Pad TF300T using XDA Premium HD app
I know this is a potentially dangerous post, but I'm looking for suggestions for things to port. I make no promises that I'll be willing/able to port any suggested software.
Some ground rules before you hit 'reply'
1) Don't ask for Chrome. I won't port it. Period.
2) The source code must be available and not have any _obvious_ specific ties to non-open source code. Eg: some proprietary or closed source library which it depends on.
3) Code must be in C or C++ (I can deal with porting some assembly if needed)
4) Project must be of a _reasonable_ size for 1 person. Honestly, I do this on my own and in my spare time. Some apps can be just massively overwhelming to port. That being sad, sometimes the big ones are also easy.... so use your own judgement here.
5) Tell me why you want it ported. Whats your "use case".
6) Drivers aren't out of the question, but they generally take significantly more work.
Feel free to +1 others suggestions.
Ok.. <puts on protective gear>.. fire away!
Cheers!
Thanks for all your awesome work.
While this isn't an app, I think that the kexec kernel-mode driver idea that was tossed around earlier would be waay more useful than an individual app. Every time it was brought up somebody said "Oh, that won't be much work." And then nobody did anything :-/
So, I'm hugely grateful for the time you put in here, but I think I'd be even huger-ly grateful-er if you opened the door to other OSs.
Sent from my SCH-I535 using xda app-developers app
What would be good is:
http://ekiga.org/download-ekiga-binaries-or-source-code
But I'm pretty sure it uses some libraries not avail
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Would be nice to have InSSIDer. I use it a lot on my laptop, rather leave it at home.
https://github.com/metageek-llc/inSSIDer-2
Myriachan said:
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Click to expand...
Click to collapse
I would say to take a look at monogame. It can actually build microsoft store apps including ARM support, so coercing it into functioning on the windows desktop may be possible. Otherwise it might end up being a rule 4 :/
There are hacks out there to run terraria on MonoGame instead of XNA, most of them pretty complete but sometimes have the odd graphical glitch. A full source port to MonoGame would be far more reliable, and actually very simple, but sadly its closed source (although not obfuscated).
One of the supposedly more reliable ones: http://www.terrariaonline.com/threads/wip-monogame-terraria-terraria-for-linux.72997/
Isn't rule one covered by rule four?
SixSixSevenSeven said:
Isn't rule one covered by rule four?
Click to expand...
Click to collapse
No.
People can have bad judgement.. so I'm making an explicit point about Chrome.
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
lambstone said:
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
Click to expand...
Click to collapse
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
bfosterjr said:
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
Click to expand...
Click to collapse
Does this help http://code.google.com/p/tcpmp-revive/source/browse/#svn/trunk
mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2101891
mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
Safari is not open source so cannot be ported.
Chrome is a rule 4 - or in other words is too much effort for 1 man to do in a reasonable time frame.
Firefox is also a rule 4, plus its a ***** to get it to compile properly under microsoft tools apparently, plus its javascript engine is raw ARMv7 JIT whereas windows RT bugs with that and would require a THUMB2 JIT. Chrome also would have javascript issues, although in chrome you can have an interpreted javascript engine I think which would just be hideously slow in comparison.
Opera - Closed source.
The list goes on unfortunately. Browsers are complex creatures. Most will come under rule 4 though.
bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
To build WinSCP you need:
- Embarcadero C++ Builder XE2 Professional.
- Copy MFC source code from Borland C++ Builder 6 Professional and
build its Unicode version (see readme_mfc.txt).
- nasm from http://www.nasm.us/
- To build 64-bit version of drag&drop shell extension, you need
Windows Platform SDK:
http://msdn.microsoft.com/en-us/windows/bb980924
Click to expand...
Click to collapse
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
domboy said:
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
Click to expand...
Click to collapse
Borland C++ is an alternative set of 3rd part C++ tools. Would take a bit of work to get a borland project to compile it under microsoft tools.
Nasm is an x86/x64 assembler yes. Assembly language is pretty much the lowest level of programming possible before writing in raw hex or binary. It is *HIGHLY* CPU dependent. Specifically the set of commands available in assembly is the plain text form of the exact instruction set the CPU has available which for x86 is different from ARM. The fact that nasm is required means that the project will have assembly in it, therefore an RT port will not be undertaken (one of the rules in the OP).
Sorry man, its proprietary tools and parts of it are unportable anyway. Doesnt mean another SFTP client can't be ported, just this one.
Here's my wishlist. I've poked at some of them, but I don't really have time to finish any of them.
WinPCap - Iirc, the biggest issue was that it was written targeting an older version of NDIS. The usecase would be to provide network support for BOCHS.
QEmu - There's a build of QEmu that builds on MSVC called WinQEmu, but it's dynarec recompiles to x86 only. I believe the official QEmu repo doesn't support MSVC, and I don't know if it can recompile to THUMB-2.
A good IRC client - X-Chat and mIRC run poorly under the emulator, and the few .net clients I've tried are meh. X-Chat has too many GCC-specific requirements, and mIRC isn't open source, I just want a good IRC client.
An X Server - I've been unable to find an X server that builds with MSVC, or anything short of Cygwin for that matter, but I'd love to have one.
Calibre is a good eBook manager I think this is the correct source code https://code.launchpad.net/calibre
I'm not good with this source code stuff so if its to much you dont need to make a port but if you can it would be appreciated thanks
Sent from my SGH-M919 using Tapatalk 4
cx1 said:
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
Click to expand...
Click to collapse
Browsing news sites and/or using Spotify.
So I know pretty much how my jailbreak is going to work from end to end, except with regard to PatchGuard. I don't need to burn my "Holy Grail" exploit in order to release a jailbreak, but it means that I have to deal with PatchGuard.
In Windows 8.1, Microsoft modified the kernel and ci.dll so that PatchGuard protects the signing enforcement mode variables. This means that if you modify the variables that were modified by 8.0's jailbreak, some random time in the next hour from that point, your system will bugcheck (bluescreen) because PatchGuard detected something tampering with the kernel. It is very obvious that the addition of these variables to PatchGuard's protected list was a deliberate attack against the RT jailbreak, because there is little other reason to care about enforcing these variables' integrity after startup.
I need to get around PatchGuard somehow. PatchGuard itself is designed to be an obfuscated mess, deliberately difficult to modify in a stable manner. It does a lot of nasty tricks, things that you would typically find in copy protection systems. Obviously, disabling it would be nice, but quite difficult. So is stopping it from bugchecking.
I can load kernel drivers, so I know of a way in which I can hook parts of the system that would not anger PatchGuard such that arbitrary unsigned DLLs and drivers could be loaded without hassle. For things like the lockdown in WinDbg, VBScript and PowerShell, I can hook NtQuerySystemInformation in the user-mode ntdll.dll and intercept the request to check the lockdown setting. Even though the system lockdown state would still be active, as long as user mode programs don't know about it, it won't be enforced. (The kernel doesn't care at all.)
However, this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time. However, patching the kernel definitely will get PatchGuard's attention, so there's no way to pull that off without defeating PatchGuard.
The optimal solution is definitely to defeat PatchGuard, but I don't know how. I'm not an expert in the field of low-level NT kernel stuff.
please release your jailbreak so that other people can help you.
If i got it correctly, it will BSOD in a hour of running, so releasing it to public is not a good idea. Maybe via PM to other devs, but that depends on OP.
why not change the variables back after you launch your unsigned exe?
windowsrtc said:
why not change the variables back after you launch your unsigned exe?
Click to expand...
Click to collapse
I think about doing this too. Can we discard hacked? If it can done. Will it have problem with running unsigned exe? And did we know exactly when did PatchGuard notice about hack?
Myriachan said:
However, this leaves one thing to be desired: executing ARM code.
Click to expand...
Click to collapse
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Cheers!
bfosterjr said:
Perhaps I'm missing something, ... why do you want to do this? The reason I ask is because this seems to be your motivation for wanting to "defeat" patch guard.
WRT simply running native applications/driver - If you can successfully load a driver, even once, then there are a few easy ways to support this without a patch guard defeat.
Click to expand...
Click to collapse
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe.
You're right that there are various ways of loading unsigned executables and drivers once the initial driver is bootstrapped. ci.dll and ntoskrnl.exe have so many variables that aren't protected by PatchGuard that this is pretty much inevitable. Ironically, removing the lockdown from WinDbg, PowerShell and VBScript is actually harder than running unsigned code when using this attack.
Defeating PatchGuard would be the optimal experience for users.
...
...
Myriachan said:
That it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported.
Click to expand...
Click to collapse
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
bfosterjr said:
Actually, I don't agree. There is no hard requirement for ARM code that I can see. The major reason for a lack of FF port is that the native RT community is too small to get behind the port to sort out re-writing parts of the code base. There is also the large build system/process that needs to be shifted to VS. Throw in the lack of a public RT 8.1 JB.. and there is little motivation for this community to invest the time/effort in making FF work.
Don't get me wrong, FF will likely come to RT (even 8.1) eventually.. but I don't see the lack of ARM code being the roadblock. Its time and effort along with a new JB.
Click to expand...
Click to collapse
The javascript JIT engine is to ARMv7 not THUMB_2 though.
SixSixSevenSeven said:
The javascript JIT engine is to ARMv7 not THUMB_2 though.
Click to expand...
Click to collapse
I gathered as much. I'm suggesting a re-write of that as part of the port.
Cheers!
Possible, but not easy. The result would likely be significantly less efficient... but better than no JIT at all. It substantially increases the effort required for porting, though.
As for PatchGuard... I don't know as much about it as I'd like, but the fact that it only checks periodically suggests something that we can anticipate and head off, assuming we can get our own drivers loaded... hmm. This is a pretty "out there" solution, but is there any chance that the version of PG from RT8.0 could be substituted in? That may assume a greater degree of encapsulation of PG functionality than is actually warranted, but it does seem to me that, if we can't modify it, we might be able to just replace (or possibly remove) it. Another option: rather than modifying the value itself, modify the code that checks it? I mean, if they were smart, that's under PG as well, but it *might* not be. Either bypassing the check for the values, or the signature check, or just spoofing the signature check, or taking it a level even further and replacing the whole loader function with a clone that lacks the check (which allows the original to remain intact, aside from however the shim is injected).
Any which way, a lot of binary RE... ick, but that's life.
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
netham45 said:
A few ideas:
1) Put a memory read breakpoint on the memory addresses you wish to change, check the context reading it and change it to what it should be if it's PatchGuard, and what you want if it's not.
2) Hook BugCheck to make it just return if PatchGuard calls it (I seem to recall reading something about PG wiping the stack/any context before calling BugCheck, so this may not work)
3) Forcibly enable Debug mode VIA setting the required kernel flag/calling the proper function (kdStartDebugger? something like that; I had found it at one point) to enable the debugger. I have no idea if PG will sense this on pre-existing threads or not, but if it does then it should shut itself down.
4) Check if THIS approach works in 8.1 (I suspect not, since it was published for 8.0 previews)
5) (This would work for g_ciOptions, but not patching the interrupt handlers), hook the usermode function that queries the state of the signing, make it call a driver that changes the bit back, check, then call the driver to set it to default again. You would only get a BSoD if you were really unlucky and PatchGuard happened to run during the 30ms that the flag was changed.
I'd like to play with some of these ideas, but without access to the current prototype (hint hint), and not having a PC I want to upgrade to 8.1 right now, it's difficult.
Click to expand...
Click to collapse
1. You can't set a read breakpoint because PatchGuard is also checking the contents of the interrupt vectors/registers. It would notice that someone is using the hardware breakpoints before it tried to read kernel memory.
2. Yes, PatchGuard overwrites KeBugCheckEx with a pristine copy among other tricks.
3. PatchGuard knows that the debugger was not enabled at boot, and will not allow it to be enabled. It will bugcheck if you try to enable it.
4. It's possible that the approach where you look for the self-decryption code at the beginning of the DPC handlers would work.
5. There is a better way, closely related to how I'm writing my installation program, to allow unsigned PEs to load. It would escape PatchGuard's notice. A user-mode hook would be required in order to neuter wldp.dll, though, since ntoskrnl.exe would still tell programs that the current policy was locked down.
I think I can do everything I need to do except execute ARM code reliably without harassing PatchGuard.
Melissa
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
sahack said:
As a plain user, I have a question:
Why do we have to use ARM Instruction Set? Isn't just Thumb-2 okay? I thought other part of Windows all runs with Thumb-2 fine.
Click to expand...
Click to collapse
Common one that needs the ARM instruction set would be a javascript engine. V8 which is the javascript JIT used in chrome only has x86 and ARMv7 versions available, it doesn't have a THUMB_2 version. Although V8 itself can compile for THUMB2, that is only the JIT'er itself, it will only ever JIT to the full instruction set. So to port chrome we wouldnt be able to use V8, there might be a way to get it to compile using the windows javascript engine (which is slower than V8 but perfectly fine) or something but its still a significant obstacle.
The same applies to quite a few other softwares.
Then as netham says, we have software written in arm assembly which people have requested, thats great but it takes alot of effort to rewrite it in thumb2 assembly.
If you have software which can indeed compile for thumb2 and function on thumb2, yeah thats great. But there is some which doesnt.
netham45 said:
There is a lot of software that we would like to port over that is written in arm assembly. We would have to rewrite it to THUMB-2 to use it on Windows RT, though. Porting software is (relatively) easy, rewriting it is difficult.
Click to expand...
Click to collapse
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
sahack said:
Okay... I used to think that only JIT compilers and media decoders needed that...
But that gives another question.... Were we able to let the CPU stay in ARM mode in Windows RT 8.0?
(And if PatchGuard checks periodically, is it possible to just reset its timer once in a while?)
Click to expand...
Click to collapse
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
SixSixSevenSeven said:
First question, no.
Second question, thats what the thread is discussing although your suggestion is perhaps worth a look into (if myriachan hasnt already)
Click to expand...
Click to collapse
Sure, you could reset the timer on PatchGuard continuously, if you can find all its timers and perfectly distinguish them from those that were created by legitimate drivers. That's the harder part, unfortunately. =/
If you have nothing to add to this discussion please do not post. Thanks
Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...
Thanks,
Toxickill.
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
LolitaPlus said:
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
Click to expand...
Click to collapse
Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
master.peterm said:
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
Click to expand...
Click to collapse
Ok so now that it can be done im going to fire up my surface and get working on a new jailbreak tool. If all succeeds then i will update accordingly. Hopefully bypassing patchguard is all that is needed to run old bypass methods. If patch guard stays bypassed then we can make the jailbreak persistent through sessions.
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
GoodDayToDie said:
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
Click to expand...
Click to collapse
Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.
Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
GoodDayToDie said:
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
Click to expand...
Click to collapse
So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:
Code:
[DllImport("ntdll.dll", SetLastError = true)]
internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));
C# code of course but you could easily code in any language.
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
GoodDayToDie said:
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
Click to expand...
Click to collapse
Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.
Looking into this, might be worth a shot.
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.
Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.
EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.
Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.
Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse
Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK
C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist
cdb is part of WinDBG
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse
Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.
Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse
I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.
Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):
https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE