soffensive blog

Practical Reverse Engineering Exercise Solutions: KeInitializeApc Routine

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:

Practical Reverse Engineering Exercise Solutions: Windows Kernel Routines

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.

Cross-Site Scripting Attacks with adverse Conditions: Upper-Case XSS

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

../images/thumbnails/2017-04-05-cross-site-scripting-attacks-with-adverse-conditions-upper-case-xss-up1.png

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.