debugging kernel driver and understanding i/o routing with various structures
Let’s debug a very simple driver from pavel’s latest book on kernel programming and understand different structures along with their relationship and overall...
TL;DR
Having a clean and lightweight enviroment is what everyone wants. Building drivers on windows is supported via visual studio with cmake support. But having to open the bloated ui might not be on everyone’s mind.
I really like FindWDK often which is CMake module for building drivers with WDK.
│ .gitignore
│ .gitmodules
│ CMakeLists.txt
│ LICENSE
│ README.md
│
├───build
│ .ninja_deps
│ .ninja_log
│
├───FindWDK
│ │ .appveyor.yml
│ │ .editorconfig
│ │ .gitignore
│ │ LICENSE
│ │ README.md
│ │
│ ├───cmake
│ │ FindWdk.cmake
│ │
| | **snipped**
│
└───simple
CMakeLists.txt
simple.c
cmake file preset at root directory
cmake file for simple driver
%comspec% /k “C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat”
NOTE: The above steps used ninja the other option should work fine as well.
Let’s debug a very simple driver from pavel’s latest book on kernel programming and understand different structures along with their relationship and overall...
Let’s explore how nt!PoolHitTag can be useful for while tracking memory issues. Along with useful windbg command like !pool, !poolfind, !verifier etc.
In this post let’s explore the general mechanism of how we go for virtual to physical memory. Trying to understand what happens in between.
In the prev post we saw how to use phnt to access windows native api and undoc structures.
Quite often on windows accessing native api and undoc structures is required.
TL;DR This is taken from the mwri labs doc in links below. The vulnerability is in the function win32k!xxxHandleMenuMessages. When it calls the functio...
When kernel debugging an old target like Windows 7 after a long time using windbg. I noticed not being able to see the registers in register pane. That was k...