1. 项目概述：这不是“逆向技能”，而是一套可落地的系统性能力重构方法论

“reverse-skill”这个词乍看像技术黑话，但在我带过27个安全团队、审过400+份红队报告、亲手拆解过132个商用IoT固件和89个闭源SaaS前端之后，我越来越确信：它根本不是某个具体工具或命令的代号，而是一种面向真实攻防场景的能力反向建模思维。你搜到的那些热搜词——Reverse Engineering、Penetration Testing、Security Research、AI-powered routing——它们不是并列关系，而是同一枚硬币的四个切面：当一个安全研究员在调试某款智能门锁固件时，他调用IDA Pro反汇编是Reverse Engineering；他构造异常蓝牙包触发栈溢出是Penetration Testing；他比对三年内同类芯片漏洞模式提炼出新的fuzzing策略是Security Research；而当他把这整套动作链喂给本地部署的CodeLlama-70B微调模型，让模型自动推荐下一步该hook哪个函数、该修改哪段寄存器值时，那就是AI-powered routing在起作用。这四个词串起来，才是“reverse-skill”的完整血肉。它不教你怎么敲objdump -d，而是教你在拿到一个完全陌生的二进制文件时，如何在3分钟内建立自己的分析路径图——这个图里有你熟悉的工具链、你踩过的坑、你信任的数据源，还有你愿意托付部分决策权的AI代理。适合三类人：刚考完OSCP想摆脱脚本依赖的渗透测试员、从开发转岗做应用安全的工程师、以及正在搭建企业级威胁建模流程的安全架构师。它解决的不是“会不会反编译”，而是“面对一个没文档、没源码、没调试符号的黑盒，我凭什么敢说‘我知道它怎么坏’”。

2. 核心设计逻辑：为什么必须“反向”构建技能树？

2.1 传统技能树的致命缺陷：从教材出发，而非从战场出发

我见过太多人学逆向的典型路径：先啃《加密与解密》，再刷CTF逆向题，最后去破解个Windows旧版软件练手。这套路径的问题在于——它假设所有目标都像教科书一样“规范”。但现实呢？去年我们审计某国产工业PLC固件时，发现厂商把ARM Thumb指令混着自定义RISC-V扩展指令写进同一段代码里，还用CRC16校验值动态解密关键跳转表。这时候《加密与解密》里讲的“识别字符串常量→定位main函数→分析控制流”三板斧直接失效。传统技能树是正向堆砌：先学CPU架构→再学汇编语法→再学调试器用法→最后学脱壳。但真实世界里，你永远是先看到一个崩溃日志（比如SIGSEGV at 0xdeadbeef），再倒推需要什么知识来解释它。这就是“reverse-skill”的起点：以故障现象为根节点，向上反向生长知识分支。比如看到崩溃地址，第一反应不是“我要学ARM汇编”，而是“这个地址在内存布局中属于哪一段？是.text还是.bss？如果是.bss，是不是堆溢出？那我需要立刻调出readelf -l firmware.bin看程序头，而不是翻汇编手册”。

2.2 AI-powered routing不是替代人，而是放大人的“模式识别带宽”

很多人误以为AI在逆向里就是自动写exp，这是危险的误解。我拿自己实测过的案例说话：用微调后的DeepSeek-Coder-32B分析某路由器Web管理界面JS混淆代码，模型能准确标出_0xabc123这个变量实际对应window.location.href，但它无法判断这个跳转是否构成开放重定向漏洞——因为这需要结合HTTP响应头、CSP策略、以及该页面在业务流程中的权限上下文。AI在这里的角色，是把人从“找变量映射关系”这种机械劳动里解放出来，让人专注在“这个跳转在什么条件下会被用户触发”这种需要业务理解的决策上。我们内部叫它“认知卸载”：把大脑有限的短期记忆资源，从记住17个混淆函数名，转移到思考攻击链路的业务合理性上。所以“AI-powered routing”的核心，不是让AI决定“该做什么”，而是让AI实时告诉你“此刻最可能相关的3个知识节点是什么”——比如当你在Ghidra里停在某个可疑的memcpy调用时，AI弹窗提示：“关联知识点：① 该函数第3参数来自ioctl返回值（见drivers/char/xxx.c第217行）；② 同型号设备2022年CVE-2022-XXXXX漏洞也在此处越界；③ 建议立即检查copy_from_user边界校验”。这三条提示背后，是AI在毫秒级内完成了对数万行驱动代码、数百份CVE报告、以及你本地项目注释的交叉索引。它不替你做判断，但把你需要的判断依据，精准递到眼前。

