Post by bartc
[PE file format]
Post by Robert Wessel Post by bartc
Doesn't sound too difficult. If someone were to create such a file
format from scratch, the chances are that it would be far less elaborate
than the PE32/PE32+/COFF version.
Even after you include debugging, resources, multiple ISAs, and all
that? I rather doubt it'll be much simpler.
It's difficult enough that I'm completely stuck at the minute. Maybe
somebody knows the answer. I need to locate the Import Table.
(virtualaddress = 0x8000, size = 2076)
The 0x8000 is an RVA. "The RVA is the address of the table relative to
the base address of the image when the table is loaded."
0x8000 is an offset of +32768. The EXE file is only 16KB in size. I'm
trying to locate the import info it points to, but I've no idea how to
turn that 0x8000 into the actual offset.
The data I want appears to be at 0x3400 in the file (I found it by
visually looking for the numbers reported by PEDUMP). But how do I get
from 0x8000 to 0x3400? The code size is 7680, the image base is 4194304,
the code base is 4096... none of the numbers add up!
This is why I detest having to deal with other people's over the top
(I may actually forget trying to sort out this EXE format, and use my
own format, but requiring a special EXE stub to load and run it. I may
still manage to finish it long before I've sussed out the EXE!
I can understand now why I looked at PE in the 1990s, and decided not to
you get it wrong, i may explain some things to you (i understand most parts of
it by now)
firstly, you got pe headers (a bit crappy ones), in the case of my own power dll it
ends at 0x178
the full calculation where it ends is
int pe_header_offset = *((int*) &pe_image[0x3c]);
int size_of_image_file_header = 24;
short size_of_optional_header = *((short*) &pe_image[pe_header_offset+20]);
int sections_table_offset = pe_header_offset + size_of_image_file_header + size_of_optional_header;
the sections_table_offset points where it ends, 0x178 may be typical but it depends probably on the size of a dos stub
(you yourself counted it in your own code)
then you got array/list of section info;
each of such info record has 40 bytes
number of this section is yet stored in headers at
short number_of_sections = *( (short*) &pe_image[pe_header_offset+6]);
the sections in my power dll are as my code prints it
This is Firex by fir 2017
Inspecting green.fire.dll ( 285696 bytes )
pe header offset 128 (0x0080) sections table offset 376 (0x0178)
.text 167992 bytes 58% 16 R-XI- EXECUTABLE
.data 91276 bytes 31% 64 RW-I-
.rdata 4020 bytes 1% 16 R--I-
.eh_fram 852 bytes 0% 4 R--I-
.bss 110984784 bytes 64 RW--U
.edata 6504 bytes 2% 4 R--I-
.idata 3012 bytes 1% 4 RW-I-
.CRT 24 bytes 0% 4 RW-I-
.tls 32 bytes 0% 4 RW-I-
.reloc 8436 bytes 2% 4 R--I- DISCARDABLE
R - section is readable, W - writeable, X - executable, I - initialised, U - ununitialised
the .idata would besection with imports,
at byte 20 in this 40 byte record mentioned you got int that is an file position (counted from begining of the file) of this import section in my case it is 042a00 (big number as this is after .code and .data whhich are about 300kb here) and there it is
youre confused by those RVA but you may skip it at this moment, those way above suffice.. as to those numbers youre confuse i may say that after those headers mentioned and after those list of sections you got sections placed itself..
sections are aligned typically to 0x200 (so first is expected to be typically at 0x200 or 0x400 depending how list of sections is long) but those sections when loaded in ram are typically aligned to 0x1000 (which is 4096 and relates to ram page sizes) - those pages when loaded in ram are copied under this mentioned base adress, this base adress for exa is said to be 0x00400000 * and 0x10000000 for dll,
but for dll it will vary.. RVAa are related to those base adress AFAIK..
in files hovever the adresses uset are
just byte numpers in a file
* the base adress for .code is 0x00400000
but afaik the usual entry point for code is 0x00401000 (im not 100% sure hovever) thus RVA of this entry point would be 0x1000 and so on