Aggregator

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

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

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

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

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

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

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

Logic of the state-check stub:

1. Update clock
2. Timer check
3. Action handling
4. Music handling
5. Audio handling
6. Key status and control input
7. Bookkeeping
8. Coin handling
9. PLX PCI status handling
10. SDL event handling
11. Draw dynamic pentagon animation
12. PCI control write
13. ASIC 27 command write
14. PCI data read
15. Graphics refresh

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

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

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

Game BIOS table:

Kernel BIOS table:

The comparison logic is also very simple:

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

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

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

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

• Input mask: 0x1FB8408E
• Return mask: 0xC2E83AB8

ROIO has three magic numbers:

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

Finally, XOR with 0xC2E83AB8.

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

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

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

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

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

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

Request 1 list, length 17:

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

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

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

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

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

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

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

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

From analysis, the modes are:

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

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

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

Other values trigger an assert.

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

System Mode handling:

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

Other values trigger an assert.

The maximum length of the buffer is 8192.

The response header format:

The request header format:

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

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

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

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

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

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

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

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

I asked an AI to write a Python implementation.

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

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

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

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

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

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

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

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

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

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

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

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

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

IGS Logo:

Teammark:

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

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

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

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

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

Commemorating the Blood Moon. Praise the Lady.

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

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

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

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

1. Kernel mount_root 时，以及游戏程序启动时 会校验 BIOS 版本信息，开发者却说是获取CRC结果，结果我愣是找遍了所有CRC的位置，也没找到任何反盗版有关的CRC计算逻辑；
2. BIOS 信息校验失败就校验PCI的驱动信息，如果失败，好像也没有任何操作，但其他地方也插入了许多一样的校验桩，校验失败就会阻止运行；
3. 系统初始化：屏幕、音频、图形、文字、语言、ASIC、Timer、PLXPCI、游戏、音乐、控制器、摄像机、台账、控制、投币、混合器等等；
4. 刷新4次ASIC，why???；
5. 加载基础 action 文件（TSGROM格式），每次加载都刷新一次ASIC；
6. 游戏版本校验，显示第一屏，加载字体，加载声音；
7. 加载读卡器；
8. 游戏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 开发单页面应用一样。

状态检查桩的逻辑

1. 更新时钟
2. 计时器检查
3. Action处理
4. 音乐处理
5. 音频处理
6. 按键状态以及控制输入
7. 台账
8. 游戏币处理
9. PLX PCI 状态处理
10. SDL 事件处理
11. 绘制动态五边形动画
12. PCI 控制写入
13. ASIC 27 命令写入
14. PCI 数据读取
15. 图形刷新

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

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

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

Game BIOS table

Kernel BIOS table

对比的逻辑也很简单，

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

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

经过统计，地址和版本字符串如下，所有地址都是0x0f0000起始。

接下来分析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 对于虚拟地址偏移的设定如下

通过IOMEM的map，也可以看到BIOS信息的地址位于 System ROM

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

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

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

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

request 1 列表，长度17

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

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

游戏主程序与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用于更新游戏配置，将会更新以下目录

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

经过分析，以下模式

• 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: 调整音量

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

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

其他值则触发 Assert

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

System Mode 对应的处理

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

其他值则触发 Assert

Buffer 的最大长度是 8192

Buffer 响应的 Header 格式如下

Buffer 请求的 Header 格式如下

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

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

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

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

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

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

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统一刷新画面。

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

IGS Logo

Teammark

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

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

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

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

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

纪念血月，赞美女神

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

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

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

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

1. Kernel mount_root 时，以及游戏程序启动时 会校验 BIOS 版本信息，开发者却说是获取CRC结果，结果我愣是找遍了所有CRC的位置，也没找到任何反盗版有关的CRC计算逻辑；
2. BIOS 信息校验失败就校验PCI的驱动信息，如果失败，好像也没有任何操作，但其他地方也插入了许多一样的校验桩，校验失败就会阻止运行；
3. 系统初始化：屏幕、音频、图形、文字、语言、ASIC、Timer、PLXPCI、游戏、音乐、控制器、摄像机、台账、控制、投币、混合器等等；
4. 刷新4次ASIC，why???；
5. 加载基础 action 文件（TSGROM格式），每次加载都刷新一次ASIC；
6. 游戏版本校验，显示第一屏，加载字体，加载声音；
7. 加载读卡器；
8. 游戏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 交互的位置，都插了代码桩，用来实现各种复杂的控制功能，也附带了一些反盗版功能。不得不吐槽，这个代码质量真糟糕，每次都要做大量的计算，性能很差。

状态检查桩的逻辑

1. 更新时钟
2. 计时器检查
3. Action处理
4. 音乐处理
5. 音频处理
6. 按键状态以及控制输入
7. 台账
8. 游戏币处理
9. PLX PCI 状态处理
10. SDL 事件处理
11. 绘制动态五边形动画
12. PCI 控制写入
13. ASIC 27 命令写入
14. PCI 数据读取
15. 图形刷新

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

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

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

Game BIOS table

Kernel BIOS table

对比的逻辑也很简单，

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

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

经过统计，地址和版本字符串如下，所有地址都是0x0f0000起始。

接下来分析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 对于虚拟地址偏移的设定如下

通过IOMEM的map，也可以看到BIOS信息的地址位于 System ROM

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

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

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

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

request 1 列表，长度17

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

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

游戏主程序与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用于更新游戏配置，将会更新以下目录

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

经过分析，以下模式

• 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: 调整音量

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

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

其他值则触发 Assert

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

System Mode 对应的处理

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

其他值则触发 Assert

Buffer 的最大长度是 8192

Buffer 响应的 Header 格式如下

Buffer 请求的 Header 格式如下

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

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

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

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

TSGROM存放了游戏的多媒体资源，有脚本、音频、2D动画。

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

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

IGS 的 TSGROM 定义了游戏的各种图形行为，并称之为 action，主程序通过解析 action 来实现功能。如果是要重写一个ASIC27软件，那么需要逆向分析 action parser，但是我想尝试最完美的破解方式，dump ASIC ROM 放到模拟器运行。不想分析这种屎山代码。

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

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

IGS Logo

Teammark

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

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

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

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

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

纪念血月，赞美女神

You must login to view this content

You must login to view this content