0

I'll appreciate if anyone can give me a couple advices regarding kernel debugging/reversing.

For instance if i want to know how the heap manager works what should i look for ?

I have no experience in reversing kernels.

2

First and most important advice I can give you is to not debug on your host machine, use a virtual machine such as hyper-v, VMWare and virtualbox instead.

Second, your preferred tool is WinDbg. There are many tutorials for setting it up with virtual machines. You can start from MSDN.

If you want to learn more how "heap management works" fast and in great details, you should consider reading the book What Makes It Page by Enrico Martignetti.

1

Since this is tagged windows, getting that kind of information is fairly easy these days:

  1. Go read Windows Internals by Russinovich, et all. This is an excellent book (actually two books) on how everything works.
  2. Read the source code from Wine or ReactOS which have already reverse engineered most of the kernel. This is a great way to answer specific questions about individual APIs / code paths.
0
  1. Set up a VM using virtual box or vmware.
  2. Configure the VM to boot with debugging enabled. Instructions here
  3. Set up a serial connection from the guest to the host machine.
  4. Run WinDBG on the host machine and connect over that serial interface.
  5. Debug.

This whole process is illustrated very well in Practical Malware Analysis a book I recommend to everyone looking to get into RE on windows.

0

The great thing about the Windows operating system is that though it is proprietary, the heart of it that really matters has been remarkably well documented over the years. MSDN is a great source. You can start by understanding windows driver model.

The windows driver model is the core framework of api's from which windows is built on. Consisting of kernal and user mode drivers (additional frameworks wrap much of the boiler plate code into simpler api's). User mode drivers are simply dll's (dynamic link libraries) and kernal mode, dll's with a different file extension (.sys instead of .dll) and explicit linking with GetProcAddress() and LoadLibrary() do not work for kernal. Much of this is well documented though complex in their inner workings. There are some Windows supplied drivers which are proprietary.

Beyond this there is a root driver called acpi.sys, supplied by microsoft. This is the root node from which all drivers and bus drivers are a child.

Additionally there are the mechanisms in which windows routes messages from driver to driver called interrupt request packets or irp's. The memory in user mode applications are virtualized by the memory controller in such a way that memory can not be predictably utilized outside the context of the calling handle.

Given all the constraints you may realize there isn't a single implementation that is unique to windows. Indeed the greatest attributes of windows has been compliance through carefully and skillfully planned guidance, and by virtue of this, tends to be well known or anything but proprietary.

  • Also "What Makes It Page?: The Windows 7 (X64) Virtual Memory Manager" by Enrico Martignetti – marshal craft Feb 18 '16 at 8:27
  • Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation 1st Edition by Bruce Dang (Author), Alexandre Gazet (Author), Elias Bachaalany (Author), Sébastien Josse (Contributor) – marshal craft Feb 18 '16 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.