KeStackAttachProcess

[L. Spiro]

Hello.

I have written a driver routine that changes its thread context to make a
quick read of RAM from another process.
As the topic here suggests, it uses KeStackAttachProcess(), performs the
quick read, and leaves with KeUnstackDetachProcess().

It is generally stable—I am not trying to read kernel RAM or anything
dangerous so I don’t get any blue screens, but if the target process closes
while my thread is over there my application deadlocks so hard it can not be
closed by any means but a reboot.


Is there any sure way to prevent this?
I tried using CLI and STI but then I get blue screens whining about
privilege levels. I use KeLowerIrql( DISPATCH_LEVEL ) but I get the same
error anyway (I thought DISPATCH_LEVEL could always use CLI?).

I think I could reduce the chances of this deadlock (currently at 94%—if the
target closes, my application WILL deadlock) using
PsGetProcessExitProcessCalled() and then aborting if TRUE, but then I think
this is only reduces the chances, not eliminates them. What if the process
is closed after I call that function but before I go into it with
KeStackAttachProcess()?

Is there any way to get a brief lock that absolutely ensures the process
cannot close while I am there?


Thank you.

P. S.: I call ObReferenceObjectByHandle() before going into the target
process. This is supposed to raise the reference count on the process so it
can’t fully close, which should have been preventing my problem.
Am I being mislead?

[L. Spiro]

My mistake regarding raising the level to DISPATCH_LEVEL.
I see that while in DISPATCH_LEVEL I can not do anything to cause exceptions.
I have my code in __try/__except (as required) to safely return if I read
RAM that is not readable, which happens a lot, so I got blue screens while
running at that level.

I guess this is also a problem I would have with CLI and STI—between them I
would not be allowed to raise/catch any exceptions.


But this leaves my problem even more open than it was.
Now I really have no idea how I should go about ensuring my thread can
safely return if the target process is closing.


Any help appreciated.

[Maxim S. Shatskih]

Correct, any page faults on DISPATCH_LEVEL will cause BSODs and not AV
fault exception.

Get rid of DISPATCH_LEVEL in your design.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
***@storagecraft.com
http://www.storagecraft.com

Post by L. Spiro
My mistake regarding raising the level to DISPATCH_LEVEL.
I see that while in DISPATCH_LEVEL I can not do anything to cause exceptions.
I have my code in __try/__except (as required) to safely return if I read
RAM that is not readable, which happens a lot, so I got blue screens while
running at that level.
I guess this is also a problem I would have with CLI and STI—between them I
would not be allowed to raise/catch any exceptions.
But this leaves my problem even more open than it was.
Now I really have no idea how I should go about ensuring my thread can
safely return if the target process is closing.
Any help appreciated.

[RossettoeCioccolato]

L.

Perhaps what you need is ExAcquireRundownProtection (). The problem will be
finding pEProcess->RundownsProtect without relying on undocumented (and
frequently changing) internal structures.

Regards,

Rossetoecioccolato.

[RossettoeCioccolato]

Don't hold back, Don. Tell us what you really think! :-)

Regards,

Rossetoecioccolato.

USING CLI AND STI IN A WINDOWS DRIVER IS BRAINDEAD. This only stops
interrupts on one processor, so you are hosed anyway.
ObReferenceObjectByHandle() protects the PROCESS_OBJECT from being
deleted, it says nothing about any memory for the process.
You design is way broken, what are you trying to do at a basic level?
Cause what you have not is crap.
--

[Don Burn]

USING CLI AND STI IN A WINDOWS DRIVER IS BRAINDEAD. This only stops
interrupts on one processor, so you are hosed anyway.

ObReferenceObjectByHandle() protects the PROCESS_OBJECT from being deleted,
it says nothing about any memory for the process.

You design is way broken, what are you trying to do at a basic level? Cause
what you have not is crap.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

