Hi all,
i've just finished writing my very first driver :lol
The program i have written does nothing more then calling KeBugCheck to create a bsod on demand.
For now i have used the arguments of 0x00000000 to create the error code, but i would like to go further by letting the user decide which specific error code they wish when running the program. This means i need to take an argument from usermode and pass it to the DriverEntry PROC to call the KeBugCheck() or KeBugCheckEx() function.
Since i'm still learning driver development i don't know how i would pass such an argument to the driver, so that would be my question.
Also any info on writing drivers would be very welcome since i have found that the info available for this subject is very hard to find.
I have a copy of the XP DDK but in my opinion you already need to be a driver guru to make use of the ddk's info since it is very hard to use :(
Thanks in advance for your replies.
Kind regards,
Mark
p.s, the program i have written to create the bsod on demand can be found link removed. Source of course is included.
Sorry Scorpion, but we don't allow linking to sites with RE or cracking content on them.
- sluggy
Hi,
The DriverEntry function is called in the context of the system thread.
You can´t pass arguments to DriverEntry.
The classic way to pass arguments from user-mode to kernel-mode drivers
is to use the DeviceIoControl function.
Take a look in the VirtToPhys sample source code inside the Kmdkit.
Regards,
Opcode
I was afraid of that :(
That means that now i would have to do extensive error checking to make sure the system won't crash by giving corrupt arguments.. I hoped it would be possible to pass arguments since then i could pass just a simple DWORD which couldn't ever damage the system while calling KeBugCheckEx with that argument.
Thanks for your response, this at least answers my question...
Quote from: white scorpion on May 21, 2005, 05:52:30 PM
That means that now i would have to do extensive error checking to make sure the system won't crash by giving corrupt arguments.
Hehe.... irony. Crash the system is your driver objective :green2
Good luck :U
..::[Opcode]::..
Yeah, bsod - blue screen of death.
Paul
yes, but a controlled crash doesn't matter, a crash without checking the arguments to a function might. And of course i don't want that ;-)
Yes, but why crash the machine at all? I don't get it!
Paul
It is funny: you can lend the program to a friend and watch their face of horror, then you tell then it was all a joke.
QuoteYes, but why crash the machine at all? I don't get it!
Paul
Some drivers use the KeRegisterBugCheckCallback() function to get notified when such an exception occurs. This gives the driver the oppertunity of closing devices before the bsod occurs. of course this is something that should be tested long before such a driver is distributed so most use would such a tool have if you are developing drivers for Windows. Indeed it can be used as a joke as well, but most importantly would be for debugging drivers.
I'm however planning on letting the user give a custom error message (therefore my question) and it would be nice as well if i could change the blue in the bsod into red or some other colour. I'm sure this shouldn't be so hard, but i just need to figure out where the data for the bsod is retrieved from before i can do something about it.
So besides the use of the program for driver developers it is also nice to learn about the working of the Windows kernel, so that's why i wrote it.
QuoteIt is funny: you can lend the program to a friend and watch their face of horror, then you tell then it was all a joke.
i once saw a screensaver which shows a bsod screen and then shows the screens just like your system is rebooting again. These things are a lot more fun to play with then such a program since the target user might have some important files he is working on which aren't saved yet before he runs the program. So that's something to be careful with.
you can alos pass arguments through the registry because of the ZwOpenKey etc.
Quote from: white scorpion on May 22, 2005, 12:04:39 PM
it would be nice as well if i could change the blue in the bsod into red or some other colour.
They probably hardcoded the blue colour into the OS.
Quote from: white scorpion on May 22, 2005, 12:04:39 PM
QuoteIt is funny: you can lend the program to a friend and watch their face of horror, then you tell then it was all a joke.
i once saw a screensaver which shows a bsod screen and then shows the screens just like your system is rebooting again. These things are a lot more fun to play with then such a program since the target user might have some important files he is working on which aren't saved yet before he runs the program. So that's something to be careful with.
I have that screensaver already; several people have already been fooled by it. You are right about being careful, though.
Quote from: white scorpion on May 22, 2005, 12:04:39 PM
So besides the use of the program for driver developers it is also nice to learn about the working of the Windows kernel, so that's why i wrote it.
Nice, but very complicated! :tdown
Actually, you can change the bsod to whatever color you want. Have you searched for bsod themes? Also, starting with Longhorn, Microsoft is going to use the bsod for advertisements (dealers will, also). Now that is funny!
Paul
QuoteActually, you can change the bsod to whatever color you want. Have you searched for bsod themes? Also, starting with Longhorn, Microsoft is going to use the bsod for advertisements (dealers will, also). Now that is funny!
Paul
you're kidding right?! so soon we might even get some stupid add when we get a bsod ?? That would be really something stupid!
I will search for the themes, perhaps i can figure out how to change it ....
Thanks for your replies ;-)
LOL :green
Now is the time of Red Screen of Doom
http://blogs.msdn.com/michkap/archive/2005/05/07/415335.aspx
Quote from: white scorpion on May 21, 2005, 03:45:10 PM
I have a copy of the XP DDK but in my opinion you already need to be a driver guru to make use of the ddk's info since it is very hard to use
Not very hard if u really want to learn how to write drivers like me. There are books available on internet.
Im working on my first driver and this is just for turning FLOPPY drive led on and off. So this will work on W95-2k without error message: Privileged instruction. I think it's simple way to start.
That sure is a good way to start, but it would be nice to have some sort of API reference especially for use in kernel mode, This would make coding drivers a lot easier!
White Scorpion,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/drisupport_ed401318-53d0-42fb-b450-a12de883daa2.xml.asp
Also, take a look at the ntoskrnl.inc file functions. The function names give a clue as to what the function does. Search the web for info on params and usage.
Thanks DoD,
that list from msdn might indeed be useful only it still isn't what i meant... perhaps once i get the hang of it i will create my own database of API's usable in KM.
A fellow named Leo wrote several really neat hacks for the Amiga back in the late 80's. In reference to changing the bsod to different colors you could do something similar to what he did:
Get a pointer to the full screen buffer for the system.
Make another identical buffer and copy the original or create your own bsod with advertising or your own info
Place your screen buffer in front of the actual system screen buffer with no transparency.
Then when the mouse is moved or a key is pressed switch back to the actual screen and cleanup.
His hacks were really inspiring!
Melt: made it look your screen was melting from the top down.
Tilt: displayed created pinball like firewords then displayed the Amiga "Enter Kickstart Disk" equivalent of the bsod if my memory serves correctly.
Robotroff: created a transparent screen to place in front of the system screen and ran like a TSR would under dos. After a few minutes one of many various little robots with varying personalities would appear on the screen marching or flying toward your mouse pointer. When it got there it would start moving the pointer (by simulating the input events from the mouse and moving along with it) to the nearest margin of the screen.
I think the same could probably be accomplished on Windows although I am not certain of that. It requires the ability to safely switch your screen buffer with the actual system screen ... or, to create a transparent overlay that can be placed in front of the system screen.
QuoteGood News from the Front
Leo Schwab, creator of Robotroff, Guru Meditation Number 49424D53.75636B73
(spell it out), and other marvelous Amiga hacks, brings us
news of -=RJ Mical's=- Latest Creation. Take it away, Sir Schwab:
I spoke to -=RJ Mical=- this evening. He is indeed a father.
The child's name is Alexander Joseph Mical. No word yet on whether
or not it's surrounded by -= =-, or any other symbol.
-=RJ=- happened to mention in passing that they have the same middle
name. "So from where did you derive Alexander?" I asked.
"Well, we wanted a conqueror......"
Timothy Rue (AAi member)
Incidently, none of the things he did were malicious ... They were all just great and widely accepted hacks to inspire the imagination!
Edit:Here's a pointer to Leo's homepage: http://ewhac.best.vwh.net/.
Sounds interesting... I will search for more info on it.. Thanks Phil!