*EDIT* since this thread changed focus to kernel driver after second page, I changed subject accordingly.
After someone posted very good link about injection techniques
(http://www.codeproject.com/system/hooksys.asp), i wrote about 10 days ago my version of keyreader that inject DLL with SetWindowsHook, and read memory with normal memory read, from inside EQ process. But after completing that, I still continued using ReadProcessMemory version.
Now after I saw t this very good stealth version of hook DLL that Maggotboy wrote, I still have same questions , namely:
1) What is way that SOE can detect using of ReadProcessMemory?
2) What is way that SOE can detect using of hooked DLL direct memory read?
3) Is it really safer using direct memory inproccess read?
My answers on those questions are reason I still use ReadProcessMemory. Maybe I'm wrong on some of those issues, thats why I'm posting this here
1) To detect call of API function, SOE needs to do exactly same techniques as described in above link, one of which is very same SetWindowsHook.So they need to first inject their code in all processes address space, and then to hook to some execution point (with SetHook on some mesages, or modifying Process Table or ..). Or, alternativelly, modify some kernel DLL or tables to hook on kernel level.
2) to detect hooked DLL, SOE need again to detect only some API function that is used in that DLL. Or it can use VirtualProtect on key data memory . Sniffer can use same VirtualProtect to unlock data, but then again SOE can detect only one API function called for area where key data is (VirtualProtect). Maggotboys example also use another API function easily detectable (SetWindowsHook with process ID of EQ itself), while my version is using global hook and is not detaching and attaching to single process so even intercepted SetWindowsHook would not point to EQ as target...but nevertheless, I still need to use VirtualProtect :\
3) It seemed to me that detecting in process DLL (which needs to use VirtualProtect) is exatly same job as detecting outprocess ( which needs to use ReadProcessMemory) -- > in both cases SOE only need to detect API CALL of 2 specific functions. Only detecting inprocess is easier since SOE does not need to do first part of all spy programs - hooking into other process. They can just change Process tables or put JMP on start of code of 2 API functions in their own addres space. And inprocess with use of VirtualProtect is more dangerous ( if wrong memory segment start is used in VirtualProtect , then it will fail and memory read will trip trigger, so sniffer will be detected even if SOE does not implement complicated API function interceptions)
Again, maybe I'm wrong on some of those issues, but so far I'll stay with ReadProcessMemory, and only will add some security measures to check memory footprint of area pointed by ReadProcessMemory pointer ... so even if SOE inject its own sniffer for that, i can detect it and not use API function.