Rigol DSXXXX .GEL firmware file format

[janekivi]

After looking inside Rigol Digital Oscilloscope firmware file (DS1000ZUpdate.GEL)
I found this not to be very complicated. There was index with file names and
all binary data in one row. This can be extracted and may be modified if we
find out all tricks of it.
We don't like to break it - we like to make it better!

There are similarities between DS1000Z to DS6000. Only DS1000Z has index
with file names, the others have similar index structure.

We had some discussion in other threads from here:
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg980793/#msg980793
but I make here new starting point and let's continue it here.
Who knows where we'll end up with this...

----------------------------------------------------------------------------------------------------------
After little pause we managed to solve GEL footer and made progress with new scope hacks.

04.08.2016 - Latest RigolPacker

15.04.2018 - More detailed updated GEL file format

15.04.2018 - GEL file modifications guide

15.04.2018 - Disassembly information, Functions, IDA scripts

21.04.2018 - Bootloader versions

[janekivi]

For unpacking DS1000Z firmware 00.04.03.02.03 I made very noprofessional script.
It extracting all files and striping header if head = 24. You can set it to 0.

But if we like to pack someting back together we must add then this header.
So what is there. Header has 24 bytes where:
4 is file crc32
4 is some file type? Packed app has 03 00 00 00, packed gui stuff have 01, other have 00 00 00 00
4 is file lenght
4 is AA 55 55 AA (something spezial ?)
4 is Firmware version FB 7E 3D 00 -> 4030203
4 is buffer 00 00 00 00 (or for future use...?)

[Danielw]

Nice work!

Maybe we could start a collaborative IDA session, I know it exists plugins for that, but I've never tried any myself.
I looked through the code and found some functions rather quick. And a lot of variables are easy to identify from printf strings.

//Daniel

[BravoV]

Thank you janekivi  , subscribed.

[RhymeMess]

I created a small python script that is a little bit less hacky. It properly decodes the header information and extracts the offset to create the correct files. Thus this works with all the DS1000Z Firmware files I tried.
DS2000 has an entirely different structure though.

After the files, there is always an 280 bytes footer I didn't yet look into...

*edit* I didn't remove the 24 bytes file header yet...

*edit2* I updated the script to strip the 24 bytes header and decompress the file if possible. AFAIK python > 3.3 is needed for decompression, it gracefully fails if decompression is not possible.

*edit3* Update here

[smithnerd]

I did some quick analysis of the footer last night.

Comparing the final 280 bytes with those of previous firmwares, some patterns emerge:

There are 5 x 32 bit integers (hex):

80 00 00 00
01 00 00 00
80 00 00 00
01 00 00 00
04 00 00 00

Then 256 bytes of data.

then a final 32 bits trailing:

01 00 01 00

Visualising the 256 bytes of data as a bitmap clearly shows that there is more entropy in the first 128 bytes.

[janekivi]

- When You strip 24 bytes header, do not cut 24 bytes from file end too.
- Actually the file without header is the right one and header making it to ... "SparrowAPP.out with header ..."
- My Python 3.4 didn't unpack anything and footer without crc is skipped as I see in script too.
  May be some plugin needed for all Pythons?

[RhymeMess]

- When You strip 24 bytes header, do not cut 24 bytes from file end too.

The length is from the GEL Header, that includes those 24 bytes. I'm pretty certain those 24 bytes have to go as well. Its not "cut from the end" but "don't extend beyond the end".

- Actually the file without header is the right one and header making it to ... "SparrowAPP.out with header ..."

I changed it to write the file without header and a "file.header" file. The 24 bytes discussion should be a lot clearer as well.

- My Python 3.4 didn't unpack anything and footer without crc is skipped as I see in script too.
  May be some plugin needed for all Pythons?

I have pyliblzma installed which is probably needed. I also fixed a problem with the decompressor only decompressing the first file...

*edit* Small modification that also writes the header file, so it should be possible to reconstruct the entire firmware from the unpacked one.
Also this is a little decrappified.

[Shock]

If you have any missing firmware versions from this list (or one shown in red) please upload or send me a link in a PM etc, preferably the original Rigol zips.

Version 00.04.03.02.03 Date 2015-10-20 (Rigol Website)
Version 00.04.03.01.05 Date 2015-06-16 (Rigol Website)
Version 00.04.03.00.01 Date 2015-05-05 (Rigol Website)
Version 00.04.02.04.07 Date 2014-12-31  (Rigol Website)
Version 00.04.02.03.00 Date 2014-10-21
Version 00.04.01.02.00 Date 2014-07-28
Version 00.04.00.00.00 Date ? (Additionally contains boot code)
Version 00.02.03.05.00 Date ?

[bitwelder]

Have you tried to have a look to the f/w upgrade files for other Rigol models, to find if there is a common pattern in the file structure and by looking at differences identify the fields related to models ID, etc. ?

[RhymeMess]

I had a quick look into some files from here and they are all different from the DS1000Z. I looked into DS2000, DS4000, DS405X and DSA800 (which even doesn't contain a .GEL file).

DS2000 and DS4000 seem to have the same file structure...

*edit* Some more cleanups and the bytes 32-36 are 0x00070000 for every firmware, except for the boot update, where it is 0x000f0000. So I changed the default folder to $Device-$Version-$UpdateType...

*edit2* Probably last coffe break before the weekend; If you have PIL (or Pillow) installed, it will create a png like smithnerd did from the last file. Also did a few more sanity & crc checks, SparrowBootloader.sb should be written correctly now...
Also it always automaticall sets the output directory to $Device-$Firmware-$Type and now allows for multiple GEL Files. So "./unpack.py *.GEL" works properly now.

[janekivi]

- When You strip 24 bytes header, do not cut 24 bytes from file end too.

The length is from the GEL Header, that includes those 24 bytes. I'm pretty certain those 24 bytes have to go as well.
Its not "cut from the end" but "don't extend beyond the end".

I was looking the output and there was length difference 24+24 bytes. From Siglent experiment I think the file is
having the header in eeprom but for us to study the file we can strip it.

But latest scripts don't unpack my DS1000Z-00.04.03.02.03. I see only 6 files.

[RhymeMess]

No Error? Can you post a log of the script?

[janekivi]

There is CRC errors with V7. If I skip crc check, the file is extracted correctly and crc is the same as in the header.
I have Python 3.4.4

[Userli]

I was able to replace the start screen image (logo.hex) by the one attached.
To do so I wrote a small Windows application.
It replaces the RGB565 data and updates the CRCs.
The device accepted to load the same FW version including the new image.

[janekivi]

And what You are thinking I was hoping to see here when started this thread : )

Only thing, Your program is very small... so there will be some dependencies.
It is written in Microsoft .NET? Not any of my computers get it to functioning.
It won't extract anything and crash, and logo button give error too: GDI+

[Userli]

The tool currently only reflects the knowledge you kindly shared and makes it easier accessible to Windows users. It requires .NET 4.5 and the most obvious bugs should be solved.
It uses the 7z SDK for decompression. I was unable to tune the parameters of the SDK such that I could compress a file again and get exactly the same as in the .GEL file.
Does anybody have an idea on how to determine the compression parameters from a compressed LZMA file?
Otherwise one could try a brute force approach by cycling over all possibilities.
Or maybe there is another LZMA implementation which does this?
I found that SparrowCalFile.hex has the wrong file sizes in the LZMA header. They are much smaller than the real sizes and the decompression fails with either of them.

[janekivi]

I'm the dumb here but how to You use this program.
I can open firmware file.
I can now see original logo. I can see the image, save it and change (to view another but ...?)
Save image is saving original and what next? No any action here, I can only view images, I close the window?
Now the import logo button is active. Pressing id does...(nothing)?
Extract files button crash the app.
Save firmware file is saving original one.

[Userli]

Looking a bit further into the 24 bytes headers of the individual files, it looks to me as if the uint32 in bytes 4 to 7 tell if the file is compressed. For all those having a valid LZMA header, bit 0 is 1 here.
The first file SparrowAPP.out has also bit 1 set. No idea why.

To change the image do as follows:
1) open firmware file
2) show logo
3) in logo window save image (as BMP)
4) modify BMP without changing it's size
5) click change image and select the changed BMP
6) on main panel import logo (this loads the image currently in the logo window into the main file data structure)
7) save firmware file
Now you should have a new .GEL file with the modified logo.

Clicking on extract files should ask you to select the directory for storing the files. Does this work?

[et328]

Clicking on extract files should ask you to select the directory for storing the files. Does this work?

Doesn't work, it asks for the extract directory and crashes after you press OK.

[Userli]

There was indeed a dependency on the LZMA executable, which I missed. I'll try to integrate it in the main code. For the time being just put the LZMA#.exe into the same directory as the main rigolpacker.exe.

[janekivi]

This is better now!
Let's step through this logo stuff too. I know the BMP and can edit it without changing its size.
800 x 480 x 3 + 54 bytes header is always 1152054 bytes. But there is no BMP, you have PNG.
Teach us too to edit this without changing its size.

[Userli]

Where do you get the .png ?
In step 3 you click the button "Save image" to save it as .bmp.

[et328]

File has .bmp extension but the actual fileformat seems to be .png

[smithnerd]

The LZMA implementation used deviates from the spec slightly, looking at the header:

Code: [Select]

5d 00 00 80 00 cc 20 3c 00 ef a7 10 00

5d is packed lc, lp, pb bits, and 00 00 80 00 (8 MiB) is the dictionary size, as expected.

The next 8 bytes should be uncompressed file size as an unsigned little-endian 64 bit integer, but it isn't. Instead it is two unsigned 32 bit little-endian integers representing:

cc 20 3c 00 (3940556 bytes) uncompressed file size
ef a7 10 00 (1091567 bytes) compressed file size

Zero out the last 4 bytes and it decompresses without issue:

Code: [Select]

5d 00 00 80 00 cc 20 3c 00 00 00 00 00


[Userli]

I tidied up the logo handling. It will now save as bmp and requires bmp as input. The new version is attached.

The LZMA header is indeed as you say except for the file SparrowCalFile.hex, where compressed and uncompressed sizes are much different from the real ones.

[boffin]

4 is AA 55 55 AA (something spezial ?)

55AA is often used to verify that memory is working it's (every other bit)
01010101
10101010

IIRC correctly IBM PC add on roms required 55AA as the 1st two bytes to signal it was a real thing (and not just random data). But that was a loooong time ago

[Fenichel]

55AA is often used to verify that memory is working it's (every other bit)
01010101
10101010

IIRC correctly IBM PC add on roms required 55AA as the 1st two bytes to signal it was a real thing (and not just random data). But that was a loooong time ago

0x55AA also used to be widely used in older graphic file formats, where the byte order used by the writing and reading machines might be unpredictably different.  I've forgotten what one was supposed to write (21930 or 43605), but whatever it was, if you read the other one back then you knew you had to byte-swap while reading the rest of the file.  In recent, tagged (TIFF-based) formats, the byte order is still the file-writer's choice, but it is the file-writer's obligation to put an indicator (0x4D4D for big-endian, 0x4949 for little-endian) as the first 16 bits of the file header.  The codes are ASCII for "II" (hinting at Intel,  little-enders) and "MM" (hinting at Motorola, big-enders).

[janekivi]

Logo customize option is working now. 
So, we can close this thread.

Of course not. This is only beginning and may be there can be done something more useful.
But be careful with next steps and think about motto there:
"We don't like to break it - we like to make it better!"
and test your idea before and have repair or undo procedures
ready so you don't have many angry "brick" owners here.

Always is good idea to remove non working files from here too. Or what you think?

[smithnerd]

SparrowCalFile.hex consists of 420 individual LZMA streams concatenated together. Each one is 604 bytes long (uncompressed). I've only decompressed a few at random, but they don't look terribly interesting.

[Userli]

@smithnerd is there any documentation on this archive format? What tool did you use to decompress it?

Edit:
Sometimes it's just too obvious. Got it.

[janekivi]

I was able to replace the start screen image (logo.hex) by the one attached.
......

I'm not a good artist but something like this is needed there 
or old BW type : )

(I was growing up with this kind of round corners TV http://mentallandscape.com/L_0249.jpg)

[smithnerd]

guiPicData.hex is a very simple format, which is easy to traverse.

A 4 byte header represents x and y dimensions for each image, followed by the RGB565 data.

uint16 x;
uint16 y;
char data[x*y*2];

So it's easy to calculate the offset of the next image. I make it 494 bitmaps in total. Once I figure out how to put headers on the data, I will post a thumbnail image.

Edit:

This seems clunky, but it works OK:

Code: [Select]

$ avconv -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s 9x9 -i image.data -f image2 -vcodec png output.png
avconv is from libav.

[janekivi]

I was trying this with logo before in windows
http://www.madox.net/blog/2011/06/06/converting-tofrom-rgb565-in-ubuntu-using-ffmpeg/
But I think Your output is something else... My 11x11 crap can't be the same
9x9 can't be the right number and what is the dimensions then for 40 00 11 00
Somehow I can make left arrow from first data if I use 32x32

[smithnerd]

what is the dimensions then for 40 00 11 00

64 x 17

My 9x9 was for a file picked at random.

It seems avconv chokes on files smaller than 8 pixels wide. RGB565 is a pain in the arse...

[janekivi]

This is better arrow : )

But let's ask from Userli, who made logo changer, what You can do with this file?
Rigol packer did make png from hex too or bmp or....

[pascal_sweden]

Here is my preferred boot screen!

[smithnerd]

I'm hacking something up in C which puts a BMP header on the data - seems the easiest solution.

[ebclr]

This may help

http://www.ti.com/lit/an/spraa74a/spraa74a.pdf

[RhymeMess]

There is CRC errors with V7. If I skip crc check, the file is extracted correctly and crc is the same as in the header.

Yeah sorry, there is some weired thing, where crc32 in python interprets the crc as a signed integer. I added the workaround to the second crc check as well... If anyone is still interested

[smithnerd]

Quick and dirty RGB565 to BMP converter.

[smithnerd]

Converting back to RGB565 is easy with this android SDK tool:

https://android.googlesource.com/platform/build/+/android-4.4.3_r1/tools/rgb2565/

together with ImageMagick:

Code: [Select]

$ convert logo.bmp rgb:- | rgb2565 > logo.raw

[BloodyCactus]

some interesting stuff here. nice work guys

[garnix]

Being a complete "noob" on this hacking - what do you think is possible beside modifying the startup-screen?

Some things I would find useful:

• Pluses -> Pulses  text change
• Help-menu: English text is sometimes almost non-understandable, could that be modified?
• Exchange some GUI elements - e.g. the WAIT button has very uneven spacing...? Or menu-icons?
• Remove all the "glass/gloss"-effects from the UI and make it more modern by replacing the underlying images?

[Userli]

I implemented the findings of smithnerd and re arranged the interface slightly.
Now the usage is more consistent: After loading the .GEL file you double click on the name of the file you're interested in.
This opens the hex code and clicking on "open content" will then decompress, show images, etc. , depending on the nature of the file.
It's iterative such that on each new panel you can again click open content to dig deeper if possible.

The new way of changing the start screen would be:
1) open firmware file
2) double click on /sys/logo.hex
3) click "show content" in new window
4) in logo window save image (as BMP)
5) modify BMP without changing it's size
6) click change image and select the changed BMP
7) save firmware file
I should maybe mention here that you use this application at your own risk.

I found that SparrowConfig.hex is the start screen image with "MSO ready"  written in addition. The tool will show it the same way as the logo file.

The aim is definitely to be able at some point to change more serious data.
The problem currently is that I didn't find a compression tool yet, which will create the same compressed form of a file as is in the .GEL.
This is necessary since the ELF file (SparrowApp.out) containing the processor code with all the typos is LZMA compressed in the .GEL .
The same holds for GuiPicData.hex, which contains all the little images the user interface is made of.

[janekivi]

Being a complete "noob" on this hacking - what do you think is possible beside modifying the startup-screen?

Some things I would find useful:

Then You must learn!

First rule is... take all apart and look inside to see how the system is working [big hammer emoticon here]
and then we see what we can do if all are coming apart. We are working with hammer right now.
Like I said, who knows where we ending with this... at the end or dead end.

[smithnerd]

The problem currently is that I didn't find a compression tool yet, which will create the same compressed form of a file as is in the .GEL.
This is necessary since the ELF file (SparrowApp.out) containing the processor code with all the typos is LZMA compressed in the .GEL .
The same holds for GuiPicData.hex, which contains all the little images the user interface is made of.

I share this concern and It's something I've been looking into.

I suspect the LZMA implementation is part of the MQX SDK used to create the firmware (Classic or v5, I couldn't say). I haven't got round to seeing what documentation or code is available on the NXP MQX pages yet.

That said, it may not be a problem. The fact that 7z's LZMA decoder can cope with their code bodes well for the opposite being true, so long as their header weirdness is respected.

[Circlotron]

Just posting so I can be notified of replies to this thread.
Go guys and gals!!! 

[BravoV]

Just fyi, quoting Borjam's post from other thread.

New firmware version!

http://int.rigol.com/Support/SoftDownload/3

Code: [Select]

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2016/05/31

[Updated Contents]
--------------------
v00.04.04.00.07  2016/07/19
     - Added the full-screen display in the XY mode
     - Modified the Trace data of average sample mode
     - Fixed the bug of system halted for wave persistance in the Zoom mode
     - Fixed bugs about Measure


Now. Who dares?

 

[Shock]

Nice finally Rigol released the whole firmware update history in the latest 00.04.04.00.07 firmware archive. If you have any of the firmware shown in red please PM or attach in a post.

v00.04.04.00.07   2016/07/19
v00.04.03.02.03   2015/10/20
v00.04.03.01.05   2015/06/16
v00.04.03.00.01   2015/05/05
v00.04.02.04.07   2014/12/31
v00.04.02.03.00   2014/10/21
v00.04.01.02.00   2014/07/28
v00.04.00.00.00   2014/03/18
v00.02.03.05.00   2014/01/27
v00.02.01.01.00   2013/10/31
v00.02.00.01.00   2013/09/02
v00.01.00.16.09   2013/08/14
v00.01.00.13.09   2013/07/25
v00.01.00.12.08   2013/07/10
v00.01.00.03.00   2013/05/21
v00.01.00.02.00   2013/05/19
v00.01.00.00.05   2013/05/19

[Userli]

Good news!
It looks like the compression is optional.
In the new FW file the file GuiResData.hex is uncompressed, whilst it was compressed in the last FW file.
It might therefore be possible to change the ELF file and add it uncompressed, circumventing the possible compression problems.

I agree with smithnerd though, that most likely it will also accept files compressed with the LZMA algorithm from 7zip.

[janekivi]

After hacking something together with notepad I get all images from latest update:
I put this file and guiPicData to somewhere and double click on ***.py and get RAW data.
This is making for me BAT file too with ffmpg convert command lines. I add to this directory
ffmpeg.exe and all required DLL files for this. You can change "ffmpeg" with something else.
PNG can changed too to something else if other parameters corrected too.
Double click on BAT is making next miracle...

Code: [Select]

import os
src_file = 'guiPicData'      #code.py and this file with data must be in the same directory
path = 'images'              #it makes new directory
if not os.path.exists(path):
    os.makedirs(path)

src_file_size = os.path.getsize(src_file)
b = bytearray(open(src_file, 'rb').read())
pos = 0
nr = 0
 
while pos < src_file_size:
x = b[pos:pos+2]
y = b[pos+2:pos+4]
num1 = int.from_bytes(x, byteorder='little', signed=False)
num2 = int.from_bytes(y, byteorder='little', signed=False)
length = num1 * num2 * 2
data = b[pos+4:pos+4+length]
pos +=4+length
nr +=1
print (length, num1, num2, pos) # for test and feedback
output = "file_%03d_%dx%d" % (nr, num1, num2)
open(os.path.join(path, output), 'wb').write(data)
text = "ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s %dx%d -i %s -f image2 -vcodec png %s.png" % (num1, num2, output, output)
# output = "file_%03d_%dx%d.bat" % (nr, num1, num2)   # uncomment if you want bat file for each RAW image
# open(output, 'w').write(text)                       # uncomment if you want bat file for each RAW image
with open(os.path.join(path, "test.bat"), "a") as myfile:
myfile.write(text+ '\n')

All images are in zip here too:

[Dwaine]

I tried to replace the logo with this new firmware.  It worked with no issue.  Nice work everyone

[Userli]

First success.
I managed to replace the RIGOL logo on the main screen. (see attachment)
To do so, I replaced the image and put the uncompressed file back.
Bit 1 in the 5th byte of the 24byte file header tells if the file needs decompression - so it needs to be cleared.

You should always reopen the file with the application after saving and check that the changes have been applied.
I added loads of consistency checks and if you find any entry in the error log, the file is most likely broken.

[janekivi]

Looks like guiResData.hex contains some data : )
First part is menu structure, some parts contains text, one part is help...

