Gynvael Coldwin posted a small challenge at the end of his last podcast on Windows Kernel Debugging with Artem Shishkin: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Welcome back agent 1336. No mail. > mission --take MISSION 012 goo.gl/qudiHJ DIFFICULTY: ██░░░░░░░░ [2╱10] ┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅ Our agents managed to install a hardware keylogger in suspects computer.

Exercise 7 on page 35: Sample H. The function sub_10BB6 has a loop searching for something. First recover the function prototype and then infer the types based on the context. Hint: You should probably have a copy of the PE specification nearby. Due to alignment issues, our routine is located at 10BB2 and has the following disassembly: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 sub_10BB2: mov eax, [esp+4] push ebx push esi mov esi, [eax+3Ch] add esi, eax movzx eax, word ptr [esi+14h] xor ebx, ebx cmp [esi+6], bx push edi lea edi, [eax+esi+18h] jbe short loc_10BEB loc_10BCE: push [esp+0Ch+arg_4] push edi call ds:dword_169A4 test eax, eax pop ecx pop ecx jz short loc_10BF3 movzx eax, word ptr [esi+6] add edi, 28h inc ebx cmp ebx, eax jb short loc_10BCE loc_10BEB: xor eax, eax loc_10BED: pop edi pop esi pop ebx retn 8 loc_10BF3: mov eax, edi jmp short loc_10BED The PE file format and offsets have been described in detail here: http://www.

Exercise 6 on page 35 of the book Practical Reverse Engineering presents us with a malware samples. These can be downloaded at the following page: https://grsecurity.net/malware_research/ In this exercise, we are expected to have a look at the following routine sub_13842: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 .text:00013842 sub_13842 .text:00013842 mov eax, [ecx+60h] .text:00013845 push esi .text:00013846 mov esi, [edx+8] .text:00013849 dec byte ptr [ecx+23h] .

This blog post contains my solution for the decompilation exercise of the RtlValidateUnicodeString function in the Windows Kernel. The following contains the disassembly without annotations: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 kd> uf rtlvalidateunicodestring ntdll!RtlValidateUnicodeString: 77686f6c 8bff mov edi,edi 77686f6e 55 push ebp 77686f6f 8bec mov ebp,esp 77686f71 837d0800 cmp dword ptr [ebp+8],0 77686f75 0f85fc380300 jne ntdll!

Here are a couple of commands I regularly use for reverse engineering: uf <function>: Unassemble function dt nt!_ktss: Show the definition of the data structure _ktss ?? sizeof(_ktss): Show the size the data structure _ktss occupies in memory .hh uf: Show help for the function uf x nt!*createfile*: Search all functions having the string createfile in its name !vtop <PDPT-pointer> <virtualAddress>: Compute physical address of given virtual address and the pointer to the page directory pointer table

Another exercise for us is the decompilation of the KiInitializeTSS function: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 nt!KiInitializeTSS: 82847359 8bff mov edi,edi 8284735b 55 push ebp 8284735c 8bec mov ebp,esp 8284735e 8b4508 mov eax,dword ptr [ebp+8] 82847361 b9ac200000 mov ecx,20ACh 82847366 66894866 mov word ptr [eax+66h],cx 8284736a 33c9 xor ecx,ecx 8284736c 6a10 push 10h 8284736e 66894864 mov word ptr [eax+64h],cx 82847372 66894860 mov word ptr [eax+60h],cx 82847376 59 pop ecx 82847377 66894808 mov word ptr [eax+8],cx 8284737b 5d pop ebp 8284737c c20400 ret 4 We obtain the function prototype: (source)

Unfortunately I had no time in the past days to continue with the exercises. We continue with the decompilation of the KeReadyThread function in Windows 7. The following listing shows the disassembly: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 nt!KeReadyThread: 828a8125 8bff mov edi,edi 828a8127 56 push esi 828a8128 8bf0 mov esi,eax 828a812a 8b4650 mov eax,dword ptr [esi+50h] 828a812d 8b4874 mov ecx,dword ptr [eax+74h] 828a8130 f6c107 test cl,7 828a8133 7409 je nt!

We are tasked with decompiling the Windows Kernel routine KeInitializeQueue. Firstly, we obtain its disassembly:  Secondly, we consult MSDN for its signature: 1 2 3 4 VOID KeInitializeQueue( _Out_ PRKQUEUE Queue, _In_ ULONG Count ); The routine itself does not return anything. We learn it takes two parameters and as the assembly contains the ret 8 instruction, the KeInitializeQueue function cleans up the stack and thus, it uses the stdcall convention.

First of all a quick reminder: This series of blog posts relates to exercises from the book Practical Reverse Engineering by Dang et al. Although it is called reverse engineering in general, it actually is mostly relevant to Microsoft Windows operating systems. This is simply due to the fact that Microsoft Windows is closed source in contrast to the Linux/Unix families, which means its source code is publicly available and so no reverse engineering endeavours are necessary.

To keep me motivated and document my progress, I will create a series of blog posts with answers to some of the exercises from the book “Practical Reverse Engineering” by Dang, Gazet and Bachaalany. In the last post, we introduced the Windows Kernel Debugger (KD) and some of the functions. I have learned that rather than using KD directly, we can use WinDbg’s interface which is more user-friendly. When calling livekd, simply append the “-w” parameter and WinDbg will start up: