msftool -- Motorola Superfile Editor

[samr7]

This is a tool for editing Motorola superfiles -- SHX and maybe someday SBF. It can be used to create SHX files for use with PST. It's similar to puper's SHXCoDec, but comes with source, has a command-line interface, can handle multi-interface files, and can encrypt and decrypt non-RSA section images.

The current version is 0.1.1 -- USE AT YOUR OWN RISK.

This tool has the following features:

• Split an SHX file into .DSC/.BIN files with (hopefully) full detail preservation.
• Combine a .DSC/.BIN group into an SHX file.
• Support for single-interface and mult-interface superfiles
• Transparent recomputing of checksums -- most of the time.
• Transparent encryption/decryption of encrypted Neptune image data.
• Transparent rewriting of the section manifest for EZX AP ramldrs.

Using msftool and PST to modify firmware has two advantages over the pivot_root thing: you can flash without having Linux in a bootable or shell-accessible state, and no memory card is required.

There are three modes of operation:

1. Dump information about an SHX file:

msftool file.shx

This will check the integrity of the SHX file, and output the metadata to stdout. The metadata is in the msftool .DSC format.

2. Decompose SHX into DSC/BIN:

msftool -x file.shx

This will produce one .BIN file for each section in the SHX file, and a text .DSC file with the headers and other metadata.

3. Compose DSC/BIN into SHX:

msftool file.dsc

This will create an .SHX file out of a .DSC file and any number of .BIN files. If the .BIN/.DSC group was unmodified from a "-x" decompose operation, the result should be the same as the original, or inconsequentially different -- more or fewer newlines between S-records, altered alignment of S-records, reordered section descriptors in the ramldr, etc.. You may replace or modify any of the checksummable .BINs, or edit the .DSC to add/remove sections, and recompose into a new SHX.

Motorola superfiles include ramldr code, which is uploaded to the device before the actual firmware code, runs on the device, and is responsible for writing the firmware to flash and computing checksums. In order to create a superfile, you need a ramldr program appropriate for your device and firmware type. Unless you know how to create a ramldr for your device -- and drop me a note if you do!! -- you'll need to find a preexisting superfile for your device that contains a ramldr, and extract the ramldr. On top of this, if you diverge from the structure of the original superfile when "borrowing" its ramldr code, you better know what you're doing. There seems to be a lot of variation in ramldr programs among A780 superfiles, and not every ramldr will work flawlessly in every case. Some ramldrs will cause PST to emit "code group contains no subscriber checksum" errors, which should be harmless.

msftool is most likely to work correctly for the case of generating EZX superfiles that contain only AP image data. These will contain only images for platform "GSM Dalhart" and will consist only of Linux updates. As long as you don't overwrite the boot loader area, and possibly even if you do, it is unlikely that you will brick your phone.

I have tested msftool by creating a superfile derived from the 0D.50AHP China Mobile branded firmware, including encrypted BP portions that were decrypted and re-encrypted, and minus the language pack, userfs_hat, and setup parts. This abomination flashed successfully and seems to work.

[_Paradise]

As long as you don't overwrite the boot loader area, and possibly even if you do, it is unlikely that you will brick your phone.

Are you sure the bootloader is in the SHX file?

If you fail to flash the flash will erased but you still have access to the bootloader. so i'm thinking the bootloader is protected from erase and possibly could only be flashed from within a working OS on the phone.

Edit: i'm talking about the bootloader for the AP.. the BP is a different story

[pnail]

Can't this be done by standard binutils: (arm-linux-) objcopy?

[samr7]

