WinDbg调试（三）-- 空格引发的悬案
空格引发的悬案
1、描述现象:
在代码中有一段利用rmdir指令删除目录代码，但是有用户反馈一直删除失败，但是有没有看到错误的日志信息，正好有同事能复现,所以今天好好探究一番。
2、思考过程
很好奇的一点就是为什么有的环境就是正常。
首先想到2个问题:
①代码有没有执行。
②假如执行，有没有错误。
关于这两个问题都有个难点,我该如何下断点：
2.1、分析代码是否执行
删除目录的代码其实利用Python代码执行rmdir命令行，伪代码如下：
subprocess.Popen('rmdir /S /Q %s' % to_del, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
第一个问题下断点的难点在于，这段代码是在python中，同事的是发布版本没法直接调试python代码。
第二个难点就是在python环境中又起了一个进程，这个临时进程生命周期很短，如何attach上去呢。
如果找不到合适的断点后续分析使将无法下手。
起身走到阳台，思考几分钟，即是python的启动命令行，那么势必会创建新的进程。既如此那我可以利用WinDbg在CreateProcess函数下断点，
在创建进程时有两个版本的函数CreateProcessA和CreateProcessW，在不确定是哪个函数时，这两个函数我们的都要下断点。
此时我们配置下远程调试，连接到同事的电脑上。
输入如下指令：
bm kernelbase!CreateProcess?
0: 00007ffa`8d1a0870 @!"KERNELBASE!CreateProcessA"
1: 00007ffa`8d1a07f0 @!"KERNELBASE!CreateProcessW"
确认是这个思路，启动exe。挂上WinDbg下个断点来一个触发操作。
果然收到断点事件，查看下堆栈信息，调用的unicode版本的函数：
0:000> k# Child-SP RetAddr Call Site
00 00000015`b55fd5c8 00007ffa`8e28cef4 KERNELBASE!CreateProcessW
01 00000015`b55fd5d0 00007ff9`ff1a7fe0 KERNEL32!CreateProcessWStub+0x54
02 00000015`b55fd630 00007ff9`ff1a3004 xxx!_winapi_CreateProcess_impl+0x300
下面栈省略。。。
从MSDN官网文档再看这个出的原型：
creationResult = CreateProcess(NULL, // No module name (use command line)
cmdLine, // Command line
NULL, // Process handle not inheritable
NULL, // Thread handle not inheritable
FALSE, // Set handle inheritance to FALSE
NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE | CREATE_NEW_PROCESS_GROUP, // creation flags
NULL, // Use parent's environment block
NULL, // Use parent's starting directory
&startupInfo, // Pointer to STARTUPINFO structure
&processInformation); // Pointer to PROCESS_INFORMATION structure
第二个参数就是命令行的参数，值放在rdx寄存器中，执行如下命令：
0:000> du rdx0000028e`c4d2a310 "C:\windows\system32\cmd.exe /c ""
0000028e`c4d2a350 "rmdir /S /Q F:\work\project 中文\Loca"
0000028e`c4d2a390 "lData\BackUp\ProjectName001\wo"
0000028e`c4d2a3d0 "rkTD\workTD_backup_2024-08-30"
0000028e`c4d2a410 "-11-18-52 - 副本""
在这里下断点还有个小技巧，就是断点命中，让其自动打印参数：
0:000> bm kernelbase!CreateProcess? "du rdx"breakpoint 0 redefined
0: 00007ffa`8d1a0870 @!"KERNELBASE!CreateProcessA"
breakpoint 1 redefined
1: 00007ffa`8d1a07f0 @!"KERNELBASE!CreateProcessW"
找到命令行参数果然就是我要删除的目录。
到这里排除第一个疑问，其实代码是执行。
2.2、代码执行出错了？
接下来就是证明第2个问题：为什么执行行为不是我期待的。
这个进程是python启动，执行完进程就退出，我根本没有机会截停这个过程怎么办。于是我心生一计，我可以直接把启动进程的参数复制出来，直接在CMD中
模拟执行，再把WinDbg挂在cmd过程中就可以。
那么新的问题来了，断点在哪里下。
在CMD中执行的命令是rmdir，我在想肯定是执行Win32API函数删除目录，去MSDN管网去找对应的API,果然找到一个RemoveDirectory来下个断点。
复制当时的目录，F:\work\project 中文\LocalData\BackUp\ProjectName001\workTD\workTD_backup_2024-08-30-11-18-52 - 副本，打开cmd命令行。
先用WinDbg attach上，下个断点，在这里我不确定调用的是哪个函数，所以都下了断点。后面就是打印参数，按照unicode和ASIIC方式打印。
0:004> bm *!RemoveDirectory? "du rcx;da rcx"0: 00007ffa`8d1cf3b0 @!"KERNELBASE!RemoveDirectoryW"
1: 00007ffa`8d27e980 @!"KERNELBASE!RemoveDirectoryA"
2: 00007ffa`8e295250 @!"KERNEL32!RemoveDirectoryA"
3: 00007ffa`8e295260 @!"KERNEL32!RemoveDirectoryW"
4: 00007ffa`8eac48e8 @!"SHELL32!RemoveDirectoryW"
在cmd中执行
rmdir F:\work\project 中文\LocalData\BackUp\ProjectName001\workTD\workTD_backup_2024-08-30-11-18-52 - 副本
WinDbg立马断点下来，这里初现端倪，文件路径被截断了。
0:004> g000001cc`fbf1f4e0 "F:\work\project"
000001cc`fbf1f4e0 "F"
KERNELBASE!RemoveDirectoryW:
00007fff`5cf7f3b0 48895c2408 mov qword ptr [rsp+8],rbx ss:00000056`7fd0f010=000001ccfbf17c56
看下堆栈信息：
0:000> k# Child-SP RetAddr Call Site
00 00000056`7fd0f008 00007ff6`a0f6aab0 KERNELBASE!RemoveDirectoryW
01 00000056`7fd0f010 00007ff6`a0f5c862 cmd!RdWork+0x197dc
02 00000056`7fd0f360 00007ff6`a0f5bea1 cmd!FindFixAndRun+0x242
03 00000056`7fd0f800 00007ff6`a0f6ebf0 cmd!Dispatch+0xa1
04 00000056`7fd0f890 00007ff6`a0f68ecd cmd!main+0xb418
05 00000056`7fd0f930 00007fff`5dc07374 cmd!__mainCRTStartup+0x14d
06 00000056`7fd0f970 00007fff`5f49cc91 KERNEL32!BaseThreadInitThunk+0x14
07 00000056`7fd0f9a0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
此时依旧是老套路，查看KERNELBASE!RemoveDirectoryW原型，发现第一个参数就是路径地址，此时发现路径已经被截断
0:000> du rcx000001cc`fbf1f4e0 "F:\work\project"
至此可以分析出导致的原因，路径被截断。再仔细对比分析发现路径中存在了空格。
我们再接着往下分析，更加验证之前的猜想。
再从堆栈分析，当前的栈执行完之后会返回的地址00007ff6a0f5c862，可以反汇编看下cmd!FindFixAndRun+0x242执行逻辑：
0:000> u cmd!RdWork+0x197dccmd!RdWork+0x197dc:
00007ff6`a0f6aab0 0f1f440000 nop dword ptr [rax+rax]
00007ff6`a0f6aab5 85c0 test eax,eax
00007ff6`a0f6aab7 0f85a769feff jne cmd!RdWork+0x190 (00007ff6`a0f51464)
00007ff6`a0f6aabd 48ff15148b0100 call qword ptr [cmd!_imp_GetLastError (00007ff6`a0f835d8)]
00007ff6`a0f6aac4 0f1f440000 nop dword ptr [rax+rax]
00007ff6`a0f6aac9 33d2 xor edx,edx
00007ff6`a0f6aacb 8bc8 mov ecx,eax
00007ff6`a0f6aacd 8bd8 mov ebx,eax
此时我们在00007ff6a0f6aabd下个断点，输入单步执行指令g，
0:000> gBreakpoint 2 hit
cmd!RdWork+0x197e9:
00007ff6`a0f6aabd 48ff15148b0100 call qword ptr [cmd!_imp_GetLastError (00007ff6`a0f835d8)] ds:00007ff6`a0f835d8={KERNELBASE!GetLastError (00007fff`5cf3b610)}
这里提示调用的KERNELBASE!GetLastError来查找错误。再执行p，单步执行一次，让这条语句执行完。
此时我们调用!glt，就可以获取到当前的错误码。
0:000> !gleLastErrorValue: (Win32) 0x2 (2) - The system cannot find the file specified.
LastStatusValue: (NTSTATUS) 0xc0000034 - Object Name not found.
果然和上面的分析一致。
此时你设想下，要是你的路径下存在F:\work\project被删除了，那是多么可怕的事件。
3、解决方案
解决方案很简单，就是在路径上加上双引号就可以了。
subprocess.Popen('rmdir /S /Q \"%s\"' % to_del, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
