Siglent .ads firmware file format

[SMB784]

Great news. Congrats!!!

Thanks!! Color me impressed with all the efforts in this thread.

Thanks again yall!

[tv84]

As I've told SMB784, I advise all to:

1st option - Instead of the official OS install, install janekivi full OS file. It's exactly the same thing with the pwds already changed.

2nd option - After installing the official OS, when you install janekivi patch, do it only with the rootfs file (and the script .txt, of course).

Less operations, less risk!

Regarding the advice of CustomEngineerer about the login problem: thinking of it, it was totally right and not an insult, it could have been a problem with the client  SMB784 was using to connect to the scope. Although SMB784 was able to see the correct prompt, there was no assurance that what he writes in the console was correctly/transparently being sent to the scope.

A solution could have been to change the client (I usually use Putty) or investigate what was introducing garbage in the connection.

Or, in the extreme, use (in his case) the RPi as a gateway to telnet to the scope...

Glad it is solved! Now, time for upgrade. 

[SMB784]

As I've told SMB784, I advise all to:

1st option - Instead of the official OS install, install janekivi full OS file. It's exactly the same thing with the pwds already changed.

2nd option - After installing the official OS, when you install janekivi patch, do it only with the rootfs file (and the script .txt, of course).

Less operations, less risk!

Regarding the advice of CustomEngineerer about the login problem: thinking of it, it was totally right and not an insult, it could have been a problem with the client  SMB784 was using to connect to the scope. Although SMB784 was able to see the correct prompt, there was no assurance that what he writes in the console was correctly/transparently being sent to the scope.

A solution could have been to change the client (I usually use Putty) or investigate what was introducing garbage in the connection.

Or, in the extreme, use (in his case) the RPi as a gateway to telnet to the scope...

Glad it is solved! Now, time for upgrade. 

As it turned out in my case, the problem wasn't the telnet, rather it was the act of copying the files from the computer to the flash drive.

I tried telnetting into the scope from the RPI with the software installed from files copied over using my desktop and couldn't log into the scope. But as soon as I copied the files over to the USB using the RPI, the scope recognized them and correctly installed the custom software, and at that point I could log in via telnet from either the RPI or the desktop.

So something was going wrong in the process of making the USB with the custom software on it when using the desktop. I have no earthly idea what could have been going on though.

In my case, using RF-loop's instructions worked perfectly once I performed them using the RPI to make the USB instead of the desktop.

[BillB]

As it turned out in my case, the problem wasn't the telnet, rather it was the act of copying the files from the computer to the flash drive.

I tried telnetting into the scope from the RPI with the software installed from files copied over using my desktop and couldn't log into the scope. But as soon as I copied the files over to the USB using the RPI, the scope recognized them and correctly installed the custom software, and at that point I could log in via telnet from either the RPI or the desktop.

So something was going wrong in the process of making the USB with the custom software on it when using the desktop. I have no earthly idea what could have been going on though.

In my case, using RF-loop's instructions worked perfectly once I performed them using the RPI to make the USB instead of the desktop.

Congrats!  Figured it wasn't telnet, as you could correctly type "root\r".  I guess if you wanted to be sure the pwd characters you were typing were correct, you could have typed them into the user field to see them. 

Anyway, what is odd, is that you were able to correctly generate the factory OS update USB configuration.  Was that the same process that didn't work for your attempt with the modified OS update? 

[tv84]

As it turned out in my case, the problem wasn't the telnet, rather it was the act of copying the files from the computer to the flash drive.

Remember why I asked you to make sure the CRC of the files (in the flash drive) was correct... 

For sure, next time you'll remember!

[SMB784]

Anyway, what is odd, is that you were able to correctly generate the factory OS update USB configuration.  Was that the same process that didn't work for your attempt with the modified OS update?

That is correct, I used the exact same process on the same computer to generate the modified OS update USB configuration as the one I used to generate the factory OS update USB configuration.  The factory USB configuration worked, and the modified USB configuration didn't.

Then when I generated the modified USB configuration on my RPi, it worked right away.  It's very strange.

Indeed, TV84 was probably correct in his advice that I check the CRC values.  I didn't actually check them, because I was in the process of learning how to check them when I tried making the USB on the RPi.  However, it seems strange to me that the simple act of copying the files over to the USB on one system would change the CRC values of those files when doing that exact same process on a different system does not modify them in any way.

Anyways it was a fun, albeit frustrating experience, with a rather bewildering but ultimately satisfying end result.  Thanks again to all of you who helped me.

[tv84]

Updated my parsing list of all Siglent FWs.

Now we can see the extra details of the files used in the ZIPs.

The only UID/GID combinations are:

1000/1000
65534/65534 (only in some SDG800 .ADS when the rw_uImage is used)

[kerouanton]

thank you all especially janekivi and tv84 for reversing the .ads file format.
I'm still new at that and as I'm learning Python it motivated me to reimplement the decoding process. I followed the steps described on some of your posts, but I am still far from what tv84 outputs in his parsing list.

