Category Archives: Embedded

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 😀

Modifying the Sercomm AD1018 for NAND flashing

My previous work has mostly involved SPI-based flash, but more modern devices like the Meraki MR33 have only NAND storage and there are instances where it is necessary to modify the contents of NAND using hardware means (e.g. to downgrade u-boot before flashing OpenWrt).

There are a wide variety of hardware NAND flashers available on the market, however they are often expensive, proprietary, and slow. Hardware flashers like a Teensy++ 2.0 running NANDway or the NANDLite (which are both quite inexpensive options) will work for reading data, they are not at all convenient if you want to modify the data and rewrite it. Every NAND chip is unique and has its own bad blocks which you should take into consideration. The net result using these programmers is that you have a very slow workflow: you must obtain a consistent dump of the NAND through a device which often reads at only 100KB/s, modify the contents (recalculating ECC/OOB), and then write it back to the NAND.

Why bother with all of this when Linux has a very robust and fast mtd subsystem in the kernel?


Enter the Sercomm AD1018.

Sercomm AD1018

The Sercomm AD1018 is a DSL router originally produced for Vodafone España and based on the Broadcom BCM6328. There are two hardware revisions, which are the same apart from the amount of RAM: v1 has 64MB of RAM and v2 has 128MB. It can be found on eBay from Spanish sellers for less than 20€, and is supported by OpenWrt. As a bonus, you can easily modify the hardware to add SPI flash and then boot OpenWrt off of SPI.

With the operating system booted from SPI, you have a free NAND interface to do what you want. What do we want? A cheap, Linux-based NAND dumping and flashing platform!

However, there is a problem. The “NOR” OpenWrt image for the AD1018 doesn’t include support in the kernel for BRCMNAND so although there is support in the device tree for the onboard NAND, it is unusable in Linux. This makes the device significantly less useful as a NAND flashing platform.

This is easy to solve though: copy the kernel configuration for the smp target, which includes NAND, to the generic target:

cp target/linux/bcm63xx/smp/config-default target/linux/bcm63xx/generic/

You can download the binary image to flash from here.

After flashing the NOR release of LEDE as described in the installation instructions, simply flash the new NOR image with BRCMNAND support using sysupgrade:

sysupgrade -n /tmp/openwrt-21.02.1-bcm63xx-generic-sercomm_ad1018-nor-squashfs-cfe.bin

After rebooting you should now be able to access NAND flash from OpenWrt:

[    0.877092] nand: device found, Manufacturer ID: 0x92, Chip ID: 0xf1
[    0.883812] nand: Eon NAND 128MiB 3,3V 8-bit
[    0.888227] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    0.896083] bcm6368_nand 10000200.nand: detected 128MiB total, 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, Hamming ECC
[    0.908376] Bad block table found at page 65472, version 0x01
[    0.915264] Bad block table found at page 65408, version 0x01
[    0.923011] 1 fixed-partitions partitions found on MTD device brcmnand.0
[    0.930026] Creating 1 MTD partitions on "brcmnand.0":
[    0.935356] 0x000000000000-0x000008000000 : "storage"

Until now, apart from installing the SPI flash, we have only addressed software issues. The kernel output above is the stock NAND which is soldered to the PCB, not exactly practical for flashing NAND from other devices.

The OpenWrt wiki suggests hand soldering a TSOP48 socket to the PCB. I am here to tell you there is a much easier method.

You can purchase TSOP48 sockets for around $5/piece from distributors (or AliExpress) however I dislike these because I still sometimes have difficulties soldering the 0.5mm pitch of TSOP48, and wrecking a TSOP48 socket while soldering gets expensive quickly. In my opinion, there is a cheaper and easier solution: use a 24 pin 0.5mm pitch FPC connector and a TSOP48 socket for a TL866II.

The TL866II TSOP48 socket can be purchased for under $4 on AliExpress. The FPC to 2.54mm breakout PCB, 24 pin FPC cable, and 24 pin 0.5mm FPC connector can all be purchased for dirt cheap (~$0.10/piece) in lots of 10+ from AliExpress. I feel this provides numerous advantages over a surface mounted TSOP48 socket:

  • FPC connectors are very inexpensive, so if you accidentally destroy it while soldering, no big loss
  • Since the TL866II TSOP48 socket is connected via FPC cables, you can easily bring it between devices while you are iterating the flash contents

Thankfully, the designers of the TL866II TSOP48 socket routed every pin. However, you should be attentive because the pinout of the TL866II TSOP48 socket is not what you might expect:

When mounting the FPC-24P 0.5mm breakout boards, note that the odd-numbered pins are always on the outer row.

All that remains is to desolder the NAND flash and solder the FPC connectors to the AD1018 PCB

Finally, after cutting a small slot the flat flex cables can be routed outside the enclosure and the TSOP48 socket can be securely mounted

Now it is possible to put the TSOP48 NAND from another device into the socket and use tools like nanddump and dd to manipulate the contents. Since it is OpenWrt, you can even mount a remote filesystem using NFS, sshfs or similar to have even more storage.


While I feel the AD1018 is a very good NAND programmer for the price, there are a few important considerations to consider when comparing the AD1018 against commercial NAND programmers:

  • You cannot hot-swap NAND (however, it boots quickly and has a physical power switch)
  • Since brcmnand is built-in to the kernel and not a module, the router won’t boot if NAND is not present
  • Linux attempts to generate a bad block table when one isn’t present, and this may take quite a long time to complete
  • The AD1018 is likely difficult to obtain outside Europe