How is it that WriteProcessMemory succeeds in writing to read-only memory?

Xformer 10: The Atari 800 emulator has gotten a huge update
December 6, 2018
@Microsoft365 Microsoft 365
December 6, 2018

How is it that WriteProcessMemory succeeds in writing to read-only memory?

When you call Write­Process­Memory and tell
it to write to memory that is read-only,
the Write­Process­Memory succeeds.
How can that be?

Because
Write­Process­Memory tries really hard to please you.

As I noted some time ago,

the primary audience for
functions like
Create­Remote­Thread
and
Write­Process­Memory
is debuggers
.
And when debuggers try to patch memory,
it’s often for things like
patching in a breakpoint instruction
or doing some

edit-and-continue

magic.
So the
Write­Process­Memory tries really hard to
get those bytes written.
If the page is read-only,
Write­Process­Memory temporarily changes
the permission to read-write, updates the memory,
and then restores the original permission.

“No need to thank me, just trying to help.”

There is a race condition
if the target process happens to be manipulating the
page protection at the same time that
Write­Process­Memory is.
But that’s okay, because the intended audience is debuggers,
and debuggers will freeze the target process before
trying to edit its memory.

There is no security hole here, because the
way the
Write­Process­Memory function
changes the page protection is basically
Virtual­Protect­Ex,
so it will succeed only if you already could have
modified the protections yourself anyway.
If you didn’t have permission to change the protections,
then
Write­Process­Memory‘s
attempt to change the protections would fail too.

News Reporter
News Reporter
Head of Operations (Banking), Director IT Governance, Teamlead Microsoft, Service Delivery Manager. Interested in Office 365, LAMP, IT Security and much more!