Up to now, I am able to :
1. extract a .ads file from the downloaded zip file and load it in memory.
2. calculate the checksum
3. reverse the bytes
4. xor it with increasing pattern
5. xor it from the center
6. save the result

What should be the next steps, for example to locate and isolate each part?

[janekivi]

Next you need probably put this before reverse and XOR
https://www.eevblog.com/forum/testgear/siglent-ads-firmware-file-format/msg984820/#msg984820

to get SPD3303X-E_1.01.01.02.05-EN.hex

like there, inside is the same jpg image starting at 0x00024D68
https://www.eevblog.com/forum/testgear/siglent-ads-firmware-file-format/msg1181598/#msg1181598

[kerouanton]

Let's take a look in SDG1000-V100R001B01D01P31.ADS for example

I am trying to move forward on my python .ads decoding script, but as a newbie I'm a bit lost and expect to rely on janekivi replies to see if I'm able to get the same results. For this, I need this exact SDG1000-V100R001B01D01P31.ADS file, but I wasn't able to find the correct download URL, both on siglent.com, siglentamerica.com, and old.siglentamerica.com.
Has anyone the download url, so I can move forward and try getting the same results on my script?

Also, as far as I understood, some parts of the file are 3des encrypted (some parts only as with my actual script I am able to get clear-text strings such as model number, at least on the SPD3303 .ads file), but I'm still unable to understand how janekivi found the right offset and length of the encrypted part, as well as the key itself. The method used to investigate and find those is challenging for me!

As both of you, I'm just playing around with those files for fun, as I try to learn Python and nothing more (well, having a root access on my devices is fun too).

Thanks

[janekivi]

Oh crap. I could have let you to walk the same way. But you can test my theory and find those
patterns and XOR regions and crypted places. It was straightforward because inside was zip.
Some stuff you can find by scrolling id up and down in "notepad", because XOR FF pattern is
easily visible in 00 regions and in other places data is looking so alien. Crypted parts I found
simply by unziping it by cutted pieces to see if output ends now as it ends by unziping full file.
If output was shorter - I did cut file too early, if output was the same - my piece was longer
or right size, then I shortened it by one byte for test. With this method I found exact places
without decompiling update file reading part in app. I don't know can I now find something
like this with IDA... probably no, I would use notepad and calculator, maybe a little bit python.

I didn't cut the header off - 72 or 112 bytes and after reverse it was at the end, that's why
there was offset in file center calculation (j = len(b)/2-36) or (j = len(b)/2-56)

[tv84]

The file is attached.

The 2 encrypted blocks have 0x2800 and 0x1400 sizes, as my parsings show. It shouldn't be too dificult to find where they are located. The key is available inside an .app file.

Study what janekivi linked (the 3DES implemented is "Siglent 3DES", not standard 3DES).

Have fun!

[kerouanton]

Thank you both of you for your kind answer, and the file.

I will keep you informed of my findings! it is like a puzzle game, indeed.

[PhilipPeake]

This may be common knowledge, but I was about to try fixing the root password for my SDS1102X running SDS1000X_V100R001B01D02P1510.ADS, and discovered that there is no telnet service running. Only Ports 111 and 9009.

So much for my idea of trying to upgrade the bandwidth - at least until there is enough progress here to decode and re-assemble the entire thing.

[BillB]

This may be common knowledge, but I was about to try fixing the root password for my SDS1102X running SDS1000X_V100R001B01D02P1510.ADS, and discovered that there is no telnet service running. Only Ports 111 and 9009.

So much for my idea of trying to upgrade the bandwidth - at least until there is enough progress here to decode and re-assemble the entire thing.

The same with the SPD3303X-E.  Open ports 111,9009 and no telnet.

[markus_jlrb]

Philip,

In Linux and in a sh, bash
shell enter the cmds below.

echo *IDN? > /dev/usbtmc0

or other SCPI commands

in one window

and

while true
do
cat /dev/usbtmc0
sleep 1
done

in a second window.

While the scope is connected via USB
and not LAN.

USBTMC must be enabled in the utility
menu under IO selection.

Good luck for your investigation
Markus

[janekivi]

https://www.siglentamerica.com/service-and-support/firmware-software/dc-power-supplies/#spd1000x-series

This was long time ago, but not in the table yet
https://www.eevblog.com/forum/testgear/siglent-ads-firmware-file-format/msg1364981/#msg1364981

[tv84]

https://www.siglentamerica.com/service-and-support/firmware-software/dc-power-supplies/#spd1000x-series

This was long time ago, but not in the table yet

Hi janekivi,

Now it's in the table but, since it's the first without the minimum size for 2nd 3DES block decryption, there is a little detail that I haven't solved - Section Checksum.

According to that section the correct checksum should be 0xFEE2D1B1.

Code: [Select]

