Remote kernel debugging using Windbg.

In the following article we will discuss two different methods of remote kernel debugging using Windbg and also various operating systems. Let's begin!

NOTE: It is recommended that you use VMware for this I have NOT tested this on any other virtualisation software.

1. VirtualKD:

Giving the fact that this is a straight forward installation we will not be covering this in depth, you can find information and the download link on the official website at:-

http://virtualkd.sysprogs.org/

Important notes:

- This only works between a HOST and Virtual Machine it will NOT WORK between two virtual machines.
- Very fast debugging compared to Serial Ports.
- Only works on a Windows host so if you with to do this on OS X or Linux this will not help you. (There might be other similar software to help you achieve this however I am not aware of any)

2. Serial Ports:

This method even though it's documented I found that most of the online sources I found were missing different steps or were covering an older version of VMware. For the following example we will use the following names:

"DEBUGEE" - Machine to be debugged.
"DEBUGGER" - Machine which runs the debugger.

Make sure you have Windows Debugging tools installed on the debugger, if you do not you can download and install it at the following url:-

http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

The next step is to edit the .vmx file of both debugger and debugee, before saving the changed make sure you have no serialport0 line before.

WINDOWS:
* DEBUGGER:

serial0.present = "FALSE"
serial1.present = "TRUE"
serial1.fileType = "pipe"
serial1.yieldOnMsrRead = "TRUE"
serial1.startConnected = "TRUE"
serial1.fileName = "\\.\pipe\D:\windbg"
serial1.pipe.endPoint = "client"
* DEBUGEE:

serial0.present = "FALSE"
serial1.present = "TRUE"
serial1.fileType = "pipe"
serial1.yieldOnMsrRead = "TRUE"
serial1.startConnected = "TRUE"
serial1.fileName = "\\.\pipe\D:\windbg"
Of course the fileName should be a valid path.

OS X / LINUX:
* DEBUGGER:

serial0.present = "FALSE"
serial1.present = "TRUE"
serial1.fileType = "pipe"
serial1.yieldOnMsrRead = "TRUE"
serial1.startConnected = "TRUE"
serial1.fileName = "/private/tmp/windbg"
serial1.pipe.endPoint = "client"

* DEBUGEE:

serial0.present = "FALSE"
serial1.present = "TRUE"
serial1.fileType = "pipe"
serial1.yieldOnMsrRead = "TRUE"
serial1.startConnected = "TRUE"
serial1.fileName = "/private/tmp/windbg"
The same thing applies here, fileName should be a valid path.
Now there is only one step left to do and that is to edit the c:\boot.ini on the debugee and add a line as follows:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows Server 2003 Debug" /fastdetect /NoExecute=OptIn /debug /debugport=com2 /baudrate=115200

The above method only applies to Windows XP/2003 for further version you can use bcdedit.exe as follows:

bcdedit /debug on
bcdedit /enum (to see if debug mode is on)
bcedit /dbgsettings Serial debugport:<com_port> baudrate:115200

The last thing you need to do is open Windbg on your debugger and go to "File -> Kernel Debugging" (make sure you select com2 on port) and reboot your debugee machine.

Linux exploit development part 4 - ASCII armor bypass + return-to-plt

I know it's been a lot of time since the last paper but this one gave me some headaches.

Download: Linux exploit development part 4 - ASCII armor bypass + return-to-plt

Linux exploit development part 3 (rev 2) - Real app demo ret2libc

As you have probably expected this is the real application demo + video demo of my part 3 of the Linux exploit development series.

Technical paper: Linux exploit development part 3 - ret2libc
Demo paper: Linux exploit development part 3 (rev 2) - Real app demo ret2libc
Video demo:

Linux exploit development part 3 (rev 2) - Real app demo from sickness on Vimeo.

Linux Exploit Development Pt 2 (rev 2) - Real App Demo (part 2)

Question:
In short why another part 2 if we already have one?

Answer:
Recently I've been receiving feedback from people who have read the papers and amongst those _sinn3r and corelanc0d3r actually recommended I should also give examples using real vulnerable application.

About the paper:
I will not be repeating myself, this paper does not contain any theory in it. If you do not have the required knowledge I suggest you first read my part 2 paper before trying this: Linux Exploit Writing Tutorial Pt 2 - Stack Overflow ASLR bypass Using ret2reg

The paper can be found here and long with the paper I've also made a quick video demonstration:

Linux exploit development part 2 (rev 2) - Demo from sickness on Vimeo.

Hope you enjoy it and have fun :)

Linux exploit development part 3 - ret2libc

I'm not going to repeat myself from the paper, this will just be a short description of what the paper contains.

So in the previous tutorials our exploits were made on Backtrack 4 R2 now we are going to make them on Debian Squeeze (latest) because Backtrack does not have DEP enabled by default (PAE enabled kernel on 32 bits).

In short terms DEP or NX prevents some stack or heap memory spaces from being executed, it also prevents executable memory from being writable. This is very effective against buffer overflows that inject and execute malicious code. (More about NX here)

How to bypass this !? ... -> Linux exploit development part 3 - ret2libc.pdf

Linux Exploit Writing Tutorial Pt 2 - Stack Overflow ASLR bypass Using ret2reg

As expected the part 2 of my tutorial series, I'm not going to repeat myself again, so without any other introductions here it is:

Linux Exploit Writing Tutorial Pt 2 - Stack Overflow ASLR bypass Using ret2reg

Linux exploit development part 1 - Stack overflow.

I've started to write a series of tutorials about exploit development on Linux, this is the first part which contains a Stack overflow, with hardcoded ESP address (I know it's unreliable, that's why it's part 1).
Anyways here is the PDF: Linux exploit development part 1 - Stack overflow

Hope you enjoy it.