|
|
IriverNavigation
Tools Guideihpfirm (firmware encryption/decryption tool)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. 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!)What is "ESTFBINR headers"? I found this RockBox mail. -- StephanNielsen 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 decryptionDaveHooper : 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.ihpfirm linksihpfirm Windows Binaryihpfirm Source Code dd (convert and copy a file)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=notruncthat 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). In the linux prompt:GDBHere is a nice http://www.ucdot.org/article.pl?sid=03/01/30/0548223&mode=thread GDB guide.MFC5249 Coldfire Cross-CompilerA 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: CrossGCC Frequently Asked QuestionsHints, Tips, & Tricks for GNU C Coldfire MFC52xx EmulatorCompiling 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 download the emulator first, and untar it. Also download an image for the 5206 from the uClinux download page, and ungzip it. Then cd into coldfire-0.x.x and:./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. Emulator UsageIf you write 'help' in the emulator prompt, you will be shown a list of possible commands (these commands will be further explained later):ALIAS BR [ CFRD CFRI CFRM DE DI DL dl --offset 0 input_file.bin DN EXIT GO MM.L MM.W RD PRD RM SS [(c)lear] COMPAT TRACE TIME r12 - 02 Apr 2021 - 20:46:07 - UnknownUser
Copyright © by the contributing authors.
|