Windows Phone 7 - ROM Deployment and how it will affect us

Search This thread

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,332
1,563
Riverside, CA
Samsung Galaxy S22 Ultra
Windows Phone 7 has standardized the bootloader requirements for OEMs. No longer will an OEM be allowed to implement it's own design for ROM deployment (such as HTC with the .nbh/RUU system, .dz/LGMDP with LG, etc.)

The image format will be B000FF/.bin, which receives only minor changes from CE5, and so our current tools should work fine with this. The major change is in the way the bootloader handles image deployment. For Samsung and a handful of other manufacturers, this won't change too much, as they already utilize the B000FF system for deployment. The filesystem inside will be IMGFS - no longer will BinFS be used for NK/XIP section (now IMGFS will all partitions on device, NK and OS just being split by package rather than a seperate FS)

The physical flash layout will look as follows:

  • Reserved Regions, updateable only through a special oem-written driver to allow access to this area (size varies)
  • Partition Table (1KB)
  • BLDR (1MB)
  • DBSP (Device Boot State Partition, 256KB)
  • DPP (Device Provisioning Partition, 256KB)
  • USP (Update State Partition, 2MB)
  • ULDR1 (>=6MB)
  • ULDR2 (>=6MB)
  • NK (IMGFS, >=4.5MB) - At least 1MB free space for updates
  • OS (IMGFS, >=181MB) - At least 20% free space for updates
  • User Store (TexFAT)

Only the User Store (Which uses new Transaction-Safe ExFAT filesystem) will be user-writeable, all other areas will only be writable during an update operation. The Partition Table, DBSP, DPP, USP, and User Store are all not updateable during an update operation, only during a full-flash scenario. B00FF images are signed and checksummed, and passed through to the bootloader via ethernet over usb. The connection will most likely be encrypted, using the same flashing utility as Zune HD. (This is currently used to deploy images to the DevKits)

.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.

Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed.

As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD.

Similar to CE5/WinMo 6.x, There is a BLDR (Base Boot Loader) which makes the initial determination to boot up to the ULDR or to the WP7 OS. The OEM implements alternate boot parameters to trigger this and/or a button press combination. If ULDR is triggered, it checks the battery and power source to ensure that there is enough life remaining to successfully complete the flash, then awaits the flash download. There are redundant ULDR partitions (ULDR1/ULDR2) to facilitate failsafe recovery in the event of a failed ULDR flash (ULDR provides a basic level of functionality to enable a recovery flash even in the event of power failure during a flash)

MSFT is pushing it's Phone Update service much harder this time - it is intended to be used as the primary method for distributing phone updates. These can be deployed both over-the-air and through a USB connection with the Zune software.
 
Last edited by a moderator:

RustyGrom

Senior Member
Apr 18, 2006
1,006
83
Orlando
Thanks. I didn't see these threads before. Any chance you could share or point to the docs this info came from? It seems tweakers.net acquired it and I wouldn't mind looking through.
 

leo70

Member
Jan 16, 2011
45
23
...

.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.

Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed. As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD...

Hi Da_G,

How can I get my hands on these files: not wp7 os but the other partition (dpp/bldr/uldr/imgfs/etc) contents? What IS known about wp7-fs? spl?
Do you have ANY dumps - even ZuneHD equiv? maybe the source of your .ffu info and an actual .ffu? Thanks there- pm me if you get the time. Yeah... I am noob here but interested in moving into rom-dev; used to do xbox-1+live and do have jtag, logic analyzers+trace, etc here. How would I begin? Once again: thanks and well done!

Edit/Update:

Perhaps with Cotulla's partition layout over 4 seperate nand areas it would be an option to modify this and his wp7 spl because the activation thing happened AFTER (live activation hack around etc) he had finished leo70 release and then..........

