Author Archives: Hal Martin

About Hal Martin

In my free time I like experiment with hardware and embedded systems. Here I write about personal projects and random adventures into firmware land.

Fujitsu iRMC S4 License

A few years ago we looked at iRMC S4 on the Fujitsu TX140 S2. iRMC S4 provides typical remote management features that you would expect to find in a BMC: remote power control, sensor monitoring and alerting, hardware inventory, and boot order over-ride/selection. Some additional features like the remote KVM and remote media require a license key.

Licensed IPMI features are not new and other vendors, such as Supermicro, have had their IPMI license reverse engineered.

Fujitsu are a somewhat niche vendor when it comes to servers, and to date I am not aware that anyone has publicly reverse engineered the iRMC S4 license.


They say a picture is worth a thousand words, so we will start with a diagram

iRMC S4 license contents

An iRMC S4 license has four distinct fields

  1. Header/magic: 4 bytes (iRMC)
  2. Features to be enabled by the license (bitmask): 4 bytes
  3. Type of license (temporary or permanent): 4 bytes
  4. CRC32 of the system serial number: 4 bytes

The above data is encrypted using AES-128, and the output is base32 encoded with hyphens every 4 characters.

For example, here is an iRMC S4 license (enabling KVM and remote media) for an RX chassis with the serial number YLNS012345:

ZKAF-Z5EG-PL5G-6GFR-YEG6-CKGM-KQ

And the actual license contents:

69524d43 0300000 0ffffff05 2e4dbb51

Licensed features in iRMC S4 include:

  • Remote KVM
  • Remote media
  • eLCM

Feature bit 1 is for KVM, bit 2 remote media, and bit 3 seems to be for eLCM (eLCM appears to only be available on some models).

Installing an iRMC S4 license on a TX chassis


Back in 2014, Fujitsu changed the iRMC S4 licensing to be “node-locked”, which means that a license is tied to a specific server and cannot be transferred. The installation of a volume license is not possible after 2015-01-01 00:00:00.

iRMC S4 tracks the “Power on Hours (PoH)” of the chassis, and it appears that there is the capability to generate a temporary license which will expire after a certain number of Power on Hours is reached, probably to provide customers with time to evaluate the value proposition of purchasing iRMC licenses.

iRMC S4 time limited license

If you are reading this, then you are probably not interested in generating temporary licenses. Setting the field to 0xffffff00 for a TX chassis and 0xffffff05 for an RX chassis will result in a permanent license.


Now that we have covered the fields in an unencrypted iRMC S4 license, it will be obvious that the example license ZKAF-Z5EG-PL5G-6GFR-YEG6-CKGM-KQ is not simply the base32 encoded binary license data.

Unlike Supermicro, Fujitsu use a static HMAC message and key to create an HMAC-SHA1 hash, the first 16 bytes of which are used as the key for AES-128. The AES encrypted data is then base32 encoded and the output is the iRMC license you install via the web interface.

I will not be disclosing Fujitsu’s HMAC key and AES IV here, but suffice to say you can download and unpack the iRMC firmware from Fujitsu and find the values in /usr/local/lib/libfts_license.so.1.12.1. Thanks Fujitsu!


For anyone interested in reverse engineering the iRMC S4 license validation themselves:

  • the HMAC key and message are used in lkeyInitCipherKey in libfts_license
  • the AES IV is used in decrypt_with_license in libfts_license

libfts_license in Ghidra, showing decompiled function and hexdump

Anyone looking for a simpler solution, a proof-of-concept for python is here. Note that you need to provide the correct HMAC/AES values obtained from libfts_license.


To anyone wondering, the license logic from iRMC S4 is not applicable to older iRMC platforms such as iRMC S2 or iRMC S3.

However, the license logic appears to be unchanged between iRMC S4 and S5. Hardware with iRMC S5 is too expensive to justify purchasing to verify this, but maybe someone will leave a comment as to whether the license logic described here is still applicable to iRMC S5.

Edit: An anonymous reader has written to say that the logic is unchanged for iRMC S5 ✨

Meraki MS210/MS225 hardware overview

The Meraki MS210 and MS225 series switches offer 24 or 48 ports of Gigabit Ethernet, four SFP/SFP+ uplink ports, a dedicated remote management port, and stacking capabilities via QSFP.

Meraki MS210-24 and MS210-48

The MS210/MS225 series are based on the Broadcom BCM56160 “Hurricane3” ASIC, and the Broadcom BCM82756 10G PHY. PoE models contain the Broadcom BCM59121 PSE controller. All switch models have 16MB of SPI flash (MX25L12805D), 256MB of NAND (MT29F2G08ABAEAWP), and 1024MB of DDR4 DRAM.

MS225-48LP internal PCB

MS225-48LP switch internals with PoE midplane removed

The Meraki codename for the MS210 and MS225 series is “brumby” and all brumby switches run the same firmware release (switch-arm). The MS250 is essentially the MS225 with hot-swap power supplies (similar to the MS220/MS320).

Keen readers may be wondering why the MS210 series has only SFP ports while the MS225 has SFP+ ports, given they are identical hardware and run the same switch-arm firmware. The answer is market segmentation; Meraki decided to artificially limit the speed of the MS210 SFP ports to 1G, even though the MS210 hardware is capable of 10G via SFP+. Early in the boot process switch_brain checks the switch model, and if it identifies as the MS210 series the SFP port speed is limited to 1000M.

The stock Meraki boot process uses u-boot on SPI to load a “bootkernel” (also from SPI), which then initializes NAND and using kexec boots the main firmware. The firmware layout follows the standard Meraki practice of having A/B firmware images: bootkernel1, bootkernel2, part.safe, part.old.


