Slashdot Mirror
Windows RT Jailbroken To Run Third-Party Desktop Apps
An anonymous reader writes "We all knew it was just a matter of time, now it looks like Windows RT has been Jailbroken. From the article: 'The hack, performed by Clokr, exploits a vulnerability in the Windows kernel that has existed for a long time — since before Microsoft ported Windows from x86 to ARM, in fact. Basically, the Windows kernel on your computer is configured to only execute files that meet a certain level of authentication. There are four levels: Unsigned (0), Authenticode (4), Microsoft (8), and Windows (12). On your x86 Windows system, the default setting is Unsigned — you can run anything you like. With Windows RT, the default, hard-coded setting is Microsoft (8); i.e. only apps signed by Microsoft, or parts of Windows itself, can be executed.'"
Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s. That cruft does exist now and is used to run things like Office and Notepad etc. but Microsoft can easily rewrite them in the future. What will happen to Putty, VNC and the like then? They will break,and then again we will blame Microsoft for it. That's the reason to lock it down.
This space for rent.
All 3 of them.
This may border on being pedantic, but I'd call this a crack instead of a jailbreak. It sounds like they're just patching a kernel value ... not breaking out of a jailshell.
I expect MS will probably just find a way to patch it up in the near future.
Theoretically you could run some kind of shell on there, so yes, you could run android or linux, but it'd still be running within windows.
And yes, you'd need to flip this bit each time you booted.
What is more interesting is the fact you maybe able to completely rewrite the whole thing; getting rid of windows entirely...
- http://www.milkme.co.uk
"Need" implies there are people using it, which is a conclusion we might want to take off our mat for the time being.
The fine article has a big link in the first paragraph: "What is WIndows RT?"
Oh, wait...
No sig today...
"Windows RT Gains Solution to Allow Customers to Run Any Software They Choose"
And we wonder why people don't "get" Software Freedom. Somebody please remember to name the next software-freedom work-around "murder" just to keep the bad PR going.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Windows RT contains a complete Win32 API environment (all the standard DLLs are there: kernel32.dll, user32.dll, etc).
Visual Studio 2012 comes with the ARM compiler, so building executables is fairly easy. The restriction, to not allow ARM Win32 applications, only came late in the development cycle, so it's really only hacked in. Visual Studio will even allow native development for ARM applications, going as far to remote debugging the application, by simply adding a "enabled" setting to the ARM manifest file.
The Windows RT SDK for building executables is not required to link existing applications, only a library file is required and that is easily built (in the XDA thread, a tool was posted that builds library files from live DLLs).
Except the problem with your whole premise is that you forget the user.
Basically Apple "whitelists" what Apps can run under iOS (and are clearly moving that way for OSX too), yet people rail against it and even go so far as to remove the "whitelist" (e.g. jailbreak).
The problem comes down to who does the vetting and testing of an application to add it to a whitelist? If it is the user, they've proven they can't be trusted because they'll "vet" any new screensaver/antivirus/cursor application that comes along. If it is a central organization (Microsoft/Apple/Google/etc..) you then run into conflicts of interest in what they think you should do with the platform and what you actually need/want to do (e.g. what happens when you have a problem that can't be solved by any existing approved application?).
There is no simple single solution to the problem of security. A real solution by nature needs to be multilayered which means there is some complexity and ultimately users have to take responsibility for their actions. The idea that a single company/program can keep you safe just keeps perpetuating this idea that you don't have to pay attention to what your are downloading/executing and it's that mentality that allows malware to continue to be so successful.
When someone says, "Any fool can see
Due in no small part to the fact that there is no such thing as a standard GNU/Linux distribution. If you had experience developing for Embedded Linux systems you would realize how unfounded your "complaint" is. We have been using Busybox and non-glibc libc for over a decade.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, due to the fact that they eschew GNU entirely, which is actually pretty common across Linux distributions with the sole exception of Android.
I'm aware that Embedded Linux don't use glibc, they tend to use uClibc or (worse) something proprietary.
But Android is still deliberately separated from GNU/Linux platforms because Google wanted to control it all and cater to handset vendors that don't like having to comply with the GPL.
I think this article linked through TFA reviewing the WOA appstore sums it up nicely "But for now, x86 compatibility isn't just a check box: It's a doorway back to a land of sanity.". Kinda sad they are actually charging more than iPad for Surface when its quite obvious just from reading the reviews their appstore is completely broken and worthless.
BTW it may be a little petty of me, but since i called it months ago that the WOA and Win 8 appstore would be a trainwreck, since they couldn't make GFWL functional after years and a competitor that would be easy enough to copy they sure as hell wouldn't be able to pull off an appstore for a different arch so I'd like to say "I told you so" to those that doubted me and do the dance of smug superiority.
ACs don't waste your time replying, your posts are never seen by me.
Ummmm.... no. You can sideload "Metro" applications just fine (after running one command to unlock this capability). The packages must be signed, but they can be signed by anybody (including self-signed), so long as they chain to any trusted certificate. Visual Studio generates an install script for the package that checks whether its (also auto-generated) signing cert is trusted, and if not, offers to install the cert for you. You can also do so manually (just double-click the cert file and follow the usual import steps).
So, .APPX (Metro application bundle) files don't require "Microsoft" signing level. What about the binaries they contain, though? It turns out that those don't need to be signed at all. At least a month back, a different branch of the "run everything on Windows RT" project bore fruit; we could run "desktop" apps within the AppContainer of a "Metro" app. (WinRT isn't supposed to include the APIs to launch new processes directly, but you have to be linked against the system call interface on Windows anyhow, which means it's possible to just scan the address space for the NtCreateProcess entry point and call it.) These apps don't have to be signed *at all* even without anything like the hack posted here. They run with low Integrity Level and have (by default) extremely limited permissions (access the System32 directory, their install directory, and their data directory, and only the last of those with write permissions), but they do not have to be signed.
There's no place I could be, since I've found Serenity...
Self-reply with more info...
There is some code injected, but it's injected into the user-mode process CSRSS.EXE using the debugger, not injected into the kernel. The injected code modifies a struct which is then passed as a parameter to the kernel via a system call. This call can only be made by the CSRSS (Client/Server Runtime SubSystem) process, and the kernel "trusts" it more than it should (lack of sanity checks on the parameters). When the kernel processes the modified struct, it will change the required signing level flag within the kernel.
There's no place I could be, since I've found Serenity...