-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Undocumented PE Header Machine Type #36364
Comments
PE headers are written by language compilers or by crossgen-like tools. So changing area to VM. |
The machine codes that are documented on MSDN are for Windows. For other OS-es, we xor them with an OS specific value so that we can prevent binaries for e.g. Linux amd64 to be used on Windows amd64 or OSX amd64. runtime/src/coreclr/src/inc/pedecoder.h Lines 90 to 104 in 61c6581
|
So 0xC020 == 0x8664 xor 0x4644 => OSX amd64 |
The issues Gabe linked to also potentially finger memmove as a reliability issue. I remember we had a bug a while back with this on Full Framework, but I don't recall offhand if it affected Core 3.1.3. |
On the
|
@gfs, can this be closed for now? Assume the memmove is a different issue than the title? |
The memmove issue is not related to the title but was a symptom. I think per @GrabYourPitchforks it was worth tracking but if you want to separate the issues for tracking and close this that's fine. |
yeah a separate issue would help with triaging appropriately. Thx |
@dotnet/jit-contrib
I discovered some PE binaries that are System packages that have undocumented machine codes. The binaries with those machine codes are linked below along with related GitHub issues in a PE header parsing library.
The documentation does not list these as possible machine type codes: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
See linked bugs also for potential issues with
memmove
causing fatal CLR crash.The text was updated successfully, but these errors were encountered: