Gorgias' Blog

IGS Arcade 逆向系列（四）- ASIC27协议和TSGROM文件静态分析

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

嵌入式架构分析

IGS的反盗版技术上不难，但是非常诡异，可能是代码写的太烂了。

IGS E2000 本质上，是 PC + 游戏基板的组合（研华设计）。既要考虑到 Anti-Copy （反盗版），又需要考虑到软件工程上的复用。ASIC相当于一个完全黑盒的计算模块，将游戏关键逻辑放在里面，既能提升性能，也可以防止破解。

主程序流程分析

游戏主程序会开辟一段 0x200034的栈空间，其中缓冲区占0x200000，而且这个栈开辟出来后不会恢复，这会导致IDA Pro无法反编译，不知道是不是故意的。

首先需要patch这个缓冲区大小，减小函数的栈帧，然后将函数 undefine，最后重新识别，就可以成功反编译。

Kernel mount_root 时，以及游戏程序启动时会校验 BIOS 版本信息，开发者却说是获取CRC结果，结果我愣是找遍了所有CRC的位置，也没找到任何反盗版有关的CRC计算逻辑；
BIOS 信息校验失败就校验PCI的驱动信息，如果失败，好像也没有任何操作，但其他地方也插入了许多一样的校验桩，校验失败就会阻止运行；
系统初始化：屏幕、音频、图形、文字、语言、ASIC、Timer、PLXPCI、游戏、音乐、控制器、摄像机、台账、控制、投币、混合器等等；
刷新4次ASIC，why???；
加载基础 action 文件（TSGROM格式），每次加载都刷新一次ASIC；
游戏版本校验，显示第一屏，加载字体，加载声音；
加载读卡器；
游戏Loop，4种状态(Game, Test, Setting, Demo)，可通过ASIC控制

游戏使用了SDL 1.2.7开发，SDL（Simple DirectMedia Layer）是一个跨平台的多媒体开发库，主要用于提供对音频、输入设备（键盘/鼠标/游戏手柄）和图形硬件的底层访问‌。但是这个性能比较低，只适合2D游戏。Percussion Master 2008 是2D游戏。Speed Driver 2 是 3D游戏，两者的差别可能很大。

开发者在游戏主程序每一处与 ASIC 交互的位置，都插了代码桩，暂时把他称作 RealTimeEvent，应该是统一事件处理程序，每次逻辑的变化、动画的变化，都需要刷新事件。用来实现各种复杂的控制功能，也附带了一些反盗版功能。不得不吐槽，这个代码质量真糟糕，每次都要做大量的计算，性能很差，和用纯 js + html 开发单页面应用一样。

状态检查桩的逻辑

更新时钟
计时器检查
Action处理
音乐处理
音频处理
按键状态以及控制输入
台账
游戏币处理
PLX PCI 状态处理
SDL 事件处理
绘制动态五边形动画
PCI 控制写入
ASIC 27 命令写入
PCI 数据读取
图形刷新

区域初始化

percussion master 2008 支持7个地区，3种语言；简体中文、繁体中文、英文。

ROIO BIOS 信息校验

内核会运行一个驱动 /dev/roio, 游戏程序通过此驱动对比内置的版本信息表，实现校验功能。内核本身和游戏程序均内置了表格，原理应该是开发者通过某些工具解析了BIOS信息，然后将物理偏移硬编码到程序和内核里面。

内核和主程序的 BIOS 信息表结构有些区别，Kernel的4字节对齐，但使用原理都是一样的。

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;
}

对比的逻辑也很简单，

第一步通过遍历程序内置的 BIOS Table，获取版本字符串地址、目标字符串物理地址、遍历轮数等。第二步，通过 IOCTL Call /dev/roio，对比System ROM 区域指定偏移和程序内置的对应字符串，只要有一个字符相等就通过，太蠢了。

该内核只允许运行在4种主板，但是游戏允许运行在更多的设备，因此需要校验主程序、内核、主板是否匹配。这是反盗版的机制，直接patch掉就行了。

经过统计，地址和版本字符串如下，所有地址都是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

接下来分析ROIO驱动，大部分代码都插了 Anti-Copy 暗桩，使用XOR，对性能影响最小，可以防止游戏A程序放到游戏B的系统运行。

输入参数 mask 0x1FB8408E
返回值 mask 0xC2E83AB8

ROIO 的 Magic Number 有三种：

0xfc 获取目标地址的32位数值，小端
0xfd 获取目标地址的32位数值，大端
0xfe 获取目标地址的8位数值

最后再 xor 0xC2E83AB8

这里的data作为偏移，基址是0xc0000000，然后加上BIOS信息的值，是因为x86打开了paging，因此CPU访问内存需要走虚拟地址。Linux i386 对于虚拟地址偏移的设定如下

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

通过IOMEM的map，也可以看到BIOS信息的地址位于 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

BIOS芯片封装是PLCC 32，使用RT809H成功dump。

使用系统启动后，BIOS ROM的一些数据被解析到了内存里，不是1:1 copy，偏移地址是 0xF0000，。

PCCard 随机数校验

我实在不理解这个代码的目的是什么，驱动代码里有SPY的关键词，可能是反嗅探用的暗桩？在启动程序、初始化游戏和print日志会触发，如果上面的BIOS Check 失败了，也会触发此校验。通过ioctl来请求/dev/pccard0，获取结果或者不获取结果。

request 0 列表，用于对比结果。列表有4个成员，对应相关偏移。从四个里随机选一个，并带上随机数，随机值区间 [17, 768]，本地计算后，发到驱动执行一下，然后发回来，实际上PCI没有真正参与。

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

request 1 列表，长度17

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

看[1,255]的值是否能命中列表的值，尝试5-30次，如果命中，尝试次数-1，然后再来一次。如果没命中，就通过ioctl来请求随机值对应的偏移（参数[17,768]），幻数就是命中的那个值。我感觉可能是用来初始化驱动的，实在想不到其他作用了。为什么写的那么复杂？

在游戏主程序的某处，发现了残留的代码，异或的内容是 0xD4AA268A，在 percussion master 2008 未发现触发逻辑，应该是另一个游戏的暗桩。可以更确定，这个功能就是为了反盗版的。（虽然设计的很烂）

ASIC 27 协议

A27 初始化

游戏主程序与I/O板的通信，经过 PLX PCI 9030 芯片，以共享内存的方式，进行数据交换。

游戏启动后，ASIC 27 初始化之前，会先加载PCI 9030驱动，并开辟一段缓冲区，专门用来存放 ASIC Buffer，里面有各种数据状态。开发者称作 CommandPort。

接下来初始化 ASIC 27，首先更新Checksum，将位于buffer的按键灵敏度、按键输入、灯光状态、system mode、buffersize累加得到数值checksum，然后放在buffer的两个位置。后续的每次ASIC 27 请求，都会重新计算 checksum。

首先写入0x2024字节到ASIC 27，cmd: 0xfe，也就是直接拷贝缓冲区数据到到共享内存。然后ASIC处理后，刷新的共享内存，并且会将sm从0x1c改为其他值，代表处理结束。

ASIC会将游戏的配置信息，同步OS用于更新游戏配置，将会更新以下目录

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

将sm设为0，同时再更新一次 checksum，发送到A27

System Mode

经过分析，以下模式

0x0: 默认模式
0x1: ASIC测试数据读取
0x2: 按键测试
0x3: 蜂鸣器测试
0x4: 灯光板测试
0x5: 投币测试
0x6: Trackball 测试
0x7: SelMode，IGS Logo
0x8: Teammark
0xc: Coin Page
0xf: option
0x14: Photo
0x10: Song Play
0x1a: CCD
0x1d: 调整音量

A27 System Mode Write 状态机

发送数据到ASIC之前的预处理，当 sm 为以下值，无处理逻辑，返回1

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

0x1: 测试数据写入
0x4: 灯光测试
0x5: 投币测试
0x7: SelMode
0x8: Teammark
0xc: 代码已删除
0xe: 代码已删除
0xf: 代码已删除
0x10: Song
0x13: 代码已删除
0x14: 代码已删除
0x1a: 摄像机测试
0x1d: 调整音量

其他值则触发 Assert

A27 System Mode Analysis 状态机

ASIC 返回的数据，由游戏主程序处理，当 sm 为以下值，无处理逻辑，返回1

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

System Mode 对应的处理

0x1: ASIC测试数据读取
0x2: 进入按键测试
0x3: 进入蜂鸣器测试
0x4: 进入灯光板测试
0x5: 投币测试
0x7: 加载 IGS LOGO
0x8: 加载 Teammark 数据
0xC: 代码已删除
0xE: 代码已删除
0xF: 代码已删除
0x10: Song
0x13: 代码已删除
0x14: 代码已删除
0x1a: CCD 信息

其他值则触发 Assert

按键状态机

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

Buffer 结构体分析

Buffer 的最大长度是 8192

Buffer 响应的 Header 格式如下

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];
}

Buffer 请求的 Header 格式如下

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 响应也会携带 Checksum，游戏主程序会验证。计算方式为以下数据的累加

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

Buffer 混淆分析

Percussion Master 2008对比旧版本，增加了简易混淆，目的是反盗版，避免拷贝ROM直接运行。当从缓冲区拷贝到 ASIC 27 buffer时，数据就会被混淆处理。

混淆的前提条件是 System Mode 符合下列值才会触发，刚好这些 mode 的数据都没有被Write状态机预处理。

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

混淆阶段，程序把 asic27_buffer 的数据复制到 dest。用 dest 作为源，分块处理，每块大小是 0x500 = 1280 字节。取数据块，用块头 4 字节 + mask_table 计算扰动值，根据扰动值对块数据做循环重排，最终写回缓冲区。

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

用 v3 算一个偏移量，如果剩余数据不足 0x500，则 v3 % (剩余长度-4) + 4；否则固定 % 0x4FC + 4，保证偏移范围在 [4, 0x4FF]。

先把 [v3, end] 拷贝到目标，再把 [4, v3) 拷贝过去，最终得到一个“旋转过”的块，前 4 字节（header）本身不按顺序复制，而是被跳过+重新拼接。

让 AI 写了一个 python 的代码实现。

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:
    """混淆单个 0x500 大小的数据块"""
    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]]

    # 计算偏移量（范围 4 ~ 0x4FF）
    obfs_value = obfs_value % 0x4FC + 4

    # 数据重排：
    #   [obfs_value:end] + [4:obfs_value]
    part1 = block[obfs_value:]       # 从 obfs_value 开始到结尾
    part2 = block[4:obfs_value]      # 从 4 到 obfs_value
    new_block = part1 + part2
    return new_block


def deobfuscate_block(block: bytes, header: bytes) -> bytes:
    """反混淆单个 0x500 数据块，需要原始 header"""
    if len(block) < 4:
        return block

    # 重新计算扰动值（必须用原始 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

    # block 的排列规则是：
    #   new_block = block[obfs_value:] + block[4:obfs_value]
    # 我们要反过来拼回原始
    part1_len = len(block) - (obfs_value - 4)  # 对应 obfs_value ~ end
    part1 = block[:part1_len]
    part2 = block[part1_len:]

    # 恢复成 [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("原始数据前 32 字节:", data[:32])

    obfs = obfuscate(data)
    print("混淆后前 32 字节:", obfs[:32])

    deobfs = deobfuscate(obfs, headers)
    print("反混淆前 32 字节:", deobfs[:32])
    print("反混淆是否正确:", deobfs == data)

TSGROM 解析

TSGROM是游戏多媒体资源文件，有脚本、贴图。类似 unity 的 assets。

PM2008 的 TSGROM 版本支持不低于 00.0000.0004，和PM1一致。代码写的简单粗暴，全是while(1)。

也有一些 rom 没有携带版本信息，不知道有什么作用，比如biglogo.rom，有大量LZSS图片数据，但是和代码里的颜色格式对不上，应该是历史遗留。

TSGROM 既可以从文件加载、也可以从RAM加载。第一次加载后，就会存到RAM，后续就不用再操作文件了。

PM2008支持 TGA、BPM、PCX的图形文件，TSGROM 格式又臭又长非常无聊，没必要展开分析，我开发了解析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

以 IGS Logo 为例，解压后有动画的每一帧的图片

Action Parser

IGS 的 TSGROM 定义了游戏的各种图形行为，并称之为 action，主程序通过解析 action 来实现功能。如果要在PC运行游戏主程序，游戏的各种事件都和A27协议有关，需要逆向分析对应Action，但是我想尝试最完美的破解方式，dump ASIC ROM 放到模拟器运行，不想分析这种屎山代码。

ACT BLOCK 数据块数量
ACT INDEX ACT 索引
ACT DATA Action 数据
ACT POOL Action 数据
ACT STEP 动作帧

主程序是符号剥离的，分析起来很费时间，简单记录一下：

在加载 TSGROM 时，程序会加载 act_data 到内存，根据 act_pool 的的数量，将 pool data 也加载到内存; 每个 TSGROM 会被分配独立的 Group ID。Action 系列的函数，都是根据 Group ID 来区分。最多 0x80 个 action group，每个 Group 长度 0x2AA4。每个 Group 还有对应的 index，action index 大小 0xaa9, 列表长度也是 0x80。

在加载 tsgrom 之前，首先创建 action 对象，总共 1024 个 action_data，每个 action_data 长度 0x8D 字节。接着调用 ActionUse 初始化 act_data，并且分配图形显示资源，用 ActionFace, ActionShow 等配置控制图形显示，最后调用RealTimeEvent统一刷新画面。

TSG ROM 暗桩

IGS 故意损坏了资源文件的某些数据块，需要通过 ASIC 芯片动态修复，这也是 IGS 的反盗版机制，防止破解者修改动画文件实现换皮游戏。

IGS Logo

Teammark

以 IGS Logo 为例，当 buffer 的标识数匹配 1 时，代表数据包类型是资源修复，当遍历到指定的块，此处是7，就将来自 ASIC 27 的 0x400 字节追加到对应的损坏区域，完成资源数据修复。

写在结尾

IGS将游戏主程序和硬件强关联，如果要将游戏盗版至其他平台，需要付出非常多的时间。

游戏框架、歌曲谱面，逻辑是状态机，比较复杂，不在我的破解目标内。

把逆向工程写到博客，感觉花费了更多的精力，自己逆向只需要记录一些数据，但是形成文章，就要写的让别人看懂。

下一篇主题：IGS Arcade 逆向系列（五）- ASIC27协议Hook和主程序patch工作

纪念血月，赞美女神

IGS Arcade 逆向系列（三）- Getshell

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

这段时间有不少进展，但是遇到瓶颈了，大概还有三篇的量，最近很忙，先更新第三篇。

我把芯片贴纸拆开并做了详细的分析工作，第一篇硬件分析方向基本上没错，更新了对IGS的芯片描述，第二篇文章代码有一些bug，已更新。

要高效分析游戏主程序，最好是设备上动态调试，首先需要shell权限。除了CF卡和IO口，我目前几乎没有任何对这个设备输入内容的途径。

如果走串口调试，第一步找到硬件调试口，下一步修改kernel内置的boot command。很麻烦，还要重打包回去，不够优雅。

CF卡有两个分区我可以直接写入，一个就是Kernel所在的Boot分区，另一个是日志和临时文件分区，那个说不定可以getshell，但是Pwn这个硬件不是我的目的。

IGS CRAMFS 重打包

之前我根据IGS魔改的cramfs特征，二次开发了cramfs-tools，但是它只能解包，不能重打包。它是不完美的，我有一点强迫症，想要让它作为真正的toolkits。

IGS 魔改了cramfs的结构体，在cramfs_inode加入了校验值，也就是每次读取inode就会检查。

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;
};

在get_cramfs_inode，有一个暗桩，用inode_magic异或根inode的magic，判断是否等于0x705DE1，如果不等于就出错。虽然简单，但是每个游戏都不一样，重复的patch工作也挺烦人的。

下图的可读性看起来不错，是因为我做了一些费时间的工作。其实这里IDA的反编译一开始是识别错误的，和汇编完全不一样。要把结构体先还原了，这里的分支才会正确，不然就会丢失很多代码。

我已经实现了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

修复 Shell 环境

IGS 在新版的PM2008，做了很多阻止破解的措施。这个Kernel非常老，我花了大量时间解决兼容性问题。操作系统，编译工具链，源代码反复测试了许多版本，终于找到了稳定的编译环境。

修复agetty

现在的系统初始化后是没有tty shell的，因为IGS移除了agetty。这个组件位于util-linux。需要重新编译，静态链接。

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

然后在 /etc/inittab，增加下面这行命令。看起来是有115200的串口输出，我还没有在COM口尝试。因为在卧室里研究，场地有限，我喜欢更优雅的调试方式。

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

修复SSH Services

IGS移除了ssh服务，本来想用现成的dropbear，结果没一个能运行。花了大量时间找到个兼容的dropbear 0.53版本，完成静态编译（解决了很多错误），很多特性是在代码里写死的，我甚至做了一些patch，但还会出现奇怪的问题。于是只能选择ssh，新版的ssh由于弃用了过时加密算法，连接旧版ssh都要指定算法。因此要选择较新版本的openssh，以及openssl。

编译好后生成密钥对，因为算法和格式有差异，所以要重新生成

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

sshd_config 需要手动配置这些

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

最后需要修复sshd的权限，否则会出错

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

在前文提到的启动脚本添加ssh启动命令

/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

修复ifconfig并且启用网络

IGS 禁止了网络连接，我在游戏代码里看到是可以联网的，游戏有一个OnlineMode，早期是有全球排名的，但当前版本不支持，代码里有明显的修改痕迹。没有地方可以触发进入OnlineMode。

系统甚至还有DHCP服务。配置IP的逻辑写在代码里。

ifconfig被失效了，应该也是被魔改了，自己重新编译一个。

/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

这样就可以连接外部网络了。

我还编译了一版 busybox，遇到大量兼容性问题，做了一些patch，也花了很多时间才编译成功。二进制文件可以在这里下载

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

将这些文件放到指定目录，然后重打包，写入CF卡，重启设备，ssh服务就可以直接访问了。

由于没有回显，只能将stdout输出到rdisk4s4，也就是ext3分区，读取并挂载查看回显。花了很多时间才调试成功，这两条命令用了无数次。

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

游戏环境分析

E2000主机有两个I/O接口，控制指令来自外部，即使拿到root也玩不了游戏。

游戏主程序

游戏主程序实际运行在/exec/PM2008v2 会启动3个进程

根据地址空间，可以判断出，此程序运行在X11，OpenGL渲染。并且可以控制读卡器。调用了/dev/plx/Pci9030-0，访问方式是DMA转虚拟地址，应该是游戏的物理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

游戏程序本身有大量字符串，看起来像是编码后的数据，在此之前，我从来没接触过Big5编码，直接让deepseek帮我写了个脚本识别。

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)

游戏是台湾地区研发的，使用了繁体中文，IDA不能自动识别。需要手动添加。

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

因为非ASCII，也没有太好的识别方式，就还是参考上篇文章的修复字符串思路吧。

运行游戏主程序，只会打印这些日志。

[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

代码里将dprintf逻辑移除了，所以不会打印日志。

瓶颈

现在遇到瓶颈了，因为节奏游戏的命中判定，是放到ASIC，ASIC把判定状态传递到CPU。主程序是没有判定逻辑的。目前把ASIC27协议分析出来了，自己写判定逻辑倒是没问题，但这就不叫破解了。只有破解了ASIC，才能完美模拟这些游戏。接下来需要Dump ASIC的固件，难度很高，不知道今年能不能搞定。

接下来还有两篇已经完成的工作，等有空再写。

IGS Arcade 逆向系列（四）- ASIC27协议和TSGROM文件静态分析
IGS Arcade 逆向系列（五）- ASIC27协议Hook和主程序patch工作

吐槽 Hexo

上个月我都Linux电脑CPU缩肛了，死因是长期运行，散热不好，我花了大量时间排查，迁移工具，然后把博客环境迁移到新电脑。

以前写博客都是nvm到旧版node，运行Hexo框架生成静态页面，8年没有动过。因为从那时起，hexo的依赖就很烦人，更新必出问题，导致我不敢更新。

旧环境在MacOS很难跑起来，不管是源码安装还是brew安装都不行。我不理解一个nodejs项目为什么要用到python3.8。

那一堆乱七八糟的依赖，用最新版Hexo也不行，很多主题都不兼容。我都用asdf了，怎么还能这样？果断放弃Hexo，迁移博客到Hugo用了很多时间。

IGS Arcade 逆向系列（二）- 游戏文件恢复

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

上一篇文章写到游戏有个破坏分区的保护机制，本篇将深入分析。

作为2007年发布的游戏，此游戏加固机制还是比较落后的，主要是靠一些拼接，修改特征的方法来加固。并没有现代APP加固的那么卷的特性。主要是加固的环节有点多，并且每个游戏都不一样。然后由于开发上的特性，（编译优化，代码风格），使得逆向分析变麻烦了。

要提取游戏其实比较简单，等游戏运行时通过shell从内存或者从文件系统（如果文件落地）dump就行了。但是如果要提取不同游戏，这样就太麻烦了，还是先静态分析吧。

总之，这个逆向过程像是在做MISC题一样，需要一些逻辑推理。

逆向陷阱

一般情况下，分析文件系统的内容，很少会先从内核入手，一般先看init相关文件。第一步一般都是看 /etc/inittab，脚本首先启动rc，然后启动图形界面

# 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

配置环境变量，启动X，然后启动读卡器，最后启动游戏，除了这个循环有一点反常，其他都非常正常。到这个时候肯定就认为/PM2008v2/PM2008v2是游戏本体了

#!/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

接下来分析 PM2008v2，第一眼看上去，里面有很多程序装载的代码。联想到之前有很多文件没有magic，猜测可能是拿来动态加载代码文件还原成elf的。但是后来 Nova 和我说这东西不是游戏，我才知道了它的异常。这个文件有很多glibc特征，感觉就是一个静态链接glibc的程序。

为了方便逆向和后期的游戏移植，我需要确认GCC和GLibc版本，PM2008v2: GCC: (GNU) 3.3.1，但是没有GLibc的版本信息。因此我直接找到系统的libc.so，版本暂定为glibc 2.3.2。在最新的linux下不好编译，docker下也出了问题。

分析伪游戏程序

编译 GCC 3.3.1

由于目标版本内核是i686的，我使用CentOS4编译，运行在VMware，为了保证优化之后的汇编代码一致，我要使用相同GCC的版本，然后编译。并且搭建这个环境，也能方便以后对辅助分析该平台其他游戏，也有一些帮助。前期准备工作多一点，后期就可以少走一些弯路。

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

使用阿里云的vault源，先安装开发环境依赖。

yum groupinstall "Development Tools"

使用下列配置，指定版本为i686，旧版的gcc，最好不要并发编译，可能会出问题（3.3.1没有遇到，3.2.2遇到了），然后删除系统自带的gcc，再安装。

../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

编译 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要解压到glibc目录

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

GCC 2.3.2编译可能会遇到一些bug，需要打patch，刚好E2000平台的Linux也是LFS版本，可以去这里下载 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

接下来配置编译选项，先暂时这么用吧，因为即使设置细分的优化选项，最后的汇编内容都和目标文件差异很大。

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

差异项：

栈帧：目标程序大部分的函数返回都是 0xC9 leave，而我编译的都是先move esp, ebp，然后pop ebp。
内链函数：目标程序函数内部的call，一些中等长度的函数，会被优化成内联函数。

上述内容，即使我将编译优化级别设为O3，也几乎没有变化。手动配置fomit-frame-pointer、-finline-limit=n等信息，也没用。也许需要手动设置__inline__吧，我没时间去验证。这个情况，用flare生成signature，几乎还原不了那种函数内部带有call的符号。

经过分析，PM2008v2这个程序，就是一个killdisk函数，静态编译了glibc。

因此，如果执行inittab，是不可能启动游戏的。

系统初始化分析

网友的逆向成果

Nova之前告诉了我一些信息，实际上，仅从这个笔记，我看不出具体的加载流程，只能看出文件头需要还原，然后rc.0实际上是elf文件，启动时会执行。而且Submarine Crisis游戏文件和我的PM2008游戏文件又一些差异。

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

这个脚本是用于还原游戏文件的，我尝试了一下，可以生成一个ELF，但是放到IDA分析会出错。我并不知道生成的文件要如何运行。因此还是需要自己分析一遍。

分析内核启动过程

通过分析依赖和其他环境变量，并没有找到任何能启动游戏的路径。在上一篇文章，分析了文件系统挂载，在挂载之后，还有一系列操作。IDA遇到长度过大的函数，可能就会出错，无法反编译。但是问题不大，麻烦的不在这里。

上一篇文章由于是分析基于开源代码魔改的filesystem，可以直接对照逆向，因此不还原其他符号，问题也不大。该内核版本是2.4，bzImage没有携带符号表。这里的代码很多是IGS自己开发的，有些系统调用不是通过int来调用的。如果有用到syscall，在符号没还原的情况下分析，还是有一些麻烦，如果用bindiff，就需要在ida 8下用。我没有时间去移植到Mac上。Linux Kernel有一个syscall table，如果IGS没有自定义过syscall，那么可以直接将自己编译的kernel的syscall 符号照搬过来。

另外，IDA9对这个老的Linux 2.4内核解析不太好，很多交叉引用和汇编指令都没有识别出来，需要手动修复。

修复立即数交叉引用

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}")

修复字符串数据

可能是因为交叉引用没有识别完全，字符串识别总是会错失前面几个bytes，需要手动修复字符串。

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

根据上图代码，可以得知游戏初始化的第一步是先运行/bin/zsh，并且携带这些参数。

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

下一步就是运行/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

最后运行这些

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

Kernel Cmdline可以在parse_cmdline_early找到，并非LILO控制。

如果从外部设置了bootcmdline，其中有一个暗桩，会检测bootloader参数是否等于”JBoot“，如果不等于，就进入死循环。

这个JBoot是不是代表James写的Bootloader？👀

bootloader=JBoot

内核自带的启动命令

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

并没有设置init=，因此肯定会执行/sbin/init，然后执行/etc/inittab

恢复ZSH符号受阻

线索到了/bin/zsh，这个程序入口和PM2008v2一样，我判断也是基于glibc改的，但是我导入FLIRT Signature，只能识别出最里层的函数，还是那个编译优化的原因。

/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

目前不知道到底是基于什么GCC和GLibc改的，考虑到后面可能有很多程序也会用到glibc，所以需要确定是什么版本，看看有没有快速恢复符号的办法。

依赖关系分析

使用我五年前开发的YAFAF，可以很快找到相关的依赖关系。rc*.d应该是游戏的代码。

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)

从这些特征来看，这几个文件，应该是多个不同环境编译的elf文件的碎片构成。

并且/sbin/init也是基于glibc2.3.X，所以用gcc3.2.2编译glibc2.3.2吧，基于centos3，编译这一版GCC，不能用并发，否则会出错。还好我以前编译openwrt遇到过类似错误，不然又要卡很久，搜都搜不到是啥原因。

../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

编译GLibc，不管是用O2还是O3，最后几乎都没有内联函数优化。目前还搞不明白是什么原因，也搜不到，问AI也没用。

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

恢复分析 ZSH 符号

我不喜欢做机械而重复的工作，如果要我直接逆向zsh，我会觉得非常无聊。这个版本ida对识别instruments不是太好，很多地方需要手动恢复。用下图脚本恢复完后，下一步就是恢复function entry，在我上一篇文章有类似的脚本。

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)

因为没有办法用glibc的signature，我想了一个比较傻的办法，但是速度比调用MCP分析要快。

先把文件A（自己编译的）的glibc字符串完全恢复，恢复函数入口。在文件B，先修复函数入口，修复立即数偏移，修复字符串，去重，去除过短字符串，然后逐个匹配文件A的字符串，并筛选。从筛选结果遍历交叉引用，将不重复且为函数的筛选出来。

如果文件A的这些函数有符号，就恢复到文件B；
字符串作为参数入栈的函数，找到当前函数空间的所有call，如果目标地址没有符号，也用这个办法去还原入栈的函数符号。
递归设置符号，比如恢复了这个call的函数，然后再去call函数内部寻找其他的函数。这个感觉没什么必要，因为会遇到很多情况。

IDA Pro 脚本，从目标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 脚本，将A到交叉引用符号加载到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()

这些这几个脚本比较糙，还需打磨，主要是现在够用了。而且可能作用不是很大，因为做了这几项优化后，很快就能看出这几个ELF，实际上没有魔改Glibc，只是静态链接了而已。并且都是用 libc_start_main 来启动主函数。

修复GECA和rc0.d

从 /dev/hdc1 的 0x1B44 * 512 位置读取 0x400 字节，这个是一个ELF Header，写入到 /mnt/head 里。

IGS应该是把这个ELF头藏在了FAT分区的空白处。因为分区是连续的，无法直接从分区布局看出藏了内容。

从 /bin/arch 的末尾的位置读取 0x400 字节，写入到 /mnt/GECA 里。

然后将 /etc/init.d/rc0.d 追加到 /mnt/GECA 末尾

修复游戏文件

在我开始分析之前，Nova 把他和 BatteryShark 研究的进度分享给我了，他们已经将 Speed Driver 2 的ELF还原，但是这个ELF还是有问题的，并且不能用在其他游戏，比如Percussion Master 2008。 IGS Dump EXEC

因此还是要自己动手，恰好我也要逆向分析还原游戏文件的代码。

在内核启动阶段，GECA 被 zsh 修复后，立刻就会用相同的环境变量和参数运行。

rc* 的拼接顺序，是通过一个字符串变量来设定的，每个游戏都不一样。

这个数字字符，刚好对应 /etc/rc.d 的文件顺序

2 1 3 5 8 4 7 6 9

GECA 代码运行过程：先将/etc/rc.d的碎片，根据不同顺序来设置剪切尺寸，输出到/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

然后挂载ramfs在/exec，将这些文件拼接成真正的游戏文件，替换掉原本的硬盘破坏程序。接下来的启动过程就符合前面的 /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

可以编写一个脚本来实现这个过程

#!/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

修复后，虽然避开了多个版本的glibc特征，但ELF可能还有问题，因为每个游戏的主程序恢复算法还是有略微差异。PM2008的恢复逻辑输入就比SD2多两个参数，先分析PM2008吧。

还需要动态分析一下内存里的ELF文件是怎么装载的，但是现在发现，在游戏机接网线或者键盘，就会自动死机，不知道是不是安全机制。下一篇将分析如何在设备上动态调试。

IGS Arcade 逆向系列（一）- E2000平台分析

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

前言

2010年是街机的黄金时代，随着移动终端和家用游戏机普及，街机行业也逐渐走向没落，尽管国内出台了一些政策鼓励游戏游艺设备行业发展，但此行业在未来一直都不被资本看好。2020 疫情更是给电玩行业带来了很大的打击。

在以前，100元可能只能买50个币，现在100元可以买200个币。

我喜欢赛车游戏，湾岸Midnight、头文字D、Speed Driver是近几年电玩城最火的游戏，因为它有账号功能，具备社交属性。前段时间在破解极速5的玩家APP，才知道IGS (鈊象电子)就是我小时候玩的三国战记和西游的厂商，IGS反破解在整个行业都是顶尖的，竞速游戏的极速系列更是号称无人可破解。

上个月，我家旁边的大玩家电玩城倒闭了，我感觉迟早有一天极速系列游戏会消失，便想挑战破解极速系列游戏。

IGS 极速系列发布顺序如下：

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

我计划从E2000平台开始破解，难度肯定比PGM（PolyGame Master）更低，因为是基于PC开发的，不需要额外模拟声卡和显卡。硬件几乎没有物理保护，CPU指令集是x86，OS是Linux，没有反调试，也没有VMP，这不就是新手村吗。

Speed Driver系列在亚洲影响力媲美湾岸Midnight，头文字D，雷动G（都被破解了）。IGS的反破解是最成功的，在整个产品生命周期内都未被破解。

硬件分析

在 Arcade-docs 可以查询到每个设备的硬件信息和支持的游戏凭借我擅长的淘电子垃圾能力，已经搞到一台E2000主机。国外有不少爱好者购买，所以价格涨上去了。

外部接口分析

正面有两个RS-485接口，并且CF卡可以从外部拆卸

背面接口，具有千禧年PC的接口特点

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

主板分析

考虑到这个破解难度不高，其他贴了贴纸遮盖丝印的元件就不分析了，太麻烦

我买的这个主机安装了 Percussion Master 2008 游戏，但极速2也能运行

主板型号：I-JOIN E2000-V256 IH-02 （研华）
A - CPU：Celeron M 370 (1.5 GHz)
B - 北桥：未知
C - GPU：NVIDIA GeForce 6200 (256 MB, GDDR2)
D - 2 x DDR 333 256MB
E - Chipset: Intel 852GME (ICH4-M)
F - PCI9030，是GPIO芯片，可能用于游戏控制器的信号传输。
G - I/O 控制器有LPC接口
H - A11 BIOS芯片 SST 49LF004B（PLCC32）
I - IH-C02 ALTERA EPM3032ALC44-10N CPLD (PLCC44), 控制器，里面有ROM，用途不详
J - IGS EV29LV640-90PCR 8MB EEPROM，DIP 48-Pin 封装，IGS定制的芯片。这个芯片专门贴了游戏名称的标签，说明BIOS ROM 也和游戏有关。可能会有跟V21芯片相关的内容。
K - V21，IGS036E，也许是一颗FPGA或者ASIC，用于加密处理控制信号的输入输出
L - 64K x 16 HIGH-SPEED CMOS STATIC RAM x3
M - CF卡：ADATA 2GB (266X)
N - IDE硬盘接口

我有很多种办法拿硬件的root shell，但我对游戏加载的过程更感兴趣，因此先做软件逆向分析吧。

I/O板分析

这几块板子又称控制板，应该是用于连接游戏控制器，比如方向盘、刹车油门、投币器之类的。

通过连接主板的25pin + 30pin 的I/O口进行通信

价格可能比主机本体还贵

应该可以使用逻辑分析仪来捕获这些传感器信号，然后实现控制功能。但据说控制信号由V21芯片（ASIC）处理，可能会加密。我也不打算去仿制一个控制板。这种街机游戏没有地平线5好玩。现在电玩城也便宜，真想玩的话，就直接花钱去电玩城，或者买一套方向盘在家里玩。

文件系统分析

直接dump CF卡，文件大小2GB，file命令的回显如下：

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

启动过程，LILO作为MBR，直接安装在第一个扇区，用来引导Linux

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

通过fdisk查看分区信息。是Linux操作系统，四个分区，并首尾连续，最后一个分区之后的内容，都是0x00，不存在隐藏分区

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

E2000平台的分区有一个特点，第三分区和第四分区，顺序是反的。

第二分区和第四分区，7z无法完全提取，binwalk能识别出一些压缩区域，因此大概率是经过了魔改的文件系统。

每个分区的用途如下（最后我找到了分区2，4的原始文件系统类型）：

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

Kernel 逆向

目前未找到rootfs和游戏程序，他们大概率位于第二分区和第四分区。我认为逆向kernel可以少走不少弯路。不依赖内核，其实可以直接硬逆出文件系统的格式，但这样很无聊，而且最终写出来的extractor，肯定比不了开源的文件系统解压工具。首先看第一个分区，有一个 loader 和 kernel。显示了内核版本，但是这里不一定是正确的版本。

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经过了IGS 定制开发，会显示，IGS Loader v2.0 Boot Menu 2007/04，可判断版本是lilo-22.8

这里没什么好分析的，直接开始提取vmlinux，内核文件是bzImage格式，需要解压

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

接下来就是普通的内核逆向，第一步计算基址，基址有很多种确定方法，可以参考我其他文章。

这里多看两眼就猜出来了，0xC0100000

基址配置正确，IDA就可以自动识别出一些交叉引用，剩下的需要手动还原。IDA 9.0修改了一些API，又得重新写一下脚本。

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")

# 可以根据实际情况自己定义 function entry opcode

当然到这里还没有完全识别出全部交叉引用，在data段，还有一些字符串和offset还原的不是很好，但影响不大，实在是没有思路的话，就把这些内容还原，说不定会有新发现。

接下来就是找分析切入点，实在没啥技术含量，我有很多种方案，比如从文件系统特征入手之类的，但全写出来就像说“茴字有五种写法”一样搞笑。

可以确认内核版本是 2.4.31，并且IGS版本是v1.0，而不是bzImage显示的v0.5。

根据下列字符串，可以确定IGS魔改文件系统对应的原始文件系统版本

rofs：cramfs
shfs: squashfs 2.2

Linux 2.4.31 没有squashfs，直接找squashfs的patch，IGS魔改SHFS是基于squashfs2.2。 https://master.dl.sourceforge.net/project/squashfs/OldFiles/squashfs2.2r2.tar.gz

Linux 2.4没有支持kallsysm，因此需要手动还原符号。一些printf，memcpy，str之类的函数可以快速一眼看出来，但是我要分析系统启动过程，所以需要还原一些内核专用的符号。

这种老设备，在新的linux下没有办法交叉编译，我安装了一个CentOS 5.10的32位虚拟机，成功编译，提取出 System.map 和 vmlinux，这样就可以方便对比IGS魔改的部分。

对于这种找不到ramdisk或者rootfs的固件，第一步肯定是找到kernel里的sys_mount和boot parameters

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)

这里可以确定，rootfs应该是第二分区，游戏数据在第三分区。

挂在ramdisk的逻辑，位于此处

prepare_namespace
  ->rd_load_disk
     ->rd_load_image
       ->identify_ramdisk_image

在此次可以确定IGS 支持 squashfs 和 igs rofs 格式的ramdisk。并且可以确定它们的magic。

分析过程就不记录了，他们把 FS 的header魔改了，分析起来有一些恶心🤢。

提取文件系统

我分析了 E2000 平台的三种自定义文件系统 header，内容如下。

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

以 Percussion Master 2008 为例

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;

将上述文件header，移植到cramfs-tools和squashfs-tools，就可以完美提取文件系统，并且还可以发现文件是否损坏。我已经将代码上传至github。https://github.com/gorgiaxx/igs-toolkits

这个版本提取难度不高，但下个版本E3000就用上加密了。

玩家 @novacosmic00 之前请我帮忙提取 GoGoBall 的文件，但他说他已经解密了其他游戏的文件。唯独 GoGoBall 解不了。用我修改的工具尝试提取，发现文件CRC不对，但还是能提取出大部分。

在我提取完固件之后，和玩家 @novacosmic00 沟通，才知道两年前有人研究过这个，并写了提取脚本。

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

作者可能是根据文件系统内容，找出地址规律反推结构体的，这也是一种办法，但缺点是提取出来的文件可能比较混乱，而且无法检测CRC错误。

shadow-

shadow文件，默认都清空了root密码

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

这是原始的文件

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

反破解

/PM2008v2/PM2008v2，符号去除了，并且根据字符串特征，也像是正常的loader

但实际上，如果在自己电脑运行，他会把你分区前512k写0。我当时居然运行了，还好我没给root，而且硬盘是NVME的。谁能想到这个18年前的游戏，还有这一手🙈。以前从来没接触过这个领域，据说街机的反破解有很多自杀式逻辑。

下一篇文章将分析游戏内部的保护机制

参考

萌娘百科 - Speed_Driver系列

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

VW ID.4 ICAS1 车控分析

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

前言

2021年在360搭了一套ID.4台架环境，本来快要出成果了（拿到了ODIS内网权限，还有ICAS3的root），被安排出差去搭建展示车，后续工作计划被打乱。这期间不管是工作还是生活都遇到了许多糟心事，便停止了研究。

算是一个怨念项目吧，今年5月我在机缘巧合下又研究了ID.4的ICAS1的车控逻辑，还有一个怨念项目是CAN-Pick NG，写了一半又搁置了，不知道2025可不可以完成。

ID.4 是大众MEB平台，EE架构总共有两个域控制器，ICAS1, ICAS3。其中ICAS1(J533)与车身控制有关。下图是J533的位置，位于序号13。将线控模块装载到此处，可以实现车身监测和控制。

车内ECU拓扑

Classic CAN： 500k

CAN-FD：仲裁域500k, 数据域2M。若要分析CAN-FD，ZLG设备最合适。

通过分析 ELSA电路图和大众内部培训资料，发现总线命名混乱，必须重新整理才能得到正确的CAN拓扑图。

J533总共有9路CAN，4路LIN（暂不需要），关键ECU如下。

Running-Gear CAN (CAN-FD)
- J104 - ABS
- J500 - EPS，转向助力控制单元
- NX6 - 制动控制器 (Brake Booster)
Powertrain CAN (CAN-FD)
- J623 - 电机控制模块 Engine/Motor Control Module
- J841/J944 - 电驱单元
- J234 - 气囊（不能在这里Fuzzing，危险）
Driver Assistance CAN，CAN-FAS (CAN-FD)
- J428 - 车距调节控制单元
- J446 - 泊车雷达控制单元
- J769/J770 - 行驶换道辅助系统控制单元
- J928 - 全景摄像头控制单元
Convenience CAN (Classic)
- J527 - 电控换档模块 (Steering Column Electronics Control Module)
- J605 - 行李箱盖控制单元
- J764 - 转向柱锁
- …其他车身控制
CAN-EV (CAN-FD)
- J979 - 加热与空调控制模块 (Heater and Air Conditioning Control Module)

J533连接器T40a定义

T40a 连接器和表格对应如下。

总线安全策略

网关隔离

多功能方向盘控制信号，由Convenience CAN接收，但是底盘CAN的ECU也能收到。底盘CAN发出的多功能方向盘控制信号，不会被J533转发到目标ECU。

CRC 校验

分析CAN总线变化，可以看到大部份报文的变化规律，第一字节随机，第二字节有规律递增。第一字节是CRC，第二字节是计数器。

CRC 初始值

参考OpenDBC github /opendbc/can/common.cc volkswagen_mqb_checksum

可以获取VM MQB平台的 Checksum 初始值，但是ID.4有很多新的CRC初始值，我通过逆向分析并记录在下面了。

大部份控制信号有CRC和计数器，ECU不会校验某些不重要功能的CRC，比如天窗，车窗，鸣笛。但是会校验转向助力，行李箱盖开启，雨刮等影响驾驶的功能。

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 算法

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:
        # 无需校验
        crc ^= [0x00] * 16  # 默认情况下，返回全 0

    crc = crc8_lut_8h2f[crc]  # 标准 CRC8 8H2F/AUTOSAR 最后一个 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 信号

Convenience CAN有以下信号通信，可用于状态读取，车身功能基本上可以通过此路CAN进行控制。包括空调，前后大灯，鸣笛，雨刮，车窗，车锁，车辆状态等信息。

0x12B	GRA_ACC_01	自适应巡航，GRA系统，ACC，
0x1F0	EA_02	应急辅助
0x205	SAM_01	开关和执行模块
0x2B7	RCTA_01	Rear Cross Traffic Alert，后方交通警示
0x31B	ESP_24	
0x366	Blinkmodi_02	闪烁模式
0x397	LDW_02	车道偏离警示系统
0x3BE	Motor_14	电机控制
0x3C0	Klemmen_Status_01	端子状态
0x3CE	TSG_HFS_01	后座门窗功能系统
0x3CF	TSG_HBFS_01	后门窗户功能系统
0x3D0	TSG_FT_01	前门功能系统
0x3D4	SMLS_01	转向柱开关模块
0x3D5	Licht_Anf_01	灯光要求
0x3D6	Licht_hinten_01	后部灯光状态
0x3DC	Gateway_73	这些信息涉及车辆的各种信号和状态，包括系统提示、安全提示、故障诊断、信号更新和旧信号的替换
0x48B	BEM_06	低电压能源管理
0x520	Airbag_02	气囊2
0x551	WFS_01	车钥匙防盗
0x582	HDSG_01	后备箱管理状态
0x583	ZV_02	中央门锁系统
0x585	Systeminfo_01	诊断和生产模式设置
0x592	Kessy_04	智能钥匙系统（Kessy）以及远程停车功能的状态和控制
0x5A0	RLS_01	光传感器和雨量传感器
0x5A7	TM_01	Telematics
0x5F0	Dimmung_01	调光
0x5F4	Innenlicht_11	车内灯光
0x641	Motor_Code_01	电机设码
0x643	Einheiten_01	单位设置
0x656	ELV_01	电子转向柱锁
0x658	Licht_vorne_01	前灯状态
0x65D	ESP_20	
0x668	Klima_12	空调系统
0x670	Motor_18	
0x6AE	Spiegel_01	后视镜
0x6AF	Rear_View_01	后视摄像头
0x6B2	Diagnose_01	
0x6B4	VIN_01	
0x12DD54C9	SAL_01	照明模块

其他信号

DBC已经分析出来了，暂时不公开。

0x184
1. 锁车
  1. 第二字节 后视镜开 0x20 开
  2. 第三字节 后视镜关 0x40 关
2. 车窗
  1. 第六字节 车窗  04 左前下，02 左前上，40 左后下，08右前上，10右前下
  2. 第七字节，01右后下
0x185
1. 车窗控制，10 20 up 40 80 down
  1. 第一字节 前排
  2. 第二字节 后排
0x598
1. 天窗控制
  1. 第三字节 0x20 无 0x21 tap 0x22 滑动 0x25 长按
  2. 第七字节：04 关一下，08 一直关，0C 开一下，10 一直开， 14，1c其他

控制转向

要求档位在D/B或者R档。以下五个信号可以用于控制方向盘。

LWI_01 Lenkwinkelsensor
LH_EPS_03 Lenkhilfe Electric Power Steering
HCA_01 Heading Control Assist
GRA_ACC_01 Geschwindigkeitsregelanlage & Adaptive Cruise Control
PLA_05 Park Lane Assist

提示

组合使用0x86, 0x9f, 0x126, 0x12b, 0x302信号，在CAN-FAS发送，可以实现泊车方向盘转向功能。
组合使用0x86, 0x9f, 0x302信号，在Gear-Running CAN发送，可以实现方向盘转向。
其中0x9f(LH_EPS_03)和0x302(PLA_05)两个信号都可以直接控制方向盘。
0x302没有CRC校验，因此控制方向盘比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

控制方向盘Demo，仅让方向盘动起来，真正要实现远控，需要有力学的知识，还要设计控制算法。

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  # 默认情况下，返回全 0

    crc = crc8_lut_8h2f[crc]  # 标准 CRC8 8H2F/AUTOSAR 最后一个 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)

注意事项

离开车辆之前，确保CAN总线处于接通状态，否则会大量耗电。
不要对Powertrain 和Running Gear CAN 进行 Fuzzing，可能直接会导致人身伤害，另外，也可能导致ECU异常，产生潜在隐患。比如转向灯失效，后视镜无法打开。

QNX7 密码 hash 算法分析以及 Hashcat 模块编写

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

前言

在 2021 年想要碰撞 QNX Hash 发现 hashcat 不支持 QNX 6.6.0版本。当时 issue 就有人提了这个需求，但我一直很忙没时间开发。

直到2023年9月的艰难单刷工信部车联网攻防演练，又遇到了 QNX 7 的 Hash，发现那么多年过去了还是没支持。

为了防止下次又遇到这个需求，于是就抽空研究了 qnx 的库还有 hashcat，为了编写 hashcat 模块走了一点弯路。

QNX /etc/shadow hash算法分析

根据官方文档 QNX 700 docs: accounts_etc_shadow，可以得知Hash组成如下

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

这个 hash 使用 @ 作为分隔符，大写的 S 代表是 SHA-512，小写的 s 代表 SHA-256。如果加逗号和数字就代表迭代的次数。随后是 Base64 格式的 hash 和 base64 格式的 salt。

阅读完 QNX 官方文档的描述，给人的感觉是原来那么简单。如果看了 hashcat 的 QNX6 (-m 19200) 的模块，第一反应就是，是不是改一下迭代和格式就行了？

于是我复制了一份 QNX6 碰撞模块，想复用代码减轻工作量。按照官方文档适配，hashcat 总是返回 self-test 失败。随后分析 /src/OpenCL/m19200.cl 发现参考了 John 的代码，并且做了一些 hack 的处理，不够优雅。首先猜测是这段 CL 代码有 bug，下一步就是去分析 QNX 7 的 hash 生成逻辑。

hash 的生成逻辑在 /usr/lib/pam.qnx.so

