Author Topic: Unlocking Siglent SDS1104X-E, step by step  (Read 192333 times)

0 Members and 2 Guests are viewing this topic.

Offline jgreco

  • Newbie
  • Posts: 1
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #50 on: December 06, 2018, 04:03:33 pm »

For some real fun, check out these GitHub repositories:

https://github.com/Siglent/FindKeys
https://github.com/Siglent/TryKeys


Purely for educational purposes only. User is expected to comply with all applicable state, county, federal and international laws :)

This is almost awesome and almost worked swimmingly well.

The Tek 475 here decided to go traceless.  I'd been sorely tempted by the low end Rigol for the last few years, but the Siglent at 200MHz with four channels felt like a more compelling addition.  Don't need the 200MHz, don't actually need any of the other features either, don't even use a scope often anymore, but it's always fun to hack, and being able to log in to your devices to poke around is fun.  Aside from not immediately figuring out that the unit came with DHCP disabled, all of that went very well and I had the eevblog-modified OS loaded and running without much ado.

However, when I got to the github projects above, my code development environment is much closer to working on a VT100 than it is a PC with an IDE.  There was a little irony that a user with a handle of VT100 posted a bunch of Microsoft-dependent stuff.  I didn't have Visual Studio loaded anywhere, and how to use it wasn't entirely clear to me, as my development environment is usually just vi, cc, make, and the rest of the UNIX stack.  I figure if someone who's written tons of C had issues figuring this out, maybe non-developers or other old UNIX farts might have trouble too.  If this turns out to be helpful to someone, here's a few notes, hard won through about eight hours of persistence and one trashed VM, hopefully a clue or two for anyone similarly clueless-ish about Visual Studio:

Visual Studio is huge.  It almost overflowed my 50GB Windows lab VM's.  I installed Visual Studio Community 2017 with the Visual Studio Installer downloaded from Microsoft.  Under "Workloads" I had it install .NET Desktop Development, Desktop development with C++, and .NET Core cross platform development.  I also selected "NuGet targets and build tasks" under "Installation details" the second time around, because something went tragically wrong with my first VM, and NuGet wasn't working correctly.  Some of these selections are needlessly sloppy, I'm sure.

Once in Visual Studio 2017, I went to "File -> Open -> Open from Source Control", plugged in the FindKeys github URL, and it picked it up, bringing up a "Solution Explorer" window.  After spending some time looking around and wondering where a "build" button or key was, I opened "Program.cs" in the editor to look at it and suddenly "Build" became available in the menu bar.  Yay for obtuseness.  It built the FindKeys.dll just fine, depositing it in C:\Users\username\source\repos\FindKeys\bin\Debug\netcoreapp2.1, so I just moved the memory dump bin file to that directory and ran it there, and it worked.

At this point, things went off the rails unrecoverably on the first VM.  I tried to do the same process for TryKeys and it went seriously sideways.  It needed a package called "LiteGuard" and I couldn't figure out how to install it.  For whatever reason, NuGet was broken and unusable in the first VM.  Being unfamiliar with the tool and thinking myself just too dumb for modern tools, I wasted several hours stuck trying to remediate that.  Install-Package simply wasn't there or was broken or something.  So I switched to a different lab VM, installed Visual Studio again, and went to do TryKeys again.

This bombed as the build still needed "LiteGuard".  Trying to install that, it refused.  It really wanted a project name.  So I knew I wasn't really doing this correctly, but I didn't really care, so I exited out of VS to dump the mess, launched VS again, did "New -> Project from Existing Code", specified "Visual C#", pointed the dir at C:\Users\username\source\repos\TryKeys, and named it "TryKeys".  Then I was finally able to successfully go to "Tools -> NuGet Package Manager -> Package Manager Console" and entered

PM> Install-Package LiteGuard -Project TryKeys

It still presented an error but it seemed to complete, so I again opened Program.cs, ran "Build", and it built, and ran great.

Y'all are welcome to explain in excruciating detail how I made this more complicated than needed or went about it entirely the wrong way.  :-)  I just felt it would be a shame if the effort put into these two fine Siglent tools was not accessible to someone without any coding experience.  Thanks for the tools.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #51 on: December 06, 2018, 07:23:31 pm »
My process was get to the point where you kill the application, step 12, then fire up the process again, step 11, then using "PS -A" to find its new PID, and "kill -ABRT <PID>" It was my third loop of starting and killing it that got me a core dump.
 

Offline vt100

  • Contributor
  • Posts: 15
  • Country: af
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #52 on: December 07, 2018, 12:55:40 am »
There was a little irony that a user with a handle of VT100 posted a bunch of Microsoft-dependent stuff.

