标题: 寡妇王为什么要跟微软符号服务器过不去
创建: 2020-11-17 17:35
更新:
链接: http://scz.617.cn:8/windows/202011171735.txt
之前听云海说微软符号服务器被组织处理了,搞得他只好挂代理下符号文件。当时听个响,没在意,毕竟不搞Windows很久了。最近要用cdb,ntdll.pdb都拖不回来,慌了。
在debugger.chm中看到环境变量:
set _NT_SYMBOL_PROXY=<ip>:<port>
set _NT_SYMBOL_PROXY=http://<ip>:<port>
这种好像只能指定HTTP代理,不支持想像中的语法:
set _NT_SYMBOL_PROXY=socks5://<ip>:<port>
如果一定要用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-cacheHTTP/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跟一下转向。
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 GMTHTTP/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
...
挂着加密代理可以取回PDB,不挂则取不回,应该是"vsblobprodscussu5shard60.blob.core.windows.net"
被组织处理了。
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"
提前在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
...
其他办法不再一一示例,最后拼出"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的套路,绝大多数情况下无此必要。
疯狂的话就这样干:
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自带工具。
过去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中应该有相应项,懒得测。