Generating the BMW CIC Mid Navigation FSC

The BMW CIC Mid is the Business Navigation system available in Europe, and never installed in vehicles intended for North America. As a resident of North America, investigation of the CIC Mid firmware is purely theoretical as I have no ability to verify the correctness of the reverse engineering, and therefore am not intending on releasing any keygen source code.

Source code to dump QNX IFS, ImageFS, and HBCIFS is available on github here: https://github.com/ReverseEngDotDev/dump_hbcifs

1. Similar to the previous post investigating the CIC Premium/High, the E89 spDaten pack was used, with the 9283251A.0pb extracted from the data\CM63F1 folder. I assumed the “CM” folder set was for the “CIC Mid” and this file was chosen as it was the only large file available in the folder with the same name as the “CIC” (63F1 series).

2. Unpack the 9283251A.0pb file.

An initial attempt to dump the 0pb file failed, as the base/boot part of the firmware does not contain the binary necessary to investigate the Navigation FSC activation. However, in the CIC High 0pb the file contained a standard IFS boot partition and an uncompressed ImageFS partition. The ImageFS partition was relatively easily dumped using a slightly modified version of the dumpifs tool. The new CIC Mid firmware uses a partition with an “hbcifs” signature, and there does not appear to be any tool to dump the “hbcifs” parition, or much information about hbcifs online.

3. The limited information I was able to find on the internet (Post from “turbo-quattro” forum here) states that hbcifs stands for “Harmon/Becker Compresed IFS” and memifs2 is used to extract the hbcifs partition. This information appears to be correct as Harmon/Becker is the manufacturer of the CIC system. So we get the memifs2 binary from the CIC High 0pb, diassemble with Ghidra, and go to the main() Function.

4. The first point of interest is the string “no image found at location specified”. Immediately preceding the statement we can see iVar5 being set. Following that function shows the subroutine which checks for the image signatures “hbcifs” and “imagefs”, and shows us which signature codes are used to identify the image type. We now know 0x0c is HBCIFS and 0x0b is ImageFS, so we can safely assume that 0x0d is IFS.

5. Scrolling further down the main() function shows a check for the IFS (0x0d) image signature as well as a statement indicating “decompress problem”. The function before the statement passes five (5) values and has decompression strings. Comparing the bit checks against the open source dumpifs struct, we can quickly determine the flags as well as the loop to decompress each block/buffer.

6. Returning to the main() function, and scrolling further down the disassembly, there is a check for the HBCIFS image signature (0x0c). Entering into the function above the “compressed data” string shows another string indicating a “crc16 int. error” and is likely a checksum routine prior to decompression. Below the “compressed data” and above the “decompress problem” string, the function passes a very similar five (5) values to the IFS Decompression Routine, but value three (3) is not identical. Entering into this function shows that it calls the IFS Decompression Routine, so the HBCIFS format is similar, but not identical to IFS decompression. Instead of decompressing multiple individual (up to) 64k blocks, HBCIFS passes the full size of the image to the LZO/UCL decompression. Additionally, unlike IFS, a different set of flags are used: 0x01 = LZO, 0x03 = UCL and 0x04 = {something else}

7. To decompress the HBCIFS, the dumpifs program can be modified to read the size from the HBCIFS header and pass it as a value to the IFS decompression routine.

The structure for HBCIFS is therefore

The Hex header in the 0pb file based against the above structure is:

8. Using the new tool on the CIC Premium/High (9283426A.0pb) and CIC Mid (9283251A.0pb) firmware allows us to dump all files from all firmware partitions without difficulty.

9. Disassemble “CicMidNavSecond” with Ghidra. This is a 30+ MB binary, and takes a really long time to fully process.

10. Using the same process as the CIC Premium/High, looking for common byte strings used in encryption routines, the same MD5 init seed “0x67452301” was found.

11. The same “.swt” key files were identified as strings in the CIC, the same “1B” file and file header is used, and even more surprisingly the same RSA E and modulo keys appear to be used.

12. Comparing the Main Key routines, both algorithms appear identical, using the same RSA ModExp, MD5 and DES rounds as the CIC High.

13. Without a CIC Mid to test, it appears that the same keygen could be used to generate the map activation code as the CIC High.

Title picture borrowed from : https://mca.electricmura.ro/en/blog-bmw-mask-ccc-cic-or-nbt-idrive/