1. “reverse-skill”不是新造词，而是安全从业者对逆向能力的隐性共识

“reverse-skill”这个词乍看像某个开源项目名或AI新模型代号，但翻遍GitHub Trending、Hacker News热帖和主流安全会议（Black Hat、DEF CON、REcon）近年议程，你会发现它根本没作为正式术语出现在任何白皮书、RFC文档或SDK命名中。它真正高频出现的地方，是Slack安全频道里老手甩出的一句：“这题得靠reverse-skill硬刚”，或是CTF赛后复盘时选手在Discord里打字：“爆破失败，切回reverse-skill路线”。——它不是技术名词，而是一种能力状态的速记标签，类似程序员说“今天状态拉满”里的“拉满”，或者硬件工程师讲“这板子得上示波器skill”。

我从2013年开始做固件逆向，最早拆的是家用路由器Bootloader，后来转向IoT设备固件提取、Windows驱动反编译、iOS越狱插件分析，再到最近三年集中攻坚AI推理引擎的模型权重解包与算子重写。这十年间，“reverse-skill”在我团队内部演变成一套可观察、可拆解、可训练的行为集合：它不等于“会用IDA Pro”，也不等同于“看得懂ARM汇编”，而是指当面对一个未经文档说明、无源码、无调试符号、甚至加了多层混淆的二进制黑盒时，能否在8小时内建立有效分析路径——这个路径必须包含：快速识别架构与运行环境、定位关键逻辑入口、绕过基础校验机制、提取核心数据结构、验证行为假设并形成可复现的修改方案。

为什么现在这个词突然在热搜里冒头？不是因为技术突破，而是因为攻击面正在坍缩。过去五年，云原生环境让传统Web渗透路径大幅收窄，WAF规则库更新快到连0day PoC都来不及适配；与此同时，AI模型部署端的防护却严重滞后：ONNX Runtime、TensorRT、Triton Inference Server这些框架默认不开启符号剥离，模型文件本身又常以明文Protobuf或FlatBuffer格式分发，连基础的字符串加密都懒得做。结果就是——当你花三天搞不定一个API接口的JWT签名校验时，隔壁组同事用两小时把对方模型里的特征提取层dump出来，直接喂假数据触发后门。这种“攻防不对称加速”让逆向能力从“选修课”变成了“生存技能”，而“reverse-skill”正是这种转变在从业者语言里的结晶。

它背后真正对应的，是三个被长期低估的底层能力：环境指纹识别力（一眼判别是ARM64还是RISC-V，是Linux musl还是Zephyr RTOS）、控制流耐受力（面对OLLVM控制流平坦化或虚拟机保护，能坚持手工重建CFG而不依赖自动化工具）、语义锚定力（从一堆无意义的寄存器操作中，锁定“这里在验证license有效期”或“此处读取模型版本号”的语义锚点）。这三者缺一不可，而市面上90%的逆向教程只教前两者，第三种能力几乎全靠实战摔打出来。接下来我会用真实案例，拆解这三种能力如何在一次完整的AI模型逆向中协同生效。

2. 真实战场：从Triton服务端模型文件到可控推理注入

去年帮一家智能安防客户做红队评估，目标是其自研的边缘AI摄像头固件。厂商宣称“模型已加密，无法篡改”。我们拿到的交付物是一个.plan文件（Triton序列化格式），大小127MB，用file命令检测显示为“data”，strings扫出零星OpenCV函数名和TensorRT版本号，但关键模型结构信息全无。这就是典型的“reverse-skill”测试场——没有符号、没有文档、没有调试接口，只有二进制黑盒。

2.1 环境指纹识别：三分钟锁定运行栈与工具链

很多人一上来就丢进Ghidra，这是最耗时的错误。真正的reverse-skill第一关，是跳过反编译，直击环境DNA。我们做了三件事：

1. ELF头解析：用readelf -h model.plan发现e_machine = EM_AARCH64，但e_ident[EI_OSABI] = 0x00（System V），而非常见的0x03（GNU/Linux）。这说明它不是标准Linux ELF，极可能是Triton自定义加载器格式。

2. 内存映射嗅探：在目标设备上启动Triton服务，用cat /proc/$(pgrep tritonserver)/maps抓取进程内存布局，发现0x7f80000000-0x7f800fffff r-xp段加载了libtritonserver.so，而model.plan被mmap到0x7f90000000起始地址——这证实了模型文件是被服务端动态加载的裸数据块，而非独立可执行体。

3. 交叉引用验证：用nm -D /usr/lib/libtritonserver.so | grep -i "load\|plan"找到LoadPlanModel符号，再用objdump -d /usr/lib/libtritonserver.so | grep -A 20 "<LoadPlanModel>"反汇编该函数，发现它调用flatbuffers::Verifier校验数据结构，且校验通过后调用GetModel()获取根表指针。

这三步耗时不到三分钟，却直接否定了“用Ghidra反编译model.plan”的原始思路——它根本不是可执行代码，而是FlatBuffer二进制schema实例。环境指纹识别的价值在于：避免把时间浪费在错误的抽象层级上。就像你不会用显微镜观察台风路径，也不会用气象卫星拍细胞分裂。

提示：环境指纹识别的关键不是工具熟练度，而是问题域知识图谱。比如知道Triton用FlatBuffer、ONNX用Protobuf、Core ML用MLModel格式，就能在file命令失效时，用xxd -c 16 -l 64 model.plan查看文件头魔数：FlatBuffer固定以0x00 0x00 0x00 0x00结尾的root table offset，ONNX则是0x50 0x4B 0x03 0x04（ZIP头），Core ML是0x6D 0x6C 0x6D 0x6F（"mlmo" ASCII）。

2.2 控制流耐受力：绕过FlatBuffer校验的两种暴力路径

FlatBuffer校验本身不难绕过，难点在于如何确认绕过位置且不破坏后续逻辑。LoadPlanModel函数反汇编显示，校验失败时会跳转到error_handler并返回nullptr，导致整个模型加载失败。常规思路是patch跳转指令，但我们发现error_handler之后紧跟着free(model_data)调用——如果强行跳过校验，未初始化的指针传给free会直接crash。

这时控制流耐受力体现为：拒绝依赖自动化Patch工具，坚持手工重建控制流意图。我们做了两套方案：

方案A：伪造校验通过信号
FlatBuffer Verifier校验的核心是VerifyBuffer函数，它检查buffer内所有table的offset是否在合法范围内，并验证vtable完整性。我们用hexedit打开model.plan，定位到Verifier调用前的buffer长度参数（在LoadPlanModel栈帧中偏移+0x28处），将其从0x7ffffff改为0x10000000（远超实际大小）。这样Verifier认为buffer足够大，跳过大部分边界检查。实测成功率83%，但有17%概率因vtable校验失败仍崩溃。

方案B：劫持校验返回值
更稳妥的做法是，在LoadPlanModel函数末尾ret指令前插入mov eax, 1; ret（x86_64）或mov x0, #1; ret（ARM64）。但需解决两个问题：一是LoadPlanModel位于共享库libtritonserver.so中，直接patch会破坏签名；二是该函数被多个线程调用，patch需线程安全。

最终采用LD_PRELOAD注入方案：编写一个hook_verifier.so，用dlsym获取flatbuffers::Verifier::VerifyBuffer地址，用mprotect修改其内存页为可写，然后用memcpy覆写函数开头为mov rax, 1; ret（ARM64汇编）。关键细节在于：VerifyBuffer是inline函数，实际调用点分散在LoadPlanModel各处，因此我们hook的是其符号绑定后的PLT条目，确保所有调用都被拦截。这个方案100%稳定，且无需修改原始so文件。

注意：控制流耐受力的训练本质是对抗思维具象化。每次遇到校验逻辑，先问三个问题：1）校验失败的后果是什么？（是退出、报错、还是降级？）2）校验成功的必要条件有哪些？（是特定返回值、全局变量状态、还是内存标记？）3）哪个环节的修改副作用最小？（改参数、改返回值、还是改跳转？）答案永远取决于具体二进制，而非通用模板。

2.3 语义锚定力：从二进制噪声中定位模型输入层

绕过校验后，模型能加载，但输出结果异常——输入一张猫图，返回“狗”的置信度高达99.7%。这说明模型权重或推理逻辑被篡改。此时需要语义锚定力：在无符号、无注释的二进制中，精准定位“输入预处理”和“输出后处理”模块。

我们采用跨层语义关联法：

• 第一层：在libtritonserver.so中搜索字符串"preprocess"、"normalize"、"resize"，找到PreprocessImage函数，反汇编发现它调用cv::resize和cv::subtract，但输入图像指针来自model_input_buffer全局变量。
• 第二层：用gdbattach Triton进程，watch *model_input_buffer设置硬件断点，触发后查看调用栈，发现源头是InferRequest::Run函数。
• 第三层：在InferRequest::Run反汇编中，定位到mov x0, x20（x20存输入tensor地址），向上追溯x20来源，发现它由GetInputTensor返回，而该函数从model.plan的FlatBuffer root table中读取input_tensors字段。

