The Windows Mobile Image Update System - Updating your ROM without losing data!

Search This thread
By:
Advanced…
C

cmonex

Retired Recognized Developer
Jul 23, 2006
3,040
49
Budapest
stepw said:
Hi Da_G,
When a package is installed, are replaced modules completely pruned or ULDR only updates XIP chains and requires extra flash space to store new modules?

It's logical to assume new modules may be larger than existing and replacing them in-place is not likely to be possible. Rebuilding partitions where updated modules reside in-memory is probably pretty intensive and not very fault tolerant, so I doubt it happens too...

This said, are there issues like fragmentation and/or available space limitation when using ImageUpdate in the long run? Any idea how many updates will a ROM survive before it runs out of space in XIP partitions due to fragmentation or increased modules sizes?
Click to expand...
Click to collapse



I'd like to know these answers myself too! so I think uldr should only be used for things like a rom has some small bugs left in it and you don't want people to hard reset just to install a permanent fix to those...
btw I dont think uldr handles XIP, it's just IMGFS updater, no? maybe I'm wrong and it can update XIP itself too (though these WM5+ XIPs dont have chains)
 
inertiax3

inertiax3

Senior Member
Apr 14, 2008
812
7
cmonex said:
I'd like to know these answers myself too! so I think uldr should only be used for things like a rom has some small bugs left in it and you don't want people to hard reset just to install a permanent fix to those...
btw I dont think uldr handles XIP, it's just IMGFS updater, no? maybe I'm wrong and it can update XIP itself too (though these WM5+ XIPs dont have chains)
Click to expand...
Click to collapse

Da_G has managed to update the MSXIPKernel part of the XIP so I guess it also handles the XIP..
 
mbarvian

mbarvian

Senior Member
Mar 13, 2008
1,784
3
since .cabs are based on _setup.xml, could we also remove files using these .cab.pkgs?
 
Da_G

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,332
1,563
Riverside, CA
Samsung Galaxy S22 Ultra
IIRC, ULDR has support for 3 types of partition

RAMIMAGE (NK partition, XIP)
ROMIMAGE (used in CE)
IMGFS (OS partition)

Can update all 3 :)

When ULDR writes RAMIMAGE, it copies entire image off the flash to memory, relocs etc, and then writes new image back to flash

So fragmentation, etc. isn't an issue - just free space :)
 
stepw

stepw

Senior Member
Feb 11, 2007
589
16
Neat-o! So it's important to maintain power while ULDR erases/overwrites XIP with an image from RAM.
 
stepw

stepw

Senior Member
Feb 11, 2007
589
16
cmonex said:
of course if you were to implement this, the OS could be stored decompressed in ram (well, it can be compressed imgfs too, if you want, but decompressed image is even faster but eats more ram of course). and to make boot times better, have an internal backup battery thingie, that can keep the ram powered when you soft reset, or change batteries, or this OS would always have to get reloaded and that'd make boot very slow. it could of course still have persistent storage, that is not related to how the *read-only* OS image itself is stored.
Click to expand...
Click to collapse

More RAM, less battery lifetime. A non-rechargeable backup battery will not survive long if it has to provide power to RAM while main battery is offline.
 
P

pidsw

Senior Member
Jan 3, 2008
143
1
Victoria
I've seen a few NOR/NAND Hybrid devices in the works, the should be more common in high end devices next year.

Regarding storage, this may be a niave question, but the memory allocated to potential image updates is declared in a texture file for the memory layout of a device BSP. Is this fixed in hardware, or just a decision based on the OS? If it is fixed in hardware, it will really hurt existing devices on WM7 as many things have been moved around to improve performance.

Aside: MS recommends that OEMS put all frequently used DLL's into modules as they use virutal memory RAM more efficiently than Files and that are faster to load and slightly faster to execute. Part of the execution benefit based on the assumption that the "rebuilding" that imageupdate and cooking does helps to minimize TLS swapping and other virtual memory overhead which can be quite a perf loss on many devices which require software interrupts to update their TLS (VM->Physical map)

We often get swapping of system dlls when we have the potential for ~120 megs of accesseble memory (much of it read only however) if the "big hammer" sections are filed. This should not happen, and hurts responsivness which is arguably one of the most measures of performance on a phone.

I noticed that custom roms have far fewer modules, than the latest HTC WM6.5 drops - is there a reason for this that I do not know about?
 
A

anoopnayak

New member
Jul 6, 2009
1
0
Need some inputs on Language packages

Hi,
I am not sure I am asking the query in right place but my quesry is related to Image update so thought to get some inputs from you. I have set of language packages for a perticular language and when I pass the input file to the Update application it installs all the language packages and restarts but after that I get a UI saying all tha packages are installed properly. Even after installing the language packs the device bootsup in the base language (0409). What might be the reason for the same? It would be great if I can get some inputs on the same as.

thanks
Anks
 
C

chavonbravo

Senior Member
Jul 15, 2006
408
3
anoopnayak said:
Hi,
I am not sure I am asking the query in right place but my quesry is related to Image update so thought to get some inputs from you. I have set of language packages for a perticular language and when I pass the input file to the Update application it installs all the language packages and restarts but after that I get a UI saying all tha packages are installed properly. Even after installing the language packs the device bootsup in the base language (0409). What might be the reason for the same? It would be great if I can get some inputs on the same as.

thanks
Anks
Click to expand...
Click to collapse

Try changing values of these keys:
[HKEY_LOCAL_MACHINE\MUI]
"SysLang"=dword:00000409
[HKEY_CURRENT_USER\MUI]
"CurLang"=dword:00000409
 
xda2_haseeb

xda2_haseeb

Senior Member
Aug 10, 2007
2,454
160
Lahore
ND4SPD said:
open cmd window:

type: copy /b DefaultCerts.dat+"cert file name".cer DefaultCerts.dat

If you get an error, it's probably because DefaultCerts.dat need read-only protection taken off.
Click to expand...
Click to collapse
Can i have a step by step guide of what should i do to get Image Update System working?? Can i also know how-to make a certificate, and i guess adding procedure is given in the post above, am i right?? I also want to know how-to create *.cab.pkg files?? THNX!!
 
ND4SPD

ND4SPD

Senior Member
Jan 15, 2007
691
0
31
Chicago, IL
nd4spd.tumblr.com
xda2_haseeb said:
Can i have a step by step guide of what should i do to get Image Update System working?? Can i also know how-to make a certificate, and i guess adding procedure is given in the post above, am i right?? I also want to know how-to create *.cab.pkg files?? THNX!!
Click to expand...
Click to collapse

I really wish I could help with that, but I can't even get a proper Image Update ROM flashed onto my phone without any errors. However, once you have a ROM that can handle Image Update, here's what you need to do:

  1. Re-build all the dsms properly - apparently you don't need it to check against the certs in the dsms, so that's fine. You can use Ervius's DSM Editor to do so.
  2. Update the DefaultCerts.dat to have the cert that you are going to sign all of the .cab.pkg files with. This will be a .cer file.
  3. Using cabarc, build all of the .cab.pkg (you can specifiy the output file to end with .cab.pkg instead of just .cab)
  4. Sign all of the .cab.pkg files with the .spc and the .pvk files that go along with the .cer file.
  5. Figure out all of the dependencies of a specific package and then cabarc all of the required .cab.pkg files into a .cab.pks file - you don't need to sign this .cab.pks. If you don't have the time or don't want to bother figuring out the dependencies - you should probably just put all of the .cab.pkgs you generated into one big .cab.pks file. If there aren't any dependencies, you can just copy the specific .cab.pkg file onto the device and then run it. It's the same for the .cab.pks file - once you have it, copy it to the device and then run it from there. The Update program should automatically attempt to install at that point.
  6. If you create a Release folder in the root of your device, you'll also be able to get a UpdateValidator.log file that will tell you exactly where you got an error if something did go wrong.
 
xda2_haseeb

xda2_haseeb

Senior Member
Aug 10, 2007
2,454
160
Lahore
ND4SPD said:
I really wish I could help with that, but I can't even get a proper Image Update ROM flashed onto my phone without any errors. However, once you have a ROM that can handle Image Update, here's what you need to do:

  1. Re-build all the dsms properly - apparently you don't need it to check against the certs in the dsms, so that's fine. You can use Ervius's DSM Editor to do so.
  2. Update the DefaultCerts.dat to have the cert that you are going to sign all of the .cab.pkg files with. This will be a .cer file.
  3. Using cabarc, build all of the .cab.pkg (you can specifiy the output file to end with .cab.pkg instead of just .cab)
  4. Sign all of the .cab.pkg files with the .spc and the .pvk files that go along with the .cer file.
  5. Figure out all of the dependencies of a specific package and then cabarc all of the required .cab.pkg files into a .cab.pks file - you don't need to sign this .cab.pks. If you don't have the time or don't want to bother figuring out the dependencies - you should probably just put all of the .cab.pkgs you generated into one big .cab.pks file. If there aren't any dependencies, you can just copy the specific .cab.pkg file onto the device and then run it. It's the same for the .cab.pks file - once you have it, copy it to the device and then run it from there. The Update program should automatically attempt to install at that point.
  6. If you create a Release folder in the root of your device, you'll also be able to get a UpdateValidator.log file that will tell you exactly where you got an error if something did go wrong.
Click to expand...
Click to collapse
Thnx!! its really informative but seems to be too much difficult :p so ill try sticking to normal ROMs for now :D
 
C

chavonbravo

Senior Member
Jul 15, 2006
408
3
I'm wondering how all this would work for updating a device w/out hardspl and an with the original rom.

1) Is it possible to edit existing .dsm's inside the rom, like Transciber package for exampe?
2) If so, could one edit it to be empty (in other words, remove Transcriber), and still have the .dsm properly signed?
3) Is it possible to extract certificate that is used in rom and use it on new .dsm? I doubt this is possible.
4) So if that can't be done, can DefaultCerts.dat be overwritten in ROM to include your own certificate? Or maybe there's some sort of protection to prevent this.

Reason I ask is for a TG01, which doesn't have any known update or flash program yet, so maybe image update is the only viable option for now.
 
ND4SPD

ND4SPD

Senior Member
Jan 15, 2007
691
0
31
Chicago, IL
nd4spd.tumblr.com
chavonbravo said:
I'm wondering how all this would work for updating a device w/out hardspl and an with the original rom.

1) Is it possible to edit existing .dsm's inside the rom, like Transciber package for exampe?
2) If so, could one edit it to be empty (in other words, remove Transcriber), and still have the .dsm properly signed?
3) Is it possible to extract certificate that is used in rom and use it on new .dsm? I doubt this is possible.
4) So if that can't be done, can DefaultCerts.dat be overwritten in ROM to include your own certificate? Or maybe there's some sort of protection to prevent this.

Reason I ask is for a TG01, which doesn't have any known update or flash program yet, so maybe image update is the only viable option for now.
Click to expand...
Click to collapse

As far as I know, it's not possible to edit the stuff in the ROM. According to Da_G the TFAT partition (the user partition) which contains the windows folder, "shadows" the IMGFS partition. In other words, even if you changed something in the windows folder, it wouldn't change the actual ROM since that is located in the IMGFS partition, not the TFAT partition.

Image Update is in fact designed to run without HardSPL or any such thing. Because it doesn't go check against the SPL or the IPL to make sure it's from an authentic source, it checks the certificates in the individual Image Update packages against the DefaultCerts.dat. In your case, the ROM will be signed with Microsoft's Firmware Certificates and Toshiba's own certificates. Unless you can get access to Toshiba's own .pvk files for the certificate they files are signed with, this will not be a viable option for you.

There is however, another thing you should explore, but only if you are experienced. Itsme's tools can live read/write to the IMGFS partition. This way, you can update the ROM to contain the proper certs/dsms that will allow you use Image Update to update the system. This is very risky, and you can easily brick your phone with the slightest mistake

I'll need to check once more, but I don't think that WM6.5 supports Image Update packages that deletes the software. You can use an update provxml in that specific package that will delete those files from the ROM.

Good luck!
 
Last edited:
C

chavonbravo

Senior Member
Jul 15, 2006
408
3
ND4SPD said:
There is however, another thing you should explore, but only if you are experienced. Itsme's tools can live read/write to the IMGFS partition. This way, you can update the ROM to contain the proper certs/dsms that will allow you use Image Update to update the system. This is very risky, and you can easily brick your phone with the slightest mistake
Click to expand...
Click to collapse

