{"id":100415,"date":"2018-12-06T07:00:00","date_gmt":"2018-12-06T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=100415"},"modified":"2019-03-13T00:10:52","modified_gmt":"2019-03-13T07:10:52","slug":"20181206-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20181206-00\/?p=100415","title":{"rendered":"How is it that WriteProcessMemory succeeds in writing to read-only memory?"},"content":{"rendered":"

When you call Write­Process­Memory<\/code> and tell it to write to memory that is read-only, the Write­Process­Memory<\/code> succeeds. How can that be? <\/p>\n

Because Write­Process­Memory<\/code> tries really hard to please you. <\/p>\n

As I noted some time ago, the primary audience for functions like Create­Remote­Thread<\/code> and Write­Process­Memory<\/code> is debuggers<\/a>. And when debuggers try to patch memory, it’s often for things like patching in a breakpoint instruction or doing some edit-and-continue<\/a> magic. So the Write­Process­Memory<\/code> tries really hard to get those bytes written. If the page is read-only, Write­Process­Memory<\/code> temporarily changes the permission to read-write, updates the memory, and then restores the original permission. <\/p>\n

“No need to thank me, just trying to help.” <\/p>\n

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

There is no security hole here, because the way the Write­Process­Memory<\/code> function changes the page protection is basically Virtual­Protect­Ex<\/code>, 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<\/code>‘s attempt to change the protections would fail too. <\/p>\n","protected":false},"excerpt":{"rendered":"

Because it tries really hard.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-100415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Because it tries really hard.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=100415"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/100415\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=100415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=100415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=100415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}