1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

你的任务是在 IDA Pro 中分析打开程序。
你可以使用 MCP 工具（如 ida-pro-mcp）来获取反编译、反汇编和程序结构信息。

请严格按照以下逆向分析策略执行：

1. 首先检查 IDA 的反编译结果（F5 输出），结合语义理解代码逻辑，并在关键位置添加注释。
2. 将无意义的变量名（如 v1、v3、a1 等）重命名为具有实际语义的名称。
3. 如有必要，修改变量和函数参数的类型，尤其是指针、数组和结构体类型，以提高代码可读性。
4. 将函数重命名为能够准确描述其行为的名称（例如校验函数、解密函数、初始化函数等）。
5. 当反编译信息不足或存在歧义时，请查看对应的反汇编代码，并基于汇编指令补充注释和分析结论。
6. 绝对不要自行进行任何数字进制转换（例如十六进制转十进制），如有需要，必须使用 int_convert MCP 工具。
7. 禁止尝试任何形式的暴力破解，所有结论必须通过反汇编逻辑分析和必要的简单 Python 推导脚本得出。
8. 分析过程中请始终关注：
   - 输入数据的来源与长度
   - 校验逻辑与失败分支
   - 字符串处理、循环结构、状态机或加密/混淆逻辑
9. 在分析完成后，请生成一个 report.md 文件，内容包括：
   - 程序整体结构概览
   - 关键函数说明（含重命名理由）
   - 校验/解密流程的完整逻辑说明
   - 得出最终结论的推导过程
10. 请不要随意生成文档，如果文档有更新，尽可能在原文档更新。代码也不要随意生成不同的文件。

请以“逆向工程师”的视角进行分析，避免臆测、过度抽象或脱离汇编语义的解释。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

frida17.5版本API说明
Memory read/write APIs
Back in the day, you’d access memory like this:

const playerHealthLocation = ptr('0x1234');
const playerHealth = Memory.readU32(playerHealthLocation);
Memory.writeU32(playerHealthLocation, 100);
The modern equivalent is:

const playerHealthLocation = ptr('0x1234');
const playerHealth = playerHealthLocation.readU32();
playerHealthLocation.writeU32(100);
Where each write-counterpart returns the NativePointer itself, to support chaining:

const playerData = ptr('0x1234');
playerData
    .add(4).writeU32(13)
    .add(4).writeU16(37)
    .add(2).writeU16(42)
    ;
The legacy versions of these are now also gone, and have been gone from our TypeScript bindings for as long as the legacy-style enumeration APIs. So this change should also not be noticable to most of you.

Static Module APIs
Now for the breaking changes that also affect users who were current with the TypeScript bindings, prior to 19.0.0, released together with Frida 17. The following static Module methods are now gone:

Module.ensureInitialized()
Module.findBaseAddress()
Module.getBaseAddress()
Module.findExportByName()
Module.getExportByName()
Module.findSymbolByName()
Module.getSymbolByName()
These are all straight-forward to migrate away from.

But first, let’s cover the odd one out:

Module.getSymbolByName(null, 'open')
This is now accomplished like this:

Module.getGlobalExportByName('open')
For the rest, you first need to look up the Module, and then access the desired property or method on it. For example, instead of:

Module.getExportByName('libc.so', 'open')
The new way is:

Process.getModuleByName('libc.so').getExportByName('open')
The equivalent for Module.getBaseAddress() is thus:

Process.getModuleByName('libc.so').base
This means there is now only one way to do Module introspection, and the API design is such that we encourage you to write performant code. For example, in the past you might have been tempted to do:

const openImpl = Process.getExportByName('libc.so', 'open');
const readImpl = Process.getExportByName('libc.so', 'read');
But now you’ll probably think twice before doing:

const openImpl = Process.getModuleByName('libc.so').getExportByName('open');
const readImpl = Process.getModuleByName('libc.so').getExportByName('read');
And instead do:

const libc = Process.getModuleByName('libc.so');
const openImpl = libc.getExportByName('open');
const readImpl = libc.getExportByName('read');
Which is both more readable and more performant.