Post by L. Spiro
Hello.
I have written a driver routine that changes its thread context to make a
quick read of RAM from another process.
As the topic here suggests, it uses KeStackAttachProcess(), performs the
quick read, and leaves with KeUnstackDetachProcess().
It is generally stable-I am not trying to read kernel RAM or anything
dangerous so I don't get any blue screens, but if the target process
closes
while my thread is over there my application deadlocks so hard it can not be
closed by any means but a reboot.
Is there any sure way to prevent this?
I tried using CLI and STI but then I get blue screens whining about
privilege levels. I use KeLowerIrql( DISPATCH_LEVEL ) but I get the same
error anyway (I thought DISPATCH_LEVEL could always use CLI?).
I think I could reduce the chances of this deadlock (currently at 94%-if
the
target closes, my application WILL deadlock) using
PsGetProcessExitProcessCalled() and then aborting if TRUE, but then I think
this is only reduces the chances, not eliminates them. What if the process
is closed after I call that function but before I go into it with
KeStackAttachProcess()?
Is there any way to get a brief lock that absolutely ensures the process
cannot close while I am there?
Thank you.
P. S.: I call ObReferenceObjectByHandle() before going into the target
process. This is supposed to raise the reference count on the process so it
can't fully close, which should have been preventing my problem.
Am I being mislead?

[L. Spiro]

USING CLI AND STI IN A WINDOWS DRIVER IS BRAINDEAD. This only stops
interrupts on one processor, so you are hosed anyway.

I know that already; I thought I asked for a way to lock all processors here
but it seems I asked that somewhere else.
I never intended for CLI/STI to be my final solution but I wanted to test it
on my single-processor machine just to check that I am on the right trail.
Then upgrade to whatever allows me to lock all processors, but anyway I
figured out on my own that it wouldn’t work that way if I am relying on
exceptions to tell me I am reading bad memory.

ObReferenceObjectByHandle() protects the PROCESS_OBJECT from being deleted,
it says nothing about any memory for the process.

Since I was using __try/__except to catch invalid reads I wouldn’t really
care if the RAM I was reading suddenly became invalid (I am not reading
kernel RAM as I mentioned). It would throw an exception and my routine would
just carry on.
This works fine until the target process is closing. What is different
about the process during closing that causes this to happen?

You design is way broken, what are you trying to do at a basic level? Cause
what you have noW is crap.

I think that comes with the learning process.
I don’t take much offence because you are Don Burns and have a reputation
for flaming/threatening people. So they say.



It turns out my design isn’t actually crap anyway.
It actually does work, just not when reading address 0x7FFE0000.
If the target closes while I read that it deadlocks.

My plan for now is to just consider that kernel-mode starts at 0x7FFE0000
instead of 0x80000000. Solid plan?
Any other tricky addresses such as this about which I should know?



L. Spiro

[RossettoeCioccolato]

L. Spiro,

Post by L. Spiro
It actually does work, just not when reading address 0x7FFE0000.
If the target closes while I read that it deadlocks. <

But why does it deadlock, really? Is it possible that you are raising an
exception while accessing the user mode page(s) and KeUnstackDetachProcess()
is not getting called in that case? Where is KeUnstackDetachProcess() in
relation to your exception handler, inside or outside the __try...__except
block? If you comment out the code that accesses user mode memory do you
still deadlock?

Have you tried locking down the user mode memory using a MDL before
attempting to access it? This approach has the advantage of working on
multi-processor systems.

Regards,

Rossetoecioccolato.

[L. Spiro]

My code looks like this:

if ( NT_SUCCESS( NtStatus ) ) {
KeStackAttachProcess( &Process->Pcb,
&pState );

NtStatus = STATUS_SUCCESS;
__try {
NtStatus = STATUS_PARTIAL_COPY;
RtlCopyMemory( Irp->AssociatedIrp.SystemBuffer, BaseAddress,
NumberOfBytesToRead );
NtStatus = STATUS_SUCCESS;
}
__except( 1 ) {
if ( NtStatus != STATUS_PARTIAL_COPY ) {
NtStatus = STATUS_UNSUCCESSFUL;
}
}
KeUnstackDetachProcess( &pState );
}

(I verify the size of Irp->AssociatedIrp.SystemBuffer beforehand and do
other various checks so it is definitely not an overflow of that buffer or
anything simple such as that.)
So KeStackAttachProcess() is definitely always matched with
KeUnstackDetachProcess().

Post by RossettoeCioccolato
If you comment out the code that accesses user mode memory do you
still deadlock?

I haven’t tried this after discovering 0x7FFE0000 as being the cause.
Previously, removing RtlCopyMemory() saved me from some problems but I think
those were caused by other things I have since fixed and I wasn’t
specifically looking at 0x7FFE0000 then. I’ll have to try it.

Post by RossettoeCioccolato
Have you tried locking down the user mode memory using a MDL before
attempting to access it?

I haven’t yet since I have been relying on __try/__except to get out of
trouble memory spots and it has been working except for this problem.



