Hack of Sigllent spectrum analyzer ssa3021X?

[tv84]

Just an idea: if someone creates a modified ads file, wouldn't it be better to create one that just re-enables the telnet service and doesn't do anything else, like replacing ecomb?

Next time we go that way.   

[electronic_eel]

Next time we go that way.   

I can't - I installed the unmodified update so I don't have telnet anymore.

Would my idea work? I mean must an update always contain ecomb and so on to work or could you really just re-add telnet and be done?

It would be nice if you could try to create such an update.

[tv84]

An .ADS can contain whatever we desire. No restrictions.

"Give me a telnetd, and I shall move the earth."

BTW, telnetd is only a link to busybox telnetd. So we just need to recreate the links.

Can anyone provide the script to recreate the links?

[electronic_eel]

An .ADS can contain whatever we desire. No restrictions.

that's what I wanted to hear.

BTW, telnetd is only a link to busybox telnetd. So we just need to recreate the links.

was just going to mention this, but cross checked with my ubi dumps to be sure.

To me it seems like they deleted just the links to the initscripts that start and stop telnetd. The actual telnetd link is not touched in the additional.sh you posted before.

Can anyone provide the script to recreate the links?

how about the attached script?

[tv84]

how about the attached script?

Do you want me to pack it for you?

[electronic_eel]

Do you want me to pack it for you?

That would be nice.

You'd probably have to rename it to .sh (had to rename because of the forum limits). And maybe add some .ads magic that is needed to have it actually executed.

[tv84]

Maybe it's no so simple. Isn't there the problem of the FS RO ?

Why do they use that fstab change in the official script?


These are the other scripts in the official .ADS.

[electronic_eel]

Maybe it's no so simple. Isn't there the problem of the FS RO ?

When the additional.sh is run as intended by Siglent the fs is rw, otherwise the regular update can't remove these symlinks.

Why do they use that fstab change in the official script?

I just diffed the new fstab against one from my ubi dump. They just add the line where they mount /tmp with tmpfs. So before /tmp was probably mounted to the root fs and that caused problems so they fixed it. I don't think this change has something to do with closing down access, I think it is just regular bugfixing.

These are the other scripts in the official .ADS.

Thanks, that gives me a lot more context to work with. I'll have to look through this code to determine how to get the update system into the right state, but without overwriting ecomb or other important stuff.

[electronic_eel]

Here is your script:

After I began reading the stuff in siglentlib.sh I don't think they intended an .ads to not contain ecomb and some other stuff. The additional.sh is only run through upgrade_app(), which overwrites ecomb and so on. I think I need some more time to understand what is exactly going on when an update is running and what is the best way to inject a script without causing negative side effects.

So I don't think this simple way is going to work. I'll post some updated scripts when I have finished my investigation.

I'm not sure if ../init/ is the best path option because I think this script runs in /usr/bin/siglent/usr/usr/upgrade/

ln stores exactly the string you give as parameter into the symlink. The relative path is resolved when you later access the file. This relative symlink is exactly what was in there before, I checked that with my ubi dump.

[electronic_eel]

In that case, you can run the ADS.

Of course, my ADS contains only the upgrade.sh with the contents that I wrote above. Because the ecomb doesn't recognize anything else.

No additional.sh sh*t and the rest. Well, I included the fstab but, as you said, it's harmless now.

hmm. have a look at check_and_upgrade() in the siglentlib.sh. If there are update files there (is_need_upgrade), then it directly begins overwriting stuff (upgrade_uboot, upgrade_uimage). It then calls upgrade_app which in turn first overwrites ecomb, ui_data,... then only the additional.sh is called. We absolutely don't want to run that part of the script as it would overwrite uboot and the kernel image.

What I haven't figured out yet is how upgrade.sh is called and how it interacts with the other stuff in siglentlib.sh.

My current guess is that upgrade.sh is called directly when the .ads is installed, before the first reboot. After the reboot, some startup script calls check_and_upgrade() and executes the calls in there.

If that is indeed what is happening, then we'd need to do the rw-remount in upgrade.sh and also remove /usr/bin/siglent/usr/usr/upgrade/upgrade.sh afterwards so that is_need_upgrade() doesn't trigger.

Do you concur?

[tv84]

Read my previous msg as I re-edited.

I'm not using any of that stuff because all we want is the symlink creation.

When you go for an update, in the SSA, the app knows it has to search for an upgrade.sh in the .ADS. This is an upgrade feature! No need to investigate.

But, of course our simplistic script won't work as needed because we are not doing the FS RW. As I said, investigate that part sequence and don't worry with partitions/directories updates/replaces/reformats as we won't be doing any of those.

Edit: The .ADS isn't "installed" as you say. The .ADS is decrypted and decompressed into the /upgrade/ dir and then the upgrade.sh is immediately exceuted. It then takes care of the rest.

