静态 vs 动态，请先阅读。 有必要在一开始就明确_动态_分析与_静态_分析之间的界线：本工具完全通过静态分析进行排名。 它直接从二进制文件中读取编译后的 MIDL / NDR 结构，并且从不执行任何东西。
Windows RPC 攻击面的静态分类工具。 将其指向一个包含 PE 二进制文件的文件夹；它会找出每个注册了 RPC 服务器的文件，直接从编译后的 MIDL 结构中恢复每个接口的 NDR 方法签名、传输绑定和注册标志，然后按可达性 × 危险性对每个接口进行排名，并为每个分数附带一份完整的算术回执，以便你可以手动核对计算过程。
现有的 RPC 工具可以轻松恢复接口的方法签名及其注册标志。但没有一个工具能将这两者结合起来，回答那个真正决定你时间分配的问题：既然我可以到达这个接口，并且考虑到其方法接受什么输入，与机器上其他所有东西相比，我应该多紧急地检查它？ 这正是本工具所填补的空白。
筛选 目标文件夹，使 Ghidra 只自动分析真正注册了 RPC 服务器的二进制文件（它们导入 rpcrt4.dll 并调用某个 RpcServerRegisterIf\* API）。在 System32 上，这可能意味着一个下午与一周之间的差别。
提取 每个接口：UUID、RPC_SERVER_INTERFACE / MIDL_SERVER_INFO 链、权威的 DispatchTableCount、每个方法的 opnum + 参数方向 + 解码后的 NDR 操作码、注册标志（R9）、安全回调（“bouncer”）是否存在、安全描述符（尽力恢复），以及端点 / 传输绑定。
排名 在两条独立轴上对每个干净接口进行评分，并将它们相乘为一个 0-100 的综合得分，划分为 Critical / High / Moderate / Low 四个等级。
自我解释：每个分数都附带一条回执字符串，列出各个组成部分以及得出最终数值的算术过程。
target dir --(pefile filter) --> only RPC-registering PEs
--(Ghidra headless auto-analysis) --> analyzed program DB
--(extract_rpc_interfaces.py script) --> interfaces + NDR + flags + endpoints
--(two-axis AHP ranking engine) --> ranked interfaces + receipts
--> single JSON report
零符号依赖： 本引擎的一个关键技术差异点是，它完全不需要调试符号即可工作。通过以编程方式遍历调度表并直接从内存解析原始 NDR（Network Data Representation）字节码和编译后的 MIDL 结构，该工具绕过了对 Microsoft 的 .pdb 文件或实时端点映射器查询的需求。这保证了引擎能够开箱即用地处理去符号的生产环境 System32 二进制文件，与它们出厂时完全一致。
Ghidra 11.x（使用自带的 support/analyzeHeadless）。PATH 中需要 JDK 17+。
驱动端需要 Python 3.8+，并安装 pefile。
提取脚本在 Ghidra 自带的 Jython 2.7 下运行——无第三方导入，无需安装任何东西。
目标：Windows x64 PE 文件。分析本身与操作系统无关（Ghidra 是跨平台的），因此你不必在 Windows 上运行它。
git clone https://github.com/talha-nazeef-ahmed/RPC-Triage
cd RPC-Triage/
python -m pip install -r requirements.txt # just pefile
requirements.txt：pefile>=2023.2.7
所有操作都由 orchestrator.py 驱动：它会为你完成筛选、导入、分析和运行提取脚本。
python orchestrator.py \
-t \"C:\Windows\System32\" \
-g \"C:\ghidra_12.1.2_PUBLIC\" \
-s \".\extract_rpc_interfaces.py\" \
-o \".\out\report.json\" \
--stagedir \".\out\staged\" \
--projdir \".\out\ghidra_proj\" \
--projname RPC_Atlas
首次运行 vs 重新运行（重要）。 首次运行执行较慢的部分：筛选、导入匹配的二进制文件、运行完整自动分析，然后在 --projdir 中写入一个 .analysisComplete 标记。之后每次针对同一项目的运行都会跳过导入/分析（-process -noanalysis），直接对已分析的程序重新运行脚本。因此，分析 System32 是一次性成本，之后的迭代输出会很便宜。若分析被中断，则不会写入该标记，并会删除不完整的项目（.rep / .gpr），然后重新开始。
一个 JSON 文件：一个二进制文件列表，每个二进制文件带有一个 Interfaces 数组。本仓库的 output/FullBatchRun.json 中包含一次对 System32 的完整运行结果；这是原始、未经整理的输出，因此你可以看到该工具在大规模情况下的确切产出。每个接口包含：
标签；数据质量门禁：
Clean：正常恢复；按常规参与排名。
Needs-Review：已排名，但调度表遍历超出了存储的计数（通常是结尾的 thunk 块）。分数是真实的，但带有 [Provisional]；在引用它之前请核实方法数量。
Diagnostics / Diagnostics (2)：该行是提取产物（错误识别为 UUID 的 ASCII 字符串和/或损坏的 MIDL 指针）。不参与评分（Rank: N/A）。这些条目被有意保留：它们反映工具自身的运行状况，而不是攻击面。
关于 FLAG: Walked X != Stored Y 的说明。存储的 DispatchTableCount 是权威值，也是每个分数所使用的值。遍历计数是独立的可执行性交叉检查；当两者不一致时（通常为整齐的 2 倍关系），该接口会被标记为 Needs-Review，以便你知道需要人工检查。它绝不会悄悄改变分数。
这部分让分数具有可论证性：
Moderate/35 | Gate:35 [ncacn_np:41, MultiEndpointBonus:15, HasBouncer:-46, BouncerIsNotCaching:25] | Surface:100 [HasBogusStruct:1x(opnums 5):[in]:61, HasCallerSizedBuffer:5x(opnums 0,6,11):[in]:49, InPtrs:6:18, Count:12:6 -> raw:134 [capped to 100] * 1.0 -> 100] | (35 * 100) / 100 = 35 [Provisional]
从左到右解读：
Moderate/35：等级与综合得分。
Gate:35 [...]：可达性轴。从传输基础分（ncacn_np:41，命名管道）开始，然后列出每个注册修饰项及其带符号的贡献值：MultiEndpointBonus:15（在多个传输上注册）、HasBouncer:-46（存在安全回调，这会降低可达性）、BouncerIsNotCaching:+25。求和后钳制在 [5,100] 之间 -> 35。
Surface:100 [...]：危险性轴。每个触发的信号格式为 Name:count x(opnums):direction:weight，例如 HasBogusStruct 在 1 个参数（opnums 5）上触发，其权重为 61。然后是基于计数的贡献：InPtrs:6:18 = 6 个调用者可控的入指针，贡献 +18；Count:12:6 = 12 个方法，贡献 +6。raw:134 是封顶前的总和，[capped to 100] 表示钳制到 100， 是置信度乘数（当签名不确定时会降至 0.5）；最终 Surface 为 。
第二个示例展示了钳制效果和低置信度折扣：
Low/3 | Gate:5 [Dynamic / epmapper:29, LocalCallOnly:-100, SecureOnly:-65, HasBouncer:-46, BouncerIsNotCaching:25] | Surface:50 [... -> raw:140 [capped to 100] * 0.5 -> 50] | (5 * 50) / 100 = 3
仅 LocalCallOnly:-100 一项就将门控分数压到零以下，因此其被钳制在下限 5；签名不确定，所以 Surface 减半（* 0.5）；综合得分落在 3。危险的输入空间，但实际上不可达 -> 正确地被降级处理。
Critical >= 75、High >= 50、Moderate >= 25，其余为 Low（无论门控分数如何，未恢复出任何攻击面的接口都归为 Low）。阈值基于综合得分；其背后的模型位于 docs/Surface_Scoring_Methadology.md。
所有三个权重表（传输基础分、门控修饰项、危险信号）都通过层次分析法（Analytic Hierarchy Process）推导而来；包括两两比较、几何平均权重和实测一致性比率。完整的推导过程、矩阵、一致性数值和手工演算笔记见 docs/Surface_Scoring_Methadology.md。
为了确保提取结果不是自说自话，本工具恢复出的接口与一个独立的、成熟的 RPC IDL 提取器（James Forshaw 的 NtObjectManager 中的 RpcServer 解析器）在同一批二进制文件上进行了交叉核对。lsass、samsrv 和 winlogon 的参考转储位于 validation/，完整演练见 validation/VALIDATION.md。将其中任何一个与 output/FullBatchRun.json 中对应的二进制文件进行比较：接口 UUID、方法/opnum 数量和每个参数的方向都能对上（例如，winlogon 的 12E65DD8-... 接口在两个输出中都显示有五个方法：Proc0-Proc4）。参考工具止步于恢复 IDL；本工具则利用同样恢复出的攻击面，并在此基础上添加上可达性 × 危险性排名。与该项目无任何关联，它仅被用作独立的真实性校验。
仅静态。 不会调用任何目标。可达性是从注册信息推断的，而非运行时行为。
Needs-Review 的分数是临时的（provisional），直到人工核实方法数量为止。
此工具是我正在进行的 ALPC/RPC 和 Windows 内部机制研究的一部分。我将在不久的将来发布更多发现，并推出配套工具。如果你觉得它有用，可以考虑在 GitHub 上关注我，或关注我的以下社交媒体账号，以便收到未来发布的动态。
这是一个用于在你自己拥有的系统上进行漏洞研究的静态分类/映射工具。它报告的是_攻击面_，而不是漏洞。如果你在它所标出的接口中发现了任何问题，在公开任何细节之前，应先通过协调披露流程（MSRC）进行报告。
MIT
| 参数 | 含义 |
|---|
-t / --target | 要扫描的二进制文件文件夹 |
-g / --ghidra | Ghidra 安装文件夹（包含 support/analyzeHeadless 的那个） |
-s / --script | extract_rpc_interfaces.py 的路径 |
-o / --output | 要写入的 JSON 报告路径 |
--stagedir | 筛选出的 RPC 二进制文件被复制到的文件夹（保留） |
--projdir | 持久化 Ghidra 项目所在的文件夹 |
--projname | Ghidra 项目名称（例如 RPC_Atlas） |
| 字段 | 含义 |
|---|
CallSite | RpcServerRegisterIf\* 调用的地址 |
Tag / TagDesc | 数据质量分类（见下文） |
Rank | \"{Tier}/{Composite}\"，例如 Critical/91 |
RankDetail | 完整评分回执（见下文） |
UUID | 接口 UUID |
InterfaceAddress / DispatchAddress | 恢复出的结构体地址 |
FunctionsCount | 权威的已存储方法数量；可能带有 (FLAG: Walked X != Stored Y) |
Endpoints | 传输 / 端点绑定 |
Security | HasBouncer、SecurityDescriptor、SecureOnly、LocalCallOnly |
Methods | 每个 opnum 的参数列表及解码后的 NDR 操作码 |
* 1.0(35 * 100) / 100 = 35 [Provisional]：综合得分 = Gate × Surface / 100。可达性和危险性相乘而非取平均，因为危险只有在可达时才有意义：一个你无法触及但极具危险性的接口绝不能排到最上面。末尾的 [Provisional] 标记警告：动态内存遍历与存储的方法数量略有出入，这意味着需要人工核实边界。