I wanted to learn .netcore and this was my first .net core application.

Quote
Visual Studio is huge.  It almost overflowed my 50GB Windows lab VM's.

if someone makes a pre-compiled version available then you could get away with installing the .dot core runtime, which is significantly smaller, and would run on linux.  .dotcore apps will compile and run on linux, allegedly.

Quote
It needed a package called "LiteGuard" and I couldn't figure out how to install it.

I have absolutely no idea what LiteGuard is. It wasn't a nuget package I used, but it does show up in project.assets.json now that I look. Perhaps it was a dependency of another nuget package I used in TryKeys which I didn't use in FindKeys -- e.g. the telnet library, for instance.

It was my third loop of starting and killing it that got me a core dump.

Strange thing is, I get a core dump each and every time, on the first try. I have no explanation as to why others have problems getting a core dump. Maybe I'm lucky.
vt100
the world's best dumb terminal
 

Offline plurn

  • Regular Contributor
  • *
  • Posts: 96
  • Country: 00
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #53 on: December 15, 2018, 06:15:40 am »
I think I found an easier way to get the mem dump. I did this without needing to set a known root password.

I did this with a stock standard unhacked new SDS1104X-E software version 8.1.6.1.26. Some notes:

Insert a USB thumb drive formatted appropriately for the SDS1104X-E
Using the SCPI control of the web interface, put the following command (or similar depending on what filename you want):

SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin

Wait a minute or more for it to complete - it needs to copy a 256 megabyte file

cleanly shutdown the SDS1104X-E (with the power button on the front)

You can now move the USB thumb drive to a pc. There should be a memdump.bin file on there. You can follow other people already mentioned processes to extract keys from this. I used vt100's instructions from step 20 onwards here: https://www.eevblog.com/forum/testgear/unlocking-siglent-sds1104x-e-step-by-step/msg1877477/#msg1877477   Thanks vt100. I used the free "Hex Fiend" on macos as the Hex editor but I expect any would do.

Thanks to Rerouter for letting me know about the "SHELLCMD" SCPI command https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2041069/#msg2041069.

Also thanks to everyone who provided procedures for extracting keys.
« Last Edit: December 15, 2018, 08:31:13 am by plurn »
 
The following users thanked this post: booyeah, Max2018

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #54 on: December 15, 2018, 06:38:38 am »
I should point out the memdump is slightly different to the core dump.

the core dump has the licenses loaded in somehow, (havent actually looked into it). while the memdump is just the application file.
so you cannot unlock at present with just the system file.

The other issue is if you tried to get a core dump, well the web interface is run by the system app, so once it crashes, the interface locks up.

« Last Edit: December 15, 2018, 06:41:11 am by Rerouter »
 

Offline plurn

  • Regular Contributor
  • *
  • Posts: 96
  • Country: 00
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #55 on: December 15, 2018, 06:47:39 am »
I should point out the memdump is slightly different to the core dump.

the core dump has the licenses loaded in somehow, (havent actually looked into it). while the memdump is just the application file.
so you cannot unlock at present with just the system file.

The other issue is if you tried to get a core dump, well the web interface is run by the system app, so once it crashes, the interface locks up.

With the file produced by the "SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin" command, I believe I found all the keys. I think /dev/mem includes all memory - not just the memory from an application core dump. I only tested the bandwidth key as I don't have a need for the other ones. Bandwidth key worked for me.


« Last Edit: December 15, 2018, 06:49:57 am by plurn »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 3212
  • Country: pt
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #56 on: December 15, 2018, 08:47:38 am »
Coredump provides a continuous mem image.

/dev/mem provides a fragmented memory image (in blocks of 4kB or something), with "random" order. For me it's random, if anyone can explain the logic it would be GREAT!

They are not the same and that's why some manipulations need to be done in /dev/mem.

BUT, both ways provide the needed licenses.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #57 on: December 15, 2018, 08:55:34 am »
well if you wanted to play it that way, there are very few strings that are only capitalized alphanumeric, at least 16 characters long and contain no symbols, so on that basis you may be able to filter down memory images to only relevant ASCII formatted strings,
 

Offline bugi

  • Regular Contributor
  • *
  • Posts: 249
  • Country: fi
  • Hobbyist using the ultra slow and unsure method
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #58 on: December 15, 2018, 11:11:39 am »
/dev/mem provides a fragmented memory image (in blocks of 4kB or something), with "random" order. For me it's random, if anyone can explain the logic it would be GREAT!
I'm no kernel expert, but at least on "bigger CPUs" most kernels these days do some kind of memory space randomization (which is probably "corrected" in the page tables inside CPU) for security reasons. Malware have harder time looking for data or injecting code, since the desired locations are randomly somewhere... (That description is probably too simple, slightly misunderstood by me, etc. but... might explain the random order in the /dev/mem.  Something like this: https://en.wikipedia.org/wiki/Address_space_layout_randomization)
 
