Mike Heskin
@hexkyz
Sep 6
Thanks to the great work done by 15432, we can finally decrypt the MIG flashcart firmware code. Here's what we've learned so far.
https://github.com/15432/mig_research
1) MIG is TX/GW, unsurprisingly. As explained by 15432, the exact same MIPS-like VM code is used within the firmware. A number of other similarities can also be found such as the FPGA communication code stack being the exact same as the one used by the SX Core.
2) The gamecard communication protocol (which is based on SNOW 2 and AES-CCM) is entirely implemented in the ESP32 firmware. MIG included a piece of previously unobtainable key material (the IV used for SNOW) in the firmware code, which could only be extracted by decapping.
3) However, a crucial piece of key material, the Lotus3 hardware AES key, is not visible to the ESP32. Instead, they've hid it inside the FPGA and request it to do the decryption of the relevant data. This alone makes it impossible to clone their hardware, but there's more.
4) Both the bootloader and firmware have multiple layers of verification. Aside from using the ESP32 Secure Boot system (which uses RSA-PSS), the firmware itself double checks signatures during the update process.
5) Additionally, there's a small MIPS VM handling some critical tasks which include verifying another RSA signature that lives inside a "secure block" (flash address 0x1FF000). This block also contains their firmware keys (encrypted) and other important material.
6) The firmware keys are stored encrypted and the key to decrypt them is generated by hashing (HMAC-SHA256) a chip unique IV in the bootloader with a chip unique HMAC key. The latter is programmed to efuses and locked from reading.
7) Decrypting the "update.s2" file is a matter of stripping away a first layer of TEA encryption, parsing metadata, decrypting the actual firmware code with the right AES key and, finally, deobfuscating the resulting plaintext through their custom XOR-based algorithm.
8) This last XOR-based algorithm is an absolute abomination of mixing random values and multiple seed sources just to make it as hard as possible to reverse engineer (even Ghidra wasn't able to produce an accurate decompilation of it, despite having support for Xtensa).
