|
Hello,
I would like to know where Windows processes execution and opening of files and programs on the computer, because I'm creating a kernel-mode execution-filter driver (basically, a driver that sits back and "spys" on every program that tries to open up on my computer, before my computer actually detects it or processes it) for security purposes, and to block it or suspend it from the settings the user choose from a GUI application that manages this centrally.
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
modified 30-Apr-12 10:27am.
|
|
|
|
|
Brandon T. H. wrote: Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
And you want to write a kernel file system filter driver?
Good luck!
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: Good luck!
There are driver tutroials on here, especially the firewall "Network/Ethernet Filter Driver" here, C++ and Visual Basic are fairly common in syntax, so it's not something that is completely new or very hard and complex to understand, I could look up some code blocks online and change some words around in the programming and change a network/ethernet filter driver into a execution filter driver (it is possible). But There some things to avoid or try not to make or risk and that I have converters to translate from language-to-language.
But you could be right, with the excemption that some language(s) (for example, Visual Basic or C++ CLI/CLR) does not support driver developing/creating/compiling.
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Brandon T. H. wrote: I could look up some code blocks online and change some words around in the programming and change a network/ethernet filter driver into a execution filter driver
I think Eric's comment was indicating that there is far more to it than that. Changing a few words in one type of driver will not give you a different type. First you need a good understanding of how specific filters work and their interaction with the system. Then you need to understand the specifics of the area that you are trying to filter. As you say there are tutorials, but it takes more than a few hours with online tutorials to be able to understand kernel level programming fully.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
1). Drivers are written in C. C++ is not supported by Microsoft in the kernel. Yes you can use it, but be very careful, so it is best to use C. And you are going to have to use iy in its very raw form. Lots of pointers, pointers to pointers, casting pointers to ints, and so on.
2) Brandon T. H. wrote: Network/Ethernet Filter Driver" Thats an NDIS model driver. It isnt WDM, and isnt anything like a file system filter. (Yep. I have written plenty of both).
3) Brandon T. H. wrote: so it's not something that is completely new or very hard and complex to understand, I so wish I could watch your first efforts... Drivers ARE very complex and hard to understand.
Brandon T. H. wrote: I could look up some code blocks online and change some words around in the programming and change a network/ethernet filter driver into a execution filter driver (it is possible).
As stated that isnt possible, totally different model, diferent API, different everything.
Brandon T. H. wrote: I have converters to translate from language-to-language
This isnt going to work.
You need to be very very proficient in C and understand the kernel/OS/HW in detail in the particular realm you will be working in.
FSF drivers are some of the hardest to write too, so you are jumping in at the deep end. NDIS drivers are actually fairly simple (in comparison).
OK, think of this, kernel code is about 20 times more complex than user mode code. Thats the kind of mind numbing nastiness you will be working with.
You also need to use windbg to debug, so you need to be very proficient in its use.
Oh, and assembler. You are going to be debugging alot in assembler as you trace into system calls to see why your code is going wrong.
Ten there is the install. This can be a major nightmare in its own right and can have fundamental impacts on the way your driver works, or not.
==============================
Nothing to say.
|
|
|
|
|
Too bad I can't vote this one a 10+.
I haven't done any driver development in the 30+ years I've been writing code and looking at that stuff still my head explode!
|
|
|
|
|
yeah, it is brain bendingly complicated.
==============================
Nothing to say.
|
|
|
|
|
Brandon T. H. wrote: C++ and Visual Basic are fairly common in syntax
Not even close. Yes, both look like "code", and both have markings at the beginning and the end of a method, but that's where the similarities end.
Bastard Programmer from Hell
|
|
|
|
|
Brandon T. H. wrote: C++ and Visual Basic are fairly common in syntax
Heresy! Blasphemy!
At least artificial intelligence already is superior to natural stupidity
|
|
|
|