IC逆向工程实战：从FPGA bitstream到netlist的LLM辅助解析

1. 从TCHES 2026的IC逆向综述说起为什么这个方向突然又热了如果你这两年一直在做芯片安全、硬件可信或者EDA工具链相关的工作应该能明显感觉到一个变化IC逆向Integrated Circuit Reverse Engineering这个曾经偏小众、偏学术的方向正在被越来越多的人重新拿出来讨论。TCHES 2026收录的这篇IC逆向综述某种程度上就是这个趋势的一个信号——它不是在讲某一个具体的攻击手法而是在系统性地梳理整个领域的方法论、工具链和未解难题。我自己第一次接触IC逆向是在做FPGA上的IP保护验证时当时的需求很简单确认第三方交付的bitstream里有没有夹带额外的逻辑。结果一上手才发现这件事远比想象中复杂。你拿到的可能是一个已经烧录好的FPGA配置文件也可能是一块封装好的芯片甚至只是一张die photo。从这些不同形态的输入出发逆向的路径、工具、难度完全不一样。这篇综述的价值在于它把IC逆向拆成了几个清晰的层次网表级netlist逆向、门级逆向、晶体管级逆向、以及物理版图逆向。每个层次的输入输出、所需工具、精度要求都不同。而最近LLM的介入又给这个领域带来了新的变量——不是说LLM能直接帮你把bitstream翻译成RTL而是它在模式识别、文档理解、脚本生成这些环节上确实能显著降低逆向工程师的重复劳动。关键词里出现的FPGA、netlist、LLM其实正好对应了当前IC逆向的三个热点FPGA作为可重构平台在逆向验证中的角色、netlist作为逆向核心中间表示的解析难度、以及LLM在逆向流程自动化中的潜在切入点。这篇文章我就围绕这三个点结合我自己在FPGA开发和硬件安全验证中的实际经验把IC逆向这件事从“综述”落到“可操作”的层面。适合谁看如果你是从FPGA开发转过来的想了解硬件安全方向或者你是做芯片验证的需要理解逆向工程的基本逻辑再或者你只是对“怎么从一块芯片里把电路扒出来”这件事好奇那这篇内容应该能给你一个比较实在的入口。2. IC逆向的四个层次从bitstream到晶体管每一步到底在做什么2.1 网表级逆向最接近软件逆向的层次网表级逆向是IC逆向里门槛最低、也最容易被误解的一个层次。很多人以为拿到netlist就等于拿到了电路的全部信息实际上netlist只是一个“连接关系”的描述它告诉你哪些门连到了哪些门但不告诉你这些门在物理上怎么布局、时序怎么收敛、功耗怎么分布。在FPGA场景下netlist逆向的典型输入是一个已经综合并实现后的设计文件比如Xilinx的.dcp或者Intel的.qsf配合.sof。如果你拿到的是bitstream那第一步是把它还原成netlist。这个过程在学术界叫bitstream reverse engineering对于较老的FPGA系列比如Xilinx 7系列已经有比较成熟的开源工具链可以做到部分还原。但对于更新的系列厂商的加密和混淆手段越来越强纯靠开源工具基本走不通。我自己在实际项目里做过一次FPGA netlist的逆向验证目标是确认一个第三方IP里有没有未声明的计数器逻辑。当时拿到的是一份综合后的EDIF网表工具用的是开源的yosys配合edif2verilog。整个流程大概是# 将EDIF网表转换为Verilog RTL edif2verilog input.edf output.v # 用yosys进行逻辑优化和层次化分析 yosys -p read_verilog output.v; hierarchy -top top; proc; opt; write_verilog cleaned.v但这里有个坑EDIF网表里的实例名往往是工具自动生成的比如U1234、n_5678你根本不知道哪个是计数器、哪个是状态机。这时候就需要结合功能聚类的方法把逻辑上相关的门归到一起再根据连接模式猜测功能。比如一个典型的计数器会有一组触发器共享同一个时钟并且触发器的输出会反馈到加法逻辑里。这种模式识别以前靠手写脚本现在LLM可以帮上忙——你把网表的结构化描述喂给LLM让它帮你标注可能的模块功能准确率虽然不能到100%但能省掉大量初筛时间。注意网表级逆向的合法性边界非常明确。你只能对自己拥有的、或者明确授权允许逆向的器件和设计进行操作。未经授权的逆向在很多国家和地区都是违法的这一点没有任何模糊空间。2.2 门级逆向当netlist变成标准单元门级逆向和网表级逆向的区别在于门级逆向的输入是标准单元库映射后的网表也就是说你看到的不是AND2、OR3这种通用门而是NAND2_X1、INV_X4这种具体工艺库里的单元。这个层次的逆向通常发生在你拿到了一个已经完成物理实现的芯片但还没有做版图提取的阶段。门级逆向的核心任务是从标准单元网表中恢复出功能模块。这比网表级逆向难的地方在于标准单元库里的单元种类可能上百种而且很多单元的功能是复合的比如OAI21或-与-非这种你光看名字不一定能立刻反应过来它的逻辑功能。更麻烦的是综合工具在映射的时候会做各种优化原本清晰的模块边界可能被拆得七零八落。我在一次学术合作中接触过一个案例从一颗老式微控制器的门级网表中恢复出它的指令译码器。当时用的方法是基于图神经网络的模块识别——把网表转成图结构节点是标准单元边是连接关系然后用训练好的GNN模型去预测每个节点属于哪个功能模块。这个方法在ISCAS基准电路上能到85%以上的准确率但在真实芯片上因为工艺库差异准确率会掉到60%左右。这里LLM的切入点比较有意思。LLM不擅长直接处理图结构但它擅长处理文本化的结构描述。你可以把网表的连接关系转成一种类似自然语言的描述比如“单元A的输出连接到单元B的输入单元B是一个二输入与非门它的另一个输入来自单元C”然后让LLM去推断这个局部结构的功能。实测下来对于小规模的局部结构5到10个单元LLM的推断准确率相当可观但规模一大就不行了因为上下文长度和推理深度都有限制。2.3 晶体管级逆向看到的是硅不是逻辑晶体管级逆向是IC逆向里最硬核的部分。到了这个层次你面对的已经不是逻辑门了而是晶体管、电阻、电容这些物理器件。输入通常是一张高倍放大的die photo或者是一份从版图提取出来的SPICE网表。这个层次的核心挑战是器件识别和参数提取。从die photo里你需要识别出哪些区域是PMOS、哪些是NMOS、哪些是多晶硅栅、哪些是金属连线。这个过程在学术界叫layout extraction工业界有成熟的工具比如Synopsys的Hercules但这些工具需要你提供工艺文件而逆向场景下你往往没有。我自己没有直接做过晶体管级逆向但和做这方面研究的朋友聊过他们的实际流程是先用SEM或光学显微镜拍高分辨率图像然后用图像分割算法把不同层扩散区、多晶硅、金属1、金属2分开再根据设计规则推断器件边界。这个过程中LLM可以辅助的是工艺文档的理解和脚本生成——比如你有一份模糊的工艺说明LLM可以帮你整理成结构化的参数表或者帮你写图像处理的Python脚本。但晶体管级逆向的精度要求极高一个错误的器件识别可能导致整个网表的功能完全错误。所以这个层次目前还是以人工半自动工具为主LLM更多是辅助角色。2.4 物理版图逆向从图像到几何物理版图逆向和晶体管级逆向有重叠但侧重点不同。晶体管级逆向关注的是“这是什么器件”物理版图逆向关注的是“这些几何图形怎么组成器件”。在先进工艺节点下版图的复杂度呈指数级上升一个简单的反相器可能涉及十几层掩模每层的设计规则都不一样。这个层次的逆向通常用于工艺分析和知识产权取证。比如你怀疑某颗芯片抄袭了你的版图设计就需要做版图级的比对。这时候LLM能帮上的忙主要是设计规则检查DRC脚本的生成和调试——把自然语言描述的设计规则转成Calibre或ICV的规则文件这个任务LLM做得相当不错因为规则文件本质上是结构化的文本。3. FPGA在IC逆向中的双重角色既是靶子也是工具3.1 为什么FPGA成了逆向研究的热门靶子FPGA在IC逆向研究里的地位很特殊。一方面FPGA本身就是可编程器件它的配置数据bitstream直接决定了内部逻辑功能所以bitstream逆向成了一个独立的研究方向。另一方面FPGA又可以作为逆向验证的平台——你从某颗ASIC里逆向出来的网表可以放到FPGA上跑一遍看看功能对不对。bitstream逆向的难度取决于FPGA厂商的防护策略。早期的FPGA比如Xilinx Spartan-3系列bitstream格式已经被完全逆向出来了开源社区有完整的文档。但到了28nm以下厂商开始对bitstream进行加密和压缩逆向难度大幅上升。TCHES这篇综述里提到目前对先进FPGA bitstream的逆向主要还是靠侧信道分析和故障注入纯静态分析基本走不通。我在实际项目里用过的一种方法是基于差分分析的bitstream逆向。思路很简单你有一个已知功能的参考设计把它综合实现后得到bitstream A然后你修改设计里的某一个参数比如把计数器位宽从8改成16再综合实现得到bitstream B。对比A和B的差异就能定位到计数器对应的配置位。这个方法对于小规模设计很有效但设计一大差异位就太多了根本对不上。3.2 用FPGA做逆向验证的实操细节从ASIC或FPGA逆向出来的netlist最终是要验证功能正确性的。最直接的方法就是把它放到FPGA上跑。但这里有几个坑第一时钟和复位策略可能完全不同。逆向出来的netlist里时钟树往往是理想化的没有考虑实际的skew和jitter。你直接放到FPGA上可能因为时序不满足而跑不起来。我的做法是先用create_clock和set_clock_uncertainty给一个比较宽松的约束让工具先跑通再逐步收紧。第二IO标准要重新映射。逆向出来的网表里IO可能只是普通的输入输出端口但FPGA上的IO有LVCMOS、LVDS、SSTL等各种标准。你需要根据原芯片的IO特性在FPGA的约束文件里指定正确的IO标准。比如原芯片是1.8V LVCMOS你在FPGA上就要设成LVCMOS18。第三BRAM和DSP的推断。如果逆向出来的netlist里有大规模的存储或乘法逻辑直接映射到FPGA的LUT上会非常浪费资源。你需要手动把这些逻辑推断成BRAM或DSP块。Xilinx的Vivado有synth_design -ram_style block这样的选项但效果取决于原设计的代码风格。# 示例在Vivado中强制将存储推断为BRAM synth_design -top top_module -part xc7a100tcsg324-1 -ram_style block # 设置IO标准 set_property IOSTANDARD LVCMOS18 [get_ports {data_in[*]}] # 创建时钟约束 create_clock -period 10.000 -name sys_clk [get_ports clk]3.3 FPGA逆向中的LLM辅助从脚本生成到模式识别LLM在FPGA逆向里的应用目前我看到比较靠谱的有两个方向。一个是约束文件的生成和调试。FPGA开发里最烦人的事情之一就是写SDC约束尤其是当时序不收敛的时候你需要反复调整set_max_delay、set_false_path这些约束。LLM可以根据你的时序报告建议你加哪些约束、改哪些参数。我试过把Vivado的时序报告摘要喂给LLM让它给出约束修改建议大概有70%的建议是直接可用的剩下的需要微调。另一个是bitstream差异的模式分析。前面提到差分分析会产生大量差异位LLM可以帮你从这些差异位里找规律。比如你发现某一段配置位总是成组变化LLM可以推测这可能对应一个多位的参数比如数据位宽而不是多个独立的控制位。这个能力在人工分析时很依赖经验LLM相当于把一些经验模式固化了。但要注意LLM在FPGA逆向里的作用目前还是辅助不是替代。它不能帮你从零逆向一个bitstream但可以在你已经有了初步结果之后加速后续的分析和验证。4. Netlist解析的硬骨头为什么从连接关系恢复功能这么难4.1 Netlist的本质一张有向图但信息量远不止图Netlist在形式上就是一张有向图节点是门或触发器边是连线。但如果你只把它当图来处理会丢掉很多关键信息。比如位宽——一根线到底是一根信号还是一组总线在网表里总线通常被拆成多个独立的位你需要通过命名规则或者连接模式把它们重新组合起来。再比如时序——触发器之间的路径延迟决定了电路的最高频率但网表本身不包含延迟信息你需要结合工艺库才能算出来。我在解析一个逆向出来的netlist时遇到的最大问题是模块边界模糊。综合工具在做优化时会把一些小的组合逻辑吸收到触发器里或者把多个模块的逻辑合并到一起。结果就是你看到的网表是一大坨扁平的逻辑根本分不清哪里是ALU、哪里是寄存器堆。解决这个问题的常用方法是基于连接密度的聚类。模块内部的连接通常比模块之间的连接更密集所以你可以用图聚类算法比如Louvain算法把网表分成若干簇每个簇大概率对应一个功能模块。这个方法的准确率取决于设计的规整程度对于手工设计的电路效果不错但对于高度优化的自动综合结果效果会打折扣。4.2 从netlist到RTL逆向综合的可行性边界很多人问能不能直接从netlist生成可读的RTL代码答案是能但生成的RTL和原始RTL差距很大。这个任务在学术界叫reverse synthesis或者RTL reconstruction目前最好的工具也只能做到功能等价代码风格和可读性远远不如人工写的。原因在于综合是一个信息丢失的过程。原始RTL里的循环、条件分支、函数调用这些高级结构在综合后都变成了扁平的门级逻辑。逆向综合要做的是从门级逻辑里重新发现这些高级结构这是一个欠定问题——同一个门级网表可能对应多种不同的RTL写法。LLM在这个任务上有天然的优势因为它见过大量的RTL代码知道什么样的代码模式会综合成什么样的门级结构。我试过把一个小模块的netlist描述喂给LLM让它生成对应的Verilog代码结果生成的代码功能是对的但风格很“机器”——大量的assign语句和always (*)块没有清晰的模块划分。不过对于逆向验证来说功能对就够了可读性可以后续再优化。4.3 LLM在netlist理解中的实际表现能做什么不能做什么我拿一个实际的例子测试过LLM在netlist理解上的能力。输入是一个8位计数器的门级网表大概有50个标准单元。我把网表的连接关系转成文本描述然后问LLM“这个电路的功能是什么”LLM的回答是“这是一个计数器因为它有一组触发器共享同一个时钟信号并且触发器的输出通过加法逻辑反馈到输入端。”这个判断是正确的。但当我换成一个更复杂的例子——一个带有状态机的UART收发器——LLM就开始出错了。它能把触发器和组合逻辑分开但无法准确判断状态机的状态编码和转移条件。原因在于状态机的逻辑在综合后变得非常分散LLM很难从局部的连接模式推断出全局的状态转移。所以我的结论是LLM适合做netlist的局部模式识别和功能标注不适合做全局的架构恢复。在实际逆向流程里你可以用LLM来快速标注一些明显的结构计数器、移位寄存器、简单的FSM然后人工去分析剩下的复杂逻辑。5. 把LLM接进逆向流程哪些环节真的省力哪些是噱头5.1 文档理解和知识提取LLM最稳的落地场景IC逆向涉及大量的文档工作工艺手册、标准单元库说明、工具使用指南、之前的逆向报告。这些文档往往是PDF格式格式混乱有的还是扫描件。LLM在文档理解上的能力在这个场景下非常实用。我自己的做法是把工艺库的databook转成文本然后用LLM提取每个标准单元的功能描述、真值表、驱动能力等参数整理成结构化的表格。这个工作以前需要人工一条条录入现在LLM几分钟就能搞定准确率在95%以上。剩下的5%主要是格式特别奇怪的单元人工复核一下就行。另一个场景是逆向报告的自动生成。逆向过程中会产生大量的中间结果网表片段、功能推断、验证波形。LLM可以根据这些中间结果自动生成一份结构化的逆向报告草稿你只需要补充关键结论和证据链。这个功能对于团队协作特别有用因为逆向往往不是一个人从头做到尾中间交接的时候一份清晰的报告能省很多沟通成本。5.2 脚本生成和工具链粘合LLM的强项IC逆向的工具链非常碎片化有的工具输出EDIF有的输出Verilog有的输出SPICE格式之间需要各种转换脚本。写这些脚本本身不难但很繁琐而且容易出错。LLM在生成这类“胶水代码”上表现很好。比如你需要把一份自定义格式的网表转成标准Verilog你可以把输入格式的样例和输出格式的要求描述给LLM让它生成一个Python转换脚本。我试过几次生成的脚本基本能直接跑只需要改一下文件路径和几个边界条件。# LLM生成的网表格式转换脚本示例 import re def parse_custom_netlist(filepath): 解析自定义格式网表返回模块列表 modules [] with open(filepath, r) as f: for line in f: # 匹配类似 G1 NAND2 A B Y 的格式 match re.match(r(\w)\s(\w)\s(\w)\s(\w)\s(\w), line) if match: modules.append({ instance: match.group(1), cell_type: match.group(2), inputs: [match.group(3), match.group(4)], output: match.group(5) }) return modules def generate_verilog(modules, module_namereverse_netlist): 根据解析结果生成Verilog网表 lines [fmodule {module_name} (]; # ... 端口声明和实例化代码 return \n.join(lines)但要注意LLM生成的脚本一定要人工审查尤其是涉及文件读写和循环的地方。我遇到过LLM生成的脚本在遇到空行时崩溃的情况因为它在正则匹配时没有处理边界条件。5.3 模式识别和功能推断LLM的潜力与局限前面已经提到LLM在局部模式识别上表现不错但在全局架构恢复上力不从心。这里再补充一个实际案例。我拿一个逆向出来的SPI主控器网表做测试网表里有大概200个标准单元。我把网表按功能簇分成几块分别喂给LLM。对于时钟分频器那块LLM准确识别出了分频比和分频逻辑。对于移位寄存器那块LLM也识别出了移位方向和位宽。但对于状态机那块LLM给出的推断和实际功能有出入——它把状态机的一个中间状态误判成了复位状态。这个案例说明LLM在数据通路上的推断能力比较强因为数据通路的结构比较规整模式重复度高。但在控制逻辑上因为状态机的编码方式和转移条件千变万化LLM的推断准确率会明显下降。所以我的建议是把LLM用在数据通路的快速标注上控制逻辑还是靠人工分析或者传统的FSM提取算法。两者结合整体效率能提升不少。6. 逆向工程师的实操避坑清单从工具选型到法律边界6.1 工具选型开源工具够不够用IC逆向的工具链可以粗略分成三类开源工具、商业工具、自研脚本。开源工具里yosys用于逻辑综合和网表处理nextpnr用于FPGA布局布线magic和klayout用于版图处理ngspice用于电路仿真。这些工具对于学术研究和初步逆向够用但在处理大规模工业级设计时性能和精度都跟不上。商业工具里Synopsys的Hercules和IC Validator用于版图提取和DRCCadence的Innovus和Tempus用于物理设计和时序分析。这些工具功能强大但价格昂贵而且很多功能需要特定的license。对于个人研究者或者小团队我的建议是先用开源工具跑通流程遇到瓶颈再考虑商业工具。自研脚本是逆向工程师的核心竞争力。因为逆向场景千变万化没有哪个工具能覆盖所有需求。Python是写这类脚本的首选语言配合networkx做图分析、numpy做数值计算、matplotlib做可视化。LLM可以帮你快速生成脚本框架但核心算法还是得自己设计。6.2 常见坑网表解析中的命名混乱和位宽推断网表解析里最让人头疼的就是命名混乱。综合工具生成的实例名和网络名往往没有任何语义信息比如n_1234、U5678。你需要在解析阶段就建立一套命名规范把工具生成的名字映射成有意义的标识符。我的做法是先用脚本提取所有实例和网络的连接关系然后根据连接模式给它们打标签。比如一个实例的输出连接到多个触发器的时钟端那它大概率是时钟缓冲器可以命名为clk_buf_*。一个实例的输入来自多个触发器的输出输出又反馈到这些触发器的输入那它大概率是组合逻辑可以根据它的输入输出数量命名为comb_*。位宽推断是另一个坑。网表里的总线通常被拆成独立的位你需要根据连接关系把它们重新组合。常用的方法是基于命名前缀的聚类——如果多个网络的名字有相同的前缀比如data_0、data_1、data_2那它们大概率属于同一个总线。但综合工具不一定保留这种命名规律所以还需要结合连接模式来判断。6.3 法律和伦理边界什么能做什么绝对不能碰IC逆向的法律边界非常明确但很多人容易忽略。核心原则是你只能对你拥有或明确授权的硬件进行逆向。具体来说你自己设计的芯片你可以随意逆向。你购买的开发板或芯片如果厂商的许可协议允许逆向有些开源硬件允许你可以逆向。你受委托对某颗芯片进行安全评估并且有书面授权你可以在授权范围内逆向。除此之外任何未经授权的逆向都可能违反法律。我在实际工作中每次开始逆向之前都会确认三件事硬件的来源是否合法、授权范围是否明确、逆向结果的使用是否受限。这三件事缺一不可。尤其是第三点很多委托方只说了“你可以逆向”但没说“逆向结果能不能公开”这会导致后续的合规问题。提示如果你不确定某个逆向行为是否合法最安全的做法是咨询法律专业人士而不是自己猜测。硬件安全领域的法律风险比软件领域更高因为涉及物理器件和商业秘密。6.4 从逆向到防护逆向思维的正面价值最后说一个容易被忽略的点IC逆向不只是攻击手段它也是防护设计的基础。你只有知道逆向是怎么做的才能设计出抗逆向的电路。比如如果你知道差分分析可以定位bitstream里的关键配置位你就可以在设计中加入配置位混淆让不同配置位之间的差异变得不可区分。我在做FPGA IP保护时就借鉴了逆向里的差分分析方法来评估自己的防护方案。具体做法是生成多个功能相近但配置不同的bitstream然后用差分分析看能不能定位到关键逻辑。如果能定位到说明防护不够需要加强混淆。这个“以攻促防”的思路在实际项目中非常有效。TCHES这篇综述里也提到了类似的观点逆向和防护是一体两面的做逆向研究的人往往也是最好的防护设计者。所以如果你对硬件安全感兴趣不要只盯着攻击手法也要思考怎么把这些知识转化成防护方案。