[electronic_eel]

I'm not using any of that stuff because all we want is the symlink creation.

What means "using"? I think it gets automatically "used" if a upgrade.sh script is existing at the right place on bootup.

When you go for an update, in the SSA, the app knows it has to search for an upgrade.sh in the .ADS. This is an upgrade feature! No need to investigate.

Edit: The .ADS isn't "installed" as you say. The .ADS is decrypted and decompressed into the /upgrade/ dir and then the upgrade.sh is immediately exceuted. It then takes care of the rest.

ok, the .ads is unpacked and upgrade.sh executed, directly and before rebooting. A regular upgrade.sh will then trigger the reboot.

You posted a upgrade.sh from Siglent. It doesn't replace ecomb, but we know that it is replaced somehow. So how does this happen?
I think after the reboot the ecomb program will call check_and_upgrade(). That will then overwrite some stuff, remove upgrade.sh and then do a reboot. That is the second reboot you always experience when doing an update on the SSA. On the next reboot no upgrade.sh is there anymore, so the system boots into the regular program.

But, of course our simplistic script won't work as needed because we are not doing the FS RW. As I said, investigate that part sequence and don't worry with partitions/directories updates/replaces/reformats as we won't be doing any of those.

I think you have to activetly prevent the replacement of this stuff, because if you leave upgrade.sh in place it will automatically take place.

Another idea: can't we just directly start telnetd from upgrade.sh and then remove upgrade.sh? That way don't have to take care of file system modifications and so on.

Do you know if upgrade.sh is called as root or as another user?

[electronic_eel]

Could you please build me an .ADS with just the attached upgrade.sh?

That should open up telnet just once and only during this session. Deleting the upgrade.sh will make sure there are no surprises at the next reboot.

[tv84]

Another idea: can't we just directly start telnetd from upgrade.sh and then remove upgrade.sh?

The attached .ADS should activate telnetd for the current SSA session. Login as usual.     

The script inside is electronic_eel's creation. I just applied the external paint.

[electronic_eel]

This script works! (after tv84 and I did some back and forth to figure out what was going on)

When you install it as update you get instant telnet access. But for this session only, so after a reboot everything is unchanged and as before.

The SSA shows a small progress bar when installing, it halts at 60%. This is normal and means you can now telnet in. The password is unchanged. The ui becomes unresponsive, it says you should wait for the update to complete. So just call "reboot" in your telnet session when you are done.

[arturfra]

Ok thanks for trying and create it, but what’s the exact procedure to install new update with all options enabled?

[electronic_eel]

Ok thanks for trying and create it, but what’s the exact procedure to install new update with all options enabled?

you install the original update from Siglent website. Now telnet access is closed.

Then you install the telnet_SSA3000X update as posted by tv84 above. That gets you telnet access back for the current session, but doesn't change or update anything of the system. Now you use telnet to do the regular procedure to extend your bw/options as posted previously in this thread. done.

[arturfra]

Nice, could i recuperate my s/n with that procedure or it’s the same as before?

[NikWing]

hey all

after reading the thread (all new posts since I was here last time) I'm a little bit puzzled if I should upgrade the fw or not.
I currently have fw 1.2.8.2 (HW 07.03.00) which I applied months ago after I got the device.

Can I safely upgrade to the newest fw like I see it in post #633 without losing anything?
1.2.9.1 is on the siglent download page and here you talk about v1.2.9.3a.
Which would be better?

Thanks for unpuzzling me

[tv84]

You can upgrade peacefully (to 1.2.9.3a since it's the latest).

[NikWing]

oh wow, quick reply

thanks, tv84, so I just apply the new fw and all options will stay

edit: yay, done

[Steen]

Hi,
Is it possible to upgrade the SSA3021X, SW1 1.2.9.3a, SW220180708-1, HW 0F.03.00 ?

Anyone!  -is it possible to to upgrade SSA3021X that comes with SW1 1.2.9.3a??

[TTH]

You can enable all options using the previously documented procedure - after running telnet_11201.ads for the session.

[Deepblue]

Hi everybody,
I have been reading this thread and decided to order a Siglent SSA3021. It came with the tracking generator license and the 1.2.9.2.a firmware installed.
I managed to get all the options enable, using knowledge from this thread  everything looks fine, apart from the license number which is XXXXXXX as I knew it would be when hacking it.

My question is; have anybody tried the TekBox EMCView pre-compliance software (Link) with a hacked Siglent? They state the software will be locked to the SSA's serial number, but wil this work with a hacked unit?
I have the original S/N, but I suppose the unit reports "XXXXXXXX" back to the software?!?

Hope someone can help me out here.

[tv84]

For that case, maybe you can use a hexeditor and change the app file to SCPI report your S/N in the place where it has the XXXXXXXXX. Leave all the other files as they are.

But you would have to do that patch in every update...

Poor's man solution.