Windows RT has been jailbroken, you can now run un-signed code

The day that Microsoft announced Windows RT and that it would be a closed platform, many began to wonder how long it would take for the platform to be jailbroken. While we are still testing the waters ourselves, it looks like the platform has been opened up by vulnerability in the Windows kernel that was ported to the Windows RT platform.

The information comes from a post penned to the Surfsec blog who claims that they have been able to run unsigned desktop applications on Windows RT. Yes, you read that correctly, unsigned desktop applications on Windows RT. The crux of the post is this, there is no technical limitation to stopping desktop applications from running on Windows RT and it appears to be purely a marketing move. We posted the conclusion of the lengthy post explaining the exploit that was used to allow an unsigned desktop application to run on Windows RT:

Windows RT is a clean port of Windows 8. They are the same thing and MSFT enforces Code Integrity to artificially separate these platforms. It does not stop pirates from modifying store apps (and their license checks) because store apps are the only things that can actually run unsigned. The fact that this method works on Windows 8 as well shows how similar the systems are. You can even enforce Code Integrity on Windows 8 to see what Windows RT feels like!
The decision to ban traditional desktop applications was not a technical one, but a bad marketing decision. Windows RT needs the Win32 ecosystem to strengthen its position as a productivity tool. There are enough “consumption” tablets already.

There is a lot to consider as the exploit will only last until you restart the device and it requires quite a few steps to actually unlock and run unsigned code on the platform. But, seeing that, according to the author, the only thing from stopping traditional applications from running on Windows RT is Microsoft blocking the action, it does show the true power of Windows RT.

While we do not know if there is a demand for a home-brew community for the Windows RT platform, iOS arguably became popular after its home-brew community ran wild with the platform and was able to add significant functionality to the device. If Windows RT can develop a serious following, it could be the key to making Microsoft's mobile Windows platform the next billion dollar revenue stream for the company.

Source: Surfsec

Report a problem with article
Previous Story

Toshiba announces Satellite U845t budget touchscreen Ultrabook

Next Story

NVIDIA unveils Tegra 4, seen in prototype Windows tablet

86 Comments

Commenting is disabled on this article.

neonspark said,
this is awesome. unleash RT. it is a lot better than windows 8 in that most of the malware has yet to be re-compiled

How is it better, when it's effectively the same thing?

It's effectively the same thing but different.

Windows RT only runs on the ARM architecture, therefore any malware has to be recompiled. Even then it won't run due to Code Integrity being enforced and apps only being available through the Store.

A proper IM solution would be nice. I am not sure if there are even developer tools out there that can compile a program to work on ARM Windows RT, the system was closed, so why would there need to be tools?

"Windows RT needs the Win32 ecosystem..."

Except Windows RT is specifically for ARM and doesn't emulate or have the Win32 APIs AFAIK.

FACEPALM. How do you think applications like control panel and notepad work? They are accessing win32 APIs likewise with Office 2013!

ingramator said,
FACEPALM. How do you think applications like control panel and notepad work? They are accessing win32 APIs likewise with Office 2013!

They are arm specific versions ...

ingramator said,
FACEPALM. How do you think applications like control panel and notepad work? They are accessing win32 APIs likewise with Office 2013!

That's why I added AFAIK (As Far As I Know) to the end of my post!!!!!

neo158 said,
"Windows RT needs the Win32 ecosystem..."

Except Windows RT is specifically for ARM and doesn't emulate or have the Win32 APIs AFAIK.


It doesn't have ALL of the Win32 APIs. So you were half right.

SharpGreen said,

It doesn't have ALL of the Win32 APIs. So you were half right.

What are you going on about with this half the amount of Win32 APIs crap... Windows RT is Windows 8 compiled for ARM the APIs are there just not accessible by WinRT applications for security reasons. Hackers like me have ways of bypassing these restrictions, one way is to parse LoadLibraryA and GetProcAddresse in memory through kernel32.dll injection. It's a trick we've been doing to access full APIs since the dawn of Windows and in fact many viruse/malware services use it to gain superuser privileges and write any arbitrary code into memory without being questioned by the OS memory integrity checker. Anyways I know what I'm talking about but I think you are just a software dev playing in the wrong ball park, this is hardcore kernel level shiit not user level coding.