2.3 Security Research作为“反向技能”的校准器

真正的Security Research从来不是“发现新漏洞”，而是“证伪旧假设”。举个例子：某次我们分析一款医疗设备固件，按常规思路，所有网络通信都该走TLS，但抓包发现有个UDP端口在传明文JSON。团队第一反应是“这肯定是个后门”，于是疯狂逆向相关模块。折腾三天后，一位老研究员翻出设备说明书附录里的“本地维护协议”章节，发现这UDP端口是厂商预留的物理隔离网段专用通道，连设备外壳上的维修接口都标注了“仅限授权服务人员接入”。这个案例说明：逆向的终点不是代码，而是业务语境。Security Research在这里的作用，就是强制你跳出二进制世界，去查产品文档、看专利文件、甚至打电话问售后——这些动作看似“不技术”，却是防止你把精力浪费在伪目标上的关键刹车。我们在“reverse-skill”训练中，硬性规定每个逆向任务必须包含“30分钟非代码调研”：查官网更新日志、翻GitHub历史commit、搜LinkedIn上该产品首席工程师的演讲PPT。去年有个实习生靠读某厂商CTO在Black Hat Asia的演讲稿，提前两周预判出他们新固件里会引入的特定内存保护机制，直接把逆向效率提升了5倍。这才是Security Research给reverse-skill装上的真实导航仪。

3. 实操框架拆解：四层漏斗式分析法

3.1 第一层漏斗：现象锚定（Phenomenon Anchoring）

这是reverse-skill的启动开关，也是最容易被忽略的环节。很多人一拿到固件就急着binwalk，结果在无用的压缩包里耗掉半天。正确做法是：用最小成本锁定最尖锐的现象。我们团队的标准流程是“三问法”：

1. 它坏在哪里？不是泛泛说“设备连不上网”，而是精确到“Wi-Fi连接超时发生在wpa_supplicant进程发起EAPOL-Start后的第372ms，且此时/proc/net/wireless显示信号强度稳定在-42dBm”。这个描述里包含了时间戳、进程名、协议阶段、物理层参数——每一项都是后续分析的黄金线索。

2. 它什么时候坏？记录触发条件的最小完备集。比如某打印机固件崩溃，不是“打印时崩溃”，而是“当连续发送3个以上含CMYK色彩空间的PDF，且第2页包含嵌入式ICC配置文件时，在解析/usr/lib/cups/filter/pdftops子进程的第4次malloc调用后崩溃”。这里的关键是找出“3个PDF”“CMYK”“ICC文件”这三个变量的组合阈值。

3. 它和谁一起坏？观察关联现象。还是那个打印机案例，崩溃时串口同时输出[ERR] DMA channel 5 timeout，这就把问题域从PDF解析器瞬间缩小到DMA控制器驱动。我们自制了一个现象锚定速查表，放在工位显眼处：

提示：现象锚定阶段严禁打开IDA或Ghidra。所有信息必须来自运行时可观测数据，这是为了强迫大脑建立“现象→系统组件”的直觉映射，而不是依赖反编译器的视觉欺骗。

3.2 第二层漏斗：路径生成（Path Generation）

当现象锚定完成，你就拥有了一个带坐标的“故障点”。接下来要做的，不是顺着代码往下读，而是以故障点为圆心，向外辐射出所有可能的上游路径。这一步我们用“三层路径图”来实现：

• 硬件层路径：故障点对应的物理信号走向。比如崩溃地址0x80001234在ARM Cortex-A9上属于DDR内存区域，那就要查SoC手册确认该地址映射到哪个外设控制器（UART？USB？GPU？），再查该控制器的中断向量表偏移。

• 固件层路径：从故障点反向追溯调用链。这里的关键是区分“静态路径”和“动态路径”。静态路径用readelf -d firmware.elf | grep NEEDED看依赖库，再用nm -D libcrypto.so | grep EVP_Encrypt找符号；动态路径则用strace -f -e trace=memory,signal ./target_binary 2>&1 | grep -A5 "SIGSEGV"捕获真实执行流。去年分析某车载ECU时，静态分析显示所有加密都走OpenSSL，但strace却抓到大量ioctl(0x40086601)调用——查手册发现这是厂商自研的硬件加解密引擎ioctl命令，直接绕过了OpenSSL。

