Skip to content

Add support for large-address aware applications #21

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

Merged
merged 1 commit into from
Jun 19, 2022
Merged

Add support for large-address aware applications #21

merged 1 commit into from
Jun 19, 2022

Conversation

m417z
Copy link
Contributor

@m417z m417z commented May 5, 2022

Large-address aware applications linked with the /LARGEADDRESSAWARE flag can have a user-mode address with its upper bit set. The current code sign-extends the pointer, e.g. 87aaeb58 to ffffffff87aaeb58, leading to an invalid pointer and likely to a crash.

I discovered this due to a bug report for Windhawk:
ramensoftware/windhawk#3

I came up with a small program which triggers the bug most of the time:
https://gist.github.com/m417z/7177d820252ab42f4d86c905589b6f05

Also, a similar notice regarding 32-bit to 64-bit pointer casting can be found here:

Assigning a pointer to the Buffer member will sign-extend the value if the code is compiled as 32-bits; this can break large-address aware applications running on systems configured with 4-Gigabyte Tuning or running under WOW64 on 64-bit Windows. Therefore, use the PtrToPtr64 macro when assigning pointers to Buffer.

src/wow64ext.h Outdated
@@ -351,6 +351,10 @@ struct _CONTEXT64

#pragma pack(pop)

// Without the double casting, the pointer is sign extended, not zero extended,
// which leads to invalid addresses with /LARGEADDRESSAWARE.
#define PTR_TO_DWORD64(p) ((DWORD64)(DWORD)(p))

Choose a reason for hiding this comment

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

If this is ever called from x64 code, it will truncate the pointer

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, wow64ext is an x32-only library, but PTR_TO_DWORD64 might be helpful in generic code outside of the library. I changed the macro, should be fine now, thanks.

Copy link
Contributor

Choose a reason for hiding this comment

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

for me its ok, @rwfpl can you merge this PR?

@rwfpl rwfpl merged commit 2a5546e into rwfpl:master Jun 19, 2022
@m417z m417z deleted the large-address-aware branch June 19, 2022 18:36
@injertao
Copy link

injertao commented Jul 6, 2022

PTR_TO_DWORD64 not applicable to hProcess
When hProcess = -1

@m417z
Copy link
Contributor Author

m417z commented Jul 19, 2022

@injertao good catch. Here's a PR to fix this: #22

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.

5 participants