DI-604 Flash Reverse Engineering

Flash image with firmaware version 2.10 flash.bin

Encoding: little

Flash memory map:

• 0x0000.0000 - 0x0002.0000 - bootloader (permanent) (used up to 0x1.39e0)
• 0x0000.0000 - 0x0000.1800 - initialisation code
• 0x0000.1800 - 0x0000.3000 - uncompression code (ARJ), copied to the 0x2030.0000 prior to execution
• 0x0000.3000 - 0x0001.0000 - ARJ compressed "factory setting" restoration image
• 0x0001.0000 - 0x0001.39e0 - text strings/ configuration data ???
• 0x0001.39e0 - 0x0002.0000 - empty space ??
• 0x0002.0000 - 0x0010.0000 - ARJ compressed firmware image - upgradable via HTTP or TFTP (current version is 2.10)
• 0x2000.0000 - SDRAM start
• 0x2038.0000 - 0x2039.477b
• 2038.3884 - ??
• 2038.3964 - ??

Firmware Format

Info from Chris Windibank, 01/Mar/04

The firmware file is always 917,504 (0xe0000) bytes in length, presumably because it's a 1MB flash and the bootloader, backup firmware and settings area is 131,072 (0x20000) which leaves exacly that amount!

It is checksummed by the attached code. They decided to xor all bytes together and check it against a know value. I'm not really an expert in checksums so I can't say if this is unusual or not but it's certainly not a mainstream algorithm.

The first part of the file is the actual firmware in ARJ format using the -m1 compression mode and the archive consists of a single file named NML.MEM. The unused area after the firmware is zeroed and finally a signature and checksum is attached at the end. The signature is constant and the checksum can be calculated by xoring all the bytes in the file minus the checksum area and then xoring the result with 0xaabbbbaa.

The attached file can be used to generate a valid flash binary. I am a WindowsXP user and it was tested with Visual Studio 6.0 but it only contains C standard library calls so it should compile fine with GCC. It's usage is as follows:

mkflash outfile - where outfile is the name of the output file (I use di604_firmware_ucl.bin)

It expects to find a file name NML.ARJ in the current directory (the first version took and input file but I got tired of typing it). I have been renaming zImage NML.MEM and then using the following to make the archive for mkflash.

arj32 a -m1 NML.ARJ NML.MEM

I'm not sure if the firmware checks to see if the arjed file in the archive is actually name NML.MEM but that is the way DLink does it so I did the same.

The bootloader expands the archived firmware sitting at 0x20000 in flash ROM to 0x20000000 in RAM. It then flips the RAM/ROM address spaces and jumps to address 0 which is the begginning of RAM after the flip.

At this point the router will start to execute zImage which is a compressed kernal and ramdisk. It should decompress the kernal and ramdisk and then jump to the entry point of the decompressed kernal. I chose to go with the compressed kernal because it's an easy way to get the ramdisk into memory from a single arjed archive. It may be better to try something different later when the kernal is actually working!

Bootloader decoding

check SRC of the main firware (0x2000)
check reset buttom

load uncompression code to SDRAM
      if RESET load from      0x03000
      if no RESET load from   0x20000
if uncompression return 1 - then switch memory and start from 0
	   

void  f_0x9c4()
{
   f_0xebc(16,-1);
   return;
}	   

*20383884 = r0;
return -1;

 if(!f_0x00db0)
       return 20383964;
 else
       return f_0x0db0(); // 20383884
	   

void f_0x0f24(word val){
{
  word *addr;
  addr = f_0x0edc();
  if(addr!=0)
       *addr = val;
   return;
}
	  

indirectly called functions 0x4e0
0xacc - 0xae4
0xae8 - 0xd24
0xd28 - 0xdac