• AI辅助路径：把故障点特征喂给本地化模型。我们用LoRA微调的Qwen2-7B，输入格式固定为：“故障地址：0x80001234；寄存器状态：r0=0x00000000, r1=0x80001000；调用栈：kernel_init+0x123 → do_one_initcall+0x45 → xxx_driver_init+0x78；现象：DMA timeout”。模型输出不是代码，而是三个概率排序的路径建议：“① 检查xxx_driver_init中request_irq参数是否匹配硬件中断号（概率82%）；② 验证r1指向的DMA缓冲区是否在dma_alloc_coherent分配范围内（概率76%）；③ 审查do_one_initcall的错误处理分支是否遗漏disable_irq（概率63%）”。这些建议直接对应可执行的验证步骤，省去了你翻Linux内核源码猜意图的时间。

3.3 第三层漏斗：证据闭环（Evidence Closure）

路径生成后，你会得到一堆待验证的假设。这时必须建立“证据闭环”机制：每个假设必须有且仅有两种验证方式——可复现的触发条件，或可测量的物理信号。我们拒绝任何“看起来像”的主观判断。举个真实案例：某智能家居网关的固件升级失败，日志显示flash write error at 0x00100000。初步路径指向SPI Flash驱动。但验证时发现：

• 在实验室用逻辑分析仪抓SPI总线，发现WREN（写使能）指令后紧跟着PP（页编程）指令，时序完全合规；
• 用flashrom -p ch341a_spi读取Flash内容，对比升级前后，发现失败时0x00100000位置确实写入了全0xFF，但其他扇区正常；
• 关键证据来了：用万用表测Flash芯片VCC引脚，发现在PP指令执行瞬间，电压从3.3V跌到2.8V，持续12μs——这低于SPI Flash规格书要求的最小工作电压3.0V。

最终结论不是“驱动bug”，而是“电源设计缺陷”。这个闭环里，逻辑分析仪（数字信号）、flashrom（存储内容）、万用表（模拟电压）三种证据相互印证，缺一不可。我们在证据闭环阶段强制使用“三证原则”：

1. 行为证据：能用strace/tcpdump等工具捕获的系统调用或网络包；
2. 状态证据：能用cat /proc/xxx或ioremap读取的寄存器/内存值；
3. 物理证据：能用示波器/逻辑分析仪/万用表测量的真实电信号。

注意：没有物理证据支撑的“内存损坏”“竞态条件”等结论，在我们团队报告里一律标为“待验证”，直到用示波器抓到毛刺或用JTAG看到寄存器翻转。

3.4 第四层漏斗：知识沉淀（Knowledge Crystallization）

当证据闭环完成，真正的reverse-skill才刚开始。我们不做“这次修好了就完事”的交付，而是执行“知识结晶化”流程：

• 生成最小可复现PoC：不是完整的exploit，而是能100%触发现象的最简代码。比如上面的电源问题，PoC就是一段裸机代码，只做WREN→PP两步操作，其他全删。这个PoC要能在不同批次的硬件上复现，证明是设计缺陷而非偶发故障。
• 构建领域知识图谱：把本次分析中涉及的所有实体（芯片型号、寄存器地址、驱动函数、CVE编号）导入Neo4j，建立关系边。比如spi_flash_write函数节点，连向CVE-2021-XXXXX（因未校验电压）、MT29F2G08ABAEA（Flash芯片）、drivers/mtd/devices/m25p80.c（驱动文件）。半年后，当新设备出现类似flash write error，图谱能自动关联出“检查VCC稳定性”这个最高优先级动作。
• 编写对抗性测试用例：把PoC转化成自动化测试。我们用Python+PyTest写测试套件，每次固件编译后自动跑：test_voltage_sensitivity.py（模拟电压跌落）、test_spi_timing_margin.py（调整CLK相位）、test_flash_erase_stress.py（连续擦除1000次）。这些测试用例不是为了“通过”，而是为了“暴露设计边界”。

这个过程把一次性的逆向成果，变成了可积累、可检索、可演化的组织资产。去年我们用这套方法，把某系列IoT设备的平均逆向周期从23天压缩到7.2天，关键就在于知识图谱里已沉淀了142个类似电源问题的检测模式。

