Wiki > Main > IriverToolsGuide (compare)
Difference: IriverToolsGuide (r10 vs. r9)
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
DaveHooper (stripwax) has developed and published decryption & encryption 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
Dave's scramble/descramble code has now (as of Jan 24th 2005) been incorporated into the Rockbox scramble and descramble tools.
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
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.
This linux command is utilized to extract specific address parts of the firmware. An example:
dd if=raw1.40us.bin of=sdram_img.bin bs=1 skip=$[0xE3099] seek=$[0x0] count=$[0x19D2E9-0xE3099] conv=notrunc
that example copies the first block of SDRAM at offset 0x3100000 into offset 0 (seek=0) of sdram_img.bin.
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).
In the linux prompt: /usr/bin/perl add_strings.perl_script sdram_img.bin ihp_sdram.asm 0x31000000
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.
Here's how you Build a Cross Compiler
Some additional info for the interested:
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.
This info is from www.slicer.ca
./configure make Run the emulator: ./coldfire Connect 2 telnet clients to it (one for each serial ports the coldfire supports): telnet localhost 5206 telnet localhost 5207 Go back to the emulator window and download the uClinux binary: dBUG> dl /path/to/image-an5206-big-20000706.bin Start it up: dBUG> go 10000 Watch serial port 1 (telnet localhost 5206) for output. It will hang on calibrating the delay loop for a while.. that's normal.. don't panic. run with: ./coldfire --timerhack to speed up the timer.
If you write 'help' in the emulator prompt, you will be shown a list of possible commands (these commands will be further explained later):
DL To load a binary file into the emulator at offset 0x0 write:
dl --offset 0 input_file.bin
r11 - 29 Oct 2007 - 08:18:19 - DaveChapmanRevision r10 - 24 Jan 2005 - 09:18 - DanielStenberg
Revision r9 - 21 Jan 2005 - 14:35 - DaveHooper
Copyright © by the contributing authors.