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

Memory map corruption on PE with FileAligment 0x1000 #3338

Open
Vityacv opened this issue Apr 17, 2024 · 1 comment · May be fixed by #3342
Open

Memory map corruption on PE with FileAligment 0x1000 #3338

Vityacv opened this issue Apr 17, 2024 · 1 comment · May be fixed by #3342
Labels
bug The issue describes a bug. It does not mean the bug has been reproduced by a developer.

Comments

@Vityacv
Copy link

Vityacv commented Apr 17, 2024

Operating System

Windows 11, Build 24h2 26100.1

x64dbg Version

snapshot_2024-04-11_18-47.zip

Describe the issue

Memory map on new windows build on pe's with FileAlignment 0x1000 (almost all modules have it now):

Size=00000000000C8000
Party=System 
Page Information=kernel32.dll, ".text", "fothk", ".rdata", ".data", ".pdata", ".didat", ".rsrc", ".reloc"
Allocation Type=IMG
Current Protection=-R--- 
Allocation Protection=ERWC-
 
Address=00007FF6B4AA0000
Size=000000000005B000
Party=System 
Page Information=notepad.exe, ".text", "fothk", ".rdata", ".data", ".pdata", ".didat", ".rsrc", ".reloc" 
Allocation Type=IMG
Current Protection=-R--- 
Allocation Protection=ERWC-
 
Address=00007FF8C7430000
Size=0000000000256000
Party=System 
Page Information=ntdll.dll, ".text", "SCPCFG", "SCPCFGFP", "SCPCFGNP", "SCPCFGES", "RT", "PAGE", "fothk", ".rdata", ".data", ".pdata", ".mrdata", ".00cfg", ".rsrc", ".reloc"
Allocation Type=IMG
Current Protection=-R--- 
Allocation Protection=ERWC-

Normally you should see:

Address=00007FF641C00000 
Size=0000000000001000 
Party=User
Page Information=x64dbg.exe 
Allocation Type=IMG 
Current Protection=-R---
Allocation Protection=ERWC- 
Address=00007FF641C01000
Size=0000000000012000 
Party=User
Page Information=".text"
Allocation Type=IMG 
Current Protection=ER---
Allocation Protection=ERWC- 
Address=00007FF641C13000
Size=000000000000A000 
...

Steps to reproduce

  1. Launch debugger and check memory map

Attachments

No response

@Vityacv Vityacv added the bug The issue describes a bug. It does not mean the bug has been reproduced by a developer. label Apr 17, 2024
@ynwarcs
Copy link
Contributor

ynwarcs commented Apr 26, 2024

Can reproduce it as well on 24H2 26080.1. The problem seems to be the extra 0x1000 bytes in the page region that contains the module, which doesn't end up matching x64dbg's calculations as to how big the region should be. Here's an example by running calc.exe & checking windows.energy.dll:

  • The module has 8 sections (not incl. the header), when each section is aligned, the total size comes out to 0x43000 bytes, which is different than the size of the region, which is 0x44000 bytes.
  • This makes the two sizes mismatch during the checked performed in https://github.com/x64dbg/x64dbg/blob/development/src/dbg/memory.cpp#L263. Then the memory map is deemed invalid.

In contrast with earlier builds, the region size always matches the total size calculated by x64dbg, there's no extra memory at the end, which can be seen in the memory view as well.

I don't have time to debug what the extra memory represents, but maybe someone will have a better idea, you can check the dump in the screenshot below. To fix the problem, maybe we can also handle the case where the region is larger than the total size of the sections, and mark the remaining memory in a special way?

Sections of the module:
section_windows_energy_24H2

Current page info:
currentPage_windows_energy_24H2

Extra memory structure:
extramemory_windows_energy_24H2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue describes a bug. It does not mean the bug has been reproduced by a developer.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants