Hi,
How can I change page protection from kernel, similar to VirtualProtect?
Thanks,
Anatoly.
Why do you feel the need to do that? What problem are you trying to solve?
- S
From: xxxxx@gmail.com
Sent: 6/13/2012 0:20
To: Windows System Software Devs Interest List
Subject: [ntdev] Changing memory protection attributes
Hi,
How can I change page protection from kernel, similar to VirtualProtect?
Thanks,
Anatoly.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I am dealing with some malware that took over a process. It prevents loading my dll into it. I could revert the changes it made, if I had something like VirtualProtect in kernel. I once saw a code that does something like it by changing section protection.
Can anyone help?
Here is a newsflash for you:
If you don’t want malware, your user account should not be a member of Administrators. UAC doesn’t help. Your users must be Users.
If you got malware, just blow the whole install and start from scratch. That’s the only way if your files could have been compromized while you were logged in as as Administrator account.
On 6/13/2012 2:57 PM, xxxxx@gmail.com wrote:
I am dealing with some malware that took over a process. It prevents loading my dll into it. I could revert the changes it made, if I had something like VirtualProtect in kernel. I once saw a code that does something like it by changing section protection.
Can anyone help?
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554670(v=vs.85).aspx.
However, since you are in the kernel why don’t you lock the (user mode)
memory with a MDL and remap the physical pages to a new kernel mode
virtual address with whatever protections you like.
Well, this is exactly how I did things back in my old miserable days of being Windows user. However, for this or that reason I was still getting infected on regular basis (around once in 3 month, sometimes even more
frequently). I used to think of clean reinstall as of a regular procedure - annoying but inevitable one…
Anton Bassov
wrote in message news:xxxxx@ntdev…
> I used to think of clean reinstall as of a regular procedure - annoying
> but inevitable one…
Now Win8 makes it easier 
– pa
Thanks George, I have few more questions.
The malware makes changes in dlls that are mapped to all processes. I guess when it patched this process there was a copy on write and dirty bit was not set. How can I check this?
And another question: this routine takes only NewProtect parameter. Should I take care about the previous state or this protection affects only the memory that I mapped in kernel?
Thanks,
Anatoly.
Anatoly,
On 6/15/2012 2:06 PM, xxxxx@gmail.com wrote:
I guess when it patched this process there was a copy on write and dirty bit was not set.
Correct. If the malware patched a dll then copy on write occurred and
you have a different physical page backing the VA than the rest of the
system. At least that is typically how it works. You have to attach to
the infected process, probe and lock the user VA to get the physical
pages. Then call MmGetSystemAddressForMdlSafe to get a system VA. Then
call MmProtectMdlSystemAddress to make the pages writable.
Before you attach to the target process it is a good idea to acquire
rundown protection by calling PsAcquireProcessExitSynchronization unless
you know that the process will be kept alive while you are attached
(e.g. you are processing an IRP send down from the process by a standard
means). Attaching or being attached to a process while it’s address
space is being torn down can be a most unpleasant experience.
MmProtectMdlSystemAddress changes the protection on the *system* address
which will be torn down when you close the MDL, so you don’t need to
restore the previous protection.
If copy on write was invoked shouldn’t the modified page already be
writable? After all, the “bad guy” managed to write to it.
Also, you will need to prevent process threads from attempting to
execute the patch while you are restoring the original code. You can
try freezing execution of the process threads, however, a thread might
get frozen while in the patch. Or you could just say a prayer and hope
for the best, given that your system is already screwed.
Note that I am not saying that any of this is a good idea. I am just
trying to answer your questions without passing judgement. (I realize
that this is an unusual posture for this list. )
Regards,
George.
> Note that I am not saying that any of this is a good idea.
It isn’t.
If you need to resort to MmProtectMdlSystemAddress it is quite possible that the page is still shared, not copied-on-write. Modifying shared image pages from the kernel can cause all sorts of problems. Malware may be doing it but that doesn’t mean it’s OK for everybody else to do it.
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of George M. Garner Jr. [xxxxx@gmgsystemsinc.com]
Sent: Friday, June 15, 2012 12:46 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Changing memory protection attributes
Anatoly,
On 6/15/2012 2:06 PM, xxxxx@gmail.com wrote:
I guess when it patched this process there was a copy on write and dirty bit was not set.
Correct. If the malware patched a dll then copy on write occurred and
you have a different physical page backing the VA than the rest of the
system. At least that is typically how it works. You have to attach to
the infected process, probe and lock the user VA to get the physical
pages. Then call MmGetSystemAddressForMdlSafe to get a system VA. Then
call MmProtectMdlSystemAddress to make the pages writable.
Before you attach to the target process it is a good idea to acquire
rundown protection by calling PsAcquireProcessExitSynchronization unless
you know that the process will be kept alive while you are attached
(e.g. you are processing an IRP send down from the process by a standard
means). Attaching or being attached to a process while it’s address
space is being torn down can be a most unpleasant experience.
MmProtectMdlSystemAddress changes the protection on the *system* address
which will be torn down when you close the MDL, so you don’t need to
restore the previous protection.
If copy on write was invoked shouldn’t the modified page already be
writable? After all, the “bad guy” managed to write to it.
Also, you will need to prevent process threads from attempting to
execute the patch while you are restoring the original code. You can
try freezing execution of the process threads, however, a thread might
get frozen while in the patch. Or you could just say a prayer and hope
for the best, given that your system is already screwed.
Note that I am not saying that any of this is a good idea. I am just
trying to answer your questions without passing judgement. (I realize
that this is an unusual posture for this list. )
Regards,
George.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer