Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update image memory region processing to support 24H2 changes #3342

Open
wants to merge 1 commit into
base: development
Choose a base branch
from

Conversation

ynwarcs
Copy link
Contributor

@ynwarcs ynwarcs commented May 2, 2024

24H2 adds hotpatching, with hotpatchable modules having an extra page mapped at the end of their image region. We previously assumed that the image region will only contain the header and executable sections, that's no longer the case.

Fixes #3338

24H2 adds hotpatching, with hotpatchable modules having an extra page mapped at the end of their image region. We previously assumed that the image region will only contain the header and executable sections, that's no longer the case.
@ynwarcs
Copy link
Contributor Author

ynwarcs commented May 2, 2024

I spent a few days tracking down where an extra page in some image regions is coming from. That ultimately resulted in this post: https://ynwarcs.github.io/Win11-24H2-CFG. It's pretty long & technical so feel free to skim over it.

Basically, there's now hotpatching on Windows 11 24H2, and most of system modules are marked as hotpatchable, which makes kernel code extend their image region by a single page. This page will store new CFG functions, presumably so that they can be hotpatched painlessly. x64dbg assumed that the image region only contains header + sections, which caused the linked bug. This fix handles that, but I made it a little more generic (i.e. we don't assume there's only going to be a single page, or even that the leftover size in the region is page-aligned), if you want me to make the checks more specific to this page, let me know. At the moment, there's only a single page but this could change in the future I guess.

One more thing to note about this page is that it's seen as committed by the debugger, but is actually not committed by the OS, causing VirtualProtect to fail. I tried to tinker around and see if I could get it to work properly, but nothing really worked. This doesn't cause any specific bugs, but stuff like e.g. software breakpoints or writing to the memory on this page doesn't work. Since the debugger doesn't report back any issues about the failure of VirtualProtect, it's not obvious why the operation failed.

MEMPAGE imageExtensionPage = {};
imageExtensionPage.mbi.BaseAddress = (PVOID)(pageBase + totalSize);
imageExtensionPage.mbi.RegionSize = pageSize - totalSize;
sprintf_s(imageExtensionPage.info, "ImageExtension");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"ImageExtension" is the name that shows up in kernel functions which deal with the extra page, hence why I named it this. If the format should be different, let's change it.

@AppVeyorBot
Copy link

Download x64dbg 1.0.1874 (commit e1eb85add9 by @ynwarcs)

@mrexodia
Copy link
Member

I think the solution should be to check for that flag + build number and insert those pages as fake pages earlier. This way other potential logic errors could be hidden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Memory map corruption on PE with FileAligment 0x1000
3 participants