标题: 利用findrpc寻找RPC接口信息 创建: 2021-11-06 15:55 更新: 2023-06-19 13:44 链接: https://scz.617.cn/python/202111061555.txt 参看 《RpcView简介》 https://scz.617.cn/windows/202110270957.txt 就此，颜涛提到可以试试IDA插件findrpc。 https://github.com/lucasg/findrpc 这是个IDAPython插件，直接在IDA中Alt-F7加载，从binary中静态分析RPC相关数据 结构。若在Windows上用，依赖一个外部PE还可以得到IDL文件，此时findrpc可以当 成曾经的IDA插件mIDA的替代品。 RpcView已经非常优秀，为什么需要findrpc呢？findrpc作者提到，某些进程受PPL机 制(Protected Processes Light)保护，RpcView可能无法获取其RPC接口信息，此时 findrpc就派上用场了。另有一些进程可能不是后台驻留的，执行完就结束了，这种 无法用RpcView看。内核中也有RPC接口，RpcView无法用于内核。这几种场景都可以 静态分析二进制获取RPC接口信息。 findrpc与RpcView互为补充。 关于PPL，参看 The Evolution of Protected Processes Part 1: Pass-the-Hash Mitigations in Windows 8.1 - Alex Ionescu [2013-11-05] https://www.crowdstrike.com/blog/evolution-protected-processes-part-1-pass-hash-mitigations-windows-81/ 假设IDA分析来自LTSB Win10中的usermgr.dll(10.0.14393.4169)。下面举例说明 findrpc的使用。 Alt-F7加载findrpc.py，若顺利，会在三个窗口中显示逆向分析获取的信息。 1) Output窗口 MSDN_40\findrpc\1.jpg Output窗口以文本形式输出找到的RPC相关数据结构，比如这种 [findrpc] (+) rpc informations for IID : b18fbab6-56f8-4702-84e041053293a869 -stub_type: server -IID: b18fbab6-56f8-4702-84e041053293a869 -interface: 0x7fff7ee01010 -interpreter: 0x7fff7ee0c790 -stub_desc: 0x7fff7ee0caa0 -dispatch_table: 0x7fff7ee0c7d0 -syntax_info: [0x7fff7ee0c900,0x7fff7ee0c950] -transfer_syntax: None -func_table: 0x7fff7ee0c9a0 -proc_handlers : [0] 0x7fff7ed879a0 ... [31] 0x7fff7edd9310 可以看到IID、各远程过程地址，可以点击地址跳转过去查看。 2) "detected rpc structures"窗口 MSDN_40\findrpc\2.jpg "detected rpc structures"窗口将Output窗口的输出换个形式展现，给出具体结构 名及相应地址，比如 _RPC_SERVER_INTERFACE _MIDL_SERVER_INFO_ MIDL_STUBLESS_PROXY_INFO RPC_DISPATCH_TABLE _MIDL_STUB_DESC RPC_SYNTAX_IDENTIFIER _MIDL_SYNTAX_INFO 此处部分地址可点击后跳过去，Output窗口所有地址可点击。右键选中某结构，右键 菜单里有4种操作 MSDN_40\findrpc\3.jpg -------------------------------------------------------------------------- Apply type 相当于跳到结构所在地址，Alt-Q应用结构 Clear applied type Renamed applied type 在结构所在地址处出现名字，形如 _findrpc_b18fbab6_56f8_4702_84e041053293a869_rpc_dispatch_table 中间是IID，后缀表明结构是啥 MSDN_40\findrpc\4.jpg Renamed proc handlers 类似"Renamed applied type"的操作 -------------------------------------------------------------------------- 显然，若有PDB文件加持，就别用那两个Renamed操作，"Apply type"倒是可以用。 3) "FindRpc results"窗口 MSDN_40\findrpc\5.jpg "FindRpc results"窗口将Output窗口的输出换个形式展现，重点展现远程过程所在 地址。无法从此点击地址跳过去，只有Output窗口中的地址可以点击。右键选中某个 IID，右键菜单里有3种操作 MSDN_40\findrpc\6.jpg -------------------------------------------------------------------------- Generate stub (beta) 产生RPC所用桩码，比如 usermgr_b18fbab6-56f8-4702-84e041053293a869.h usermgr_b18fbab6-56f8-4702-84e041053293a869_s.c 看了一下，这些.h、.c没啥用，果然是beta功能 Generate json summary 将插件识别出的RPC信息以json形式导出，比如 usermgr_b18fbab6-56f8-4702-84e041053293a869.json Decomplie interface (only for Windows) 调用"decompile\DecompileInterface.exe"，解析上述json格式的数据，生成 IDL文件。相当于 "decompile\DecompileInterface.exe" usermgr_b18fbab6-56f8-4702-84e041053293a869.json MSDN_40\findrpc\7.jpg -------------------------------------------------------------------------- "Decomplie interface"功能只在Windows上有，因为要调外部PE文件。usermgr.dll 中某接口的IDL确实生成了，但findrpc作者在github上提供的三个示例，无一成功生 成IDL文件。findrpc作者提供的IDL示例中远程过程名应该是利用了PDB文件，我测试 没看到这效果，还是Proc*这种名字。用Process Monitor看，会找dbghelp.dll，一 般System32目录有，但没有symsrv.dll。从windbg中复制dbghelp.dll、symsrv.dll 到DecompileInterface.exe所在目录，会优先加载。DecompileInterface.exe是32位 PE，起初复制32位dbghelp.dll、symsrv.dll过去，发现虽然优先加载了，但转头又 去加载System32下的dbghelp.dll；后来复制64位dbghelp.dll过去，优先加载后不再 去找System32下的dbghelp.dll。但无论怎么穷折腾，IDL中仍然是Proc*，没有用上 符号信息，诡异。 github上的findrpc是2019年8月的，作者用的可能是"IDA 7.3+Python 2"，findrpc 无法直接用于"IDA 7.6.x+Python 3.9.x"。若非要在后一种环境中用，需要做两种移 植工作，首先是Python2到Python3的移植，其次是IDAPython 7.3到IDAPython 7.4及 更高版本的移植，都是有例可循的。 findrpc项目自带DecompileInterface.exe，作者有段介绍 DecompileInterface.exe is a custom loader for Forshaw's NdrParser.ReadFromRpcServerInterface which uses a json file exported from IDA instead of reading a remote process's memory. findrpc作者没有提供DecompileInterface.exe源码，2021.5.23有人在github上问作 者能不能提供DecompileInterface.exe源码，作者未回答。简单说一下这事。 https://github.com/0xd4d/dnSpy dnSpy是款强大的.NET反编译器，可以无源码调试.NET程序，可以从.NET PE导出 VS 2019工程。 MSDN_40\findrpc\8.jpg 若只是看看DecompileInterface.exe代码逻辑，dnSpy看看即可。若想与最新版 NtApiDotNet、Newtonsoft.Json的源码适配，就有些费劲。 用dnSpy看旧版NtApiDotNet.dll，原来有 public interface NtApiDotNet.Ndr.IMemoryReader public class NtApiDotNet.Win32.DbgHelpSymbolResolver 最新版里它们变了 internal interface NtApiDotNet.Utilities.Memory.IMemoryReader internal sealed partial class NtApiDotNet.Win32.Debugger.DbgHelpSymbolResolver 再比如，旧版NtApiDotNet.dll中RPC_SERVER_INTERFACE是public的，新版源码中它 是internal的。我能想到的办法是改NtApiDotNet源码，把internal改回public，不 知正经办法是啥？对现在的C#一窍不通，不深究了。 最后是 public DbgHelpSymbolResolver(NtProcess process, string dbghelp_path, string symbol_path) public DbgHelpSymbolResolver(NtProcess process, string dbghelp_path, string symbol_path, SymbolResolverFlags flags, TextWriter trace_writer) 旧版DbgHelpSymbolResolver构造函数只有3个形参，新版新增了2个形参。 除非确有刚需，否则没必要折腾DecompileInterface.exe可编译源码，findrpc自带 的那个就能用。