Products > Test Equipment
DG4000 - a firmware investigation
tized:
--- Quote from: cybernet on November 24, 2013, 02:28:14 am ---just reversed the crc on the firmware files for the DG4000 ;-)
its actually a packaging format, that contains multiple segments which get loaded into the flash then (the loader addresses are still a bit off) anyhow i attach a link to the splitted files.
the big 2MB file is the main code - u can load it into LDRViewer and it dismantle it without a hitch, other stuff are help system files, etc ..
so theoretically it should now be possible to modify code, stuff it back together, crc it - and flash it ;-)
http://www.filedropper.com/dumpfilestar
--- Quote ---./gelfile ./DG4000Update.GEL
hdr_buf: RIGOL:DG4:UPDATE FILE ALL
fwr: CRC:7A57 ADDR:20040000 LEN:00228EF0 00000004 00000004
-> dumped dump_20040000.bin (2264816 bytes)
fwr: CRC:8CE7 ADDR:20300000 LEN:000C3DF6 00000008 00000008
-> dumped dump_20300000.bin (802294 bytes)
fwr: CRC:8C44 ADDR:20400000 LEN:00001661 00000008 00000008
-> dumped dump_20400000.bin (5729 bytes)
fwr: CRC:0611 ADDR:20440000 LEN:00000252 00000010 00000010
-> dumped dump_20440000.bin (594 bytes)
fwr: CRC:8845 ADDR:20440400 LEN:00002855 00000010 00000010
-> dumped dump_20440400.bin (10325 bytes)
fwr: CRC:D973 ADDR:20443400 LEN:00000252 00000010 00000010
-> dumped dump_20443400.bin (594 bytes)
fwr: CRC:BDC8 ADDR:20443800 LEN:000019FE 00000010 00000010
-> dumped dump_20443800.bin (6654 bytes)
fwr: CRC:8570 ADDR:20460000 LEN:00000206 00000010 00000010
-> dumped dump_20460000.bin (518 bytes)
fwr: CRC:3CB3 ADDR:20460400 LEN:0000F081 00000010 00000010
-> dumped dump_20460400.bin (61569 bytes)
fwr: CRC:D5A9 ADDR:2046FC00 LEN:00000206 00000010 00000010
-> dumped dump_2046fc00.bin (518 bytes)
fwr: CRC:0259 ADDR:20470000 LEN:000091B6 00000010 00000010
-> dumped dump_20470000.bin (37302 bytes)
fwr: CRC:219D ADDR:205B0000 LEN:00169DE8 00000020 00000020
-> dumped dump_205b0000.bin (1482216 bytes)
fwr: CRC:A299 ADDR:207B0000 LEN:0003D6C4 00000040 00000040
-> dumped dump_207b0000.bin (251588 bytes)
fwr: CRC:63BD ADDR:20830000 LEN:0004BB9C 00000040 00000040
-> dumped dump_20830000.bin (310172 bytes)
fwr: CRC:0000 ADDR:209B0000 LEN:00480000 00000080 00000080
-> dumped dump_209b0000.bin (2097152 bytes)
-> dumped dump_20bb0000.bin (2097152 bytes)
-> dumped dump_20db0000.bin (524288 bytes)
--- End quote ---
--- End quote ---
Funny thing, I've just done the same for the DS2000 firmware and this is what I got:
--- Code: ---Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
--- End code ---
The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.
cybernet:
--- Quote from: tized on November 24, 2013, 01:24:31 pm ---Funny thing, I've just done the same for the DS2000 firmware and this is what I got:
--- Code: ---Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
--- End code ---
The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.
--- End quote ---
nize stuff, im also looking into the DS2000 atm - but you are a step ahead as it seems.
for the DG the bootloader stream is in 0x2000 0000 - the application is in 0x2000 4000 - looking at your GEL listing, i would assume its the same with the DS2k.
the bootloaders gets overwritten during boot (0xffa0 0000 segment) and in the 0x0-0x01fff ffff range so best to dump it while it sits in the bootloader ...
did u already find/implement the CRC check ? looks different then the DG one.
tized:
--- Quote from: cybernet on November 24, 2013, 01:40:34 pm ---
--- Quote from: tized on November 24, 2013, 01:24:31 pm ---Funny thing, I've just done the same for the DS2000 firmware and this is what I got:
--- Code: ---Device: DS2202
Version: 00.01.00.00.03
| No. | Size (B) | Location | Target | CRC | Type | Dev. B_A |
|-----|------------|------------|------------|----------------|------|-----------|
| 1 | 0x00378f9c | 0x00000220 | 0x20040000 | 0x27e9427e (V) | 0 | 0x00_0x01 |
| 2 | 0x0017cca8 | 0x003791bc | 0x20000000 | 0x5a3ac3c3 (V) | 6 | 0x00_0x05 |
| 3 | 0x00010f60 | 0x004f5e64 | 0x20000000 | 0x52c1a46b (V) | 2 | 0x00_0x0a |
| 4 | 0x000321aa | 0x00506dc4 | 0x20020000 | 0x6c49f38a (V) | 2 | 0x00_0x0b |
| 5 | 0x0000245a | 0x00538f6e | 0x200d6000 | 0xcd2a7325 (V) | 2 | 0x00_0x0c |
| 6 | 0x00007fb4 | 0x0053b3c8 | 0x200c8000 | 0x4cac7870 (V) | 4 | 0x00_0x0e |
| 7 | 0x000663f4 | 0x0054337c | 0x200f0000 | 0x454d5a80 (V) | 4 | 0x00_0x0f |
| 8 | 0x00001d54 | 0x005a9770 | 0x20120000 | 0xbcb8589e (V) | 2 | 0x00_0x10 |
| 9 | 0x0006dc62 | 0x005ab4c4 | 0x20000000 | 0x885a8c98 (V) | 4 | 0x00_0x11 |
| 10 | 0x000032d8 | 0x00619126 | 0x20040000 | 0xb7481d18 (V) | 3 | 0x00_0x13 |
| 11 | 0x00000b64 | 0x0061c3fe | 0x20000000 | 0xd2b695f5 (V) | 5 | 0x00_0x14 |
| 12 | 0x0003c598 | 0x0061cf62 | 0x20000c00 | 0x3f1c1bcc (V) | 5 | 0x00_0x15 |
| 13 | 0x00000118 | 0x006594fa | 0x201e4c00 | 0x1af2df9d (V) | 5 | 0x00_0x15 |
| 14 | 0x00009010 | 0x00659612 | 0x2003d400 | 0x550735a2 (V) | 5 | 0x00_0x15 |
| 15 | 0x00001661 | 0x00662622 | 0x201fd800 | 0x5161cee1 (V) | 3 | 0x00_0x15 |
| 16 | 0x000bb808 | 0x00663c83 | 0x20045000 | 0x4b530b40 (V) | 3 | 0x00_0x15 |
| 17 | 0x00046ef0 | 0x0071f48b | 0x20100000 | 0x52c4edfb (V) | 7 | 0x00_0x15 |
| 18 | 0x00000000 | 0x0076637b | 0x20122800 | 0x00000000 (V) | 2 | 0x00_0x32 |
|-----|------------|------------|------------|----------------|------|-----------|
--- End code ---
The 'Type' and 'Device' fields are not verified, just my guess. The first block is the LDR and the second is for the FPGAs.
All the 'Type' 2 blocks seem to be more application code.
--- End quote ---
nize stuff, im also looking into the DS2000 atm - but you are a step ahead as it seems.
for the DG the bootloader stream is in 0x2000 0000 - the application is in 0x2000 4000 - looking at your GEL listing, i would assume its the same with the DS2k.
the bootloaders gets overwritten during boot (0xffa0 0000 segment) and in the 0x0-0x01fff ffff range so best to dump it while it sits in the bootloader ...
did u already find/implement the CRC check ? looks different then the DG one.
--- End quote ---
Yes, I've found it strange that the target of the LDR is 0x2000_4000. Either they found no reason to change the bootloader, or one of the other blocks with the 0x2000_0000 is the bootloader. The first DXE in LDR thought loads into 0xFFA0_8000.
The CRC is standard CRC32, I just used the bzip.crc32() method (I'm coding my parser in Python), the 'V' beside each CRC means it checks OK.
The header format Rigol used in this firmware goes as follows:
--- Code: ---16 Bytes - MSB first - ASCII - Device name
16 Bytes - MSB first - ASCII - Version number
4 Bytes - LSB first - UInt - Fields per entry (Each field is 32b UInt, LSB first)
4 Bytes - LSB first - UInt - Number of entries
List of block descriptor entries, each entry with the following fields:
SIZE - Number of bytes in block
LOCATION - Offset to the block in the .GEL file
CRC - Standard CRC32
TYPE* - Some kind of type code
TARGET - Target address
CODE_A* - Looks like device code
CODE_B* - Always 0
--- End code ---
* - Fields I'm guessing about, not sure yet.
cybernet:
so far i agree only the fields per entry which is offset +0x20 according to your table .. e.g.
--- Code: ---00000000 44 53 32 32 30 32 00 00 00 00 00 00 00 00 00 00 |DS2202..........|
00000010 30 30 2e 30 30 2e 30 31 2e 30 30 2e 30 35 00 00 |00.00.01.00.05..|
00000020 [color=orange]07 00 00 00[/color] [color=red]11 00 00 00[/color] b4 3d 31 00 04 02 00 00 |.........=1.....|
--- End code ---
07 = i dont see that used in the code
i do see 0x11 = number of records in the header used - and its read in 0x1C chunks x 0x11 times (which relates to your logic) - where the 07 is used, i no clue so far.
do you work form the assembler code or by studying the file ?
loc_1FD6B0A:
R0 = [P5]; // P5 = ptr to file handle
P1 = [FP -0x8]; // P1 = ptr to file data buffer (containing first 0x28 bytes)
R2 = [P1 + 0x24];
R2 *= R7; // R7 =0x1C
CALL FILE_fread_sub_1FF0982;
[FP -0x4] = R0;
CC = (R0 == -0x1);
cybernet:
found it +0x20 is a bitmask, bit 0,1,2,3 are probed and that seems to impact the routine that parses the data chunks and writes them to flash. (loc_1FD6B50)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version