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.
Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.Sign up to join this community
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.
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.
Since this is tagged windows, getting that kind of information is fairly easy these days:
This whole process is illustrated very well in Practical Malware Analysis a book I recommend to everyone looking to get into RE on windows.
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
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.