Siglent .ads firmware file format

[tautech]

I have ordered an SDS 1204x-e,..............

As many here may be aware, this instrument has been recently reported to have security issues by online security forums. 

Correction if I may, those issues are unconfirmed for SDS1004X-E models. Only SDS1202X-E are implicated as having WLAN security issues.....which may or may not effect all manner of test equipment and brands.

[ewaller]

As I said, I've not my instrument yet, but...

Does the instrument not open a Telnet port?  Does it not ask for a root password when attempting to log in via telnet?  Is there not a hashed entry in /etc/passwd for which there is a password that is not well known?  Does replacing that hash with that for a known password not permit one to log in using that well known password?  If these are yes, this instrument is vulnerable.

Note that I am asking these questions as it is my intent to root this instrument; but I am trying to determine which tack I want to take.  I might add that I choose to do this purely for intellectual curiosity.  I do fully intend to buy appropriate licence keys when and if I choose to add options.

[rf-loop]

As I said, I've not my instrument yet, but...

Does the instrument not open a Telnet port?  Does it not ask for a root password when attempting to log in via telnet?  Is there not a hashed entry in /etc/passwd for which there is a password that is not well known?  Does replacing that hash with that for a known password not permit one to log in using that well known password?  If these are yes, this instrument is vulnerable.

Note that I am asking these questions as it is my intent to root this instrument; but I am trying to determine which tack I want to take.  I might add that I choose to do this purely for intellectual curiosity.  I do fully intend to buy appropriate licence keys when and if I choose to add options.