-whilst jtag/usb or eth/debug happening- (obviously you'd though of this b4- im just theorizing- let me know if way off)- to take a HTC HD2 (LEO70) that HAS BEEN ACTIVATED ON LIVE and see where/how/when/with/which partitions, filesys, regkeys, etc, have pvk for live or the ffu and then insert a test cert like ur own xbmod/chevron. or whatever is in sdk for 7 or ce. and then utilize this to diff and comp. I dont see why not. Then .ffu then self signature.
 
Last edited:
  • Like
Reactions: raven_raven

-WP7User-

Senior Member
Aug 31, 2010
315
33
Zurich
Now THAT'S cool! Thanks, Da_G!
This would mean, that we basically could get custom Rom's on WP7. Can't wait to see the first ones :D
 

arimozuki

Senior Member
Oct 24, 2009
53
0
eh?

Did you look at the post dates before you all started subscribing? Almost a year now, doubt you'd see anything new ... but this and more 'subscribed' and a possible 'sod off' post.
 

surrender420

Member
Jul 12, 2010
31
1
Is this the only discussion on the topic? I'm sure im not the only one looking forward to having an unlocked bootloader. Any updates?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Windows Phone 7 has standardized the bootloader requirements for OEMs. No longer will an OEM be allowed to implement it's own design for ROM deployment (such as HTC with the .nbh/RUU system, .dz/LGMDP with LG, etc.)

    The image format will be B000FF/.bin, which receives only minor changes from CE5, and so our current tools should work fine with this. The major change is in the way the bootloader handles image deployment. For Samsung and a handful of other manufacturers, this won't change too much, as they already utilize the B000FF system for deployment. The filesystem inside will be IMGFS - no longer will BinFS be used for NK/XIP section (now IMGFS will all partitions on device, NK and OS just being split by package rather than a seperate FS)

    The physical flash layout will look as follows:

    • Reserved Regions, updateable only through a special oem-written driver to allow access to this area (size varies)
    • Partition Table (1KB)
    • BLDR (1MB)
    • DBSP (Device Boot State Partition, 256KB)
    • DPP (Device Provisioning Partition, 256KB)
    • USP (Update State Partition, 2MB)
    • ULDR1 (>=6MB)
    • ULDR2 (>=6MB)
    • NK (IMGFS, >=4.5MB) - At least 1MB free space for updates
    • OS (IMGFS, >=181MB) - At least 20% free space for updates
    • User Store (TexFAT)

    Only the User Store (Which uses new Transaction-Safe ExFAT filesystem) will be user-writeable, all other areas will only be writable during an update operation. The Partition Table, DBSP, DPP, USP, and User Store are all not updateable during an update operation, only during a full-flash scenario. B00FF images are signed and checksummed, and passed through to the bootloader via ethernet over usb. The connection will most likely be encrypted, using the same flashing utility as Zune HD. (This is currently used to deploy images to the DevKits)

    .ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.

    Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed.

    As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD.

    Similar to CE5/WinMo 6.x, There is a BLDR (Base Boot Loader) which makes the initial determination to boot up to the ULDR or to the WP7 OS. The OEM implements alternate boot parameters to trigger this and/or a button press combination. If ULDR is triggered, it checks the battery and power source to ensure that there is enough life remaining to successfully complete the flash, then awaits the flash download. There are redundant ULDR partitions (ULDR1/ULDR2) to facilitate failsafe recovery in the event of a failed ULDR flash (ULDR provides a basic level of functionality to enable a recovery flash even in the event of power failure during a flash)

    MSFT is pushing it's Phone Update service much harder this time - it is intended to be used as the primary method for distributing phone updates. These can be deployed both over-the-air and through a USB connection with the Zune software.
    1
    ...

    .ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.

    Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed. As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD...

    Hi Da_G,

    How can I get my hands on these files: not wp7 os but the other partition (dpp/bldr/uldr/imgfs/etc) contents? What IS known about wp7-fs? spl?
    Do you have ANY dumps - even ZuneHD equiv? maybe the source of your .ffu info and an actual .ffu? Thanks there- pm me if you get the time. Yeah... I am noob here but interested in moving into rom-dev; used to do xbox-1+live and do have jtag, logic analyzers+trace, etc here. How would I begin? Once again: thanks and well done!

    Edit/Update:

    Perhaps with Cotulla's partition layout over 4 seperate nand areas it would be an option to modify this and his wp7 spl because the activation thing happened AFTER (live activation hack around etc) he had finished leo70 release and then..........

    -whilst jtag/usb or eth/debug happening- (obviously you'd though of this b4- im just theorizing- let me know if way off)- to take a HTC HD2 (LEO70) that HAS BEEN ACTIVATED ON LIVE and see where/how/when/with/which partitions, filesys, regkeys, etc, have pvk for live or the ffu and then insert a test cert like ur own xbmod/chevron. or whatever is in sdk for 7 or ce. and then utilize this to diff and comp. I dont see why not. Then .ffu then self signature.