This problem only happens on the 0x7FFE0000 chunk of shared memory, so
because of its exceptional properties I don’t know enough to really figure
out the exact cause of the deadlock or how to fix it. I also don’t want to
run away from the problem by just denying reading of that area.
Would MmProbeAndLockPages() be the solution for this (and all other)
section(s) of RAM?




After reading http://www.microsoft.com/whdc/Driver/tips/MmProbe.mspx I have
a few questions.
MmProbeAndLockPages() verifies the addresses for me, right? Which means
after I get the lock I can be sure that it will not throw any exceptions if I
read from the pointer it gives me, right?

Looking at a few examples, I don’t see how MmProbeAndLockPages() is locking
the address from where I want to read. I see examples such as this:


Mdl = MmCreateMdl(NULL,
Buffer, // <-- This is the address where they store the data after
they read it.
BytesToRead);
...
MmProbeAndLockPages(Mdl, // <- Still no lock on the data they intend to read.
PreviousMode,
IoWriteAccess);
...
KeAttachProcess(&Process);
SystemAddress = MmGetSystemAddressForMdl(Mdl);
RtlCopyMemory(SystemAddress, ReadAddress, BytesToRead);
KeDetachProcess();



In this example I fail to see how ReadAddress (the address from which they
want to read in the target process) has been locked. They locked the buffer
where they want to store the data instead, which I assume is because they
passed that address as a virtual address from the original process and they
need to make it kernel so they can write to it while in the target process.

Is this not to be used as I originally thought, or will I be safe to use
their example, but swap the lock to be the read address instead of the write
address (their example actually does the same thing my code is trying to do,
which is why I considered it a valid example).

I just want to ask this to be sure I don’t make a stupid mistake since I
haven’t used these functions yet.



Regards,
L. Spiro

[Alexander Grigoriev]

By the way, KeStackAttachProcess' first argument is PKPROCESS, not PCB.

And I would not put magic numbers into __except(). If 1 means
EXCEPTION_EXECUTE_HANDLER, you should write

__except(EXCEPTION_EXECUTE_HANDLER)

You may also want to call KeEnterCriticalRegion, to prevent your thread from
being terminated while in the process context.

Post by L. Spiro
if ( NT_SUCCESS( NtStatus ) ) {
KeStackAttachProcess( &Process->Pcb,
&pState );
NtStatus = STATUS_SUCCESS;
__try {
NtStatus = STATUS_PARTIAL_COPY;
RtlCopyMemory( Irp->AssociatedIrp.SystemBuffer,
BaseAddress,
NumberOfBytesToRead );
NtStatus = STATUS_SUCCESS;
}
__except( 1 ) {
if ( NtStatus != STATUS_PARTIAL_COPY ) {
NtStatus = STATUS_UNSUCCESSFUL;
}
}
KeUnstackDetachProcess( &pState );
}
(I verify the size of Irp->AssociatedIrp.SystemBuffer beforehand and do
other various checks so it is definitely not an overflow of that buffer or
anything simple such as that.)
So KeStackAttachProcess() is definitely always matched with
KeUnstackDetachProcess().

Post by RossettoeCioccolato
If you comment out the code that accesses user mode memory do you
still deadlock?

I haven't tried this after discovering 0x7FFE0000 as being the cause.
Previously, removing RtlCopyMemory() saved me from some problems but I think
those were caused by other things I have since fixed and I wasn't
specifically looking at 0x7FFE0000 then. I'll have to try it.

Post by RossettoeCioccolato
Have you tried locking down the user mode memory using a MDL before
attempting to access it?

I haven't yet since I have been relying on __try/__except to get out of
trouble memory spots and it has been working except for this problem.
This problem only happens on the 0x7FFE0000 chunk of shared memory, so
because of its exceptional properties I don't know enough to really figure
out the exact cause of the deadlock or how to fix it. I also don't want
to
run away from the problem by just denying reading of that area.
Would MmProbeAndLockPages() be the solution for this (and all other)
section(s) of RAM?
After reading http://www.microsoft.com/whdc/Driver/tips/MmProbe.mspx I have
a few questions.
MmProbeAndLockPages() verifies the addresses for me, right? Which means
after I get the lock I can be sure that it will not throw any exceptions if I
read from the pointer it gives me, right?
Looking at a few examples, I don't see how MmProbeAndLockPages() is
locking
Mdl = MmCreateMdl(NULL,
Buffer, // <-- This is the address where they store the data after
they read it.
BytesToRead);
...
MmProbeAndLockPages(Mdl, // <- Still no lock on the data they intend to read.
PreviousMode,
IoWriteAccess);
...
KeAttachProcess(&Process);
SystemAddress = MmGetSystemAddressForMdl(Mdl);
RtlCopyMemory(SystemAddress, ReadAddress, BytesToRead);
KeDetachProcess();
In this example I fail to see how ReadAddress (the address from which they
want to read in the target process) has been locked. They locked the buffer
where they want to store the data instead, which I assume is because they
passed that address as a virtual address from the original process and they
need to make it kernel so they can write to it while in the target process.
Is this not to be used as I originally thought, or will I be safe to use
their example, but swap the lock to be the read address instead of the write
address (their example actually does the same thing my code is trying to do,
which is why I considered it a valid example).
I just want to ask this to be sure I don't make a stupid mistake since I
haven't used these functions yet.
Regards,
L. Spiro

