Siglent SDS1104X-E Hack to 200Mhz， and full options ?

[Gege34]

I agree with you (specially vtwin@cox.net) that this is not the most reliable way to find the keys, but it is the simplest and it works for a majority of people.
And to improve the chances of success of this method, it is recommanded to do it (the dump of the memory) on an oscilloscope which has just been powered on.

[ian.ameline]

English:

It should be noted, and bears repeating, that this process only works if your option keys do not span a 4K memory page boundary. If they do, you could find a portion of a key is located 10's of megabytes away in the memory dump from the rest of the key.

cat /dev/mem simply dumps the scopes physical memory, and memory malloc'd by the linux kernel to the scope task may or may not be contiguous within physical memory.

True, but it seems many have been lucky in finding keys using this method (myself included). And also, it might be possible to just reboot and retry if not successful the first time, since the memory allocations might not be exactly the same for every boot and application launch.

There is also the fact that the memory allocator will most likely return memory aligned on 16 byte boundaries (to accommodate neon vector types). This makes it impossible for anything 16 bytes or under to cross a page (4k) boundary.

[vtwin@cox.net]

There is also the fact that the memory allocator will most likely return memory aligned on 16 byte boundaries (to accommodate neon vector types). This makes it impossible for anything 16 bytes or under to cross a page (4k) boundary.

My scope returned memory keys not aligned on a 4k boundary.... in one instance, 12 bytes of the key was in one 4k segment, and the remaining 4 bytes of the key were located 20+ megabytes earlier in the memory dump. It was also pretty consistent in this regard, where I would get 8 or 12 bytes in one 4k chunk and have to go look for the remaining portion elsewhere at the start of a 4k chunk. I created 10 cold-start dumps with various delays upon startup to see how the delay time, or things I did on the scope's panel) affected the placement of the keys.

(of course I also was not using the SHELLCMD method to gain root access... I used version of the firmware with the "known" root password to get to a telnet prompt the "old" way, before the SHELLCMD bypass was known, so this may have played a role too.)

It is good the "simple" method works for a large number of people... but new people reading the thread should simply be aware the "simple" method may not always work and to be prepared for the possibility of a "deep dive".... that's all.

[HookEm]

@Gege34: Thanks for the excellent 14-step summary:
https://www.eevblog.com/forum/testgear/sds1104x-e-hack-to-200mhz-and-full-options/msg2258400/#msg2258400

@vtwin@cox.net: In my case, you were proven correct!
My Option keys were broken apart: I only found 24 characters (1 complete key + 1/2 of another) at the expected "simple method" location. So I wrote a small C-program to parse the dump file, looking for the other 24 characters (uppercase letters or decimal numbers) at the start of each 4K-page boundary. It turns out that I only found 4 hits in the 240+MB file, so eye-balling each case with a Hex-editor was a very reasonable task!

Wow, I'm so glad I went with 1104X-E... This forum rocks!

[tv84]

My Option keys were broken apart: I only found 24 characters (1 complete key + 1/2 of another) at the expected "simple method" location. So I wrote a small C-program to parse the dump file, looking for the other 24 characters (uppercase letters or decimal numbers) at the start of each 4K-page boundary. It turns out that I only found 4 hits in the 240+MB file, so eye-balling each case with a Hex-editor was a very reasonable task!

That's what I call doing your homework! 

[KungFuJosh]

@vtwin@cox.net: I wrote a small C-program to parse the dump file, looking for the other 24 characters (uppercase letters or decimal numbers) at the start of each 4K-page boundary. It turns out that I only found 4 hits in the 240+MB file, so eye-balling each case with a Hex-editor was a very reasonable task!

Any chance you'd share that program?

Thanks,
Josh

[KungFuJosh]

English:

• Have a USB stick that is recognized by the oscilloscope (make a screenshot on it to try)
• Connect to the oscilloscope with the web interface
• In the SCPI tab, send the command SCOPEID? and note the result, it is like wwww-xxxx-yyyy-zzzz
• Send the command *IND? to get the serial number like SDSxxxxxxxxxxxx
• Send the command SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin
• Wait a while for this command to finish (we will say 1mn, there is 240MB to write on the USB stick)
• Put the USB stick on a computer, there must be a file memdump.bin
• Open this file in a Hex editor (I use HxD on windows)
• Find your SCOPEID without the - (so wwwwxxxxyyyyzzzz)
• We must have just before a 100M (or 200M according to its oscilloscope), it's the active bandwidth and still a little (37 characters) above SDS1000X-E
• A little lower (116 characters) there must be letters, in fact 2 groups of 16 characters and one of 32 characters (that we cut in half), which makes us 4 groups of 16 characters corresponding to the key to activate the bandwidth option (respectively 100MHz, 200MHz, 50MHz, 70MHz)
• To activate the corresponding license it is necessary to send the command SCPI MCBD key and to turn off/on again the scope
• Start again from the beginning of the file and look for its serial number (SDSxxxxxxxxxxxx), search until find the one where it is written MSO 5 characters before
• A little lower (69 or 117 characters) a group of readable characters, there are 3 groups of 16 characters which correspond to the activation key of options, if this key appears 2 times is that it's already active. The options are respectively (AWG, WIFI, MSO) and can be activated with the command SCPI LCISL option,key

