Cheat Engine

[Polynomial]

I'm developing an application that needs to be notified on every thread startup on the system. As such I have a driver that uses PsSetCreateThreadNotifyRoutineEx to make a callback. Right now I'm sending information about new threads to DbgView via the kernel debugging APIs. What I want to do is have an event-driven system in my user-mode application (written in C#) that is notified of new threads.

I had my C# application use the NamerPipeServerStream class to create a new named pipe. I signal the driver to say that the named pipe has been created using DeviceIoControl. The named pipe on the user application side performs async reads. When new data comes in, the application shows the data in a message box.

In the driver I use ZwCreateFile to open a handle to the named pipe, then ZwWriteFile to send the data. Unfortunately something seems to be going wrong, since the data never reaches the usermode application.

Here's my code:

[Dark Byte]

What is the return value of ZwWriteFile ?

and the createfile parameters might be wrong (you set it up as a blocking call correct ?)

[NoMercy]

Why don't you call DeviceIOControl, with as inpur buffer a void pointer (void*) and then parse in the driver the string into that pointer, and the usermode apllication has the value to.

[Polynomial]

@NoMercy
That's a pretty unreliable method, since it relies on a shared memory block. It's a synchronization nightmare. Add in problems caused by GC and unpinned managed memory and it becomes a disaster.


Anyway, I ended up going a different route. My code uses a global event which is acknowledged by the user-mode application, which then follows it up with a DeviceIoControl call to get the parameters of the event.

In order to prevent preemption problems (e.g. second event raised before user-mode app can read event info from DeviceIoControl) I'm using a KEVENT which blocks the process notification callback until an IRP comes in to ask about the event. For safety I set a timeout of 500ms on process create routine event and a timeout of 1000ms on thread create routine event (thread create requires two IRPs from the userland app) so it doesn't hang if you kill the app. The problem is that it seems to sometimes take longer than 1 second to go from ZwSetEvent on the global event, to the user app, back to the driver via DeviceIoControl and KeSetEvent. This seems a little excessive, even for the managed part of it. Any ideas what might be causing this latency?

[Polynomial]

Ok, so it turns out (for some reason) my wait thread was synchronous between event wake-ups and took quite a while to complete an iteration. Probably related to switching between a native callback and managed code. I created 25 wait threads and that seems to have solved the problem.