Victor43,
In kernel mode you could call ZwWriteVirtualMemory to write to another process' memory but IIRC it's not exported by the kernel but you could get its address from the SSDT or locate the service index from the SSDT and use it in a direct SYSCALL / INT 0x2E yourself using asm etc. Same applies to ZwReadVirtualMemory being unexported from the kernel. Anyhow, you don't really need to use these "service" APIs since you can directly attach to the target process via its Eprocess object and do whatever you want with the process memory, you can attach with KeStackAttachProcess and when done use KeUnstackDetachProcess.
Use whatever you feel more comfortable with I guess, since you are somewhat new to writing drivers??? This is why I have mentioned a few different ways. Reading or writing to a particular process' memory using the latter method is literally as easy as calling RtlCopyMemory for example within the running process context, since you are currently within the process' address space much like an injected DLL would be for example. I hope you understand that analogy? I would suggest, as EP_X0FF already mentioned, to not do all this non-trivial hook checking / detection work in a kernel mode driver, especially since this can more easily be done from usermode with less chances of BSODing the system if implemented properly. Simply create your own kernel mode memory reading and writing routines and expose them to your usermode component(s)
Basic skeleton or pseudo code of model might look like this...
-Process calls DeviceIoControl with special control code for reading/writing to a process' address space
-Driver receives code and sees any _input_ parameters such as target process id, operation type (r/w), size of data, code area in target process which will be a virtual address, buffer to copy from or copy to depending on which operation (r/w)
-Driver takes in process id and converts this to something usable such as Eprocess object (PsLookupProcessByProcessId)
-Driver makes a call to KeStackAttachProcess using the returned pointer to Eprocess from above step
-Driver validates both target r/w address in process as well as buffer from usermode (Probing .. MmIsAddressValid .. MDLs)
-Driver uses RtlCopyMemory to copy _in_ data or copy _out_ data to/from process since now directly in process' context
-Driver calls KeUnstackDetachProcess and cleans up any memory allocations, locks etc.
I'd also recommend that you use process rundown protection when attaching to a process but this is out of the scope of this basic design
Accept nothing less than STATUS_SUCCESS