If you wish to flash your MS210/MS225, you will need to remove or socket the SOIC8 SPI flash (U18). This is because the ASIC is powered by the same +3.3V voltage rail as the SPI flash, and will attempt to boot when you attach your flashing device, which interferes with your ability to read/write the contents of flash. I prefer the Wieson G6179-10 SOIC8 socket (available from Adafruit). People outside the US will probably find it easier to desolder the flash and use a SOIC8 socket with prototype wires, as the G6179-10 is difficult to obtain for a reasonable price.

MS225 with SPI flash socket installed

Unlike the MS120, the MS210/MS225 do not implement secure boot, so all that is needed to develop on the platform is to recompile and flash u-boot from the Meraki GPL release and then interrupt the boot process and provide your own firmware build (e.g. via TFTP).

The UART header is J31 on both the 24 and 48 port models and follows the standard Meraki UART pinout (1: VCC, 2: Tx, 3: Rx, 4: GND) at 115200 baud.


The Broadcom SDK for the BCM56160 series implements the packet engine in userspace, using the linux_kernel_bde and linux_user_bde kernel modules to interface with the ASIC. In the Meraki firmware, the packet engine is a component of the userspace click daemon, which loads the bcm_click shared object during click router initialisation.

There are no public datasheets available for any of the Broadcom chips used in the MS210/225. While you can find information on OpenBCM, as far as I can tell the API provided by OpenBCM (via the kernel modules) which is used to implement the packet engine has no public documentation. If anyone has more information, please get in touch 😀

Riverbed SteelHead CX 255

The Riverbed SteelHead are a series of bandwidth optimization appliances that can typically be found for a reasonable price on eBay. Today we are looking at the Riverbed CX 255 (36€ from eBay.de), a small unit with 3 Ethernet interfaces.
Riverbed SteelHead CX 255

Powering the CX 255 is an Intel Celeron 725C (1C2T) soldered to the NAMB-3250MB motherboard, along with with 2GB of DDR3-1333 unbuffered ECC. You will not win any benchmarks with this CPU.

NAMB-3250MB motherboard (Rev. A102-1; 19A2325001-01) inside the CX 255

The CX 255 consumes 20W idle, and is powered by an external 12V 7A power supply (5.5×2.5mm, center positive).

Running powertop --auto-tune sadly does nothing to the reduce power consumption. It appears to the primary reason for this is the high power consumption of the DH89xxCC chipset used

DH89xxCC chipset features and TDP (PDF)

The console port uses the Cisco rollover cable pinout, and operates at 115200n8. The two 40mm PWM fans run at around 5000RPM, and while not they do not scream as some 1U servers do, they are clearly audible from several meters away.


OpenWrt x86-64 running on the CX 255

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:1c.0 PCI bridge: Intel Corporation DH89xxCC PCI Express Root Port #1 (rev 08)
00:1d.0 USB controller: Intel Corporation DH89xxCC USB2 Enhanced Host Controller #1 (rev 08)
00:1f.0 ISA bridge: Intel Corporation DH89xxCC LPC Controller (rev 08)
00:1f.2 SATA controller: Intel Corporation DH89xxCC 4 Port SATA AHCI Controller (rev 08)
00:1f.3 SMBus: Intel Corporation DH89xxCC SMBus Controller (rev 08)
00:1f.6 Signal processing controller: Intel Corporation DH89xxCC Thermal Subsystem (rev 08)
00:1f.7 System peripheral: Intel Corporation DH89xxCC Watchdog Timer (rev 08)
01:00.0 Co-processor: Intel Corporation DH89XXCC Series QAT (rev 21)
01:00.1 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
01:00.2 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

There are also the CX 570 and CX 770, which appear quite similar from the exterior. The CX 570 and CX 770 have three additional Ethernet interfaces and better CPUs. According to this document (PDF) the CX 570 has an Intel Pentium B925C while the CX 770 has an Intel Xeon E3-1125C v2.

From the lspci output on the CX 255 and the board layout, I assume that the CX 570/770 has an additional I210 controller and the remaining 2 Ethernet PHYs from the DH8900CC populated. I anticipate that the idle power consumption is similar to that of the CX 255.


Here is the lspci output from the CX 770:

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:1c.0 PCI bridge: Intel Corporation DH89xxCC PCI Express Root Port #1 (rev 08)
00:1c.1 PCI bridge: Intel Corporation DH89xxCC PCI Express Root Port #2 (rev 08)
00:1d.0 USB controller: Intel Corporation DH89xxCC USB2 Enhanced Host Controller #1 (rev 08)
00:1f.0 ISA bridge: Intel Corporation DH89xxCC LPC Controller (rev 08)
00:1f.2 SATA controller: Intel Corporation DH89xxCC 4 Port SATA AHCI Controller (rev 08)
00:1f.3 SMBus: Intel Corporation DH89xxCC SMBus Controller (rev 08)
00:1f.6 Signal processing controller: Intel Corporation DH89xxCC Thermal Subsystem (rev 08)
00:1f.7 System peripheral: Intel Corporation DH89xxCC Watchdog Timer (rev 08)
01:00.0 Co-processor: Intel Corporation DH89XXCC Series QAT (rev 21)
01:00.1 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
01:00.2 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
01:00.3 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
01:00.4 Ethernet controller: Intel Corporation DH8900CC Series Gigabit Network Connection (rev 21)
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

The CX 770 also includes minimal lights out management (Aspeed AST1050 BMC), which can be configured to share the PRI ethernet interface. The BMC only provides remote power control and sensor readings, there is no support for KVM or serial console redirection.