flat assembler
Message board for the users of flat assembler.

Index > Windows > Question about the PE32+ format

Thread Post new topic Reply to topic

Joined: 09 Nov 2018
Posts: 77
bzt 15 Nov 2018, 11:53
Hi Tomasz,

I've moved this topic into it's own thread, because I don't want to pollute the Planned file format tutorials topic. Hope you don't mind.
Tomasz Grysztar wrote:
PE+ as a format is able to handle 64-bit VAs fine. Only the RVAs are still limited to 32 bits.

I have already written about this in the tutorial, too.
Thank you for your answer! I've read the link you sent me, and it is very interesting. It describes a different PE+ than the official docs, for example here. The latter explicitly states address size is not changed, and indeed the table in the doc has only 4 bytes sizes, offsets and addresses.
Microsoft wrote:
These fields contain general information that is useful for loading and running an executable file. They are unchanged for the PE32+ format.
Later there's a reference to an 'ImageBase' field which is expanded, but linking to higher half I got 32 bit address in it (*). Also there's absolutely nothing about the expansion of 'AddressOfEntryPoint', but that supposed to be an offset instead of and address in the first place, isn't that right? But for higher half kernel I got the truncated address there (*). If PE+ is as you say (and I think you've tested your code, so I'm willing to believe) that means there's definitely a bug in the GNU toolchain.

(*) I've used gcc and cross-binutils under Linux to generate, dump and check my PE+ files. I don't have Win, so I could test my boot loader with GNU toolchain generated PEs only, that's why this topic is so interesting to me. If anybody would be kind to compile this little C code under Win in PE32+ format for me, and send the binary back for further investigation and comparision, that would really made my day!

Post 15 Nov 2018, 11:53
View user's profile Send private message Reply with quote
Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8346
Location: Kraków, Poland
Tomasz Grysztar 15 Nov 2018, 13:28
The capabilities of the format are one thing, and limitations of specific implementation another.

AFAIK, Windows is not able to load PE+ image at high base (above 4G), so if PE+ specifies a large 64-bit default base, Windows has to relocate it.

Nevertheless, the relocations in such case are processed correctly. Instruction like "mov eax,$" can contain a large 64-bit value in an image file and upon loading by Windows be fixed to contain a correct 32-bit address (corresponding to where Windows actually ends up loading the image).
Post 15 Nov 2018, 13:28
View user's profile Send private message Visit poster's website Reply with quote

Joined: 09 Nov 2018
Posts: 77
bzt 15 Nov 2018, 22:13
Thanks for the answer!

So it seems I'm walking on thin ice here. I'm sure there are people writing higher half kernels in PE+ format, so it have to be possible to do so. Even though it's not supported by standard toolchains and Win won't load it at higher half normally (that's understandable, you should never load a kernel with Windows anyway).

I'm just guessing at this point, because I mostly use ELF, I know that format much better. Also I've used the GNU toolchain to create the test PE+ files for my loader, which introduced another possible source of error. But according what you've said, it seems you'll need that manual sign extension for PE+ kernels if you map them in higher half. Thanks! Good to know!

Post 15 Nov 2018, 22:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.