标题: 寡妇王为什么要跟微软符号服务器过不去 创建: 2020-11-17 17:35 更新: 2022-07-21 09:57 链接: https://scz.617.cn/windows/202011171735.txt 之前听云海说微软符号服务器被组织处理了，搞得他只好挂代理下符号文件。当时听 个响，没在意，毕竟不搞Windows很久了。最近要用cdb，ntdll.pdb都拖不回来，慌 了。 在debugger.chm中看到环境变量: set _NT_SYMBOL_PROXY=: set _NT_SYMBOL_PROXY=http://: 这种好像只能指定HTTP代理，不支持想像中的语法: set _NT_SYMBOL_PROXY=socks5://: 如果一定要用SOCKS5代理，上Proxifier可能是最省事的办法。有工具可以在SOCKS5、 HTTP代理之间互相转换，比如privoxy，非要那么干也成。 接下来看看到底发生了什么。设有: set _NT_SYMBOL_PATH=srv*x:\sym*http://msdl.microsoft.com/download/symbols 提前在Wireshark中捕捉"ip host 204.79.197.219"，这是"msdl.microsoft.com"解 析得到的IP。 执行如下命令: cdb.exe -noinh -snul -hd -o -xe ld:ntdll "C:\Windows\System32\mspaint.exe" 断下来时PDB文件并未下载成功，Wireshark中看到: -------------------------------------------------------------------------- GET /download/symbols/ntdll.pdb/1B97D8849C140AFE54A40E6ED4FB118B1/ntdll.pdb HTTP/1.1 Accept-Encoding: gzip X-TFS-FedAuthRedirect: Suppress User-Agent: Microsoft-Symbol-Server/10.1710.0.0 Host: msdl.microsoft.com Connection: Keep-Alive Cache-Control: no-cache HTTP/1.1 302 Found Cache-Control: no-store, no-cache, max-age=0 Location: https://vsblobprodscussu5shard60.blob.core.windows.net/b-4712e0edc5a240eabf23330d7df68e77/7AC458EFE0274B109CCD547267B1BBD9707826E4EEDBA0A15D8669330B0E53AC00.blob?sv=2019-02-02&sr=b&si=1&sig=GoX58V8riLdz13ZmjykVR7QVT1IpYCcVNWE1wW3lMnk%3D&spr=https&se=2020-11-18T14%3A28%3A50Z&rscl=x-e2eid-8b250a50-c3a54692-a1b2bcd9-bb885b32-session-2fd5c3c6-24e84a30-9ff512a9-bde6d996 X-Cache: TCP_MISS Server: Microsoft-HTTPAPI/2.0 ... Date: Tue, 17 Nov 2020 13:58:46 GMT Content-Length: 0 -------------------------------------------------------------------------- 有302转向，再用curl跟一下转向。 curl --ciphers DEFAULT --compressed -ksL -I http://msdl.microsoft.com/download/symbols/ntdll.pdb/1B97D8849C140AFE54A40E6ED4FB118B1/ntdll.pdb SoftICE时代的"Symbol Retriever"可以下载PDB；大概2005年初微软在服务端做过一 次改动，对获取PDB的HTTP请求检查User-Agent，必须类似上面那种形式；不知何时 起，这个限制又被取消了，现在用curl下载PDB不需要指定符合格式的User-Agent。 curl可以指定HTTP或SOCKS5代理，在WSL中执行: curl -x http://127.0.0.1:8000 --ciphers DEFAULT --compressed -ksL -I http://msdl.microsoft.com/download/symbols/ntdll.pdb/1B97D8849C140AFE54A40E6ED4FB118B1/ntdll.pdb curl -x socks5://127.0.0.1:8001 --ciphers DEFAULT --compressed -ksL -I http://msdl.microsoft.com/download/symbols/ntdll.pdb/1B97D8849C140AFE54A40E6ED4FB118B1/ntdll.pdb -------------------------------------------------------------------------- HTTP/1.1 302 Found Cache-Control: no-store, no-cache, max-age=0 Content-Length: 0 Location: https://vsblobprodscussu5shard60.blob.core.windows.net/b-4712e0edc5a240eabf23330d7df68e77/7AC458EFE0274B109CCD547267B1BBD9707826E4EEDBA0A15D8669330B0E53AC00.blob?sv=2019-02-02&sr=b&si=1&sig=RDrAC2qKb0S8u9fGePYD0%2FPPIoyeX42ChzEd7BNj6lc%3D&spr=https&se=2020-11-19T03%3A28%3A48Z&rscl=x-e2eid-862c5716-c43647f8-8c59043a-f60bfe46-session-5f28ea33-15294c4e-90e6df13-91a74790 X-Cache: TCP_MISS Server: Microsoft-HTTPAPI/2.0 ... Date: Wed, 18 Nov 2020 02:50:08 GMT HTTP/1.1 200 OK Content-Length: 1608704 Content-Type: application/octet-stream Content-Language: x-e2eid-862c5716-c43647f8-8c59043a-f60bfe46-session-5f28ea33-15294c4e-90e6df13-91a74790 ... Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0 ... -------------------------------------------------------------------------- curl -x http://127.0.0.1:8000 --ciphers DEFAULT --compressed -ksL -I "https://vsblobprodscussu5shard60.blob.core.windows.net/b-4712e0edc5a240eabf23330d7df68e77/7AC458EFE0274B109CCD547267B1BBD9707826E4EEDBA0A15D8669330B0E53AC00.blob?sv=2019-02-02&sr=b&si=1&sig=RDrAC2qKb0S8u9fGePYD0%2FPPIoyeX42ChzEd7BNj6lc%3D&spr=https&se=2020-11-19T03%3A28%3A48Z&rscl=x-e2eid-862c5716-c43647f8-8c59043a-f60bfe46-session-5f28ea33-15294c4e-90e6df13-91a74790" 挂着加密代理可以取回PDB，不挂则取不回，应该是"vsblobprodscussu5shard60.blob.core.windows.net" 被组织处理了。 提前在Wireshark中捕捉"ip host 104.214.40.16"，这是"vsblobprodscussu5shard60.blob.core.windows.net" 解析得到的IP。 执行如下命令: curl --ciphers DEFAULT --compressed -ksL -I "https://vsblobprodscussu5shard60.blob.core.windows.net/b-4712e0edc5a240eabf23330d7df68e77/7AC458EFE0274B109CCD547267B1BBD9707826E4EEDBA0A15D8669330B0E53AC00.blob?sv=2019-02-02&sr=b&si=1&sig=RDrAC2qKb0S8u9fGePYD0%2FPPIoyeX42ChzEd7BNj6lc%3D&spr=https&se=2020-11-19T03%3A28%3A48Z&rscl=x-e2eid-862c5716-c43647f8-8c59043a-f60bfe46-session-5f28ea33-15294c4e-90e6df13-91a74790" Wireshark中看到，发往104.214.40.16:443的SYN包刚一出去，鲜红的RST就打回来， 组织太粗暴了。从这个上下文看，寡妇王可能是误中副车，逆向工程环境真是太不友 好了，这还怎么建设社会主义网络强国啊，好痛心。 很久没有手工下过PDB，都到这儿了，重温一下。 $ dumpbin.exe /headers KernelBase.dll | find ".pdb" 1183946C cv 27 002609B8 25F9B8 Format: RSDS, {5FB214A5-33D3-CB12-7ADE-9F509D0EACAD}, 1, kernelbase.pdb 根据"{5FB214A5-33D3-CB12-7ADE-9F509D0EACAD}, 1"组装成"5FB214A533D3CB127ADE9F509D0EACAD1" Visual Studio中有dumpbin.exe，也可以用windbg自带的dbh.exe。 $ dbh.exe KernelBase.dll info ... CVData : kernelbase.pdb ... PdbSig70 : 0x5fb214a5, 0x33d3, 0xcb12, 0x7a, 0xde, 0x9f, 0x50, 0x9d, 0x0e, 0xac, 0xad PdbAge : 0x1 ... 在windbg提示符下有多种办法获取这种信息: 0:000> !lmi KernelBase Loaded Module Info: [kernelbase] Module: KERNELBASE ... Debug Data Dirs: Type Size VA Pointer CODEVIEW 27, 2609b8, 25f9b8 RSDS - GUID: {5FB214A5-33D3-CB12-7ADE-9F509D0EACAD} Age: 1, Pdb: kernelbase.pdb ... 0:000> !chksym ntdll ntdll.dll Timestamp: 1000A5B9 SizeOfImage: 1F8000 pdb: ntdll.pdb pdb sig: CDE75D03-9306-8342-03EB-D8D4E7D50369 age: 1 Loaded pdb is x:\sym\ntdll.pdb\CDE75D039306834203EBD8D4E7D503691\ntdll.pdb ntdll.pdb pdb sig: CDE75D03-9306-8342-03EB-D8D4E7D50369 age: 1 MATCH: ntdll.pdb and ntdll.dll 其他办法不再一一示例，最后拼出"5FB214A533D3CB127ADE9F509D0EACAD1"即可。注 意，Age字段不要漏了，不只是GUID字段。 $ curl -x http://127.0.0.1:8000 --ciphers DEFAULT --compressed -ksL -I http://msdl.microsoft.com/download/symbols/kernelbase.pdb/5FB214A533D3CB127ADE9F509D0EACAD1/kernelbase.pdb $ curl -x http://127.0.0.1:8000 --ciphers DEFAULT --compressed -ksL http://msdl.microsoft.com/download/symbols/kernelbase.pdb/5FB214A533D3CB127ADE9F509D0EACAD1/kernelbase.pdb -o kernelbase.pdb 用curl下回来的kernelbase.pdb放到此处即可: x:\sym\kernelbase.pdb\5FB214A533D3CB127ADE9F509D0EACAD1\kernelbase.pdb 这是纯手工下载PDB的套路，绝大多数情况下无此必要。但还真别说永远用不上，今 天我就碰上几个PDB死活不能自动下载成功，最后手工下载放进相应目录的。 疯狂的话就这样干: set _NT_SYMBOL_PROXY=127.0.0.1:8000 set _NT_SYMBOL_PATH=srv*x:\sym*http://msdl.microsoft.com/download/symbols symchk.exe /r /q C:\Windows\System32 symchk.exe是windbg自带工具。批量下载时有些可能失败，最好在"x:\sym\"中搜 "download"关键字，那些下载出错的文件名形如: X:\sym\PlayToManager.pdb\B2D670946FD45CA1BBF1A6B5F794A2941\download0F2F25838CCB44E9AA22EC4D6139671D.error 这种可以手工下载: http://msdl.microsoft.com/download/symbols/PlayToManager.pdb/B2D670946FD45CA1BBF1A6B5F794A2941/PlayToManager.pdb 过去IDA的pdb.cfg中有个PDBSYM_DOWNLOAD_PATH用于指定符号文件目录，但7.5.1版 的pdb.cfg发生变化: -------------------------------------------------------------------------- // Symbol search path // The _NT_SYMBOL_PATH environment variable overrides this setting. // If none of these variables is set then the default value will be used: // "SRV*CACHEDIR*http://msdl.microsoft.com/download/symbols" // where // CACHEDIR=%TEMP%\ida for Windows // CACHEDIR=$TMPDIR/ida or $TMP/ida or /tmp/ida for non-Windows OSes // //_NT_SYMBOL_PATH = "SRV*c:\\symbols*http://symbols.mozilla.org/firefox;SRV*c:\\symbols*http://msdl.microsoft.com/download/symbols"; -------------------------------------------------------------------------- 换句话说，新版IDA的符号文件目录完全采用windbg的设置。不知IDA认不认 _NT_SYMBOL_PROXY？估计不认，不然pdb.cfg中应该有相应项，懒得测。 Process Explorer自动认_NT_SYMBOL_PATH环境变量，但Process Monitor不会，只能 手工指定符号目录。记得给Process Explorer、Process Monitor指定windbg中新版 dbghelp.dll，不要用缺省的"C:\Windows\SYSTEM32\dbghelp.dll"；然后它们都认 _NT_SYMBOL_PROXY环境变量，查看调用栈回溯时会自动挂代理下载符号文件；基于这 个事实，最好在sysdm.cpl中设置全局环境变量。 直接在sysinternals工具中下载符号文件有潜在风险。假设正在看一些关键进程、线 程的调用栈回溯，如果因网络故障导致这个过程的GUI长时间失去响应，Win10可能判 定需要强制重启，开始收集信息，你都没机会正常关闭其他进程。关键进程都还不是 指smss.exe、lsass.exe、winlogon.exe这种，反正符号文件没就位前别瞎看调用栈 回溯，要么就别配置使用符号文件。 2020-11-27 17:26 小钻风 小钻风刚才跟我说，现在可以不挂代理下载微软符号了。用curl试了一下，尽管还是 有302转向，但寡妇王确实没有RST 104.214.40.16。不知是组织良心发现了，还是拦 截策略有优化？2020.11.17还在RST，我专门为此事灌了瓢水。 2020-12-15 11:32 scz 除了PDB文件，还可以从微软符号服务器下载PE文件，参 《MSDN系列(44)--从微软符号服务器下载PE文件》 https://scz.617.cn/windows/202112141154.txt