Before the NSA SMB vulnerability needs to tune the kernel of the shellcode, so collated a bit of WinDbg debugging Shellcode skills.
It is easier to load shellcode directly in the application layer by following these steps
- . Dvalloc 5000
- . readmem Shellcodepath allocaddress length
- R EIP = allocaddress
Because the. Dvalloc command is not available in dual-machine kernel mode, some special methods need to be taken.
Through the next nt! NtCreateFile Breakpoint, let it break down, other functions can also, use nt! NtCreateFile is primarily concerned with the frequency of its invocation, when it breaks down, it is tantamount to hijacking a thread, calling the function in that thread nt! ExAllocatePool manually allocate a memory page pool.
Directly step to return, EAX is the allocated memory pool.
Load the shellcode through the. Readmem.
Set up an EIP to step into the debug.
In this article, its author sets This step as a WinDbg script
https://vallejo.cc/2017/06/23/ loading-and-debugging-windows-kernel-shellcodes-with-windbg-debugging-doublepulsar-shellcode/
But rather bloated, at least I did not run up, in fact the whole step is completely a breakpoint, the following is my integrated breakpoint:
BP nt! NtCreateFile "Ed esp+4 0;ed esp+8 20000; r EIP = nt! EXALLOCATEPOOL;BP exallocatepool+0x15 \ "R eax;. Readmem c:\\\\users\\\\goabout2\\\\desktop\\\\shellcode @eax L; R eip = ea+0x0\ "; g"
Where the red part can be replaced by itself, first, two red boxes to identify the allocated memory pool, and the length of the copy of the Shellcode, the third identifies the shellcode of the entry offset, which is generally directly 0, the effect is as follows:
Reprint please indicate the source
WinDbg Debug Kernel Shellcode