Introduction
This post is to help pool together ideas on how to finally get unofficially developer unlocking (I'm just gonna call it 'jailbreaking' for now, even though thats politically-incorrect) on NoDo and later builds of Windows Phone 7.
The main motivation here is, of course, homebrew. It seems a little ridiculous to me to pay $99 for a Marketplace account that I would never publish to, and aside from that, I find it very hard to share any homebrew applications I make when only a small subset of users can sideload them, and they would of course never be approved to the Marketplace.
So, here's the sitch
I've been working on and off for a few weeks on how to get this working, and since I simply do not have the time or resources to crack it myself, I'm sharing what I've found in hopes that some of the much brighter minds here on XDA can finally crack this thing open.
First off, let's start with the basics. To developer unlock WP7, the internal change is really quite simple: change the DeveloperUnlocked key from 0 to 1. This, of course, requires registry access, which we don't have (LG aside) without sideloading, which is a bit of a paradox.
Fortunately, we have the official Phone Registration tool to look at, and the code is, thankfully, not obfuscated. Let's lay out how it works:
-Tool logs into the Live account
-Tool gets some sort of auth token from the live login
-Tool connects to the phone on port 27077 and sends a special packet, containing a cookie for the phone to use in its internal authorization
-Phone connects to developerservices.windowsphone.com, and sends this cookie (auth token) over to the server over HTTPS to get the response.
On success, the server returns something like this:
And the phone sends this byte sequence back the the registration tool:
If anything goes wrong, it sends back something like this:
Pretty simple, actually.
Taking a lesson from past examples
Two important pieces of information: How did ChevronWP7 work, and more importantly, how was it blocked?
The program was actually quite simple. To lay it out:
-ChevronWP7 starts an HTTPS webserver
-Chevron changes the hosts file in Windows to reroute all developerservices.windowsphone.com traffic to itself (localhost)
Since this is an HTTPS connection, a valid certificate must be used, or else the connection will fail. To get around this, the Chevron team made that ChevronWP7.cer file, which, essentially, created a developerservices.windowsphone.com certificate to match a fake one on the server. Since this wouldn't be issued by an authority, the user had to manually install it.
-With the certificate manually installed, Chevron sends the unlock packet to the phone, the phone tries to connect the to webserver, Windows connects it to localhost instead of the real server, and Chevron sends back a success packet.
Voila.
How it was blocked
Despite what people seem to think, Microsoft didn't exactly block ChevronWP7 specifically. Rather, they fixed the security hole it exploited.
To test things out, I wrote my own unlocking system using some C# and an SSL Apache server. Sure enough, after installing a fake certificate I made, it worked on my 7004 build. On my 7390 build, however, it instantly returned the same error code as if no certificate was installed:
Build 7008 with no certificate:
Build 7390 with certificate:
What does this mean? I'm no expert here, but here's what I think: Microsoft patched the hole by preventing the unlocking system from using custom-installed certificates to connect to SSL. My reasoning here is that I can connect to the server through Internet Explorer with a secure connection after installing the certificate on the phone, but the unlocking system acts as if no such certificate exists. Guess it only uses trusted certificates, now.
What I've tried
I've tried a couple different things to get around this plateau, actually. Aside from constructing my own debug unlocker for my 7004 device, I also tried mirroring the Marketplace XAPs, which didn't work due to the DRM. I've also knocked on any loose bits I can find, but no use-it just won't budge.
tl;dr
Here's the deal. I've tried what I can think of, and now I hope some more bright minds can finally crack this thing open. Again, my goal here is the homebrew, and while I know this has been promised before, I cannot simply wait in uncertainty until it is finally implemented.
What steps we take from here, I'm not too sure. If we want to take the web-spoofing route, we'll need a way to install trusted certificates, which is probably not the easiest thing to do. But if there are any other gaping holes in the OS, now is the time to find them
As a general favor, I would like it if we could keep this thread low on off-topic posts; I know many of you want this, but expressing those thoughts will only slow things down
Thanks, and good luck to us all
~Jaxbot
This post is to help pool together ideas on how to finally get unofficially developer unlocking (I'm just gonna call it 'jailbreaking' for now, even though thats politically-incorrect) on NoDo and later builds of Windows Phone 7.
The main motivation here is, of course, homebrew. It seems a little ridiculous to me to pay $99 for a Marketplace account that I would never publish to, and aside from that, I find it very hard to share any homebrew applications I make when only a small subset of users can sideload them, and they would of course never be approved to the Marketplace.
So, here's the sitch
I've been working on and off for a few weeks on how to get this working, and since I simply do not have the time or resources to crack it myself, I'm sharing what I've found in hopes that some of the much brighter minds here on XDA can finally crack this thing open.
First off, let's start with the basics. To developer unlock WP7, the internal change is really quite simple: change the DeveloperUnlocked key from 0 to 1. This, of course, requires registry access, which we don't have (LG aside) without sideloading, which is a bit of a paradox.
Fortunately, we have the official Phone Registration tool to look at, and the code is, thankfully, not obfuscated. Let's lay out how it works:
-Tool logs into the Live account
-Tool gets some sort of auth token from the live login
-Tool connects to the phone on port 27077 and sends a special packet, containing a cookie for the phone to use in its internal authorization
-Phone connects to developerservices.windowsphone.com, and sends this cookie (auth token) over to the server over HTTPS to get the response.
On success, the server returns something like this:
Code:
<ResponseOfRegisteredDeviceStatus xmlns="Microsoft.WindowsMobile.Service.Marketplace"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ResponseCode>0x00000000</ResponseCode>
<ResponseMessage i:nil="true" />
<Entity xmlns:a="http://schemas.datacontract.org/2004/07/Microsoft.WindowsMobile.Service.Marketplace.BLLDevPortal.Entities">
<a:DaysLeft>365</a:DaysLeft>
<a:AppsAllowed>10</a:AppsAllowed>
</Entity>
</ResponseOfRegisteredDeviceStatus>
Code:
16, 81, 7, 0, 1, 4, 0, 2, 0, 0, 0
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0Pretty simple, actually.
Taking a lesson from past examples
Two important pieces of information: How did ChevronWP7 work, and more importantly, how was it blocked?
The program was actually quite simple. To lay it out:
-ChevronWP7 starts an HTTPS webserver
-Chevron changes the hosts file in Windows to reroute all developerservices.windowsphone.com traffic to itself (localhost)
Since this is an HTTPS connection, a valid certificate must be used, or else the connection will fail. To get around this, the Chevron team made that ChevronWP7.cer file, which, essentially, created a developerservices.windowsphone.com certificate to match a fake one on the server. Since this wouldn't be issued by an authority, the user had to manually install it.
-With the certificate manually installed, Chevron sends the unlock packet to the phone, the phone tries to connect the to webserver, Windows connects it to localhost instead of the real server, and Chevron sends back a success packet.
Voila.
How it was blocked
Despite what people seem to think, Microsoft didn't exactly block ChevronWP7 specifically. Rather, they fixed the security hole it exploited.
To test things out, I wrote my own unlocking system using some C# and an SSL Apache server. Sure enough, after installing a fake certificate I made, it worked on my 7004 build. On my 7390 build, however, it instantly returned the same error code as if no certificate was installed:
Build 7008 with no certificate:
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0What does this mean? I'm no expert here, but here's what I think: Microsoft patched the hole by preventing the unlocking system from using custom-installed certificates to connect to SSL. My reasoning here is that I can connect to the server through Internet Explorer with a secure connection after installing the certificate on the phone, but the unlocking system acts as if no such certificate exists. Guess it only uses trusted certificates, now.
What I've tried
I've tried a couple different things to get around this plateau, actually. Aside from constructing my own debug unlocker for my 7004 device, I also tried mirroring the Marketplace XAPs, which didn't work due to the DRM. I've also knocked on any loose bits I can find, but no use-it just won't budge.
tl;dr
Here's the deal. I've tried what I can think of, and now I hope some more bright minds can finally crack this thing open. Again, my goal here is the homebrew, and while I know this has been promised before, I cannot simply wait in uncertainty until it is finally implemented.
What steps we take from here, I'm not too sure. If we want to take the web-spoofing route, we'll need a way to install trusted certificates, which is probably not the easiest thing to do. But if there are any other gaping holes in the OS, now is the time to find them
As a general favor, I would like it if we could keep this thread low on off-topic posts; I know many of you want this, but expressing those thoughts will only slow things down
Thanks, and good luck to us all
~Jaxbot
