My father was at the Microsoft HQ for 2 weeks, he sent me a text from there : "Félicité par ms..." ("Congratulated by Microsoft..."), we were talking about the exploit at this moment. This morning, he came back home after a long sleepy flight. Just ten minutes ago, he told me about how Microsoft "thanked" the exploit.
Mark Russinovich, co-founder of sysinternals (Acquired then by MS), made a demo on how to change the color of the bluescreen on a Surface. Using the kernel debugger, he first triggered a bluescreen to see where was the bluescreen display code located inside the kernel. After that, he seeked for the color code (My father didn't remember how) and asked the audience for what color they wanted instead of blue, a man answered pink. Then he made an unsigned driver that would change the code color inside the kernel hex/assembly (I don't know if he had access to the PDB for this exploit), and, thanks to the exploit, he installed the driver. Finally, he triggered a bluescreen that was actually a pinkscreen.
This demo couldn't have been possible without Netham's jailbreak, and Microsoft looks actually very grateful to him. This makes me think that the Surface is kind of a Kinect-like product. The Kinect has been hacked 3 hours after its commercialization, and Microsoft didn't fix it. They even published an SDK so devs can use it on PC for whatever they want. The Surface remembers me that case, and I think they actually waited for a jailbreak to be released.
Thanks Netham for this jailbreak.
Cool though that sounds... there are a few important points here.
0. Netham45 publishes a nice tool, but it's not really his exploit. The research that produced the jailbreak hack in its basic form was performed by another XDA-Devs member, clrokr.
1. Odd that you mention a kernel debugger. Clrokr's exploit, as published, doesn't enable kernel debugging. That's blocked by Secure Boot policies which aren't affected by this hack.
2. If Microsoft wants to enable a kernel debugger, they can do that easily without any external help. For that matter, it's known that development devices (i.e. non-production-models) come with a much less-restricted bootloader; it's not as if MS developed Windows RT or the drivers for various devices without having a kernel debugger already!
3. Similar to #2, if Microsoft wants to run arbitrary user-mode code on Windows RT outside of an AppContainter sandbox, they can do that already via three different methods: either enable TestSigning mode and install their own certificates (we can't do this due to Secure Boot, same as kernel debug block), sign the binaries with their own trusted keys (obviously they can do this, or none of the Windows RT desktop mode software would run!), or simply change the signature enforcement check in the kernel and re-compile it (it's just a flag they can set; Windows on x86 has the same flag but it defaults to no enforcement for user-mode code and they could change that on RT easily).
4. Going back to #1, the current exploit is for user-mode code. So far as I know, it doesn't enable installing custom drivers either. Again, that's probably done either by enabling Testsigning mode (on a non-secure-boot-locked system) or removing the signature enforcement entirely in a custom Windows RT build.
That said, whatever the oddities in your story, I hope this works out like you describe. I personally think MS shot themselves in the foot with the restrictions of RT, and I hope they come to their senses about it. I've actually met Russinovich, and he's a very cool dude. He doesn't strike me at all as the sort of person to support a lock-the-user-out-of-their-own-system policy like RT currently has. Unfortunately, his position at MS (Technical Fellow) is has influence but isn't actually managerial; if the people in charge of the RT project demand that the jailbreak be blocked, it will be and Mark might have very little to do with the decision.
He can't remember all the details. My father works on PDW not debugging, and the debugging tools Marc used are from Sysinternals as far as I remember. But yes the details may not be accurate.
Mark might have very little to do with the decision
Click to expand...
Click to collapse
Doesn't it sound like "politically incorrect" to make this kind of hack on a Surface if that goes against the opinion of the company ? I know Microsoft doesn't keep an eye on every single demonstration from their employees but that would sound odd if MS finally fixes it. It is true that they lock their Xbox products as hard as they can, but there is commercial argument in the case of the Surface. Official developers will still develop Metro apps if they want to aim at WinRT users.
Related
Hi,
I asked this question over on another mobile phone forum and a user directed me here, so here goes:
Is it necessary for apps developed for Windows Mobile 5 and 6 (PPC) to be "signed" in any way in order to be installed and run? Similar to the way newer Symbian OS apps must be signed? Or can they just be developed and flat-out installed without any hassle or complication, the same way apps for regular desktop Windows PC's can be?
As a programmer/developer and also a Symbian user, I absolutely HATE the need for signing or certifying anything for it to be able to run. If it's not necessary on a laptop or desktop, it shouldn't be necessary on a phone. I am considering switching over from Symbian to WM6, but ONLY if the platform is completely free of the need for anything resembling certificates and signing.
At the very least, is there the option for the end WM6/5 user to easily change a setting within the OS so as to allow the full installation of non-signed apps? I'd settle for that. With Symbian, both developers and users are completely imprisoned by certificates and cannot do anything without the permission of the OS fascists.
Thanks for any help on this..
on WM5 default, when you try and uninstall something unsigned, you just have to tap the "yes" button to run the application, after that it remembers it for that app.
so basically for my setup (wm5/wm6) i can run anything, signed or unsigned. And there is a fix somewhere to disable the notification warning
hope that helps
and
come to the light side
Pocket PC's for the win
Thanks for your reply.. it's certainly encouraging to hear that WM5/6 is not restricted by the absolute necessity for signed certificates like Symbian is. As a programmer I completely refuse to bother developing software for a platform that handcuffs both developer and end user so mercilessly. If I can write programs in Visual Basic that will comple to an EXE and run hassle-free on any Windows PC, I don't see why I should have any less freedom when writing programs for a mobile device.
SymbianSigned and its locked OS is a deal-breaker for me. In looking through this forum though, it seems that there are in fact some components of WM that absolutely must be signed to be installed? Like skins for example? Are there any other components that fall into that category?
Still hoping to get a defnitive answer on what components of WM require mandatory signing and which ones are totally non-restrictive optional. So far my understanding is that under no circumstances do any applications ever have to be signed in order to be installed and run, no matter what kind of advanced access and functions they involve. Correct? Whereas fully integrated keyboard skins do need to be signed, for some reason. Correct?
Any other categories not covered above that do or don't require signing?
Thanks!
As far as I know the worse case scenario for signing is that you must also install your own cert. All that happens when you do this is again a warning.
As for the merits of the whole signing thing. Although I agree symbian goes too far, I think some kind of signing procedure, that is more robust should be required for windows mobile.
My preferred solution would be to have restricted functions that on install warn the user of exactly what capabilities the SW has, and allows the user to allow or restrict certain capabilities.
Simply an I trust this or that is useless as everyone ends up trusting everything as you have little choice. But given that it is easy to write SW using the RIL functions that completely unknown to the user can call expensive pay lines, download ridiculous amounts of data over gprs, or even send me personal information from your device, some security should definitely be required.
The truth is because of the ability to make expensive phone calls directly to people who will have direct financial benefit, I would argue security for a phone is at least if not more important than on the PC.
my 2 cents
WM5/WM6 editions for touch-screen devices generally come with "relaxed" security which means that third party apps don't have to be signed to execute once somebody answers yes to a first-time warning dialog box. ROM cookers here generally relax this requirement even more by setting a registry value HKLM\Security\Policies\Policies\0000101A to a 1. This disables the first-time warning message also.
However, services and device drivers generally need to be signed because they are executed before these relaxed settings take effect. Application developers generally can work around this too by starting the service/device driver themselves with a little program placed in \windows\startup
WM6/WM5 editions for devices without touch-screens generally have a higher security setting that disallows execution of any application unless it is signed.
I want to change default Minimum Signing Level in ci.dll on my windows 8 pro.Can someone tell me how to do that?
The hack used to change Minimum Signing Level at run-time in Windows RT would also work (with replacement of the THUMB2 instructions for x64 or x86 instructions), but that's pretty wasteful as a way to do it. Using a kernel debugger would also work, though you'd probably need another computer to do it from. Modifying the file itself... possible, but tricky. You have to turn off the system file restoration service, or block it somehow. You also need to either use a debugger or Test Signing, or the kernel will probably refuse to load the library because its signature will be invalid.
Out of curiosity, why would you *want* to change that value?
GoodDayToDie said:
The hack used to change Minimum Signing Level at run-time in Windows RT would also work (with replacement of the THUMB2 instructions for x64 or x86 instructions), but that's pretty wasteful as a way to do it. Using a kernel debugger would also work, though you'd probably need another computer to do it from. Modifying the file itself... possible, but tricky. You have to turn off the system file restoration service, or block it somehow. You also need to either use a debugger or Test Signing, or the kernel will probably refuse to load the library because its signature will be invalid.
Out of curiosity, why would you *want* to change that value?
Click to expand...
Click to collapse
Because I need something like a EXE(DLL) firewall.I have tried windows 8 build in Parental Controls but its too simple and its not strong enough.So I think the Minimum Signing Level would be helpful.
The tool you want is called AppLocker. There might be others as well.
I'm curious what the use case is where you think that MSL would help. Generally, that's going to be too permissive (users can still run CMD and other MS-signed software) or too restrictive (you don't need to run *anything* third-party?) or both.
I would set app restrictions in the group policy manager if I was you.
If you really want to go down the route of editing the signing level I would suggest creating a driver that edits it instead of actually editing ci.dll. That's not trivial, but it's far simpler than actually editing ci.dll.
AppLocker in the group policy can not block unwanted(unknow) service.And cil.dll checks itself.As netham45 said,a driver is the best way.But I have never written a driver.Could you help me?
AppLocker certainly can block unknown services. You may need to enable DLL Rules enforcement (I'm not sure what it takes to create a Windows Service that runs under svchost.exe; I've never tried, but DLL rule enforcement will work anyhow) and by default APpLocker will block all EXE services (along with all other EXEs you don't specify exemptions for). Unless your users are admins (which they shouldn't be, or you're already hosed; an admin could just undo whatever changes you made anyhow via any method) they shouldn't be able to bypass properly-configured AppLocker policies.
BTW netham45, I'm pretty sure we're talking about the same feature.
FAQ for AppLocker: http://technet.microsoft.com/en-us/library/ee619725(v=WS.10).aspx
What you are asking for is exactly what this Windows feature *does*.
I was thinking of Software Restriction Policies, I've never actually worked with AppLocker but I have worked with SRPs.
That FAQ has a question in the differences.
Something interesting that I found out while thinking about how to interop Unlock WP8: The "PhoneReg.exe" app which is a signed app used for developer unlocking a device is written in un-obfuscated C#.net code!
If anyone has access a program such as Dis#, we should be able to reverse-engineer this and at least figure out what types of data are being passed back and forth between different account types (e.g. Student dev unlock, vs regular dev unlock). Then we can maybe guess at what needs to be passed to Interop-Unlock these devices!
Based on my understanding of how the WP7 interop unlock works, all the Developer unlock does is modify a registry value. As the value gets higher, the more "Development stuff" you can do.
I'll see if I can scare up a copy of that app. Decompiling .NET code is trivial - you don't even need a paid tool, there are many perfectly good free ones (I usually use JustDecompile) - assuming it's not obfuscated.
With that said, bear in mind that we can't currently modify the data that the app receives from the network. That was actually how the original ChevronWP7 unlocker for WP7 worked, but Intercepting (or in the case CWP7U, spoofing) the data was blocked when Microsoft added a feature commonly called "certificate pinning", where rather than checking whether the server's SSL certificate is trusted in general (which you could do by installing a cert manually), the phone now checks for a specific cert (Microsoft's).
However, it's possible (a bit unlikely, but possible) that we'll find a vulnerability in the app. For example, they may have slightly messed up the cert pinning in a way we can exploit (I checked for cert pinning, but I didn't check for ways they might have screwed it up), or they might have left in some debug code we can mess with (that's how HTC interop unlock on WP7 was achieved), or some other such weakness.
If there's some way to help out by testing and such tasks in willing to test on my Lumia 920, if any vulnerability is found Just send me a PM if so
Sent from my Lumia 920 using Board Express
Cool. Good to know. What was nice about the program I mentioned is that it supposedly decompiles everything and then builds it into a nice Microsoft C# project that can be imported into Visual Studio. (I was able to do that, but bits of code within some classes and methods are missing and just have a code comment called //trial)
Some of the interesting code bits I noticed include:
1. the wonderful "NativeMethods.cs" file. This is a wrapper that allows you to call functions within "PhoneREG.dll" such as "GetAuthToken" and "GetWinPhone8Port"
2. "connectionManager.cs" It opens up a session to the phone using port 27077 to pass data.
3. The files called "lockCommand.cs" and "unlockCommand.cs" The deal with passing and converting some kind of "authToken" to the phone.
4. The "SignInDialog.cs" code provides everything necessary to sign into widows Live. It has variables to store oAUTH tokens.
My thoughts are as follows:
1. we could maybe write a custom app that functions as normal, but edits the ByteArray before it gets sent to the phone. Basically you would need an MSDN developer account of some sort, but signing in with this app will give you Interop Privileges.
2. Maybe there will be something "hidden" if we can figure out what this app is talking to on the phone via port 27077.
That sounds interesting. I'll try to look at the data tomorrow before I head to work and see if I can find anything Hopefully I will
Sent from my Lumia 920 using Board Express
If we can actually bypass interop lock with a non-MS signature, that would be fantastic... and I'd be astonished. That wasn't possible in WP7 (Mango or later, when the interop-lock was present) and isn't possible in Windows RT either.
Can you either send the app, or post a link to where you got it from?
Hi guys,
just wanted to give you all a huge *thumbs up*! You're doing great work here!
I have a Lumia 920 for about 2 weeks now.
So, as i did some Lumia 800 and Lumia 900 custom roms, and became a little "bored" to WP7, i would be happy if i could help you by testing some stuff on my Lumia 920
If you need my help, just let me know
lordmaxey said:
Hi guys,
just wanted to give you all a huge *thumbs up*! You're doing great work here!
I have a Lumia 920 for about 2 weeks now.
So, as i did some Lumia 800 and Lumia 900 custom roms, and became a little "bored" to WP7, i would be happy if i could help you by testing some stuff on my Lumia 920
If you need my help, just let me know
Click to expand...
Click to collapse
I know your feeling I made WM6.5.x, Android and WinPho 7 roms for the HTC HD2 before I got my Lumia 920
Sent from my Lumia 920 using Board Express
I have a dev unlocked Lumia 820 and can do any testing if required
If you are running a Windows 8 PC and can install the Windows Phone 8 SDK, the PhoneReg tool can be found at C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Tools\Phone Registration
There are some other tools that I haven't poked around at that could be interesting to try and decompile and "re-work" such as the XapSignTool. (I think this might be written in C++ though)
The SDK in its entirety can be downloaded from http://developer.windowsphone.com/en-us/downloadsdk. You want "SDK 8.0".
I'll get my dev unlock in a month. Will get it as a birthday gift So by then I'll be able to help out more.
Should've checked the USB port stuff this morning, but I didn't have time for it but will do it when I get home in 2 hours
Sent from my Lumia 920 using Board Express
EDIT: Can't seem to find a usable USB sniffer that works under Windows 8, or I've been configuring those I've tried wrong. Enabled TESTSIGNING in BCDEDIT and rebooted, so Test Mode is activated, but no tool seem to work
Regards
The phone itself can communicate with a Windows 7 PC, just not if you want to use the SDK. Perhaps try the same experiment under Windows 7? You might be able to copy the "Phone tools" directory off of Windows 8 onto Windows 7. It uses .net 4.5, so make sure the runtime is installed.
I have already gone down this road and can fairly confidently say it is a dead-end. The only interesting thing I found was the ability to switch a phone to use the internal Microsoft development authentication servers. Best of luck though - maybe I missed something.
SynergeTechSolutions said:
I have already gone down this road and can fairly confidently say it is a dead-end. The only interesting thing I found was the ability to switch a phone to use the internal Microsoft development authentication servers. Best of luck though - maybe I missed something.
Click to expand...
Click to collapse
Thats sad. Do you have any data collected from the communications on port 27077? That's what we're looking for right now.
Sent from my Lumia 920 using Board Express
SynergeTechSolutions said:
I have already gone down this road and can fairly confidently say it is a dead-end. The only interesting thing I found was the ability to switch a phone to use the internal Microsoft development authentication servers. Best of luck though - maybe I missed something.
Click to expand...
Click to collapse
bummer
Any details about what you found out?
Did you see if the internal (test, I assume) server mode used cert pinning? If not, we can spoof those servers and basically re-implement the original ChevronWP7 unlocker (in a more elegant form, too).
Not quite the Goal you want to move to but maybe what you have found out so far can be used to enable Dev Unlocking and XAP deployment to Dev Unlocked WP8 devices from Windows 7. I believe there are quite a lot of developers who would be happy to have that possibility.
I do know that when you activate dev unlock on WP8 devices, it does it using the Windows Phone IP over USB service ("C:\Program Files (x86)\Common Files\Microsoft Shared\Phone Tools\CoreCon\11.0\Bin\IpOverUsbSvc.exe"). The IpOverUSBSvc is more or less just a .NET wrapper (I figured this would be the case). If anyone is good at x86 assembly and can get into the IpOverUsbPc.dll, we may get somewhere.
snickler said:
I do know that when you activate dev unlock on WP8 devices, it does it using the Windows Phone IP over USB service ("C:\Program Files (x86)\Common Files\Microsoft Shared\Phone Tools\CoreCon\11.0\Bin\IpOverUsbSvc.exe"). The IpOverUSBSvc is more or less just a .NET wrapper (I figured this would be the case). If anyone is good at x86 assembly and can get into the IpOverUsbPc.dll, we may get somewhere.
Click to expand...
Click to collapse
several tools exists for decompiling DLLs to have a look at the source (which I assume will be .NET)
Reflector is one - commercial - solution, but in Adrian Banks blogs you will find alternatives that are free - and some commercial ones also.
http://www.adrianbanks.co.uk/?p=71
NielDK said:
several tools exists for decompiling DLLs to have a look at the source (which I assume will be .NET)
Reflector is one - commercial - solution, but in Adrian Banks blogs you will find alternatives that are free - and some commercial ones also.
http://www.adrianbanks.co.uk/?p=71
Click to expand...
Click to collapse
the DLL I mentioned is unfortunately a COM dll. I already ran ILSpy against the exe to find that out. We will need someone with x86 assembly experience
I posted this question several months ago in the 8X forum and have decided to put this out for discussion again.
ZaneKaminski said:
So, recently, an exploit has been developed for Windows RT devices that allows modifying the minimum signing level constant for the extent of the time that Windows is running. The exploit works on Windows RT devices to allow them to run unsigned native code, but interestingly enough, can also be used on regular x86 devices to change that same value. Since WP8 devices are built on the same NT kernel, it is likely that they enforce signature verification in much the same way, and we may be able to exploit this vulnerability on our devices.
For this to work, there are at least these prerequisites...
The WP8 remote debugger needs to let us mess with the CSRSS process.
There needs to actually be a CSRSS process, or something else we can exploit that makes a call to NtUserSetInformationThread.
If this exploit works on WP8, an easy way (as in, on the start screen or something) to load unsigned/native applications on the device and execute them would be nice.
I don't know much about any of those things. Would someone more knowledgeable care to shed some light on the subject?
Click to expand...
Click to collapse
Remote debugger is disabled in retail devices. So, the first exploit should edit BCD and registry entries
this is Cotulla reply:
there are two checkers.
user mode and kernel mode.
Kernel mode - driver SecMgr.sys and user mode - CI.dll.
I patched both of them already to disable signature checking on custom files.
I am talking about EXE/DLL/SYS.
Not sure who is checking XAP files in WP7.
I think these is important winload.exe,bootmgr,ci.dll,SecRuntime.dll
The Windows RT jailbreak won't work as-is on WP8, since WP8 uses a different version of win32k and csrss. It's possible the exploit is still there but it's not too likely we'll get the tools that leaked from MS like they did on RT to actually do it.
Hi... I'm from the Windows RT jailbreaking world and don't have a Windows Phone, so please excuse my ignorance.
I have an exploit in Microsoft's Secure Boot code that works on all architectures. I suspect that the same bug works on Windows Phone 8. However, it requires writing to privileged areas of the system. This is easy in desktop Windows and in Windows RT, but I have no idea of its feasibility on Windows Phone 8.
Doss anyone here have insight into this? =^_^=
My RT jailbreak proof (8.1, so not the existing one):
https://mobile.twitter.com/Myriachan/statuses/365350790803619840
Myriachan said:
Hi... I'm from the Windows RT jailbreaking world and don't have a Windows Phone, so please excuse my ignorance.
I have an exploit in Microsoft's Secure Boot code that works on all architectures. I suspect that the same bug works on Windows Phone 8. However, it requires writing to privileged areas of the system. This is easy in desktop Windows and in Windows RT, but I have no idea of its feasibility on Windows Phone 8.
Doss anyone here have insight into this? =^_^=
My RT jailbreak proof (8.1, so not the existing one):
https://mobile.twitter.com/Myriachan/statuses/365350790803619840
Click to expand...
Click to collapse
Unfortunately WP8 is locked down tight and no one can write to the OS partition as far as I know.
petard said:
Unfortunately WP8 is locked down tight and no one can write to the OS partition as far as I know.
Click to expand...
Click to collapse
So to pull it off, you'd need an NT kernel privilege escalation exploit that could be done from a low box token in the WP8 sandbox...yuck. Possible, though. Such an exploit would obviate my exploit, though, because then you could make a side loaded app that jailbreaks the phone when you run it.
As I understand, some registry values can currently be modified via this app. Can't help much more unfortunately.
some of the registry can be accessed, but not all. snickler, gooddaytodie and others are trying to find a way to write to registry. theres a thread on here that talks about the progress.
In particular, we have read-only access to most of the registry, but not much (if any) in the way of write access, beyond what a handful of built in and OEM apps can do (OEM apps can have extra permissions; some store settings in the registry and/or change system configurations, but I haven't yet found a way to get arbitrary access).
Great work on that RT exploit, though. It actually may be useful on the phone even if we do find an arbitrary app EoP exploit - it could make it a lot easier to do certain things - but the most likely EoP is actually us finding a way to abuse an OEM (or built-in) app to change the registry and/or file system. If we can find that, a way to then run arbitrary code with full permissions would be a really useful thing to use such a hack for...