[L. Spiro]

Post by Alexander Grigoriev
By the way, KeStackAttachProcess' first argument is PKPROCESS, not PCB.

I always get an error when I use that and I have to cast it away (or use
what I use now). But for neatness sake I will change it back.

Post by Alexander Grigoriev
And I would not put magic numbers into __except(). If 1 means
EXCEPTION_EXECUTE_HANDLER, you should write

Actually I use a macro for my __except() which then uses
EXCEPTION_EXECUTE_HANDLER, but when I pasted it here I manually decoded my
macro into “__except( 1 )”. Otherwise I am using the correct value.

Post by Alexander Grigoriev
You may also want to call KeEnterCriticalRegion, to prevent your thread from
being terminated while in the process context

I wasn’t sure if I would need this or not. But I have to be sure of one
thing: I should only use this if I am at passive level right? Because it
raises my IRQ level and if it goes above APC I could no longer be able to
catch exceptions.
Other than that, thank you for the tip.
Might this be the solution for the problem regarding reading address
0x7FFE000 while the target closes?


Thank you,
L. Spiro

[Maxim S. Shatskih]

Post by L. Spiro
This problem only happens on the 0x7FFE0000 chunk of shared memory, so

I think this is something around MM_HIGHEST_USER_ADDRESS.

IIRC functions like ProbeForRead/Write and MmProbeAndLockPages/UserMode check
that the pointer+length is <= this address.

[RossettoeCioccolato]

Maxim,

nt!MmHighestUserAddress is 0x7ffeffff on this x86 system. So the OP
conceivably could read 1MiB starting at that address without exiting user
space. But 0x7FFE0000 is the
USER_SHARED_DATA section that is mapped into both the user and kernel
address space of every process. It's only 1 page in size on current
systems.

Why the OP would want to read this shared section using
KeStackAttachProcess() is a mystery to me. Why not just use the
SharedUserData macro and read it directly from kernel space. Perhaps the OP
is trying to build a malware scanner or something similar by reading from
process user virtual address space from 0 to MmHighestUserAddress. In that
case the design truly is flawed, as others have noted.

But perhaps the OP is simply trying to understand how things work. As for
why the shared section should behave differently from other user addresses I
am not sure that it does in this case. The problem only occurs when the
target address space is being torn down, in which case 0x7FFE0000 may no
longer be mapped to the shared section by the time the OP attempts to
dereference it.

Regards,

Rossetoecioccolato.

[L. Spiro]

Hi, “OP” here.

Post by RossettoeCioccolato
Why the OP would want to read this shared section using
KeStackAttachProcess() is a mystery to me. Why not just use the
SharedUserData macro and read it directly from kernel space. Perhaps the OP
is trying to build a malware scanner or something similar by reading from
process user virtual address space from 0 to MmHighestUserAddress.

I do not actually have an interest in that address at all actually.
I have only been using that address as a reference because it is constantly
changing and that allows me to see clearer results while I study this.
Otherwise the special properties associated with that chunk are not
significant and I already modified my driver to consider 0x7FFE000 and above
to be kernel-mode (which my driver does not allow to read). But still, this
isn’t the solution I want; it’s tacky and I want to know what the real
problem is and what the real solution should be.
I considered checking just that chunk and if found it would read the RAM
from my own process without attaching to the target, but still I question how
official this solution really is.

Post by RossettoeCioccolato
In that
case the design truly is flawed, as others have noted.

I still wish someone would propose a non-flawed design.

Even ReactOS uses this design. And they don’t lock the target address they
are going to read, they lock the *buffer* address where they will write.
Otherwise they don’t do anything special to mask out this region and they
would also get this crash if they were reading that area while the process
closed.