You speak of pdocwrite, right? If so, I imagine the old and new defaultcert.dat files should be same size, and I'd have to find the offsets where the old is with pdocread, and then write a same file size in that offset with pdocwrite?
 
ND4SPD

ND4SPD

Senior Member
Jan 15, 2007
691
0
31
Chicago, IL
nd4spd.tumblr.com
chavonbravo said:
You speak of pdocwrite, right? If so, I imagine the old and new defaultcert.dat files should be same size, and I'd have to find the offsets where the old is with pdocread, and then write a same file size in that offset with pdocwrite?
Click to expand...
Click to collapse

Yeah, i'm talking about the pdocwrite/pdocread tools. I think what you said would work. The way I'm going to try it is by dumping the whole rom with pdocread, making the changes, and then writing it back with pdocread again. Just remember that the new defaultcerts must be the exact same as the old one or you're going to have some errors.
 
C

chavonbravo

Senior Member
Jul 15, 2006
408
3
ND4SPD said:
Yeah, i'm talking about the pdocwrite/pdocread tools. I think what you said would work. The way I'm going to try it is by dumping the whole rom with pdocread, making the changes, and then writing it back with pdocread again. Just remember that the new defaultcerts must be the exact same as the old one or you're going to have some errors.
Click to expand...
Click to collapse

For that to work, I'd need a 440 byte certificate to replace the existing Toshiba one. How can you go about creating a certificate that you know will be that size? Every one I've seen is bigger.

edit: had to play quite a bit with makecert.exe options until i got the needed 440byte size, so no probs. Just gotta try it now.
 
Last edited:
C

chavonbravo

Senior Member
Jul 15, 2006
408
3
Well, don't think that'll work. I've tried, and get the error:

CopyFileToTFFS(imgfsnew.bin:0, 0, 05140000)
ERROR: ITWriteDisk - The media is write protected.

So IMGFS is write protected from itsme tools as well. Maybe there's a flag in registry that can be set to change that, but I doubt it.
 
You must log in or register to reply here.

Similar threads

