\n\nThis page has been machine-translated from the original page.
\n
My goal is to become proficient with WinDbg for Windows debugging and dump-based troubleshooting.
\nIn Trying the WinDbg User-Mode Debugging Tutorial, I covered how to debug user-mode applications with WinDbg.
\nThis time, as a practical use case, I’ll show how to inspect memory and register information during live debugging of a user-mode application with WinDbg.
\nFor a full list of articles on Windows debugging and dump analysis with WinDbg, see the index page:
\nReference: Debugging and Troubleshooting Techniques with WinDbg
\n\nThis article has two goals:
\nI’ll set breakpoints at various points in the program during live user-mode debugging with WinDbg and inspect the stack information at the time of each function call.
\nI’ll also tamper with memory from WinDbg to make an arbitrary piece of code execute.
\nThe program used in this test is made up of the following source code.
\nWhen run, it calls the ret_func function, prints a few strings, and then exits.
// return_addr.cpp\n#include <stdio.h>\n\nint ret_func() {\n printf(\"Call ret_func\\n\");\n return 0;\n}\n\nint main() {\n printf(\"Start main\\n\");\n ret_func();\n printf(\"Return ret_func\\n\");\n return 0;\n}The sample code is available at kash1064/Try2WinDbg.
\nFor instructions on how to compile the sample program with a symbol file (.pdb), refer to the following article:
\nReference: How to Generate Symbol Files (.pdb) in a Linux Environment Using llvm-mingw
\nLet’s get started with the analysis using return_addr.exe, the compiled binary from this source code.
I’m using the UWP version, WinDbg Preview, for this analysis. It is available from the Windows Store.
\nFirst, launch the compiled return_addr.exe from WinDbg.
My goal here is to observe the value stored in the base pointer at the time of a function call.
\nNext, set a breakpoint at the first address of the ret_func function, identified using the Disassembly window:
0:000> bu 00007ff6`96451470\n0:000> bl\n 0 e Disable Clear 00007ff6`96451470 0001 (0001) 0:**** return_addr!Z8ret_funcv\n 1 e Disable Clear 00007ff6`96451490 0001 (0001) 0:**** return_addr!mainAfter running with g and hitting the breakpoint, use the r command to print register information:
0:000> g\nBreakpoint 0 hit\nreturn_addr!Z8ret_funcv:\n00007ff6`96451470 4883ec28 sub rsp,28h\n\n0:000> r\nrax=000000000000000b rbx=0000000000000001 rcx=00000000ffffffff\nrdx=00007ffdef6e0980 rsi=0000021d4c3134d0 rdi=000000000000002b\nrip=00007ff696451470 rsp=0000002e738ff748 rbp=0000002e738ff780\n r8=0000002e738fdb78 r9=0000021d4c31a47b r10=0000000000000000\nr11=0000002e738ff660 r12=0000000000000000 r13=0000000000000000\nr14=0000021d4c315230 r15=0000000000000001\niopl=0 nv up ei pl nz na pe nc\ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202\nreturn_addr!Z8ret_funcv:\n00007ff6`96451470 4883ec28 sub rsp,28hWe can see that the value of the rbp register immediately after the function call is 0x2e738ff780.
Next, enter the address pointed to by the rbp register in the Memory window’s address bar to inspect memory.
The value stored there appears to be 0x7FF6964513DA (note: read in reverse, as values are stored in little-endian format).
Next, to find the address that will be called after ret_func finishes, inspect the value of the rsp register at the moment the function was called.
From the register information, the stack pointer address is 0xa74d0ffd58, so let’s check the Memory window.
The value stored there appears to be 0x7FF6964514B7.
Checking the Disassembly window again confirms this is the address of the instruction scheduled to be called after ret_func finishes.
Finally, I’ll tamper with the memory at the address pointed to by the rsp register — the address to jump to after ret_func returns — and make an arbitrary function execute.
In WinDbg, you can tamper with memory by directly editing values in the Memory window. (WinDbg must be launched with administrator privileges.)
\nReference: Viewing and Editing Memory in WinDbg - Windows drivers | Microsoft Docs
\nNote: in the version of WinDbg Preview I’m using, editing values directly from the Memory window did not work. (It did work in WinDbg X64 included with Windows Debug Tools, so this may be a limitation or a bug in the Preview version.)
\nTherefore, I’ll use the e command instead of the Memory window to tamper with the memory.
Reference: e, ea, eb, ed, eD, ef, ep, eq, eu, ew, eza (Enter Values) - Windows drivers | Microsoft Docs
\nThe address I want to modify is 0x000000150acffb58, the address currently pointed to by the rsp register.
I’ll change the value at that address to the call address of the ret_func function so that ret_func is called one more time.
The call address of ret_func is 0x00007ff7 81df1470.
The following command tampers with the memory in one shot. (Values are entered in reverse because of little-endian notation.)
\neb 000000150acffb58 0x70 0x14 0xdf 0x81 0xf7 0x7f 0x00 0x00After running the command, the memory was successfully overwritten!
\nIn this article, I introduced how to inspect and tamper with memory using WinDbg.
\nFor other articles on Windows debugging and dump analysis with WinDbg, see the list on the following page:
\nReference: Debugging and Troubleshooting Techniques with WinDbg
","fields":{"slug":"/windows-windbg-007-memory-spoofing-en","tagSlugs":["/tag/win-dbg-en/","/tag/kernel-en/","/tag/reversing-en/","/tag/english/"]},"frontmatter":{"date":"2021-10-18","description":"","tags":["WinDbg (en)","Kernel (en)","Reversing (en)","English"],"title":"Overwriting the Memory Pointed to by the Stack Pointer in WinDbg to Execute an Arbitrary Function","socialImage":{"publicURL":"/static/d0c4232665b4646dc19e54bd760ebe95/windows-windbg-007-memory-spoofing.png"}}}},"pageContext":{"slug":"/windows-windbg-007-memory-spoofing-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}