Being able to trust the hardware I bring into my home is incredibly important, especially so when that hardware is networking-related. I’ve seen many who were surprised at my usage of the YuanLey 6-port switch, with accusations of spyware being flung about baselessly. I had been monitoring the switch since the day I bought it, noticing nothing untoward, and I’ve already decompiled the most recent firmware for it, too.

Of course, I know most people who want to buy new networking equipment, be it a switch, router, or otherwise, don’t all have the necessary capabilities to reverse engineer a firmware dump via static analysis. That’s why I’m going to show you the basics of how you can get started, using my own managed switch’s firmware, so that you can start doing your own firmware analysis, too.

For this kind of project, I recommend using Linux. I have a Ubuntu development environment running on Proxmox that I access over RDP.

This is static firmware analysis does not cover all bases, as code can be dynamically built or modified at runtime. We will cover my mitigations towards that at the end of the article.

Analyzing our firmware file

Binwalk is your best friend

Credit:

We’ve downloaded our firmware file from the YuanLey website, and it comes in the form of a zip file. The first step is to simply extract it and then get a feel for its contents. In our case, we just have a single “vmlinux-YS25-0402M-YUANLEY-240801EN.bin” along with a changelog and a PDF with instructions for updating.

So, what do we do? The first step is to use a tool called “binwalk.” It’s a tool used for analyzing binary images, and we can use it to show us a table of identifiable blocks of data, along with an entropy graph. An entropy graph is especially important, as it will allow us to immediately get a sense for whether the data is compressed or encrypted. It essentially plots the file’s randomness against its length, and an entropy of 1 means that the data is very random. We can generate an entropy graph with the following command:

binwalk -E filename.bin

When plotting entropy, 0.7 is roughly the threshold for what’s considered to be “random.” Looking at the above graph, you’ll see high entropy values, but note that “random” does not mean encrypted. These files are not encrypted and can, in fact, be extracted. The blocks that drop to 0 are predictable sets of data, and given that those gaps seem to sit between large spikes, it’s likely that these are sections of null bytes or other predictable data.

Behind the graph, you’ll see in my terminal that there are many lines of HTML document headers and footers. This was obtained by using “binwalk filename.bin”, without the -E, as this gives us an idea of the layout of the firmware file. At this point, it would be quite common to find a SquashFS filesystem or equivalent that can be extracted and mounted, but there’s no such thing here.

At this stage, it seems likely we essentially have a pack of web GUI files rather than anything else, especially given that nearly everything contained here appears to be HTML. However, we’ll move on to extracting some of the data, now.

We’ll pull the HTML and other data

We have sections of data in our firmware file that are split by offsets, but this means we can extract those individual sections into files that can be interacted with individually. If we had identified a SquashFS filesystem, we could have extracted its contents, though there’s none here. Instead, we have our HTML files, our CRC32 table, and a Base64 table. We’ll start with the HTML files first, as I wrote a simple script to extract them all based on their offsets.

From analyzing these files, there’s nothing out of the ordinary. Most of them are tiny, and contain what appear to be all of the different UI elements of the web panel on the YuanLey managed switch. What is pretty funny is that I identified a vendor string of a competing brand in China:

SiriVision-Web-Smart

. I confirmed that I receive this string in unauthorized curl requests:

401 Authorization RequiredAuthorization RequiredThis server could not verify that youare authorized to access the documentrequested. Either you supplied the wrongcredentials (e.g., bad password), or yourbrowser doesn't understand how to supplythe credentials required.SiriVision-Web-Smart

Still, there’s nothing nefarious here so far, even if the inclusion of a different brand raises eyebrows. I’d suspect that there’s an element of white-labelling going on here, where companies buy the hardware and software from an original manufacturer and then put their own brand on it. This is further supported by the fact that, in a separate analysis, ServeTheHome discovered that the YuanLey YS25 0801 is virtually identical to the Davuaz Da K9801W under the hood.

Extracting the Base64 table from the binwalk highlights something interesting, as there were changes to VLAN behavior. The update log mentions that it “Fixed the mirror port save setting problem,” which could conceivably be linked to VLAN behavior depending on the details of this particular bug.

In the firmware file, there’s nothing else of note here to analyze. In fact, even the base64 table portion of the firmware is tiny. I can see references to internal files throughout this analysis, so it’s clear that there’s a wider system under the hood than is represented here.

Finally, I moved over to Ghidra, where I attempted to analyze blocks of code that I suspected were binary portions. I had identified that the RTL8373 Realtek SoC was in tow, alongside the RTL8221B. This isn’t an uncommon configuration in the slightest, and the RTL8373 is likely similar to the 8372N which has a DW8051 microprocessor supporting the 8051 instruction set.

Unfortunately, I could not find any data in the firmware file that appeared to match the 8051 instruction set, and given my lack of familiarity, the analysis of the firmware stopped there. I would have undoubtedly been looking at assembly for an architecture I’m unfamiliar with,

It still seems fairly safe

I’ve been monitoring it for months

Even if it seems hard to trust a managed switch from a relatively unknown brand, it does appear that at the very least, this switch appears to be pretty safe, and there are a few reasons I feel confident in saying that. Not only did I not come across anything in my static analysis of the firmware that suggests the company is up to no good, but I’ve been monitoring the switch since I rolled it out, and I’ve not seen anything dangerous or worrying from it.

Over the past few months, I’ve tested it extensively. I’ve put it on its own isolated network and logged connections, I’ve check the ARP table to ensure that no devices are being spoofed, and I kept an eye on it with the ZenArmor for months only to see that it had not done anything online. Between the fact that its network behavior appears squeaky clean and its firmware does too, there’s not much more really that could be left hiding. Even the Telnet and SSH ports are filtered on it.

As a result, it’s as good as it can get without having access to the manufacturer’s full source code. If you’re worried about a switch like this, feel free to filter its access to the internet, and ensure that it’s not spoofing other devices to get around it. You can apply the same methods we used here to almost any firmware file, and there are countless other steps you can take to start reverse engineering your own hardware and software, too.