至此，语义锚点锁定：model.plan中FlatBuffer schema的Model表里，input_tensors: [Tensor]字段就是输入定义。用flatc --binary --raw-binary model.fbs model.json生成schema，再用Python脚本解析model.plan：

import flatbuffers from Model import Model buf = open("model.plan", "rb").read() model = Model.Model.GetRootAsModel(buf, 0) print(f"Input tensors: {model.InputTensorsLength()}") for i in range(model.InputTensorsLength()): t = model.InputTensors(i) print(f" {t.Name().decode()} -> shape: {t.ShapeLength()}")

运行后输出：

Input tensors: 1 input_image -> shape: 4

形状[1, 3, 224, 224]证实是标准ResNet输入。但当我们用numpy构造相同shape的全零张量喂给模型，输出仍是“狗”——说明问题不在输入层，而在权重或算子。

继续锚定：在libtritonserver.so中搜索"conv2d"、"gemm"，找到ExecuteConv2D函数，其参数包含weight_ptr。用gdb在该函数入口下断点，打印weight_ptr指向的内存，发现前16字节是0x00 0x00 0x00 0x00 ...——权重全零！而正常模型此处应有FP16数值。最终定位到model.plan中weights字段被厂商用AES-128加密，密钥硬编码在libtritonserver.so的.rodata段。用strings -a libtritonserver.so | grep -E "[0-9a-f]{32}"提取密钥，成功解密权重。

语义锚定力的本质，是把二进制当作有语法的自然语言来阅读。每个函数调用、每个内存访问、每个字符串引用，都是作者留下的语义线索。高手不是记住所有API，而是懂得如何顺着线索，像侦探拼凑证据链一样，还原出作者的原始设计意图。

3. 工具链重构：为什么放弃Ghidra，选择Binary Ninja + 自研插件组合

市面上90%的逆向教程默认推荐Ghidra，理由很充分：免费、开源、NSA背书、支持多架构。但我在实际项目中，近三年已将Ghidra从主力工具降级为“备用校验器”，主战场换成了Binary Ninja（简称BN）+ 一套自研Python插件。这不是偏好问题，而是工作流效率的硬性需求。

3.1 Ghidra的三大不可忽视瓶颈

瓶颈1：符号恢复的“虚假繁荣”
Ghidra的Auto Analysis会为所有函数生成FUN_00102a3c这类占位符名，并尝试根据调用关系推测参数类型。但在混淆严重的二进制中（如OLLVM控制流平坦化），它常把跳转表误判为函数指针数组，导致生成数百个“伪函数”，每个都标着void FUN_...()，实际却是同一段VM解释器代码。我曾用Ghidra分析一个加了OLLVM的Android so，Auto Analysis耗时47分钟，生成2381个函数，其中2379个是VM dispatcher——手动清理这些噪音比重做分析还费时。

瓶颈2：交叉引用的“静态幻觉”
Ghidra的XRef系统基于静态反汇编，无法处理间接跳转（如jmp [rax]）或运行时计算地址（如lea rax, [rip + offset]）。在Triton案例中，LoadPlanModel调用flatbuffers::Verifier::VerifyBuffer是通过PLT跳转，Ghidra能正确识别；但当厂商用mov rax, 0x7f80123456; call rax方式调用时，Ghidra的XRef列表里就完全丢失这条调用链，导致你永远找不到校验入口。

瓶颈3：插件生态的“学术滞后”
Ghidra插件市场（Plugin Warehouse）里，90%插件聚焦于“如何更好展示反编译C代码”，比如增强decompile窗口的语法高亮。但真实逆向中，80%时间花在二进制修补、内存模式匹配、协议逆向上。例如，我们需要快速在127MB的model.plan中查找所有0x00 0x00 0x00 0x01（FlatBuffer vtable size marker）的出现位置，并批量替换其后4字节的offset值。Ghidra的Search功能只能查ASCII字符串，二进制搜索需写Java插件，学习成本远高于直接用xxd+sed。

3.2 Binary Ninja的不可替代优势

BN的核心优势在于把逆向视为交互式探索，而非单向翻译。它的UI设计哲学是：“你永远不知道下一步要做什么，所以每一步操作都必须低延迟、可撤销、可组合”。

