Windows RT Jailbroken To Run Third-Party Desktop Apps 178
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.'"
Non Sequitir (Score:2, Interesting)
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)
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.
Re: (Score:3)
Re:Non Sequitir (Score:5, Funny)
Good news, the Surface will never "brick".
(It will just become a more literal interpretation of the word "tablet")
Re: (Score:2)
A tile?
Sort of -- More like a facade.
Re:Non Sequitir (Score:5, Interesting)
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)
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.
Re: (Score:2)
There's no legacy compatibility story to begin with
There is for open source software and for developers.
Re: (Score:2)
And how many of those would choose Windows in the first place?
Re: (Score:2, Insightful)
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
Re: (Score:2)
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: (Score:2)
It happened to me the last time I tried to create a Word document from scratch back in 2006. I was using Word for the Mac and several pages into a detailed document Word crashed and I could no longer open up the document. Someone suggested later after I restarted from scratch (with OpenOffice) that Open Office might have been able to read the corrupted document. I've never seen applications that had to be so aggressive against their own bugs as the Office apps. I was in the unfortunate situation of having t
Re:Non Sequitir (Score:5, Insightful)
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.
Re: (Score:2)
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)
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.
Re: (Score:3)
In which context it makes even less sense and just sets up WoA as a separate product, not another facet of Win8.
That's exactly how it is intended - which is why it's called "Windows RT", and not "Windows 8" in the first place.
Even selling some kind of "WinRT Enterprise" with this switch set to enabled would probably give them a nice boost for initial adoption - right now corporations thinking about migrating to mobile have to choose whether to rewrite their internal apps for Java, Obj C, .Net, Lua/JS with a crossplatform framerwork or HTML5 and backend, when they could have an easy option of "Recompile it for now and rewrite to Metro part by part in the meantime"
Most enterprises that want to run their existing apps on a mobile device would just get an Intel-based tablet and be done with it.
Note that you kinda outline the problem yourself: even if you can enable RT to run arbitrary desktop apps, you need to recompile not just the apps, but also all the supporting libraries/frameworks. E.g. you can't run Java apps until someone takes JRE and builds it for
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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++
Re: (Score:2)
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
Re: (Score:2)
But this is an OS for a new type and use of computing with a new type of interface. It seems unreasonable that old applications would be particularly welcome or prevalent. I can see the attraction some developers might have -- just recompile and run on RT, but this solution that all the extra crap has to go along with it which will kill the memory and processor limitations not to mention eat up power which this new type of computing has precious little of.
Their approach completely defeats the purpose of t
Re: (Score:2)
Why would anyone in their right mind want to run Windows if it won't run their crusty old Windows apps?
Comment removed (Score:5, Insightful)
Ms only hardware??? then they will need to make (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
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)
Re: (Score:2)
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)
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)
Thanks for the information. How about a native C++ Windows SDK (i.e. headers, libraries, dlls for native desktop apps, MFC etc.)?
Re:well then the appstore will NEED NO censorship (Score:4, Funny)
"Need" implies there are people using it, which is a conclusion we might want to take off our mat for the time being.
Comment removed (Score:4, Interesting)
All the users will be happy. (Score:5, Funny)
All 3 of them.
Re:All the users will be happy. (Score:4, Funny)
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.
Re: (Score:2)
All 3 of them.
who are not Microsoft employees, paid advertisers, etc.
Re: (Score:2)
You're implying that MS employees use their own crap?
The only place that the Surface was sold out was Seattle, with lines wrapping around the block (at least from what the media was saying). Given their 80k+ employees there, that's about the only reason - the employees and their families.
The biggest user of Windows Phone is also their employees - of course, only because MS gave everyone one. No telling how many actually stuck with them though.
Then again, MS never used their own Visual Source Safe product. (They do use TFS to some degree, but I doubt its
Not a Jailbreak (Score:4, Informative)
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)
"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:2)
Re: (Score:2)
How about "I got my phone totally wasted and then installed some unsigned apps"?
Re: (Score:3)
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)
MS, and probably Windows RT licensees won't be happy with losing control over what can be run on that OS.
As I understand, this crack allows legacy x86 code to be recompiled and run on ARM devices. Such as un-crippled Office, other legacy apps by 3rd parties.
Given that this results in sales of additional h/w and s/w by MS, I cannot imagine why they would be unhappy.
Customers ( a short term for Windows RT licensees) would also feel happy about being able to run 'normal' desktop x86 apps on RT.
Intel might cr
Re: (Score:2)
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
Is there a way to use this to install Linux? (Score:1)
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.
Re:Is there a way to use this to install Linux? (Score:4, Insightful)
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...
Re: (Score:2)
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)
Re: (Score:2)
> 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.
Re: (Score:2)
Re: (Score:2)
With the exception of Bionic, which is smaller and weaker than glibc. Android's compatibility with standard GNU-based Linux platforms is extremely weak.
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:2)
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)
Re: (Score:2)
How much code is GPL differs (Score:2)
Re: (Score:2)
Lesser of two evils (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Troll)
Despicable (Score:1)
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.
Re: (Score:2)
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)
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).
Re: (Score:2)
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
Now we can make a Beowolf Cluster! (Score:2)
Tomorrow is Tuesday... (Score:1)
Re: (Score:2)
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
Fraudulent use of a developer license (Score:2)
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"?
Re: (Score:2)
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)
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.
Developing Applications (Score:1)
Re:Developing Applications (Score:5, Informative)
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).
Which 3rd party apps are those? (Score:2)
Still have to be complied to ARM right?
Re: (Score:2)
Won't things that use the CLR run without recompilation?
Re: (Score:2)
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)
That would be for things using .NET. Legacy native code, written in C/C++, would have to be recompiled.
Re: (Score:2)
CLR = Common Language Runtime = "things using .NET". You basically just re-stated his comment...
Summary continuation (Score:5, Informative)
Based on the little I know... (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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
Good if they dont sell out like the Chevron devs (Score:2)
This would be good if they keep their independence from Microsoft and allow these phones to do some good.
Re: (Score:3, Informative)
The fine article has a big link in the first paragraph: "What is WIndows RT?"
Oh, wait...
Re: (Score:2)
Really, building your own walled garden of executables from places you trust actually sounds like a pretty clever idea. It also sounds like Linux
Re: (Score:2)
To speculate on your question, I would suggest that it's probably something to do with the fact that you have a bit of a reputation for what I might call an erratic posting style. You're usually very long winded on a topic, and I've seen you post things that
Re:Whitelisting of a sort (& the future of sec (Score:5, Interesting)
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.
Re: (Score:2)
Accessibility by definition grants extra ability to those who have less or no skill.
There's nothing wrong with accessibility in general. But it incurs a cost. By granting the unskilled extra power that they have no skill in weilding, accessibility makes the landscape that much more dangerous. There are those who are willing and able to become skilled, and through an increase in accessibility, there will be an increase in these people. But this happens at the cost of having to deal with everybody else, who a
Re: (Score:2)
See subject-line, & that quote of myself, vs your misinterpretation of what I wrote (or perhaps you just missed it)...
You mean the subject line that is simply showing as "Whitelisting of a sort (& the future of securi"?
As far as possibly misinterpreting you, I will admit your writing style is not as clear as it could be but you clearly go on about whitelisting being most/all of the security solution (to the extent you talk about it possibly replacing AV software). If that was not the point you were trying to get across, then I apologize but that is how it came across to me.
See above again - in corporate environs, where THE MACHINE IS NOT THE USERS but the companies? That'd be the network admins doing the testing (hopefully).
In this case the network admins/company are st
Whitelisting will need NO Centership other then ap (Score:2)
Whitelisting will need NO Centership other then apps the crash the system.
and more then 1 app store as well a 100% free zone for both dev's and users.
Re: (Score:3)
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 usua
Scriptable? (Score:2)
You can sideload "Metro" applications just fine (after running one command to unlock this capability).
How hard is it to script the periodic commands to renew this capability?
Re: (Score:2)
Pretty easy, the task scheduler is included in Windows RT. It's a single Powershell command (must be run as Admin): Show-WindowsDeveloperLicenseRegistration. That pops an interactive dialog, but it's easy enough to get through.
I actually hadn't bothered to do this before (I have MSDN access, so the developer registration lasts for 3 months each time) but for those using the 1-month registrations, a scheduled task to renew it makes a lot of sense.
Re: (Score:2)
Since when attaching the debugger constitutes a jailbreak?
Since the operating system allowed the user to attach a debugger without a recurring payment. This, as I understand it, is one difference between the Windows RT developer license model and the $99 per year model used by Xbox Live Indie Games, iOS, and Windows Phone 7.
Re: (Score:2)
The important point here, other than that yes, you can sideload and debug on RT without paying extra for the privilege, is that the value which must be changed is in kernel mode, but RT only allows user-mode debugging. The kernel debugger is disabled via Secure Boot (the bootloader understands the debug switch, but if you attempt to set it, Secure Boot will block you).
Typically, attaching a debugger to a user-mode process still doesn't let you modify kernel memory; the debugged process and the debugger itse