4. 工具链实战：从零搭建你的reverse-skill工作站

4.1 硬件层：别迷信“专业设备”，用好手边的三件套

很多新人以为reverse-skill必须买$5000的逻辑分析仪，其实我们主力设备是三样：

• Saleae Logic 8（$159）：不是因为它多强大，而是它的协议解析插件生态最成熟。我们自己写了SPI Flash电压监测插件，能自动标出WREN指令执行时的VCC波动幅度。关键技巧：把探针地线焊在Flash芯片的GND引脚焊盘上，而不是主板GND铜箔——后者会有毫欧级阻抗，掩盖真实压降。
• Bus Pirate v3.6（$35）：专用于SPI/I2C总线的“暴力探测”。当遇到没有文档的传感器时，我们用它循环发送0x00到0xFF的字节，记录哪些地址返回非0xFF响应。去年破解某安防摄像头的私有协议，就是靠Bus Pirate扫出0x3C地址返回0x01 0x02 0x03，再结合示波器看时序，反推出这是“获取设备序列号”指令。
• 自制JTAG适配器（成本<¥20）：用ESP32-WROOM-32做主控，烧录OpenOCD固件。关键创新是把ESP32的ADC引脚接到目标芯片的VDD引脚，实时监测供电电压。当GDB连接时发现target halted，我们第一反应不是查GDB日志，而是看ADC读数——如果电压低于3.1V，直接断电重启，省去90%的“连接失败”排查时间。

实操心得：所有硬件设备必须做“基准校准”。比如Logic 8，每次开机后先测一个已知稳定的3.3V电源，记录其波形作为参考模板。这样下次看到VCC跌落到2.9V时，你能立刻分辨是设备问题还是探针接触不良。

4.2 固件层：Binwalk不是万能钥匙，学会给它“喂饲料”

binwalk -e firmware.bin是新手最爱，但90%的商用固件会在这一步卡住。我们的解法是“分层剥离”：

1. 先做熵值分析：binwalk -E firmware.bin。如果整个文件熵值均匀（≈7.8），说明高度压缩或加密；如果出现明显低熵区（<4.0），大概率是未压缩的文件系统。去年分析某路由器固件，熵值图显示0x120000处有个长条状低熵区，用dd if=firmware.bin of=rootfs.img bs=1 skip=0x120000 count=1048576提取后，file rootfs.img直接识别出Squashfs filesystem。
2. 针对高熵区做密钥爆破：不用暴力穷举，而是用strings firmware.bin | grep -E "(key|pass|cipher)"找线索。某次在固件里找到default_aes_key = "H3ll0W0rld!"，用openssl enc -d -aes-128-cbc -K $(echo -n "H3ll0W0rld!" | sha256sum | cut -c1-32) -iv 0000000000000000 -in encrypted.bin -out decrypted.bin直接解密。
3. 对解密后的镜像再binwalk -e：这时才能真正展开文件系统。关键技巧：binwalk的-R参数能扫描自定义签名。我们维护一个custom_signatures文件，里面存着某厂商私有文件系统的magic bytes（如0x4D 0x41 0x47 0x49 0x43对应他们的固件头），binwalk -R custom_signatures firmware.bin就能精准定位。

4.3 软件层：Ghidra不是终点，而是起点

我们禁用Ghidra的自动分析（Auto Analysis），因为它的默认规则会把大量mov r0, #0识别为memset，误导分析方向。标准流程是：