Regards.

ingramator said,

What are you going on about with this half the amount of Win32 APIs crap... Windows RT is Windows 8 compiled for ARM the APIs are there just not accessible by WinRT applications for security reasons. Hackers like me have ways of bypassing these restrictions, one way is to parse LoadLibraryA and GetProcAddresse in memory through kernel32.dll injection. It's a trick we've been doing to access full APIs since the dawn of Windows and in fact many viruse/malware services use it to gain superuser privileges and write any arbitrary code into memory without being questioned by the OS memory integrity checker. Anyways I know what I'm talking about but I think you are just a software dev playing in the wrong ball park, this is hardcore kernel level shiit not user level coding.

Regards.

Again with the needless insults. Look up "WINAPI_FAMILY_PARTITION" and stop spreading missinformation and insults.

SharpGreen said,

Again with the needless insults. Look up "WINAPI_FAMILY_PARTITION" and stop spreading missinformation and insults.

I give up, do you have a Surface RT or Windows RT device? I do and it's running all of my .NET 4.5 applications and a few ARM compiled ones like PuTTY, TightVNC and Bochs. All work 100% networking, sound and graphics. I would love you to explain to me how these applications have access to all their APIs if they do not exist on Windows RT? Please, I didn't know you were such an expert!!!

ingramator said,

I give up, do you have a Surface RT or Windows RT device? I do and it's running all of my .NET 4.5 applications and a few ARM compiled ones like PuTTY, TightVNC and Bochs. All work 100% networking, sound and graphics. I would love you to explain to me how these applications have access to all their APIs if they do not exist on Windows RT? Please, I didn't know you were such an expert!!!


Well since it's obvious you didn't read what I said originally...why should I continue wasting my time? All I've really said is that the entire Win32 API was not available on Windows RT. Just because some of your apps are working doesn't guarantee 100% of Windows desktop apps will.

please,save the drama. If you care about running desktop apps, buy an atom x86 tablet,like the acer w510. it gets the same battery life as winrt tablets, it has better performance, and it runs all desktop apps without needing to recompile code to arm.

true about everything but battery life. At the moment ARM processors outdo X86 processors like atom but this could soon change with the next gen. Anyhow some of us Microsoft Surfaces and it's nice to be able to hack things together and unlock your device to get as much raw capability for the money! its also really fun

I actually have a surface and a w510. the w510 actually gets a tad more juice than the surface. I tested both devices doing the exact same tasks. the acer has a smaller screen though(10.1" vs 10.6"),so it could give it an advantage in battery life, but my point was,battery life is similar.

and I like hacking devices for the fun of it too, but some people are going off about how locked down windows rt is and whatnot, when in reality if they were so concerned about that,then they should have gotten an x86 variant instead.

Edited by vcfan, Jan 7 2013, 8:47am :

vcfan said,
I actually have a surface and a w510. the w510 actually gets a tad more juice than the surface. I tested both devices doing the exact same tasks. the acer has a smaller screen though(10.1" vs 10.6"),so it could give it an advantage in battery life, but my point was,battery life is similar.

and I like hacking devices for the fun of it too, but some people are going off about how locked down windows rt is and whatnot, when in reality if they were so concerned about that,then they should have gotten an x86 variant instead.

I think the w510 has a larger battery but I can't remember off the tip if my head but yeah I completely agree if you don't want to suffice to the "limitations" of Windows RT then you shouldn't be using it!

vcfan said,
please,save the drama. If you care about running desktop apps, buy an atom x86 tablet,like the acer w510. it gets the same battery life as winrt tablets, it has better performance, and it runs all desktop apps without needing to recompile code to arm.

If you care about running x86 apps, avoid Atom like the plague

