We could try to find this loading using static analysis, but remember that I’m not comfortable reverse engineering this firmware, and I want to demonstrate a more dynamic approach.
Perhaps this is a "two types of people" situation, but I would absolutely not do that; once you dump the flash you can analyse and inspect it carefully at your leisure as it is otherwise inert, but messing around with the device itself presents a very real risk of accidentally bricking it.
If you read the article, the OP points out that static analysis for this platform is not supported in Ghidra.
Also, reading between the lines, I think it's safe to assume the author did dump the flash.
> Using the strings command on the firmware dump reveals a lot of interesting details about the webserver itself, but nothing obvious hints us to the password.
The author is referring to limitations in analysing banking:
> Ghidra supports the 8051 architecture but not code banking.
Usually in these ISAs an I/O port or a register sets the bank number, so any processor module should be able to resolve concrete banked references. But you still need to know what that register holds in various code paths, which are likely dynamically computing those values.
No tooling can give this out-of-the-box, as it relies on knowing the concrete initial state of the system (i.e. memory and register contents), and knowing what to return when hooking into I/O accesses.
Once these are known, we can leverage the built-in pcode emulator and run it with this state. It seems nowadays Ghidra has some built-in support for Z3, but I personally never used it, so I'm not sure how viable it is for symbolic execution. Regardless, with either approach, we would now have concrete banked code references being resolved, and could script some auto annotation of the disassembly with these references. These would be equivalent to what the author gathered from the logic analyzer trace.
A pure static analysis approach seems to suggest one would manually brute-force through all possible bank numbers at any given code path, which I guess is only viable if you have the time for that.
It’s too bad Saleae prices are so high now. Their original models launched at a very affordable price point but that’s long gone.
In the past they’ve offered discounts to students and contractors if you know where to look and how to ask: https://blog.saleae.com/saleae-discounts/ If anyone is considering one, it’s worth a try to see if they still honor this.
The alternative logic analyzers mentioned in this article look interesting, but the software side leaves a lot to be desired. Some people get along okay with PulseView (or forks, like in this article) but I never enjoy using it.
Even with the alleged education discount a Logic8 will still set you back around 250$ and it only has 8 channels @ 100MS/s, the LA used by the article author is 69$ and does 200MS/s on 16 channels, going up to 800MS/s if you're using just 4ch.
The new Saleae Logic MSO looks like a fantastic piece of kit, but their pricing isn't justifiable for an hobbist IMHO.
There’s more to a LA than the sample rate. The main benefit of the Saleae is the software, which is what you’re really paying for.
For a budget hobbyist I do agree that going with a very cheap hardware and dealing with Pulse View is the way to go. For anyone doing more serious or paid work the Saleae devices really can be worth the premium if you can swing it.
Has anyone looked into what the "web managed" part of these switches involves? Is it a purely local web interface or is it exfiltrating traffic to some random server God knows where that's doing the managing on my behalf? This one seems to be purely local, https://cdn.shoplazza.com/06c9d3aa7743ce86dfca2f75e56a2faa.p..., but I've seen others that claim app-based management which probably aren't running that locally.
I know a community who invested in an Arm sbc to do photo management with a locked bootloader running a locked Linux kernel where the developers have walked away (Ukraine war)
Its the "Monument" device. The users would love it if somebody unlocked things this way.
do you know the SPI clock frequency? I am trying to figure out the sampling rate required to reliably capture the trace. That determines the tier of logic analyzer needed I guess.
in this particular case "We need to be able to capture 60 MHz SPI."
For something cheap and capable you could try building rp2350 based https://github.com/gusmanb/logicanalyzer, goes up to 400Ms/s. Its just a Pico1/2 with a level shifter board
"This is an affordable logic analyzer capable of reaching up to 400Mhz of sampling speed. The analyzer uses a Pico/Pico2 as its core. The analyzer offers 24 channels but can be chained up to 5 devices allowing the sampling of up to 120 channels at once."
I havent played with their software yet, but I have a ton of experience with pulseview and while its feature rich it is sluggish and not suited for high speed big volume acquisitions (especially the dreadfully Python 3.4 plugins and Im saying this as an author of one of the plugins) so anything written even half competently might be better.
1. Read the datasheets. Some parts only support certain frequencies, so find the minimum of the master and slave frequencies.
2. Check at boot. Most devices boot slowly for the first few transactions then speed up. So if you saw valid data then aliasing, get a better kit.
3. Start high. I think the fastest serial memory devices cap out at 250 MHz DDR for volatile and 200 for non-volatile. So even a digital discovery (which I think is the best LA for high speed bursts) can deal with it
We could try to find this loading using static analysis, but remember that I’m not comfortable reverse engineering this firmware, and I want to demonstrate a more dynamic approach.
Perhaps this is a "two types of people" situation, but I would absolutely not do that; once you dump the flash you can analyse and inspect it carefully at your leisure as it is otherwise inert, but messing around with the device itself presents a very real risk of accidentally bricking it.
If you read the article, the OP points out that static analysis for this platform is not supported in Ghidra.
Also, reading between the lines, I think it's safe to assume the author did dump the flash.
> Using the strings command on the firmware dump reveals a lot of interesting details about the webserver itself, but nothing obvious hints us to the password.
The author is referring to limitations in analysing banking:
> Ghidra supports the 8051 architecture but not code banking.
Usually in these ISAs an I/O port or a register sets the bank number, so any processor module should be able to resolve concrete banked references. But you still need to know what that register holds in various code paths, which are likely dynamically computing those values.
No tooling can give this out-of-the-box, as it relies on knowing the concrete initial state of the system (i.e. memory and register contents), and knowing what to return when hooking into I/O accesses.
Once these are known, we can leverage the built-in pcode emulator and run it with this state. It seems nowadays Ghidra has some built-in support for Z3, but I personally never used it, so I'm not sure how viable it is for symbolic execution. Regardless, with either approach, we would now have concrete banked code references being resolved, and could script some auto annotation of the disassembly with these references. These would be equivalent to what the author gathered from the logic analyzer trace.
A pure static analysis approach seems to suggest one would manually brute-force through all possible bank numbers at any given code path, which I guess is only viable if you have the time for that.
It’s too bad Saleae prices are so high now. Their original models launched at a very affordable price point but that’s long gone.
In the past they’ve offered discounts to students and contractors if you know where to look and how to ask: https://blog.saleae.com/saleae-discounts/ If anyone is considering one, it’s worth a try to see if they still honor this.
The alternative logic analyzers mentioned in this article look interesting, but the software side leaves a lot to be desired. Some people get along okay with PulseView (or forks, like in this article) but I never enjoy using it.
Even with the alleged education discount a Logic8 will still set you back around 250$ and it only has 8 channels @ 100MS/s, the LA used by the article author is 69$ and does 200MS/s on 16 channels, going up to 800MS/s if you're using just 4ch.
The new Saleae Logic MSO looks like a fantastic piece of kit, but their pricing isn't justifiable for an hobbist IMHO.
There’s more to a LA than the sample rate. The main benefit of the Saleae is the software, which is what you’re really paying for.
For a budget hobbyist I do agree that going with a very cheap hardware and dealing with Pulse View is the way to go. For anyone doing more serious or paid work the Saleae devices really can be worth the premium if you can swing it.
Has anyone looked into what the "web managed" part of these switches involves? Is it a purely local web interface or is it exfiltrating traffic to some random server God knows where that's doing the managing on my behalf? This one seems to be purely local, https://cdn.shoplazza.com/06c9d3aa7743ce86dfca2f75e56a2faa.p..., but I've seen others that claim app-based management which probably aren't running that locally.
Very nice!
An 8051 with XIP SPI flash - that must be ancient tech.
Not necessarily, there are 8051 soft cores you can get for your FPGA/ASIC.
The phone I type it on has a 8051-compatible MCU in its touchscreen controller. These are everywhere.
Most of the USB mice and keyboards you can buy today have an 8051 core.
silicon labs still makes (very fast) 8051 cores. efm8sb are incredibly good for battery powered devices
Interesting that someone else had previously found it too -- I wonder how they got hold of it?
https://github.com/up-n-atom/SWTG118AS/commit/514483b9c9e4d6...
I know a community who invested in an Arm sbc to do photo management with a locked bootloader running a locked Linux kernel where the developers have walked away (Ukraine war)
Its the "Monument" device. The users would love it if somebody unlocked things this way.
I'd be curious to know more about the switch reverse engineering. What was the ultimate goal for this password.
do you know the SPI clock frequency? I am trying to figure out the sampling rate required to reliably capture the trace. That determines the tier of logic analyzer needed I guess.
in this particular case "We need to be able to capture 60 MHz SPI."
For something cheap and capable you could try building rp2350 based https://github.com/gusmanb/logicanalyzer, goes up to 400Ms/s. Its just a Pico1/2 with a level shifter board
"This is an affordable logic analyzer capable of reaching up to 400Mhz of sampling speed. The analyzer uses a Pico/Pico2 as its core. The analyzer offers 24 channels but can be chained up to 5 devices allowing the sampling of up to 120 channels at once."
I havent played with their software yet, but I have a ton of experience with pulseview and while its feature rich it is sluggish and not suited for high speed big volume acquisitions (especially the dreadfully Python 3.4 plugins and Im saying this as an author of one of the plugins) so anything written even half competently might be better.
A few ways:
1. Read the datasheets. Some parts only support certain frequencies, so find the minimum of the master and slave frequencies. 2. Check at boot. Most devices boot slowly for the first few transactions then speed up. So if you saw valid data then aliasing, get a better kit. 3. Start high. I think the fastest serial memory devices cap out at 250 MHz DDR for volatile and 200 for non-volatile. So even a digital discovery (which I think is the best LA for high speed bursts) can deal with it
In a pinch, a frequency counter should be able to give you at least a ballpark estimate.
article says 60MHz