An interesting SCPI command to explore the scope (warning to not brick it), SHELLCMD telnetd -l/bin/sh -p9999 open a telnet (root shell) without password.

I tried this with firmware 7.1.6.25R2 and it didn't work well at all. The keys in my memdump file were reversed, or in different areas, making it very difficult to guess the correct order and corresponding function of each key.

After upgrading to firmware 7.1.6.1.26 it worked perfectly. The bandwidth keys and options keys were all correctly oriented, and exactly where they should be.

I installed all the option keys via SCPI, and they immediately became active/permanent without need to restart the scope. After restarting, the permanent keys are still working.

This gives me the impression that Siglent was trying to make it easier to hack the keys.

Side note: there was reference in my 25R2 memdump to Pikachu for some reason. 

Thanks,
Josh

[bloomingtonmike]

In the above post the serial number command is *IDN? Btw.

Thank you everyone for the reassurance. Mem dump and scpi commands worked great just as Josh said.

[KungFuJosh]

In the above post the serial number command is *IDN? Btw.

Thank you everyone for the reassurance. Mem dump and scpi commands worked great just as Josh said.

The serial number is also listed on the home screen of the Siglent web interface...so no effort really needed there with SCPI.

Glad it worked for you too. 

[bloomingtonmike]

Home screen is where I got it too Josh. It was just bugging me why I could not get the serial number back from the scpi interface so I looked it up. Just a typo.

[KungFuJosh]

lol, I was clearly lazier than you about it. I saw it on the home screen, and grabbed it before I tried any of the commands.

[Rerouter]

Its not that they are making it easier, Its more a case of a lot of people digging into whats happening to try and resolve there own desires and along the way finding odd quirks that benefit the whole.

Its like a school network admin Vs a school of high schoolers, one side is busy with other things, the other is full of hundreds or thousands of bored people with nothing better to do

So off I go running a incrementing character search on SCPI up to 12 characters because I wanted to find command for Bode plot mode, ended up digging up a lot in the process, didn't find the command and so went on to disassembling the system application to see if there was any way to add it, found more commands in the process and finally found a work around.

Then used some of his finding to try and help someone copy off a file of interest and a linux guru jumped up and thought, "lets try and dump the memory manually with this command some guy has shown us how to use." and here we are today.

[KungFuJosh]

Its not that they are making it easier, Its more a case of a lot of people digging into whats happening to try and resolve there own desires and along the way finding odd quirks that benefit the whole.

Its like a school network admin Vs a school of high schoolers, one side is busy with other things, the other is full of hundreds or thousands of bored people with nothing better to do

So off I go running a incrementing character search on SCPI up to 12 characters because I wanted to find command for Bode plot mode, ended up digging up a lot in the process, didn't find the command and so went on to disassembling the system application to see if there was any way to add it, found more commands in the process and finally found a work around.

Then used some of his finding to try and help someone copy off a file of interest and a linux guru jumped up and thought, "lets try and dump the memory manually with this command some guy has shown us how to use." and here we are today.

Older firmware was significantly harder to get the codes. Newer firmware was simple as hell. There's a significant sequential difference in ease of acquisition based on firmware versions. If that's not on purpose, that would be an insane coincidence.

[tv84]

Older firmware was significantly harder to get the codes. Newer firmware was simple as hell. There's a significant sequential difference in ease of acquisition based on firmware versions. If that's not on purpose, that would be an insane coincidence.

This is not something preplanned. That is the way the kernel is segmenting the processes mem in realtime. If you have that particular memory area in a segment frontier, you may end up with the lics splitted. If the area is in the middle of the segment, then everything will be next to each other.

Of course, based on the average level of expertise of the members, everyone should be able/obliged to find their solution without all these "guides for dummies".

[KungFuJosh]

This is not something preplanned. That is the way the kernel is segmenting the processes mem in realtime. If you have that particular memory area in a segment frontier, you may end up with the lics splitted. If the area is in the middle of the segment, then everything will be next to each other.

Of course, based on the average level of expertise of the members, everyone should be able/obliged to find their solution without all these "guides for dummies".

Why was it being segmented differently only based on the firmware change? I tried dumping the memory more than 10 times with 25R2 and it was never together.

BTW- as a dummy, I dig the guides.

[tv84]

Why was it being segmented differently only based on the firmware change? I tried dumping the memory more than 10 times with 25R2 and it was never together.

Because the program changes makes different memory allocations and, as more memory is (de)allocated, you may end up in a segment border.

And, if you dump before going to the lic menu or dump after trying to register a lic, you'll probably obtain completely different results... 