I think we got into a little misunderstanding. yeah the atom might use up more juice than arm, but im comparing overall total tablet battery life you're getting with the device.

We can only hope! Best bet's VLC, first I have to get this exploit working though. M8 is actually pretty good though, it's my replacement for the ****ty music app!

The Boot Loader should be unlocked to begin with so this shouldn't be necessary.

Edited by Simon-, Jan 7 2013, 7:25pm :

Hmm, wonder if someone will come up with a way to bootstrap the jailbreak process to run at startup every time. Either way, if applications can be written to the full Win API then there are endless possibilities. Can't wait to see what people come up with!

i think part of the reason is because of Intel and Microsoft's relationship, essentially if Windows RT allowed desktop apps, there will probably be an ARM desktop computer

The relationship between Intel and Microsoft actually isn't very good. Anyway, I think Windows RT is a deliberate move in that direction. They are laying the groundwork now.

The crux of the post is this, there is no technical limitation to stopping desktop applications from running

Seriously? You and other people did not understand this?

This is the DUMBEST thing I have read this year. Does nobody have a freaking clue what Windows NT is or how works? Really?

Windows RT is Windows 8 just running on ARM, in what person's diseased mind would they think it was incapable of running desktop applications, especially when the majority of the OS utilities, desktop Apps and Office itself are DESKTOP applications.

Just compile for ARM and circumvent any certificate/signing requirements. This doesn't let x86 Apps run, you at least get that, right?

Holy stupidity batman.

Edited by thenetavenger, Jan 7 2013, 5:58am :

thenetavenger said,

Seriously? You and other people did not understand this?

This is the DUMBEST thing I have read this year. Does nobody have a freaking clue what Windows NT is or how works? Really?

Windows RT is Windows 8 just running on ARM, in what person's diseased mind would they think it was incapable of running desktop applications, especially when the majority of the OS utilities, desktop Apps and Office itself are DESKTOP applications.

Holy stupidity batman.

*Minds Blown*

Windows RT, by default, only has Office as a Desktop app, unless I'm missing something? This bypasses that limitation, which is what he's referring to...

farmeunit said,
Windows RT, by default, only has Office as a Desktop app, unless I'm missing something? This bypasses that limitation, which is what he's referring to...

There are literally hundreds of programs in the windows folder that are Win32 apps, think notepad, control panel, bluetooth share (fsquirt.exe) etc etc etc... all this exploit does is lift the restriction Microsoft intentionally put in place to prevent malware and shiit from getting on Windows RT. There is and never was any technical limitation of being able to run desktop software on Windows RT despite all the FUD spreading over many ignorant techsites namely c/zdnet by people who are so called "IT journalists" that really don't know the slightest about computing particularly operating systems. The only thing stopping us was a kernel value which has since been located and exploitable in memory. Now all we need is a persistent patch (or hopefully a toggle released by Microsoft ) to let us keep our crap running after the device is shutdown!

Edited by Charisma, Jan 7 2013, 2:19pm :

thenetavenger said,
Windows RT is Windows 8 just running on ARM, in what person's diseased mind would they think it was incapable of running desktop applications, especially when the majority of the OS utilities, desktop Apps and Office itself are DESKTOP applications.
Exactly. Windows RT can run Desktop apps, it's just that it's only allowing those that are coded for ARM.

Just compile for ARM and circumvent any certificate/signing requirements. This doesn't let x86 Apps run, you at least get that, right?
I've been thinking the same thing too for months now. That seems to be the biggest hurdle at the moment, to get desktop apps coded for ARM..

ingramator said,
There are literally hundreds of programs in the windows folder that are Win32 apps, think notepad, control panel, bluetooth share (fsquirt.exe) etc etc etc... all this exploit does is lift the restriction Microsoft intentionally put in place to prevent malware and shiit from getting on Windows RT. There is and never was any technical limitation of being able to run desktop software on Windows RT despite all the FUD spreading over many ignorant techsites namely c/zdnet by people who are so called "IT journalists" that really don't know the slightest about computing particularly operating systems. The only thing stopping us was a kernel value which has since been located and exploitable in memory. Now all we need is a persistent patch (or hopefully a toggle released by Microsoft ) to let us keep our crap running after the device is shutdown!
But programs will still have to be coded for ARM, right? Since Windows RT runs on an ARM processor instead of an x86 processor.

