| 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 |
| Message Index |
| Next page |
| Previous page |