I have a few questions which are a little beyond me and may or may not be possible...but anyway, here the are:

Is there an API call or function of some sort I could use to detect disk activity (Another program reading/writing to the disk)?

If there is a way to detect disk activity (as described above), would there be a way to find out what is being read/written to from/to the disk, and what program is reading/writing it? Basically, is there a way to intercept the information similar to the way "packet sniffers" do?

Also, is there a way to detect when a new process is created in the memory (a program is started)? And also to find information about the process, too. (Such as the program's name [i.e. "Internet Explorer"], exe name [i.e. "IE.exe"], ect...)

If anyone could either post some code or point me in a direction to find the answer to these, that would be nice :)

I also wasn't sure where to post this...so if this is the wrong place please let me know.

Thanks,
Anubis

[quote author=Anubis link=board=31;threadid=6641;start=0#msg58319 date=1083626312]
I have a few questions which are a little beyond me and may or may not be possible...but anyway, here the are:

Is there an API call or function of some sort I could use to detect disk activity (Another program reading/writing to the disk)?

If there is a way to detect disk activity (as described above), would there be a way to find out what is being read/written to from/to the disk, and what program is reading/writing it? Basically, is there a way to intercept the information similar to the way "packet sniffers" do?

Also, is there a way to detect when a new process is created in the memory (a program is started)? And also to find information about the process, too. (Such as the program's name [i.e. "Internet Explorer"], exe name [i.e. "IE.exe"], ect...)

If anyone could either post some code or point me in a direction to find the answer to these, that would be nice :)

I also wasn't sure where to post this...so if this is the wrong place please let me know.

Thanks,
Anubis
[/quote]

OK, first, get familiar with the tools from http://www.sysinternals.com, such as FileMon, and ProcExp. Those are the types of utilities I think you are wanting to write. Download them, play with them, test them out, learn how they act as you do things on the system. Then next week maybe we'll answer your question.

Note: It will most likely involve kernel drivers. You may be able to "borrow" filemon's driver and use that to grab information, but that won't show you what is actually being written, just that something is being written and who is writing it.

If you want an imperfect solution you could try loading some of your code in a dll into every process and hooking the ReadFile/ReadFileEx/WriteFile/WriteFileEx calls. That should let you see most of the regular reads and writes being done by regular apps in the system. You will not see memory mapped reads/writes. You will also not see kernel driver reads/writes.

Haha, Adron takes newbie from A directly to Z. That's so not going to help :p

[quote author=Grok link=board=31;threadid=6641;start=0#msg58362 date=1083635879]
Haha, Adron takes newbie from A directly to Z. That's so not going to help :p
[/quote]

That depends on what the objective is. Having him start doing something he won't be able to complete would be making him waste time. I like to explain the difficulties of various approaches as early as possible, so he can consider which one to choose. Or so that he can abandon the project before investing too much into it.

That's an approach. My teaching is to build on foundations to provide understanding that will be applicable in areas lateral to the current problem.

[quote author=Grok link=board=31;threadid=6641;start=0#msg58369 date=1083636650]
That's an approach. My teaching is to build on foundations to provide understanding that will be applicable in areas lateral to the current problem.
[/quote]

That works. He should notice that filemon is 50% kernel driver when he tries compiling it though ;)

[quote author=Adron link=board=31;threadid=6641;start=0#msg58355 date=1083633796]
Note: It will most likely involve kernel drivers. You may be able to "borrow" filemon's driver and use that to grab information, but that won't show you what is actually being written, just that something is being written and who is writing it.

If you want an imperfect solution you could try loading some of your code in a dll into every process and hooking the ReadFile/ReadFileEx/WriteFile/WriteFileEx calls. That should let you see most of the regular reads and writes being done by regular apps in the system. You will not see memory mapped reads/writes. You will also not see kernel driver reads/writes.
[/quote]
It would be better to hook NtReadFile/NtReadFileScatter/NtWriteFile/NtWriteFileGather in ntdll. Otherwise you may miss things like CopyFile copying data, and so on.

He'll be missing some things either way... Unless he makes a fs filter! That's what he should make!

[quote author=Adron link=board=31;threadid=6641;start=0#msg58680 date=1083782109]
He'll be missing some things either way... Unless he makes a fs filter! That's what he should make!
[/quote]
Yes, but he'll be moving significantly less when catching the system calls.

You could probably catch section view writes with some clever programming, e.g. re-protect the view to something that raises a fault on access, and use a vectored exception handler (or patch to ntdll!KiUserExceptionDispatcher) to get a crack at first-chance handling.

[quote author=Skywing link=board=31;threadid=6641;start=0#msg58781 date=1083824314]
[quote author=Adron link=board=31;threadid=6641;start=0#msg58680 date=1083782109]
He'll be missing some things either way... Unless he makes a fs filter! That's what he should make!
[/quote]
Yes, but he'll be moving significantly less when catching the system calls.

You could probably catch section view writes with some clever programming, e.g. re-protect the view to something that raises a fault on access, and use a vectored exception handler (or patch to ntdll!KiUserExceptionDispatcher) to get a crack at first-chance handling.
[/quote]

That would be likely to cause an extreme performance loss though.