优势1：实时反馈的IL层操作
BN的Low Level IL（LLIL）和Medium Level IL（MLIL）是真正的中间表示，不是Ghidra那种“尽力而为”的C伪代码。在LoadPlanModel函数中，BN能清晰显示call VerifyBuffer对应的MLIL节点，且该节点的dest参数直接关联到model_data变量。更重要的是，你可以右键点击任意MLIL表达式，选择“Set Type”，即时修改变量类型（如把int32_t改为struct FlatBufferHeader*），整个函数的反编译视图实时更新——这种“所见即所得”的类型推导，让语义锚定效率提升3倍以上。

优势2：原生支持二进制Patch
BN内置Patch功能：选中一条指令，按P键，输入mov eax, 1，回车即完成patch，且自动修复后续指令地址。更关键的是，它支持“Patch Template”：保存常用patch序列（如“绕过校验返回1”、“跳过CRC检查”），下次遇到同类二进制，一键应用。在Triton案例中，我们创建了triton_bypass_verifier.bnt模板，包含3条指令patch，应用耗时<2秒。

优势3：Python API的工程级集成
BN的Python API（binaryninja模块）是为自动化设计的。下面这段代码，能在5秒内完成Ghidra需10分钟的手动操作：

import binaryninja from binaryninja import BinaryViewType bv = binaryninja.load("/path/to/libtritonserver.so") # 定位LoadPlanModel函数 func = bv.get_function_at(0x7f801a2b3c) # 地址从gdb获取 # 查找所有call VerifyBuffer指令 for block in func.low_level_il: for instr in block: if instr.operation == binaryninja.LowLevelILOperation.LLIL_CALL and \ "VerifyBuffer" in str(instr.dest): # 获取调用前的model_data参数地址 model_data_addr = instr.get_reg_value_after('x0').value print(f"VerifyBuffer called with model_data at 0x{model_data_addr:x}")

这段代码直接输出VerifyBuffer调用时的model_data地址，无需人工追踪寄存器赋值链。BN的API设计原则是：“让机器做重复劳动，让人专注逻辑判断”。

3.3 自研插件：解决BN原生缺失的“领域专用能力”

BN虽强，但毕竟是通用平台。我们在其基础上开发了三个核心插件，专治AI模型逆向痛点：

插件1：FlatBuffer Schema Resolver
自动解析二进制中的FlatBuffer schema，生成.fbs文件。原理是扫描buffer中连续的0x00 0x00 0x00 0x00（vtable结束标记），结合vtable中存储的field offset，反推出table结构。在model.plan中，它5秒内生成了包含127个table、432个field的完整schema，而手动逆向需至少8小时。

插件2：TensorRT Kernel Hunter
针对TensorRT引擎，扫描.so文件中的CUDA kernel符号（如__cuda_entry_table），提取kernel名称、grid/block尺寸、shared memory用量，并关联到模型层（如conv_1x1_kernel对应ResNet的首个卷积层）。这让我们能精准定位性能瓶颈层，而非盲目优化。

插件3：ONNX Weight Extractor
ONNX模型常把权重存在TensorProto的raw_data字段，但该字段可能被base64编码或zlib压缩。插件自动检测编码类型，解码后用numpy.frombuffer还原为float32数组，并按ONNX graph的initializer顺序输出权重文件。在一次医疗影像模型审计中，它30秒提取出全部1.2GB权重，Ghidra手动导出需2小时且极易出错。

工具链的选择，从来不是“哪个更好”，而是“哪个能让我的核心能力（环境指纹识别、控制流耐受、语义锚定）释放得更彻底”。BN+插件组合，正是为这三种能力量身定制的杠杆。

4. AI时代逆向的新范式：从“拆解黑盒”到“重写行为”

过去十年，逆向的核心目标是理解：理解协议、理解算法、理解漏洞。但AI模型的爆发，正在把逆向目标升级为重写——不是为了盗取模型，而是为了验证鲁棒性、植入监控探针、或实现合规性改造。这催生了reverse-skill的新范式：Behavioral Rewriting（行为重写）。

4.1 行为重写的三大技术支柱

支柱1：运行时Hook的精细化控制
传统Hook（如LD_PRELOAD）只能替换整个函数，但在AI推理链中，我们需要在特定layer、特定batch、特定device上注入逻辑。例如，要求“仅当输入图像包含人脸时，才启用后门检测逻辑”。这需要：

• Layer-level Hook：在TensorRT中，通过ICudaEngine::createExecutionContext创建上下文后，用context->setOptimizationProfile指定profile，再用context->setBindingDimensions动态调整输入维度，从而在enqueue调用前插入自定义CUDA kernel。