The following users thanked this post: tv84

Offline vt100

  • Contributor
  • Posts: 15
  • Country: af
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #59 on: December 15, 2018, 12:46:36 pm »
I spent quite a bit of time on this, with tv84's guidance, so let me state the following.

cat /dev/mem will give you a memory dump of the scope's entire memory. That memory is managed by the operating system kernel, and is broken up into 4k chunks, aka "pages". The kernel memory manager allots those pages to each process, using a process only someone intimately family with the kernel would be able to explain. Suffice to say, for our purposes, we can assume that any given process running on the scope will be assigned memory pages in a completely random order, even though to the process itself they may appear to be contiguous, they really are not, as the kernel is actually managing the allotment of and access to memory.

(if someone intimately family with the kernel memory management process can tell me where in a memory dump the paging table is located, and how to extract information from it in order to "reorganize" the memory pages for a given process into a single contiguous chunk, feel free to email me, I always enjoy a good intellectual exercise in programming.)

In order to retrieve your license keys from a memory dump, you need to utilize the process (either automatically or manually) captured in the "FindKeys" and "TryKeys" .net Core applications posted on GitHub. The reason being the memory keys will more than likely be "fragmented" into multiple 4k pages of memory. You may have 1/2 of a key at the end of one 4k memory page, and the remainder of the key at the start of another 4k memory page (I personally observe this w/ my own scope and was taking screen shots of a winhex display of the memory dump when I was going back and forth with tv84). And, those key fragments may be located megabytes apart in the file, with the 2nd half actually being 'first' in the file and the 1st half of the key being towards the end of the file.

