As you may assume we are working on GEL file format day and night.
And we found some weird and wonderful things there.
After taking some lessons from
tv84 I have connected IDA to the scope and now all is possible -
from top to the bottom. Things can be dangerous and destructive but some are safe to try. You will
find them after this format guide:
====================================================================
Rigol DS1000Z GEL file format:
GEL file has header, all the required update files and scrambled footer at the end.
I believe all the hex numbers are in little endian format.
====================================================================
--------------------------------------------------------------------------------------------
00000000 |
44 53 31 30 30 30 5A 00 00 00 00 00 00 00 00 00 |
DS1000Z 00000010 |
30 30 2E 30 34 2E 30 34 2E 30 33 2E 30 32 00 00 |
00.04.04.03.02 00000020 |
00 07 00 00 0A 00 00 00 |
--------------------------------------------------------------------------------------------
GEL header is starting with
model number and for this there are 16 bytes (0x00 - 0x0F).
For DS1000Z there is written DS1000Z in ASCII-ANSI.
Next 16 bytes (0x10 - 0x1F) are for
update version in ASCII-ANSI like 00.04.04.03.02
First 00 are the software branch here which is compared with last 4 bytes in SparrowApp.out
header during update.
Next 4 bytes (0x20 - 0x23) are some sort of
firmware type "bitmask" as
tv84 suggest.
So normal update has there 00 07 00 00 and updates with bootloader have there 00 0F 00 00.
0000 0111 0000 0000 - normal update file
0000 1111 0000 0000 - update file with bootloader
So there is one bit which may mark bootloader existence.
Next 4 bytes (0x24 - 0x27) are
update files count in this GEL.
Number is in hex format and 0A 00 00 00 is meaning - 10 files in this GEL. One of them is Footer which is
like control sum and not used by scope.
--------------------------------------------------------------------------------------------
00000020 |
2F 73 79 73 2F 53 70 61 |
/sys/Spa00000030 |
72 72 6F 77 41 50 50 2E 6F 75 74 00 00 00 00 00 |
rrowAPP.out 00000040 |
00 00 00 00 00 00 00 00 13 92 10 00 80 02 00 00 |
’ € 00000050 |
1D 3D 2F AE 00 00 00 00 00 00 00 00 01 00 00 00 |
=/® 00000060 |
00 00 00 00 |
--------------------------------------------------------------------------------------------
From 0x28 are coming 60 byte sections with info about every file in GEL.
First is usually app file - SparrowAPP and all of them are saved in SYS directory. So there are all names
like this first example - /sys/SparrowAPP.out in ASCII-ANSI format. For
filename may be reserved 32 bytes.
Next 4 bytes are this
file length in hex like 13 92 10 00.
Next 4 bytes are this
file beginning address in GEL from the first header byte 0x00000000.
For example 80 02 00 00 so right after last header byte because this is the first file.
Next 4 bytes are this
file CRC32 like 1D 3D 2F AE in little endian.
Next 4 + 4 bytes are
always 00 00 00 00 00 00 00 00. May be for any other use in some other
equipment firmware.
Next 4 bytes are probably
file type in hex format. App is 0x01, Logo is 0x0A, footer is 0x32.
Scope is saving files from GEL and say in messagebox what it is doing, may be it used for this.
Last 4 bytes are
00 00 00 00 again and may be buffer or reserved for any other use.
Last 60 byte info about last file is footer info. There are used only 3 fields - length, which is 0x118,
beginning and file type, which is 0x32. There is no needed filename or CRC32.
====================================================================
--------------------------------------------------------------------------------------------
00000000 |
B2 BD E7 A7 03 00 00 00 FB 91 10 00 AA 55 55 AA |
²½?§ ?‘ ?UU?00000010 |
6E A6 3D 00 00 00 00 00 |
n¦= --------------------------------------------------------------------------------------------
Files itself coming after header with their own 24 byte headers.
File headers first 4 bytes is
file CRC32 in little endian.
Next 4 bytes are
info about compression. This is probably in hex format and also bitmask.
03 00 00 00 (bitmask 0011) - if there is LZMA packed app
01 00 00 00 (bitmask 0001) - if there is LZMA packed gui data
00 00 00 00 (bitmask 0000) - if there is plain file
Next 4 bytes are
file length in little endian.
Next 4 bytes are
AA 55 55 AA - unknown.
Next 4 bytes are
software version in little endian like 6E A6 3D 00 = 4040302.
Next 4 bytes are software branch
00 00 00 00.
tv84 explanation====================================================================
Last 280 bytes of GEL is footer. Footer has its own header and footer. It contain 2 x 128 (0x80) byte parts.
--------------------------------------------------------------------------------------------
00000000 |
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 |
€ € 00000010 |
04 00 00 00 |
--------------------------------------------------------------------------------------------
First 4 bytes are
first part length 0x80
Next 4 bytes are
first part bitmask probably ?
Next 4 bytes are
second part length 0x80
Next 4 bytes are
first part bitmask probably ?
Last 4 bytes are
footer length 0x04
Footer last 4 bytes are footer footer...
--------------------------------------------------------------------------------------------
00000110 | 01 00 01 00 |
--------------------------------------------------------------------------------------------
It is in little endian and used in scope like 10001 (00010001). So this may be the processing bitmask.
One 1 is indicating you need to process one part and second 1 is indicating you need to use second
part for this. When we see it in action we can clarify it later.
Between are the two 128 byte parts which are created by complex obfuscation script.
Some day we see it in action but for now it is black box. Probably you give to it some
parameters to begin and data to scramble.
Data is
version string length,
update version in ASCII-ANSI and
SparrowAPP.out CRC32without its header.
--------------------------------------------------------------------------------------------
00000000 |
0E 30 30 2E 30 34 2E 30 34 2E 30 33 2E 30 32 B2 |
00.04.04.03.02²00000010 |
BD E7 A7 |
½?§ --------------------------------------------------------------------------------------------
I saw this during my first baby steps in jtag debugging after teammates pointed me out the right place.
After which we started footer descrambler program. I saw there some weak points and made new footer
by hand.
*****************************************************************************
That's why you need to have compressed SparrowAPP.out with the same CRC32. This can be done
by modifying this part CRC for example. GEL itself must have at least 2 files which are SparrowAPP.out
and footer. Then you have files count 2 in header but need to have all other files already in scope.
This is good for updating modified files separately. My dream of having GEL with only LOGO was
crashed...
... to be continued
So next steps with modifying GEL file and doing upgrade or downgrade we cover in following section:
*****************************************************************************
For playing with your GEL and oscilloscope:*****************************************************************************
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1478447/#msg1478447