• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

Project: Let's 'jailbreak' NoDo

Search This thread

Jaxbot

Inactive Recognized Developer
Mar 14, 2009
1,224
548
windowsphonehacker.com
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:
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>
And the phone sends this byte sequence back the the registration tool:
Code:
16, 81, 7, 0, 1, 4, 0, 2, 0, 0, 0
If anything goes wrong, it sends back something like this:
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0

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:
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0
Build 7390 with certificate:
Code:
16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0

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
 

Jaxbot

Inactive Recognized Developer
Mar 14, 2009
1,224
548
windowsphonehacker.com
I've found a certificate in the Windows folder of my WP7. Maybe this is the one you need to use?

Sent from my T8788 using XDA Windows Phone 7 App

No, I believe that is for app signing or the like. The certificate has to match the private key on the webserver, so the only way around this would be access to Microsoft's private key, which is basically impossible to obtain (and illegal)
 

Jaxbot

Inactive Recognized Developer
Mar 14, 2009
1,224
548
windowsphonehacker.com
Nice work :) Few days ago, I thought about a quite similar project.
What about the "USB"-Way, no Webservers, no certificates just raw (manipulated) USB packages?

When my developer account becomes activated I could "sniff" some traffic between PC and Phone for you, if you want :)

Can you expound upon this? Are you talking about USB deploying or something else? From what I can tell, you can't deploy packages to the phone without it being dev unlocked. In fact, not even reading data from the device is possible to this extent. Or are you talking about something else?

Thanks ;)
 

kingjovius

Member
May 2, 2010
27
0
Hey

another possibility i can think of is trying to use the update-process to update the registry. Did someone look into this approach?

Ive no knowledge in this stuff but instead of the update process, how bout maybe the use of flashing? Like instead of flashing a whole new rom, maybe use that process to just put in an edited registry key or something, however it works
 

ChrisKringel

Senior Member
Jan 6, 2009
358
70
I've thought about this, but it would involve some complicated understanding of the update system. If anyone knows how to go about doing this, though, I'm all ears ;)

I don't own a WP7 myself so I can only hypothesize... When an update is available it is downloaded by Zune. Zune itself checks on a Web-Server whether an update is available. The emulation of this server would not be complicated... The question is the type of the updates and what they consist of... And they have somehow to be transmitted via Zune. Maybe we could reverse engineer the chevron updater?

€dit: I just took a look into the "Unwalsh"-Tool. It seems to download the selected updates as *.cab files:

Code:
    Mui item = new Mui {
        ID = 1,
        MUI = "0409",
        MuiName = "English (United States)",
        CabinetUrl = new List<string> { "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0409.pks_65fe09539f02edc8e1d44609fb537b87613063ea.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0409.pks_0cdfd833159cd10036e6025ec1db784dd712b2f4.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0409.pks_b4e3f25a79cfd5514895169ba167d9bd0cdb135d.cab" }
    };

These updates are cab files that consist of multiple pku files.
 
Last edited:

Jaxbot

Inactive Recognized Developer
Mar 14, 2009
1,224
548
windowsphonehacker.com
I don't own a WP7 myself so I can only hypothesize... When an update is available it is downloaded by Zune. Zune itself checks on a Web-Server whether an update is available. The emulation of this server would not be complicated... The question is the type of the updates and what they consist of... And they have somehow to be transmitted via Zune. Maybe we could reverse engineer the chevron updater?

€dit: I just took a look into the "Unwalsh"-Tool. It seems to download the selected updates as *.cab files:

Code:
    Mui item = new Mui {
        ID = 1,
        MUI = "0409",
        MuiName = "English (United States)",
        CabinetUrl = new List<string> { "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0409.pks_65fe09539f02edc8e1d44609fb537b87613063ea.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0409.pks_0cdfd833159cd10036e6025ec1db784dd712b2f4.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0409.pks_b4e3f25a79cfd5514895169ba167d9bd0cdb135d.cab" }
    };

These updates are cab files that consist of multiple pku files.

Actually, that's really interesting, because from what I can tell, that would install a package to the device rather than having to have a whole new OS ver. Which I already suspected, but it's a good confirmation.

What this means, then, is it might be possible to use the updating system to deploy a registry package to the device that changes the key. As for reverse engineering ChevronWP7.Updater, that's no sweat-it just uses the libraries Microsoft used with Windows Phone Support Tool.