Post by RossettoeCioccolato
But perhaps the OP is simply trying to understand how things work.

50% is for my own understanding.
As for the other half, I am the lead programmer in a video game company. We
currently only make Nintendo DS games but in the future we may expand to PC
and video-game security is a field in which I am very interested. There is
also another game company in my area that has been interested in hiring me
for contract work in security for their gambling games.
I am interested in doing it, but the logical first step is to understand all
of this from the inside out.


Regards,
L. Spiro

Post by RossettoeCioccolato
As for
why the shared section should behave differently from other user addresses I
am not sure that it does in this case. The problem only occurs when the
target address space is being torn down, in which case 0x7FFE0000 may no
longer be mapped to the shared section by the time the OP attempts to
dereference it.
Regards,
Rossetoecioccolato.

[Maxim S. Shatskih]

Post by L. Spiro
__except( 1 ) {
if ( NtStatus != STATUS_PARTIAL_COPY ) {
NtStatus = STATUS_UNSUCCESSFUL;

Should be:

NtStatus = GetExceptionCode();

[RossettoeCioccolato]

L. Spiro,

Post by L. Spiro
KeStackAttachProcess( &Process->Pcb,

Since your code runs at all I assume that this and similar bugs are just
typographical errors and say no more.

Post by L. Spiro
In this example I fail to see how ReadAddress (the address from which they
want to read in the target process) has been locked. They locked the buffer
where they want to store the data instead, which I assume is because they
passed that address as a virtual address from the original process and they
need to make it kernel so they can write to it while in the target process.

If you look at the documentation for MmProbeAndLockPages() you can specify
IoReadAccess, IoWriteAccess, or IoModifyAccess as the lock operation. The
examples to which you refer assume that your input parameters were in memory
a few cpu cycles ago and your process address space is not going to be torn
down while you are attempting to read from them. What you are attempting to
do does not fit within the usual paradigm, as perhaps you already may have
guessed.

Post by L. Spiro
http://www.microsoft.com/whdc/Driver/tips/MmProbe.mspx...
MmProbeAndLockPages() verifies the addresses for me, right? Which means
after I get the lock I can be sure that it will not throw any exceptions if I
read from the pointer it gives me, right?

MmProbeAndLockPages() locks the physical page(s) in memory, as the reference
which you cite indicates. It does not protect the virtual address or
prevent it from being removed from the target process address space. You
can read from the system address from any process once you have successfully
probed and locked the page(s). But the physical page may no longer be in a
coherent state.

There generally is no safe way to read from or write to memory that you do
not own. The memory manager was not designed for this scenario. Rutkowska
calls this the "Memory Reading Problem (MRP)."
http://www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Rutkowska/BH-Fed-06-Rutkowska-up.pdf.
You are likely to encounter race conditions and other problems doing what
you are attempting to do.

That having been said, you might want to try MmProbeAndLockProcessPages. It
performs the following sequence for you:

KeAttachProcess();
MmProbeAndLockPages();
KeDetachProcess();

Once you have locked the process page(s) in memory you can call
MmGetSystemAddressForMdlSafe() and then RtlCopyMemory().

As a general rule you should do as little as possible while attached to
another process. Using a MDL allows you to detach before calling
RtlCopyMemory(). Of course you need to be sure to unlock the MDL when you
are done with it.

I am not saying that this design pattern is "safe" or that it should be used
in general use software. I am merely offering it as something you can try
for experimental purposes and would be interested in hearing your results.

Regards,

Rossetoecioccolato.

[J de Boyne Pollard]

DB> You design is way broken, what are you trying to do at a basic
level?
DB> Cause what you have noW is crap.

LS> I think that comes with the learning process.
LS> I don't take much offence because you are Don Burns and
LS> have a reputation for flaming/threatening people. So they say.

... without any justification for doing so. (I've never seen anyone
say that about M. Burn, and I doubt that what you state is actually
true in the first place.) Note that M. Burn wrote _nothing at all_
about you, and neither flamed or threatened you, in the above. Xe
wrote that your design is broken. If you are identifying yourself
with your design, then that is _your_ error, and no-one else's. M.
Burn certainly didn't do that.

[Mark Roddy]

Post by J de Boyne Pollard
DB> You design is way broken, what are you trying to do at a basic
level?
DB> Cause what you have noW is crap.
LS> I think that comes with the learning process.
LS> I don't take much offence because you are Don Burns and
LS> have a reputation for flaming/threatening people. So they say.
... without any justification for doing so. (I've never seen anyone
say that about M. Burn, and I doubt that what you state is actually
true in the first place.) Note that M. Burn wrote _nothing at all_
about you, and neither flamed or threatened you, in the above. Xe
wrote that your design is broken. If you are identifying yourself
with your design, then that is _your_ error, and no-one else's. M.
Burn certainly didn't do that.

Don has a well deserved reputation for being outspoken in his opinions.
His blunt honesty is sometimes mistaken for flaming, but flaming is
generally confrontation for the sake of confrontation rather then simply
being blunt and honest. The OP's design is broken and that is that.

[L. Spiro]

.... without any justification for doing so. (I've never seen anyone
say that about M. Burn, and I doubt that what you state is actually
true in the first place.)

Someone did indeed say exactly that.

Note that M. Burn wrote _nothing at all_
about you, and neither flamed or threatened you, in the above.

I used “flaming/threatening” as a quote from what someone else has said
about him.
I am fully aware that he didn’t threaten or flame *me*.
I just said that if he has a reputation for flaming or threatening, or for
being heavily outspoken as another has said, then I don’t take it personally.


L. Spiro

[Don Burn]

"L. Spiro" <***@discussions.microsoft.com> wrote in message
news:1623299B-909B-4D02-B898-

Post by L. Spiro

You design is way broken, what are you trying to do at a basic level?
Cause
what you have noW is crap.

I think that comes with the learning process.
I don't take much offence because you are Don Burns and have a reputation
for flaming/threatening people. So they say.
It turns out my design isn't actually crap anyway.
It actually does work, just not when reading address 0x7FFE0000.
If the target closes while I read that it deadlocks.

Your design is crap, since it is guaranteed to not work in a number of
cases. Note: that exception handling is not strong enough to protect you
from the blue screens.

Well you don't want my help anyway since you believe I flamed you. Note:
the people who consider me a flamer typically fall into the category of I
have to do XXX, I don't care if it destabilizes the system, so I think you
are in good company.

For the sake of the machines out there you may touch, I will ask again "what
is your overall goal, i.e. not the how to hack your code, but what is the
reason you are reaching into the process in the first place" there may be a
better way, if you will tell us then listen.

[L. Spiro]

Post by Don Burn
Your design is crap, since it is guaranteed to not work in a number of
cases. Note: that exception handling is not strong enough to protect you
from the blue screens.

Then what is, and what is the correct way to go about this?
Windows’ ReadProcessMemory() doesn’t crash when it reads 0x7FFE0000 while
the target is closing. What is it doing that is so special?

Post by Don Burn
Well you don't want my help anyway since you believe I flamed you.

I didn’t say you flamed me. I quoted another person and justified why I
won’t take personal offense.

Post by Don Burn
the people who consider me a flamer typically fall into the category of I
have to do XXX, I don't care if it destabilizes the system, so I think you
are in good company.

You might take the time to notice my spelling, grammar, and punctuation, all
of which hint at an ultra-perfectionistic condition that also forbids me from
accepting a solution that “just works”.
I am here because I need to know the 100% correct solution. I will accept
nothing that destabilizes the system.

Post by Don Burn
For the sake of the machines out there you may touch, I will ask again "what
is your overall goal, i.e. not the how to hack your code, but what is the
reason you are reaching into the process in the first place" there may be a
better way, if you will tell us then listen.

Right now there is no single specific task I need to complete with this
function (though I hope that doesn’t make you treat it less seriously).
I work in a game company and game security is one of my interests. I may
well put my knowledge to professional use later, but one criteria for doing
that would be to have the actual knowledge.


If I wanted a hack solution I could use the methods everyone else (including
ReactOS) is using (which I am only using now until I find the real solution).
But I can’t accept anything that has even a small chance of destabilization,
especially if I am to do professional work in game security (which I intend
to do).





So as I mentioned before I don’t actually care specifically about address
0x7FFE0000 (I certainly wouldn’t need a device driver if I wanted to access
it), except that it causes this problem.
You say there are tons of other situations that are guanteed to fail. What
are they? I would like to know even if I end up not using this method.
I want to know the correct method, but also why it is correct.


Regards,
L. Spiro

[RossettoeCioccolato]

L. Spiro,

Windows' ReadProcessMemory() doesn't crash when it reads 0x7FFE0000 while
the target is closing. What is it doing that is so special? <

It calls ExAcquireRundownProtection to prevent the process from closing
while its virtual address space is being accessed.

Regards,

Rossetoecioccolato.