First image - Apps, Menu, Item. This part is keep going to address in red - 05 BE 08.
If there is Apps, section length is the following 4 bytes - green.
Current Menu is ending at the same address and length to there is 04 80 - blue.
Inside of the Menu is couple of Item's with their lengths - yellow.

When this part is ending (next image), there is 3 addresses for next 3 parts.
05 BE 14 - beginning of 1st
06 AF 00 - beginning of second
09 AF E0 - beginning of third

On third image we see 1st part ending, second beginning and length A1 A8
which lead us to beginning of something. That part is ending at 09 AF DF and
next we see last file with his length. From 09 AF E0 is exactly 01 BB 3C to the
file end.
Now, how to eat those parts and what's inside...

[Userli]

I guess that guiResData contains the references to the images in guiPicData.
Most likely their address and geometry is coded in there as well as the position at which they must be shown on the screen.

[Fungus]

A really nice thing to do to start with which shouldn't be too difficult is to find the version number of the GEL file and hack it.

This would allow people to downgrade their firmware by fooling the scope into thinking old versions are actually newer so they can downgrade their firmware.

[janekivi]

This is easiest trick. (In first look...)
You edit the firmware number by smallest step needed and scope say:
"A newer software version detected.
Update?
Model :DS1000Z
Version:00.04.03.02.05"
Where is the numbers. Just at the beginning. Bytes 10 .... 1F
Why smallest step? Because then  You can update it many times.
If there is too big version nr, You need always increase it ...

(Actually I didn't let it to do update at this time, so it may not be sucess, but barely)
...and that's it, he checking it in all other places too

[Userli]

Next success!
I decompressed guiPicData and compressed it again.
Then I created a new .GEL file with the newly compressed guiPicData and deployed it successfully to the scope.
Now we know that the Rigol decompression mechanism can handle files compressed by the 7z SDK.
This obviously doesn't mean, that it will always work but the probability is high that it does.

The next step will now be to change the Pluses, of which I still found two occurrences in the latest FW.

Concerning changing the version number: this is indeed easy.
You can even make it the same number as the one installed.
The scope will then ask you if you want to reinstall this version.
However, if by accident you put a number much bigger than the current one, you will have to tweak all subsequent FW files to this very version to make them install.

[smithnerd]

Next success!
I decompressed guiPicData and compressed it again.
Then I created a new .GEL file with the newly compressed guiPicData and deployed it successfully to the scope.
Now we know that the Rigol decompression mechanism can handle files compressed by the 7z SDK.
This obviously doesn't mean, that it will always work but the probability is high that it does.

The next step will now be to change the Pluses, of which I still found two occurrences in the latest FW.

Great news about LZMA. I would counsel against trying to patch SparrowAPP.out at the moment, unless you have the ability to recover via JTAG. I have reason to believe that even trivial modification of this file will brick the scope.

[Userli]

Thanks for the warning.
Would you want to share your concerns with us?

[Meka77 wd]

Hi everyone.
I just modified DS1000ZUpdate.GEL file 00.04.03.01.05 (04.03 SP1) to 00.04.03.02.03 (04.03 SP2, current installed shit)...
 
Here is what happened:

1. Same software version detected. Update?... 
2. Reading Gel file... 
3. Analysing Gel file... 
4. Update was failured. Please, check your flash driver and the update file, then try again!...

fkers.

[smithnerd]

Thanks for the warning.
Would you want to share your concerns with us?

High Assurance Boot:

http://cache.freescale.com/files/32bit/doc/app_note/AN4555.pdf

I suspect the contents of the mystery footer is a signature for SparrowAPP.out. I might be totally wrong about this though - too early to say...

[Userli]

Well, not THAT easy.
The version number is repeated in each file header as Uint32.
So all of them have to be changed, too.

I will add a mechanism to my application where you can change the version to the one of another .GEL file by opening it.
This should be reasonably safe .

[janekivi]

Files not the problem I think, so not that easy too. Something is now in the footer.

Actually I took DS1000Z(ARM)Update_00.04.03.01.05 and have DS1000Z(ARM)Update_00.04.03.02.03
Now I look footers and DS1000Z(ARM)Update_00.04.03.01.05 footer second half from 80 to FF is the
same as DS1000Z(ARM)Update_00_04_04_00_07 footer.
Somebody must look into APP. I can't read it.

[Userli]

@Meka77 wd if you open your modified file in the RigolPacker you should see one error per file stating that the version is different.
I modified the application as mentioned in the last post.
You can now click on change version, open another FW file who's version will then be copied to the current one.

I didn't try to deploy a FW file with modified version.
As before: USAGE AT YOUR OWN RISK!!!

@janekivi I didn't find the version in the footer.
I would therefore assume that it's sufficient to change it in all the headers.
When you say "Somebody must look into APP." what are you referring to?

[Meka77 wd]

Thanks for your efforts @userli...
I just tried your tool and same things happened...
Sorry no joy.
Btw. i also tried in bootloader mode (when device off, put usb stick, powerup wait untill beeps, press help button some, device reads stick, asap all leds flashing (fail to update) ) and nothing changed.

[janekivi]

When you say "Somebody must look into APP." what are you referring to?

If somebody understand IDA, this is may be helpful to help us to find out how this footer is made...
When we know how app is reading it.
Something is done here with RC5_RC6 and SHA-1.
License generator is using SHA-1 too but footer can be made with SHA-1 and RC5_RC6.
Weirdly there is 128 bytes matching older firmware footer.

I see that MD5/SHA-1 share their initial values, so there is one of them or both.
You know, one thing needs MD5...
and now - there it is: PKSC: X.509

[Userli]

@ janekivi ok, I see.
 I agree, that it will be difficult to analyze the footer without a hint from the code.

I added a very basic viewer for ELF files.
At least it shows, where the application code is.
Maybe somebody has a disassembler for this uP?

Furthermore I added checksums of the code shown, to help finding if it's referenced anywhere else.
For the footer I assumed that it also had a 24byte header.
This is not certain at all, since the structure of the first 24 bytes of the footer do not match the structure of the other file headers.
Therefore the export function now exports the footer including the first 24bytes.

Today was rather disappointing:
 I reproduced Meka77 wd's problem.  So the version is stored also somewhere else.
Furthermore I fixed the Pluses and replaced the compressed file in the archive.
This gives the same error as you get with the version change.

[janekivi]

I have seen scope on Dave's video with custom logo. One is here:
https://www.eevblog.com/forum/blog/coolest-rigol-ds1052e-firmware-ever!/
But I don't remember surely was there something more...

[Meka77 wd]

Hi.. Thanks again @userli.

For future reference:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-firmware-downgrade-*is*-possible-and-here-is-how/

As seen on above discussion reply #23 there is nothing bad happening when firmware ver. upgraded or downgraded.

But there is a catch... bootloader version!!!

Why they blocked firmware downgrade from later ver. bootloaders is beyond my imagination.

Again, i think most important! feature for this kind of devices is ability to freely upgrade or downgrade firmware or bootloader revisions.

This scope is unreliable and very frustrating to use for me since 4.3.2.3 ver. firmware.

And RMS bug is not that simple...



Please if you did not watch it, take a closer look

It affects FTT, other channels RMS measurements, Auto Cursor Quick Trace, scope performance and many other shit i am not aware of. I think there is some kind of constant background calculation or error correction scheme going on and because of it scope very slow, intensity grading performance  degraded (to me anyway).

Sorry for my bad english...

[janekivi]

For bugs is there another thread but this firmware stuff is bit complicated.
There may be different upgrade types and then corresponding files in it.
For logo we can may be make only GEL with logo.hex. But update with
app is needing footer where is public key or certificate or hashed something...

First 128 bytes is signature for example. Following 128 bytes is key or...
which  an be the same as in other firmware footer.

[Userli]

I was wondering if it could be as easy as removing the 2nd bit of the 4th byte in the file header, which is only set for SparrowApp. (assuming this indicates "requires checking", like the first bit indicates "requires decompression")
Only removing this bit doesn't have any obvious effect.
The FW still installs fine.

Fixing now the Pluses in addition, though, makes the deployment fail.

Now I just decompressed and re compressed the ELF file without changing anything (adapting the checksums obviously) and the deployment also failed.
Assuming that the newly compressed file can be decompressed by the scope, it means that the check using (most likely) information from the  footer is done on the compressed file only.

[janekivi]

We inventing a bit a our own wheel here
http://gotroot.ca/rigol/
http://gotroot.ca/rigol/degel-0.1.tar.gz
In one update there was this new bootloader: SparrowBootloader.sb
This can be sb - secure boot.
http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
x509 keys and all this kind of stuff or only name like this...

[Userli]

It's well possible that they used an existing mechanism to sign the code.
It could be as simple as signing a combination of version number and sha1 of the compressed file with the private key used for the license codes.
It might also be that they secure the boot process, this, however, would not prevent it from deploying the FW.
I would assume the corresponding code being part of the ELF file.

[janekivi]

Newly fixed (with help of our SparrowAPP) Signsrch http://aluigi.altervista.org/mytoolz.htm#signsrch
can recognize 36 signatures

Code: [Select]

  offset   num  description [bits.endian.size]
  --------------------------------------------
  400264e1 1038 padding used in hashing algorithms (0x80 0 ... 0) [..64]
  400ae1f0 1119 Jpeg dct AA&N scale factor [double.le.64]
  4014b9ec 2249 TEA1_DS [32.le.4]
  40150d70 2057 RC5 and RC6 magic values (0xb7e15163L 0x9e3779b9L) [32.le.8&]
  401ceddc 1016 MD4 digest [32.le.24&]
  401ceddc 1036 SHA1 / SHA0 / RIPEMD-160 initialization [32.le.20&]
  401ceddc 2402 Lucifer (outerbridge) DFLTKY [..16]
  401cede8 2053 RIPEMD-128 InitState [32.le.16&]
  401f372c 3048 DMC compression [32.le.16&]
  401f3dec 648  CRC-32-IEEE 802.3 [crc32.0xedb88320 lenorev 1.1024]
  401f3dec 641  CRC-32-IEEE 802.3 [crc32.0x04c11db7 le rev int_min.1024]
  401f41ec 129  Adler CRC32 (0x191b3141) [32.le.1024]
  401f45ec 131  Adler CRC32 (0x01c26a37) [32.le.1024]
  401f49ec 133  Adler CRC32 (0xb8bc6765) [32.le.1024]
  401f4dec 652  CRC-32-IEEE 802.3 [crc32.0xedb88320 benorev 1.1024]
  401f4dec 645  CRC-32-IEEE 802.3 [crc32.0x04c11db7 be rev int_min.1024]
  401f51ec 130  Adler CRC32 (0x191b3141) [32.be.1024]
  401f55ec 132  Adler CRC32 (0x01c26a37) [32.be.1024]
  401f59ec 134  Adler CRC32 (0xb8bc6765) [32.be.1024]
  401f5e69 2295 zinflate_lengthExtraBits [32.be.116]
  401f5e6c 2294 zinflate_lengthExtraBits [32.le.116]
  401f5edd 2304 zinflate_distanceExtraBits [32.be.120]
  401f5ee0 2303 zinflate_distanceExtraBits [32.le.120]
  401f64b0 1086 Zlib dist_code [..512]
  401f66b0 1087 Zlib length_code [..256]
  401f67b0 1089 Zlib base_length [32.le.116]
  401f6824 1091 Zlib base_dist [32.le.120]
  40229148 408  CRC-16-CCITT modem/x25/kermit [crc16.0x8408 lenorev 1.512]
  40229148 401  CRC-16-CCITT modem/x25/kermit [crc16.0x1021 le rev int_min.512]
  4022a1c8 1290 __popcount_tab (compression?) [..256]
  4022a2d8 2075 Generic squared map [..16]
  4022bd40 2875 libavcodec ff_mjpeg_val_ac_luminance [..162]
  4022bde4 2876 libavcodec ff_mjpeg_val_ac_chrominance [..162]
  4022c777 3051 compression algorithm seen in the game DreamKiller [32.be.12&]
  40356877 2914 libavcodec nuppelvideo fallback_lquant [..64]
  40356a6c 1994 power2 table [16.le.30]

How to read or analyze bootloader SparrowBootloader.sb in http://gotroot.ca/rigol/DS1000Z-04_00_00_00.7z

[smithnerd]

I've been looking at SparrowBootloader.sb with this:

https://github.com/eewiki/elftosb

Code: [Select]

$ ./sbtool SparrowBootloader.sb
---- Boot image header ----
Signature 1:           STMP
Signature 2:           sgtl
Format version:        1.1
Flags:                 0x0000
Image blocks:          19764
First boot tag block:  9
First boot section ID: 0x00000000
Key count:             1
Key dictionary block:  7
Header blocks:         6
Section count:         1
Section header size:   1
Timestamp:             446216079000000
Product version:       999.999.999
Component version:     999.999.999
Drive tag:             0x0000
SHA-1 digest of header:
    0x00000000: 2d 5c 14 b8 10 81 fe 5f ee e2 09 ee 75 55 fe 80
    0x00000010: bb 35 50 44
Header digest is correct.

---- Section table ----
Section 0:
    Identifier: 0x0
    Offset:     10 blocks (160 bytes)
    Length:     19752 blocks (316032 bytes)
    Flags:      0x00000001
                0x1 = ROM_SECTION_BOOTABLE

---- Key dictionary ----
error: the image is encrypted but no key was provided
It should be encrypted with AES-128, the key for which is burned into the OTP area of the i.MX28. Hopefully though, it might only be using 'encrypted boot' mode and not the 'high assurance boot' mode.

[technogeeky]

I haven't dug into this myself (I will at some point, I'm working on porting something right now for the scope).


But while digging around today, I recognized that this is an opportunity to really make the scope's help functionality useful.

I can't imagine that they would have encrypted that. We could include our own pictures, and take advantage of the multiple pages to add useful information and diagrams in.

Let me know if this is currently possible (in the sense that it will survive unpacking and repacking), and I'll get started.

[Userli]

It might be a good point to give a short summary on where we are, such that it is easier to get into this thread.

It is currently possible to change the start screen image and any of the 420 small images which are used to make up the user interface.
Rigol packer supports those changes as well as the extraction of the decompressed payload for further analysis.

Still to be done are (at least)
- the change of version (for downgrading),
- changes to the application code (mostly correcting typos in strings)

The problems seen/suspected are
- the compressed application code seems to be signed, most likely taking the version number into account
  * we suspect the signature in the first half of the footer but don't know about the mechanism used
- the boot loader might use at least secure boot


-

[MarkF]

Any chance of finding a way to swap out the small font?

[Dwaine]

Any chance of finding a way to swap out the small font?

I noticed some bmp that were fonts/characters.  Like the input keyboard.  I guess you would have to redo the bmp file with larger fonts.

[technogeeky]

Any chance of finding a way to swap out the small font?

I noticed some bmp that were fonts/characters.  Like the input keyboard.  I guess you would have to redo the bmp file with larger fonts.

This might be easier than if they were actual fonts, though. We'll see.

[Dwaine]

Any chance of finding a way to swap out the small font?

I noticed some bmp that were fonts/characters.  Like the input keyboard.  I guess you would have to redo the bmp file with larger fonts.

This might be easier than if they were actual fonts, though. We'll see.

I was kinda disappointed to see that really they are just throwing up bmp files to make up the screen.  No GUI rendering for the UI.   

I always wondered why BMP files.   Would it not be more efficient to use png files?  Smaller and less processing intensive?

 

[smithnerd]

The fonts are not in guiPicData.hex. They may be in guiResData.hex, but I doubt it. Most likely they were included in the main SparrowAPP.out encoded as 1bpp tables.

A few days ago, I looked for the bit pattern of the 'busy part' of a W or M (I forget) on the extra large font, but didn't find anything - too many false positives...

I'm sure they'll turn up as we identify more parts of the SparrowAPP.out and guiResData.hex data.

[smithnerd]

I was kinda disappointed to see that really they are just throwing up bmp files to make up the screen.  No GUI rendering for the UI.   

I always wondered why BMP files.   Would it not be more efficient to use png files?  Smaller and less processing intensive?

They're not using BMP files, they're using raw 16bpp data. I'm slapping a BMP header on them, because BMP supports that bitmap data type without a lot of extra hassle. PNG for example, does not really support 16bpp, only 8 or 24/32.

[FrozenHaxor]

I always wondered why BMP files.   Would it not be more efficient to use png files?  Smaller and less processing intensive?

Actually both formats are lossless while PNG is compressed and BMP not. So technically BMP is less demanding on computing side of things. It's sort of, closer to the roots of the machine itself so to speak.

[Dwaine]

I was kinda disappointed to see that really they are just throwing up bmp files to make up the screen.  No GUI rendering for the UI.   

I always wondered why BMP files.   Would it not be more efficient to use png files?  Smaller and less processing intensive?

They're not using BMP files, they're using raw 16bpp data. I'm slapping a BMP header on them, because BMP supports that bitmap data type without a lot of extra hassle. PNG for example, does not really support 16bpp, only 8 or 24/32.

Thanks for answering.   All this is interesting stuff.

[technogeeky]

I've been looking at SparrowBootloader.sb with this:

https://github.com/eewiki/elftosb

Code: [Select]

$ ./sbtool SparrowBootloader.sb
---- Boot image header ----
Signature 1:           STMP
Signature 2:           sgtl
Format version:        1.1
Flags:                 0x0000
Image blocks:          19764
First boot tag block:  9
First boot section ID: 0x00000000
Key count:             1
Key dictionary block:  7
Header blocks:         6
Section count:         1
Section header size:   1
Timestamp:             446216079000000
Product version:       999.999.999
Component version:     999.999.999
Drive tag:             0x0000
SHA-1 digest of header:
    0x00000000: 2d 5c 14 b8 10 81 fe 5f ee e2 09 ee 75 55 fe 80
    0x00000010: bb 35 50 44
Header digest is correct.

---- Section table ----
Section 0:
    Identifier: 0x0
    Offset:     10 blocks (160 bytes)
    Length:     19752 blocks (316032 bytes)
    Flags:      0x00000001
                0x1 = ROM_SECTION_BOOTABLE

---- Key dictionary ----
error: the image is encrypted but no key was provided
It should be encrypted with AES-128, the key for which is burned into the OTP area of the i.MX28. Hopefully though, it might only be using 'encrypted boot' mode and not the 'high assurance boot' mode.

...

Can we get a (somewhat comprehensive) list of the software you guys are using to do these searches? Or, if the software won't necessarily be available to us, a list of the techniques you're using so we can learn to do the same?

Thanks,
-tg

[MarkF]

I have generated several bmp and png files containing fonts for both Windows Direct X and OpenGL.  Not a problem if we can id the font data and format.

[Fungus]

I noticed some bmp that were fonts/characters.  Like the input keyboard.  I guess you would have to redo the bmp file with larger fonts.

You'll also have to change all the character sizes and offsets.

They might be stored separately or they might even be hard-coded in the program (in which case you'll have a hard time changing them).

I always wondered why BMP files.   Would it not be more efficient to use png files?  Smaller and less processing intensive?

Completely the opposite. PNG uses ZLIB compression so it needs a lot more RAM and resources to decompress.

Plus: BMP can use indexed colors, PNG cannot. BMP might be smaller than PNG for fonts.

Actually both formats are lossless while PNG is compressed and BMP not.

BMP has compression: https://en.wikipedia.org/wiki/BMP_file_format#Compression

[FrozenHaxor]

BMP has compression: https://en.wikipedia.org/wiki/BMP_file_format#Compression

Sure it does, that was not the point though. You'll want to avoid compression in such application to limit the amount of computing needed to be done, which would slow things down.

At the end of the day, everything has compression if you run it through those particular lossless algorithms

[smithnerd]

Has anybody dumped the memory on a 4.4.0.7 scope yet?

[Fungus]

BMP has compression: https://en.wikipedia.org/wiki/BMP_file_format#Compression

Sure it does, that was not the point though. You'll want to avoid compression in such application to limit the amount of computing needed to be done, which would slow things down.

Just keeping the facts straight.

A font on something like an oscilloscope would probably be best as a single uncompressed bitplane. BMP can do that.

[janekivi]

For entertainment I dived into DS6000 latest firmware. Header is similar but there is no file names.
Somebody must know them or they in standard order. I found familiar ones but images are in many
of them. Here is are the samples. What is DT-3033A and is it charging something?

[technogeeky]

For entertainment I dived into DS6000 latest firmware. Header is similar but there is no file names.
Somebody must know them or they in standard order. I found familiar ones but images are in many
of them. Here is are the samples. What is DT-3033A and is it charging something?

Can you post the list of tools you are using to analyze the .GEL files?

[janekivi]

File 16 is this

[janekivi]

Tools... what You need. I was using notepad and calculator all the time actually.
Sometimes I need convert or process then I make script for python (with notepad
of course). If I look firmware file in text lister (this is from Total Commander and
[F3 View] button actually what does all the magic for me)  then I look hex numbers
and calculate them in all kind of weird ways with windows calculator. Then in
Total Commander is compare tool in Files -> Compare by content... this is on images
in my previous posts. Then I use some sort of HexEdit because hex data operations
are difficult with notepad. I cut and paste to new files some data.
All other things for image process or unpack or ... I find on the way with google like
7zip and ffmpeg and for raw image opening and guessing is good to use Gimp and
IrfanView. If I stuck on something strange I google for tools to open, process, convert...

There is no standard frmware hacking tool (other than notepad and calculator).
If there is something, they are for some standard files. But anybody try to avoid these
standards to keep us away : )