• 第一步：关闭所有分析器，用File → Import File导入二进制，选择Raw Binary，手动设置Language: ARM:LE:32:v8、Compiler: default、Base Address: 0x80000000（根据readelf -h确认入口地址）。
• 第二步：手动标记已知函数。比如从readelf -s firmware.elf里找到printf符号地址0x80012340，就在Ghidra里右键0x80012340 → Set Function Start，再右键Function → Create Function。这样做的好处是，后续Decompiler窗口里所有调用0x80012340的地方都会显示printf("xxx")，而不是FUN_80012340("xxx")。
• 第三步：用Script Manager跑自定义脚本。我们最常用的是FindMemcpyPatterns.java，它搜索所有ldr r0, [pc, #offset]+bl memcpy模式，然后自动计算r0指向的源地址和r1指向的目标地址——这比人眼找memcpy调用快10倍。

注意：Ghidra的Decompiler对Thumb指令支持不佳。当看到BLX R0这类指令时，务必切换到Listing视图，用Ctrl+Shift+G跳转到R0寄存器赋值处，手动追踪。我们有个经验：ARM Cortex-M系列固件里，BLX R0十有八九是跳转到Flash里的函数指针表，这个表通常在.rodata段末尾，用strings firmware.bin | grep -A5 "func_ptr_table"就能定位。

4.4 AI层：本地化模型的微调与部署

我们不用API调用大模型，因为：

• 网络延迟会让Ghidra插件响应变慢；
• 敏感固件代码不能上传云端；
• 商业API的token限制无法支撑连续分析。

解决方案是量化微调+本地推理：

• 模型选型：Qwen2-7B（中文强）+ CodeLlama-7B（代码强），用QLoRA微调。训练数据来自：
  • Linux内核邮件列表里关于驱动bug的讨论（提取“现象→根因→补丁”三元组）；
  • CVE详情页的“Technical Description”字段；
  • 我们自己积累的1200+份逆向报告（脱敏后）。
• 量化部署：用llama.cpp将模型量化为Q4_K_M格式，单卡RTX 3090可跑128K context。关键技巧：把Ghidra的Decompiler输出重定向为模型输入，Prompt模板固定为：

你是一个嵌入式安全专家，请基于以下反编译代码分析潜在风险： [DECOMPILED_CODE] 请严格按JSON格式输出： {"risk_type": "buffer_overflow|use_after_free|race_condition", "evidence": "第X行调用strcpy且未检查长度", "mitigation": "改用strncpy并传入sizeof(dst)"}

• 效果验证：在测试集上，模型对buffer_overflow的识别准确率达92%，但对time_of_check_to_time_of_use这类复杂竞态，准确率只有63%——这正好印证了前文观点：AI负责“找证据”，人负责“做判断”。

5. 常见问题与避坑指南：那些没人告诉你的暗礁

5.1 “为什么我的binwalk什么都扫不出来？”——固件加密的三大伪装术

问题本质不是工具不行，而是你没识破厂商的加密套路。我们总结出最常用的三种伪装：

实操心得：永远先做file firmware.bin和ent firmware.bin。前者看文件类型，后者看熵值。如果file说“data”，ent说“entropy=7.98”，基本可以断定是加密或压缩；如果file说“POSIX shell script”，ent说“entropy=2.1”，那大概率是base64编码的二进制——直接base64 -d firmware.bin > decoded.bin。

5.2 “Ghidra反编译出来的代码全是乱码！”——符号缺失的终极解法

这不是Ghidra bug，而是你没利用好“动态符号”。商用固件通常剥离了.symtab，但.dynsym还在。破解步骤：

1. readelf -d firmware.elf \| grep SONAME找到依赖库名，如libcrypto.so.1.1；
2. readelf -d /path/to/libcrypto.so.1.1 \| grep '0x[0-9a-f]\+ \(.*\)'提取符号地址，如0x12345678 printf；
3. 在Ghidra里Symbol Table → Add Symbol，手动添加printf符号，地址填0x12345678；
4. 右键反编译窗口里的FUN_12345678→Rename Function→printf。

更狠的方法是“内存dump符号”：用JTAG连接目标设备，gdb里执行dump binary memory /tmp/symbols.bin 0x80000000 0x80100000，然后用strings /tmp/symbols.bin \| grep "printf\|malloc"找符号字符串，再用addr2line -e firmware.elf -f -C 0x80012340定位函数。去年分析某工控PLC，靠这招从内存dump里恢复出全部libc符号，反编译质量提升300%。

5.3 “AI给出的建议总是错的！”——提示词工程的三个生死线

本地AI模型出错，90%是提示词（Prompt）没写对。我们验证过的三条铁律：

• 必须限定输出格式：用{"field":"value"}强制JSON，避免模型自由发挥。测试发现，加strictly JSON比不加，格式错误率从47%降到3%。
• 必须提供上下文约束：比如分析memcpy时，Prompt里要写“目标平台是ARM Cortex-A9，r0是dst，r1是src，r2是len”，否则模型可能按x86习惯解读寄存器。
• 必须禁用推测性回答：加一句If uncertain, output {"risk_type":"unknown", "evidence":"insufficient_data"}。我们曾遇到模型把memset误判为buffer_overflow，就因为没加这句，它宁可编造证据也不愿承认不知道。

避坑技巧：把AI输出存为ai_analysis.json，用Python脚本自动校验JSON schema。如果risk_type不在预设枚举里，脚本直接报错，强制人工复核——这比相信AI的“自信度”靠谱100倍。

5.4 “为什么同样的PoC在不同设备上复现不了？”——硬件差异的隐形杀手

你以为固件一样，硬件就一样？大错特错。我们踩过的最深的坑：

• Flash芯片批次差异：同型号设备，A批次用Winbond W25Q32，B批次用Macronix MX25L32。前者支持0x05读状态寄存器，后者要求0x07。PoC里写死0x05，在B批次上永远超时。解决方案：spi_read_status函数里先发0x05，如果返回0xFF，再发0x07。
• 晶振精度漂移：某款GPS模块固件要求UART波特率误差<0.5%，但不同批次晶振公差是±20ppm。实验室用标准晶振能通，现场用廉价晶振就丢包。解决方案：在PoC里加入波特率自适应算法，用ioctl(fd, TIOCGSERIAL, &serinfo)读取实际波特率，动态调整。
• PCB走线长度：同款主板，A版本CPU到Flash的走线长8cm，B版本长12cm。高速SPI下，后者需要降低CLK频率才能稳定。解决方案：在固件启动时，用get_timer()测spi_transfer耗时，超阈值则自动降频。

这些差异不会写在Datasheet里，只能靠实测。我们的规矩是：每个PoC必须在至少3个不同生产批次的设备上验证，否则不算完成。

6. 终极实践：用reverse-skill拆解一个真实固件

6.1 目标选择：某品牌智能插座固件（v2.3.1）

选它是因为：

• 官网下载页明确写着“固件升级包”，不是OTA推送的加密流；
• strings firmware.bin \| grep "http"暴露出http://update.xxx.com/firmware/，说明有远程升级功能；
• binwalk -E firmware.bin显示熵值曲线有明显双峰，暗示存在压缩+未压缩混合结构。

6.2 现象锚定：升级失败时的串口日志

设备升级失败，串口输出：

[INFO] OTA start, version: 2.3.1 [INFO] Downloading from http://update.xxx.com/firmware/v2.3.1.bin [INFO] Download complete, size: 1048576 bytes [ERR] CRC32 mismatch! Expected: 0xabcdef12, got: 0x98765432 [ERR] Rollback to v2.2.0

关键现象：CRC32校验失败。注意不是“校验和错误”，而是明确给出期望值和实际值——这说明校验逻辑在固件里，且可逆向。

6.3 路径生成：从CRC32切入的三层路径

• 硬件层：CRC32计算通常由硬件加速器完成。查SoC手册（Realtek RTL8710BN），发现0x40002000处是CRC控制器寄存器。
• 固件层：strings firmware.bin \| grep -i "crc"找到crc32_calculate函数，readelf -s firmware.elf \| grep crc32得地址0x8001a2b0。
• AI辅助：把日志和函数地址喂给Qwen2，模型输出：“① 检查crc32_calculate的输入缓冲区是否包含HTTP响应头（概率89%）；② 验证0x8001a2b0是否被patch过（概率71%）；③ 审查升级包下载后是否执行了memmove导致缓冲区偏移（概率65%）”。

6.4 证据闭环：三证锁定HTTP头污染

• 行为证据：用tcpdump抓升级包下载过程，发现服务器返回的v2.3.1.bin前面多了HTTP/1.1 200 OK\r\nContent-Length: 1048576\r\n\r\n共56字节。
• 状态证据：在Ghidra里定位crc32_calculate，反编译显示它计算的是buffer+0x100开始的1048576字节，但buffer首地址是HTTP响应起始处。
• 物理证据：用逻辑分析仪抓SPI Flash写入，发现写入的前56字节确实是HTTP/1.1 200 OK...，证实固件把HTTP头当作了固件一部分。

结论：厂商的升级逻辑有严重缺陷——它把整个HTTP响应体（含header）传给CRC校验函数，但校验值只针对纯二进制部分。

6.5 知识沉淀：生成可复用的防护模式

• PoC：用Python写一个