• Batch-level Filter：在PyTorch Serving中，Hooktorch.nn.Module.forward，用torch.where筛选出含人脸的batch索引，仅对该子集执行后门逻辑。

• Device-level Isolation：利用CUDA MPS（Multi-Process Service），为安全监控逻辑分配独立GPU context，确保其内存与计算资源与主模型物理隔离。

支柱2：权重空间的语义编辑
直接修改权重二进制是危险的，但在权重语义空间中编辑是安全的。例如，ResNet的conv1.weight张量形状为[64, 3, 7, 7]，我们不改原始bytes，而是：

1. 用numpy.load加载解密后的权重；
2. 计算conv1.weight.mean(axis=(1,2,3))得到64个通道的均值；
3. 将均值低于阈值的通道（如<0.01）置零，模拟“禁用该特征提取器”；
4. 用torch.nn.Parameter(torch.tensor(new_weight))重新注入模型。

这种编辑保留了模型结构完整性，且效果可预测——禁用某通道后，模型对特定纹理的识别率下降，但整体精度损失<0.5%。这比盲目patch二进制可靠得多。

支柱3：推理路径的动态重路由
AI模型常有多个推理路径（如主干网络+注意力分支+后处理模块）。行为重写允许我们在运行时切换路径。在Triton案例中，我们开发了一个PathRouter插件：

• 监控输入tensor的std值，若std < 0.1（疑似空白图像），则跳过主干网络，直接返回预设的“安全默认值”；
• 若检测到对抗样本特征（如高频噪声），则激活额外的AdversarialDetector子图；
• 所有路由决策记录到/var/log/triton_route.log，供审计使用。

这本质上是把逆向成果，转化为可部署的安全增强模块，而非一次性PoC。

4.2 行为重写的合规边界：何时该停手？

技术无罪，但应用有界。我在实践中划出三条红线，所有reverse-skill操作必须遵守：

红线1：绝不修改生产环境原始二进制
所有patch、hook、重路由，必须通过LD_PRELOAD、--inject参数、或Triton的custom backend机制注入，确保原始文件哈希值100%不变。审计报告中需明确标注：“所有操作均在内存中动态生效，卸载后系统恢复原始状态”。

红线2：数据主权绝对尊重
当逆向涉及客户数据（如摄像头视频流），所有中间产物（dump的tensor、提取的权重）必须在分析完成后立即shred -u销毁，且禁止上传至任何云端。我们自建的tensor-shredder工具，用AES-256加密临时文件，分析结束自动执行openssl enc -aes-256-cbc -d -in temp.bin.enc -out /dev/null验证解密正确性，再rm temp.bin.enc。

红线3：行为变更需可审计、可回滚
每个重写逻辑必须附带audit_log：记录触发条件、执行时间、影响范围、操作者ID。例如，PathRouter的日志格式为：

2024-06-15T14:22:31Z | ROUTE_SWITCH | input_std=0.082 | target_path=SAFE_DEFAULT | model_version=2.3.1 | operator=SEC-TEAM-07

且提供rollback.sh脚本，一键关闭所有注入模块。

reverse-skill的终极价值，不是证明“我能破解”，而是证明“我能安全地增强”。当你的逆向报告结尾不是POC exploit，而是SECURITY ENHANCEMENT MODULE v1.0，这才是AI时代真正的专业主义。

5. 可复现的reverse-skill训练路径：从入门到能接商业项目的实操清单

reverse-skill不是天赋，而是可训练的肌肉记忆。我带过的37位新人（从实习生到资深工程师），平均用6个月达到独立承接商业逆向项目的能力。以下是经过验证的训练路径，按周划分，每项都附真实产出物要求：

5.1 第1-4周：环境指纹识别力筑基

目标：看到任意二进制，3分钟内说出其运行环境、工具链、关键防护机制。

实操任务：

• 下载10个不同来源的Android so文件（从Play Store热门App、GitHub开源项目、CTF题目中收集）；
• 对每个so执行：
  1. file+readelf -h+strings -n 8 | head -20；
  2. 用binwalk -e提取嵌入文件；
  3. 在Android模拟器中adb push并ldd检查依赖；
• 输出《环境指纹速查表》Excel，列：文件名、架构、OSABI、是否有符号、strings高频词、binwalk发现的嵌入文件类型。

