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.
Related
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.
Hello,
I have been searching high and low for a way to force my shiny new HTC 8x to accept a 512-bit Self-Signed Certificate. Our work email server is Lotus/IBM Domino. We have an EAS server (Notes Traveler) set up for our portable devices. MIcrosoft is the only OS that forces 1024-bit or greater certs. As a result, I cannot connect ot our EAS server.
More info can be found at support.microsoft.com/kb/2661254?wa=wsignin1.0
Through all the research I have been doing, I think it is possible to do this, since you can make it work with WIndows 8 by doing one of two things:
1.Add following in the registry:
reg add "HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config" /v minRSAPubKeyBitLength /t REG_DWORD /d 0x00000200 /f
2. use the built-in certutil to modify the registry:
certutil -setreg chain\minRSAPubKeyBitLength 512
Any thoughts on how I can do this with Windows Phone 8? I am in the process of developer-unlocking my device. I just need to wait for the SDK to finish installing into my VM.
As far as I know, there's no way to edit the registry with developer unlock.
You need more elevated privileges (Interop Unlock) and, at this moment, there's no way to obtain that on Windows Phone 8.
I know this isn't the response you are looking for, but recommend to your company to update their SSL certificate to 1024 or 2048 bits. The reason your phone won't support the 512 bit certificate is simply because it is not secure, which Microsoft finally stopped allowing last year..
Since your company is using a self-signed certificate, it should only take them a few minutes to create and install a new one that modern operating systems would support.
klamation said:
I know this isn't the response you are looking for, but recommend to your company to update their SSL certificate to 1024 or 2048 bits. The reason your phone won't support the 512 bit certificate is simply because it is not secure, which Microsoft finally stopped allowing last year..
Since your company is using a self-signed certificate, it should only take them a few minutes to create and install a new one that modern operating systems would support.
Click to expand...
Click to collapse
My IT department was surprisingly open to this, once they realized all the Windows PCs couldn't log into the web interface anymore. It might take a couple of weeks/months of planning to put it into their maintenance cycle, though. Oh the joys of working for a large corporation!
Something else I discovered earlier:
In order to write Windows Phone apps, you need the Windows Phone 8 SDK. To Install the Windows Phone 8 SDK, you need Windows 8. When I have time to set up another DEV box with Windows 8 on it, I might revisit this.
Any thoughts on how the OEM apps always seem to get "enhanced" access? (The HTC Carrier Settings tool, for example). I haven't used Windows Phone since 6.0. Back then, we could do ANYTHING! lol
I didn't even notice the Win8 requirement for the SDK, since I was anxious to upgrade to Win8 once it came out. Hmm. But, I think you could use the older 7.x SDK on older versions of Windows, if you want to get used to dev for Windows Phone (as WP7 Apps should still work on WP8).
About why the OEM can do special things to the device, I think it's a simple matter of, they have the OS code, so they can modify it or access things we can't.
OEM Apps are given additional permissions. They request these using some entries in the App-manifest but even if we were able to set these the system would reject their deployment unless they had a proper certificate. It has been that way on WP7 as well.
As for developing on Win7 and deploying to a WP8 device: it won't work. You can run WP7 Apps on WP8 devices but the deployment tools of the WP7 SDK can't handle WP8 devices. So to deploy anything onto a WP8 device you need the WP8 SDK which in turn requires Windows 8 Pro.
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
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...