The motivation for writing this WikiPage is to minimize the time people interested in the iRiver RockBox port project have to spend on learning tools. This means that they can quickly get to more productive work. If you have any questions about tools usage then please ask in the IRC channel or email. -- StephanNielsen

ihpfirm (firmware encryption/decryption tool)

DaveHooper(stripwax) has developed and published decryption & encryption tools.tools(the tool can encrypt/decrypt firmware for the H1xx-series and H3xx-series iRiver players). This tool is used to decrypt the original firmware before analyzing it. The tool can be compiled under Linux. Let me know if you have any problems doing so or if you find you need to make any changes to the source - DaveHooper )

ihpfirm -[de] (-m) (-[sS]) (-i infile) (-o outfile)
Decodes or encodes firmware binary file for the
iRiver iHP-100, iHP-120 and iHP-140 portable media players.\n
Options:
-d : Decodes an encoded firmware file (as obtained from iRiver)
-e : Encodes an unencoded firmware, to enable upload to the device
-m : When decoding, don't mark the header; when encoding, don't expect a marked header (DANGEROUS)
-s : When decoding, strip header and checksum block from output file
(i.e. outputs just the raw decoded firmware plus ESTFBINR header)
This flag **CANNOT** be used to encode firmware, as the header
contains hints for which model the firmware is targeted for
-S : When decoding, strip header, checksum and ESTFBINR header from
output file (results in just the raw decoded firmware)
As above, this flag **CANNOT** be used when encoding.
If infile or outfile are not specified, uses STDIN or STDOUT respectively
When encoding, AUTOMATICALLY updates the checksum table at the end of the
file (earlier versions of the utility did not do this!)

We use the -S flag to get the raw firmware machine code without the headers. (This is correct. The first two dwords of the 'raw' output generated using -S will be the PC and SP as documented elsewhere. DaveHooper )

ihpfirm -d -S -i ihp_120.hex -o raw1.40us.bin

A short description of the decryption

DaveHooper : The code is divided into 512-byte blocks. We initialise a 16-byte mask with a fixed pattern and XOR this with the first 16 bytes of the block. Then we write out the bytes in the following order: 2,3,4,1,6,7,8,5,10,11,12,9,14,15,16,13. Then we shift these bytes into the mask and use it to XOR the next 16 bytes. At the end of the 512-byte block, we reinitialise the 16-byte XOR mask with the fixed pattern. At the end of the firmware image is the checksum block. For each 512-byte block we derive one checksum (this checksum is actually just the XOR of all decoded bytes).

Are we sure that the firmware is 100% correctly decrypted? I'm pretty certain - certainly the decryption, edit, reencryption steps work and the resulting modified firmware runs on the device. Proof at ihpbmp (graphics/icons modification tool for iHP). If someone has some time to kill they could analyse the decryption routine in the firmware and compare with my source if they liked.

that example copies the first block of SDRAM at offset 0x3100000 into offset 0 (seek=0) of sdram_img.bin.

AddStrings (perl script)

PaulS? made a nice perl script to add strings references to the assembly code. This will add a surprising amount of clarity to the code since there are more than a few error messages that were built into the code (but the error function itself appears to have been ifdeffed out).

GDB

MFC5249 Coldfire Cross-Compiler

A cross-compiler enables compilation on a PC of i.e. C code to MFC5249 machine code.

The current gcc doesn't support the EMAC instructions, and the MAC support is said to be less than perfect. The CVS version of binutils supports the EMAC extensions. You will need to build your own cross compiler, as the latest binutils 5249 extensions haven't been released yet.

Coldfire MFC52xx Emulator

Compiling the ColdFire emulator on linux is pretty easy. Right now we don't have a working emulator for the MFC5249, so to get use to the ColdFire Emulator (which by default only supports 5206, 5206e, 5307 ColdFire processors) try downloading an uCLinux image first and play around with it. Here is how you compile and run the default emulator:

Follow the updates on the ColdfireEmulatorDevelopment page. Contact the people envolved in emulator modding if you are interested in the current MFC5249 emulator source code.