Writing a Kernel Driver Just for the Intelligence
-
Hi, As a concept, I would like to write a kernel driver just to read kernel structure data and send the information back to a user mode application (in Windows XP). I have absolutely no experience doing this kind of thing, and, in all honesty, it scares the hell out of me. I have read much of the available literature (Windows Internals, and the documentation that comes with the Microsoft DDK), but, the kernel is a murky, nebulous region of the cosmos, and I am extremely reluctant to invade it without, say, a God-like sense of comprehension. Initially, my appraoch is to use the source examples provided with the DDK, but, I'm wondering if testing something like that can destroy or damage my operating system, or the device drivers currently residing there. If this is an evolutionary process, I don't want to become bytestream roadkill. Any good suggestions from those of you have survived the development process, besides reading the forum posts at OSR and Sysinternals?
-
Hi, As a concept, I would like to write a kernel driver just to read kernel structure data and send the information back to a user mode application (in Windows XP). I have absolutely no experience doing this kind of thing, and, in all honesty, it scares the hell out of me. I have read much of the available literature (Windows Internals, and the documentation that comes with the Microsoft DDK), but, the kernel is a murky, nebulous region of the cosmos, and I am extremely reluctant to invade it without, say, a God-like sense of comprehension. Initially, my appraoch is to use the source examples provided with the DDK, but, I'm wondering if testing something like that can destroy or damage my operating system, or the device drivers currently residing there. If this is an evolutionary process, I don't want to become bytestream roadkill. Any good suggestions from those of you have survived the development process, besides reading the forum posts at OSR and Sysinternals?
Baltoro wrote:
Initially, my appraoch is to use the source examples provided with the DDK, but, I'm wondering if testing something like that can destroy or damage my operating system, or the device drivers currently residing there.
Yes, in fact when I first started developing device drivers I was locked out of my operating system several times. It was quite embarrassing. I would highly recommend testing your device drivers in VMWare or VirtualPC. It is extremely easy to create a race condition in device drivers. It can be a challenge to repair the OS when a faulty driver is installed. Once I had to edit the registry from a boot CD to prevent an upper level filter driver from attaching. No more driver development outside of VMWare for me! I have since learned my lesson! :) There are additional benefits to running your test drivers in a virtual environment. It makes debugging the driver much easier. There is a gentleman named Dana Epp[^] who has a site dedicated to those seeking ring-0[^]. He has written a tutorial showing how to use WinDbg with VMWare[^]. I have found the following blogs to sometimes contain useful information: A Hole In My Head[^] Pointless Blathering[^] It Goes To Eleven[^] OSR online[^] is also a great resource. There are many knowledgeable engineers there who are willing to help out. I would highly recommend joining the discussion lists. See you there! Best Wishes, -David Delaune
-
Baltoro wrote:
Initially, my appraoch is to use the source examples provided with the DDK, but, I'm wondering if testing something like that can destroy or damage my operating system, or the device drivers currently residing there.
Yes, in fact when I first started developing device drivers I was locked out of my operating system several times. It was quite embarrassing. I would highly recommend testing your device drivers in VMWare or VirtualPC. It is extremely easy to create a race condition in device drivers. It can be a challenge to repair the OS when a faulty driver is installed. Once I had to edit the registry from a boot CD to prevent an upper level filter driver from attaching. No more driver development outside of VMWare for me! I have since learned my lesson! :) There are additional benefits to running your test drivers in a virtual environment. It makes debugging the driver much easier. There is a gentleman named Dana Epp[^] who has a site dedicated to those seeking ring-0[^]. He has written a tutorial showing how to use WinDbg with VMWare[^]. I have found the following blogs to sometimes contain useful information: A Hole In My Head[^] Pointless Blathering[^] It Goes To Eleven[^] OSR online[^] is also a great resource. There are many knowledgeable engineers there who are willing to help out. I would highly recommend joining the discussion lists. See you there! Best Wishes, -David Delaune
-
Hi, As a concept, I would like to write a kernel driver just to read kernel structure data and send the information back to a user mode application (in Windows XP). I have absolutely no experience doing this kind of thing, and, in all honesty, it scares the hell out of me. I have read much of the available literature (Windows Internals, and the documentation that comes with the Microsoft DDK), but, the kernel is a murky, nebulous region of the cosmos, and I am extremely reluctant to invade it without, say, a God-like sense of comprehension. Initially, my appraoch is to use the source examples provided with the DDK, but, I'm wondering if testing something like that can destroy or damage my operating system, or the device drivers currently residing there. If this is an evolutionary process, I don't want to become bytestream roadkill. Any good suggestions from those of you have survived the development process, besides reading the forum posts at OSR and Sysinternals?
Baltoro wrote:
I'm wondering if testing something like that can destroy or damage my operating system
Oh yes! :)
Baltoro wrote:
or the device drivers currently residing there
Deffinitely!
Baltoro wrote:
If this is an evolutionary process
And about as slow. But more painfull.
Baltoro wrote:
Any good suggestions
- Ghost your system. You are going to need it. 2) Never set a test driver to auto start. You can get into a boot-bsod-boot-bsod loop. 3) Get Walter Oneys book. 4) Use a DDK sample to start with. Say, a simple IO, or a write to buffer/read from same buffer driver to het a feel if you like. I have spent about 10 years writing drivers, still learning stuff!
Morality is indistinguishable from social proscription
-
Baltoro wrote:
I'm wondering if testing something like that can destroy or damage my operating system
Oh yes! :)
Baltoro wrote:
or the device drivers currently residing there
Deffinitely!
Baltoro wrote:
If this is an evolutionary process
And about as slow. But more painfull.
Baltoro wrote:
Any good suggestions
- Ghost your system. You are going to need it. 2) Never set a test driver to auto start. You can get into a boot-bsod-boot-bsod loop. 3) Get Walter Oneys book. 4) Use a DDK sample to start with. Say, a simple IO, or a write to buffer/read from same buffer driver to het a feel if you like. I have spent about 10 years writing drivers, still learning stuff!
Morality is indistinguishable from social proscription