[KungFuJosh]

Because the program changes makes different memory allocations and, as more memory is (de)allocated, you may end up in a segment border.

And, if you dump before going to the lic menu or dump after trying to register a lic, you'll probably obtain completely different results... 

I tried a number of different routines and timing with 25R2 to get the dump. All the gibberish besides the codes changed, but never the codes.

From what you're saying, it sounds like I could have reflashed 25R2 and had similar results as the newer firmware? I'd be tempted to downgrade and test that theory if not for my laziness and lack of benefiting from it.

[tv84]

From what you're saying, it sounds like I could have reflashed 25R2 and had similar results as the newer firmware? I'd be tempted to downgrade and test that theory if not for my laziness and lack of benefiting from it.

No need to. Different people in this forum have reported different results with the same FW versions. Keep yourself in "laziness and lack of benefiting from it" mode.

[jtruc34]

Well, I'm requesting your help, because I tried the steps Gege34 suggested on my SDS1104X-E, and when I tried to dump the memory on the USB key, nothing happened. What am I doing wrong?

[Illusionist]

Well, I'm requesting your help...

I did that exact procedure myself on a new SDS1104X-E two weeks ago. It worked perfectly for me - couldn't believe it was so simple. Although I did have to search the file twice for the keys because I just didn't recognize them on the first pass.

Are you sure your USB stick is recognzied by the 'scope (two of mine were, one wasn't), and does your 'scope have the latest firmware (6.1.26)? The latest firmware makes a difference, from a quick review of the thread, for finding the keys at least.

When I dumped the memory, the USB stick's light started flashing, but never stopped. Eventually I gave up waiting for it to stop (15 minutes or so) and shut down and pulled it. The file was on there.

[Apofview]

It is *IDN? not IND? it took me a while... 
16GB usb stick worked, no problem, and stick did not have indication led so after dump command I pushed print button to make sure that scope is able to write to usb, scope prints on lcd file written to usb, not sure is this check valid but for me it worked...
scope version 8.1.6.

[KungFuJosh]

It is *IDN? not IND? it took me a while... 
16GB usb stick worked, no problem, and stick did not have indication led so after dump command I pushed print button to make sure that scope is able to write to usb, scope prints on lcd file written to usb, not sure is this check valid but for me it worked...
scope version 8.1.6.

The serial number is also available on the home screen of the web interface, no commands necessary.

[jtruc34]

Are you sure your USB stick is recognzied by the 'scope (two of mine were, one wasn't), and does your 'scope have the latest firmware (6.1.26)? The latest firmware makes a difference, from a quick review of the thread, for finding the keys at least.

Yes, I am sure it is recognised by the scope, since I could save a screenshot on it and then view it on my computer. I suspect it is the path of the USB stick that is wrong, since I tried SHELLCMD echo something > /usr/bin/siglent/usr/mass_storage/U-disk0/something.txt and it didn't do anything and nothing was on the key when I checked on my computer. Or could I find the path in another way?

[Apofview]

English:

• Have a USB stick that is recognized by the oscilloscope (make a screenshot on it to try)
• Connect to the oscilloscope with the web interface (conect scope to net and enable it in the IO tab)
• In the SCPI tab, send the command SCOPEID? and note the result, it is like wwww-xxxx-yyyy-zzzz
• Send the command *IND? to get the serial number like SDSxxxxxxxxxxxx
• Send the command SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin
• Wait a while for this command to finish (we will say 1min, there is 240MB to write on the USB stick)
• Put the USB stick on a computer, there must be a file memdump.bin
• Open this file in a Hex editor (I use HxD on windows)
• Find your SCOPEID without the - (so wwwwxxxxyyyyzzzz)
• We must have just before a 100M (or 200M according to its oscilloscope), it's the active bandwidth and still a little (37 characters) above is SDS1000X-E
• A little lower (116 characters) there must be letters, in fact 2 groups of 16 characters and one of 32 characters (that we cut in half), which makes us 4 groups of 16 characters corresponding to the key to activate the bandwidth option (respectively 100MHz, 200MHz, 50MHz, 70MHz)
• To activate the corresponding license it is necessary to send the command SCPI MCBD key and to turn off/on again the scope
• Start again from the beginning of the file and look for its serial number (SDSxxxxxxxxxxxx), search until find the one where it is written MSO 5 characters before
• A little lower (69 or 117 characters) a group of readable characters, there are 3 groups of 16 characters which correspond to the activation key of options, if this key appears 2 times is that it's already active. The options are respectively (AWG, WIFI, MSO) and can be activated with the command SCPI LCISL option,key

Thank You, this info and of course Dave-s tear down and review video are the reasons why I choose Siglent.

[tv84]

Well, I'm requesting your help, because I tried the steps Gege34 suggested on my SDS1104X-E, and when I tried to dump the memory on the USB key, nothing happened. What am I doing wrong?

At the end of your command line add ";sync" without quotes.