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!KeReadyThread+0x19 (828a813e)

nt!KeReadyThread+0x10:
828a8135 e8b74af8ff      call    nt!KiInSwapSingleProcess (8282cbf1)
828a813a 84c0            test    al,al
828a813c 7505            jne     nt!KeReadyThread+0x1e (828a8143)

nt!KeReadyThread+0x19:
828a813e e892ef0000      call    nt!KiFastReadyThread (828b70d5)

nt!KeReadyThread+0x1e:
828a8143 5e              pop     esi
828a8144 c3              ret

According to this source, it has the following prototype:

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:

I am currently developing my reverse engineering skills and want to keep some important parts of this journey as well in this blog.

The first step of this series relates to disassembling Windows kernel routines, in my case Windows 7.

What are the prerequisites for this exercise?

• Ideally, install Windows inside a virtual machine
• From Windows Vista onwards, the Kernel debugging mode has to be enabled with: bcdedit /debug on
• Install Debugging Tools for Windows (for example, as part of the Windows SDK - https://www.microsoft.com/en-us/download/details.aspx?id=3138 for Windows 7, which contains the Kernel Debugger (KD))
• Install LiveKD from the SysInternals Suite 
  • IMPORTANT: the livekd.exe file should be placed in the system32 folder

Notice that since we use LiveKD, we are essentially debugging the Kernel locally without a second system. With this approach, functions cannot be debugged as LiveKD uses a Kernel read-only memory dump as a basis.

Several times I have encountered web applications that convert user-provided input to capital letters. For example, the application may behave as follows:

The injected JavaScript code (after escaping from the quotes, of course) will not be executed in the browser. Why is this the case? Remember that the HTML tag names themselves, including <SCRIPT> are not case-sensitive, whereas the contents inside them are in fact case-sensitive.