Products > Test Equipment

Siglent .ads firmware file format

<< < (48/85) > >>

tv84:

--- Quote from: cguareschi on October 21, 2018, 05:13:01 pm ---
--- Quote from: tv84 on October 21, 2018, 01:27:19 pm ---You are not studying the parsings hard enough.

SDS X are Blackfin machines with a specific format.

SDS X-E are ARM machines with a totally different format (see parsings).

Most files usualy have 2 encrypted blocks plus an encrypted file header but SDS X, for example, have no encryption.

--- End quote ---

I am reading the parse result for 1004X-E firmware this is my understanding, please correct me if wrong:

first 0x70 bytes is an encrypted header.
is the header size a known constant length to is it somewhere at some known offset in the file?
is the header encrypted with 3des? if so where do I find the key, is mode EBC, CBC, initial value for CBC?  Are these known parameters or are somewhere in the ADS file?

Read thread three times and can't find this info, just a hint that the key was in the ADS file but it was a different firmware

Thanks for helping out

--- End quote ---

For SDS X-E file header is always 0x70 bytes.
Yes it's encrypted with the same key and the key can be found in the .APP file. Once you have your decryption running you can compare it with my parsings and you'll discover the encryption mode.

cguareschi:

[/quote]
For SDS X-E file header is always 0x70 bytes.
Yes it's encrypted with the same key and the key can be found in the .APP file. Once you have your decryption running you can compare it with my parsings and you'll discover the encryption mode.
[/quote]

Ok cant read .APP file. Not there yet.

So the algorithm should be:
- read file as a byte array
- save first 0x70 bytes header
- save remaining data bytes
- reverse the remaining data bytes
- apply first XOR to data bytes with incrementing index as described by janekivi
- apply second XOR to second half of data bytes

Now I should be able to see .APP in data bytes

- get 3des parameters from data
- 3des decrypt te saved header bytes  with above parameters

Am I on the right track?
I wrote a python script to just do that but the result still seem garbled bytes (i.e. cant see .APP)

Thanks for your guidance

cguareschi:
Ok. I am getting a bunch of zipped files in the first half of the reversed xored data, the second half is unintelligible, making me think that I am screwing up the second XOR pass from half point on, although that's difficult to screw up but ...

cguareschi:
this seems correct, however I cannot get a complete zip file. The central directory at the end is only half there and is incomplete. Trying to figure out what I am doing wrong

cguareschi:

@vt100 I followed your instruction to the letter. I can launch sds100.app under busybox, I seem to be able to enable crash core dumps with ulimit -c unlimited, but when I kill sds1000.app with ABRT signal, no core dump is generated, the app is just killed. ulimit -c shows unlimited so core dumps  should  be enabled. My firmware is .25R2. Any other way to trigger a core dump? Is it possible core dumps are disabled on this particular version of Busybox?


Thanks

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