There is normal telnet port 23 open.
For access to system you need know user and password.
You can try bruteforce these using telnet connection and loose your rest limited life time or scope limited life time. Which one is first reached.  But if you are lucky of course randonmly it may open this worm can tomorrow... who knows.
But there is other way... I will recommend you now take some time for carefully read this forum and you soon hit how all works (tip, first you need change other OSV in scope (and after then "close door" changing original genuine OSV with unknown usr/pw back to scope) = "RTFM" (what is scattered around inside the forum.)

There is also other ports open for use SCPI commands.
https://www.siglentamerica.com/application-note/verification-lan-connection-using-telnet/

Also of course for web server.

[tv84]

Two questions:  First, I cannot find where you have conveyed what these scripts specifically do.  Would you state what it is they do?  Second:  Have you automated the process of creating an ads file?

1. These X-E specific .ADS have an update.sh script that is run to accomplish the installation.
2. You could say semi-automated.

The best way to protect the equipment is to leave outside the internet. Of course if you have a rogue colleague in the lab...

You cannot change the pwd since the FS is RO. To change the pwd you need to patch the FS and flash it again. That's what janekivi usually creates for forum members.

All your other indications seem correct and have been used/implemented...

PS: As rf-loop says, for someone who reads carefully, the info is already in the forum.

[ewaller]

TV84,

I am not overly concerned about security for my instrument.  It will be on my private Lan on a guest subnet jail that I use for my IoT devices .  I have read the threads with interest, and I agree that there is probably enough information here to create an ads file myself.  What is not clear is what those scripts do.  On the surface, they open a new port at 10101 (IIRC) that does not require a password.  Is that what they do?  Is that a transient port that goes away at the next reboot? or is it persistent?  Unfortunately, there is no easy way to audit those files so I would have to trust you as to what they do.

If they open a port with a root session, and it is transient, that would be my preferred method to root the instrument, rather than uploaded the OS image with a modified /etc/shadow. 

[ewaller]

There is normal telnet port 23 open.
For access to system you need know user and password.
You can try bruteforce these using telnet connection and loose your rest limited life time or scope limited life time. Which one is first reached.  But if you are lucky of course randonmly it may open this worm can tomorrow... who knows.

All true and fully understood. 

But there is other way... I will recommend you now take some time for carefully read this forum and you soon hit how all works (tip, first you need change other OSV in scope (and after then "close door" changing original genuine OSV with unknown usr/pw back to scope) = "RTFM" (what is scattered around inside the forum.)

And, I have read the fine manual -- fully -- and I do understand it.  But, if one uploads an OS with a modified /etc/shadow file, then I do know the password -- and so do a lot of other people.  Granted,  a lot of other people who have no access to my instrument.  I would prefer to find a transient solution the leaves the instrument with official firmware that vanishes with the next reboot.  That seems to be that tv84 had been suggesting.   

There is also other ports open for use SCPI commands.
https://www.siglentamerica.com/application-note/verification-lan-connection-using-telnet/

Which is another vector I would consider. It sounds like the SCPI which permits one to execute shell command lines does so as root.  That should provide the necessary privilege escalation to punch a temporary hole. 

[tv84]

I am not overly concerned about security for my instrument. 
...
so I would have to trust you as to what they do.

Contradiction? You are not obliged to trust me. You must weight the pros and cons of what the script allegedly allows you to do - open a transient port with root access, versus not being able to audit the script and continue without access.

Of course, i'm not a TPM so you decide who/what to trust.

If you don't feel comfortable, put it aside and move on.

[ewaller]

You cannot change the pwd since the FS is RO. To change the pwd you need to patch the FS and flash it again. That's what janekivi usually creates for forum members.

I understand that the cramfs is read only and is stored in flash.  Often in systems like this, the file system is shadowed in RAM allowing files to be created and changed in RAM; these files exist in their modified state until the instrument starts the next time and the cramfs is once again copied from non-volatile memory to RAM.  Note that I am not asserting that this is how it is implemented, but it is how I might have expected to be implemented.  If my expectation is correct (could be a long shot ), then it would be possible to change the root password for the duration of the session; reverting to stock after the next restart.

As some background, I am one who does not tend to follow step-by-step instructions where the goal is to merely install as a means to an end.  My goal (and motivation) is to fully understand each step in the process and to consider the best solution.   "Best" is defined by me and is subject to change as I learn; it can be swayed by good arguments too  

[ewaller]

Contradiction? You are not obliged to trust me. You must weight the pros and cons of what the script allegedly allows you to do

Absolutely a contradiction.  Anyone who runs a random script from the Internet without considering and mitigating the risks is a fool.  I fully appreciate, and admire your efforts and have absolutely no reason to not trust you or your contributions.  OTOH, well, it is the Internet.

open a transient port with root access, versus not being able to audit the script and continue without access.

That really is not the choice.   It does answer my question though, thanks. It was unclear whether this was a transient port, or whether the ads script installed something permanent.  Correct me if I am wrong, but these scripts instantiate a port at 10101 that stays open until the next restart, and that after restart, the instrument has stock firmware, unchanged by the script.

Of course, i'm not a TPM so you decide who/what to trust.

If you don't feel comfortable, put it aside and move on.

I am feeling out my comfort level.  And I do trust you.  But I do intend to understand what will happen to my instrument.  At this point, I believe yours to be the "Best" solution in that it seems to not do anything permanent.

[tv84]

Correct me if I am wrong, but these scripts instantiate a port at 10101 that stays open until the next restart, and that after restart, the instrument has stock firmware, unchanged by the script.

I could answer yes but, since I'm not a TPM, you would have to trust me... Do you?

[ewaller]

I could answer yes but, since I'm not a TPM, you would have to trust me... Do you?

Nothing personal, but not fully.   But enough to try your scripts, especially if they make no permanent changes.

Did I miss something that I should have read?  That collection of ADS scripts that open port 10101 kind of popped up out of no where -- and seem like a good approach.  But I really could not discern that they make no permanent changes.   Have I been asking a question that has been asked and answered about whether these scripts make any stored changes?

[vt100]

Nothing personal, but not fully.   But enough to try your scripts, especially if they make no permanent changes.

He's a huge international criminal wanted by the FBI and Interpol. Trust me, you're reading it here on the internet, so, it must be true, right?


Since you can always flash the original firmware back on your scope, what are you worried about? Even if he was a notorious ransomware bitcoin criminal, what's the worst that happens? you flash your old firmware back on the box and you're none the worse for wear.

sheesh.

[ewaller]

He's a huge international criminal wanted by the FBI and Interpol. Trust me, you're reading it here on the internet, so, it must be true, right?

I trust no code downloaded from the internet -- unless things are signed with gpg keys and there is a chain of trust from me to the person who posted the code, or if it is on a site with a trusted certificate of an organization I consider reputable.  Lacking those,  I want to at least be able to read the source code.

And, in no way is this indented to besmirch anyone -- especially not as a new member of a forum -- and certainly not trying to insult a respected member of the said forum.

Since you can always flash the original firmware back on your scope, what are you worried about?

to be honest, I had not even considered rolling back.   Good point.

Even if he was a notorious ransomware bitcoin criminal, what's the worst that happens? you flash your old firmware back on the box and you're none the worse for wear.

Really?   It seems a motivation to perform this seems to be to enable features in the scope that were not enabled out of the box -- including features that cannot be enabled through the licence mechanism of the scope GUI.  Clearly these persist after rolling back to the old firmware.  For example, all 4 channel scopes use the same OS image, regardless of whether they are 100 or 200 MHz instruments.   Loading the modified version, or rolling it back does not impact whether it is a 100 or 200 MHz instrument -- there are other steps that need be done that do persist.   Same is true for the installed licences.   

If something were to corrupt things in this persistent  storage, for whatever reason, rolling back the OS will not fix things.  What else is in that storage?  Calibration factors? Serial numbers? FPGA Firmware?

sheesh.

Edit:
But, I probably will use the ADS files that they had published.  I think the risk is low to modest; certainly if I accept the assertion that these script does nothing but open a root port on 10101 that is transient.

[vtwin@cox.net]

a healthy amount of skepticism is always warranted on a public forum. I would be more concerned if I were dealing with someone without a track record of engaging in very technical discussions and assisting people in the forum.  tv84's bona fides are well established here, he's been a huge help to me (both publicly and privately) and I've never had a concern or encountered an issue running anything he's provided.

[BillB]

From what I hear, tv84 leaves the toilet seat up, and drinks directly out of the milk carton, too! 

Seriously, I've executed most of what he's generated on my equipment and so far nothing nefarious, yet.   

[SMB784]

tv84 and Janekivi are literal wizards.

I'm just a physicist, but I trust them.

[ewaller]

tv84 and Janekivi are literal wizards.

No doubt about it.   

I'm just a physicist, but I trust them.

I have no reason not to either.  I would, however, want to understand what the script does and how it does it before I use it.  I think I know what it does -- and if it does what I think it does, it is brilliant.  When I asked what it does, the answer was "These X-E specific .ADS have an update.sh script that is run to accomplish the installation. ".   That does not tell me what the script is doing, and it does imply that something is being installed.  I pressed further, and got the reply ' could answer yes but, since I'm not a TPM, you would have to trust me... Do you?'.    Okay, it seems I have a choice; for whatever reason,  I am not going to get the details of what the script does or a clear text version of what goes into an encrypted binary that will be uploaded to the update mechanism of my instrument.  Seems I have a choice to make.

I have to confess, I am a little out of my element here.  I have spent a lot of time amongst the Free (as in Libre) software crowd where code comes with the source and information on how to build and modify it.

[janekivi]

There is a little problem, we were hacking Rigol 1054Z and siglent gear with tv84
and only he knows and can trust me - how little I know and can do.
Others here really think I can make a program which does something...

[tv84]

There is a little problem, we were hacking Rigol 1054Z and siglent gear with tv84
and only he knows and can trust me - how little I know and can do.
Others here really think I can make a program which does something...

Modesty! Different methods and expertise but, in the end, the same results.

janekivi has some of the best notepad/calculator there are for these analyses! 

[ebastler]

How to open a telnet session in a Siglent when the root password is unknown?
Use the following scripts, according to each equipment.
They provide a root session via port 10101.

I may be a bit slow here... Those "scripts" are firmware files, to be installed via the regular firmware update procedure, right? And the idea is to install them temporarily, open a telnet session to make the required changes to the config file, and then re-update to the official Siglent firmware?
 
Thanks!

[tv84]

Right. The scripts don"t change anything in the equipment's FW!! It's just a runtime modification.

But the user may use them to make definitive changes... at his own responsibility.

[2N3055]

I got curious and took memcopy (cp /dev/mem) on my SDG6022X.
I got 175 something MB file.
I can't seem to find strings that look like licenses ( 16 chars. all caps and numbers no dashes)
There is a cluster of 128 bytes that looks like license material, but is lowercase+numbers.
There is no existing 200MHz valid lic in there.
Any more hints what to look for?
Thanks.

[Rerouter]

If you can share it via PM, I can have a look.

Equally if you have a copy of the system App, I would be curious to have a dig through whats buried inside.

[vtwin@cox.net]

I got curious and took memcopy (cp /dev/mem) on my SDG6022X.
I got 175 something MB file.
I can't seem to find strings that look like licenses ( 16 chars. all caps and numbers no dashes)
There is a cluster of 128 bytes that looks like license material, but is lowercase+numbers.
There is no existing 200MHz valid lic in there.
Any more hints what to look for?
Thanks.

Should probably move these ancillary posts to a new thread, they've gotten off topic quite a bit, however, that said, a 175MB file sounds kind of odd in terms of memory size... although 176 is a multiple of 4 so I suppose it could be correct... but, that said, my SDG6000 bandwidth license and IQ Function license are both 16-character uppercase values. How did you obtain the memdump?

[2N3055]

Should probably move these ancillary posts to a new thread, they've gotten off topic quite a bit, however, that said, a 175MB file sounds kind of odd in terms of memory size... although 176 is a multiple of 4 so I suppose it could be correct... but, that said, my SDG6000 bandwidth license and IQ Function license are both 16-character uppercase values. How did you obtain the memdump?

As I wrote,  "cp /dev/mem" into file on the usb drive.. Beauty of UNIX, everything is a device...
I wasn't exact on filesize, exact filesize is 174080 bytes . 170 MB exactly.
Regards