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
- Header/magic: 4 bytes (
iRMC) - Features to be enabled by the license (bitmask): 4 bytes
- Type of license (temporary or permanent): 4 bytes
- 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
lkeyInitCipherKeyinlibfts_license - the AES IV is used in
decrypt_with_licenseinlibfts_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 ✨
Great article and research.
I for once cant seem to find the file you mention , when downloading the fujitsu firmware. Are the files on the request only open source, or is there a way to extract them from the .bin file of the firmware?
If i download and create the pen, can´t find it there either.
Run
binwalk -e FTS_TX140S2D3239iRMCKronos4FirmwareUpdatefo_TX140S20960Fsdr0344_1233853.BINand then extract the cramfs (you’ll needcramfs-tools).Thanks Martin for that great article,
can´t find HMAC and AES IV data in ibfts_license.so.1.12.1 🙁
For legal reasons, I will not be disclosing the values.
But the Ghidra screenshot includes a hexdump that you might find useful 😉
Edit: There are three 16 byte values you need to obtain from the library. Addresses shown in Ghidra hex view are offset by +0x1000 from what you would see when using
hexdump. If you look at thecodein the post, there is a clue about part of the HMAC 😉Really great work.
I am in the same boat, unfortunately.
Even studying your screenshot very thoroughly, I can not deduct which values to extract from libfts_license (only have a hex editor at hand). As I understand, the python script requires a 16 byte HMAC key, a 64 byte HMAC msg (or a 16 byte sequence that is multiplied “* 4”?), and a 16 Byte AES IV value.
In the screenshot I can only see a censored 16 byte sequence and a censored 32 byte sequence (which i can find in the file)… Tried all sorts of combinations, but never got a working serial number. 🙁
Any suggestion on which byte sequence to map on which script variable would be appreciated.
For everyone as dumb as me (posted before, but my post isnt released until now from author) two hints:
HEX for the script in the style of:
\x00\x01\x02
NOT(!) like this:
00 01 02
000102
Maybe that’s not clear for everyone.
Than just rotate the keys a little bit trough the possible three fields and remember: The Company always has a good message for you and a key clearly could just contain numbers, even if AES isn’t near as dead as some people believe. 😉
Extremely impressive work! I have no idea how you figured all of this out.
KVM_Media_eLCM working great on Fujitsu TX1320 M3.
The video redirection didn’t want to work using the Java WebStart avr.jnlp file (black screen), but if you go to Console Redirection > Video redirection and turn on the HTML5 player, you can see the video output from the machine just fine (not sure if this is a feature that appears only after IPMI fimware update).
Took me a while to figure out where to put what due to the riddle form, but it’s all been more rewarding in the end thanks to that 🙂
Thank you so much!
I found the values from your screenshot. Do I need more?
I am confused that the blurred values are longer than 16 characters? 🙁
There are three 16 byte values you need to obtain from the library.
Two of the 16 byte values happen to be adjacent to each other, which is why there are more than 16 bytes blurred.
Thanks for your work. With your screenshot was easy. Now I have two servers with KVM_Media.
I somehow struggle to understand where the begin of the relevant data is… any hint for the three address starts?
Python script worked with my tx1320 m2 MB. Many thanks for the posts and hints.
Okay, maybe a very dumb question:
I found the HEX-values, extracted them and then I got some errors. Maybe I don’t get the right meaning of the HMAC-/AES-HEX-values in the script (or the right fields to the right input). First of all, putting HEX to script directly from HEX-Editor is a bad idea -> spaces collides with len(). So I removed them.
Next I stripped the 0s out of the HEX, worked for two of three fields, but the one with the nice companies name statement doesn’t work obviously, cause of no leading 0. Do I get something totally wrong here? Should that HEX-field be cut into half?
A short hint would be very nice.
Than just rotate the keys a little bit trough the possible three fields and remember: The Company always has a good message for you and a key clearly could just contain numbers, even if AES isn’t near as dead as some people believe.
This sentence is very important, I have successfully found the secret key 😉
Thanks for the elaboration on this! In a test environment for educational purposes only, this works with a Fujitsu TX1320 M3 (iRMC S4 Firmware version 9.08F) and with KVM_Media (but not with KVM_Media_eLCM) using the Pyhton script (GitHub: halmartin/irmc_s4.py “Fujitsu iRMC S4 PoC”, linked in the article).
After updating to iRMC S4 Firmware 9.69F (Base: 9.69.F), the licenses still persist/work.
One interesting point: I observed a different license key in the exported XML than the one entered (using “iRMC S4” -> “Save Configuration” -> “Include License Information”).
If one does not get the combination/assignment of the three extracted 16 Byte hex values (blurred in the screenshot) right, try all 6 permutations. You can also check your script by feeding/comparing it with input/output values given here (article), which must match.
Of course the hex values must be noted correctly in Python, e.g.:
HM___K_Y = b”\x01\x01….\x01″ (mod edit: example values, do not interpret as a hint)
> One interesting point: I observed a different license key in the exported XML than the one entered (using “iRMC S4” -> “Save Configuration” -> “Include License Information”).
Yes, this can happen. I added a comment to the linked gist with a validator which will tell you which features are licensed as well as dumping the raw license as hex. You can input your exported license, and compare to the above description of the license fields to see what’s changed.
Thanks for this little riddle! Got it after some time 🙂
I had problems with the Crypto Module (Module not found) on Windows. I couldn’t install the pycrypto modul through pip because of missing C++ Build Tools but pycryptodome did work.
Hello. Thank you very much for the tutorial. By any chance, do you know the iRMC S2 license logic? Or could you steer me into the right direction, how to obtain it? Thanks
Earlier versions of iRMC (S2/S3) are based on an RTOS, and I do not have any knowledge of the license logic used in these. You can download the complete firmware from Fujitsu’s support website, and a disassembler like Ghidra or IDA should get you started.