I'll dig around ;) Also, the pku files can be opened in WinRAR.
 

ChrisKringel

Senior Member
Jan 6, 2009
358
70
That sounds like great news. It would be a huge advantage if we could get our hands on a package that updates the registry rather than a few language files...

Do you know what the *.dsm files are? From viewing them I would assume they are somehow certificate related... They also contain a link to a Certificate Revocation List
Code:
http://crl.microsoft.com/pki/crl/products/MicrosoftMobilePCA.crl

€dit:

I took a look into the Chevron updater an extracted the links used to download the NoDo-Update

Code:
public Updater()
{
    this.actionTimer = new Stopwatch();
    this.lastStep = -1;
    this.osUpdates = new List<string> { "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.pks_669700d5014b3a9c73fe81390281620ca29d0675.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.pks_35616816bdd0b9c08e39cdbab9fc9f7bfafec5ac.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.pks_7fea4585c1275be10e4c06adffb3c4e42372f7d2.cab" };
    this.languageUpdates = new List<string> { 
        "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0407.pks_4c77b51d9ae1114f3a0d5aeb47adc5e781fec04b.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0409.pks_65fe09539f02edc8e1d44609fb537b87613063ea.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_040c.pks_e0c4e50429486eeb100752c0c956cda8b98e02de.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0410.pks_4a27af7e5f1baf3243b6220419aa1cd1ebe43958.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0809.pks_b1006360c74695b323988cdee3aafd608d469693.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7008.0-7.0.7355.0-armv7-retail-microsoft.lang_0c0a.pks_7871a8595b50c7bb32443fad4df7f735d6b7c04f.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0407.pks_464df1a0972db2c7028d53d6465cdc5ec0192b84.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0409.pks_0cdfd833159cd10036e6025ec1db784dd712b2f4.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_040c.pks_f6cc1ff8991c0f113aff142af3f78cfd6a203529.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0410.pks_e041d85cc2c49c20aecce9428339f411d4e837e2.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0809.pks_83b3967ab7eacd863245811ae0b762f242f4dbd7.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/01/diff-7.0.7355.0-7.0.7389.0-armv7-retail-microsoft.lang_0c0a.pks_02ec89c1f4b7495915204f0751873121f68b009e.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0407.pks_cabe462db180b214e380969a82252923c8fbbb2e.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0409.pks_b4e3f25a79cfd5514895169ba167d9bd0cdb135d.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_040c.pks_96edbca5e0b6285ccd8d841bb12531d38b57fd46.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0410.pks_488bc339318e5530b2c67d022d79c0212674b6a8.cab", 
        "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0809.pks_6dc73e33c46694ee7316fa60740fb1b64d80e37c.cab", "http://download.windowsupdate.com/msdownload/update/software/dflt/2011/03/diff-7.0.7389.0-7.0.7390.0-armv7-retail-microsoft.lang_0c0a.pks_1a3cd8ee2df1f3988c1347badcd3bedeb373014b.cab"
     };
    this.Languages = new List<Language>();
    this.Progress = new List<string>();
    Language item = new Language {
        ID = 1,
        MUI = "0409",
        Name = "English (United States)"
    };
    this.Languages.Add(item);
    Language language2 = new Language {
        ID = 2,
        MUI = "0809",
        Name = "English (United Kingdom)"
    };
    this.Languages.Add(language2);
    Language language3 = new Language {
        ID = 3,
        MUI = "040c",
        Name = "French"
    };
    this.Languages.Add(language3);
    Language language4 = new Language {
        ID = 4,
        MUI = "0410",
        Name = "Italian"
    };
    this.Languages.Add(language4);
    Language language5 = new Language {
        ID = 5,
        MUI = "0c0a",
        Name = "Spanish"
    };
    this.Languages.Add(language5);
    Language language6 = new Language {
        ID = 6,
        MUI = "0407",
        Name = "German"
    };
    this.Languages.Add(language6);
}

Some of the contain interesting files... For instance executables and dlls, and RGU files. From what i've read these RGU files are registry updates. However i wasnt able to open them. But i think its a start.
 
Last edited:
  • Like
Reactions: colossus_r

noelito

