Siglent .ads firmware file format

[fenugrec]

So I've been poking at the .ads update file for SDG1000X plus, in particular P43R8 , and I think there are minor tweaks (again) to the .ads format, and I'm not done figuring it out.

I wish I had found this thread sooner; would have saved a few hours...

My process so far :
- reverse all bytes of .ADS file
- xor 0xff on bytes at offsets +0,1,3,6, etc. (nothing new here)
- xor 0xff on last "half" of the file

The last steps helps, but is not perfect : 7z complains

Code: [Select]

Path = SDG1000X_Plus_P43R8.SDA.zip
Type = zip
ERRORS:
Headers Error
Unconfirmed start of archive
WARNINGS:
There are data after the end of archive
Physical Size = 22809189
Tail Size = 1762
Characteristics = Local

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2025-07-15 01:43:30 D....            0            0  firmdata0
2024-08-19 04:05:25 .....          497          240  firmdata0/NSP_trends_config_info.xml
2025-07-15 01:43:30 D....            0            0  img
2025-07-15 01:43:30 .....     25821184     18762362  img/siglent.img
2025-03-16 20:12:06 .....        15252         4030  img/devicetree.dtb
2025-03-16 20:12:06 .....      3626512      3601591  img/uImage
2025-03-16 20:12:06 .....      2762796       440447  img/BOOT_tmp.bin
------------------- ----- ------------ ------------  ------------------------
2025-07-15 01:43:30           32226241     22808670  5 files, 2 folders

and there is evidence of corruption in img/siglent.img ; some weird plaintext strings with bad characters.
While extracting files, siglent.img causes a "CRC error", and BOOT_tmp.bin a "Data error".
The 'PK' chunk headers for all of those files look fine, except the last (BOOT_tmp.bin) : it declares a compressed size of 440447 (0x6b87f), but at the end of that chunk, there is still 0x6e6 bytes left of high-entropy, with no header or visible structure.
I'm wondering if there's a subtle difference in the XOR strategy. Also since I see so much plaintext in the extracted files, it's not clear if / where there is a block of "DES" encrypted data at all ?

Has anyone else looked into these more recent .ads files ?

[tv84]

There is a DES block in there. You have to decrypt it in order to have a 100% working zip. There's info in the forum that shows where.

[fenugrec]

There is a DES block in there.

Thanks tv84 for this and your previous posts in this thread. I was hoping they "forgot" to do their DES trickery in this one, since I couldn't see any obvious trace that there was any, but it looks like I'll have to dig some more.
It's odd that they would only cover... a very late part of the .zip ? just to cover the .zip "central file directory" structure and mangle some data I guess.

[EDIT] ugh, I had an off-by-one error in my python garbage, which I only discovered after re-writing the whole thing in C. I'm trying hard to convince myself that the X hours digging in .zip and ubifs file format internals were "educational"

[TERRA Operative]

Take a look at this, see what you guys think?

https://github.com/JaredCabot/siglent-ads-format

[tv84]

Take a look at this, see what you guys think?

 

"The lesson worth recording: standard permutation and S-box tables do not imply a standard cipher. The three inner-loop deviations of Chapter 4 are invisible in the tables and are only found by reading the round logic. This is the trap that gave the format a reputation for being only partly recoverable; it is fully recoverable."

   The stuff I teach Claude is running out...

[TERRA Operative]

Claude is getting good. Even a software Luddite like me can get stuff done (And by that I mean I can poke Claude to do stuff for me).

[TERRA Operative]

Changed my ADS github repo to https://github.com/JaredCabot/siglent-ads-format to keep the ADS stuff separate from the instrument specific repos.