Edited by Charisma, Jan 7 2013, 3:48pm :

thenetavenger said,

This is the DUMBEST thing I have read this year.

It`s only a week old! Also do you think this isn`t news, and by that i mean the fact unsigned, non MSFT store apps or exsisting apps recompiled to ARM could potentially run on RT whether the manufacturer want`s it or not!
Obviously it`s not any where near complete yet, plus a patch could be released to stop it.

dtourond said,
But programs will still have to be coded for ARM, right? Since Windows RT runs on an ARM processor instead of an x86 processor.

Indeed or if they are built using the .NET framework then there's a pretty good chance they will be platform independent otherwise any libraries needed will have to be compiled with ARM in mind! That's not the hard bit though, the hard bit is patching the kernel to let you run unsigned code.

ingramator said,

There are literally hundreds of programs in the windows folder that are Win32 apps, think notepad, control panel, bluetooth share (fsquirt.exe) etc etc etc... all this exploit does is lift the restriction Microsoft intentionally put in place to prevent malware and shiit from getting on Windows RT. There is and never was any technical limitation of being able to run desktop software on Windows RT despite all the FUD spreading over many ignorant techsites namely c/zdnet by people who are so called "IT journalists" that really don't know the slightest about computing particularly operating systems. The only thing stopping us was a kernel value which has since been located and exploitable in memory. Now all we need is a persistent patch (or hopefully a toggle released by Microsoft ) to let us keep our crap running after the device is shutdown!

Since you claim to know SO much about Windows, did you know that Windows RT only has about half (probably less) of the full Win32 API? There's a C++ defined called WINAPI_FAMILY_PARTITION that has 2 switches. One (called WINAPI_FAMILY_DESKTOP) that allows the full desktop Win32 API and another (called WINAPI_FAMILY_APP) that limits Win32 to just what is needed for WinRT and for the few desktop apps allowed on Windows RT. Knowing that, even if one could run a non-WinRT native Win32 app it would be limited to just those APIs that available. So whoever is saying this isn't a technical limitation is an idiot.

ingramator said,
Indeed or if they are built using the .NET framework then there's a pretty good chance they will be platform independent otherwise any libraries needed will have to be compiled with ARM in mind! That's not the hard bit though, the hard bit is patching the kernel to let you run unsigned code.
So, by platform independent you mean being to run an application on ARM and on x86/64 processors? To me, platform means Windows, OS X, Ubuntu, etc.

dtourond said,
So, by platform independent you mean being to run an application on ARM and on x86/64 processors? To me, platform means Windows, OS X, Ubuntu, etc.

Well there is Mono which works good enough. So you cross platform in your definition is totally possible.

dtourond said,
So, by platform independent you mean being to run an application on ARM and on x86/64 processors? To me, platform means Windows, OS X, Ubuntu, etc.

No, I mean truly platform independent like you said, across multiple operating systems regardless of their architecture. As long as they have .NET 4.5 installed you will be able to run a .NET application (provided the .NET framework is able to access what it needs in term of APIs)!

SharpGreen said,

Since you claim to know SO much about Windows, did you know that Windows RT only has about half (probably less) of the full Win32 API? There's a C++ defined called WINAPI_FAMILY_PARTITION that has 2 switches. One (called WINAPI_FAMILY_DESKTOP) that allows the full desktop Win32 API and another (called WINAPI_FAMILY_APP) that limits Win32 to just what is needed for WinRT and for the few desktop apps allowed on Windows RT. Knowing that, even if one could run a non-WinRT native Win32 app it would be limited to just those APIs that available. So whoever is saying this isn't a technical limitation is an idiot.