File Header Size: 00000070
00000000 - File Checksum: FE691817 [00000004-0002FB6F] (with only the File Header decrypted)  CKSM OK
00000004 - File Size: 0002FB00 (without 0x70 bytes of the File Header)
0000000C - Product_ID: 600
00000026 - Vendor/Brand: SIGLENT
0000003A - USB Host Controller: ISP1763
****************************************************
Decrypting the 0x2800 and 0x1400 blocks...
Reversing file...
XORing with 0xFF (incrementing pattern)...
XORing with 0xFF from 0x00017D80 until 0x0002FAFF
****************************************************
00000000 --- Section Checksum: FEE2D1B1
00000004 --- Section Size: 0002FACC [00000034-0002FAFF]  CKSM OK
00000008 --- Section # 00000007
00000034 --- 0002FAFF  ***** STM32 32-bit ARM Cortex file *****
00000034 - Vector Table:        (Little Endian - Flash(ROM): 0x08000000 - SRAM: 0x20000000)
00000034 ---        Initial SP value: 200193F0
00000038 ---                   Reset: 0802039D  (Thumb 16/32 bits)
0000003C ---                     NMI: 080203C1  (Thumb 16/32 bits)
00000040 ---              Hard fault: 080203C3  (Thumb 16/32 bits)
00000044 --- Memory management fault: 080203C5  (Thumb 16/32 bits)
00000048 ---               Bus fault: 080203C7  (Thumb 16/32 bits)
0000004C ---             Usage fault: 080203C9  (Thumb 16/32 bits)
00000050 ---                   Rsvd1: 00000000
00000054 ---                   Rsvd2: 00000000
00000058 ---                   Rsvd3: 00000000
0000005C ---                   Rsvd4: 00000000
00000060 ---                  SVCall: 080201B9  (Thumb 16/32 bits)
00000064 ---          Rsvd for Debug: 080203CD  (Thumb 16/32 bits)
00000068 ---                   Rsvd5: 00000000
0000006C ---                  PendSV: 080201E9  (Thumb 16/32 bits)
00000070 ---                 Systick: 080203D1  (Thumb 16/32 bits)
00000074 --- IRQ0 to IRQ80  [00000074-000001B7]
****************************************************
  File Processed OK

Edit1: SOLVED the decryption of the partial 3DES block. So, in order to verify the 2nd DES block decryption we must consider that the last block was padded with all 0x00s (to complete a 8-bytes block), before 3DES encryption.

[gperoni]

I'm trying to hack my SDG6000X, here is my understanding of what I have to do by giving this thread a fast read:

1) Download a firmware upgrade from Siglent
2) Use tv84's post on the SDG6000X thread to understand where the filesystem begins in the ADS file downloaded
3) I assume the filesystem is encrypted? If so decrypt it (silly xor patterns or something), once decrypted mount the filesystem and change the shadows file.
4) Change the checksum, I wouldn't know where to find it or the crc32 init, etc.
5) Re-make the filesystem, encrypt it, put it back in place, use the resulting ADS for a firmware upgrade and get root access
6) - Will figure something out.
7) Profit.

What are the tools I should use in the process? I saw a couple of scripts and programs but they don't seem to be complete, should I write my own?

[janekivi]

You must get something like this at the end
SDG6000X_eevblog_29R10.zip
I do it by hand, use notepad and hexedit and have too many steps in multiple laptops...
this is messy process...

[bluejedi]

If I remember correctly, the OS update was previously listed on the download page as:

    SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 05.22.18)

but is currently listed as:

    SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 06.26.18)

[rf-loop]

If I remember correctly, the OS update was previously listed on the download page as:

    SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 05.22.18)

but is currently listed as:

    SDS1004X-E Operating System -V1 (Only For 4-Channel ) (Release Date 06.26.18)

I have not checked how these older and more new files match but one I know. Instructions pdf is tiny bit edited. I have not compared all files but I have some "feel" they are equal.

But who use these when we have something "better" like SDS1004X-E_OSV1_EN_eevblog

[tv84]

If you look inside, it seems they changed only the:

SDS1004X-E OS Revise History and Update Instructions.pdf

[tv84]

New firmware for SVA1015X
V2.1.1.1.12a
https://www.siglentamerica.com/download/6912/
38.8 MB

Changelog
2018/8/8
1. Spectrum Analysis mode：Improved the stability of sweep and interface.
2. VNA mode: fasten the VNA sweep speed; expand the minimum span from 10M to 10 kHz.
3. Modulation Analysis mode: add trigger, optimize the modulation analysis algorithm.
4. Add user port number selection for web server.

Product_ID 11401 (that was ripped from original FW) confirmed!! 

[radiolistener]

This may be common knowledge, but I was about to try fixing the root password for my SDS1102X running SDS1000X_V100R001B01D02P1510.ADS, and discovered that there is no telnet service running. Only Ports 111 and 9009.

So much for my idea of trying to upgrade the bandwidth - at least until there is enough progress here to decode and re-assemble the entire thing.

I investigated it here: https://www.eevblog.com/forum/testgear/siglent-sds1000x-how-to-make-direct-ethernet-connection/msg1650191/#msg1650191

The port 111 is getport, it is used to obtain VXI-11 protocol port and returns 9009 port.
The port 9009 is VXI-11 protocol port.

I implemented VXI-11 protocol in C#, so you can use it to send SCPI commands with no need to install NI VISA runtime.
The example in C# takes oscilloscope screenshot with SCPI command.