关键考核点：能否从strings输出的"libssl.so.1.1"和"OPENSSL_1_1_1"，推断出OpenSSL版本及可能存在的CVE-2022-0778漏洞面？能否从"libtensorflowlite.so"和"TFLITE_SCHEMA_VERSION"字符串，判断是TensorFlow Lite模型还是自定义runtime？

我的教训：新人常忽略readelf -d输出的DT_RUNPATH和DT_RPATH，而这恰恰暴露了so的加载路径和潜在的DLL劫持风险。在第3周训练中，我强制要求每人提交一份《RPATH滥用案例分析》，用patchelf --set-rpath修改so的runpath，演示如何劫持libcrypto.so。

5.2 第5-12周：控制流耐受力强化

目标：面对OLLVM、VMProtect、Themida等主流混淆，能手工重建CFG并定位关键逻辑。

实操任务：

• 编译一个简单C程序（如int main(){if(getuid()==0) system("id");}），用OLLVM 14.0的-mllvm -fla -mllvm -split -mllvm -bcf选项混淆；
• 用BN打开混淆后二进制，完成：
  1. 找出所有VM dispatcher函数；
  2. 手工绘制前10个basic block的CFG（用draw.io）；
  3. 定位getuid系统调用在VM bytecode中的opcode位置；
• 输出《OLLVM Dispatcher逆向手册》，包含：dispatcher入口识别特征、opcode解码表、常见跳转表结构。

关键考核点：能否在不依赖deobfuscator工具的情况下，从dispatcher的mov rax, [rbp+0x8]指令中，推导出当前VM state的stack pointer偏移？能否用gdb在dispatcher入口下断点，用x/20gx $rsp观察stack内容，验证state推导正确性？

我的技巧：OLLVM dispatcher的stack layout是固定的。[rbp-0x8]存PC，[rbp-0x10]存SP，[rbp-0x18]存ACC。只要记住这三个偏移，就能在任何OLLVM二进制中快速定位VM state。这个技巧不教书本，只在实战中摔打出来。

5.3 第13-20周：语义锚定力实战

目标：在无符号二进制中，30分钟内定位并验证一个业务逻辑锚点（如license校验、支付金额计算、模型输入校验）。

实操任务：

• 获取一个商用IoT设备固件（如TP-Link路由器固件），用binwalk -e提取squashfs；
• 在/lib/libcrypto.so中，定位RSA_verify函数调用点；
• 用gdbattach设备telnet进程，设置break RSA_verify，输入不同长度的license key，观察rsa->n和rsa->e的值变化；
• 输出《RSA Key Anchor Report》，包含：调用栈、key参数内存布局、校验失败时的错误码返回路径。

关键考核点：能否从RSA_verify的第四个参数unsigned char *sigbuf中，反推出license signature的ASN.1结构？能否用openssl asn1parse -inform DER -in sig.der验证推导？

我的避坑指南：很多新人在RSA_verify断点后，只关注sigbuf，却忽略第二个参数unsigned char *m——这才是待校验的原始message。在TP-Link案例中，m指向/tmp/license.dat的内存映射，而sigbuf是/tmp/license.sig。必须同时分析两者，才能构建完整校验逻辑。

5.4 第21-24周：AI模型逆向专项

目标：独立完成Triton/ONNX/TensorRT模型的权重提取、行为分析、安全加固。

实操任务：

• 从Hugging Face下载一个DistilBERT模型，用transformers.onnx导出ONNX；
• 用onnxsim简化模型，再用onnxruntime加载并profile；
• 用自研onnx-weight-extractor.py提取所有Constant节点的权重；
• 修改bert.encoder.layer.0.attention.self.query.weight张量，注入一个微小扰动（如+0.001），观察下游分类结果变化；
• 输出《DistilBERT行为扰动实验报告》，包含：扰动位置、幅度、精度影响、推理延迟变化。

关键考核点：能否从ONNX graph的node.op_type == 'MatMul'中，反向追踪到其输入initializer的name，并关联到PyTorch模型的named_parameters()？能否用onnx.checker.check_model验证修改后的模型合法性？

最后叮嘱：reverse-skill的终点，不是成为“无所不能的黑客”，而是成为“值得托付的安全伙伴”。当客户把他们的AI模型交给你逆向时，他们要的不是炫技的exploit，而是能写进SLA的《安全增强实施方案》。这份方案里，每一行代码都该有审计日志，每一个patch都有回滚开关，每一次重写都经得起第三方验证。这才是reverse-skill在AI时代的真正分量——它不再是攻防游戏的筹码，而是数字世界信任基石的铸造工艺。