[janekivi]

Yeah, interesting DS6000 files. First of them is... I don't know, app of some kind.
Text in it:
[Battery]   Installation:   Yes Consumption:    Voltage£?   Current£?   No  [Fan]   Fan1 Speed: Fan2 Speed: [Temperature]   Inlet:  Outlet:
Cryptographic verification operation has started, the certification failed!
DS1204B Rigol   RIGOL Technologies, Inc.    Screen Oscillograph Copyright (c) 2009 Rigol.

Files are all in open format and You can open DS2000, DS4000, DS6000 firmware files
and search for text - battery, temperature, PLUSE

[Dwaine]

That's interesting.  I guess maybe they had their build environment setup for some other product/device.  Then just changed that environment for the scopes?
Oh would it be so nice to have the firmware source in GITHub.  I guess we can only dream.

[smithnerd]

Tools... what You need.

I mostly just use the tools which the average linux distro provides; dd, hd (hexdump), grep, more, tail, head, strings etc. I write a few shell scripts for doing repetitive stuff (often with sed/awk). Rarely do I need to break out the C compiler.

I use Regular Expressions a lot.

binwalk is very useful for quickly identifying files within files.

A hex editor, paper, pencil and a calculator with base-n.

[Macbeth]

It's amusing to see this firmware .GEL cracking. I don't have a DSXXXX but I do have a DM3058 and its firmware is in an unencrypted format.

Much like this thread I have memory mapped lots of plain text strings, private storage for calibration data, found plenty of instances of obvious IEEE floating points. I've also found all the large and small character maps for English and Chinese characters.

I have an unhealthy reason for this, because I used Rigols Ultrasensor software and it bricked my DM3058. Long story, but I didn't trust sending it back to them for unbricking and then using Ultrasensor again and bricking it all over.

I learned how to JTAG program it myself. Now I want to use it as a testbed to learn IDA with Blackfin. But then again I keep finding something better to do! 

[laj]

I've been looking at SparrowBootloader.sb with this:

https://github.com/eewiki/elftosb

Code: [Select]

$ ./sbtool SparrowBootloader.sb
---- Boot image header ----
Signature 1:           STMP
Signature 2:           sgtl
Format version:        1.1
Flags:                 0x0000
Image blocks:          19764
First boot tag block:  9
First boot section ID: 0x00000000
Key count:             1
Key dictionary block:  7
Header blocks:         6
Section count:         1
Section header size:   1
Timestamp:             446216079000000
Product version:       999.999.999
Component version:     999.999.999
Drive tag:             0x0000
SHA-1 digest of header:
    0x00000000: 2d 5c 14 b8 10 81 fe 5f ee e2 09 ee 75 55 fe 80
    0x00000010: bb 35 50 44
Header digest is correct.

---- Section table ----
Section 0:
    Identifier: 0x0
    Offset:     10 blocks (160 bytes)
    Length:     19752 blocks (316032 bytes)
    Flags:      0x00000001
                0x1 = ROM_SECTION_BOOTABLE

---- Key dictionary ----
error: the image is encrypted but no key was provided
It should be encrypted with AES-128, the key for which is burned into the OTP area of the i.MX28. Hopefully though, it might only be using 'encrypted boot' mode and not the 'high assurance boot' mode.

Have a look at sbtool's "-z" option (Zero-Key)
 As in "sbtool -V -d -z SparrowBootloader.sb"  or "sbtool -V -d -b -x 0 -z SparrowBootloader.sb >sp.bin"

[smithnerd]

Crikey.

[janekivi]

Of course You can use all the tools available in here, made by all of us.
(Yes, I forgot paper and pencil, I'm a big paper user overall)
I compiled with C this sbtool for windows, if anyone need.
win_sbtool.zip
It is acting funny and outcome is not correct.

[laj]

Another alternative (on *nix) to sbtool from elftosb, is mxssb from uboot (at denx.de/mxssb.git)
below is a patch to let it extract the individual csf parts into raw bin dump's

[Userli]

I found that the version number in the individual file headers is not used.
One can change them without any effect.
I also exchanged the 2nd part of the footer, which was found identical in two versions by janekivi, by another one and the installation failed.
This shows that it is used when checking the file integrity.

Furthermore I managed to disassemble the ELF file in SparrowApp using Hex-Rays IDA demo.
It would be helpful to find the installation routine and maybe the integrity check.
Seeing the size of the code, this is by far not obvious.
Interesting is the string:
An older software version detected. Update?
 

[smithnerd]

The bootloader looks less daunting. It's only ~300k and it has much of the same upgrade functionality. Trouble is, the IDA demo can only read ELF files...

My current theory is that the second part of the footer is a cryptographic nonce or just an obfuscation (e.g. it gets XORed with the other half for the actual hash).

Edit:

Which is this (for 4.4.0.7):

Code: [Select]

$ hd footxor
00000000  11 5a 11 39 f5 d6 0c d7  fd 99 26 24 7b 94 7c 52  |.Z.9......&${.|R|
00000010  1a b9 17 d0 c7 19 5f f2  2d 8a d4 8e 13 2f 54 05  |......_.-..../T.|
00000020  34 fd f8 c1 a5 0c 46 3f  4d df 23 e2 da 03 00 a4  |4.....F?M.#.....|
00000030  20 15 62 9a 98 7d 14 18  0d 90 c7 9b 9b 91 9d e6  | .b..}..........|
00000040  44 6a 90 2d 77 9a 1f 2e  4c 2c 9a 35 81 aa 62 40  |Dj.-w...L,.5..b@|
00000050  ff 17 55 f3 0b 52 0c af  ed a6 98 4c e9 88 1c a9  |..U..R.....L....|
00000060  a1 d4 a0 3a 3a b1 d5 12  9f 17 dd a7 ec cf c1 1c  |...::...........|
00000070  9b 4b 54 03 bc 7f 4b 8b  76 9d 0f 6a 38 ac c1 29  |.KT...K.v..j8..)|


[janekivi]

No no no
I think first 20 bytes is header and last 4 is footer and then You have 256 bytes to play with.
Where first 128 is something and last 128 is the same in at least two firmware files.

80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
128 bytes
128 bytes
01 00 01 00

Or of course there is some other explanation...

[Userli]

I had a look at the bootloader binaries exported by sbtool.exe.
The 6 code parts are concatenated and each has the following format:
16byte header:
 - uint8 checksum
 - uint8 command type
 - uint16 flags
 - uint32 memory address
 - uint32 length
 - uint32 additional data
payload as given by length.

Looking at the 5th part, however, the length in the header says 0x49acc .
This would make that part end in the middle of a string section.
The next header starts at 0x04DFF1, which makes it more probable, that the part ends just before.
The first part shows the same: length given 0x3C, according to header position 0x40 .
Maybe a bug in sbtool?

[Userli]

I added the possibility to see the boot loader details to RigolPacker.
Furthermore you can now convert it to an ELF file, which you can then disassemble with IDA.
To do so, open the GEL file containing the bootloader.
Double click on /sys/SparrowBootloader.sb
In the new window click on "Convert to ELF"
In the next window click "save to file".
Now you can open this file in IDA.
Ignore the warning about invalid sections.

The new version is attached.

[Userli]

Cybernet refers in his post
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265156/#msg265156
several times to AD.
Does anybody know what AD stands for?

[smithnerd]

Cybernet refers in his post
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265156/#msg265156
several times to AD.
Does anybody know what AD stands for?

Analog Devices.

[janekivi]

This is a notepad tutorial time again. Maybe in another thread this time.

Let's open latest DS1000Z-00.04.04.00.07 or DS1000Z-00.04.03.01.05 update file footer and start
analyzing it. File compare is good thing, so we put both of them side by side. After scrolling them
quickly up and down we see some pattern. If we concentrate our look into it we start seeing...
OK... nothing.
Let's take hex view from one of them. So, first 20 bytes are header I think:
80 00 00 00   01 00 00 00   80 00 00 00   01 00 00 00
04 00 00 00
Then comes 128 bytes strange code:
64 29 7F D9 1A C9 9B D5 74 5C 2B 8E A3 5E 57 7A
62 DF 99 D4 BA DC 33 FE F2 37 40 E8 78 71 12 E6
10 E9 B4 B4 B5 54 17 47 73 65 9D EB 5D 4F A1 10
3E CF 7E 43 35 A9 0B A8 28 1F A3 8D 26 F2 A4 0E
44 2B 67 F0 BE E1 A3 63 CA 9F 17 56 53 32 7A F4
F8 07 7F 8C 0D 91 A7 C9 8E 99 8B 22 A9 6D 4E 0D
BE 89 A2 56 A7 58 B6 C7 99 39 48 54 91 5A 11 39
F4 D6 0C D7 7D 99 26 24 7A 94 7C 52 1E B9 17 D0
Next is another not too strange 128 bytes:
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB
C7 D3 DF EB F7 03 10 1C 28 34 40 4C 58 64 70 7C
88 94 A0 AC B8 C4 D0 DC E8 F4 00 0D 19 25 31 3D
49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
4F 79 6B 5F 53 47 3B 2F 23 17 0B FF F2 E6 DA CE
C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E
02 F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D
41 35 29 1D 11 05 F9 EC E0 D4 C8 BC B0 A4 98 8C
At the end is footer:
01 00 01 00

Today we looking at the second part here:
A3 30 20 - 30 is "0" and 20 is "space" in ASCII but what is the next row of data?
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB C7 D3 DF EB F7
03 10 1C 28 34 40 4C 58 64 70 7C 88 94 A0 AC B8 C4 D0 DC E8 F4
00 0D 19 25 31 3D 49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
If we start from 20 - add 0B - you got next, then add 0C - got next and next and next...
Next row 03 is 0103 if we add 0C to F7 and maybe 01 is added to the next, so:
now we add 0D to the 03 - got 10, then add 0C - got next and next and next...
Next row 00 is 0100 if we add 0C to F4 and maybe 01 is added to the next, so:
now we add 0D to the 00 - got 0D, then add 0C - got next and next and next...

And now what... there is 4F 79 6B
4F 79 6B 5F 53 47 3B 2F 23 17 0B
FF F2 E6 DA CE C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E 02
F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D 41 35 29 1D 11 05
F9 EC E0 D4 C8 BC B0 A4 98 8C

If we start from 79 - subtract 0E - you got next, then subtract 0C - got next and next and next...
Next row FF is right if we subtract 0C from 010B and maybe 01 is subtracted from next, so:
now we subtract 0D from the FF - got F2, then subtract 0C - got next and next and next...
Next row F6 is right if we subtract 0C from 0102 and maybe 01 is subtracted from next, so:
now we subtract 0D from to the 9C - got EC, then subtract 0C - got next and next and next...

So, half of 128 bytes next byte is 0C bigger than previous and in middle is turning
point from where next byte is 0C smaller than previous. Very hi-tech code.
(Sometimes I use excel for help and visualization... to get sharper look for hacking)

That's all. Long story, short question - what pattern is this?

[janekivi]

It reminds me something like crypted data.
In Sparrow(ARM)update_00.04.00.00.00 pattern is more visible
and the same only other updates have different step.
I rearrange the columns for You:

79 8A 99 49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
         49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
         49 FE B2 67 1C D1 85 3A EF A3 58 0D C2 76 2B E0 94
         49 FE B2 67 1C D1 85 3A EF A3
   48 4C 94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
         94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
         94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67 B2 FD 48
         94 DF 2A 76 C1 0C 58 A3 EE 39 85

[RhymeMess]

I tried to apply the same scheme to the first 128 bytes, but nothing meaningful appeared. Also subtracting 0x0c resulted in this: 

7e  53  6a  54  5c  89  71  7f  88  20  f0  22  ae  10  93  7d   ~SjT\.q.. ."...}
44  95  91  e7  d9  bc  76  a6  31  7b  76  cc  65  9e  73  33   D.....v.1{v.e.s3
c7  77  8a  cd  a0  cb  1d  d4  25  67  41  16  d9  40  2e  fd   .w......%gA..@..
e3  19  e6  2a  8d  2f  ce  d6  79  a1  b3  95  74  71  63  cf   ...*./..y...tqc.
cc  8c  d7  49  26  d2  50  00  d6  37  7f  f6  bd  d7  b3  67   ...I&.P..7.....g
a2  d6  bb  02  6f  7e  dc  7c  d6  df  29  a1  94  1b  08  10   ....o~.|..).....
e7  df  96  e6  fb  d4  a3  8a  ee  f9  35  09  7f  6d  d9  e6   ..........5..m..
3c  60  32  e9  1d  cb  3f  b0  35  69  8f  80  f3  2d  a2  8a   <`2...?.5i...-..
5a  81  e4  ff  00  00  00  00  00  00  00  00  00  00  00  00   Z...............
00  00  00  00  00  00  01  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  01  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
a2  ca  02  00  00  00  00  00  00  00  00  00  01  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  01  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  01  00  00  00  00  00  00  00  00   ................


Still not meaningfull, but the lower 128 bytes are not empty. 0x0c was chosen to zero out most of the lower half. "5a  81  e4  ff " might be a checksum¹⁾, "a2  ca  02  00" translates to 182946, but that doesn't mean anything to me... maybe I should check more footers...

*edit*
1) looking into more footers, it doesn't look like a checksum.

[RhymeMess]

Here are a few more:

Code: [Select]

DS1000Z-00.04.00.00.00-7/footer
93  9b  52  47  96  e8  8e  d5  84  37  fa  bf  c7  ba  87  5a   ..RG.....7.....Z
85  ad  f6  db  b1  7b  bd  9c  00  1c  a4  ab  69  3e  7f  1f   .....{......i>..
02  7e  b3  49  10  eb  6b  06  6d  d5  c8  64  1c  34  6d  a9   .~.I..k.m..d.4m.
9f  ad  b0  22  0d  d5  54  5d  cc  19  f2  19  30  50  6b  96   ..."..T]....0Pk.
a1  de  19  3e  3d  8d  89  c0  ae  14  d8  b9  a4  f2  a9  f4   ...>=...........
05  76  75  ea  de  ad  99  8e  af  cf  29  b9  e4  21  0e  4a   .vu.......)..!.J
46  d2  60  39  07  47  d5  3e  28  24  50  e9  fd  e3  e1  db   F.`9.G.>($P.....
5e  eb  c0  2b  6e  94  c4  21  f0  5e  3c  5f  ef  40  30  6f   ^..+n..!.^<_.@0o
ee  5d  5b  fc  01  00  01  01  01  00  01  01  00  01  01  01   .][.............
00  01  01  00  01  01  00  01  01  01  00  01  01  00  01  01   ................
01  00  01  01  00  01  01  00  01  01  01  00  01  01  00  01   ................
01  01  00  01  01  00  01  01  00  01  01  01  00  01  01  00   ................
a7  48  04  01  01  00  01  01  00  01  01  01  00  01  01  00   .H..............
01  01  01  00  01  01  00  01  01  00  01  01  01  00  01  01   ................
00  01  01  01  00  01  01  00  01  01  00  01  01  01  00  01   ................
01  00  01  01  01  00  01  01  00  01  01  00  01  01  01  00   ................

DS1000Z-00.04.01.02.00-7/footer
3d  84  28  8c  01  05  50  51  bd  72  d2  e6  98  6c  8b  38   =.(...PQ.r...l.8
8b  b7  8f  6e  fe  3b  4c  c5  60  ba  78  43  18  d9  c8  81   ...n.;L.`.xC....
08  b8  bb  8a  f0  65  9a  a4  f2  ed  e5  b3  41  bb  7b  f7   .....e......A.{.
33  42  7a  bb  77  27  3d  91  09  e8  81  02  dc  4c  7a  65   3Bz.w'=......Lze
ef  a8  e5  cb  b0  65  8d  52  0d  ee  b5  b9  9b  22  96  3e   .....e.R.....".>
d4  eb  d0  23  87  6e  46  54  22  f7  40  b0  32  4a  a9  26   ...#.nFT".@.2J.&
24  64  34  25  a9  81  f7  73  63  74  9b  3e  4d  5c  88  18   $d4%...sct.>M\..
27  4c  03  1d  9a  8e  cd  ce  4f  ea  83  85  c0  41  43  56   'L......O....ACV
a0  03  5c  00  00  00  00  00  00  00  00  00  00  00  00  00   ..\.............
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  c0  08  91  91  90  91  91  90  91  90  91  90  91  91  90   ................
6f  3e  01  00  00  00  00  00  00  00  00  00  00  00  00  00   o>..............
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  90  91  90  91  90  91  90  91  91  90  91  90  91  90   ................

DS1000Z-00.04.02.04.07-7/footer
c0  59  10  67  65  49  50  96  a6  1b  47  42  3e  2a  b5  87   .Y.geIP...GB>*..
0d  56  87  48  4b  c6  a3  76  8d  9c  ca  84  34  98  32  2a   .V.HK..v....4.2*
f0  d9  08  8f  f7  bd  18  04  04  84  49  36  7b  51  36  2b   ..........I6{Q6+
d1  5e  a3  3f  f8  96  ea  5d  61  64  53  14  24  ad  d8  50   .^.?...]adS.$..P
93  84  5e  75  ff  9a  af  76  01  30  e8  9d  4e  cc  ac  23   ..^u...v.0..N..#
0a  30  00  85  30  59  67  da  02  91  bb  a2  15  e8  03  c0   .0..0Yg.........
48  58  a2  06  84  a7  42  9d  f5  79  f7  b3  00  4b  2d  41   HX....B..y...K-A
eb  dc  a9  b8  4c  08  d7  ca  f6  73  72  dd  97  9f  7d  95   ....L....sr...}.
f6  cc  bf  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
01  00  00  01  00  00  01  00  00  00  01  00  00  01  00  00   ................
01  00  00  01  00  00  01  00  00  00  01  00  00  01  00  00   ................
01  00  00  01  00  00  00  01  00  00  01  00  00  01  00  00   ................
5a  4f  02  00  00  01  00  00  01  00  00  01  00  00  00  01   ZO..............
00  00  01  00  00  01  00  00  01  00  00  00  01  00  00  01   ................
00  00  01  00  00  01  00  00  00  01  00  00  01  00  00  01   ................
00  00  01  00  00  01  00  00  00  01  00  00  01  00  00  01   ................

DS1000Z-00.04.03.01.05-7/footer
7e  53  6a  54  5c  89  71  7f  88  20  f0  22  ae  10  93  7d   ~SjT\.q.. ."...}
44  95  91  e7  d9  bc  76  a6  31  7b  76  cc  65  9e  73  33   D.....v.1{v.e.s3
c7  77  8a  cd  a0  cb  1d  d4  25  67  41  16  d9  40  2e  fd   .w......%gA..@..
e3  19  e6  2a  8d  2f  ce  d6  79  a1  b3  95  74  71  63  cf   ...*./..y...tqc.
cc  8c  d7  49  26  d2  50  00  d6  37  7f  f6  bd  d7  b3  67   ...I&.P..7.....g
a2  d6  bb  02  6f  7e  dc  7c  d6  df  29  a1  94  1b  08  10   ....o~.|..).....
e7  df  96  e6  fb  d4  a3  8a  ee  f9  35  09  7f  6d  d9  e6   ..........5..m..
3c  60  32  e9  1d  cb  3f  b0  35  69  8f  80  f3  2d  a2  8a   <`2...?.5i...-..
5a  81  e4  ff  00  00  00  00  00  00  00  00  00  00  00  00   Z...............
00  00  00  00  00  00  01  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  01  00  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
a2  ca  02  00  00  00  00  00  00  00  00  00  01  00  00  00   ................
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  01  00  00  00  00  00  00  00  00  00  00  00  00  00   ................
00  00  00  00  00  00  00  01  00  00  00  00  00  00  00  00   ................

DS1000Z-00.04.00.00.00-15/footer
da  5a  4d  70  5c  55  15  22  b8  df  f1  ef  3b  36  ad  aa   .ZMp\U."....;6..
26  db  84  b8  5d  db  26  06  ee  af  b4  a4  2e  04  a9  35   &...].&........5
4a  98  d4  d2  5b  56  73  18  ae  d1  34  3a  24  4c  01  f1   J...[Vs...4:$L..
e9  41  df  4b  56  93  fc  ed  99  62  c5  51  b1  3a  f3  20   .A.KV....b.Q.:.
a6  69  c9  56  7d  17  2d  fd  82  6f  eb  2d  d4  53  2d  72   .i.V}.-..o.-.S-r
c7  4e  41  c4  e2  e5  5c  b0  f1  6f  cc  c3  d3  47  aa  a0   .NA...\..o...G..
40  d0  09  9f  76  8c  7f  f5  dd  5a  7a  93  a6  c9  7f  6c   @...v....Zz....l
73  fa  a3  c9  85  e9  aa  0b  9d  cb  07  80  79  1a  49  5e   s...........y.I^
31  90  f5  00  00  01  00  00  01  00  00  00  01  00  00  00   1...............
01  00  00  01  00  00  00  01  00  00  00  01  00  00  01  00   ................
00  00  01  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
00  01  00  00  01  00  00  00  01  00  00  01  00  00  00  01   ................
c0  69  01  00  00  01  00  00  00  01  00  00  01  00  00  00   .i..............
01  00  00  00  01  00  00  01  00  00  00  01  00  00  01  00   ................
00  00  01  00  00  00  01  00  00  01  00  00  00  01  00  00   ................
00  01  00  00  01  00  00  00  01  00  00  00  01  00  00  01   ................


The first 20 and last 4 bytes are always the same. The value I substracted is not and I have no real clue where to look for it. I just used the difference between bytes 160 and 161 because that kinda worked.

[Userli]

Very interesting!

Look at it like this:

Code: [Select]

A3 30 20

2B 37 43 4F
5B 67 73 7F
8B 97 A3 AF
BB C7 D3 DF
EB F7 03
         10
1C 28 34 40
4C 58 64 70
7C 88 94 A0
AC B8 C4 D0
DC E8 F4 00

0D 19 25 31
3D 49 55 61
6D 79 85 91
9D A9 B5 C1
CD D9 E5 F1
FD

4F 79

6B 5F 53 47
3B 2F 23 17
0B FF F2 E6
DA CE C2 B6
AA 9E 92 86
7A 6E 62 56
4A 3E 32 26
1A 0E 02 F6

E9 DD D1 C5
B9 AD A1 95
89 7D 71 65
59 4D 41 35
29 1D 11 05
F9

EC E0 D4 C8
BC B0 A4 98
8C

[RoGeorge]

This post is just to easily follow the subject.

[janekivi]

After reading some memory dumps thru the jtag I didn't find there anything helpful.
In one point was license code and serial number did end there with DSER. Before
was some 7 byte keys, like from RIGLOL source: 7A3E808599A525
and 46C5B8D451045C which is not from there.
I didn't find any other keys used in RIGLOL.
When it reads the SD, I saw there all my deleted files too in TOC.
During update there was full previous GEL file and next from SD card. In one point
it reads last 486 bytes from update file where at the end is 280 bytes footer.
But how it checking this footer and what's there inside I don't know yet.
Somehow the last part is having strange pattern and there are probably zeros
with 3 byte and 2 byte data. Then it can be crypted with RC5 and 8 bit buffer.
But I don't know... there are probably some more algorithms for key and data.

[smithnerd]

there are probably some more algorithms for key and data.

I've made quite a bit of progress with this. I'll try to spend a couple of hours tomorrow documenting what I've found...

[smithnerd]

I started to approach this from the other direction, by doing some bottom up reverse engineering of the OS.

We already know that SparrowAPP.out is a statically linked ELF binary containing the field upgradeable 'application' part of the scope firmware. While it is only part of the complete system, it provides some insight into how the whole system is built. Memory segments are from the ELF file:

Code: [Select]

$ readelf  -S SparrowApp.out
There are 12 section headers, starting at offset 0x3c1eec:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 3c1e40 000000 10      0   0  4
  [ 1] .shstrtab         STRTAB          00000000 3c1e40 000069 00      0   0  4
  [ 2] A1 rw             PROGBITS        00000000 000034 000040 01  AX  0   0  4
  [ 3] Absolute sections NOBITS          00007ff4 000074 000004 01  WA  0   0  1
  [ 4] Absolute sections NOBITS          00007ffc 000074 000004 01  WA  0   0  1
  [ 5] P2 zi             NOBITS          00010000 000074 0004c4 01  WA  0   0  4
  [ 6] P3 zi             NOBITS          00018000 000074 0011a0 01  WA  0   0  4
  [ 7] P4 rw             PROGBITS        40000000 000074 3c1dcc 01  AX  0   0 16
  [ 8] P5 ui             NOBITS          40600000 3c1e40 001900 01   A  0   0 32
  [ 9] P6 rw             NOBITS          40601900 3c1e40 2b9444 01  WA  0   0 32
  [10] P9 zb             NOBITS          40b00000 3c1e40 200000 01  WA  0   0 32
  [11] P8 ui             NOBITS          43ee0000 3c1e40 020000 01   A  0   0  8

(Physical RAM starts at 0x40000000)

At power up the i.MX283's ARM core (ARM926EJ-S, ISA is arm5TE) enters into the bootloader, SparrowBoot.sb, which is loaded into RAM at 0x41000000 (it's about 0x50000 long depending on version). During normal boot, the bootloader opens the NAND flash device as a UFFS filesystem, loads logo.hex and displays it. It then loads /sys/SparrowAPP.out into RAM and passes control to its entry point in segment 7 (P4 rw): 0x40293738 (according to readelf -h). The bootloader remains in RAM, but is not referenced again, so one can copy it from a RAM dump using:

Code: [Select]

$ dd if=ramdump.bin of=bootloader.bin bs=1 skip=16777216 count=327680
SparrowBoot.sb is a self-contained MQX 3.7.0 instance which contains UFFS and MFS (the native MQX FAT32 library) plus USB host support.

SparrowAPP.out is a separate MQX 3.7.0 instance which contains UFFS, MFS, RTCS (TCP/IP stack), USB host and device stack, TFS (Trivial filesystem, a RAM disk essentially), the GUI toolkit (not identified yet, possibly homegrown). libpng, zlib etc. plus the rest of the scope application code.

SparrowAPP.out was compiled using the IAR ARM compiler (one can tell from the segment names) and so is probably linked against IAR's DLIB and runtime libraries. MQX 3.7.0 does not natively support i.MX parts, so the Board Support Package (BSP) and Processor Support Package (PSP) are, most likely, provided by Embedded Access Inc:

http://embedded-access.com/products/mqx-rtos/

However, if one hunts around the NXP site, it is possible to download the MQX 3.7.0 source code (which is fairly ancient) and compile it for the nearest supported ARM part, which turns out to be a Freescale Kinetis K60 (ARM Cortex M4 core). Compiled with symbols and debug info, this can be used to identify large amounts of OS code, with a high degree of confidence. Cortex M4 is thumb only (16-bit) while SparrowAPP.out is mostly/solely arm (32-bit), so the usual signature based analysis tools wouldn't be of any help - I had to do it by hand, which was time consuming, but educational and quite good fun.

I would estimate that I've identified 75-80% of the OS code, as follows:

UFFS (100%)
TFS (100%)
MFS (95+%)
RTCS (90+%)
USB (host 90+%, device ~75%)
BSP (<10%)
PSP (<10%)
MQX (80+%*)

* Difficult to estimate, as it depends on build configuration.

I also found the MQX 3.7.0 source here (not official, but convenient to browse):

https://github.com/gxliu/MQX-3.7.0

UFFS source is available here:

https://sourceforge.net/projects/uffs/

I identified the version as 1.3.6 (the latest version), using typos and ideosynchrocies in the strings.

TFS is used to serve web content out of RAM, from the built in httpd, which is provided with RTCS. There are also strings for a 'GoAhead' Web server, which I haven't investigated yet. Similarly libpng and zlib are easy to find, but not terribly interesting or helpful.

So, what is the point of this?

Say for example, one is interested in examining how the SCPI service on tcp/5555 works. It is now a fairly easy task to search for function calls to RTCS_socket, choose one with the number 0x15b3 (5555) nearby, then follow the function calls down to the handler routine. The API details for how sockets work in RTCS are well documented. Obviously one can learn a lot about interfacing with the scope hardware from this point.

Knowing more about the filesystem is interesting, particularly calls to uffs_open(), I believe the missing MIRACL crypto API stuff is probably in one of the files in the internal flash, and most likely it is loaded and unloaded on demand. We really need to dump the flash to find out...

I've been working on firmware version 04.03.02.03, as that was current when I started. It doesn't look like anything much changed with later firmware revisions, as far as the OS is concerned. Similarly, the differences between the MQX parts of the earliest bootloader (from the .GEL) and recent ones are minimal, as far as I can tell.

I have to figure out how to share what I've done so far. As it currently stands the data is in a format which is very specific to my workflow. It would be nice to create a symbol table which could be linked back into the existing ELF file, then the free/demo version of IDA could read it directly.

I also want to investigate the DLIB, DLPP, RT and M libraries supplied with IAR. I believe it should be possible to identify any linked functions using signature techniques, but it is not as straight forward as I first assumed. It would be great to identify all the string functions in particular.

[janekivi]

RAM seems to be there like in other scopes, what about other addresses

device               start                   length
-----------------------------------------------------
RAM           0x4000 0000      0x3FF FFFF
FLASH
SD
...


At one point I see
F r e e s c a l e , I n c .   R O M   R e c o v e r y   R e c o v e r y   C o n f i g u r a t i o n
R e c o v e r y   I n t e r f a c e   3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

Enabling of DCDC failed at setting of 5VCTRL ENABLE_DCDC.  We need power down device.