So what FindKeys does is it examines the memory dump and identifies strings which may possibly be part of a license key. When it identifies a partial candidate, it will combine that partial candidate with other partial candidates to create one or more candidates to try  (e.g. given the program finds one 8-character string A and another 8 character string B, it will create two candidates, AB and BA, to try.  Trykeys takes the file of potential keys and tries to implement them.

A core dump, however, is a contiguous snapshot of a processes' memory. When the core dump is created, the memory pages assigned to the scope process are all arranged in the correct order by the kernel. The process of creating a core dump is handled at the OS level thus the OS can organize the memory pages into the correct order as they are written to a core dump file. Thus with a core dump, the keys will be contiguous as they are represented in their actual underlying class structures and are easily discoverable using the 'shortcut' of using a hex editor to search for your serial # or scope Id.

Whenever possible, I encourage people to use the core dump method, it is cleaner and faster. However, understandably some folks have a problem getting a core dump (I cannot replicate this issue on my scope, each and every time I follow the posted 'process' in the previous post, I get a core dump, so I have no idea what makes my scope different from someone else's). For those who cannot get a core dump, then the memory dump/findkeys/trykeys route is their only option to recover the license keys they previously paid for and accidentally lost the paperwork on.
« Last Edit: December 15, 2018, 01:08:02 pm by vt100 »
vt100
the world's best dumb terminal
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 3476
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #60 on: December 15, 2018, 11:59:58 pm »
SIGABRT and SIGSEGV should produce a core dump, but Linux has the ability to prevent that via compile time options as well as other means I've not been able to sort out.  There is a core_dump_filter in /proc/<pid>, but I don't know any of the details.  I use Solaris like God intended whenever possible.

My use of Linux is like my use of Windows, it is only done under coercion.
 

Offline jazper

  • Regular Contributor
  • *
  • Posts: 56
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #61 on: December 18, 2018, 07:23:41 am »
My method was slightly different:

1. dump memory to fat32 formatted USB through web interface on 1104x-e - wait 1minute after performing this, then shut down the scope before doing anything else.
SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin

2. Compile find keys using Visual studio - https://github.com/Siglent/FindKeys

3. Run find keys on PC on the the memory dump - note you need to edit the config json.

4. Flash custom firmware with known telnet/root password ( https://www45.zippyshare.com/v/SEUJEWE1/file.html) - Follow instructions in pdf in the file. (note flash drive needs to be either 8gb or 32gb) - I tried to find a way to not do this, but it's the easiest way of getting root access.

5. Set up network on SDS1104x-e

6. Compile trykeys ( https://github.com/Siglent/TryKeys )

7. Use trykeys on a PC on the same network using the key file from findkeys, wait for reboot on 1104 - save the keys that are found - Note you need to edit the config json within findkeys

8. Update firmware to latest firmware from siglent
« Last Edit: December 18, 2018, 07:44:30 am by jazper »
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1918
  • Country: 00
    • If you like my hacks, send me a donation
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #62 on: December 18, 2018, 10:42:25 pm »
I think I found an easier way to get the mem dump. I did this without needing to set a known root password.
...
SHELLCMD cat /dev/mem > /usr/bin/siglent/usr/mass_storage/U-disk0/memdump.bin

that worked for me as well (options and BW), tested with unhacked new SDS1204X-E software version 8.1.6.1.26
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline photomankc

  • Contributor
  • Posts: 31
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #63 on: December 19, 2018, 03:02:33 pm »
Now we are talking.  I'd much rather avoid tinkering around with modded firmware.  I'll give this method a try.
 

Offline MartyMacGyver

  • Regular Contributor
  • *
  • Posts: 70
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #64 on: December 25, 2018, 09:03:28 am »
My SDS1104X-E arrived today with 7.1.6.1.25R2 (stock) on it.

After some fun (creating a wireless client bridge to get wired LAN handy, and using Ubuntu in a VM to format the flash drive for the Unixy flash boots) I was able to log in, run the commands, and rebooted.

At that point my model number went from SDS1104X-E to SDS1204X-E.  :-+

(Note to others: For the "OSV" updates, if you try to format the USB from Windows (certainly 10, maybe earlier ones) you'll likely have an annoying time of it. Bite the bullet and format and extract from Linux.) The only clue you'll have that it's working is it takes a bit longer to boot up, and the telnet password ends up working. If you're already on 7.1.6.1.25R2 like I was I'm almost certain the stock "SDS1004X-E_OSV1_EN-1.zip" step is not necessary, just the modified one.

I then grabbed the "SDS1004X-E_6.1.26_EN.zip" update and installed that. The model number is still 1204, and the firmware is now 7.1.6.1.26. I can still log in via telnet so all this suggests the unlock and mod worked.

One question though... I see mention of "8.1.6.1.26" in the thread here: is that some entirely different firmware, a typo, or what? Am I (at the moment) on the latest and greatest with 7.1.6.1.26?

Edit: One other bit of advice - if using a VM to format disks and such and you have problems with new DHCP addresses (as I just did with the SDG2042X I'm fiddling with now) be sure to shut down that VM to rule it out - in my case it made it impossible to route to the new device under test!
« Last Edit: December 25, 2018, 09:24:08 am by MartyMacGyver »
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1918
  • Country: 00
    • If you like my hacks, send me a donation
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #65 on: December 25, 2018, 09:15:07 pm »
One question though... I see mention of "8.1.6.1.26" in the thread here: is that some entirely different firmware, a typo, or what? Am I (at the moment) on the latest and greatest with 7.1.6.1.26?

i made dump of my dso (8.1.6.1.26), haven't found any binary differences to OS update file (7.1.x.xx) nor to latest available firmware.
Sure there might be still something different in mtd7 or mtd8, but due to lack of dump from 7.1 i can't compare, but probably there is no diff a well.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 
The following users thanked this post: MartyMacGyver

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #66 on: December 25, 2018, 09:50:01 pm »
8. And 7. Are the exact same. Just a rename.
 
The following users thanked this post: MartyMacGyver

Offline ewaller

  • Contributor
  • Posts: 29
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #67 on: December 27, 2018, 02:18:48 am »
I found a much easier way to root the scope.

After mounting the cramfs  from the OS update on my Arch Linux box (on a loop device), I note that the telnet server is provided by busybox.  And, as the scope's web interface allows us to run shell commands as root, I figured I would spin up a telnet server where the login application is a humble shell rather than that pesky password program.

tl;dr:

Go to the SCPI web interface and send:

SHELLCMD telnetd -l/bin/sh -p9999

Then, use your favorite Telnet client to attach to port 9999.  You are in -- no password challenge.

Edit:  Did I note that one does this with stock firmware?
« Last Edit: December 27, 2018, 02:21:02 am by ewaller »
 
The following users thanked this post: NF6X, bitseeker, patman27, plurn, therealdjryan, rickwookie, n3mmr, jazper

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #68 on: December 27, 2018, 02:33:29 am »
All the fun new things that turn up from a little digging :)

Great work ewaller

On the not so stock side, Getting the hang of patching out most of the typos in the scope software,
Main pain is the HISTORY_LIST query, they pointed command and query to the same string so having to shuffle stuff around to fit a new string.
 

Offline SMB784

  • Frequent Contributor
  • **
  • Posts: 421
  • Country: us
    • Tequity Surplus
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #69 on: December 27, 2018, 06:02:37 pm »
I found a much easier way to root the scope.

After mounting the cramfs  from the OS update on my Arch Linux box (on a loop device), I note that the telnet server is provided by busybox.  And, as the scope's web interface allows us to run shell commands as root, I figured I would spin up a telnet server where the login application is a humble shell rather than that pesky password program.

tl;dr:

Go to the SCPI web interface and send:

SHELLCMD telnetd -l/bin/sh -p9999

Then, use your favorite Telnet client to attach to port 9999.  You are in -- no password challenge.

Edit:  Did I note that one does this with stock firmware?

Do you think it is then possible to change the default root password?

Offline ewaller

  • Contributor
  • Posts: 29
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #70 on: December 27, 2018, 06:22:43 pm »

Do you think it is then possible to change the default root password?
Not from that shell.  The /etc/shadow file that contains the password hash is in a cramfs (Cram File System https://en.wikipedia.org/wiki/Cramfs ) which is inherently read only.  The solution that has been used to date involves updating the system with a rebuilt cramfs with a /etc/shadow file that has the new password hash in it; then that file system -- in it entirety -- is uploaded to the scope at boot time.

Part of my motivation was was to find a way to root the system when running stock firmware; and the nice part is that it requires no password.  With this, I think it will be possible to run code from a USB drive that has been cross compiled for ARM.  There may be issues find finding dynamically linked libraries, and the USB drives may be mounted with the noexec flag (meaning the OS will refuse to run code from the device).  I forgot to check that last night in my exploration :)  I'll look tonight.
 

Offline vtwin@cox.net

  • Regular Contributor
  • *
  • Posts: 175
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #71 on: December 27, 2018, 07:05:41 pm »
I'm guessing the SCPI SHELLCMD functionality will either be PDSH'd, or removed completely, in an upcoming firmware release  ;D
A hollow voice says 'PLUGH'.
 

Offline plurn

  • Regular Contributor
  • *
  • Posts: 96
  • Country: 00
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #72 on: December 28, 2018, 02:00:07 am »
I found a much easier way to root the scope.

After mounting the cramfs  from the OS update on my Arch Linux box (on a loop device), I note that the telnet server is provided by busybox.  And, as the scope's web interface allows us to run shell commands as root, I figured I would spin up a telnet server where the login application is a humble shell rather than that pesky password program.

tl;dr:

Go to the SCPI web interface and send:

SHELLCMD telnetd -l/bin/sh -p9999

Then, use your favorite Telnet client to attach to port 9999.  You are in -- no password challenge.

Edit:  Did I note that one does this with stock firmware?

That is awesome - works perfectly. Thank you.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #73 on: December 28, 2018, 08:08:33 am »
I should also point out, most of the recent methods listed here should work just fine for a number of BK precision scopes. :)
 

Offline t1d

  • Super Contributor
  • ***
  • Posts: 1212
  • Country: us
Re: Unlocking Siglent SDS1104X-E, step by step
« Reply #74 on: December 28, 2018, 06:42:15 pm »
I found a much easier way to root the scope.

After mounting the cramfs  from the OS update on my Arch Linux box (on a loop device), I note that the telnet server is provided by busybox.  And, as the scope's web interface allows us to run shell commands as root, I figured I would spin up a telnet server where the login application is a humble shell rather than that pesky password program.

tl;dr:

Go to the SCPI web interface and send:

SHELLCMD telnetd -l/bin/sh -p9999

Then, use your favorite Telnet client to attach to port 9999.  You are in -- no password challenge.

Edit:  Did I note that one does this with stock firmware?
Hi, everyone. I have this scope on order and it should be here in a few days.

I very much appreciate the graciousness, expertise and effort that it took each and every participant to develop this thread. Thank you!

I am considering this upgrade, but its means is completely outside my knowledge base. I see that the steps are summarized, in the first post, but I have questions about how this post relates to the first.
- Is Ewaller's method the complete protocol, or only a portion of it?
- If it is complete in itself, Ewaller, please write a start to finish tutorial using it, for us noobs. Post #68 is still above my pay grade.
- If it is only a portion and it being easier, has it been incorporated into Post #1? If not, please do so.

Thank you for your help and kindness. I am sure I will have lots more questions.

PS: My current OS is Windows 8.1. I expect to buy a new laptop, soon. It will, likely, have Windows 10/Home.
« Last Edit: January 11, 2019, 03:05:24 am by t1d »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf