ZwWriteVirtualMemory()... (II)

On Wednesday, January 31, 2001 12:58 PM Norbert Kawulski wrote:

Hello Miguel,
are you sure you want to write into Apps memory ?

Yes. I know it sounds weird, but for my “testing purposes” it’s exactly what
I need to do. :slight_smile:

How do you know that the App is still alive ?
Consider having a DevIoControl/Read pending in the App.
This would be the normal way of data exchange between a driver and an
App.

I’m using a straightforward DispatchDeviceControl() routine…

How does the App know that you have written memory ?

…which assumes memory has been written if the returned
Irp->IoStatus.Information
value is different from 0 (it’s a very simple approach, but it works for now).

Meanwhile, I suspect Don gave me a valuable tip to the real problem:

On Wednesday, January 31, 2001 1:35 PM Don Burn wrote:

If you are trying to access memory of a process from a device
driver you need to be in the context of the process.

I know, but the case is that my driver gets hold of a PID which refers to an
application which has nothing to do with the driver itself (so you might
consider
this PID is arbitrary).

For example, if you are called from an application, you may access memory
from that application.

Yes, I already did that in my first approach (it’s easy to pass data in the
Irp->AssociatedIrp.SystemBuffer).

If you need to access memory in an arbitrary context (such as an interrupt
or DPC routine) use the various memory manager calls to create a MDL
for the region you wish to address, while you are in the context of the
process.

I’m sure you’re absolutely right, Don. The thing is that for now, I don’t need
(yet) to get into DPC stuff. I’m simply doing some research and this driver is
being used for “testing purposes”: presently, I have some (trusted) information
available to my driver:
-A given process ID (PID) and
-The virtual address (within that process context) I need to write to.

The “action” is taking place in the DispatchDeviceControl() routine. I thought
I could use the above information to gain access to the app process context,
using ZwOpenProcess() with PROCESS_VM_WRITE access; then I could
call ZwWriteVirtualMemory() to actually write into the memory location.

I wasn’t very amused to get into MDL stuff, as I haven’t studied it yet
properly. :slight_smile: But I suspect that is, in fact, the right way to go…

If you really need to access an arbitrary process context, there
are undocumented calls to attach a specific processes context,

Btw, which ones?

but I suspect as a newbie, you are not doing this.

:slight_smile: Yes, you’re right again. I don’t want to take your time on this, so could you
please give me a hint of where to start digging (DDK samples, docs, links?)?

Thank you so much both of you,

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

«Humour and love are God’s answers
to Human weaknesses»


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Miguel,

The calls you want are:

VOID KeAttachProcess (IN PEPROCESS Process);

VOID KeDetachProcess ();

the only example I know of them is from SysInternals:

http://www.sysinternals.com/ntw2k/source/fundelete.shtml

Don Burn
Windows 2000 Device Driver and Filesystem consulting.

----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Wednesday, January 31, 2001 10:01 AM
Subject: [ntdev] ZwWriteVirtualMemory()… (II)

> On Wednesday, January 31, 2001 12:58 PM Norbert Kawulski wrote:
>
> >Hello Miguel,
> >are you sure you want to write into Apps memory ?
>
> Yes. I know it sounds weird, but for my “testing purposes” it’s exactly
what
> I need to do. :slight_smile:
>
> >How do you know that the App is still alive ?
> >Consider having a DevIoControl/Read pending in the App.
> >This would be the normal way of data exchange between a driver and an
> >App.
>
> I’m using a straightforward DispatchDeviceControl() routine…
>
> >How does the App know that you have written memory ?
>
> …which assumes memory has been written if the returned
> Irp->IoStatus.Information
> value is different from 0 (it’s a very simple approach, but it works for
now).
>
> Meanwhile, I suspect Don gave me a valuable tip to the real problem:
>
> On Wednesday, January 31, 2001 1:35 PM Don Burn wrote:
>
>
> >If you are trying to access memory of a process from a device
> >driver you need to be in the context of the process.
>
> I know, but the case is that my driver gets hold of a PID which refers to
an
> application which has nothing to do with the driver itself (so you might
> consider
> this PID is arbitrary).
>
> >For example, if you are called from an application, you may access memory
> >from that application.
>
> Yes, I already did that in my first approach (it’s easy to pass data in
the
> Irp->AssociatedIrp.SystemBuffer).
>
> >If you need to access memory in an arbitrary context (such as an
interrupt
> >or DPC routine) use the various memory manager calls to create a MDL
> >for the region you wish to address, while you are in the context of the
> >process.
>
> I’m sure you’re absolutely right, Don. The thing is that for now, I don’t
need
> (yet) to get into DPC stuff. I’m simply doing some research and this
driver is
> being used for “testing purposes”: presently, I have some (trusted)
information
> available to my driver:
> -A given process ID (PID) and
> -The virtual address (within that process context) I need to write to.
>
> The “action” is taking place in the DispatchDeviceControl() routine. I
thought
> I could use the above information to gain access to the app process
context,
> using ZwOpenProcess() with PROCESS_VM_WRITE access; then I could
> call ZwWriteVirtualMemory() to actually write into the memory location.
>
> I wasn’t very amused to get into MDL stuff, as I haven’t studied it yet
> properly. :slight_smile: But I suspect that is, in fact, the right way to go…
>
> >If you really need to access an arbitrary process context, there
> >are undocumented calls to attach a specific processes context,
>
> Btw, which ones?
>
> >but I suspect as a newbie, you are not doing this.
>
> :slight_smile: Yes, you’re right again. I don’t want to take your time on this, so
could you
> please give me a hint of where to start digging (DDK samples, docs,
links?)?
>
> Thank you so much both of you,
>
> Miguel Monteiro
> xxxxx@criticalsoftware.com
> www.criticalsoftware.com
> ------------------------------------------------------------
> «Humour and love are God’s answers
> to Human weaknesses»
> ------------------------------------------------------------
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com