With upcoming CycloneDX 2.0 release, a lot of improvements were made regarding its Hardware Bill of Materials (HBOM) capabilities. In this post, I’ll describe process how you can generate an HBOM for a Wi-Fi router.
In my case, I’m using D-Link R18 worth about ~30$ and sitting unused in my case. In parallel with HBOM I worked with Claude to add it OpenWRT support (which worked and which I would describe separately). But since I participated in HBOM group work, I thought this would be a good exercise.
First, important note that it’s always easier for manufacturer to create SBOMs, HBOMs and other BOMs. But since those rarely exist and if they are usually remain undistributed, I’ll show how we can make one ourselves.
Table of Contents
I Label
Router usually has label, which has some useful information, which in my case included product number, serial number (which I left out of the published HBOM), model number, country of origin, MAC address and several regulatory classifications.
If you don’t worry about exposing network default passwords, take a picture and feed it to Claude.
II Tear Down
This was easy on this router. Unscrew 2 screws on the bottom and pry open. Then take detailed pictures of everything including close ups of chips and feed everything to Claude.
In my case this was first overall board view, where we can see Econet SoC EN7528HU:
Then take close up picture of DRAM Flash, Nanya NT5CC128M16JR-EK (U1001), 256 MiB:
Next take a picture of the rear buttons for identification:
and another close up, this time of SPI-NAND Macronix MX35LF1GE4AB-Z4I (U15 Flash):
III Collect Bootlog
Next, identify boot UART serial (there were 3 candidate ports), connect serial and collect bootlog using picocom, in my case:
picocom -b 115200 /dev/ttyUSB0
and let Claude take the log and analyze it.
IV Compile against the spec
With all data gathered, just ask Claude to compile against the specification. While CycloneDX 2.0 is not released yet, I was using latest 2.0-dev branch at commit ea8c360, which should be close to the final release as HBOM-related work was already merged.
V Gaps
Main gap that I had was Wi-Fi chip protected by metal shield, which I didn’t want to remove (as I didn’t want to break the thing, at list yet). But the chip itself was down to 2 candidates. Therefore, we used CycloneDX 2.0 component choice addition which essentially means, this can be one of several components. In my case: MT7905DAN or MT7915DAN, with MT7975 A-die.
Further, evaluating the document against recent IST paper on HBOMs by Allan Friedman and Nicholas Leiserson, we could improve coverage by stating what levels are explicitly excluded or included. This would likely require follow up work in CycloneDX specification.
In this HBOM preparation, I was mostly focusing here on the major chips (SoC, DRAM, flash and Wi-FI), plus the connectors and other user-facing parts. Power-management chips, discrete semiconductors and passive components are out of scope for this HBOM.
Additionally, with preparing HBOM via teardown, it is nearly impossible to determine origin of chips. For this, deeper understanding and monitoring of actual supply chains is required.
Also, it looks follow up work might be needed in CycloneDX specification to represent “known but not disclosed” state. In my case, this would be, for example, serial number.
VI Result and Summary
Resulting HBOM is published in ReARM repository here with its provenance document, describing step-by-step generation with several versions that we had, which data came from label, from images, from boot log and from my observations (i.e. instructions to connect serial).
Overall, I spent couple of days on this while getting interrupted on other things and doing OpenWRT port work in parallel. If the goal would be to take HBOM only, the process should take about 3-4 hours per steps above and is fairly straightforward.
While it is unlikely that an end-user would be interested in producing HBOM documents, it is an invaluable tool in the supply chain security, especially when dealing with many devices of the same type.
Once HBOM becomes an inventory item, it can then be quickly analyzed for findings and violations, similar to SBOM. When propagating large number of devices through supply chains, few hours to collect data seems like a small investment relative to the benefits that such inventory document provides.