分析完逻辑，和 m19200.cl 对比发现，首先旧版本 CL 代码里轮次不对，第一轮就是盐和密码拼接计算一次 SHA，其次新生成的 digest 没有和上一次结果异或。所以不是简单 base64 就行的。

其实新版的 hash 生成逻辑使用的是标准的 PBKDF2 (Password-Based Key Derivation Function) 算法，很多软件（Adobe、MacOS、Cisco等）都使用这个算法生成 Hash，迭代次数越高，碰撞 hash 的效率就越低。QNX 官方文档没有明说算法名称，只说是 SHA-512，某种意义上提高了安全研究门槛。

可以使用 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

Hashcat模块编写

参考官方文档

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

最开始我还在想办法写新的 CL 代码，得知是标准算法后，直接摆烂，想找一个顺眼的来改。

./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 每次运行都会自检当前模块，ST_HASH 和 ST_PASS 就是测试用例。于是把 KERN_TYPE 直接改为7100，打算一点一点调试，但是没想到一次就跑通了。

hashcat 是开源项目，合并代码比较慢，所以附上代码。

/**
 * 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;
}

参考

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

固件逆向的通用技巧

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

前言

这个是多年前自己为了方便查阅的写的笔记，记录的是碎片话思路，很乱，没有操作步骤，持续更新。

这里指的固件是从存储芯片提取的原始文件或升级文件。

原始固件逆向的特点

固件文件难以获取
网上很少案例，全靠自己经验摸索
不能直接运行，调试困难
大部份符号无法还原，汇编代码范围要手动指定
几乎没有代码混淆

固件的分类

根据系统架构分类，主要分为SoC固件和MCU固件。SoC固件一般由处理器单元和外围单元等组成，由处理器内置的BootROM引导至外部的Flash，这个外部的Flash的数据就称作固件。一个SoC类型的设备，通常使用SPI NOR Flash、NAND Flash、EMMC。SPI Flash一般存放Bootloader，NAND Flash存放系统内核，固件等。对于后者，一般需要提取文件系统；对于前者，需要研究启动过程。一般SPI Flash的固件会由多个部分组成，不能直接把固件的Dump丢入IDA Pro。而MCU固件不会分成很多个区域，一般来说就是一个到两个。对于只使用内置存储的MCU，只要Loader+Application；对于使用了外置存储的MCU，内置Loader+Application，外部的Flash就不会再分成多个部分了。

提取固件

对于NAND Flash或者其他冷门存储，需要在提取固件环节耗费很多精力，另外某些冷门MCU的固件也很难提取。

寻找加载基址的总结

一般逆向固件，首先要做的是找到加载基址，因为当基址还原，字符串，jpt等交叉引用ida都会自动修复。

（这里很乱，以前自己写的，看不懂就忽略吧）

加载基址有多种方法获取：

芯片数据手册，根据芯片手册的内存布局和启动模式信息，找到内存基址
寻找该芯片公开的代码，比如Bootloader，再找到加载基址。
逆向上一级Loader，找到加载下一级的基址。例如U-Boot会携带基址信息
外部中断向量表（IVT），一般是绝对地址，再稍微猜测一下
如果没有中断向量，就找可见字符串引用绝对地址
找到所有字符串，再找所有存在引用的地方，逐个匹配，存在交叉引用最多的就是正确基址。
如果有调试权限，打印内存，寻找固件头部对应的地址
首先考虑地址为整数的情况。比如0x????0000，对比函数引用的地址，与字符串分布的地址，找到低地址相同的，相减就是目前基址与有效基址的偏移。
IDA：如果16进制地址偏移的后四位与某个DCD值的后四位相等，那么这个DCD值的高位地址值就是基址高位地址，低位地址保留不变。

分析布局

首先使用hexdump看数据分布，再binwalk识别CPU指令集、opcode分布。如果看不出来，再用HEX编辑器，寻找字节占比。如果是压缩数据，比如Lempel-Ziv-Welch压缩，就很多9D，根据9D之后组成的数据，看是否符合LZW算法。https://en.wikipedia.org/wiki/List_of_file_signatures

搜索0123456789abcdefg这样的连续字符，分析大小端。有些打印机是双Flash，可能一个是1267另一个是3489。需要按最小字节块交叉拼接。

如果存在源码，根据源码的Magic，到固件里搜索，就能得到布局。

控制变量法，对比不同版本的固件，对比相同版本不同内容的固件。

如果只有一个固件，那么分析每个块的相似度，可以找出magic number，从而确定系统类型

避免重复文件

这里要用到我做的固件安全产品：UFA - 通用固件分析系统。

PS：这个功能是我在2020年底写的。

某些固件里面会有冗余系统，使用UFA，或者其他分析熵图的工具，可以快速找到重复的区域，避免增加额外工作。

连续文件 & 部份压缩文件

部份压缩系统最坑人，平时从固件中提取的二进制文件，一般就直接去逆向分析代码了，这个可以看到一些字符串和符号，但是放到IDA里无法正常识别，于是查看熵图可以发现，部份区域是代码，部份是压缩文件，还有一些SHA512常数。

但是正常压缩文件的熵都是比较平滑并且趋近1的。并且一个系统固件，多段相隔较远的地址，出现大部份字符串变量是反常的。根据它的上一级loader推断出，这是一个连续文件，并且部份压缩。

当部份加密和压缩结合

当部份加密和部份压缩结合，就会把人搞晕。

IoT设备性能较弱，为了平衡安全和使用体验，会使用部份加密。这是某设备的squashfs文件，直接解包会报错，如果经验不足可能会觉得是文件损坏。稍为有经验一点的会找到解谜代码，并且对文件解密，这种情况还是会解包失败。squashfs是会压缩的，所以较难看出是不是部份加密。

实际上部份加密和完全加密是有一定区别的。

压缩文件的熵，是会存在一定幅度的波动，这一区域就是部份加密的漏网之鱼。

而完全加密随机性更高，就是平滑的一条线。

识别函数

有时基址不正确，IDA可能也不能准确识别出code区域，函数入口，就更别说去分析基址了。这种情况下可以先尝试还原一部分函数。

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)))

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)

恢复常用函数

对于私有的MCU固件不使用外部链接库，因此大部分基础功能都在代码里实现，需要先找出使用频繁的函数：

memcpy memset memcmp mmap printf strcpy kfree

对于基于开源项目开发的固件，可以参考源码特征识别出基本的函数

根据这些函数可以进一步推导出逻辑。

查找引用最多的函数脚本

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)

对于开源的MCU固件，一般自己先编译一个固件，要保证工具链、版本号一致。链接时生成符号信息，在使用FILRT生成符号和指纹，在固件里匹配，就能还原出大部分函数。

寻找带字符串的函数

对于基址没有和0x1000对齐的固件，难以肉眼猜出基址。但是我还有办法，首先察看字符串全局变量，看左侧的地址，记住这些地址序列

在x86平台，静态变量入参会用push，push搜索起来也要比mov这种更佳方便。在IDA全局搜索 push 0x，然后再筛选0x62，0x97结尾的内容。如下图所示，这些连续规律和上图地址序列一致，一眼丁真。

基址计算： 0xFEFA5762 - 0x22F62 = 0xFEF82800

修复函数交叉引用

有的函数找不到调用源，可能是放在一个jumptable内，可以全局搜索立即数，搜索的值为该函数的地址。有的时候地址是相对偏移地址，要减去基址。

有的时候一个32位地址是由高16位和低16位组成，特征如下

MOV Rx, #HighAddr
MOVT Rx, #LowAddr

冷门架构

IDA Pro作为反汇编工具，能够正确把机器码反编译成汇编语言，并且能够生成函数调用图，已经很好了。对于V850这种架构，需要先手动识别出每个函数入口，另外大部分交叉引用还不能正确识别，也需要手工生成。

另外是芯片特定的寄存器偏移、外围地址分布。包括RAM、外围设备总线，外围接口寄存器，中断寄存器等。一般在芯片数据手册里面找，如果手册未公开，就到BSP、Scatter里找。再在IDA Pro的CFG里新增特定平台的配置，包括地址分布，寄存器描述。

对比源码逆向

如果看不懂代码到底什么意思，就找一个相似功能的工程，编译成同一平台的固件，放入IDA Pro逆向分析，对比源码，大概能知道是什么意思。

模拟执行

如果遇到很复杂的代码，却只要得到结果，就能使用Unicorn Engine模拟执行，但是只支持ARM、MIPS、PPC等常见架构。

逆向特定功能

加解密库会有很多常量数据，通过搜索这些数据，可以确定使用了哪些加解密算法，可以反推到关键代码。加密、哈希、冗余校验函数，一般这类函数都会有专门的常数数组，特征很明显，通常在启动、升级、通信阶段用到。

使用FindCrypt插件，可以快速发现这些函数。

比如SD、SATA协议的CMD，全局搜索立即数

CAN总线，搜索CAN寄存器地址

IDA pro problems 技巧

在 IDA pro 点击 view > Open subviews > Problems，找到下列类型的问题

NONAME
BOUNDS

这些问题一般都会携带一个立即数，代表对应的地址不在预设的段地址范围内。这类立即数一般可能是寄存器地址，也可能是使用了正确基址的地址。

还有一种可能能是外部二进制文件的地址（一般Bootloader比较多，比如固件A的基址无法确定，但是函数入口还原了，固件B有一些错误地址，如果调用的高位地址和固件A匹配，那么基本可以确定固件A的基址）。

Case

某x86固件，基址不确定。首先搜索Problem，筛选BOUNDS，可以看到一堆Call，意思是函数调用，但是这里使用的是near ptr，也就是相对地址，因此这里的7A10Ah，是当前基址加上偏移的地址。

但是，这个文件大小也没有超过0x40000，所以7A10A是个无效地址。随便点一个地址进去，可以发现，0xFEF84DE0是0x7A10A函数的参数，所以这个0xFEF84DE0不可能是寄存器，极大可能是全局变量。

根据寻找带字符串的函数这里的技巧，可以确定基址是0xFEF82800，当修改好基址，IDA会自动识别出更多有效函数。而且前面提到的0x7A10A会变成0xFEFFC90A，可这还是一个无效地址。因为这个地址是指向外部的二进制地址，另一个二进制文件的printf函数地址就是0xFEFFC90A，因此要添加外部二进制文件。

这里一定要注意，接下来的操作过程，非常容易出错。因为操作提示不太人性化，几天不用就会忘记，填错了容易毁了当前的工程文件。Shift+F7进入Segment页面，创建一个新的段，

段名随便填，开始地址是外部二进制文件基址

添加完检查下是否和其他段冲突

添加外部二进制文件，File -> Load file -> Additional binary file…

这里的offset填写为IBB段的基址。

JVMTI加密保护绕过

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

研究过程

最近研究某汽车，遇到一个Win下的软件，用于连接经销商内网。

安装完成，目录有jar文件又有exe文件。

执行start.exe之后可以看到启动了两个Java进程

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

猜测第二个进程可能是内置浏览器，第一个进程是关键进程

使用jdgui打开，发现部分类显示Internel Error，并且关键类没有显示。使用其他java反编译工具也一样。

简单逆向start.exe文件，发现只是用作ClassLoader，可能用于在线更新。

在启动参数看到了agentlib指向jvmprotect，使用IDA Pro打开jvmprotect，发现使用了JVMTI作为agent，猜测可能作为解密模块。

JVMTI支持包括但不限于取证，调试，监控，线程分析，覆盖率分析等工具。

简单查阅JVMTI文档，得知如下三个主要方法，可以作为逆向切入点

Agent_OnLoad 启动时调用
Agent_OnAttach 附加时调用
Agent_OnUnload 卸载时调用

使用IDA Pro打开这个agent。得知Agent_OnLoad是启动函数，由于代码基于JNI和JVMTI，打开阅读不太方便。我整合了一个jvmti_all.h头文件，方便逆向。（由于这个回调函数太简单，并且没有用到其他功能，所以没有派上什么用场）。

启动时设置SetEventCallbacks，此时会把jar包的class文件逐个传入这个回调函数。然后把每个类解密，并且输出日志。

我很懒，不想还原算法，打算用frida或者unicorn engine去解密。

阅读完这篇文章 Yilun Fan - 谈谈Java Intrumentation和相关应用，发现Instrumentation API基于JVMTI，因此可以使用Java Agent来导出class文件

参考等你归去来 - 如何获取java运行时动态生成的class文件？，我打包了名为ClazzDumpAgent.jar的Agent。d参数代表dump路径，-f参数是匹配提取的前缀，-r文件代表包名。

agentlib和javaagent存在先后顺序，一定要先解密完再导出。

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

执行这段脚本，可以看到解密完每个class之后，都会导出这个class。

随后将路径打包成zip文件，用 Java 反编译软件打开，相比较第一张图，可以看到之前显示为null的class已经出现率，但是有些显示Internal Error的类没有出现。这是因为没有执行的class不会被解密，这时候主动触发这个功能，在命令行可以看到相关的类被实时解密。

建议用CFR去反编译，报错更少。

cfrd -jar ./decypted.zip ./out

彩蛋

参考

JDPA

JVMTI Documentation

谈谈Java Intrumentation和相关应用

等你归去来如何获取java运行时动态生成的class文件

Yilun Fan - 谈谈Java Intrumentation和相关应用

JVMTI.h and ClazzDumpAgent

固件提取系列 UBI文件系统提取以及重打包

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

前言

去年写的，不小心把github仓库弄成私有，Readme没了，重新传了个Readme，觉得有点不好意思。先把这篇文章放出来吧

UBI(Unsorted Block Images)全称未分类块镜像。由IBM公司设计，是一个基于Raw Flash设备的卷管理系统，可以在单个物理设备上管理多个逻辑卷，并且支持耗损均衡(wear-leveling)。广泛应用于嵌入式设备。

提到Raw Flash，就要解释一下什么是MTD(Memory Technology Device)。MTD是用于访问Memory设备(尤其是Flash设备)的一个Linux子系统，作为硬件和文件系统之间的抽象层。以NAND Flash为例，MTD对NAND flash封装，为上层文件系统驱动提供抽象接口。MTD设备由擦除块(Eraseblocks)组成，MTD驱动提供了读写和擦除三种操作，但是在修改每个块之前都要先擦除。

UBI结构

UBI有点像LVM(Logical Volume Management)，LVM提供逻辑扇区到物理扇区的映射，而UBI提供逻辑擦除块(LEB)到物理擦除块(PEB)的映射。从上述可知，UBI是以块为单位操作的。

在每个UBI块（非坏块）的头部，有两个长度为64字节的头信息。

EC header(erase counter header)，包含了每个PEB的信息(VID的偏移，数据的偏移)。
VID Header(volume identifier header)，包含了卷ID和LEB对应PEB的编号。

在Linux源码/linux/drivers/mtd/ubi目录，ubi-media.h内，有EC header和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;

ID为UBI_INTERNAL_VOL_START的卷，专门用来存放分卷表的记录。

#define UBI_INTERNAL_VOL_START (0x7FFFFFFF - 4096)

其中包含卷名

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;

一个MTD设备前面的部分一般用于存放Bootloader，后面用于UBI。下图只是一个简单的举例，实际情况可能是多个UBI和其他分区间接排列。UBI使用fastmap将LEB到映射到乱序的PEB，为UBIFS提供抽象接口。

挂载UBIFS

MTD为提供了直接操作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.

上面的工具只能操作UBI，而一般电脑上没有MTD设备。当从嵌入式设备提取了原始的Flash固件，想要在电脑上读取，可以使用来模拟一个MTD设备。一般情况下，会使用到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;

首先看NANDSim的参数，一大堆参数该如何配置呢？

$ 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)

可以去阅读内核驱动源码来了解NANDSim的实现，这里简单说明一下。首先由nandsim.c 调用nand_base.c中的nand_scan_ident，在nand_detect中会进行Read ID操作，nand_readid_op对NAND发送0x90,0x00。随后在nand_get_manufacturer，匹配厂商ID，最后在nand_scan_tail中初始化NAND芯片，设置各项属性。

NANDFlash的芯片手册会表明ID的具体参数

所以我们需要将ID设定正确，驱动会根据ID自动设置容量，页大小等数据。在NANDSim的参数只需要前四项。

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,
};

如果需要调整模拟NAND的参数，可以根据芯片手册上的数据表来选择。

一般情况下，嵌入式设备的bootloader等其他分区都会和系统分区放在同一个芯片内。因此需要对NANDSim分区，该芯片的eraseblocks以128KB为单位，也就是0x20000。

写一个脚本来寻找UBI的分布

#!/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，该芯片有4K个块。

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

加载MTD模块和NANDSim模块

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

查看MTD设备的信息，可以看到分区已经创建成功。

$ 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

通过dmesg可以看到加载的具体信息，包括芯片信息和分区信息。

$ 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"

也可以通过下面的命令查看MTD分区表

$ 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是整个MTD设备，将提取出的固件写入MTD设备，因为是在内存中模拟，所以速度很快。

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

查看ubi模块信息，会发现有mtd参数，实际上使用此参数会出错，因为默认的VID Header长度为512。

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

因此需要先挂载UBI模块，然后使用MTD-Utils的UBI Attach指定相关参数。

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

接下来可以看到挂载成功的信息

[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

随后指定文件系统UBIFS进行挂载，可以成功读取到文件系统里的内容。

$ 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

有时候在UBI之上会使用SquashFS，因此常规的挂载方法会失效

[  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

这里的hsqs是SquashFS的Magic，因此只需要将UBI用squashfs挂载即可

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

卸载操作如下

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

使用UBI Reader进行读取

下载或使用PIP安装，https://github.com/jrspruitt/ubi_reader

sudo pip install ubi_reader

先看是否准确识别UBI信息

ubireader_display_info [options] path/to/file

完全提取文件，但是遇到其他文件系统就会失败。

ubireader_extract_files [options] path/to/file

所以建议先还原PEB到LEB，然后再对其各个卷进行分析。

ubireader_extract_images [options] path/to/file

UBI重打包

挂载UBIFS之后，有可能需要修改文件重打包，使用dd命令不可行。

首先记住ubiattach命令后的回显，会打印出LEB信息

$ 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)

总共240个LEB，每个LEB占用12696字节，在mkfs里把ubifs的参数填入，打包成UBIFS。

# 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

新建ubi_config.ini文件

vi ubi_config.ini

vol_size一定要和image的尺寸对应，最后一行为空，否则报错 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

最后用ubinize生成UBI文件

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

-e 是擦除块的数量，默认是0，可以用binwalk快速查看 -Q 是映像的顺序号，可用ubi_display_info查看 -x 是UBI的版本，默认是1 -s 是子页大小，不是所有的NAND都有子页，一般来说SLC颗粒的2048字节的NAND页是由4个512字节的子页组成，MLC没有子页 -m 是页大小 -p 是物理块大小，一个物理块一般有64页，参考NAND Flash手册

下面是给mtd7烧写rootfs.ubi

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

如果是SquashFS的文件系统，那么不需要构建ubifs，在修改完系统内容后，直接用mksquashfs打包SquashFS，一定要用相应的权限打包，如果目标系统是root，那么就在root下打包。后续操作就是用ubinize打包成UBI。

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

Reference

Memory Technology Devices

UBI - Unsorted Block Images

挂载和反向制作 ubi 镜像

固件提取系列固件载体

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

固件载体

固件 (Firmware), 在港澳台称作韧体, 在手机领域又称作字库。它位于非易失性存储(Non-Volatile Memory，NVM)中，可以被读写。在嵌入式领域，最常见的NVM类型是ROM(read-only memory)和Flash Memory，其中ROM包括Mask ROM、PROM、EPROM、EEPROM；现在主流的ROM就是EEPROM，一般是在MCU内部；而更加主流的外存一般都是Flash Memory。

在嵌入式设备中，除了使用最基本的NAND或者NOR Flash芯片，还可能会使用eMMC；扩展存储会用到SD卡，CF卡，HDD等；这些都是有一个主控再加一个存储区，主控和上位机通信，只要能访问主控，就能读写存储芯片的内容。对于eMMC、SD卡、CF卡、HDD之类的设备，它的主控对外有通用的接口，只要用读卡器或者烧录座就可以读取。但是对于SoC直接管理的存储芯片，并没有对外部的通用接口，但是主控都是驱动控制的，所以只要能访问内存（外围设备的地址）就行了，因此有一些JTAG读固件、IAP读取固件、U-Boot读取固件的技巧，是而且理论上主控坏了，我们还能从存储区读取出固件。

只要是这些设备存放了操作系统，我把这原始的文件都称作固件。在嵌入式安全研究中，固件提取总是最初的工作，也是最重要的工作，决定了研究是否能继续下去。因此我决定整理这几年关于固件提取的知识分享出来。

EEPROM vs NOR vs NAND-Flash

由于EEPROM产品比Flash产品在擦写次数上有着更大的优势，再加上更小的尺寸和较低的擦写电流，因此成为车载应用中首选的存储技术。

但是对于性能较高的设备，就要用到Flash。NAND对比NOR，支持XIP，而且读取速度很快，但是写入和擦除速度很慢。NAND 的容量要大很多，速度快，价格也相对便宜，但是可靠性较低。 NAND以块为单位来访问数据，而NOR Flash可以随机访问数据。

要与固件载体通信，修改里面的数据，就要有相应的协议。对于EEPROM，协议主要有I2C, SPI，其中SPI有多种模式。而NAND Flash使用的是Raw NAND协议，现在几乎都遵循ONFI标准。对于NOR Flash一般有SPI协议；SPI的Flash一般遵循JEDEC SFDP(JESD216)标准，而Parallel NOR支持JEDEC CFI(JESD68)标准。

JEDEC：全称是Joint Electron Device Engineering Council 即电子元件工业联合会。JEDEC是由生产厂商们制定的国际性协议，JEDEC用来帮助程序读取Flash的制造商ID和设备ID，以确定Flash的大小和算法。

注意：不一定所有芯片都遵循这些标准。

NOR Package

NOR Flash 有并行和串行两种，串行一般是SOP封装，使用SPI协议。并行只有极少数BGA封装，一般是TSOP封装，TSOP-56, TFBGA-56, LFBGA-64。

NOR Flash Pin Assignment

NOR Flash支持随机访问，因此擦除单位是Byte。这里指的是并行信号引脚，NOR的信号线和SRAM基本上是一样的。如果飞线会特别麻烦。

Symbol	Pin Name	Functions
A[MAX:0]	Address	读写操作发送的地址数据
DQ[7:0]	Data Inputs/Outputs	用于输入输出命令和数据。
DQ[14:8]	Data Inputs/Outputs	用于输入输出命令和数据。
DQ15/A-1	Data Inputs/Outputs	数据或地址输入
BYTE#	Byte/word organization select	选择8位或者16位
CE#	Chip Enable	芯片使能
RE#	Read Enable	读使能，数据在RE#脉冲的下降沿生效。
OE#	Output Enable	输出使能，当OE#是LOW时，读取周期会输出数据。当OE#是HIGH时，数据输出将处于高阻状态
WE#	Write Enable	写使能
WP#	Write Protect	提供意外情况的读、擦除保护，当WP#是低电平时，其他操作将无法进行。
RST#	Reset
RY/BY#	Read / Busy Output	如果处于编程、擦除或随机写入操作，R/B#信号将变低，当操作完成时会变回高电平。如果芯片未被选中或输出被禁用时，该信号是漏极开路并处于高阻状态，需要采用上拉电阻。
Vcc	Power	3.3V或1.8V常电
Vss	Ground	接地
NC	No Connection	无连接

TSOP-56

NAND Flash

NAND Flash属于非易失性存储器，对于嵌入式设备，一般使用SLC，单位是1-bit，是一种浮栅结构，可以捕获电子并且外部绝缘，断电之后可以保留数据。Flash都不支持覆盖，即写入操作只能在空或已擦除的单元内进行。

擦除方法是在源极加正电压利用第一级浮空栅与漏极之间的隧道效应，将注入到浮空栅的负电荷吸引到源极。由于利用源极加正电压擦除，因此各单元的源极联在一起，这样，擦除不能按字节擦除，而是全片或者分块擦除。

NAND Package

ONFI标准定义了一些常用的NAND封装，NAND Flash一般是TSOP和BGA的封装，都使用SMT的贴装方式。下图是不同封装的引脚定义。

TSOP-48

BGA-63

NAND Flash Pin Assignment

NAND Flash并行输入输出，一般是8位I/O，也就是x8。图中具有上划线的引脚(在这里使用"#“号表示)，是低电平有效，该引脚默认应该是上拉的状态。

Symbol	Pin Name	Functions
I/O x	Data Inputs/Outputs	用于输入输出命令、地址和数据。如果芯片未被选中或输出被禁用时，I/O口将处于高阻状态。
CLE	Command Latch Enable	指令锁存使能，当CLE为高时，在WE#脉冲的上升沿，指令被锁存到NAND指令寄存器中
ALE	Address Latch Enable	地址锁存使能，当ALE为高时，在WE#脉冲的上升沿，地址被锁存到NAND地址寄存器中。
CE#	Chip Enable	芯片使能，如果没有检测到CE信号，那么，NAND器件就保持待机模式，不对任何控制信号作出响应。
RE#	Read Enable	读使能，数据在RE#脉冲的下降沿生效。
WE#	Write Enable	写使能，WE#负责将数据、地址或指令写入NAND之中。这些操作将在WE#脉冲上升沿生效。
WP#	Write Protect	提供意外情况的读、擦除保护，当WP#是低电平时，其他操作将无法进行。
R/B#	Read / Busy Output	如果NAND处于编程、擦除或随机写入操作，R/B#信号将变低，当操作完成时会变回高电平。如果芯片未被选中或输出被禁用时，该信号是漏极开路并处于高阻状态，需要采用上拉电阻。
Vcc	Power	3.3V或1.8V常电
Vss	Ground	接地
NC	No Connection	无连接

Array Organization

ESMT厂商的某款8位NAND的阵列组织如下，一页有2048存储+64Cache字节，一个块含有64个页，该NAND Flash有1024个块，加上Cache就是1056M-bit。也就是128MB容量+4MB的缓存。

固件读取的工具

这里说的是非扩展存储。固件提取按照读取方式，分为下列几种：脱机读取(Chip-Off)，在线读取，内部备份。

内部备份，指拿到了设备权限，从块设备备份数据，或者从I2C、SPI驱动接口读取数据。

在线读取，指在设备上外接工具、使用设备主芯片特有的调试接口，或者是存储芯片的通用接口读取数据。一般准备USB线束，或者使用JLink，USBDM之类的调试工具（也有很多冷门芯片需要特殊调试工具），属于IAP方式提取固件。

脱机读取，把目标存储芯片拆下，使用烧录座和编程器读取。该方式读取成本较高，而且编程器和与芯片相配的主控不一定兼容，因此还要手动修复固件。

在了解了芯片的标准和通信协议后，对于一些冷门的存储芯片，其实可以不依赖编程器。使用STM32、AVR或者树莓派都能完成固件提取工作。

嵌入式设备的应用

NOR Flash和普通的内存比较像的一点是他们都可以支持随机访问，这使它也具有支持片内执行(XIP, eXecute In Place)的特性，可以像普通ROM一样执行程序。这点让它成为BIOS等开机就要执行的代码的绝佳载体。

与NOR Flash不同的是，NAND不支持XIP，因此不能存放最开始的Bootloader。

最早的手机等设备之中既有NOR Flash也有NAND Flash。NOR Flash很小，因为支持XIP，所以负责初始化系统并提供NAND Flash的驱动，类似Bootloader。而NAND Flash则存储数据和OS镜像。三星最早提出NOR less的概念，在它的CPU on die ROM中固化了NAND Flash的驱动，会把NAND flash的开始一小段拷贝到内存低端作为bootloader,这样昂贵的NOR Flash就被节省下来了，降低了手机主板成本和复杂度。渐渐NOR Flash在手机中慢慢消失了。

NAND Flash相对NOR Flash更可能发生比特翻转，就必须采用错误探测/错误更正(EDC/ECC)算法，同时NAND Flash随着使用会渐渐产生坏块；通常需要有一个特殊的软件层，实现坏块管理、擦写均衡、ECC、垃圾回收等的功能，这一个软件层称为 FTL（Flash Translation Layer）。根据 FTL 所在的位置的不同，可以把 Flash Memory 分为 Raw Flash 和 Managed Flash 两类：

最早大家都是使用Raw Flash，FTL全由驱动程序实现。后来发展到SD和eMMC等，则由硬主控实现。

因此要读取原始NAND，还要考虑坏块管理，擦写平衡，ECC等功能。

其中ECC是最难的地方，因为从编程器读取NAND很大可能会出现错误，需要纠错。大部分NAND Flash使用了硬件ECC，算法由硬件决定，对于SLC颗粒，一般使用hanming，BCH之类的算法，这些实现在网上都没有标准的源码，因此需要特殊途径搞到ECC算法。

根据存储芯片应用特性，可以推断出它的用途是存放Bootloader，是系统，还是临时数据。根据芯片支持的规范，可以读取其中的内容。后续会分享一系列进阶的固件提取知识。

Reference

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