Yes I DO know a lot about Windows and low level kernel memory access in assembly... You are referring to the amount of Win32 APIs accessible through WinRT I detailed that in my response to you below. Please read it, I think you're a bit out of your league here. There is absolutely no technical limitation in Windows RT for running desktop software compiled for ARM or platform independent (.NET 4.5 in this case). The only barrier is a kernel byte which forbids the execution of it, that is why you will get an error when trying to run, for example, an .exe in Windows RT. This security exploit does not alter the kernel, that isn't possible on UEFI (at the moment anyway, we're working on a persistent kernel patch possibly a start-up script if necessary) it merely changes a value that is stored in memory, the oldest trick in the book- altering crap your not meant to while its still in RAM.

ingramator said,

Yes I DO know a lot about Windows and low level kernel memory access in assembly... You are referring to the amount of Win32 APIs accessible through WinRT I detailed that in my response to you below. Please read it, I think you're a bit out of your league here. There is absolutely no technical limitation in Windows RT for running desktop software compiled for ARM or platform independent (.NET 4.5 in this case). The only barrier is a kernel byte which forbids the execution of it, that is why you will get an error when trying to run, for example, an .exe in Windows RT. This security exploit does not alter the kernel, that isn't possible on UEFI (at the moment anyway, we're working on a persistent kernel patch possibly a start-up script if necessary) it merely changes a value that is stored in memory, the oldest trick in the book- altering crap your not meant to while its still in RAM.


Apparently it's you who's out of a league here, since you don't know what a #define is. A #define is not a "kernel level byte" its a conditional compilation statement, that in this case prevents the entire API from being compiled. No amount of bit twiddling is gonna fix that. It also doesn't matter how an app is compiled if it tries to use one of those missing APIs.

I'm laughing at the idea of owning a device that needs to be "jailbroken" to begin with. On Android we have a nice little checkbox:
"Allow installation of apps from unknown sources"

And I have found that checkbox to be VERY handy on numerous occasions.

On Android we have "rooting" to get system access. Android lets you load non-market apps but doesn't let you have full system access by default.

Being able to install non-market apps is completely different. We are talking about being able to run unsigned code not run applications that were built using the Android SDK but aren't submitted on Google Play. There isn't really an equivalent but think of it like being able to run an application that wasn't being executed through the Java layer, a native code and full hardware access allowed application which could essentially let you manipulate the entire OS.

Also with Android you get the shity linux kernel, lag and best of all free data harvesting for sale to companies!! Let alone the fact you have to root your phone to even be able to change any non-SD card file...

Chugworth said,
I'm laughing at the idea of owning a device that needs to be "jailbroken" to begin with. On Android we have a nice little checkbox:
"Allow installation of apps from unknown sources"

And I have found that checkbox to be VERY handy on numerous occasions.

You realize this is not 'universal' for all Android devices, right? Not every version of Android allows this option on all devices. You GET THIS right?

Maybe you don't...

Android devices have to be 'jailbroken' to load a custom version, and many devices have locked out the ability to gain root/jailbreak access.

There is no way to sideload Apps on many Android devices as this option is not available, and they are even locked into a specific App market.

'holier than thou' Android crap is not reality, just ignorance.


Chugworth said,
I'm laughing at the idea of owning a device that needs to be "jailbroken" to begin with.

I'm pretty content with my PS3 and my iPhone and iPad. They do exactly what they were bought for, and I have my PC if I want to do my own work.

ingramator said,
Being able to install non-market apps is completely different. We are talking about being able to run unsigned code not run applications that were built using the Android SDK but aren't submitted on Google Play. There isn't really an equivalent but think of it like being able to run an application that wasn't being executed through the Java layer, a native code and full hardware access allowed application which could essentially let you manipulate the entire OS.

Also with Android you get the shity linux kernel, lag and best of all free data harvesting for sale to companies!! Let alone the fact you have to root your phone to even be able to change any non-SD card file...

Android does native apps as well, oh and you don't need to root the device nor allow installation through unofficial sources in order to use it.

You realize this is not 'universal' for all Android devices, right? Not every version of Android allows this option on all devices. You GET THIS right?

Yeah except for like a few US carrier specific phones all Android phones carry this(you get this, right?), but if you're worried you won't have it, then you can always buy a phone that has the option, which shouldn't be hard to find.

thenetavenger said,

You realize this is not 'universal' for all Android devices, right? Not every version of Android allows this option on all devices. You GET THIS right?

Maybe you don't...

"Allow non-market apps" is a STANDARD feature, manufacturers would have to go out their way to REMOVE it, I don't know any cases of this happening.

Android devices have to be 'jailbroken' to load a custom version, and many devices have locked out the ability to gain root/jailbreak

Again the STANDARD feature is to have the BOOTLOADER unlocked or unlockable, and root access disabled for security reasons (without affecting sideloading) Unfortunately many manufacturers are locking their bootloaders, requiring rooting to get around this limitation. If the bootloader is unlocked, one could simply load a custom operating system that provides root access by default (more access, but not relating to sideloading, but also less security add user has more access to do damage), where 'rooting' is not required at all.

Summary: Sideloading available to all. Rooting/'Jailbreaking' not required to get root access and full access to load another OS/ROM if the manufacturer allows you.

Also Windows RT/Surface bootloaders are locked.

Edited by Simon-, Jan 7 2013, 6:33pm :

I still don't see it. You'll need an emulator for Intel code on the ARM. NET code will still need the Framework installed and all of the satellite assemblies. Further, will these Desktop Programs fall under the PLM (Process Lifecycle Manager)? Without the PLM, these Desktop Programs will kill Memory and Disk. Sounds like a fun challenge but nearly worthless.

seanv said,
I still don't see it. You'll need an emulator for Intel code on the ARM. NET code will still need the Framework installed and all of the satellite assemblies. Further, will these Desktop Programs fall under the PLM (Process Lifecycle Manager)? Without the PLM, these Desktop Programs will kill Memory and Disk. Sounds like a fun challenge but nearly worthless.

nah, office RT and Internet Explorer RT were probably compiled

You don't need an emulator you just need to recompile the source code up to support "any CPU" and take it out of the debug folder. PLM will work for any program launched like any of the office apps or desktop IE10 etc this will be no diference you are merely changing a kernel value (in memory) that allows for unsigned code to be executed!

ingramator said
You don't need an emulator you just need to recompile the source code up to support "any CPU" and take it out of the debug folder.
Sort of like when Apple switched from PowerPC's to Intel, they offered ways for developers to make their programs in a universal binary where it could work on both PowerPC and Intel.

dtourond said,
Sort of like when Apple switched from PowerPC's to Intel, they offered ways for developers to make their programs in a universal binary where it could work on both PowerPC and Intel.

That's fine, but Microsoft didn't port the entire Win32 runtime to Windows RT, just the new Metro-style interface. All those applications are written in C#, which compiles to an intermediate language anyways - which *is* capable of being run across multiple processors as-is. So yeah, Microsoft already does this...

As for the C++/CX-based apps, yes that will require a re-compile, although you'll save space by not having two entirely different versions of the same executable in the same binary file...

Breakthrough said,
That's fine, but Microsoft didn't port the entire Win32 runtime to Windows RT

Yes, they did. office requires Win32. Explorer requires Win32. regedit requires Win32, cmd.exe requires Win32, dxdiag requires Win32, Notepad requires Win32.

Rosyna said,

Yes, they did. office requires Win32. Explorer requires Win32. regedit requires Win32, cmd.exe requires Win32, dxdiag requires Win32, Notepad requires Win32.


He said entire. WinRT is partially Win32.

Breakthrough said

That's fine, but Microsoft didn't port the entire Win32 runtime to Windows RT, just the new Metro-style interface. All those applications are written in C#, which compiles to an intermediate language anyways - which *is* capable of being run across multiple processors as-is. So yeah, Microsoft already does this...

Win32 did not have to be *ported*. Because of the design of NT, this is what it was made for. All they needed was an ARM compiler and now you have Windows running on ARM. Windows uses a Hardware Abstraction Layer (HAL) which takes care of different hardware peculiarities. That was the only thing that needed to be ported. They have full Windows running on ARM. This means anything written for Windows and compiled for ARM will work (or any .Net targeting any CPU).

Also Metro, or Windows Store apps can be written in C#,C++, or HTML5/JavaScript. The C++ apps are fully native, meaning they require a compile for each platform. There is no intermediate language for them.

Also, as WinRT evolves, it will depend less and less on Win32. Eventually it will implemented with no Win32 API's at all.

ingramator said,
?? This will work for any Windows RT tablet mate.

I think he meant Windows RT for a tablet that had something like Android installed.

This could be possible if someone made a bootloader which has UEFI like how Cotulla got UEFI MAGLDR to install Windows RT on the HTC HD2.

DKAngel said,
but how would u run a x86/win32 app on a arm proc on the desktop but?

i am wondering the same thing, unless they're saying that Windows RT actually does some sort of x86 emulation which is awesome on microsoft's part

mrp04 said,
It'll have to be a program compiled for ARM or a .NET desktop program

i see, that makes more sense, but i think the reason they don't want unsigned code is cause of malware and stuff like that, but with this exploit people will be able to load malware

DKAngel said,
which kinda isnt worth it

i somewhat agree, ARM wouldn't be powerful enough to run certain programs and you'll just have a crappy user experience, and the programs it is capable of running you'd use the app store anyway through WinRT or HTML5

DKAngel said,
which kinda isnt worth it

Not worth it? Are you kidding? Being able to run programs like torrent clients and other software like win service crack which will let us easily sideload/repack/redistribute Windows Store Apps. This has massive capabilities and I'm hoping a hacking community will form with some diehard programmers willing to make a persistent kernel patch and a kind of unsigned library of programs that have been recompiled for ARM.

airedwin said,

i somewhat agree, ARM wouldn't be powerful enough to run certain programs and you'll just have a crappy user experience, and the programs it is capable of running you'd use the app store anyway through WinRT or HTML5

Sure, you probably won't have much fun running GIMP or some other graphics/multimedia application that has been recompiled for ARM but there are plenty and I'm thinking torrent clients that will work just fine because we don't have them on the store yet so having them will be a great thing (or ever? I don't know if they are like banned or something)!

airedwin said,

i see, that makes more sense, but i think the reason they don't want unsigned code is cause of malware and stuff like that, but with this exploit people will be able to load malware

You'll have to manually allow unsigned apps to run on your RT device, this can't be done by an app you download by mistake. So not much of a threat for malware.

DKAngel said,
which kinda isnt worth it

Yeah, recompiling is so hard and totally not worth it. /s

Anyway, if it's .NET, it can be (is?) compiled to CIL and just-in-time compiled to native code... and as a result, is architecture independent. So... no work. Yeah. Totally not worth it

Edited by rfirth, Jan 7 2013, 6:33am :

Apple made Rosetta so Intel CPUs could run PPC apps, maybe the same could be written here, converting i386 API calls to ARM API calls?

lkernan said,
Apple made Rosetta so Intel CPUs could run PPC apps, maybe the same could be written here, converting i386 API calls to ARM API calls?

Yes, it could, but it would kill your battery life. Better is to just use programs compiled for ARM, or .NET programs compiled to be architecture independent... all of which is very easy given the foundation that Microsoft has provided.

rfirth said,

Yeah, recompiling is so hard and totally not worth it. /s

Anyway, if it's .NET, it can be (is?) compiled to CIL and just-in-time compiled to native code... and as a result, is architecture independent. So... no work. Yeah. Totally not worth it

and who is going to give you such sourcecode to recompile your x86 desktop apps? hrmmm?

DKAngel said,
and who is going to give you such sourcecode to recompile your x86 desktop apps? hrmmm?

For open source projects, it's easy for you to do. For closed source software, it would be very easy for the developer to do it for you. And if it's .NET, there is a good chance it won't even require a recompile.

mrp04 said,
It'll have to be a program compiled for ARM or a .NET desktop program

I have to wonder about that. It would then have been quite an effort to get Windows Explorer, desktop Internet Explorer, and Microsoft Office (!) all running. Were they truly recompiled for ARM? If true, that would mean Microsoft would also have needed Win32 rewritten for ARM because these applications all use Win32 extensively. Sure, it's possible, but it sounds weird to get an entire API to run under ARM when you don't intend to use that for anything else than some backwards compatibility in a special mode on Windows RT. It would have made more sense to emulate x86, skip all rewrites, and hide the emulation so that only certain Microsoft signed executables can exploit it.

Edit: Thinking about it, maybe they had to rewrite Win32 for ARM anyway, because Metro apps use WinRT and WinRT builds upon Win32? Then I can see if they did recompile all these apps.

Northgrove said,

I have to wonder about that. It would then have been quite an effort to get Windows Explorer, desktop Internet Explorer, and Microsoft Office (!) all running. Were they truly recompiled for ARM? If true, that would mean Microsoft would also have needed Win32 rewritten for ARM because these applications all use Win32 extensively. Sure, it's possible, but it sounds weird to get an entire API to run under ARM when you don't intend to use that for anything else than some backwards compatibility in a special mode on Windows RT. It would have made more sense to emulate x86, skip all rewrites, and hide the emulation so that only certain Microsoft signed executables can exploit it.

Edit: Thinking about it, maybe they had to rewrite Win32 for ARM anyway, because Metro apps use WinRT and WinRT builds upon Win32? Then I can see if they did recompile all these apps.

NT uses a Hardware Abstraction Layer, so they didn't have to rewrite everything. Apart from the ARM-specific parts, it comes down to the compiler they wrote. And for any components that are .NET, they are JIT compiled, so architecture independent anyway. This is the fruit of work they began 20 years ago.

rfirth said,
Yes, it could, but it would kill your battery life. Better is to just use programs compiled for ARM, or .NET programs compiled to be architecture independent... all of which is very easy given the foundation that Microsoft has provided.
And since it's not that difficult to recompile an app for ARM anyways, this + the "jailbreak" will really prove a lot of development this year.

rfirth said,

NT uses a Hardware Abstraction Layer, so they didn't have to rewrite everything. Apart from the ARM-specific parts, it comes down to the compiler they wrote. And for any components that are .NET, they are JIT compiled, so architecture independent anyway. This is the fruit of work they began 20 years ago.

Well said, this is one of the things that puts the NT kernel so far ahead of other kernels. It's starting to pay off as other OS distribution and ancient kernel concepts start to hit walls.

rfirth said,
Anyway, if it's .NET, it can be (is?) compiled to CIL and just-in-time compiled to native code... and as a result, is architecture independent. So... no work. Yeah. Totally not worth it

Is. The byte code nature of both Java and .NET is what they have in common, and it's also why most .NET libraries are reusable with Mono on both Mac OS X and Linux.

lkernan said,
Apple made Rosetta so Intel CPUs could run PPC apps, maybe the same could be written here, converting i386 API calls to ARM API calls?
The Intel chips were also more powerful than the PowerPC chips that they were replacing. That is not the case with ARM processors compared to x86.

lkernan said,
Apple made Rosetta so Intel CPUs could run PPC apps, maybe the same could be written here, converting i386 API calls to ARM API calls?

Technically this would be possible, it would however not be feasable. Arm processors are not able to provide the power to run x86 applications in a similar way as roaetta did for ppc applications. Unless of course ARM would suddenly design real processors, not the toys they design now

sjaak327 said,

Technically this would be possible, it would however not be feasable. Arm processors are not able to provide the power to run x86 applications in a similar way as roaetta did for ppc applications. Unless of course ARM would suddenly design real processors, not the toys they design now

x86 processors are not exclusively more powerful than ARM chips. I'm certain that the current ARM chips are more powerful than the Pentiums of 10 years ago. A significant number of programs could easily run on ARM.