Senior Member
Mar 26, 2009
559
26
My phone is post nodo unlocked

Is it because non HTC phones are having problems unlocking? A hacker in the forums taught me how unlock my nodo phone
 

ChrisKringel

Senior Member
Jan 6, 2009
358
70
I've extracted some of the RGU files. I opened some with a RGU Editor found in the Forum (http://forum.xda-developers.com/showthread.php?t=587584) and they seem indeed to be registry related files. I've attached some of them, so that you can investigate further.

As you can see the file 37DDC81B-6703-4bde-AB36-B96080CE0F35.rgu is a plain text. Should not be too complicated to make it fit our needs :-D

Edit: I found also a DSM editor here in the forum. So i tried to alter one DSM to contain a self-created RGU file (attachment "test update content"). Now we have to repack them somehow as PKU-file...
 
Last edited:
  • Like
Reactions: colossus_r

amahfouz

Member
Feb 21, 2009
40
0
At last someone has gotten to this, the community seriously needs this thread and to get NoDo hacked, ever since Walsh wad convinced by MS users wishing to unlock their devices were just abandoned.
I'm not very technical but I'll help anyway I can.
Samsung Focus build 7392
 

colossus_r

Senior Member
Feb 10, 2007
2,098
394
Huawei P40 Pro
I've extracted some of the RGU files. I opened some with a RGU Editor found in the Forum (http://forum.xda-developers.com/showthread.php?t=587584) and they seem indeed to be registry related files. I've attached some of them, so that you can investigate further.

As you can see the file 37DDC81B-6703-4bde-AB36-B96080CE0F35.rgu is a plain text. Should not be too complicated to make it fit our needs :-D

Edit: I found also a DSM editor here in the forum. So i tried to alter one DSM to contain a self-created RGU file (attachment "test update content"). Now we have to repack them somehow as PKU-file...

Wowwwoowow ...This is going fast ... i am impressed ...
Way to go m8...way to go....

hmmmmmmmmmmmmmmm is there any way to downgrade your WP7 device to pre-nodo version?

Dont post those question here m8....Its serious devs discussion...

Yes..there is a way ...Go here and read and post your questions
 
Last edited:

sunhi3man

Member
Mar 31, 2007
30
0
Updating device...

Greetings,

I have read about updatewp.exe in the Samsung Focus forums which is loaded into the Zune directory if you download and install the Windows Phone Support Tool. I experimented a little by opening a command window and running the exe. It seems to have a lot of interesting features built in. It seems you could use this software to update a pks file by using the right string. If we could properly package a pks file with a edited rgu file than we could probably push it directly to the device with this software.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 18
    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:
    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>
    And the phone sends this byte sequence back the the registration tool:
    Code:
    16, 81, 7, 0, 1, 4, 0, 2, 0, 0, 0
    If anything goes wrong, it sends back something like this:
    Code:
    16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0

    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:
    Code:
    16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0
    Build 7390 with certificate:
    Code:
    16, 82, 7, 0, 1, 4, 0, 100, 0, 0, 0

    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
    5
    Today I made some real progress. I got around an important part of this SSL crap ;) Microsoft left a nice security hole there for me. We're not there yet, but a very difficult step was made.

    Sent from my OMNIA7 using XDA Windows Phone 7 App
    3
    Very good. I've meant to work on that, but the WP7 Root Tools is taking me way much more time than I planned to. So if you need any help, just ask. But I need to give the WP7 Root Tools development time too, so I'm a bit limited on time. If you need to sniff your WiFi packets, let me know. I can give you details on that.

    Yeah, I've had to put a lot aside to give jailbreaking a go. Good work on your root tool development, by the way. As for WiFi sniffing, I normally just hook it up to my computer and disable all data on the phone, since Wireshark doesn't seem to work on my network across different computers. Socketsniff works decently for now, but if you have suggestions, I'm welcome to them ;)
    Thanks
    3
    Or do you think that ChevronWP7 just got the certificates for the registration-servers and reach out licenses as they like? Doubt it ;)

    We'll be connected to developer services to officially unlock phones.
    3
    Today I made some real progress. I got around an important part of this SSL crap ;) Microsoft left a nice security hole there for me. We're not there yet, but a very difficult step was made.

    Sent from my OMNIA7 using XDA Windows Phone 7 App

    Amen to that ;)