[Are you sure the bootloader is in the SHX file?

If you fail to flash the flash will erased but you still have access to the bootloader. so i'm thinking the bootloader is protected from erase and possibly could only be flashed from within a working OS on the phone.

Edit: i'm talking about the bootloader for the AP.. the BP is a different story

The bootloader area is address range 0x00000000 - 0x00020000. It's listed as part of the built-in 32MB flash inside the Bulverde which starts at address 0. I haven't found any superfiles that include data for that region. That doesn't mean they don't exist, but also doesn't preclude that region from being some sort of special ROM.

On top of this, PST internally differentiates between "Blank" devices and "Reflash" devices, and expects different superfiles for each. Presumably a blank variant is what can be found at the end of an assembly line, with just enough code to facilitate loading the real firmware. I have never seen a "Blank" variant of any device. Some folks on motofan.ru have figured out how to convert an E398 into a blank variant by hardware manipulation, and this Neptune-based device clearly supports blankness through ROM code. The EZX devices may or may not have this sort of ROM code for their AP. I'm not much interested in experiments involving overwriting the boot loader area without some more specific information.

Edit: It's certainly possible that the boot loader might enact protections to try to prevent its area from being overwritten by a ramldr program, which have been disabled by something like the rwflash driver. I really don't know.

[samr7]

Can't this be done by standard binutils: (arm-linux-) objcopy?

Is there actually a BFD backend for superhex files? I haven't picked through the SDKs yet but that would be quite shocking, I was under the impression that SHX/SBF were Motorola proprietary secret formats.

[_Paradise]

[qoute]The EZX devices may or may not have this sort of ROM code for their AP. I'm not much interested in experiments involving overwriting the boot loader area without some more specific information.[/quote]

Yeah, smart thinking..

You at least need a working JTAG if you want to see your phone alive again after you mess up the bootloader.

But uhh.. isn't 0x00000000 - 0x00020000 about 128kb?

EDIT::
Meaning; i think it's alot of space for the bootloader, i think the C+ 64 needed less rom for it's basic.

[samr7]

Yeah, smart thinking..

You at least need a working JTAG if you want to see your phone alive again after you mess up the bootloader.

Thanks, I don't have access to a JTAG and that sounds very unpleasant.

But uhh.. isn't 0x00000000 - 0x00020000 about 128kb?

EDIT::
Meaning; i think it's alot of space for the bootloader, i think the C+ 64 needed less rom for it's basic.

It does seem awfully big. Most of the AP ramldr programs are even bigger though, on the order of 143KB of actual code. LOL, probably not written by hand.

[mack]

samr7: If this new tool includes the key for encrypting/decrypting non-RSA BP code, can't we use it to encrypt the german (GPS) BP code ?

As far as I recall, the german BP is plaintext, and just has some RSA signature. If we strip the signature and encrypt it into an SHX, maybe we'll finally get the GPS working ?

[samr7]

samr7: If this new tool includes the key for encrypting/decrypting non-RSA BP code, can't we use it to encrypt the german (GPS) BP code ?

As far as I recall, the german BP is plaintext, and just has some RSA signature. If we strip the signature and encrypt it into an SHX, maybe we'll finally get the GPS working ?

You could try, but it's likely to be futile. The RSA firmware is designed for a Neptune with a different address map. How would you even construct the superfile? By taking the CG{0,1,2,3,17} section images from the German superfile and have them flashed to the corresponding addresses for the non-RSA phone?

I would be willing to wager that the encrypted 0D.41.B1P and RSA 0D.C0.B1P BP firmwares both have working software support for the GPS module. Try taking apart the clamshell cover of your phone like in this thread and see what you find under the metal shield:

http://www.www.motorolafans.com/inde...ewtopic&t=1623

[mack]

Right, I forgot about the different addressing issue. I guess it won't work. Still, if you have everything needed for that, why not give it a shot. (I don't have a way to PST. I only use rwflash.o for reflashing). I'd try to encrypt the BP (CG1 ?) of the GPS phone and put it where the non-GPS phone expects its BP. Probably won't work but interesting to try.

Anyway, I agree with you that our BP software is most likely to include the GPS stuff, especially since we see these __FILE__ strings.

Re the thread you linked, I replied your message there now.

Anyway, if its a GPS and we have strong reasons to believe that our BP supports it by software, then it must be controlled by some SEEM we're missing. We already know how to talk to it from the linux side (my prog that talks to lapisrv), so it appears the only thing that stops us is that the GPS is somehow disabled on the BP side. Maybe we should try to upload a SEEM wit all 1's ?