Products > Test Equipment

Rigol DSXXXX .GEL firmware file format

<< < (15/38) > >>

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... :-/O


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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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