But not much readable stuff, no matter if I scroll it up or down or fast or slow : (

[smithnerd]

RAM seems to be there like in other scopes, what about other addresses

device               start                   length
-----------------------------------------------------
RAM           0x4000 0000      0x3FF FFFF
FLASH
SD
...


At one point I see
F r e e s c a l e , I n c .   R O M   R e c o v e r y   R e c o v e r y   C o n f i g u r a t i o n
R e c o v e r y   I n t e r f a c e   3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0

Enabling of DCDC failed at setting of 5VCTRL ENABLE_DCDC.  We need power down device.

But not much readable stuff, no matter if I scroll it up or down or fast or slow : (

See p.125-127 of the i.MX28 Applications Processor Reference Manual:

http://www.nxp.com/assets/documents/data/en/reference-manuals/MCIMX28RM.pdf

It shows the memory map for the processor. I believe that the internal NAND flash chip is addressed via APBH DMA at 0x80004000-0x80005FFF. Not sure what you mean by SD.

Data transfers to/from NAND flash are done with the AHB-to-APBH Bridge. I have mapped some of that stuff out while looking through the BSP/PSP code. <- edit: DCP just provides an efficient memcpy function.

[smithnerd]

Interestingly, the DCP (see ch.13) also has a memory blitting capability, which is used extensively for drawing bitmaps to the frame buffer. I discovered this while looking to see if the firmware uses the DCP's hardware crypto features - it doesn't, at least not in SparrowAPP.out.

400E0800 raster_blit
400CF644 start_dcp_blit

[janekivi]

There is 90 MB internal memory. How it accessing this?

So far I only found from memory dumps how to generate trial keys for DS1000Z
with http://www.gotroot.ca/rigol/riglol/
For this you can use V for first option character like
VSER for all options 36 hours trial key

[frozenfrogz]

I know it is usually bad practice to play necromancer and resurrect an old thread, but since this has so much useful information I hope you don’t mind

First of all: Thanks for the OS X and Windows firmware unpacking tools!
I could find some entry points with IDA, but this is so much more convenient and I am glad I found this thread!

Can you tell me how to correctly uncompress the SparrowAPP.out file? I have been poking at it with 7zip under W7 as mentioned in this thread plus binutils under OS X.
7zip will unpack most of the file, but quits with unexpected EOF.
When using binutils

Code: [Select]

greadelf -S SparrowAPP.out it tells me: Error: Not an ELF file - it has the wrong magic bytes at the start

My uncompressed SparrowApp.out (00.04.04.03.02) header:

Code: [Select]

HEX: 7F454C46 01010100
ASCII: ELF



lzma -d does not recognize the compressed file and since the uncompressed file looks pretty sane, I thought it might be possible to just manually fix the header with the hex editor.
Any pointers are welcome, since I do not know much about how ELF works and what binutils expects to see in the header.

Kind regards,
Frederik

[ankerwolf]

Hello Frederik,
two days ago I used unpack8.zip and got following output:

Code: [Select]

D:\#\#__Rigol\Batronix_SW&Doku\Tools\GEL_Unpack8>python unpack.py ds.gel
instrument series:      DS1000Z
firmware version:       00.04.04.03.02
updateType:     0x00070000
found 10 files

{'filename': '/sys/SparrowAPP.out', 'type': 1, 'start': 640, 'length': 1085971, 'crc': 2922331421, 'unknown': (0, 0, 0)}{'filename': '/sys/SparrowFPGA.hex', 'type': 5, 'start': 1086611, 'length': 803698, 'crc': 1737700535, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowDGFPGA.hex', 'type': 6, 'start': 1890309, 'length': 290564, 'crc': 3841850537, 'unknown': (0, 0, 0)}
{'filename': '/sys/logo.hex', 'type': 10, 'start': 2180873, 'length': 768024, 'crc': 2888623556, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiResData.hex', 'type': 12, 'start': 2948897, 'length': 748076, 'crc': 4026022475, 'unknown': (0, 0, 0)}
{'filename': '/sys/guiPicData.hex', 'type': 17, 'start': 3696973, 'length': 124607, 'crc': 3101109682, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowConfig.hex', 'type': 16, 'start': 3821580, 'length': 768024, 'crc': 3134270256, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowWaveTable.hex', 'type': 11, 'start': 4589604, 'length': 8424, 'crc': 2957269910, 'unknown': (0, 0, 0)}
{'filename': '/sys/SparrowCalFile.hex', 'type': 15, 'start': 4598028, 'length': 144028, 'crc': 4225940020, 'unknown': (0, 0, 0)}
{'filename': '', 'type': 50, 'start': 4742056, 'length': 280, 'crc': 0, 'unknown': (0, 0, 0)}
writing /header  (640 bytes)
writing /sys/SparrowAPP.out.header       (24 bytes)
writing /sys/SparrowAPP.out      (1085947 bytes)
writing /sys/SparrowAPP.out.decompressed         (3934197 bytes)
writing /sys/SparrowFPGA.hex.header      (24 bytes)
writing /sys/SparrowFPGA.hex     (803674 bytes)
writing /sys/SparrowDGFPGA.hex.header    (24 bytes)
writing /sys/SparrowDGFPGA.hex   (290540 bytes)
writing /sys/logo.hex.header     (24 bytes)
writing /sys/logo.hex    (768000 bytes)
writing /sys/guiResData.hex.header       (24 bytes)
writing /sys/guiResData.hex      (748052 bytes)
writing /sys/guiPicData.hex.header       (24 bytes)
writing /sys/guiPicData.hex      (124583 bytes)
writing /sys/guiPicData.hex.decompressed         (4031460 bytes)
writing /sys/SparrowConfig.hex.header    (24 bytes)
writing /sys/SparrowConfig.hex   (768000 bytes)
writing /sys/SparrowWaveTable.hex.header         (24 bytes)
writing /sys/SparrowWaveTable.hex        (8400 bytes)
writing /sys/SparrowCalFile.hex.header   (24 bytes)
writing /sys/SparrowCalFile.hex  (144004 bytes)
Corrupt input data
CRC mismatch: '' (0x00000000 vs 0x6ad11bae)
writing /footer  (280 bytes)

original filesize:      4742336
bytes processed:        4742336

There is SparrowAPP.out.decompressed ! It is a ELF-file.
But there are so many errors in the html- and css-files - I extracted - from this file.

From the Python script unpack.py file SparrowAPP.out.decompressed contains the Web-interface for the DS1000Z series. The html pages can be found, containing very many errors: there are incorrect characters -  unmotivated but in places with system. Also, one web page is 4 times slightly different included.  It is unclear where this error come from. From the GEL file probably not, because it is used to update. It may be but that the developers intentionally have infilled such errors to hide their work. After all of the html files including the .css were prepared so that they corresponded to the orignal of the Scope. Not found, where is the Access query for the Web Settings page. None of this is to find in the html files. (Microsoft Translator)

LG Wolfgang

[frozenfrogz]

Thanks for your quick answer Wolfgang,

curiously I am getting different results and no decompressed files.

Code: [Select]

python unpack.py DS1000ZUpdate.GEL
instrument series: DS1000Z
firmware version: 00.04.04.03.02
updateType: 0x00070000
found 10 files

{'start': 640, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowAPP.out', 'crc': 2922331421, 'length': 1085971, 'type': 1}
{'start': 1086611, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowFPGA.hex', 'crc': 1737700535, 'length': 803698, 'type': 5}
{'start': 1890309, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowDGFPGA.hex', 'crc': 3841850537, 'length': 290564, 'type': 6}
{'start': 2180873, 'unknown': (0, 0, 0), 'filename': '/sys/logo.hex', 'crc': 2888623556, 'length': 768024, 'type': 10}
{'start': 2948897, 'unknown': (0, 0, 0), 'filename': '/sys/guiResData.hex', 'crc': 4026022475, 'length': 748076, 'type': 12}
{'start': 3696973, 'unknown': (0, 0, 0), 'filename': '/sys/guiPicData.hex', 'crc': 3101109682, 'length': 124607, 'type': 17}
{'start': 3821580, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowConfig.hex', 'crc': 3134270256, 'length': 768024, 'type': 16}
{'start': 4589604, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowWaveTable.hex', 'crc': 2957269910, 'length': 8424, 'type': 11}
{'start': 4598028, 'unknown': (0, 0, 0), 'filename': '/sys/SparrowCalFile.hex', 'crc': 4225940020, 'length': 144028, 'type': 15}
{'start': 4742056, 'unknown': (0, 0, 0), 'filename': '', 'crc': 0, 'length': 280, 'type': 50}
writing /header (640 bytes)
writing /sys/SparrowAPP.out.header (24 bytes)
writing /sys/SparrowAPP.out (1085947 bytes)
writing /sys/SparrowFPGA.hex.header (24 bytes)
writing /sys/SparrowFPGA.hex (803674 bytes)
writing /sys/SparrowDGFPGA.hex.header (24 bytes)
writing /sys/SparrowDGFPGA.hex (290540 bytes)
writing /sys/logo.hex.header (24 bytes)
writing /sys/logo.hex (768000 bytes)
writing /sys/guiResData.hex.header (24 bytes)
writing /sys/guiResData.hex (748052 bytes)
writing /sys/guiPicData.hex.header (24 bytes)
writing /sys/guiPicData.hex (124583 bytes)
writing /sys/SparrowConfig.hex.header (24 bytes)
writing /sys/SparrowConfig.hex (768000 bytes)
writing /sys/SparrowWaveTable.hex.header (24 bytes)
writing /sys/SparrowWaveTable.hex (8400 bytes)
writing /sys/SparrowCalFile.hex.header (24 bytes)
writing /sys/SparrowCalFile.hex (144004 bytes)
CRC mismatch: '' (0x00000000 vs 0x6ad11bae)
writing /footer (280 bytes)

original filesize: 4742336
bytes processed: 4742336

It throws a CRC mismatch every time that I did not notice before. I downloaded the firmware zip archives from both rigol sources again, but the CRC mismatch won’t resolve.

The .GEL files from the two different archives have the same checksum: MD5 (DS1000ZUpdate.GEL) = 367ae75bed8864bf168f3afd63de835c

Edit: This is with the script from unpack8.zip

[ankerwolf]

Hallo,
merkwürdig ist das schon ...

Here are the unpack.py I used and the corrected html and css files.
I used Python 3.6.1 !!!

Same SparrowAPP.out.decompressed by use of 7-Zip from the compressed SparrowAPP.out !

LG Wolfgang

[frozenfrogz]

Well, well. I used Python 2.7.10 before.
Now using python 3.5.2 the unpack script gets me two additional decompressed files.

Thanks for pointing to that

[janekivi]

Good timing.
Since last week I tried to get some life to this project and got others interested too.
Right now we looking at SparrowBootloader.sb and think about procedures used
for making this and how scope decrypt the header and keys and footers there.
https://www.rockbox.org/wiki/SbFileFormat.
May not be related to our problem with footer, but interesting anyway.

[tv84]

Complementing janekivi and resuming all that has been done in this thread regarding the SparrowBootloader.sb, I include a verbosed parsing which may be clearer for all:

(I kept the offsets of the original .GEL file)

Code: [Select]

         ***  Header  ***
0020A36A          Header SHA-1: 2D5C14B81081FE5FEEE209EE7555FE80BB355044  [0020A37E-0020A3C9]  HASH OK
0020A37E           Signature 1: STMP  MAGIC OK
0020A382        Format Version: 1.1
0020A384                 Flags: 0x0000
0020A386        # Image Blocks: 19764 (16-byte blocks)
0020A38A   1st Boot Tag Offset: 0x0020A3FA
0020A38E   1st Boot section ID: 00000000 (always 0?)
0020A392     # Encryption Keys: 1
0020A394  Key Dictionary Start: 0x0020A3DA
0020A396           Header Size: 96 bytes
0020A398     # Section Headers: 1
0020A39A   Section Header Size: 16 bytes
0020A39C        Random Padding: 0x1C1A
0020A39E           Signature 2: sgtl  (Sigmatel??)
0020A3A2         Creation Time: 20-02-2014 12:54:39
0020A3AA       Product Version: 999.999.999
0020A3B6     Component Version: 999.999.999
0020A3C2             Drive Tag: 0x0000
0020A3C4        Random Padding: 0x288304AC14A7
         ***  Sections Table  ***
0020A3CA  Nam:        | Ofs: 0020A40A | Len: 0004D280 | Flg: 00000001 - ROM_SECTION_BOOTABLE
         ***  Key Dictionary  ***
0020A3DA  OTP Key0 Hash: 17D92922DDECBF7016BB6418BD05117B  CBC-MAC_AES OK
         ***  Session Key (decrypted)  ***
0020A3EA  Key: 9FE8304CBFD7B77CC666CD98DEBD6907  (using OTP Key0)
         ***  Sections (decrypted)  ***
0020A3FA  TAG  | 0001 | Section #0    | Len: 0004D280 | Flg: 00000001 - ROM_SECTION_BOOTABLE
0020A40A  LOAD | 0000 | Adr: 00000000 | Len: 0000003C | CRC: ADAACBC2  CRC OK
0020A45A  LOAD | 0000 | Adr: 00000400 | Len: 00003624 | CRC: F12B0754  CRC OK
0020DA9A  FILL | 0000 | Adr: 00018000 | Len: 00000960 | Ptn: 00000000
0020DAAA  LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: 1647D5F7  CRC OK
0020DADA  CALL | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
0020DAEA  LOAD | 0000 | Adr: 00000000 | Len: 00000040 | CRC: 7C950527  CRC OK
0020DB3A  LOAD | 0000 | Adr: 41000000 | Len: 00049ACC | CRC: F8242826  CRC OK
0025761A  FILL | 0000 | Adr: 41300000 | Len: 00001900 | Ptn: 00000000
0025762A  FILL | 0000 | Adr: 41301900 | Len: 000031E4 | Ptn: 00000000
0025763A  FILL | 0000 | Adr: 41900000 | Len: 00300000 | Ptn: 00000000
0025764A  LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: 7EE0BD03  CRC OK
0025767A  JUMP | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
         ***  File SHA-1 Hash (decrypted)  ***
0025768A  File SHA-1: FE615733935D9724A622BE3BAE285552F01297F1  [0020A36A-00257689]  HASH OK

[tv84]

Janekivi,

Here is a decoding of the last 128 bytes of the "footer" for the new bootloader. It's not a bullet-proof theory but...

Following the parsing of the files, there is the 280 (0x118) bytes of the footer 20+256+4. What is decoded (on the bottom of each file) is the 256-bytes zone.

Code: [Select]

F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_00_00_00\Sparrow(ARM)update_00.04.00.00.00\DS1000ZUpdate.GEL  /  CRC32: 35890A7B
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.00.00.00
00000020 - Bitmask: 00000700
00000024 - # Sections: 7
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         000FEEEC  000001CC  2B9CC8DC  00000001  [000001CC-000FF0B7]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  000FF0B8  E11B7BE0  00000005  [000FF0B8-001C3429]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001C342A  718FD66C  00000006  [001C342A-0020A32D]  CRC OK
000000DC  /sys/logo.hex               000BB818  0020A32E  ABE15C88  0000000A  [0020A32E-002C5B45]  CRC OK
00000118  /sys/guiResData.hex         0001A705  002C5B46  7656E54D  0000000C  [002C5B46-002E024A]  CRC OK
00000154  /sys/guiPicData.hex         0001CAB6  002E024B  D8202F6D  00000011  [002E024B-002FCD00]  CRC OK
00000190                              00000118  002FCD01  00000000  00000032  [002FCD01-002FCE18]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
000001CC  EEAB61BE  00000003  000FEED4  AA5555AA  4000000     00000000  [000001E4-000FF0B7]  CRC OK
000FF0B8  841B75C9  00000000  000C435A  AA5555AA  4000000     00000000  [000FF0D0-001C3429]  CRC OK
001C342A  138E13B9  00000000  00046EEC  AA5555AA  4000000     00000000  [001C3442-0020A32D]  CRC OK
0020A32E  9B4EA177  00000000  000BB800  AA5555AA  4000000     00000000  [0020A346-002C5B45]  CRC OK
002C5B46  484AD786  00000001  0001A6ED  AA5555AA  4000000     00000000  [002C5B5E-002E024A]  CRC OK
002E024B  B81261EA  00000001  0001CA9E  AA5555AA  4000000     00000000  [002E0263-002FCD00]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
002FCD15
47 96 9C 97 E1 7D BF 48 80 6B 19 8C 07 75 B0 BE
F7 58 02 91 F6 25 96 E6 9A 6A C2 21 3E 30 63 36
EC 1E 85 82 46 E5 04 BE DF 68 E4 FC CC B4 D5 32
85 E6 4A 20 E1 6A 72 83 03 D0 76 43 27 2B 4A 94
3F AD E0 EE FD BC 7F 0B A9 E1 55 E8 90 EA 8D E5
2C 02 D9 3B A9 48 FB B9 56 D3 F6 89 F1 1C 5A 5C
62 DC C8 DB 20 25 9C AA CE F6 F2 55 A4 0D 78 E9
D7 38 C4 E5 C3 7B 03 2E 8A 78 88 75 D2 DE FA D7
79 8A 99 49 FE B2 67 1C D1 85 3A EF A3 58 0D C2
76 2B E0 94 49 FE B2 67 1C D1 85 3A EF A3 58 0D
C2 76 2B E0 94 49 FE B2 67 1C D1 85 3A EF A3 58
0D C2 76 2B E0 94 49 FE B2 67 1C D1 85 3A EF A3
48 4C 94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B 67
B2 FD 48 94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0 1B
67 B2 FD 48 94 DF 2A 76 C1 0C 58 A3 EE 39 85 D0
1B 67 B2 FD 48 94 DF 2A 76 C1 0C 58 A3 EE 39 85
01 00 01 00
b = B4
2B C5 17 5D F2 DA 67 3B BE F5 EE AC 73 2C B2 0C
90 3C 31 0C BC 36 F3 8E 8D A8 4C F6 5E 9C 1A 38
3A B7 69 B1 C1 AB 15 1B 87 5B 22 86 A1 D4 41 E9
87 34 E3 04 10 E5 38 94 60 78 69 81 B1 00 6A 00
EF 12 FA BD 80 F4 6C AC FF EC 15 5C B9 C8 1F 2C
28 B2 3E 55 78 CB 33 A6 F7 29 01 49 65 45 38 EE
A9 D8 78 40 3A F4 1F E2 BB 97 48 60 64 81 A1 C7
69 7F C0 95 28 95 D2 B1 C2 65 29 CB DD 9E 6E 00
4E AA 05 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4B 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_00_00_00\Sparrow(Boot)update_00.04.00.00.00\DS1000ZUpdate.GEL  /  CRC32: ED3A19F6
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.00.00.00
00000020 - Bitmask: 00000F00
00000024 - # Sections: 8
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         000FEEEC  00000208  2B9CC8DC  00000001  [00000208-000FF0F3]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  000FF0F4  E11B7BE0  00000005  [000FF0F4-001C3465]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001C3466  718FD66C  00000006  [001C3466-0020A369]  CRC OK
000000DC  /sys/SparrowBootloader.sb   0004D340  0020A36A  36829BEE  00000008  [0020A36A-002576A9]  CRC OK
00000118  /sys/logo.hex               000BB818  002576AA  ABE15C88  0000000A  [002576AA-00312EC1]  CRC OK
00000154  /sys/guiResData.hex         0001A705  00312EC2  7656E54D  0000000C  [00312EC2-0032D5C6]  CRC OK
00000190  /sys/guiPicData.hex         0001CAB6  0032D5C7  D8202F6D  00000011  [0032D5C7-0034A07C]  CRC OK
000001CC                              00000118  0034A07D  00000000  00000032  [0034A07D-0034A194]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000208  EEAB61BE  00000003  000FEED4  AA5555AA  4000000     00000000  [00000220-000FF0F3]  CRC OK
000FF0F4  841B75C9  00000000  000C435A  AA5555AA  4000000     00000000  [000FF10C-001C3465]  CRC OK
001C3466  138E13B9  00000000  00046EEC  AA5555AA  4000000     00000000  [001C347E-0020A369]  CRC OK
0020A36A  --------  --------  --------  --------  ----------  --------  [0020A36A-002576A9]
         ***  Bootloader Header  ***
0020A36A          Header SHA-1: 2D5C14B81081FE5FEEE209EE7555FE80BB355044  [0020A37E-0020A3C9]  HASH OK
0020A37E           Signature 1: STMP  MAGIC OK
0020A382        Format Version: 1.1
0020A384                 Flags: 0x0000
0020A386            Image Size: 0004D340
0020A38A   1st Boot Tag Offset: 0020A3FA
0020A38E   1st Boot Section ID:
0020A392     # Encryption Keys: 1
0020A394  Key Dictionary Start: 0020A3DA
0020A396           Header Size: 00000060
0020A398     # Section Headers: 1
0020A39A   Section Header Size: 16 bytes
0020A39C        Random Padding: 0x1C1A
0020A39E           Signature 2: sgtl  (Sigmatel?)
0020A3A2         Creation Time: 20-02-2014 12:54:39
0020A3AA       Product Version: 999.999.999
0020A3B6     Component Version: 999.999.999
0020A3C2             Drive Tag: 0x0000
0020A3C4        Random Padding: 0x288304AC14A7
         ***  Sections Table  ***
0020A3CA   ID:      | Ofs: 0020A40A | Len: 0004D280 | Flg: 00000001 - ROM_SECTION_BOOTABLE
         ***  Key Dictionary  ***
0020A3DA  OTP Key0 Hash: 17D92922DDECBF7016BB6418BD05117B  CBC-MAC_AES OK
         ***  Session Key (decrypted)  ***
0020A3EA  Key: 9FE8304CBFD7B77CC666CD98DEBD6907  (using OTP Key0)
         ***  Sections (decrypted)  ***
0020A3FA  TAG  | 0001 | Sect ID:      | Len: 0004D280 | Flg: 00000001 - ROM_SECTION_BOOTABLE
0020A40A  LOAD | 0000 | Adr: 00000000 | Len: 0000003C | CRC: ADAACBC2  CRC OK
0020A45A  LOAD | 0000 | Adr: 00000400 | Len: 00003624 | CRC: F12B0754  CRC OK
0020DA9A  FILL | 0000 | Adr: 00018000 | Len: 00000960 | Ptn: 00000000
0020DAAA  LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: 1647D5F7  CRC OK
0020DADA  CALL | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
0020DAEA  LOAD | 0000 | Adr: 00000000 | Len: 00000040 | CRC: 7C950527  CRC OK
0020DB3A  LOAD | 0000 | Adr: 41000000 | Len: 00049ACC | CRC: F8242826  CRC OK
0025761A  FILL | 0000 | Adr: 41300000 | Len: 00001900 | Ptn: 00000000
0025762A  FILL | 0000 | Adr: 41301900 | Len: 000031E4 | Ptn: 00000000
0025763A  FILL | 0000 | Adr: 41900000 | Len: 00300000 | Ptn: 00000000
0025764A  LOAD | 0000 | Adr: 00008000 | Len: 00000020 | CRC: 7EE0BD03  CRC OK
0025767A  JUMP | 0001 | Adr: 00008000 | Len: 00000000 | Arg: 00000000
         ***  File SHA-1 Hash (decrypted)  ***
0025768A  File SHA-1: FE615733935D9724A622BE3BAE285552F01297F1  [0020A36A-00257689]  HASH OK
  Block Processed OK
002576AA  9B4EA177  00000000  000BB800  AA5555AA  4000000     00000000  [002576C2-00312EC1]  CRC OK
00312EC2  484AD786  00000001  0001A6ED  AA5555AA  4000000     00000000  [00312EDA-0032D5C6]  CRC OK
0032D5C7  B81261EA  00000001  0001CA9E  AA5555AA  4000000     00000000  [0032D5DF-0034A07C]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
0034A091
20 C0 53 09 AB 46 A1 09 07 2C 63 98 19 95 88 78
E4 05 CF CD 70 91 FD 49 7D 72 6C 56 CA 14 03 7E
0E EC 06 1E BF 5B 14 72 66 7D F7 77 E1 73 BA F1
20 A7 CC 5D F9 D2 14 47 26 CE D9 70 67 E7 20 86
9A EB DC 40 7D 20 AD 6A A2 ED BC 49 2F 96 23 6B
5E CA 43 39 11 E6 44 4E 17 62 50 47 2E A1 B1 CB
45 2F E0 FB 3F 6D A8 6D 4A AA EA 11 25 16 51 9F
E6 A6 BD AE E3 B4 C4 73 90 7F 32 6C AD 4D BE 1A
91 67 A2 E8 2E 75 BB 01 48 8E D4 1A 61 A7 ED 33
7A C0 06 4D 93 D9 1F 66 AC F2 38 7F C5 0B 52 98
DE 24 6B B1 F7 3D 84 CA 10 57 9D E3 29 70 B6 FC
42 89 CF 15 5C A2 E8 2E 75 BB 01 48 8E D4 1A 61
5B AC 65 1F D9 92 4C 06 C0 79 33 ED A6 60 1A D4
8D 47 01 BB 74 2E E8 A1 5B 15 CF 88 42 FC B5 6F
29 E3 9C 56 10 CA 83 3D F7 B0 6A 24 DE 97 51 0B
C5 7E 38 F2 AB 65 1F D9 92 4C 06 C0 79 33 ED A6
01 00 01 00
b = 46
E6 3F 8C FC 57 AC C1 E3 9A 79 6A 59 93 C9 76 1F
45 20 A4 5B B8 93 B9 BE AC 5B 0E B2 E0 E4 8C C1
0B A2 76 48 A3 F8 6B 83 31 01 35 6F 92 DE DF D0
B8 F9 D8 23 78 0B 07 F3 8C EE B3 03 B4 EE E1 00
35 CC 03 AE 31 1A ED F1 6F 00 16 E9 15 C2 96 24
5D 0F CF 0B 29 45 E9 39 48 DA 0E 4B 79 32 88 E8
A9 D9 D0 31 BC 30 B1 BD E0 86 0C 7A D4 0B 8C 21
AE B4 12 49 C4 DB 32 27 8A BF B9 39 C0 A7 5E 00
7C 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
69 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_01_02_00\DS1000ZUpdate.00.04.01.02.00.GEL  /  CRC32: A75B1AAA
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.01.02.00
00000020 - Bitmask: 00000700
00000024 - # Sections: 7
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         0010239F  000001CC  F06D803B  00000001  [000001CC-0010256A]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  0010256B  C1FDC842  00000005  [0010256B-001C68DC]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001C68DD  ED3B7B31  00000006  [001C68DD-0020D7E0]  CRC OK
000000DC  /sys/logo.hex               000BB818  0020D7E1  1E04D14A  0000000A  [0020D7E1-002C8FF8]  CRC OK
00000118  /sys/guiResData.hex         0001E475  002C8FF9  10AA5AE2  0000000C  [002C8FF9-002E746D]  CRC OK
00000154  /sys/guiPicData.hex         0001C782  002E746E  B7C02498  00000011  [002E746E-00303BEF]  CRC OK
00000190                              00000118  00303BF0  00000000  00000032  [00303BF0-00303D07]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
000001CC  C2B9DDD5  00000003  00102387  AA5555AA  4010200     00000000  [000001E4-0010256A]  CRC OK
0010256B  841B75C9  00000000  000C435A  AA5555AA  4010200     00000000  [00102583-001C68DC]  CRC OK
001C68DD  138E13B9  00000000  00046EEC  AA5555AA  4010200     00000000  [001C68F5-0020D7E0]  CRC OK
0020D7E1  9B4EA177  00000000  000BB800  AA5555AA  4010200     00000000  [0020D7F9-002C8FF8]  CRC OK
002C8FF9  7E7781CF  00000001  0001E45D  AA5555AA  4010200     00000000  [002C9011-002E746D]  CRC OK
002E746E  566E7022  00000001  0001C76A  AA5555AA  4010200     00000000  [002E7486-00303BEF]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
00303C04
3D C1 E9 75 76 7B CB 1C D9 4B 1D 03 9B 07 92 CA
55 0C 9B 09 07 42 8E 53 B3 6D E5 28 40 19 E1 62
6A 22 DD 67 57 BC 56 FA EC D9 BE 71 B2 6D E8 DF
12 54 CE 89 00 27 64 F5 FE E6 67 69 45 91 0B 70
81 D9 F4 29 79 14 87 35 28 3A 85 CC 31 0F 79 3B
67 7C AC 89 02 94 4E FA D8 E1 A1 F1 BF 75 CC A6
82 1E EA C5 1C 9B A4 31 CE 5A BF 81 34 D8 50 38
11 C5 C2 A5 0B 7D B0 E2 93 A9 26 A1 E1 A0 5D 07
A7 AA 06 06 06 06 06 06 06 06 06 06 06 06 06 06
06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06
06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06
06 C6 CE 5F F0 80 11 A2 32 C3 53 E4 74 05 96 26
B7 79 78 78 78 78 78 78 78 78 78 78 78 78 78 78
78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78
78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78
78 78 E8 57 C7 36 A6 15 85 F4 63 D3 42 B2 21 91
01 00 01 00
b = 90
60 54 EB E7 57 CB 8B 4B 78 59 9B F0 F7 D3 CD 75
6F 96 94 71 DF 89 45 79 49 72 5A 0C 93 DC 13 04
7B A3 CD C6 26 FA 04 17 79 D5 29 4C FC 27 11 78
1A CC B5 DF C6 5C 09 09 82 D9 C9 3B 86 42 2B 00
E6 CF 7A 40 21 4C 50 8E 12 B4 90 68 5D CC C6 19
D5 7B 3B A9 B3 D5 20 5C CB 64 B5 96 F4 3B 22 8D
F9 26 83 EE D6 E5 7F 9C CA E6 DC 2F 72 A7 AF 28
91 D6 64 D7 CE D0 94 56 98 3F 4C 58 28 78 C5 00
14 87 52 C2 31 A1 10 80 EF 5E CE 3D AD 1C 8C FB
6A DA 49 B9 28 98 07 77 E6 55 C5 34 A4 13 83 F2
61 D1 40 B0 1F 8F FE 6D DD 4C BC 2B 9B 0A 7A E9
58 88 FF 00 00 00 00 00 00 00 00 00 00 00 00 00
93 E5 75 05 96 27 B7 48 D8 69 F9 8A 1B AB 3C CC
5D ED 7E 0F 9F 30 C0 51 E1 72 02 93 24 B4 45 D5
66 F6 87 18 A8 39 C9 5A EA 7B 0C 9C 2D BD 4E DE
6F FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_02_04_07\DS1000ZUpdate.GEL  /  CRC32: 34B5A5E1
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.02.04.07
00000020 - Bitmask: 00000700
00000024 - # Sections: 7
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         00103DB2  000001CC  055C830F  00000001  [000001CC-00103F7D]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  00103F7E  028E2956  00000005  [00103F7E-001C82EF]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001C82F0  C00B6623  00000006  [001C82F0-0020F1F3]  CRC OK
000000DC  /sys/logo.hex               000BB818  0020F1F4  329211E5  0000000A  [0020F1F4-002CAA0B]  CRC OK
00000118  /sys/guiResData.hex         0001E541  002CAA0C  BF5BC175  0000000C  [002CAA0C-002E8F4C]  CRC OK
00000154  /sys/guiPicData.hex         0001DECB  002E8F4D  ABE4D204  00000011  [002E8F4D-00306E17]  CRC OK
00000190                              00000118  00306E18  00000000  00000032  [00306E18-00306F2F]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
000001CC  966AA825  00000003  00103D9A  AA5555AA  4020407     00000000  [000001E4-00103F7D]  CRC OK
00103F7E  C9AF5D56  00000000  000C435A  AA5555AA  4020407     00000000  [00103F96-001C82EF]  CRC OK
001C82F0  138E13B9  00000000  00046EEC  AA5555AA  4020407     00000000  [001C8308-0020F1F3]  CRC OK
0020F1F4  9B4EA177  00000000  000BB800  AA5555AA  4020407     00000000  [0020F20C-002CAA0B]  CRC OK
002CAA0C  5A6C6418  00000001  0001E529  AA5555AA  4020407     00000000  [002CAA24-002E8F4C]  CRC OK
002E8F4D  42893702  00000001  0001DEB3  AA5555AA  4020407     00000000  [002E8F65-00306E17]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
00306E2C
0F B7 16 CC 80 18 B7 9C 91 FB 91 22 AF 28 2C 02
5E 03 D9 70 0A 1F 11 D6 B2 9D B6 89 0C F3 74 ED
2C 54 AB 89 CF DB 42 95 E8 BB 53 D8 A2 42 C7 41
61 0E 00 8E D5 BA F3 9F 4F 02 A4 07 7A 76 9D 3C
5A 87 DA 16 C8 DF E1 1C CC 4D 16 2A 8D 72 77 05
AC 2D DE 0A 8B E3 2D 04 B3 D3 C9 D8 74 3D EB DC
45 9E AD 58 85 8F FE 12 CE 06 C0 BE 6F D5 59 C9
8F 64 6C 65 CA 73 4D 34 EF 2D 6C 40 5A 6C A0 BC
01 1C 2A 79 C8 17 67 B6 05 55 A4 F3 42 92 E1 30
80 CF 1E 6E BD 0C 5C AB FA 49 99 E8 37 87 D6 25
75 C4 13 63 B2 01 51 A0 EF 3E 8E DD 2C 7C CB 1A
6A B9 08 58 A7 F6 45 95 E4 33 83 D2 21 71 C0 0F
66 C8 77 28 D9 89 3A EB 9B 4C FD AD 5E 0F C0 70
21 D2 82 33 E4 94 45 F6 A6 57 08 B9 69 1A CB 7B
2C DD 8D 3E EF 9F 50 01 B2 62 13 C4 74 25 D6 86
37 E8 98 49 FA AA 5B 0C BD 6D 1E CF 7F 30 E1 91
01 00 01 00
b = 4F
57 B0 BF 26 8B D4 23 B9 5F 79 C0 02 3F 69 1E A4
B1 07 8E D5 20 E6 88 FE 8B 26 F0 74 A7 3F 71 9A
8A 63 6B F9 F0 AD C4 C8 CC 4F 98 CE 48 99 CF FA
CA 28 CB 09 01 97 80 DD 3E A1 F4 08 2C D8 B0 00
1A 96 39 C4 C5 2B 7D 07 06 D7 EF 52 05 39 8D 6B
61 31 32 AD 7D 24 BE E4 E2 52 97 F5 E1 F9 F6 37
EF 97 F5 F0 6C C5 84 E7 F2 7A 83 D0 D1 86 59 19
2E 52 A9 F2 A6 9E C8 FE 08 96 24 47 B1 12 95 00
76 42 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_03_00_01\DS1000ZUpdate.GEL  /  CRC32: 467EDE17
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.03.00.01
00000020 - Bitmask: 00000700
00000024 - # Sections: 8
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         00104803  00000208  89F833BF  00000001  [00000208-00104A0A]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  00104A0B  89E2A45C  00000005  [00104A0B-001C8D7C]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001C8D7D  E81C63CB  00000006  [001C8D7D-0020FC80]  CRC OK
000000DC  /sys/logo.hex               000BB818  0020FC81  C59881AD  0000000A  [0020FC81-002CB498]  CRC OK
00000118  /sys/guiResData.hex         0001E697  002CB499  3571B927  0000000C  [002CB499-002E9B2F]  CRC OK
00000154  /sys/guiPicData.hex         0001DECB  002E9B30  D34315FD  00000011  [002E9B30-003079FA]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  003079FB  D3654F59  00000010  [003079FB-003C3212]  CRC OK
000001CC                              00000118  003C3213  00000000  00000032  [003C3213-003C332A]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000208  68CFAD01  00000003  001047EB  AA5555AA  4030001     00000000  [00000220-00104A0A]  CRC OK
00104A0B  C9AF5D56  00000000  000C435A  AA5555AA  4030001     00000000  [00104A23-001C8D7C]  CRC OK
001C8D7D  138E13B9  00000000  00046EEC  AA5555AA  4030001     00000000  [001C8D95-0020FC80]  CRC OK
0020FC81  9B4EA177  00000000  000BB800  AA5555AA  4030001     00000000  [0020FC99-002CB498]  CRC OK
002CB499  2C75C357  00000001  0001E67F  AA5555AA  4030001     00000000  [002CB4B1-002E9B2F]  CRC OK
002E9B30  42893702  00000001  0001DEB3  AA5555AA  4030001     00000000  [002E9B48-003079FA]  CRC OK
003079FB  5DEF7058  00000000  000BB800  AA5555AA  4030001     00000000  [00307A13-003C3212]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
003C3227
4C CE F5 B1 EB 0C 61 85 16 F7 B7 2E 53 C6 CC D6
BA FE 11 77 7A C2 43 24 00 21 ED A1 00 9B 56 BA
B6 E2 E9 41 BF 1A 80 0D 45 D3 EF F8 65 7E D4 4E
6C BE 29 F8 21 D0 F6 40 83 82 00 15 31 78 AB 88
9F 6E 27 95 98 E2 58 25 41 AD 87 AD D5 C1 38 B1
CE CE CE D0 B1 19 17 D5 7C 44 B0 91 41 47 2F EE
78 8A 10 7E 7F E5 9F 3B 93 6C 76 69 8D 65 14 C0
52 5F 33 13 58 E1 E2 2A AA 5B FB 94 AB BA 75 4A
09 00 B0 35 BD 44 CC 53 DB 62 EA 71 F9 80 08 90
17 9F 26 AE 35 BD 44 CC 53 DB 62 EA 71 F9 80 08
90 17 9F 26 AE 35 BD 44 CC 53 DB 62 EA 71 F9 80
08 90 17 9F 26 AE 35 BD 44 CC 53 DB 62 EA 71 F9
8C 5D D3 4B C4 3C B5 2D A6 1E 97 0F 88 00 79 F1
69 E2 5A D3 4B C4 3C B5 2D A6 1E 97 0F 88 00 79
F1 69 E2 5A D3 4B C4 3C B5 2D A6 1E 97 0F 88 00
79 F1 69 E2 5A D3 4B C4 3C B5 2D A6 1E 97 0F 88
01 00 01 00
b = 87
1F 19 B9 ED A0 39 07 A3 AD 06 3F 2E CB B7 35 B8
14 D1 5C 3B B6 77 70 CA 1E B8 FC 29 00 13 47 23
98 3C BC 8C 83 56 35 3A EB F1 86 07 ED 7E 4C 3F
D5 A0 83 CB 6C 94 32 F5 B0 28 1E AC 40 00 AB 00
FA 51 91 87 11 E3 E1 35 D9 CC 2E DB 8B FE FD FD
A2 29 B1 3A A3 92 18 5E 8C DC CF 38 6F FD 6C B3
C4 5E 6B 61 E9 D7 18 3C 1C 7C 0E 88 34 93 CA FD
17 AB 07 6E 3B 4B D4 A3 AB E4 0B 2C CA 61 A3 00
6A DA 02 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 03 00 00 00 00 00 00 00 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_03_01_05\DS1000Z(ARM)Update_00.04.03.01.05\DS1000ZUpdate.GEL  /  CRC32: 27C20EF7
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.03.01.05
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         0010DBA2  00000280  49EF88AB  00000001  [00000280-0010DE21]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  0010DE22  EEA6ED8E  00000005  [0010DE22-001D2193]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001D2194  122B4672  00000006  [001D2194-00219097]  CRC OK
000000DC  /sys/logo.hex               000BB818  00219098  FF0E53FF  0000000A  [00219098-002D48AF]  CRC OK
00000118  /sys/guiResData.hex         0001F5CE  002D48B0  7AC4FCE7  0000000C  [002D48B0-002F3E7D]  CRC OK
00000154  /sys/guiPicData.hex         0001E3E4  002F3E7E  BD466AF3  00000011  [002F3E7E-00312261]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  00312262  E9F39D0B  00000010  [00312262-003CDA79]  CRC OK
000001CC  /sys/SparrowWaveTable.hex   000020E8  003CDA7A  140046C9  0000000B  [003CDA7A-003CFB61]  CRC OK
00000208  /sys/SparrowCalFile.hex     00022EFD  003CFB62  28D1126D  0000000F  [003CFB62-003F2A5E]  CRC OK
00000244                              00000118  003F2A5F  00000000  00000032  [003F2A5F-003F2B76]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000280  162BBC30  00000003  0010DB8A  AA5555AA  4030105     00000000  [00000298-0010DE21]  CRC OK
0010DE22  C9AF5D56  00000000  000C435A  AA5555AA  4030105     00000000  [0010DE3A-001D2193]  CRC OK
001D2194  138E13B9  00000000  00046EEC  AA5555AA  4030105     00000000  [001D21AC-00219097]  CRC OK
00219098  9B4EA177  00000000  000BB800  AA5555AA  4030105     00000000  [002190B0-002D48AF]  CRC OK
002D48B0  95909E61  00000001  0001F5B6  AA5555AA  4030105     00000000  [002D48C8-002F3E7D]  CRC OK
002F3E7E  E3D36C78  00000001  0001E3CC  AA5555AA  4030105     00000000  [002F3E96-00312261]  CRC OK
00312262  5DEF7058  00000000  000BB800  AA5555AA  4030105     00000000  [0031227A-003CDA79]  CRC OK
003CDA7A  27F4C06F  00000000  000020D0  AA5555AA  4030105     00000000  [003CDA92-003CFB61]  CRC OK
003CFB62  1E61A8F6  00000000  00022EE5  AA5555AA  4030105     00000000  [003CFB7A-003F2A5E]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
003F2A73
8A E9 5F BF 27 BC 39 C4 58 84 80 AE 68 84 23 AC
FC 9D 3A 2D 12 DA 5C 0E 4B D2 54 2C 9D 47 C6 05
D8 5B F1 CA 76 4D 76 56 87 FA 47 69 4E 9A D4 DD
CC F1 E3 19 B2 ED C7 A9 2E DB 9A 3B BB 38 A7 82
AA 12 2F DA A8 CA 6E 62 80 3D B2 B0 E7 04 45 D2
24 42 7B 6D F2 68 80 F8 16 2B F6 49 A9 82 6E 52
5F 74 D2 E0 D9 F9 4A B4 BA B5 74 5F D4 5B 76 84
3C D0 92 9D 74 9D 52 96 55 E0 45 B9 BA 81 D3 3D
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB
C7 D3 DF EB F7 03 10 1C 28 34 40 4C 58 64 70 7C
88 94 A0 AC B8 C4 D0 DC E8 F4 00 0D 19 25 31 3D
49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
4F 79 6B 5F 53 47 3B 2F 23 17 0B FF F2 E6 DA CE
C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E
02 F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D
41 35 29 1D 11 05 F9 EC E0 D4 C8 BC B0 A4 98 8C
01 00 01 00
b = 0C
FF 52 BC 10 6C F5 66 E5 6D 8D 7D 9E 4C 5C EF 6C
B0 45 D6 BD 96 52 C8 6E 9F 1A 90 5C C1 5F D2 05
CB 42 CC 99 39 04 21 F5 1A 81 C2 D8 B1 F1 1F 1C
FF 18 FE 28 B5 E4 B1 87 00 A1 54 E9 5D CE 31 00
76 EA 13 CA A4 D2 83 83 AD 76 F7 01 44 6D BA 53
B1 DB 20 1E AF 31 55 D9 03 24 FB 5B C7 AC A4 94
AD CE 38 52 57 83 E0 56 68 6F 3A 31 B2 45 6C 86
4B EB B9 D0 B3 E8 A9 F9 C4 5B CC 4C 59 2C 8A 00
9D 1D 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CC 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_03_02_03\DS1000ZUpdate.GEL  /  CRC32: E9E67092
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.03.02.03
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         0010A814  00000280  C8A599FA  00000001  [00000280-0010AA93]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  0010AA94  EDBD3A3D  00000005  [0010AA94-001CEE05]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001CEE06  BFF26E4F  00000006  [001CEE06-00215D09]  CRC OK
000000DC  /sys/logo.hex               000BB818  00215D0A  8F0DC137  0000000A  [00215D0A-002D1521]  CRC OK
00000118  /sys/guiResData.hex         000206A8  002D1522  5A77FD58  0000000C  [002D1522-002F1BC9]  CRC OK
00000154  /sys/guiPicData.hex         0001E6A4  002F1BCA  99FE002B  00000011  [002F1BCA-0031026D]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  0031026E  99F00FC3  00000010  [0031026E-003CBA85]  CRC OK
000001CC  /sys/SparrowWaveTable.hex   000020E8  003CBA86  724E92AA  0000000B  [003CBA86-003CDB6D]  CRC OK
00000208  /sys/SparrowCalFile.hex     00022EFD  003CDB6E  E9F29192  0000000F  [003CDB6E-003F0A6A]  CRC OK
00000244                              00000118  003F0A6B  00000000  00000032  [003F0A6B-003F0B82]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000280  96C1C31B  00000003  0010A7FC  AA5555AA  4030203     00000000  [00000298-0010AA93]  CRC OK
0010AA94  C9AF5D56  00000000  000C435A  AA5555AA  4030203     00000000  [0010AAAC-001CEE05]  CRC OK
001CEE06  138E13B9  00000000  00046EEC  AA5555AA  4030203     00000000  [001CEE1E-00215D09]  CRC OK
00215D0A  9B4EA177  00000000  000BB800  AA5555AA  4030203     00000000  [00215D22-002D1521]  CRC OK
002D1522  60ECEBCB  00000001  00020690  AA5555AA  4030203     00000000  [002D153A-002F1BC9]  CRC OK
002F1BCA  541C43A8  00000001  0001E68C  AA5555AA  4030203     00000000  [002F1BE2-0031026D]  CRC OK
0031026E  5DEF7058  00000000  000BB800  AA5555AA  4030203     00000000  [00310286-003CBA85]  CRC OK
003CBA86  27F4C06F  00000000  000020D0  AA5555AA  4030203     00000000  [003CBA9E-003CDB6D]  CRC OK
003CDB6E  1E61A8F6  00000000  00022EE5  AA5555AA  4030203     00000000  [003CDB86-003F0A6A]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
003F0A7F
7C AB 7E 46 BB B8 D1 D3 A5 C9 F3 A7 82 8F 1F 25
47 10 9C 63 45 0A 76 CF AA 0D DD 7B 17 3F 7E A6
E6 BD 2A 5D FF 9B 34 A0 93 FB 45 83 8E CD 4E 03
9A FE BE 22 13 AE 7F B4 0D 61 90 A2 74 4F A9 DB
EE E4 1B 76 76 86 A0 77 C3 0F FB 0F FA 22 43 8F
A8 69 6A FB D3 94 93 19 84 BC 3A DC C7 11 7C 68
8D 20 13 24 AB 24 E8 43 41 F5 8C 7B 6D 70 F9 7C
EA 77 3C 93 33 39 60 DD 19 B2 0C F7 E6 E8 39 29
3B C1 5B FC 9E 41 E4 86 29 CC 6E 11 B4 56 F9 9B
3E E1 83 26 C9 6B 0E B1 53 F6 98 3B DE 80 23 C6
68 0B AE 50 F3 95 38 DB 7D 20 C3 65 08 AB 4D F0
92 35 D8 7A 1D C0 62 05 A8 4A ED 8F 32 D5 77 1A
A5 09 64 C1 1E 7C D9 36 94 F1 4E AC 09 67 C4 21
7F DC 39 97 F4 51 AF 0C 6A C7 24 82 DF 3C 9A F7
54 B2 0F 6D CA 27 85 E2 3F 9D FA 57 B5 12 70 CD
2A 88 E5 42 A0 FD 5A B8 15 73 D0 2D 8B E8 45 A3
01 00 01 00
b = A2
A7 34 64 89 5C B6 2C 8C BB 3D C4 D5 0E 78 65 C9
48 6F 58 7C BC DE A7 5E 96 56 84 7F 79 FE 9A 20
BD F1 BC 4C 4B 45 3B 05 55 1A C2 5D C5 62 40 52
47 08 26 E7 35 2E 5C EE A5 56 E2 52 81 BA 71 00
BF 57 31 2F D1 84 40 BA A9 97 26 DD 6A 35 F9 E7
A3 06 AA DE 58 BC 5E 86 94 6F 8F D4 61 4E 5C EA
B2 E8 7D 31 5B 76 DD DA 7B D2 0B 9D 32 D7 03 29
39 69 D0 CA 0D B5 7F 9F 7D B9 B6 43 D5 79 6D 00
27 0A 02 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FC 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_04_00_07\DS1000ZUpdate.GEL  /  CRC32: 4F68463D
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.04.00.07
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         001097D0  00000280  1CCB275E  00000001  [00000280-00109A4F]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  00109A50  041EA3FF  00000005  [00109A50-001CDDC1]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001CDDC2  98BD1B9C  00000006  [001CDDC2-00214CC5]  CRC OK
000000DC  /sys/logo.hex               000BB818  00214CC6  046D5DC1  0000000A  [00214CC6-002D04DD]  CRC OK
00000118  /sys/guiResData.hex         000B6B34  002D04DE  9D96DD8E  0000000C  [002D04DE-00387011]  CRC OK
00000154  /sys/guiPicData.hex         0001E6BF  00387012  8B4B6D52  00000011  [00387012-003A56D0]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  003A56D1  12909335  00000010  [003A56D1-00460EE8]  CRC OK
000001CC  /sys/SparrowWaveTable.hex   000020E8  00460EE9  F5EC3227  0000000B  [00460EE9-00462FD0]  CRC OK
00000208  /sys/SparrowCalFile.hex     00022EFD  00462FD1  372075C9  0000000F  [00462FD1-00485ECD]  CRC OK
00000244                              00000118  00485ECE  00000000  00000032  [00485ECE-00485FE5]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000280  E0469303  00000003  001097B8  AA5555AA  4040007     00000000  [00000298-00109A4F]  CRC OK
00109A50  C9AF5D56  00000000  000C435A  AA5555AA  4040007     00000000  [00109A68-001CDDC1]  CRC OK
001CDDC2  138E13B9  00000000  00046EEC  AA5555AA  4040007     00000000  [001CDDDA-00214CC5]  CRC OK
00214CC6  9B4EA177  00000000  000BB800  AA5555AA  4040007     00000000  [00214CDE-002D04DD]  CRC OK
002D04DE  271E3AB5  00000000  000B6B1C  AA5555AA  4040007     00000000  [002D04F6-00387011]  CRC OK
00387012  01873014  00000001  0001E6A7  AA5555AA  4040007     00000000  [0038702A-003A56D0]  CRC OK
003A56D1  5DEF7058  00000000  000BB800  AA5555AA  4040007     00000000  [003A56E9-00460EE8]  CRC OK
00460EE9  27F4C06F  00000000  000020D0  AA5555AA  4040007     00000000  [00460F01-00462FD0]  CRC OK
00462FD1  1E61A8F6  00000000  00022EE5  AA5555AA  4040007     00000000  [00462FE9-00485ECD]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
00485EE2
64 29 7F D9 1A C9 9B D5 74 5C 2B 8E A3 5E 57 7A
62 DF 99 D4 BA DC 33 FE F2 37 40 E8 78 71 12 E6
10 E9 B4 B4 B5 54 17 47 73 65 9D EB 5D 4F A1 10
3E CF 7E 43 35 A9 0B A8 28 1F A3 8D 26 F2 A4 0E
44 2B 67 F0 BE E1 A3 63 CA 9F 17 56 53 32 7A F4
F8 07 7F 8C 0D 91 A7 C9 8E 99 8B 22 A9 6D 4E 0D
BE 89 A2 56 A7 58 B6 C7 99 39 48 54 91 5A 11 39
F4 D6 0C D7 7D 99 26 24 7A 94 7C 52 1E B9 17 D0
A3 30 20 2B 37 43 4F 5B 67 73 7F 8B 97 A3 AF BB
C7 D3 DF EB F7 03 10 1C 28 34 40 4C 58 64 70 7C
88 94 A0 AC B8 C4 D0 DC E8 F4 00 0D 19 25 31 3D
49 55 61 6D 79 85 91 9D A9 B5 C1 CD D9 E5 F1 FD
4F 79 6B 5F 53 47 3B 2F 23 17 0B FF F2 E6 DA CE
C2 B6 AA 9E 92 86 7A 6E 62 56 4A 3E 32 26 1A 0E
02 F6 E9 DD D1 C5 B9 AD A1 95 89 7D 71 65 59 4D
41 35 29 1D 11 05 F9 EC E0 D4 C8 BC B0 A4 98 8C
01 00 01 00
b = 0C
4D 06 50 9E D3 76 3C 6A FD D9 9C F3 FC AB 98 AF
8B FC AA D9 B3 C8 13 D2 BA F3 F0 8C 10 FD 92 5A
78 45 04 F8 ED 80 37 5B 7B 61 8C CE 34 1A 60 C3
E5 6A 0D C6 AC 14 6A FB 6F 5A D2 B0 3D FD A3 00
7D 70 B8 4D 27 56 24 F0 63 44 C8 13 1C 07 5B E1
F1 0C 91 AA 37 C7 E9 17 E8 FF FD A0 33 03 F0 BB
78 4F 74 34 91 4E B8 D6 B4 60 7B 93 DC B1 74 A8
6F 5D 9F 76 28 50 E9 F3 55 7B 6F 51 29 D1 3B 00
9D 1D 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CC 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_04_01_01\DS1000ZUpdate.GEL  /  CRC32: A623D8BC
00000000 - File Type: DS1000Z
00000010 - Version: 00.04.04.01.01
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset    Section Name                SectiSz   StartAdr  CRC32     Type
00000028  /sys/SparrowAPP.out         00107791  00000280  865DD4FE  00000001  [00000280-00107A10]  CRC OK
00000064  /sys/SparrowFPGA.hex        000C4372  00107A11  C72D7DD0  00000005  [00107A11-001CBD82]  CRC OK
000000A0  /sys/SparrowDGFPGA.hex      00046F04  001CBD83  AD60366F  00000006  [001CBD83-00212C86]  CRC OK
000000DC  /sys/logo.hex               000BB818  00212C87  1F2E52B7  0000000A  [00212C87-002CE49E]  CRC OK
00000118  /sys/guiResData.hex         000B6B34  002CE49F  9C2E4FC0  0000000C  [002CE49F-00384FD2]  CRC OK
00000154  /sys/guiPicData.hex         0001E6BF  00384FD3  10D74A0D  00000011  [00384FD3-003A3691]  CRC OK
00000190  /sys/SparrowConfig.hex      000BB818  003A3692  09D39C43  00000010  [003A3692-0045EEA9]  CRC OK
000001CC  /sys/SparrowWaveTable.hex   000020E8  0045EEAA  B1CE7C07  0000000B  [0045EEAA-00460F91]  CRC OK
00000208  /sys/SparrowCalFile.hex     00022EFD  00460F92  91673CA7  0000000F  [00460F92-00483E8E]  CRC OK
00000244                              00000118  00483E8F  00000000  00000032  [00483E8F-00483FA6]
Offset    CRC32     Flags     Filesize  Endianes  Version     Rsvd
00000280  82AC1341  00000003  00107779  AA5555AA  4040101     00000000  [00000298-00107A10]  CRC OK
00107A11  C9AF5D56  00000000  000C435A  AA5555AA  4040101     00000000  [00107A29-001CBD82]  CRC OK
001CBD83  138E13B9  00000000  00046EEC  AA5555AA  4040101     00000000  [001CBD9B-00212C86]  CRC OK
00212C87  9B4EA177  00000000  000BB800  AA5555AA  4040101     00000000  [00212C9F-002CE49E]  CRC OK
002CE49F  271E3AB5  00000000  000B6B1C  AA5555AA  4040101     00000000  [002CE4B7-00384FD2]  CRC OK
00384FD3  01873014  00000001  0001E6A7  AA5555AA  4040101     00000000  [00384FEB-003A3691]  CRC OK
003A3692  5DEF7058  00000000  000BB800  AA5555AA  4040101     00000000  [003A36AA-0045EEA9]  CRC OK
0045EEAA  27F4C06F  00000000  000020D0  AA5555AA  4040101     00000000  [0045EEC2-00460F91]  CRC OK
00460F92  1E61A8F6  00000000  00022EE5  AA5555AA  4040101     00000000  [00460FAA-00483E8E]  CRC OK
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
00483EA3
12 54 D6 19 55 24 20 80 04 13 9B 27 A6 0E E7 C7
95 91 CA 26 62 2D 1E 22 45 ED 67 A9 FA 27 00 83
6A 3E 80 E6 76 DE 0C 2F 76 84 EF 91 46 67 68 5D
B8 8E 13 EA 40 0B BD 4D EA 67 58 66 D0 25 EA 4B
11 D1 1D 3C 69 FC 5E E6 E6 03 BE 40 5D CC 0B C7
BE 31 30 B1 E0 15 9B 6A 39 3D 55 A6 CD 72 C8 81
61 AA A5 F3 46 D8 95 B1 E0 E2 0F DA CF 02 1F 80
94 C9 9C 18 CC 63 C7 08 25 B3 9A F3 51 27 AD C7
7B 17 24 6A B5 00 4C 97 E2 2D 79 C4 0F 5B A6 F1
3C 88 D3 1E 6A B5 00 4C 97 E2 2D 79 C4 0F 5B A6
F1 3C 88 D3 1E 6A B5 00 4C 97 E2 2D 79 C4 0F 5B
A6 F1 3C 88 D3 1E 6A B5 00 4C 97 E2 2D 79 C4 0F
75 C3 74 29 DE 92 47 FC B0 65 1A CF 83 38 ED A1
56 0B C0 74 29 DE 92 47 FC B0 65 1A CF 83 38 ED
A1 56 0B C0 74 29 DE 92 47 FC B0 65 1A CF 83 38
ED A1 56 0B C0 74 29 DE 92 47 FC B0 65 1A CF 83
01 00 01 00
b = 4B
4F 46 7C 74 65 E9 99 AE E7 AA E7 28 5C 78 06 9B
1D CE BC CC BD 3D E3 9B 73 D0 FE F5 FB DD 6A A2
3E C6 BD D8 1C 39 1C F4 EF B2 D2 28 92 68 1E C7
D7 62 9B 27 32 B1 18 5D AF E0 86 49 67 71 EB 00
C3 CE 65 D0 48 26 D4 A7 F2 5B 61 2E 96 51 DB E2
25 E3 2D F9 74 F4 C5 E0 FA 49 AD 49 BB AB 4D 51
7C 11 57 F0 8E 6C 74 DB 56 A3 1B 32 72 F0 58 05
64 E4 03 CA C9 AB 5B E7 4F 29 5B FF A9 CA 9B 00
F3 44 06 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6A 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


F:\zscan\original\RIGOL\DS1000\DS1000Z-00_04_04_03_02\DS1000ZUpdate.GEL  /  CRC32: 22AD4A12
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
  File Processed OK

 For studying the footer section:
80 00 00 00 01 00 00 00 80 00 00 00 01 00 00 00 04 00 00 00
00485BBC
69 61 C8 4B 81 93 48 87 AE DC 31 7B 04 1B 57 3C
45 71 96 FD B0 5A E8 5B 82 4F 3C C8 A9 D0 7C 84
26 05 55 DD 3B 95 A0 FF 1C C3 A7 A4 E0 56 6D 13
E9 E3 BC EB 2D 1F 61 3E E6 DA 53 DC A5 C6 60 D2
51 AC 46 EC F8 D0 29 35 7A 19 AE 53 F7 E1 A4 53
02 81 DE 43 CC D6 4D 3F B3 2E 47 43 8C E3 54 E5
A3 D9 7C CE 03 36 A6 96 14 A8 05 1D 89 8A 1B 91
A0 3E 03 5A 80 8E DE F6 19 A3 B7 4B D6 18 3F 1B
2B 8E F0 54 B9 1D 82 E6 4A AF 13 78 DC 40 A5 09
6E D2 36 9B FF 63 C8 2C 91 F5 59 BE 22 87 EB 4F
B4 18 7D E1 45 AA 0E 73 D7 3B A0 04 69 CD 31 96
FA 5E C3 27 8C F0 54 B9 1D 82 E6 4A AF 13 78 DC
63 DA 74 10 AC 47 E3 7E 1A B6 51 ED 88 24 C0 5B
F7 92 2E CA 65 01 9D 38 D4 6F 0B A7 42 DE 79 15
B1 4C E8 83 1F BB 56 F2 8D 29 C5 60 FC 97 33 CF
6A 06 A2 3D D9 74 10 AC 47 E3 7E 1A B6 51 ED 88
01 00 01 00
b = 64
4C DF E2 01 D2 80 D0 AB 6E 37 28 0D 32 E5 BC 3D
E2 A9 6A 6C BB 01 2A 39 FB 64 ED 14 91 53 9B 3F
7C F7 E2 06 00 F5 9C 96 4F 92 11 AA 82 93 46 87
F9 8F 03 CE AB 39 17 8F D3 62 77 9C 00 BD F2 00
81 41 3F 49 BA F6 B4 24 CD D1 CA D4 DC 2A 52 65
79 5C 1D E7 D4 43 1E 74 4D 2C A9 0A B7 73 48 3D
60 FA 02 B8 51 E9 BD 12 F4 EC AE 2A FB 60 55 30
A3 A6 CF 8A 15 87 3B B8 3F 2E A6 9E 8E 34 C0 00
04 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
26 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The code that does this is:

Code: [Select]

                i = start of the "last 128 bytes"

                byte b = (byte)(((byte)(buffer[i + 110] - buffer[i + 111]) + (byte)(buffer[i + 109] - buffer[i + 110])) >> 1);
                i = i + 127;

                byte a = buffer[i];
                for (int i0 = 0; i0 < 64; i0++, i--)
                {
                    buffer[i] -= a;
                    a += b;
                    if (a >= 0x100 - b) a++;
                }

                a = buffer[i];
                for (int i0 = 0; i0 < 64; i0++, i--)
                {
                    buffer[i] -= a;
                    a -= b;
                    if (a <= b) a--;
                }
I know that the main goal are the first 128 bytes but if you can see any of these decodes in memory dumps, that would help.

Resuming:

00.04.00.00.00 - decoded OK
00.04.00.00.00 (boot) - decoded OK
00.04.01.02.00 - has different pattern (investigating ATM...)
00.04.02.04.07 - decoded OK
00.04.03.00.01 - decoded OK  (although has a few bytes = 01)
00.04.03.01.05 - decoded OK
00.04.03.02.03 - decoded OK
00.04.04.00.07 - decoded OK
00.04.04.01.01 - decoded OK
00.04.04.03.02 - decoded OK

If anyone has other FW versions please post them or pm me.

Edit1: Added 00.04.03.00.01 version

Edit2 (Apr 13th): The footer contains BOTH the software version and SparrowAPP.out CRC in a obfuscated way. All of my theories above were far from correct. I'll leave them as historical information.

[ankerwolf]

Hello tv84,
Would you post the final version of the program or a link, please?
The version I used is unpack8 in this thread here.

LG Wolfgang

[tv84]

Hi Wolfgang,

My prog is a work in progress (in C#) and it's not easy to fork a small unpacker. Have you got problems or doubts about the unpack8 that you refer?

I saw in the thread some probs about CRCs but the one used by Rigol here is the standard CRC-32 hash (IEEE 802.3; CRC-32).

And, you can used my parsings as a reference to check the output of other parsers/unpackers and compare sizes and CRCs. I try to maintain full offsets so that everyone can check things by themselves.

[tv84]

It throws a CRC mismatch every time that I did not notice before. I downloaded the firmware zip archives from both rigol sources again, but the CRC mismatch won’t resolve.

The reason it throws a CRC mismatch is because the "footer" (last "file" listed) has a CRC of 0x00000000 in every Rigol DS1000Z FW release. It's a feature, not a bug.

Curious fact: The CRC will be shown correct if you extract the FW package from a memory dump.

[tv84]

A bit of OT but, for the record, may be useful to others who want to verify Rigol CRC's:

The CRC-16 that Rigol uses in the DG5000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0x1008 refin=false refout=false xorout=0x0000 check=0xAC1A residue=0x0000 name="CRC-16/RIGOL 1"

The CRC-16 that Rigol uses in the DG4000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0x0528 refin=false refout=false xorout=0x0000 check=0x147D residue=0x0000 name="CRC-16/RIGOL 3"

The CRC-16 that Rigol uses in the DG1000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0xFFFF refin=false refout=false xorout=0x0000 check=0x5CC1 residue=0x0000 name="CRC-16/RIGOL 4"

Many Rigol equipments use this variation:

width=16 poly=0x1021 init=0xEBCC refin=false refout=false xorout=0x0000 check=0x6809 residue=0x0000 name="CRC-16/RIGOL 2"

And, other Rigol equipments (that include a CRC-16), use the more common:

width=16 poly=0x1021 init=0xFFFF refin=false refout=false xorout=0x0000 check=0x29b1 residue=0x0000 name="CRC-16/CCITT-FALSE"


Edit1: Included a parsing of many Rigol file types (showing the CRCs).
Edit2: Added Rigol 2 CRC16 type.
Edit3: Added Rigol 3 and 4 CRC16 types.

[janekivi]

Inside DS1054Z was at one address

Code: [Select]

Copyright(C) Freescale Semiconductor, Inc. 2009. All rights reserved.
The somewhat disturbed crew - JC, TT, PZ, MJ, CR, CS, DM
No pygmies were harmed during testing..really...
N T L F J C M

[janekivi]

Another interesting thing happened to me...
In GEL header is update version like this:
DS1000Z         00.04.04.00.07
I changed this by one number to:
DS1000Z         00.04.04.00.08
Scope found a newer software version than my 00.04.04.00.07 and updated it successfully to... 00.04.04.00.07


(I have 00.04.04.00.07 with modified logo in my scope for all kind of hacks right now)

[janekivi]

So all the info for update messagebox is read from the header.
This info is not critical and you can write there what you like...
To get this "found update file file" box you actually don't need anything.
Empty file is good enough.
0 byte DS1000ZUpdate.GEL file is showing of course no info

[smithnerd]

I haven't looked at more recent firmwares, but on 4.3.2.3, I have that cluster of 3 DCP related functions marked as:

start_dcp_memcopy
start_dcp_memfill
start_dcp_blit

Janekivi,

Here is a code worth investigating  (addr = 0x400CF3B0):

Code: [Select]

int __fastcall DCP_Operation1(int result, int a2, int a3, unsigned __int8 a4)
}

[tv84]

I haven't looked at more recent firmwares, but on 4.3.2.3, I have that cluster of 3 DCP related functions marked as:

start_dcp_memcopy
start_dcp_memfill
start_dcp_blit

Thankx, that's what I was about to compare. There are also 3 in 4.4.0.7 but, at first sight, I say the 2nd and 3rd may be a little different... investigating ATM...

Edit:

Hex-rays bug that shows me all the 3 Ops as the MEMCOPY...    But, going back to ASM, we can see the 3 different CTRL0 setups: 0x13, 0x10013, 0x83 (memcopy, memfill & memblit) 

Now, back to the drawing board. The "footer" hashes/etc are not DCP-based...

[janekivi]

After long pause there I managed to get some good guys (better than me) interested
about this GEL file format and what is hidden inside footer. Now we know something.
They did the hard work for me and I did the... dirty work (better than nothing) and
thanks to tv84 and smithnerd and some more I finally got rid of those "Pluses".

[tv84]

After long pause there I managed to get some good guys (better than me) interested
about this GEL file format and what is hidden inside footer. Now we know something.
They did the hard work for me and I did the... dirty work (better than nothing) and
thanks to tv84 and smithnerd and some more I finally got rid of those "Pluses".

A good team effort. All essential! After a false positive, success. 

[technogeeky]

After long pause there I managed to get some good guys (better than me) interested
about this GEL file format and what is hidden inside footer. Now we know something.
They did the hard work for me and I did the... dirty work (better than nothing) and
thanks to tv84 and smithnerd and some more I finally got rid of those "Pluses".

What kind of level of reverse engineering did you guys do? Is there assembly or source to look at?

[janekivi]

 As we know only some things and can't make new correct firmware file, there is not much more to show.
For me this is schi-fi so they disassembled some functions and guided me what the scope checks. I made
all kind of changes in my already hacked GEL (my TV screen logo) and did hardware testings. I did try all
with notepad and calculator and using hex editor made 500mb worth of new files. Of course they didn't
work and scope was bricked many times. When they reached to the last crucial function, my last file did
work. So this is manually hacked together workaround to replace SparrowAPP and worked in those
special conditions I currently have.

 They made good work even not having a scope and using my memory dumps and test results. But this
is not the end as I like to know more what there is going on. Like what is inside footer exactly and how
the firmware version is checked. If You like to help with disassembly, we can widen our team. There are
all kind of cryptic and complex functions and we don't know what they are doing too. Half of software is
running scope and second half is keeping us away...
 One day we come up with something to show, I hope.

[tv84]

What kind of level of reverse engineering did you guys do? Is there assembly or source to look at?

This was never a task to be kept secret. Resuming, there are 2 .IDBs (a big one from the APP and another from bootloader) to play around.

They are somewhat commented in some critical areas but most of the things are unknown.

We focused on the primary goal but now many other things will be possible.

Once the footer processing got identified, things evolved very quickly. Then with a bit of luck and plenty of grit we discovered a workaround.

The footer only does (as far as we understand it) a obfuscation of the CRC of the APP. It's not encryption, it's not hashing. The footer is processed in 3 blocks: 0x80 bytes + 0x80 bytes + 0x04 bytes (and the 20 bytes header indicates the number os bytes, etc of those blocks).

So you can't change the APP because you would have to change it's CRC and the footer validation prevents that. Unless you go around it... 

The footer is processed by the function below. As you can see they went to great troubles to obfuscate the thing.

In order to understand the footer we need to reverse all those functions. Any help is more than welcome!

[janekivi]

I think exactly this "chinese" function I like to see translated to me, at least in "english".

[janekivi]

Any chance of finding a way to swap out the small font?

After many years I was thinking here... what font did you think back then?
All other stuff can't be resized, you need then bigger screen to fit them,
but for those there is font size to choose:

[janekivi]

Some time ago I just run sbtool source through compiler to get windows version
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg991398/#msg991398
but this wasn't the brightest idea... If you redirect output to a file, this is not binary file any more
and windows is adding 0D everywhere before 0A. This is end of line for him.
How to solve this... I did add extra option for this.
-s filename
Now it is possible to save decrypted section output to a binary file:

sbtool -z -x 0 -s bootloader SparrowBootloader.sb

sbtool - executable utility (sbtool.exe)
-z        - zero key is used for decryption
-x        - extract section
0         - section index
-s        - save output to a binary file
bootloader - new output file name
SparrowBootloader.sb - file to be processed

Now the output seems to be correct...

Code: [Select]

C:\Sbtool>sbtool -z -x 0 -s output SparrowBootloader.sb
---- Boot image header ----
Signature 1:           STMP
Signature 2:           sgtl
Format version:        1.1
Flags:                 0x0000
Image blocks:          19764
First boot tag block:  9
First boot section ID: 0x00000000
Key count:             1
Key dictionary block:  7
Header blocks:         6
Section count:         1
Section header size:   1
Timestamp:             446216079000000
Product version:       999.999.999
Component version:     999.999.999
Drive tag:             0x0000
SHA-1 digest of header:
    0x00000000: 2d 5c 14 b8 10 81 fe 5f ee e2 09 ee 75 55 fe 80
    0x00000010: bb 35 50 44
Header digest is correct.

---- Section table ----
Section 0:
    Identifier: 0x0
    Offset:     10 blocks (160 bytes)
    Length:     19752 blocks (316032 bytes)
    Flags:      0x00000001
                0x1 = ROM_SECTION_BOOTABLE

---- Key dictionary ----

Default key was found in key dictionary.

Data encryption key:
    0x00000000: 9f e8 30 4c bf d7 b7 7c c6 66 cd 98 de bd 69 07

---- SHA-1 digest of entire image ----
    0x00000000: fe 61 57 33 93 5d 97 24 a6 22 be 3b ae 28 55 52
    0x00000010: f0 12 97 f1
Image digest is correct.

---- Boot tags ----
0000: @ block 000009 | id=0x00000000 | length=019752 | flags=0x00000001
        0x1 = ROM_SECTION_BOOTABLE

C:\Sbtool>sbtool -z -x 0 -s output1 SparrowBootloader1.sb
---- Boot image header ----
Signature 1:           STMP
Signature 2:           sgtl
Format version:        1.1
Flags:                 0x0000
Image blocks:          20539
First boot tag block:  9
First boot section ID: 0x00000000
Key count:             1
Key dictionary block:  7
Header blocks:         6
Section count:         1
Section header size:   1
Timestamp:             483460119000000
Product version:       999.999.999
Component version:     999.999.999
Drive tag:             0x0000
SHA-1 digest of header:
    0x00000000: 49 d6 c3 73 8f a6 fd 2a e9 05 aa f7 e0 90 e7 ef
    0x00000010: 79 ba 54 63
Header digest is correct.

---- Section table ----
Section 0:
    Identifier: 0x0
    Offset:     10 blocks (160 bytes)
    Length:     20527 blocks (328432 bytes)
    Flags:      0x00000001
                0x1 = ROM_SECTION_BOOTABLE

---- Key dictionary ----

Default key was found in key dictionary.

Data encryption key:
    0x00000000: 46 a9 67 2a 46 19 03 68 62 22 30 9f 13 ed 63 02

---- SHA-1 digest of entire image ----
    0x00000000: c0 27 4b 0b 57 c7 68 78 49 ab 8d 04 2f 3e 3c 23
    0x00000010: 14 2d 9d 42
Image digest is correct.

---- Boot tags ----
0000: @ block 000009 | id=0x00000000 | length=020527 | flags=0x00000001
        0x1 = ROM_SECTION_BOOTABLE

[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]

(Probably I link to this page and I update it in the future)

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: [Select]

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
I was under the impression that the software version number is constructed as this:

Code: [Select]

00. - branch number
xx.00. - version number
xx.xx.00. - subversion number
etc. 
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...      

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...

[janekivi]

*****************************************************************************

For playing with your GEL and oscilloscope:

*****************************************************************************
Unbricing the scope may be the first thing.

If something is wrong with app, bootloader don't load it at next boot and all lights are blinking.
You need probably some older and smaller USB flash drive and known good GEL on it to proceed
with boottime update:
http://int.rigol.com/File/ProductSoftWare/20151124/Firmware%20update%20instruction.pdf
(I think the version must be the same or newer, but I update this information if someone report
something new about this)

*****************************************************************************
GEL header is starting with Model number like DS1000Z. Altering this row bring up new text
only in update message and has no other known effect known

*****************************************************************************
Firmware version is presented in GEL header and in all parts headers. They are safe
to change but there are some consequences. Altering it in GEL header second row

Code: [Select]

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 
is resulting message change when scope finds GEL on flash drive. It compares it with version
number from previous SparrowApp.out header which is saved to /SYS/ directory during last
update.
There may be written any number and nothing much happening. Replacing ASCII-ANSI numbers
in main header bring up different update menu messages depending what you have in previous
app header and what  position you change:

Code: [Select]

"A newer software version detected. Update?"
"An older software version detected. Update?"
"The same software version detected. Update?"
"Warning:the software branch is different. Update?"
"A temporary software detected.Update?"
"An official software detected. Update?
In SparrowApp header is version number in HEX

Code: [Select]

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¦=             
00 3D A6 6E - 4040302
If you change something in here, it will be saved and used to compare next software number in GEL
header. For example, if you write there 6D A6 3D 00, it brings up message "A newer software version
detected" after reboot if it sees the same GEL file on the inserted USB.
You can reset your experiments by correcting numbers in all headers and making new update.
But there are no other side effects detected. In system information are all correct number probably
from SparrowApp. So, changing those numbers is making no change in actual software version
and don't allow any downgrade. (We talk about this later)
 
*****************************************************************************
Logo in firmware can be safely modified.
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg984434/#msg984434
In next discussion is covered its format and other details

*****************************************************************************
guiPicData can basically be modified the same way.
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg985362/#msg985362
This is packed file from every graphics used in scope GUI. guiPicData compression is optional.
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg987165/#msg987165

*****************************************************************************
guiResData is explained little bit by konnor
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1478454/#msg1478454

*****************************************************************************


*****************************************************************************
Footer...
Modifying its contents allow you to change app easily. Otherwise you need to match original
CRC32 of SparrowApp.out. This of course can be done with any CRCManipulator which is
adding 4 bytes to the end of the file to achieve desired CRC32.
Simplest footer I found this far is 54 bytes (0x36). It must contain 13 bytes from original and
required attributes.
--------------------------------------------------------------------------------------------
00000000 | 13 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00 |                 
00000010 | 00 00 00 00 0E 30 30 2E 30 34 2E 30 34 2E 30 30 |      00.04.04.00
00000020 | 2E 30 37 B2 5D 43 F6 00 00 00 00 00 00 00 00 00 | .07²]Cö         
00000030 | 00 00 00 00 00 00 00 00 00 00                               |                 
--------------------------------------------------------------------------------------------
First 4 bytes are first part length
Next 4 bytes are first part bitmask ?
Next 4 bytes are second part length
Next 4 bytes are second part bitmask ?
Next 4 bytes are footer length
Next 13 bytes are footer first part - the decoded footer contents
Next 13 bytes are footer second part

My first try was with the same footer length and all its components. I was filling all unused
components with 00. The same way can footer made with any length. As shown here by tv84:
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1479419/#msg1479419

I did test with shorter footer too like:
00000000 | 13 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00  |
00000010 | 00 00 00 00 0E 30 30 2E 30 34 2E 30 34 2E 30 33  |      00.04.04.03
00000020 | 2E 30 32 41 13 AC 82                                               | .02A ¬‚
but this is working probably by reading following zeroes from memory as required
second part data.

Do not change the firmware version higher than you have it in the oscilloscope.
This is going to be your highest version number the scope have used. Firmware with
smaller version number isn't allowed to save. It is best to have it always "your scope
highest version number".
Otherwise you must alter every future update file!

May be there comes handy Rigol SuperFlash which allow you to reset your scope...
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1473517/#msg1473517
I did some tests and it allow you to update any file and version is saved from it.

Best practice is not to use GEL files made by other people from now, make your own!

*****************************************************************************
Downgrade can be very easily achieved by using footer manipulation.
You can take previous firmware file and replace his footer. There must be changed
"your scope highest version number" (see in footer section).
For example:
you have 00.04.04.03.02 in the scope. You take 00.04.04.01.01 GEL file and strip it 280 byte
footer. For new footer you need SparrowApp.out CRC32 from its header at 0x00000280
which you know by looking from header where are file beginning addresses. So it is 41 13 AC 82.
Your scope highest version number = 00.04.04.03.02 so far and new footer must look like:

00000000 | 13 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00  |
00000010 | 00 00 00 00 0E 30 30 2E 30 34 2E 30 34 2E 30 33  |      00.04.04.03
00000020 | 2E 30 32 41 13 AC 82 00 00 00 00 00 00 00 00 00  | .02A ¬‚
00000030 | 00 00 00 00 00 00                                                    |

Nothing else is necessary to change, only footer length in header. There is nothing
serious if you forget this. Afterwards you can reflash 00.04.04.03.02 back.
But if you alter "your scope highest version number" you must alter it again to
allow it to be at least the same as in your previous file.
May be there comes handy Rigol SuperFlash which allow you to reset your scope...
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1473517/#msg1473517
I did some tests and it allow you to update any file and version is saved from it.

Best practice is not to use GEL files made by other people from now, make your own!

*****************************************************************************




... to be continued

[janekivi]

I like to see some more disassembly like from update version calculation.
What is "An official software..." and how they affect update. There are more interesting functions.

I saw function names from konnor DS1000Z-00.04.04.03.02 SparrowApp and made IDA script from it.
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467137/#msg1467137

He made new one, mine is updated too.
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1478726/#msg1478726



I add more here if I found.

[tv84]

Footer deobfuscated (as janekivi explained).

And, now that we understand what is the other int32 in the files header (software branch), here is an updated parsing of all the DS1000 GELs available.

Regarding the update messages showed by the scope when updating, the different msgs are decided by:

if (gelBranch == scopeBranch)
  gelVer == scopeVer -> same FW
  gelVer <  scopeVer -> older FW
  gelVer >  scopeVer -> newer FW

else if (gelBranch > 0)
  gelVer(high16) >=  scopeVer(high16) -> temporary FW
  gelVer(high16) <   scopeVer(high16) -> different SW branch

else
  gelVer(high16) >=  scopeVer(high16) -> official FW           
  gelVer(high16) <   scopeVer(high16) -> different SW branch

[tv84]

Regarding the SparrowBootloader.sb known versions:

BootVersion 0.0.0.11 (GEL 02.00.01.00 02-09-2013) -> SparrowBootloader.sb with creation time: 02-08-2013 12:00:21
BootVersion 0.0.0.12 (GEL 02.01.01.00 31-10-2013) -> SparrowBootloader.sb with creation time: 25-09-2013 13:54:22
BootVersion 0.0.1.0 (GEL 04.00.00.00 18-03-2014) -> SparrowBootloader.sb with creation time: 20-02-2014 12:54:39
BootVersion 0.0.1.1 (GEL 04.01.02.00 28-07-2014) -> SparrowBootloader.sb with creation time: 04-05-2014 19:30:44
BootVersion 0.0.1.2 (taken from a MSO dump       ) -> SparrowBootloader.sb with creation time: 16-09-2014 14:04:36
BootVersion 0.0.1.2 (GEL 04.02.03.00 21-10-2014) -> SparrowBootloader.sb with creation time: 17-10-2014 10:14:44
BootVersion 0.0.1.3 (GEL 04.02.04.07 31-12-2014) -> I haven't yet seen this bootloader!
BootVersion 0.0.1.4 (GEL 04.04.01.01 14-09-2016) -> SparrowBootloader.sb with creation time: 27-04-2015 14:28:39
BootVersion 0.0.1.5 (taken from a dump               ) -> SparrowBootloader.sb with creation time: 16-11-2017 14:03:38

If anyone has others, please post.

The bootloader blocks parsing is attached.

[Shock]

Regarding the SparrowBootloader.sb known versions:

GEL 4.0.0.0 -> SparrowBootloader.sb with creation time: 20-02-2014 12:54:39
BootVersion 0.0.1.2 -> SparrowBootloader.sb with creation time: 17-10-2014 10:14:44
GEL 4.4.1.1 -> SparrowBootloader.sb with creation time: 27-04-2015 14:28:39

If anyone has others, please post.

0.04.04.03.02 2017/02/06 almost suggests it might have the file as the release notes mentioned a bootloader fix, but it's not listed in the header. Have you checked that version?

[tv84]

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

An addon to the explanation of these last 8 bytes:

The model's version (as placed in the GEL's header) is: 00.04.04.03.02

the RED is the software branch
the BLUE is the version number

In the region of the 24-bytes headers, quoted above, the last 8 bytes are:

4 bytes are software version in little endian like 6E A6 3D 00 = 04.04.03.02
4 bytes are software branch 00 00 00 00 = 00

If we look at the whole 8 bytes in little-endian the (4 bytes) branch comes before the (4 bytes) version.

This is important because when we want to upload a "temporary version" (like the one in the attached picture), one must change these "branch" bytes of the SparrowAPP file.

An "official version" appears when there is a previous "temporary version" installed in the scope, and we change the branch to 00.

[janekivi]

0.04.04.03.02 2017/02/06 almost suggests it might have the file as the release notes mentioned a bootloader fix, but it's not listed in the header. Have you checked that version?

As you can see in my parsing file DS1000_parsing_v2.txt, in previous msgs, the only 04.04.03.02 that is publicly available doesn't have a bootloader.

But, someone who has a factory 4.4.3.2 might have a bootloader in it's NAND. So, if they could extract it or from NVRAM...

Then I would assume 4.4.1.1 is 1.3 and the 4.4.3.2 has a 1.4.

Needs to be checked by you guys.

In 00.04.00.00.00 is bootloader 0.0.1.0.
I got mine from factory with 0.0.1.2 and have extracted it from memory here.
From NAND I extracted this 00.04.04.01.01 where was bootloader 0.0.1.4.

Now you need to find out how this is stored there because I can't find it by debuging...

[konnor]

LOAD:41047414 MainProcess                             ; DATA XREF: LOAD:MQX_template_listo
LOAD:41047414                 STMFD   SP!, {R12,LR}
LOAD:41047418                 MOV     R0, BootVersion
LOAD:41047420                 MOV     R1, 0x10010
LOAD:41047428                 STR     R1, [R0]

[Shock]

According to Rigol, these three firmware had associated bootloader:
00.04.00.00.00   0.0.1.0 released on 20140318
00.04.01.02.00   0.0.1.1 released on 20140728
00.04.02.03.00   0.0.1.2 released on 20141021

Then there was:
00.04.02.04.07 0.0.1.? released on 20141231

My scope (build date 2015/03) came with:
00.04.03.00.01 0.0.1.3 released on 20150505

[janekivi]

LOAD:41047414 MainProcess                             ; DATA XREF: LOAD:MQX_template_listo
LOAD:41047414                 STMFD   SP!, {R12,LR}
LOAD:41047418                 MOV     R0, BootVersion
LOAD:41047420                 MOV     R1, 0x10010
LOAD:41047428                 STR     R1, [R0]

So bootloader is writing it into memory? I see app is reading it from somewhere.
Where the version is hidden in bootloader?

[konnor]

The fragment of code(from the loader), what write the version code,  I cited above. I do not know of any other version storage locations in the bootloader. The main firmware simply reads the version from the memory.

[tv84]

I updated my previous post about the Bootloaders versions with the informations shared in these last posts.

https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1481222/#msg1481222

If you see any error or have any of the missing versions (or NAND/NVRAM dumps) please post or pm me.

[tv84]

As konnor suggested (I only suspected ), the bootloader version is HARDCODED in the code (one of the last functions in the block). Here is an extract of the bootloaders that I have:

Bootloader v1.0 - MainProcess
00 50 2D E9                             STMFD           SP!, {R12,LR}
FC 00 A0 E3 7F 0C 80 E3           MOV             R0, #0x7FFC
10 10 A0 E3 40 1B 81 E3           MOV             R1, #0x10010 ; BOOT VERSION
00 10 80 E5                             STR             R1, [R0]

Bootloader v1.2 - MainProcess
10 40 2D E9                             STMFD           SP!, {R4,LR}
00 40 B0 E1                             MOVS            R4, R0
FC 00 A0 E3 7F 0C 80 E3          MOV             R0, #0x7FFC
12 10 A0 E3 40 1B 81 E3          MOV             R1, #0x10012 ; BOOT VERSION
00 10 80 E5                             STR             R1, [R0]

Bootloader v1.4 - MainProcess
10 40 2D E9                             STMFD           SP!, {R4,LR}
00 40 B0 E1                             MOVS            R4, R0
FC 00 A0 E3 7F 0C 80 E3          MOV             R0, #0x7FFC
14 10 A0 E3 40 1B 81 E3          MOV             R1, #0x10014 ; BOOT VERSION
00 10 80 E5                             STR             R1, [R0]

Finally, now we can see the version of a bootloader without loading it into the scope.

[janekivi]

It's funny how we hack all this backwards. I do some dirty hardware hack and then you
disassemble it right way. I have EEPROM there with connector and did flash it in TL866
with different files to see their versions.
Now it is simple. You take SparrowBootloader.sb, unpack it with sbtool, take look at the
right address and all is clear

For example there is my bootloader, version 0.0.1.2
In hex is the main function region with version number.

[mrpackethead]

I'm wondering if anyone has done anything with the most recent MSO5000/7000 and their Gel file? Its looking at bit different from previous versions.

[tv84]

I'm wondering if anyone has done anything with the most recent MSO5000/7000 and their Gel file? Its looking at bit different from previous versions.

It's a simple .TAR file.

[emartine]

Anyone know what's the file that stores the channel colors?
would be great to change the 3rd channel color to red..

I believe channel RGB values are:
ch1: 255, 255, 0
ch2: 0, 255, 255
ch3: 255, 0, 255
ch4: 0, 130, 255

[emartine]

So, anyone knows if there is a chance to change channel colors??
Are they stored somewhere in the GEL firmware file?

Thanks!

[SERJSOCHI]

I tried to recolor CH3 ray, but I was able to recolor only the labels of the left menu Thanks konnor for help with repack. There are no ideas yet on how to change the color.
(tested at ds1054z, base FW 00.04.04.04.03, project folder https://yadi.sk/d/-GBWnMQ16S703g)

[Fungus]

The colors of the trace might come directly from the FPGA.

[pitfermi]

hi. i want to change my boot screen logo from the stock, to an image like  Dave's youtube channel picture. he modded his ds1054z with that picture and i want to do that same thing. what are the steps?

[SERJSOCHI]

hi. i want to change my boot screen logo from the stock, to an image like  Dave's youtube channel picture. he modded his ds1054z with that picture and i want to do that same thing. what are the steps?

Hi.
1. Download Latest RigolPacker.
2. Download Lastest firmware file (for example 00.04.04.04.03).
3. RigolPacker > Open Firmware file.
4. Double click at /sys/logo.hex (/sys/SparrowConfig.hex for MSO version) then click "Show content".
5. Click "Save to file", edit saved picture (I using Paint.Net), click "Change image" and load changed file.
6. Close All windows in reverse order, in main RigolPacker window click "Save firmware file".
7. Copy saved firmware file to USB Flash and update your ds1054z.

if, as a result of a firmware update, the sparrow in your ds1054z is dead, copy original firmware to USB Flash and spam "Help" button while ds1054z booting after power on. CH1 must start blinking.

[pitfermi]

thanks. worked.

hi. i want to change my boot screen logo from the stock, to an image like  Dave's youtube channel picture. he modded his ds1054z with that picture and i want to do that same thing. what are the steps?

Hi.
1. Download Latest RigolPacker.
2. Download Lastest firmware file (for example 00.04.04.04.03).
3. RigolPacker > Open Firmware file.
4. Double click at /sys/logo.hex (/sys/SparrowConfig.hex for MSO version) then click "Show content".
5. Click "Save to file", edit saved picture (I using Paint.Net), click "Change image" and load changed file.
6. Close All windows in reverse order, in main RigolPacker window click "Save firmware file".
7. Copy saved firmware file to USB Flash and update your ds1054z.

if, as a result of a firmware update, the sparrow in your ds1054z is dead, copy original firmware to USB Flash and spam "Help" button while ds1054z booting after power on. CH1 must start blinking.

[alexalr]

Please help with the restoration of Rigol DS1054Z. In the oscillograph there was firmware 00.04.04.04.03, mixed up the update file, instead of DS1000Z downloaded DS1000Z-E versions of 00.06.02.00 01 from here https://www.rigolna.com/firmware/. The set received an update, rebooted and as a result works, but there are no two channels, channels 1 and 2 work. Channels 3 and 4 are not enabled. As I realized - poured firmware for DS1202Z-E. Tried to upgrade with the 00.04.04.04.03 version, but the set does not see the update... Help restore the DS1054Z, please.
Modify message

[tv84]

https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg3097533/#msg3097533

Move from this thread as it is out of topic.

You have 2 solutions: ask Rigol for a FW that solves (their error) or change the FW yourself. There is enough information in this forum on how to change the version number (of the FW package) to allow flashing over a newer one.

[rob040]

I tried to recolor CH3 ray, but I was able to recolor only the labels of the left menu Thanks konnor for help with repack. There are no ideas yet on how to change the color. ...

Hi Serj,

Why would you want to change the colour of the CH3 ray? It now corresponds with the colour used on the front panel.
BTW, I used your software, the one with the simplified GUI, because it's awesome. Thanks for sharing.  I changed the logo pic into this one:

[KK1L]

Great reading and information. I have learned a lot. Was not able to back-level my 1074Z Plus to get a memory dump, but was able to change the boot screen with RigolPacker and some editing. The 1074Z needs a 800x480 BMP, so I resized Rob040's TestBleed.



73 es God Bless de KK1L, Ron <><

[Miti]

Good stuff! I've changed the boot screen to a Matrix theme. Thanks Userli!

[maelh]

I tried to recolor CH3 ray, but I was able to recolor only the labels of the left menu Thanks konnor for help with repack. There are no ideas yet on how to change the color.
(tested at ds1054z, base FW 00.04.04.04.03, project folder https://yadi.sk/d/-GBWnMQ16S703g)

That's exactly what I wanted to do as well, to make it more distinct from channel 4. Anybody made any progress here?

[Fungus]

I tried to recolor CH3 ray, but I was able to recolor only the labels of the left menu Thanks konnor for help with repack. There are no ideas yet on how to change the color.
(tested at ds1054z, base FW 00.04.04.04.03, project folder https://yadi.sk/d/-GBWnMQ16S703g)

That's exactly what I wanted to do as well, to make it more distinct from channel 4. Anybody made any progress here?

I imagine the FPGA is what draws the traces into the framebuffer.

[Ben321]

A bit of OT but, for the record, may be useful to others who want to verify Rigol CRC's:

The CRC-16 that Rigol uses in the DG5000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0x1008 refin=false refout=false xorout=0x0000 check=0xAC1A residue=0x0000 name="CRC-16/RIGOL 1"

The CRC-16 that Rigol uses in the DG4000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0x0528 refin=false refout=false xorout=0x0000 check=0x147D residue=0x0000 name="CRC-16/RIGOL 3"

The CRC-16 that Rigol uses in the DG1000 is a "customized" CRC-16 with the following parameters:

width=16 poly=0xA011 init=0xFFFF refin=false refout=false xorout=0x0000 check=0x5CC1 residue=0x0000 name="CRC-16/RIGOL 4"

Many Rigol equipments use this variation:

width=16 poly=0x1021 init=0xEBCC refin=false refout=false xorout=0x0000 check=0x6809 residue=0x0000 name="CRC-16/RIGOL 2"

And, other Rigol equipments (that include a CRC-16), use the more common:

width=16 poly=0x1021 init=0xFFFF refin=false refout=false xorout=0x0000 check=0x29b1 residue=0x0000 name="CRC-16/CCITT-FALSE"


Edit1: Included a parsing of many Rigol file types (showing the CRCs).
Edit2: Added Rigol 2 CRC16 type.
Edit3: Added Rigol 3 and 4 CRC16 types.

How did you get those specs for the CRCs? Is there software you can run that takes as input a known piece of text and its CRC value, and can output the parameters needed to generate that CRC value from the known text?

[tv84]

How did you get those specs for the CRCs? Is there software you can run that takes as input a known piece of text and its CRC value, and can output the parameters needed to generate that CRC value from the known text?

I have my own tool but a good inspiration is here.

[trmntr]

I added the possibility to see the boot loader details to RigolPacker.

Hello. Do you have such a utility for working with ds1102z-e?