A
Pandora on Windows Mobile
Replies
420
Views
243K
J
jpinsl
Sleuth255
[App] ROM Flashing Junkies: User Customization is here!
Replies
2K
Views
917K
S
spam.anonym
pof
HTCFlasher: Open Source ROM Update Utility (RUU) for HTC devices
Replies
225
Views
299K
S
skooter32
Cobaltikus
[Aug-20] CobaltController - PS3/Wii Controller Driver for Windows Mobile
Replies
682
Views
265K
Cobaltikus
Cobaltikus
A
[!WP7 support!] Htc ROM Image Editor and other Tools.
Replies
221
Views
168K
ruyzalim
ruyzalim

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 7
    Da_G
    Da_G
    ***THIS POST IS NOT COMPLETE, I WILL UPDATE MORE LATER***

    First, an introduction:

    The Image Update system allows the OEM (us! :)) to issue updates to a "Live" filesystem - without disrupting user data. This allows, for example, a buggy driver to be updated after the phone has been shipped, or a software package to be updated to the latest version, with minimal knowledge on the user's part. The system validates all updates against an internal list of certificates, and refuses the update if a match is not obtained. This system can also be used to deploy entirely new software to the device (such as support for another locale, input method editor, application support for a new feature the carrier is rolling out, etc.)

    Potential usage scenarios for this system

    A central server could be maintained for all SYS/OEM updates - each ROM Chef would need to maintain a list of original packages, any updated package(s), and download URL's for each updated package. The user would then receive these updates through the built-in AutoUpdate facility in Windows Mobile, which can check periodically, or on-demand. Each Chef could maintain seperate download servers from the update server to minimize server load.

    Alternatively, a chef could provide .cab.pkg updates in his or her ROM thread, on their own web site, etc., and the user could download these and install them at will. These packages can optionally be authenticated to be coming from the Chef, if the Chef wants to ensure updates are coming from him only. A public certificate could also be used to allow users to issue updates as well.

    The more technical Summary

    Image Update allows an OEM to issue updates to the OEM's, XIP, SYS, (possibly) Radio, or any combination of these. The update can be pushed to the user via a specially formatted SMS or by manual execution. There are at least 2 levels of certificate checking involved in the process, I believe against \SYS\Metadata\DefaultCerts.dat. The system reboots into the ULDR to apply the update, because the filesystem cannot be modified while actively mounted. The ULDR provides a minimal operating enviornment to facilitate this.

    How does a Chef need to prepare a ROM for Image Updating?

    The Chef would need to use a ROM Kitchen that leaves the .dsm and .rgu file structure intact (i.e. an "unprotected" ROM) - All .dsm's in this ROM would need to be properly formatted with Package Name, versioning info, etc. during the cooking process, in order to facilitate version checking, etc. Each .dsm would need to be signed with a certificate the Chef would use to validate the update as coming from him or her. (Alternatively a public certificate could be used like SDKCerts if the Chef chooses not to maintain direct control over updates, and allow other users to create updates as well)

    The Chef also needs to ensure not to Reduce the ULDR partition or remove it; this would cripple the Update Loader and prevent the Image Update system from functioning.

    The .cab.pkg format

    At the root of a package, the .dsm defines the Package structure (all files, registry entries, etc.) It contains version info, certificates, and other data. A ROM consists of a number of these packages, in an area of flash memory that is not user-writable. When someone wants to issue an update using the ImageUpdate system, they create a matching .dsm, same guid, with a newer version number, same internal package name, same processor ID, os version, etc., there is also a flag that can be marked as an update package or a new package - in this .dsm they define the files that will make up the new, updated package. Here they can add or remove files. One of the files defined by the package is optionally an .rgu, and this defines the registry entries associated with the package. Also optionally included is a provxml to facilitate file operations (copy/replace/delete/rename/etc.) and further registry or metabase operations. This collection of files is rolled up into a ".cab.pkg" archive by a program like cabarc. Once in a pkg.cab format, the package is signed.

    A .cab.pkg is referred to as a "Canonical Package" and multiple Canonical Packages can be rolled up into a single "Super Package" to facilitate updating multiple Packages at the same time.

    Inside this .cab.pkg is where the "MNGE" file format comes in to play. Essentially, this format is Microsoft's way of storing an XIP Module in the filesystem. (Their equivalent of our imageinfo.bin + s000, s001, etc.) - The "MNGE" format is simply a 4-byte MNGE header, followed by the imageinfo.bin, followed by the s00x sections attached to the end. When the Image Update system processes a file in this MNGE format, it is added to the IMGFS as an XIP Module.

    Deploying a .cab.pkg to a device

    Now there are several ways to deploy this package to the device, the primary way is an OMA-DM SMS message, which triggers the Image Update system to initiate a download from a server defined in the SMS message. The server can be either a normal HTTP server or a secure HTTPS server. The Image Update system will prompt the user to plug in the usb cable to download over the users home connection if the user has not already authorized the Auto Update system to utilize their GPRS data connection.

    Another way for a .cab.pkg update to be pushed to the system is simply through a file copy operation, be it ActiveSync, SD Card, Bluetooth, or otherwise. Once on the device, the .cab.pkg is executed by the user the same way a .cab would be.

    The Update Agent

    Initiated by either a completed download from push SMS, or user-executed, the "Update Agent" program (which is part of the \SYS\FWUPDATE Package) attempts to validate the Certificates, Package dependancies, and other info contained in the .cab.pkg and .dsm. Once validated, the "Update Agent" sets a flag that the bootloader reads, the flag is a boolean, off = boot into normal OS, on = boot into ULDR - so then the system reboots, the flag is read, and you load into...

    The Update Loader

    The "Update Loader" or "ULDR" which is a minimal kernel configuration, that provides just enough driver support to display info on screen, respond to user input, and read/write from the internal flash (NAND or NOR)

    From here the ULDR does further validation on the .cab.pkg, and applies it to the filesystem. If there are any modules in the package it dynamically relocates the memory map to make sure there are no overlaps. This is why it's important that reloc's not be removed from your ROM - ULDR will fail in this case.

    The End Result

    Once the ULDR has completed updating, the device is again rebooted, back into the full system, where the now-updated packages are now a part of the IMGFS, any updated files are processed (.rgu, .provxml, etc.) - The package is now a full part of the ROM.

    The new .dsm replaces the old .dsm (along with the other files in the package) and now a future update will be checked against this new package.

    If the update was pushed via OMA-DM SMS, or AutoUpdate, the device Pushes a notification to the OMA-DM server notifying it of the update status.

    What's missing right now to implent the ImageUpdate system?

    We need a Kitchen that's properly configured to allow us to create versioning info, proper package names, and insert this along with a certificate (or multiple certificates) into the .dsm's.
    We also need the Kitchen to be able to modify \SYS\Metadata\DefaultCerts.dat with the certificates used, so that it passes authentication. Alternatively the authentication checking could be patched out. (this one is easily doable at build-time)
    We need a program that can convert from a standard file to an MNGE format, so we can implement modules in our .cab.pkg's. (done it seems, thanks ervius!)
    We (optionally) need a properly configured web server that supports HTTP/HTTPS, can communicate the proper xml configuration data, and can be updated with new packages by Chefs. (this one's a ways off)
    We (optionally) need a program to convert from MNGE format to a standard file to facilitate extracting modules from .cab.pkg's. (working hard on that)
    View
    3
    Da_G
    Da_G
    I've attached a .cab.pkg for NetCF2. Open up mscoree.dll in a hex editor, and check out the MNGE header. This file becomes a module once processed by the ImageUpdate system. Note that all the executables (.exe/.dll/.mui) that become modules contain this MNGE header. All executables that are inserted into ROM as files keep their normal MZ file header. The first major step here will be in being able to convert between MZ<-->MNGE freely :) NetCF2 is a well known package that can be found in any stock ROM, so with this we have a good baseline to work with.

    http://rapidshare.com/files/238295848/netcf.cab.pkg
    View
    3
    Da_G
    Da_G
    More Technical Specifications

    The basic ImageUpdate Layout consists of:

    [IPL] -- [MBR] -- [ULDR] -- [NK] -- [IMGFS] -- [TFAT]

    [IPL] is the "Initial Program Loader" that handles basic init functions and determines if control should be handed over to ULDR, or NK through a flag set by UpdateBin.exe - the IPL is not contained within a partition. The IPL is copied entirely to RAM and executed from there. IPL loads NK into RAM, and also handles any decompression of NK if it's required - some SmartPhone's ive seen use SRPX compression for the NK partition. Once NK is copied to RAM it is then executed. The IPL is handled seperately from the other parts of the operating system, and is not flashed during a normal update.

    [MBR] is the "Master Boot Record" and contains partition tables for the below components - it points to NK so when IPL loads the MBR, control is handed over to NK. The MBR contains information on where each partition is located on the flash (memory address), the size of the partition(s), and the type of each partition. The MBR is referenced from many components on the device such as IPL and ULDR in order to facilitate handoff of control between ULDR and NK. The MBR also serves as a boundry between the IPL which is not part of the regular partition structure, and the rest of the flash, which is part of the partitioning structure.

    [ULDR] is the "Update Loader" and provides a basic WinMo system so that file operations can be done on the IMGFS partition while it's unmounted. The Update Loader is even able to update itself - during operation it is loaded entirely to RAM. On development workstations the ULDR supports a KITL connection, that can be used to load updates directly from the "Release" folder. It seems it may be possible through this method to flash a new image to the device, possibly opening up the ability to flash to devices that have not yet been flashed with "HardSPL"

    [NK] is the "Kernel Partition" - or what we know as xip.bin - This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 512KB. This partition holds only the kernel and drivers necessary to bring up the rest of the filesystem, from which the rest of WinMo is loaded. The Kernel Partition uses the same "Package" format as the IMGFS and is updatable in the same manner.

    [IMGFS] is the "System Partition" - running the Image Update filesystem. This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 9.5MB. The IMGFS uses the "Package" format to further split its components.

    [TFAT] is the "Transaction Safe FAT File System" which is where all user-writable data goes.

    In most Device Designs, there's a single NOR or NAND chip used for flash. This is important as due to the typical layout above, both NK and IMGFS must have a pre-defined amount of free space - because TFAT is the last partition on the drive, and cannot be shifted once flashed to the device. It's possible for the partition layout to be setup differently (Partitions in different order) to help alleviate that problem. The ImageUpdate system would really shine on a device with 2 flash chips, a NOR chip dedicated to the ImageUpdate partition and a NAND chip dedicated to the TFAT, but no OEM has created such a design yet.

    Packages

    Package Types

    There are 3 different types of packages, Canonical, Update, and Super.

    Canonical contains the entire contents of the package. It is used for a first-time package install, and if there are any major updates to be issued that would require the complete package. The file extension is .cab.pkg

    Update contains a binary delta between a package already on the device, and the updated version of that package. In this manner the limited space is conserved (i.e. if a package change was a simple registry entry - no need to replace the 5mb of .dll and .exe in that package, just alter the .rgu with the new data. These packages are also referred to as "Delta" packages. The concept is similar to the unix implementation of Diff/Patch. The file extension is .cab.pku

    Super contains a collection of update and/or canonical packages. This is very useful when you are attempting to bring in a new package that has dependencies on other packages - rather than reboot into ULDR for each individual package in the proper dependency order, they can all be introduced at once. Every package contained inside a super package is validated, and if one fails, the remaining valid updates may still be applied, as dependencies allow. A super package is simply an un-compressed .cab containing other packages, renamed to .cab.pks

    The package layout itself is quite basic, it consists of a .dsm which contains all versioning info, association info, and dependency info. It also contains a list of all modules and files inside the package, and a certificate store of all approved certificates that will be allowed to update that package. Alongside the .dsm is an optional .rgu, which defines the registry settings associated with that package. Also optional is a .provxml file, which can be: mxip_[packagename]_[version].provxml, mxipcold_[packagename]_[version].provxml, or mxipupdate_[packagename]_[version].provxml. mxip and mxipcold are effectively treated the same, executed only on a cold boot. mxipupdate_ provxml's will be executed any time that package is updated, in addition to a cold boot - so if you are adding new .cab.pkgs and wish the .provxml to be executed immediately, it would need to be mxipupdate. This may not be desirable in some cases, such as when the provxml might override a user preference - in that case you would only want it to run on a cold boot, in order to avoid "strange" behavior on the user's side of things.

    There is a "shadow order" defined in the .dsm as well - this controls what "priority" .rgu's are compiled together into the device registry hive - a package that shadows another package will override any .rgu entries that shadowed package may contain. This is important to consider when utilizing .cab.pkgs in order to obtain your desired end registry. This shadow order also applies to provxmls inside the package - a package that shadows another package will override its provxml settings as well.

    The user registry hive is always top-most in the shadow order (except in the case of an mxipupdate_ provxml) - so any changes to .rgu registry settings will not override a user-changed registry setting. (example: You had foobar set to 5 in your initial deployment. At some point after flashing to his/her device, the user modified the registry, changing the value of foobar to 6. Your new .cab.pkg contains an .rgu changing foobar to 7 - on device, foobar will remain set to 6, as the user registry is higher in the shadow order than the .rgu) - in the case of an mxipupdate_ provxml these will override user settings.
    View
    1
    Da_G
    Da_G
    --Reserved--
    View
    1
    l3v5y
    l3v5y
    Da_G said:
    Yep, not pushed though as that needs to be triggered via an OMA-DM SMS message, and it's not practical for someone to maintain a database of all our numbers for such a purpose.. but easily though settings - autoupdate

    I am able to extract files from .cab.pkg with winrar and 7zip, not able to create them just yet.. working on that. This one came from a blue birdy. ;)

    The MNGE headered files could indeed be replaced by a converted module, but in this case, there's a different reason for needing to convert from MNGE -> MZ, :)

    It appears to me as though the file size difference had to do with the PE executable headers that are missing..
    Click to expand...
    Click to collapse
    Oh right. It's not hard to just check for updates every so often.

    I just ran Cab2OEM on the cab.pkg files, and it extracts fine. So cab.pkg files are just cab files in terms of compression.

    Is that because there are more up to date MNGE file versions than the MZ equivalents?

    Is it just a case of replacing the file headers? *opens up hex edit*
    View

New posts