diff options
Diffstat (limited to 'oncology/dpfhack_display/reverse/README')
| -rw-r--r-- | oncology/dpfhack_display/reverse/README | 169 |
1 files changed, 169 insertions, 0 deletions
diff --git a/oncology/dpfhack_display/reverse/README b/oncology/dpfhack_display/reverse/README new file mode 100644 index 00000000..c70fa49e --- /dev/null +++ b/oncology/dpfhack_display/reverse/README @@ -0,0 +1,169 @@ +Reverse engineering HOWTO +---------------------------------------------------------------------------- + +Here it is, the long awaited hacking howto for the AX206 DPFs. + +BIG FAT WARNING: You have to be able to read 8051 assembly code and you +HAVE TO know what it is doing. Otherwise you will likely brick your frame +and we will all laugh at you. + +Also you should know something about the SPI flash layout, have a look +at the m25p80 datasheets found all over the web. Basically you should +remember that the flashes are organized in sectors of 0x10000 size. + +Since the boot loader mode is a big secret, we have to exploit the hardware +somewhat to get into the "Developer Mode" (hacking is a ugly word). +To implement developer mode, we normally use the strategy to modify the +powerdown routine such that when USB is plugged in and you press and hold +MENU for a few seconds, it will enter the modified state. +This allows us to return to the original firmware by pressing RESET. + +To get started, you need a few tools and items: +- A dump of your DPFs firmware (look for fulldump.py script from the + dpfhack-*.tgz archive to create one) +- The d52 disassembler: http://www.8052.com/users/disasm/ +- Installed Python package + +The dump binary first needs to be split up into single modules. +Why modules? The memory of the AX206 isn't big enough to store a full +program, thus a bank switching technique is used. A bank switched call +looks like: + + mov a,#0x1e ; 13a2 74 1e t. + mov dptr,#mod31_1330; 13a4 90 13 30 ..0 + lcall tramp_jsr ; 13a7 12 19 38 ..8 + +The number moved into 'a' is the module number minus one. The dump.py +script analyses the code, so you will only have to look at the modXX_XXXX +function. This is the target function called in the according module. +The loading on demand and calling of the function is handled by +tramp_jsr(). + + +1. First, you copy the generated dump (full.bin) into a folder, like + dpf/reverse/new and rename it to full_dump.bin +2. Run the makefile: + > make -f ../Makefile dump" + You will end up with a number of + *.in files in the current directory if this was successful. +3. Run make again: + > make -f ../Makefile + Now you should have a few *.asm files in the working directory. +4. Identify the powerdown module. Normally, it helps to grep for p2up: + > grep p2up *.asm + That should list a module with number around 36 or 37. +5. The powerdown ROUTINE is the function that is called most often from many + modules, but most probably NOT called from module 1 (dump01). In many + cases, this turned out to be mod37_1330. + +WARNING: You have to make sure that this module does not live in sector +0x000000 of the flash (see "dump file offset" tag in the header of the +assembly file). If it lives in sector 0x000000, the described method +will NOT work and you will brick your DPF. + +5. Find the splash screen routine that is called from the powerdown. + This is normally the routine called at the beginning of the powerdown + routine and contains code like: + + mov G_lcd_cxH,a ; 1509 f5 78 ux + mov G_lcd_cyL,a ; 150b f5 79 uy + mov G_lcd_cyH,a ; 150d f5 7a uz + mov G_lcd_dxL,a ; 150f f5 7b u{ + +6. This routine you can patch. Take a p_start_*.s from an already hacked frame + and make sure you understand what is happening. Adapt the .org statements + to the locations where YOUR patched code can safely live. + +7. The final jump into the patched firmware occurs at the bottom of the + patch, looking like + + mov a,#(53 - 1) + mov dptr,#entry_addr + ljmp tramp_jmp + + The module number in here will be the number of the last module you + extracted, PLUS ONE - because we are gonna add an extra module. + For this, the jump table will need to be modified. + +8. We do not touch the original jump table, but make a copy of it (because + it lives in sector 0x000000). The jump table record for this extra module + will be stored in the end table tag which can be read clear text in the + dump00.asm as "-EndTbl-". Have a look at a jmptbl_*.s file, the .org + statement - i.e. the address offset - has to be the offset address of the + "-EndTbl-" string. + +9. Have a look at the hackit.py script. The critical function overwriting + data on the flash is the .patchSector() method, called like + + d.patchSector(start, flashaddr, hexfile) + + start is the relocation start address of the hexfile that the flash is + patched with, it is normally identical with the first .org offset specified + in the *.s file. + flashaddr is where it is stored on the flash. + hexfile is the intel hex data file the flash is patched with. + + The hackit.py framework will take care of the patching, so you merely + will need to add another configuration record in profiles.py. + + This is an example record: + +patch_pink = [ + (COPY, [0x000000, 0x3f0000]), # Copy sector 0 + (PATCH, [0x0, 0x3f0000], "jmptbl_pink.ihx"), + (BINARY, [0x0, 0x390000], "font4x8.bin"), + (PATCH, [0x0, 0x380000], "fw_pink.ihx"), + (37, [ 0x87f37fa6, 0xc8c55832, 0x27b13328 ] , "p_start_pink.ihx"), +] + + The first COPY statement tells hackit to make a copy of the first sector + to the specified address, which should be at the end of the flash. + The PATCH statements patch the given sector address with the hex file + specified. + The BINARY option just copies a plain binary to the given address. + Finally, the very critical patching of the powerdown routine. + The first number (here 37) is the module number of the powerdown routine + as identified by you. Then, a list of known CRC32 checksums follow. + If the sector to be patched here is unknown by its CRC32, it will refuse + to patch it and print out the non matching CRC32. + + When you are ABSOLUTELY sure your hack will not overwrite anything crucial, + you can insert this CRC32 as first number in the list. + +10. Did you do the paranoia check of all addresses and offsets, do you + understand where things will go? If in doubt, make a dry run with the + patchSector function on an empty/unused sector, preferrably at the + end of your flash. Then analyze the dump again. + +Finally, you can try hacking your DPF with the hackit.py. +Once it is hacked, it will again print out a non matching CRC32 if you +run the hackit.py again. This CRC32 you insert as LAST number (mycrc) +in the list: + + (37, [ original_crc, my_crc ] , "p_start_mine.ihx"), + +Now you can test your hack and publish the profiles.py on success. + +---------------------------------------------------------------------------- + +A few advices: + +REMEMBER: Never touch sector zero (address 0x000000 - 0x010000). Never ever. + +If you bricked your frame, don't throw it away YET. Maybe some day +we'll discover how the bootloader works. And you could still use the +display for tinkering. If you have any knowledge of the boot loader, +speak up! + +Don't ask us to help you with the hacking. Try it yourself or use one of +the DPFs that are known to work. +It can take a few months to learn 8051 assembly from scratch, +but don't give up, it will be a great learning experience and later +help you to get a good job :-) + +Just read the source, duke. + +---------------------------------------------------------------------------- +Brought to you by: + +- hackfin, the evil fish, and others |