1. 从一篇综述聊起IC逆向到底在逆什么第一次看到“TCHES 2026 IC逆向综述”这个题目我脑子里冒出来的不是学术论文的框架而是几年前帮朋友看一块来路不明的FPGA加速卡时的场景。板子上的主芯片丝印被磨掉了周围一圈DDR颗粒、一颗QSPI Flash、几个电源管理芯片还有几路高速差分对。朋友问我这卡能不能二次开发我当时的回答很直接先别谈开发先搞清楚它是什么、里面装了什么、逻辑是怎么组织的。这就是IC逆向最朴素的起点——你手里有一个已经封装好的、功能未知或者文档缺失的硬件对象你需要通过一系列手段把它“翻译”回人类可理解的形式。IC逆向这个词听起来很硬核实际上它覆盖的范围非常宽。往小了说读出一颗EEPROM里的配置数据、从FPGA的比特流里恢复出部分网表结构都算逆向往大了说对一颗复杂SoC做层次化拆解、恢复寄存器映射、重建模块级功能模型也是逆向。TCHES作为硬件安全领域的顶刊它收录的IC逆向综述通常不会只讲某一个技巧而是把整个方法论链条梳理一遍从物理层面的成像、去层、探针到逻辑层面的网表提取、功能识别再到系统层面的协议恢复和固件分析。这条链条上每一环都有坑而且坑与坑之间是相互影响的。我之所以对这个题目感兴趣是因为最近几年FPGA和LLM这两个东西正在从两个方向改变IC逆向的游戏规则。FPGA让逆向过程中的数据采集、协议仿真、激励生成变得更灵活你可以用一块FPGA开发板搭出一个针对特定接口的“翻译器”把高速ADC采样回来的信号实时处理成可分析的格式。LLM则让逆向过程中大量重复的模式识别、代码理解、文档生成工作有了自动化的可能比如把恢复出来的网表片段喂给模型让它推测某个模块可能是UART控制器还是SPI主机。这两条线在TCHES这类综述里通常会被单独拎出来讨论因为它们代表的是“逆向效率”这个核心痛点的两个不同解法。这篇文章我想按自己的理解把IC逆向这件事从整体思路到具体操作拆一遍。不管你是做FPGA开发的、搞硬件安全的还是单纯对“怎么看懂一块陌生芯片”感兴趣都能从中找到能直接上手的东西。我会尽量把学术综述里那种高度抽象的描述翻译成实际干活时的步骤和判断依据同时把FPGA和LLM这两个热词落到具体的操作环节里而不是停留在概念层面。2. 逆向工程的全局拆解从黑盒到可理解模型2.1 逆向对象的层次划分与对应手段做IC逆向最忌讳一上来就埋头看波形或者磨芯片。我习惯先把逆向对象按层次分清楚因为不同层次对应的手段、工具、时间成本完全不一样。一个比较实用的划分方式是四层物理层、电气层、逻辑层、系统层。物理层关心的是芯片长什么样、用了什么工艺、金属层怎么走电气层关心的是引脚电平、时序参数、接口协议逻辑层关心的是门级网表、寄存器传输级结构、状态机系统层关心的是固件、配置数据、模块间交互关系。这个划分不是学术上的严格定义而是干活时的优先级排序。比如你拿到一块FPGA板子物理层你基本不需要动因为FPGA的比特流结构是公开可查的你直接跳到逻辑层和系统层就行。但如果你拿到的是一颗定制的ASIC物理层和电气层就是绕不过去的因为你连引脚定义都不知道。TCHES的综述里通常会强调这种“按需选择层次”的思路而不是鼓吹某一种万能方法。具体到手段物理层常用的是光学显微成像、扫描电子显微镜、聚焦离子束切割这些设备门槛高一般只在专业实验室里做。电气层常用的是逻辑分析仪、示波器、协议分析仪配合FPGA做自定义触发和采集。逻辑层常用的是比特流解析、网表提取、功能仿真工具链包括厂商提供的开发套件和第三方逆向工具。系统层常用的是固件提取、配置数据解析、动态调试有时候还需要自己写脚本做批量处理。我自己的经验是大部分实际项目根本不需要走到物理层。你遇到的绝大多数“逆向”需求其实是电气层和逻辑层的问题。比如一块工业控制板上的FPGA配置Flash被加密了你需要恢复出里面的逻辑功能或者一个老设备的通信协议没有文档你需要从波形里反推出帧格式。这些场景下FPGA和逻辑分析仪的组合就能解决八成以上的问题。2.2 为什么FPGA在逆向中越来越重要FPGA在IC逆向里的角色我把它总结为“万能适配器”。逆向过程中最头疼的事情之一是目标对象的接口协议千奇百怪而你手头的采集设备往往只支持标准协议。这时候FPGA的价值就体现出来了你可以用FPGA实现一个针对特定时序的采集前端把非标准信号转换成标准格式再送给上位机分析。举个例子我之前接触过一个项目目标设备用了一种类似SPI但时钟极性和相位都很奇怪的串行接口市面上没有现成的协议分析仪能直接解码。我的做法是用一块FPGA开发板把目标设备的时钟和数据线接到FPGA的IO上在FPGA内部写一个状态机按照猜测的时序去采样然后把采样结果通过UART送到电脑上。整个过程从搭硬件到出第一版解码结果大概花了一个下午。如果用纯软件方案或者通用仪器可能要折腾好几天。FPGA的另一个优势是实时性。有些逆向场景需要你在极短的时间窗口内完成信号采集和预处理比如抓取上电瞬间的配置过程。FPGA的并行处理能力让你可以在纳秒级的时间精度上做多通道同步采集这是普通微控制器做不到的。TCHES的综述里提到FPGA时通常会强调它在“协议仿真”和“激励生成”两方面的作用前者是听懂目标设备在说什么后者是让目标设备按照你的意图说话。2.3 LLM介入逆向的切入点与边界LLM在IC逆向里的应用目前最实在的切入点是“模式识别”和“代码理解”。逆向过程中会产生大量半结构化的数据比如反汇编出来的汇编代码、提取出来的网表片段、抓包得到的协议数据流。这些数据的特点是格式相对固定但语义不明确正好是LLM擅长的领域。我试过把一段从FPGA比特流里恢复出来的LUT配置数据整理成文本格式然后让LLM去推测这些LUT可能实现了什么逻辑功能。结果不算完美但它确实能给出一些有价值的猜测比如“这组LUT的输入输出关系看起来像是一个4位计数器”或者“这个模式重复出现可能是状态机的一部分”。这种猜测不能直接当作结论但可以作为下一步验证的方向省去了大量盲目尝试的时间。LLM的边界也很明显。它不擅长处理需要精确数值计算的任务比如时序分析、功耗估算它也不擅长处理高度依赖上下文的任务比如从一段残缺的网表里恢复出完整的模块层次。我的做法是把LLM当作一个“高级搜索引擎”和“代码解释器”用它来加速理解过程而不是用它来替代验证过程。TCHES的综述里对LLM的态度通常比较谨慎会强调“辅助”而非“替代”这个定位我觉得是准确的。3. 核心细节解析网表、比特流与协议恢复3.1 从比特流到网表FPGA逆向的关键路径FPGA逆向和ASIC逆向最大的区别在于FPGA的比特流是一个“半公开”的格式。厂商会公布比特流的文件结构但不会公布具体的配置位到逻辑资源的映射关系。这意味着你不能直接读比特流就知道里面是什么逻辑但你可以通过对比不同设计生成的比特流反推出部分映射关系。这个反推过程通常分三步。第一步是“差分分析”用同一个FPGA型号生成两个只有微小差异的设计比如一个加法器和一个减法器然后对比它们的比特流差异。差异的位置通常对应着实现差异的逻辑资源。第二步是“资源定位”通过大量差分样本建立起比特流位置和逻辑资源类型之间的对应关系比如哪些位对应LUT的输入、哪些位对应触发器的使能。第三步是“网表重建”根据定位结果把比特流翻译成门级网表然后再根据网表的连接关系推测更高层的功能。这个过程听起来很系统但实际操作中最大的坑是“比特流加密”。很多厂商的高端FPGA支持比特流加密你拿到的比特流是加密后的差分分析根本做不了。这时候要么走物理层去探针要么找其他漏洞比如利用配置接口的调试模式。TCHES的综述里会专门讨论比特流加密对逆向的影响以及目前有哪些已知的绕过思路但这些思路通常有很强的时效性厂商一打补丁就失效了。3.2 网表恢复后的功能识别LLM能帮上什么忙假设你已经成功从比特流恢复出了一个门级网表接下来的问题是这一堆与门、或门、触发器到底实现了什么功能传统做法是人工分析或者用一些基于图匹配的自动化工具。人工分析慢但准确自动化工具快但误报率高。LLM的介入点在这里就比较自然了。我试过的一个流程是先把网表按照连接关系切分成若干个子图每个子图对应一个可能的功能模块然后把子图的拓扑结构用文本描述出来比如“输入A和输入B经过一个与门输出连接到触发器的D端触发器的时钟来自输入C”最后让LLM根据这些描述推测模块功能。实测下来LLM对常见模块的识别准确率还不错比如计数器、移位寄存器、简单的状态机。但对于复杂模块比如带流水线的乘法器或者自定义的加密引擎LLM的推测就很不靠谱了。这里的关键是“人机配合”。LLM给出候选功能列表你根据经验筛选出最可能的几个然后用仿真或者实际测试去验证。这个流程比纯人工快比纯自动化准。TCHES的综述里提到LLM时通常会强调“可解释性”和“可验证性”因为逆向的结论必须经得起验证不能只是“看起来像”。3.3 协议恢复从波形到帧格式的逆向过程协议恢复是IC逆向里最常见也最实用的任务之一。你有一个设备它通过某种串行接口和外界通信但你没有协议文档。你需要从波形里反推出帧格式、波特率、校验方式、命令集。这个过程我做过很多次总结下来就是“先定帧、再定字段、最后定语义”。先定帧的意思是你要先找到数据包的边界。常用的方法是找空闲电平或者特定的同步头。比如UART的空闲是高电平起始位是低电平SPI的片选信号拉低表示一帧开始。找到边界后你就可以把连续的波形切分成一个个数据包。再定字段的意思是你要确定每个数据包里哪些位是地址、哪些位是数据、哪些位是校验。这一步通常需要你发送已知的激励观察响应通过对比来推断字段位置。最后定语义的意思是你要搞清楚每个命令码对应什么操作比如0x01是读寄存器、0x02是写寄存器。FPGA在这个过程中的作用是“可编程的激励源和采集器”。你可以用FPGA产生精确的时序激励同时采集目标设备的响应然后把两者对齐后送给上位机分析。我常用的一个技巧是在FPGA内部做一个简单的状态机让它自动发送一系列命令码并记录每个命令码对应的响应。这样一轮下来你就能得到一张命令码和响应的对照表大大加速语义推断。4. 实操过程从零搭建一个FPGA辅助逆向平台4.1 硬件选型与连接方式搭建一个FPGA辅助逆向平台硬件选型不需要追求高端。我自己的配置是一块中低端FPGA开发板带足够的IO和至少一路高速差分输入外加一个逻辑分析仪作为备份。FPGA开发板的选择上我倾向于选IO电平可配置的型号因为逆向对象的电平标准可能是1.8V、2.5V、3.3V甚至更低如果FPGA的IO电平固定你就需要额外的电平转换电路增加复杂度和故障点。连接方式上最稳妥的是用飞线把目标设备的信号引到FPGA的IO上。飞线长度尽量短尤其是高速信号否则信号完整性会出问题。如果目标设备的信号是差分对比如LVDS你需要确认FPGA的差分输入是否支持你需要的电平标准。我踩过的一个坑是某款FPGA的LVDS输入要求共模电压在特定范围内而目标设备的共模电压偏离了这个范围导致接收到的数据全是错的。后来加了一个简单的电阻分压网络才解决。供电方面FPGA开发板和目标设备最好独立供电避免相互干扰。如果必须共地确保地线足够粗并且尽量缩短地线长度。我在早期项目中曾经因为地线太长引入了大量噪声导致采集到的波形完全不可用排查了很久才发现是接地问题。4.2 采集逻辑的设计与参数计算采集逻辑的设计取决于你要抓什么信号。如果是低速串行信号比如UART或者I2C你可以用简单的过采样加边沿检测。过采样率的选择有个经验公式采样率至少是信号最高频率的4倍实际中我通常用8到16倍。比如你要抓一个波特率115200的UART信号最高频率大概是115200Hz采样率用1MHz就足够了。如果是高速信号比如DDR或者高速ADC你就需要用到FPGA内部的专用资源比如ISERDES或者IDELAY。这些资源的使用需要参考厂商的文档参数计算也比较复杂。以DDR读写为例你需要考虑时钟和数据之间的相位关系通常需要用IDELAY做动态对齐。我做过的一个项目中DDR数据速率是800Mbps我用IDELAY以78ps的步进扫描找到了最佳采样点。这个扫描过程可以自动化写一个状态机让IDELAY逐步增加同时统计误码率误码率最低的点就是最佳采样点。采集深度也是一个需要权衡的参数。FPGA内部的Block RAM容量有限如果你要抓很长时间的数据就需要用流模式把数据实时传到上位机或者用压缩算法减少数据量。我通常的做法是先用小深度抓一段看看信号特征确定触发条件后再用大深度抓完整的数据包。4.3 上位机分析流程与脚本化处理FPGA采集到的数据最终要送到上位机做分析。我习惯用Python做上位机处理因为生态丰富各种解析库都有。基本流程是FPGA通过UART或者USB把数据传到电脑Python脚本接收数据后先做格式转换把原始采样点转换成时间序列然后做协议解码最后输出结构化的结果。协议解码这部分我通常会写一个可配置的解码器把帧格式、波特率、校验方式作为参数传进去。这样同一个解码器可以复用到不同的项目上。解码结果我一般输出成CSV或者JSON格式方便后续用Excel或者数据库做进一步分析。如果数据量很大我会用Pandas做批量处理把解码、统计、可视化串成一条流水线。脚本化处理的一个好处是可复现。逆向过程中经常需要反复调整参数如果每次都是手工操作很容易出错而且效率低。把整个流程脚本化之后你只需要改几个参数就能重新跑一遍大大加快了迭代速度。我现在的习惯是任何一个逆向项目第一件事就是搭一个脚本框架把数据采集、解码、分析、可视化都串起来后面所有的工作都在这个框架里做。5. 常见问题与排查技巧实录5.1 采集数据全是噪声或者全为零这是最常见的问题原因通常有三个接线错误、电平不匹配、时钟问题。接线错误包括信号线接反、地线没接、飞线断裂。电平不匹配包括FPGA的IO电平和目标设备不兼容比如目标设备是1.8V而FPGA的IO配置成了3.3V。时钟问题包括采样时钟频率不对、时钟相位不对、时钟抖动太大。排查顺序我建议从最简单开始先用万用表确认接线连通性再用示波器看目标设备的信号是否正常最后检查FPGA的配置。如果目标设备的信号正常但FPGA采集不到大概率是电平或者时钟问题。我遇到过一次目标设备的信号幅度只有1.2V而FPGA的IO阈值是1.5V导致采集到的数据全是零。后来在信号线上加了一个简单的电平转换芯片才解决。5.2 协议解码结果不稳定或者时好时坏解码结果不稳定通常意味着采样点没有对准。对于同步协议你需要确保采样时钟的相位对准数据有效窗口的中间。对于异步协议你需要确保波特率估计准确。我常用的方法是“扫描法”把采样相位或者波特率作为变量逐步扫描统计每个取值下的解码成功率成功率最高的取值就是最佳值。另一个可能的原因是信号完整性。如果飞线太长或者没有做阻抗匹配信号边沿会变缓导致采样点判断错误。这种情况下缩短飞线或者加一个串联电阻通常能改善。我在一个高速SPI项目中遇到过类似问题SPI时钟频率是50MHz飞线长度10厘米解码成功率只有70%。后来把飞线缩短到3厘米成功率直接到了99%以上。5.3 网表恢复后功能识别准确率低功能识别准确率低的原因通常是网表本身不完整或者有错误。比特流恢复出来的网表往往缺少一些优化信息比如LUT的输入映射可能不是最优的导致网表结构和你预期的功能模块对不上。这时候不要强行用自动化工具去匹配而是先人工检查几个关键节点确认网表的基本结构是否正确。LLM在这个环节的作用是提供候选而不是给出答案。我通常会把网表按功能区域切分成小块每块单独让LLM分析然后把结果汇总后人工筛选。如果某个模块LLM给出了多个候选功能我会用仿真去验证每个候选看哪个候选的行为和实际网表一致。这个过程比较耗时但比盲目猜测靠谱得多。5.4 常见问题速查表问题现象可能原因排查方法解决思路采集数据全零接线错误、电平不匹配万用表测通断、示波器看信号重新接线、加电平转换采集数据全噪声地线干扰、时钟抖动检查地线连接、测量时钟质量缩短地线、加滤波电容解码结果不稳定采样相位不对、波特率不准扫描相位和波特率自动扫描找最佳值网表功能识别错误网表不完整、LLM误判人工检查关键节点、仿真验证分块分析、多候选验证高速信号误码率高阻抗不匹配、采样点偏移检查飞线长度、扫描IDELAY缩短飞线、动态对齐6. 一些踩坑之后的个人体会IC逆向这件事工具和方法论固然重要但真正决定效率的往往是“先做什么、后做什么”的判断。我见过太多人一上来就追求最先进的设备或者最复杂的算法结果在基础问题上卡了很久。实际上大部分逆向任务用一块普通的FPGA开发板加一个逻辑分析仪就能解决关键是你对目标对象的理解程度和你的排查思路是否清晰。FPGA在逆向中的价值我觉得被低估了。很多人把FPGA当作“可编程逻辑器件”但在逆向场景下它更像是一个“万能接口适配器”和“实时信号处理器”。你可以用它来模拟目标设备的通信对端也可以用它来产生精确的激励信号还可以用它来做实时的数据预处理。这些能力组合起来能覆盖逆向过程中很大一部分需求。LLM在逆向中的价值我觉得被高估了。它确实能加速一些模式识别和代码理解的工作但它不能替代验证。逆向的结论必须经得起实测LLM给出的任何推测都只是起点不是终点。我现在的做法是把LLM当作一个“头脑风暴伙伴”用它来生成候选方案然后用传统方法去验证。这个定位让我既能享受LLM带来的效率提升又不会陷入“看起来对但实际错”的陷阱。最后分享一个小技巧在开始任何逆向项目之前先花半个小时把目标设备的“正常行为”记录下来。比如它的上电时序、空闲状态下的引脚电平、正常通信时的波形特征。这些基线数据在你后续排查问题时非常有用因为你可以通过对比基线快速判断异常是出在目标设备还是出在你的采集系统。这个习惯帮我省下了大量排查时间尤其是在面对多个变量同时变化的时候。 
长河君 · 2026/10/6 15:46:00 · 阅读 1.2k FPGA与LLM如何重塑IC逆向工程：从比特流到网表恢复的实战解析
1. 从一篇综述聊起IC逆向到底在逆什么第一次看到“TCHES 2026 IC逆向综述”这个题目我脑子里冒出来的不是学术论文的框架而是几年前帮朋友看一块来路不明的FPGA加速卡时的场景。板子上的主芯片丝印被磨掉了周围一圈DDR颗粒、一颗QSPI Flash、几个电源管理芯片还有几路高速差分对。朋友问我这卡能不能二次开发我当时的回答很直接先别谈开发先搞清楚它是什么、里面装了什么、逻辑是怎么组织的。这就是IC逆向最朴素的起点——你手里有一个已经封装好的、功能未知或者文档缺失的硬件对象你需要通过一系列手段把它“翻译”回人类可理解的形式。IC逆向这个词听起来很硬核实际上它覆盖的范围非常宽。往小了说读出一颗EEPROM里的配置数据、从FPGA的比特流里恢复出部分网表结构都算逆向往大了说对一颗复杂SoC做层次化拆解、恢复寄存器映射、重建模块级功能模型也是逆向。TCHES作为硬件安全领域的顶刊它收录的IC逆向综述通常不会只讲某一个技巧而是把整个方法论链条梳理一遍从物理层面的成像、去层、探针到逻辑层面的网表提取、功能识别再到系统层面的协议恢复和固件分析。这条链条上每一环都有坑而且坑与坑之间是相互影响的。我之所以对这个题目感兴趣是因为最近几年FPGA和LLM这两个东西正在从两个方向改变IC逆向的游戏规则。FPGA让逆向过程中的数据采集、协议仿真、激励生成变得更灵活你可以用一块FPGA开发板搭出一个针对特定接口的“翻译器”把高速ADC采样回来的信号实时处理成可分析的格式。LLM则让逆向过程中大量重复的模式识别、代码理解、文档生成工作有了自动化的可能比如把恢复出来的网表片段喂给模型让它推测某个模块可能是UART控制器还是SPI主机。这两条线在TCHES这类综述里通常会被单独拎出来讨论因为它们代表的是“逆向效率”这个核心痛点的两个不同解法。这篇文章我想按自己的理解把IC逆向这件事从整体思路到具体操作拆一遍。不管你是做FPGA开发的、搞硬件安全的还是单纯对“怎么看懂一块陌生芯片”感兴趣都能从中找到能直接上手的东西。我会尽量把学术综述里那种高度抽象的描述翻译成实际干活时的步骤和判断依据同时把FPGA和LLM这两个热词落到具体的操作环节里而不是停留在概念层面。2. 逆向工程的全局拆解从黑盒到可理解模型2.1 逆向对象的层次划分与对应手段做IC逆向最忌讳一上来就埋头看波形或者磨芯片。我习惯先把逆向对象按层次分清楚因为不同层次对应的手段、工具、时间成本完全不一样。一个比较实用的划分方式是四层物理层、电气层、逻辑层、系统层。物理层关心的是芯片长什么样、用了什么工艺、金属层怎么走电气层关心的是引脚电平、时序参数、接口协议逻辑层关心的是门级网表、寄存器传输级结构、状态机系统层关心的是固件、配置数据、模块间交互关系。这个划分不是学术上的严格定义而是干活时的优先级排序。比如你拿到一块FPGA板子物理层你基本不需要动因为FPGA的比特流结构是公开可查的你直接跳到逻辑层和系统层就行。但如果你拿到的是一颗定制的ASIC物理层和电气层就是绕不过去的因为你连引脚定义都不知道。TCHES的综述里通常会强调这种“按需选择层次”的思路而不是鼓吹某一种万能方法。具体到手段物理层常用的是光学显微成像、扫描电子显微镜、聚焦离子束切割这些设备门槛高一般只在专业实验室里做。电气层常用的是逻辑分析仪、示波器、协议分析仪配合FPGA做自定义触发和采集。逻辑层常用的是比特流解析、网表提取、功能仿真工具链包括厂商提供的开发套件和第三方逆向工具。系统层常用的是固件提取、配置数据解析、动态调试有时候还需要自己写脚本做批量处理。我自己的经验是大部分实际项目根本不需要走到物理层。你遇到的绝大多数“逆向”需求其实是电气层和逻辑层的问题。比如一块工业控制板上的FPGA配置Flash被加密了你需要恢复出里面的逻辑功能或者一个老设备的通信协议没有文档你需要从波形里反推出帧格式。这些场景下FPGA和逻辑分析仪的组合就能解决八成以上的问题。2.2 为什么FPGA在逆向中越来越重要FPGA在IC逆向里的角色我把它总结为“万能适配器”。逆向过程中最头疼的事情之一是目标对象的接口协议千奇百怪而你手头的采集设备往往只支持标准协议。这时候FPGA的价值就体现出来了你可以用FPGA实现一个针对特定时序的采集前端把非标准信号转换成标准格式再送给上位机分析。举个例子我之前接触过一个项目目标设备用了一种类似SPI但时钟极性和相位都很奇怪的串行接口市面上没有现成的协议分析仪能直接解码。我的做法是用一块FPGA开发板把目标设备的时钟和数据线接到FPGA的IO上在FPGA内部写一个状态机按照猜测的时序去采样然后把采样结果通过UART送到电脑上。整个过程从搭硬件到出第一版解码结果大概花了一个下午。如果用纯软件方案或者通用仪器可能要折腾好几天。FPGA的另一个优势是实时性。有些逆向场景需要你在极短的时间窗口内完成信号采集和预处理比如抓取上电瞬间的配置过程。FPGA的并行处理能力让你可以在纳秒级的时间精度上做多通道同步采集这是普通微控制器做不到的。TCHES的综述里提到FPGA时通常会强调它在“协议仿真”和“激励生成”两方面的作用前者是听懂目标设备在说什么后者是让目标设备按照你的意图说话。2.3 LLM介入逆向的切入点与边界LLM在IC逆向里的应用目前最实在的切入点是“模式识别”和“代码理解”。逆向过程中会产生大量半结构化的数据比如反汇编出来的汇编代码、提取出来的网表片段、抓包得到的协议数据流。这些数据的特点是格式相对固定但语义不明确正好是LLM擅长的领域。我试过把一段从FPGA比特流里恢复出来的LUT配置数据整理成文本格式然后让LLM去推测这些LUT可能实现了什么逻辑功能。结果不算完美但它确实能给出一些有价值的猜测比如“这组LUT的输入输出关系看起来像是一个4位计数器”或者“这个模式重复出现可能是状态机的一部分”。这种猜测不能直接当作结论但可以作为下一步验证的方向省去了大量盲目尝试的时间。LLM的边界也很明显。它不擅长处理需要精确数值计算的任务比如时序分析、功耗估算它也不擅长处理高度依赖上下文的任务比如从一段残缺的网表里恢复出完整的模块层次。我的做法是把LLM当作一个“高级搜索引擎”和“代码解释器”用它来加速理解过程而不是用它来替代验证过程。TCHES的综述里对LLM的态度通常比较谨慎会强调“辅助”而非“替代”这个定位我觉得是准确的。3. 核心细节解析网表、比特流与协议恢复3.1 从比特流到网表FPGA逆向的关键路径FPGA逆向和ASIC逆向最大的区别在于FPGA的比特流是一个“半公开”的格式。厂商会公布比特流的文件结构但不会公布具体的配置位到逻辑资源的映射关系。这意味着你不能直接读比特流就知道里面是什么逻辑但你可以通过对比不同设计生成的比特流反推出部分映射关系。这个反推过程通常分三步。第一步是“差分分析”用同一个FPGA型号生成两个只有微小差异的设计比如一个加法器和一个减法器然后对比它们的比特流差异。差异的位置通常对应着实现差异的逻辑资源。第二步是“资源定位”通过大量差分样本建立起比特流位置和逻辑资源类型之间的对应关系比如哪些位对应LUT的输入、哪些位对应触发器的使能。第三步是“网表重建”根据定位结果把比特流翻译成门级网表然后再根据网表的连接关系推测更高层的功能。这个过程听起来很系统但实际操作中最大的坑是“比特流加密”。很多厂商的高端FPGA支持比特流加密你拿到的比特流是加密后的差分分析根本做不了。这时候要么走物理层去探针要么找其他漏洞比如利用配置接口的调试模式。TCHES的综述里会专门讨论比特流加密对逆向的影响以及目前有哪些已知的绕过思路但这些思路通常有很强的时效性厂商一打补丁就失效了。3.2 网表恢复后的功能识别LLM能帮上什么忙假设你已经成功从比特流恢复出了一个门级网表接下来的问题是这一堆与门、或门、触发器到底实现了什么功能传统做法是人工分析或者用一些基于图匹配的自动化工具。人工分析慢但准确自动化工具快但误报率高。LLM的介入点在这里就比较自然了。我试过的一个流程是先把网表按照连接关系切分成若干个子图每个子图对应一个可能的功能模块然后把子图的拓扑结构用文本描述出来比如“输入A和输入B经过一个与门输出连接到触发器的D端触发器的时钟来自输入C”最后让LLM根据这些描述推测模块功能。实测下来LLM对常见模块的识别准确率还不错比如计数器、移位寄存器、简单的状态机。但对于复杂模块比如带流水线的乘法器或者自定义的加密引擎LLM的推测就很不靠谱了。这里的关键是“人机配合”。LLM给出候选功能列表你根据经验筛选出最可能的几个然后用仿真或者实际测试去验证。这个流程比纯人工快比纯自动化准。TCHES的综述里提到LLM时通常会强调“可解释性”和“可验证性”因为逆向的结论必须经得起验证不能只是“看起来像”。3.3 协议恢复从波形到帧格式的逆向过程协议恢复是IC逆向里最常见也最实用的任务之一。你有一个设备它通过某种串行接口和外界通信但你没有协议文档。你需要从波形里反推出帧格式、波特率、校验方式、命令集。这个过程我做过很多次总结下来就是“先定帧、再定字段、最后定语义”。先定帧的意思是你要先找到数据包的边界。常用的方法是找空闲电平或者特定的同步头。比如UART的空闲是高电平起始位是低电平SPI的片选信号拉低表示一帧开始。找到边界后你就可以把连续的波形切分成一个个数据包。再定字段的意思是你要确定每个数据包里哪些位是地址、哪些位是数据、哪些位是校验。这一步通常需要你发送已知的激励观察响应通过对比来推断字段位置。最后定语义的意思是你要搞清楚每个命令码对应什么操作比如0x01是读寄存器、0x02是写寄存器。FPGA在这个过程中的作用是“可编程的激励源和采集器”。你可以用FPGA产生精确的时序激励同时采集目标设备的响应然后把两者对齐后送给上位机分析。我常用的一个技巧是在FPGA内部做一个简单的状态机让它自动发送一系列命令码并记录每个命令码对应的响应。这样一轮下来你就能得到一张命令码和响应的对照表大大加速语义推断。4. 实操过程从零搭建一个FPGA辅助逆向平台4.1 硬件选型与连接方式搭建一个FPGA辅助逆向平台硬件选型不需要追求高端。我自己的配置是一块中低端FPGA开发板带足够的IO和至少一路高速差分输入外加一个逻辑分析仪作为备份。FPGA开发板的选择上我倾向于选IO电平可配置的型号因为逆向对象的电平标准可能是1.8V、2.5V、3.3V甚至更低如果FPGA的IO电平固定你就需要额外的电平转换电路增加复杂度和故障点。连接方式上最稳妥的是用飞线把目标设备的信号引到FPGA的IO上。飞线长度尽量短尤其是高速信号否则信号完整性会出问题。如果目标设备的信号是差分对比如LVDS你需要确认FPGA的差分输入是否支持你需要的电平标准。我踩过的一个坑是某款FPGA的LVDS输入要求共模电压在特定范围内而目标设备的共模电压偏离了这个范围导致接收到的数据全是错的。后来加了一个简单的电阻分压网络才解决。供电方面FPGA开发板和目标设备最好独立供电避免相互干扰。如果必须共地确保地线足够粗并且尽量缩短地线长度。我在早期项目中曾经因为地线太长引入了大量噪声导致采集到的波形完全不可用排查了很久才发现是接地问题。4.2 采集逻辑的设计与参数计算采集逻辑的设计取决于你要抓什么信号。如果是低速串行信号比如UART或者I2C你可以用简单的过采样加边沿检测。过采样率的选择有个经验公式采样率至少是信号最高频率的4倍实际中我通常用8到16倍。比如你要抓一个波特率115200的UART信号最高频率大概是115200Hz采样率用1MHz就足够了。如果是高速信号比如DDR或者高速ADC你就需要用到FPGA内部的专用资源比如ISERDES或者IDELAY。这些资源的使用需要参考厂商的文档参数计算也比较复杂。以DDR读写为例你需要考虑时钟和数据之间的相位关系通常需要用IDELAY做动态对齐。我做过的一个项目中DDR数据速率是800Mbps我用IDELAY以78ps的步进扫描找到了最佳采样点。这个扫描过程可以自动化写一个状态机让IDELAY逐步增加同时统计误码率误码率最低的点就是最佳采样点。采集深度也是一个需要权衡的参数。FPGA内部的Block RAM容量有限如果你要抓很长时间的数据就需要用流模式把数据实时传到上位机或者用压缩算法减少数据量。我通常的做法是先用小深度抓一段看看信号特征确定触发条件后再用大深度抓完整的数据包。4.3 上位机分析流程与脚本化处理FPGA采集到的数据最终要送到上位机做分析。我习惯用Python做上位机处理因为生态丰富各种解析库都有。基本流程是FPGA通过UART或者USB把数据传到电脑Python脚本接收数据后先做格式转换把原始采样点转换成时间序列然后做协议解码最后输出结构化的结果。协议解码这部分我通常会写一个可配置的解码器把帧格式、波特率、校验方式作为参数传进去。这样同一个解码器可以复用到不同的项目上。解码结果我一般输出成CSV或者JSON格式方便后续用Excel或者数据库做进一步分析。如果数据量很大我会用Pandas做批量处理把解码、统计、可视化串成一条流水线。脚本化处理的一个好处是可复现。逆向过程中经常需要反复调整参数如果每次都是手工操作很容易出错而且效率低。把整个流程脚本化之后你只需要改几个参数就能重新跑一遍大大加快了迭代速度。我现在的习惯是任何一个逆向项目第一件事就是搭一个脚本框架把数据采集、解码、分析、可视化都串起来后面所有的工作都在这个框架里做。5. 常见问题与排查技巧实录5.1 采集数据全是噪声或者全为零这是最常见的问题原因通常有三个接线错误、电平不匹配、时钟问题。接线错误包括信号线接反、地线没接、飞线断裂。电平不匹配包括FPGA的IO电平和目标设备不兼容比如目标设备是1.8V而FPGA的IO配置成了3.3V。时钟问题包括采样时钟频率不对、时钟相位不对、时钟抖动太大。排查顺序我建议从最简单开始先用万用表确认接线连通性再用示波器看目标设备的信号是否正常最后检查FPGA的配置。如果目标设备的信号正常但FPGA采集不到大概率是电平或者时钟问题。我遇到过一次目标设备的信号幅度只有1.2V而FPGA的IO阈值是1.5V导致采集到的数据全是零。后来在信号线上加了一个简单的电平转换芯片才解决。5.2 协议解码结果不稳定或者时好时坏解码结果不稳定通常意味着采样点没有对准。对于同步协议你需要确保采样时钟的相位对准数据有效窗口的中间。对于异步协议你需要确保波特率估计准确。我常用的方法是“扫描法”把采样相位或者波特率作为变量逐步扫描统计每个取值下的解码成功率成功率最高的取值就是最佳值。另一个可能的原因是信号完整性。如果飞线太长或者没有做阻抗匹配信号边沿会变缓导致采样点判断错误。这种情况下缩短飞线或者加一个串联电阻通常能改善。我在一个高速SPI项目中遇到过类似问题SPI时钟频率是50MHz飞线长度10厘米解码成功率只有70%。后来把飞线缩短到3厘米成功率直接到了99%以上。5.3 网表恢复后功能识别准确率低功能识别准确率低的原因通常是网表本身不完整或者有错误。比特流恢复出来的网表往往缺少一些优化信息比如LUT的输入映射可能不是最优的导致网表结构和你预期的功能模块对不上。这时候不要强行用自动化工具去匹配而是先人工检查几个关键节点确认网表的基本结构是否正确。LLM在这个环节的作用是提供候选而不是给出答案。我通常会把网表按功能区域切分成小块每块单独让LLM分析然后把结果汇总后人工筛选。如果某个模块LLM给出了多个候选功能我会用仿真去验证每个候选看哪个候选的行为和实际网表一致。这个过程比较耗时但比盲目猜测靠谱得多。5.4 常见问题速查表问题现象可能原因排查方法解决思路采集数据全零接线错误、电平不匹配万用表测通断、示波器看信号重新接线、加电平转换采集数据全噪声地线干扰、时钟抖动检查地线连接、测量时钟质量缩短地线、加滤波电容解码结果不稳定采样相位不对、波特率不准扫描相位和波特率自动扫描找最佳值网表功能识别错误网表不完整、LLM误判人工检查关键节点、仿真验证分块分析、多候选验证高速信号误码率高阻抗不匹配、采样点偏移检查飞线长度、扫描IDELAY缩短飞线、动态对齐6. 一些踩坑之后的个人体会IC逆向这件事工具和方法论固然重要但真正决定效率的往往是“先做什么、后做什么”的判断。我见过太多人一上来就追求最先进的设备或者最复杂的算法结果在基础问题上卡了很久。实际上大部分逆向任务用一块普通的FPGA开发板加一个逻辑分析仪就能解决关键是你对目标对象的理解程度和你的排查思路是否清晰。FPGA在逆向中的价值我觉得被低估了。很多人把FPGA当作“可编程逻辑器件”但在逆向场景下它更像是一个“万能接口适配器”和“实时信号处理器”。你可以用它来模拟目标设备的通信对端也可以用它来产生精确的激励信号还可以用它来做实时的数据预处理。这些能力组合起来能覆盖逆向过程中很大一部分需求。LLM在逆向中的价值我觉得被高估了。它确实能加速一些模式识别和代码理解的工作但它不能替代验证。逆向的结论必须经得起实测LLM给出的任何推测都只是起点不是终点。我现在的做法是把LLM当作一个“头脑风暴伙伴”用它来生成候选方案然后用传统方法去验证。这个定位让我既能享受LLM带来的效率提升又不会陷入“看起来对但实际错”的陷阱。最后分享一个小技巧在开始任何逆向项目之前先花半个小时把目标设备的“正常行为”记录下来。比如它的上电时序、空闲状态下的引脚电平、正常通信时的波形特征。这些基线数据在你后续排查问题时非常有用因为你可以通过对比基线快速判断异常是出在目标设备还是出在你的采集系统。这个习惯帮我省下了大量排查时间尤其是在面对多个变量同时变化的时候。