Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Microsoft Hardware Hacking Windows Build Hardware News

Windows RT Jailbroken To Run Third-Party Desktop Apps 178

Posted by samzenpus from the free-at-last dept.
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.'"
This discussion has been archived. No new comments can be posted.

Windows RT Jailbroken To Run Third-Party Desktop Apps More

Windows RT Jailbroken To Run Third-Party Desktop Apps

Comments Filter:

  • Non Sequitir (Score:2, Interesting)

    by recoiledsnake ( 879048 )

    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.

    • Re:Non Sequitir (Score:4, Insightful)

      by Anonymous Coward on Monday January 07, 2013 @12:01PM (#42506315)

      Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s.

      Yeah, it's all about freedom from backwards compatibility and legacy code!
      Wanting to be like Apple and get paid every time a customer installs any software has nothing to do with it.

    • MS locked it down so you could only run apps you bought from the app store same reason apple locks theirs down. I suspect atleast with MS upgrade probably patches wont turn your unlocked tablet into a brick.

    • Re:Non Sequitir (Score:5, Interesting)

      by JDG1980 ( 2438906 ) on Monday January 07, 2013 @12:37PM (#42506763)

      Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s.

      If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge, but Ballmer seems to have forgotten this in his Ahab-like quest to chase down Apple.

      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.

      If Microsoft could have ditched legacy API usage for Office that easily, I think they would have done so already in the first release of Surface. At this point, the Office codebase is probably so FUBARed with 20+ years of spaghetti code and the need for backwards compatibility with 500 different document types that I doubt they could rewrite it completely even if they wanted to. Office for MacOS is almost a completely different product, done by a separate business unit. And if Microsoft ever releases a slimmed-down "Office" for iOS and/or Android, then those products will probably be written from scratch, and will not be 100% backwards compatible with anything other than OOXML.

      (Of course, any competent programmer could write a better version of Notepad in a month, so that's really not a factor.)

      • Re:Non Sequitir (Score:5, Informative)

        by shutdown -p now ( 807394 ) on Monday January 07, 2013 @01:26PM (#42507427) Journal

        If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge

        We are talking specifically about Windows RT running on ARM here. There's no legacy compatibility story to begin with, even if the restriction on MS-signed-only desktop binaries weren't there in the first place.

        • There's no legacy compatibility story to begin with

          There is for open source software and for developers.

          • And how many of those would choose Windows in the first place?

            • Re: (Score:2, Insightful)

              by tftp ( 111690 )

              And how many of those would choose Windows in the first place?

              Quite a few, if you count how many F/OSS applications are available on Windows. Majority of customers are not even in control of what OS they are running. If GIMP or Dia or OpenOffice are not available on Windows then it's like they are not available at all. Developers generally care about their customers, even though they may express no joy about the need to compile their product using a not quite compatible toolkit. It's always simpler to pu

              • Why would I want OOo? It's easier to use and sometimes even loads documents that Office chokes on? What's the fun in that?

        • Re:Non Sequitir (Score:5, Insightful)

          by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Monday January 07, 2013 @03:08PM (#42508895)

          If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge

          We are talking specifically about Windows RT running on ARM here. There's no legacy compatibility story to begin with, even if the restriction on MS-signed-only desktop binaries weren't there in the first place.

          You may have failed to realize that Win32 doesn't mean 32 bit windows API. It simply means "Not the old 16 bit API" I write all my widgets from scratch, and I talk to OpenGL directly, no SDL, no freeglut3, no MFC, just straight Win32 and OpenGL to make the lightest weight most efficient programs, even on 64 bit systems. It's crazy as hell to do this, yes, yes, I'm glutton for punishment, ha ha, you jest, "re-invent every wheel", I know, but game developers are allowed to throw away every best practice in the name of performance... Besides, you don't see wagon wheels on a formula-1 car, eh?

          That is to say, Win32 can be compiled on ARM, and then I compile my code that uses the Win32 API to get a window and event loop, and the "legacy" compatibility isn't an issue. Event pumps and windowing callbacks are going to exist no matter what API they build. If you're talking cruft, then it's that COM stuff and .NET and MFC and all the other stuff that's built on top of win32, not win32 itself.

          IMO, Win8 is about MS trying to sandbox programs via VM (C#) and simultaneously provide cross platform support while taking a cut of every software sale made. Now, I'm not going to eat that app-store cost. You are. I'll just raise my price accordingly on MS's market to offset those fees... Sucks, but C'est la vie. If MS continues allowing "side-loading" then they can't force developers like me to sell programs in their store -- C/C++ is cross platform, and so is my code, so I just rebuild the binary for each target platform, it's not a big deal. Rebuilding everything in C# and suffering that vendor lock-in cluster fsck is really off-putting, considering my C code runs across the board on every chipset, even MIPS, and every OS (thanks to OS abstraction layer, and a bit of meta-programming for iOS and Android)... No such luck with C#, yet.

          That's where MS wants to take their market -- Incompatibility land. IMO, I wouldn't play their shenanigans unless I had to, I don't think OS choice should limit software choice (and I don't think hardware choice (beyond performance) should limit OS choice. This is shit we had well and good SOLVED in the 70's. MS sees the road ahead: The bright future where all programs are cross platform -- The road to OS irrelevance -- they hate that future, they hate your freedom to choose to run any OS on your hardware. Hence SecureBoot (Which I've said time and again is Pointless), Hence C# only in App Store & XBL Indie Games, hence blocking any apps that aren't signed by MS, and not allowing users to add their own trust certs to the OS / Hardware. The jig is up. W8 is just one more battle in the Vendor Lockin war.

          I don't mean to pick on MS, Apple is going down the same road with an app-store route for their desktop too. GNU/Linux, BSD, Android, and other FLOSS OSs are the only ones that get the software repository system done right, and not even stock Android allows user installing a new / additional cert trust (recompile). This is a fight over developers, it's the applications that matter, OSs have been irrelevant for quite some time now. It's only a matter of time -- MS can't win this one, they couldn't write secure code to save their ass, which is exactly what they'd need to do.

          • That's where MS wants to take their market -- Incompatibility land.

            Right. And in their defense, that's where they built their fortune. So no matter whether you like it or not, that's where their entire business model is. Of course they won't abandon it, their tiny physical device sales (Xbox360, Kinect, Surface tablets) and small services sales ( Windows Azure, Microsoft CRM, etc.. ) can't make up for all of the revenue they depend upon from Windows and Office.

            But incompatibility benefits them at o

          • Re:Non Sequitir (Score:4, Insightful)

            by shutdown -p now ( 807394 ) on Monday January 07, 2013 @04:04PM (#42509851) Journal

            You may have failed to realize that Win32 doesn't mean 32 bit windows API. It simply means "Not the old 16 bit API"

            I don't fail to realize anything - I know perfectly well that Win32 is a cross-architecture API. My point was that, from users' perspective (and especially for enterprise users, which is what GP was referencing), the compatibility story is nil because there are no existing apps that would run. Sure, most apps are just a recompile away, but someone would have to make that recompile.

            IMO, Win8 is about MS trying to sandbox programs via VM (C#) and simultaneously provide cross platform support while taking a cut of every software sale made. Now, I'm not going to eat that app-store cost. You are. I'll just raise my price accordingly on MS's market to offset those fees... Sucks, but C'est la vie. If MS continues allowing "side-loading" then they can't force developers like me to sell programs in their store -- C/C++ is cross platform, and so is my code, so I just rebuild the binary for each target platform, it's not a big deal. Rebuilding everything in C# and suffering that vendor lock-in cluster fsck is really off-putting, considering my C code runs across the board on every chipset, even MIPS, and every OS (thanks to OS abstraction layer, and a bit of meta-programming for iOS and Android)... No such luck with C#, yet.

            Just FYI, Store apps are not required to be managed. You can write 100% native apps in C++ for it [microsoft.com] - no VM, no GC.

            (Yes, it does use language extensions for system APIs, although even those are optional. And yes, those extensions do look like C++/CLI. Nevertheless, they work differently, and they don't compile to managed code.)

            Hence C# only in App Store & XBL Indie Games

            Store apps don't support XNA. In fact, pretty much the only way to write a game for Win8 Store right now (unless it's something so basic that you can make do with XAML or HTML5) is to use C++ and Direct3D.

      • Office for Mac and Office for Windows are at least 70% the same code, and that was a few years ago. They were targeting 90%, I believe. Already, all of the document rendering/layout/document format code (at least for 2010/2011) is supposedly identical, just recompiled for OS X. The GUI and certain features specific to each platform obviously must be different, and there's a compatibility layer which abstracts the core APIs used by Office from the OS they run on (supporting things like using the Windows Comm

      • If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system.

        There is some truth to this, but my feeling is that as long as Microsoft's own desktop software is Windows only*, that will be enough to keep the business desktop on Windows. But on top of that, you can count on ISVs producing RT versions of their software, but many still don't have much incentive to port them to anything else. Businesses want to standardize the desktop, even if it causes them some pain. That standard will continue to be Windows, because it is currently the standard, if for no other reason

      • But... but... but... the Office document formats have been documented! Third-party compatibility shouldn't be an issue any more. Nor should MS have to rely on a quarter century of some of the cruftiest code on the planet to maintain their monopoly. They can simply create new apps with more flexible (and comprehensible) UIs and modern, efficient code to replace the legacy Office.

        Right? Right?

        • But... but... but... the Office document formats have been documented! Third-party compatibility shouldn't be an issue any more. Nor should MS have to rely on a quarter century of some of the cruftiest code on the planet to maintain their monopoly. They can simply create new apps with more flexible (and comprehensible) UIs and modern, efficient code to replace the legacy Office.

          Yes, I know this was sarcasm, but it's still worth elaborating upon.

          The modern Office file formats are indeed properly documented

          • Yes, I realize that the legacy formats are a big issue here, because they still have to be reverse-engineered to be supported (and ironically, non-Microsoft software has a better reputation for compatibility than Office itself, which tells you something).

            I didn't even want to mention the can of worms that is VBA because in addition to being a vintage 1990 development environment, it exposes the fact that Office apps are incredibly brittle and unstable.

            But Office is still a monopoly, so it will remain a boat

      • Microsoft locked Windows RT down because it wanted to slowly get rid of the Win32 cruft dating back to the 80s and 90s.

        If Microsoft gets rid of the "Win32 cruft dating back to the 80s and 90s", then there will be no reason for anyone to choose Windows over any other operating system. Legacy compatibility and a huge installed base of applications are Microsoft's primary competitive edge, but Ballmer seems to have forgotten this in his Ahab-like quest to chase down Apple.

        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.

        If Microsoft could have ditched legacy API usage for Office that easily, I think they would have done so already in the first release of Surface. At this point, the Office codebase is probably so FUBARed with 20+ years of spaghetti code and the need for backwards compatibility with 500 different document types that I doubt they could rewrite it completely even if they wanted to. Office for MacOS is almost a completely different product, done by a separate business unit. And if Microsoft ever releases a slimmed-down "Office" for iOS and/or Android, then those products will probably be written from scratch, and will not be 100% backwards compatible with anything other than OOXML.

        (Of course, any competent programmer could write a better version of Notepad in a month, so that's really not a factor.)

        ===
        Look at Notepad++

    • The cruft should not need to exist for a different processor architecture running applications written for the new and different processor architecture.

      And by "cruft" I mean code which is unused or unnecessary. If it is used by Office and Notepad and neither application will be present, then it is "cruft" and should be removed from a nimble and light-weight Windows.

      Putty and VNC would have to be rewritten for the new environment because Windows RT is "all new" and "written from scratch" without any of this

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Monday January 07, 2013 @01:46PM (#42507669)
      Comment removed based on user account deletion

      • Ms only hardware??? then they will need to make alot more choices then what apple has and lunix will get all the high end systems / good video cards.

        Ms may even try to lock in video cards as well.

      • But they don't really do what Apple does. The "App Store" on my Mac is only accessed by a simple text menu entry under the Apple menu. Unlike Windows 8 metro, I never see any applications pointing me to the store, I don't get any applications tell me that they refuse to run without my having an Apple ID, and I can download and run software I get from anywhere on the web.

    • Re: (Score:2)

      by wmac1 ( 2478314 )

      Even if it could be jail-broken, how people are going to develop native WindowsRT software? Is there any compiler and Windows RT (native) SDK available?

      • Re:Non Sequitir (Score:4, Informative)

        by cbhacking ( 979169 ) <been_out_cruisin ... nospAM.yahoo.com> on Monday January 07, 2013 @04:28PM (#42510291) Homepage Journal

        Visual Studio 2012 (including the free Express variants) can compile for ARM. In fact, they have to, otherwise you couldn't write native apps (games, usually) for Windows RT at all. .NET code and HTML5+JS apps will run natively on RT without recompiling, but C++ apps - which is how most games are written, and some other software - require a recompile. It's trivial to do this recompile in VS, though - there's a drop-down option to build for x86, x64, or ARM.

        Now, with that said, by default Visual Studio won't let you build an ARM *desktop* app, only a "Windows Store" (The Interface Formerly Known As Metro) app. This is very easy to work around, though - you either need to set one #define (or /D in the build command) or change the relevant header (the error tells you which one) and also change one XML build configuration (again, you'll get an error telling you which one). The instructions for doing so have been posted on XDA-Developers for months.

        • Re: (Score:2)

          by wmac1 ( 2478314 )

          Thanks for the information. How about a native C++ Windows SDK (i.e. headers, libraries, dlls for native desktop apps, MFC etc.)?

  • All the users will be happy. (Score:5, Funny)

    by Anonymous Coward on Monday January 07, 2013 @11:56AM (#42506247)

    All 3 of them.

    • Re:All the users will be happy. (Score:4, Funny)

      by Anonymous Coward on Monday January 07, 2013 @01:50PM (#42507743)

      Dude, this stupid meme is getting fucking old. Just quit, it's not funny anymore. I know for a fact there is at least double the amount you quote that are using it.

    • All 3 of them.

      who are not Microsoft employees, paid advertisers, etc.

  • Not a Jailbreak (Score:4, Informative)

    by 0x15e ( 961860 ) on Monday January 07, 2013 @11:57AM (#42506261)

    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.

    • Crack, Rip, Hack, Jailbreak ... (Score:5, Insightful)

      by bill_mcgonigle ( 4333 ) * on Monday January 07, 2013 @12:17PM (#42506537) Homepage Journal

      "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.

    • Re: (Score:3)

      by jkrise ( 535370 )

      I'd call this a crack instead of a jailbreak

      In other words, the most commonly employed method by 'pirates' to get software for free to run on Windows systems?

      I have personally not used Windows8 at all; but I hear from a local PC vendor that with Win8, you cannot get 'cracked' copies of Win8, but only 'cracked keys' to activate the damn thing; for kids who must have the latest OS at any cost on their PCs.

      I expect MS will probably just find a way to patch it up in the near future.

      No. I have seen MS for

    • Re: (Score:2)

      by mysidia ( 191772 )

      I expect MS will probably just find a way to patch it up in the near future.

      The "hole" though requires a hacker to tinker with memory.

      I expect what Microsoft will instead do is restrict debugging access -- remote debugging ONLY available on special installs of Windows RT "Developer Edition"; requiring a special product key, to enable developer functionality.

      The tablets sold to consumers won't be developer-enabled, therefore, won't have the remote debugging functionality required to tamper with kern

  • Or Android? If so it might be possible to render these gadgets useful, even if it does require going through a song and dance every time you reboot.

    • 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...

      • I wonder idly if this could be used to run Wubi to install Ubuntu in that strange dual-boot-from-a-boot-file-that-sits-within-Windows way that it does. If so, that'd be a pretty big breakthrough.

        Come to think of it, I have no idea how Wubi would react to a "secure boot" set up.

        • Re: (Score:2)

          by HJED ( 1304957 )
          From my understanding of Secure boot, I don't think wubi would work because I think it modifies the part of the bootloader that is signed. It is also probably only designed for x86 systems and as Windows RT runs on ARM, it might not be compatible. (It at least partially acts like a boot loader which is quite architecture specific)

      • > What is more interesting is the fact you maybe able to
        > completely rewrite the whole thing; getting rid of windows
        > entirely...

        That's what I meant.

    • That should be including Android, since Android is Linux. It is both the Linux kernel, and the typical user space tools you would find in a base GNU/Linux distribution. You can adb shell into a device and ls, cp, etc. and you can even get Busybox from the Google Play store. If you have the skills, nothing stops you from cross-compiling your own FOSS software and installing it as well. On many (almost all?) devices, you can also build and install a custom kernel, as has been done time and again.

      • With the exception of Bionic, which is smaller and weaker than glibc. Android's compatibility with standard GNU-based Linux platforms is extremely weak.

        • "Android's compatibility with standard GNU-based Linux platforms is extremely weak."

          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.

          • Due in no small part to the fact that there is no such thing as a standard GNU/Linux distribution.

            No, due to the fact that they eschew GNU entirely, which is actually pretty common across Linux distributions with the sole exception of Android.

            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.

            I'm aware that Embedded Linux don't use glibc, they tend to use uClibc or (worse) something

            • "Google wanted to control it all and cater to handset vendors that don't like having to comply with the GPL."

              You need to research Linux and its license. It is impossible to use Android without having to comply with the GPL. Every Android manufacturer is bound by the GPL.

              • Re: (Score:2)

                by tepples ( 727027 )
                My research tells me that manufacturers of Android devices are bound by the GPL only in kernel space. The user space tends toward the Apache license.
                • Did you fail to read what the OP wrote? Or is it that you are intentionally trying to change the subject?
                  • I agree that it is illegal to distribute Android without agreeing to the GPL. The difference between Android and GNU/Linux lies in how much code is affected by the GPL. Unlike GNU/Linux, Android limits the extent of GPL covered code to the kernel, so any changes to user space need not be distributed to the public as source code.
                    • Yes. That was my point. The OP stated that "Google wanted to control it ALL and cater to handset vendors that don't like having to comply with the GPL". (emphasis added) Since we both agree that they still need to comply with the GPL, nor does Google control it all, we clearly agree that the OP made a ridiculous statement, right?
                    • Android caters to manufacturers that don't like GPL compliance by minimizing the amount of what they have to do that they don't like. Say a manufacturer has two relevant options: either A. do what it doesn't like to a small extent, or B. do what it doesn't like to a large extent. The manufacturer is more likely to tolerate doing A as what it considers the lesser of two evils. In this case, Android is A and a GNU stack is B. With Android, they have to distribute source code only for changes to the kernel. Wi

                    • " With GNU/Linux, they would have had to distribute source code for all modifications, including the launcher modifications that manufacturers use to distinguish their products from those of other manufacturers."

                      Tell that to Red Hat and any Distribution that supports an NVIDIA or ATI proprietary driver. They implemented a new WM because they needed something that made sense for Smartphones, and there was nothing freely available. They created Dalvik to avoid licensing costs. You clearly don't understand

          • Android isn't the only Linux distro that isn't GNU. You are correct in that.

            Now, what part of that fact makes the GP complaint unfounded? Android could be a GNU/Linux distro, Google decided that it wouldn't, and this makes Android worse.

            • You are both making the assumption that Android has to use Bionic. That is what makes the complaint unfounded.

  • Despicable (Score:1)

    by Anonymous Coward

    This trend of making it hard/impossible to run what you want on your computing devices is just despicable. I predict that not many years from now there won't be a commonly-used platform where you can download whatever you want and run it. We may be way past the year 1984, but we sure seem headed for 1984.

    • Not so, I read on /. that Google, being the primary force for good on the Earth today, is going to produce a mobile OS which will free us from such things.

    • Re: (Score:2, Interesting)

      by Patch86 ( 1465427 )

      Linux isn't going anywhere, and there are plenty of niche manufacturers out there producing purpose-built Linux laptops and desktops (well I say plenty...you know, relatively speaking). Presumably they'd see a fair surge of business if they became the only way to run Linux (rather than the hitherto standard method of buying anything you like from Dell/HP/whoever and just wiping the hard drive).

    • I predict that not many years from now there won't be a commonly-used platform where you can download whatever you want and run it.

      Well, I predict that not many years from now, whatever plataform(s) that let you run whatever software you download/write will be the one(s) that is(are) commonly-used.

      There were previsions similar to mine and yours before, the ones similar to mine were always right, the ones similar to yours were always wrong. Maybe this time it is different, but I'll only belive it if somebody

  • I foresee an update to Windows RT tomorrow (or soon thereafter) to plug this serious threat to user security (have to secure users from getting apps somewhere else that Redmond doesn't make money from)

    • You do realize that sideloading "Modern" (a.k.a. "Metro") applications is fully possible and officially supported, right? The difference is that those have to run in an application sandbox that limits their capabilities and restricts the APIs they can call... in particular, they aren't supposed to be able to access the Win32 API, which is needed for making something that is recognizably Windows software (what Microsoft is calling a "desktop app" because it runs in the Desktop view of Win8 / Windows RT).

      The

      • You do realize that sideloading "Modern" (a.k.a. "Metro") applications is fully possible and officially supported, right?

        Microsoft states [microsoft.com] that it "can detect fraudulent use of a developer license on a registered machine." What information is sent back to Microsoft when a developer license is used to allow Microsoft to "detect fraudulent use"?

        • So far as I'm aware, just the application name (specifically, the package name that it is registered on the system with) and possibly a binary list; I haven't fully explored it yet. This appears to be intended as an anti-piracy protection. I've got a number of sideloaded apps, including some which are relevant to this type of work and completely unsuitable for Windows Store development (I'm looking into an alternative approach that doesn't require a kernel security hole, but I'm nonetheless on the periphery

          • Re: (Score:2)

            by tepples ( 727027 )

            If MS wanted to block the developer license I use for sideloading them, they could have done so any time in the past few months.

            Of course, I could then just get another one... it's not like the licenses cost anything.

            I was under the impression that blocking a developer license would block that particular Windows OS product key from obtaining another one.

  • Am I missing something here? How can anyone develop new applications for Windows RT and test run them?

    • Re:Developing Applications (Score:5, Informative)

      by Dudds ( 132159 ) on Monday January 07, 2013 @12:28PM (#42506659) Homepage

      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).

  • Still have to be complied to ARM right?

    • Re: (Score:2)

      by DdJ ( 10790 )

      Won't things that use the CLR run without recompilation?

      • Re: (Score:2)

        by 0123456 ( 636235 )

        Won't things that use the CLR run without recompilation?

        Only if they don't call native code at any point, or only call native code that exists on ARM versions of Windows. If they bundle an x86 version of zlib.dll and call it to read .zip files, for example, you're probably screwed.

      • Re: (Score:2)

        by s73v3r ( 963317 )

        That would be for things using .NET. Legacy native code, written in C/C++, would have to be recompiled.

  • Summary continuation (Score:5, Informative)

    by Translation Error ( 1176675 ) on Monday January 07, 2013 @12:41PM (#42506821)
    Since the summary ends before actually getting to the vulnerability it started to describe, here's the relevant text:

    Now, in theory, you could change this hard-coded setting--but all Windows RT devices use UEFI, and so Secure Boot detects the altered code and locks the system down. Secure Boot doesn't stop you from changing the setting in memory, however

  • Once you can attach a remote debugger to a process you can pretty much run whatever code you want, it's just not user-friendly. The big thing here is that a system process is bypassing sanity checks on API calls (for speed, I assume) and so it's exploited to run arbitrary code in kernel mode, and then you have the whole system (in this case, it just flips the switch to allow any app to run, for the current session only I assume, it won't persist to the next boot).

    MS may restrict the processes to which the

    • It's not actually really running arbitrary code in kernel, just changing some kernel memory which causes the kernel to run different code. All the code running is already present in the kernel - this isn't a code injection attack, or even ROP - but instead merely flipping a switch that isn't supposed to be accessible from user-mode. Very minor nit-pick, but I wanted to be clear on that. If (for example) Microsoft had decided to not permit the "Unsigned" level at all, and had removed the code which executes

      • 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 requir

  • This would be good if they keep their independence from Microsoft and allow these phones to do some good.

Slashdot Top Deals

Established technology tends to persist in the face of new technology. -- G. Blaauw, one of the designers of System 360

Close