WinDbg 是否显示 [MOV r32,r/m32] 的错误操作码？
Is WinDbg displaying the wrong opcode of [MOV r32,r/m32]?
我正在修补 VS2019 16.2.3 linker 位于
"C:\Program Files (x86)\Microsoft Visual Studio19\Community\VC\Tools\MSVC.22.27905\bin\Hostx86\x86\link.exe" 为了像往常一样摆脱 Rich Signature WinDbg:10.0.17763.132 X86.
首先找到link!IMAGE::CbBuildProdidBlock里面唯一的调用link!IMAGE::BuildImage:
ModLoad: 00130000 00297000 link.exe
0:000> # call*link!IMAGE::CbBuildProdidBlock link!IMAGE::BuildImage
link!IMAGE::BuildImage+0xeac:
00176e28 e896830000 call link!IMAGE::CbBuildProdidBlock (0017f1c3)
然后：
0:000> u 00176e28
link!IMAGE::BuildImage+0xeac:
00176e28 e896830000 call link!IMAGE::CbBuildProdidBlock (0017f1c3)
00176e2d 8b8f90020000 mov ecx,dword ptr [edi+290h]
00176e33 8b1518d42500 mov edx,dword ptr [link!CbHdr (0025d418)]
00176e39 03c8 add ecx,eax
00176e3b 898528faffff mov dword ptr [ebp-5D8h],eax
00176e41 8d8500faffff lea eax,[ebp-600h]
00176e47 898f94020000 mov dword ptr [edi+294h],ecx
00176e4d 8bcf mov ecx,edi
因此，将 add ecx,eax 更改为 nop nop 即可。
无意间发现上面那行add ecx,eax是
00176e33 8b1518d42500 mov edx,dword ptr [link!CbHdr (0025d418)]
其文件偏移量为 00176e33 - 00130000 - (1000 - 400) = 46233.
但是在 Notepad++ + HexEditor 和 VSCode + hexdump 中，它显示 8B 15 18 D4 52 00 而不是 8B 15 18 D4 25 00
00046230: 02 00 00 8B 15 18 D4 52 00 03 C8 89 85 28 FA FF
我尝试将文件复制到其他地方，或者多次启动WinDbg以确保不是由数据错误引起的，结果还是一样。
为什么 WinDbg 在 00176e33 处显示“8b1518d42500”而不是“8B 15 18 D4 52 00”，我必须彻底了解 Intel X86 Opcode and Instruction Reference 才能解决这个问题？
windbg 是否向您展示应用运行时重定位修正后的反汇编？它是 32 位代码，因此不能使用 RIP 相对寻址。
这可以解释指令中绝对地址的某些高位与磁盘文件中的不同。
0x25 字节是 mov edx, [disp32] 指令中 [link!CbHdr (0025d418)] 寻址模式的小端 disp32 编码的第二高字节。
我正在修补 VS2019 16.2.3 linker 位于 "C:\Program Files (x86)\Microsoft Visual Studio19\Community\VC\Tools\MSVC.22.27905\bin\Hostx86\x86\link.exe" 为了像往常一样摆脱 Rich Signature WinDbg:10.0.17763.132 X86.
首先找到link!IMAGE::CbBuildProdidBlock里面唯一的调用link!IMAGE::BuildImage:
ModLoad: 00130000 00297000 link.exe
0:000> # call*link!IMAGE::CbBuildProdidBlock link!IMAGE::BuildImage
link!IMAGE::BuildImage+0xeac:
00176e28 e896830000 call link!IMAGE::CbBuildProdidBlock (0017f1c3)
然后：
0:000> u 00176e28
link!IMAGE::BuildImage+0xeac:
00176e28 e896830000 call link!IMAGE::CbBuildProdidBlock (0017f1c3)
00176e2d 8b8f90020000 mov ecx,dword ptr [edi+290h]
00176e33 8b1518d42500 mov edx,dword ptr [link!CbHdr (0025d418)]
00176e39 03c8 add ecx,eax
00176e3b 898528faffff mov dword ptr [ebp-5D8h],eax
00176e41 8d8500faffff lea eax,[ebp-600h]
00176e47 898f94020000 mov dword ptr [edi+294h],ecx
00176e4d 8bcf mov ecx,edi
因此，将 add ecx,eax 更改为 nop nop 即可。
无意间发现上面那行add ecx,eax是
00176e33 8b1518d42500 mov edx,dword ptr [link!CbHdr (0025d418)]
其文件偏移量为 00176e33 - 00130000 - (1000 - 400) = 46233.
但是在 Notepad++ + HexEditor 和 VSCode + hexdump 中，它显示 8B 15 18 D4 52 00 而不是 8B 15 18 D4 25 00
00046230: 02 00 00 8B 15 18 D4 52 00 03 C8 89 85 28 FA FF
我尝试将文件复制到其他地方，或者多次启动WinDbg以确保不是由数据错误引起的，结果还是一样。
为什么 WinDbg 在 00176e33 处显示“8b1518d42500”而不是“8B 15 18 D4 52 00”，我必须彻底了解 Intel X86 Opcode and Instruction Reference 才能解决这个问题？
windbg 是否向您展示应用运行时重定位修正后的反汇编？它是 32 位代码，因此不能使用 RIP 相对寻址。
这可以解释指令中绝对地址的某些高位与磁盘文件中的不同。
0x25 字节是 mov edx, [disp32] 指令中 [link!CbHdr (0025d418)] 寻址模式的小端 disp32 编码的第二高字节。