Products > Test Equipment

Rigol DSXXXX .GEL firmware file format

<< < (31/38) > >>

janekivi:
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/Spa
00000030 | 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 CRC32
without 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

bitwelder:

--- Quote from: janekivi on April 12, 2018, 09:27:37 pm ---(Probably I link to this page and I update it in the future)

--- End quote ---
As you opened the thread, perhaps you can copy the contents of this last post (or whatever 'final results' you'll have to share) to the opening post, so it doesn't get buried it in the discussion.

tv84:
Janekivi,

I propose that you use a parsing like this as a reference for your "guide", so everybody can follow the various fields involved.


--- Code: ---00000000 - File Type: DS1000Z
00000010 - Version: 00.04.04.03.02
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         00109213  00000280  AE2F3D1D  00000001  [00000280-00109492]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  00109493  679334B7  00000005  [00109493-001CD804]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001CD805  E4FDFCA9  00000006  [001CD805-00214708]  CRC OK
000000DC  /sys/logo.hex               000BB818  00214709  AC2CE5C4  0000000A  [00214709-002CFF20]  CRC OK
00000118  /sys/guiResData.hex         000B6A2C  002CFF21  EFF83A4B  0000000C  [002CFF21-0038694C]  CRC OK
00000154  /sys/guiPicData.hex         0001E6BF  0038694D  B8D72DB2  00000011  [0038694D-003A500B]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  003A500C  BAD12B30  00000010  [003A500C-00460823]  CRC OK
000001CC  /sys/SparrowWaveTable.hex   000020E8  00460824  B0445B96  0000000B  [00460824-0046290B]  CRC OK
00000208  /sys/SparrowCalFile.hex     0002329C  0046290C  FBE2BA34  0000000F  [0046290C-00485BA7]  CRC OK
00000244                              00000118  00485BA8  00000000  00000032  [00485BA8-00485CBF]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000280  A7E7BDB2  00000003  001091FB  AA5555AA  4040302     00000000  [00000298-00109492]  CRC OK
00109493  C9AF5D56  00000000  000C435A  AA5555AA  4040302     00000000  [001094AB-001CD804]  CRC OK
001CD805  138E13B9  00000000  00046EEC  AA5555AA  4040302     00000000  [001CD81D-00214708]  CRC OK
00214709  9B4EA177  00000000  000BB800  AA5555AA  4040302     00000000  [00214721-002CFF20]  CRC OK
002CFF21  D7825E44  00000000  000B6A14  AA5555AA  4040302     00000000  [002CFF39-0038694C]  CRC OK
0038694D  01873014  00000001  0001E6A7  AA5555AA  4040302     00000000  [00386965-003A500B]  CRC OK
003A500C  5DEF7058  00000000  000BB800  AA5555AA  4040302     00000000  [003A5024-00460823]  CRC OK
00460824  558BD392  00000000  000020D0  AA5555AA  4040302     00000000  [0046083C-0046290B]  CRC OK
0046290C  7717C897  00000000  00023284  AA5555AA  4040302     00000000  [00462924-00485BA7]  CRC OK
--- End code ---

I was under the impression that the software version number is constructed as this:

--- Code: ---00. - branch number
xx.00. - version number
xx.xx.00. - subversion number
etc.
--- End code ---
 
I think the fact that 0A in branch gives "old version" is because the only chars accepted are decimal numbers. Any other is converted to 0.

janekivi:
I can copy this information to the first page but probably I link in my "Gel format guide"
other people findings and work too. Like smithnerd who made footer decrypter arm
version and tv84 who is doing most of the work and probably make x86 footermaker
some day. I don't know where he finds that enthusiasm to push my near nonexistent skills
over the limit while we working on script debugging and even not having this Rigol scope himself :)

I make this longer GEL summary by sections as I test something and some previous talk
about things is in the beginning of this thread. So I make links or repeat them... I don't know yet.
Like: you can't change SparrowApp version number without changing checksum in header and you
can verify GEL file with RigolPacker from Userli. May be we have updated version from that program too.

"Like I said, who knows where we ending with this... at the end or dead end."
there is no dead end any more.

tv84:
janekivi,

I did it in response to your request and to help you in your/our quest. Thanks to you and to smithnerd! It was a learning process for all!

It's true, I don't have a Rigol but I also don't have a Siglent...   :-DD   

Soon we'll be releasing the footer checker and the magic footer version  ;) that everybody can use to make their own official SparrowAPP without CRC patch workarounds, and life goes on.

Oh, I forgot: maybe I'll look at the scope NAND contents just to have that UFFS completed checked!

The DS1000Z GEL format seems totally busted and, now, the sky is the limit.

And, konnor seems to be the right person to lead the DS1000Z new features revolution!

I'll be looking at other Rigol equipments also. Maybe this footer checking, special USB flash signature, etc is used in other RIGOL equipments.

For now, it's not necessary to share the footer source code since the magic footer will solve everyone's needs. If RIGOL upgrades the footer validation, we'll repeat the reversing or create another workaround.

You should create the GEL format guide and gather all the infos of your investigations!! And explain the downgrades, etc...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod