Disecting a PE File
-
Thanks Harrold, Well,
m_pSH[ i ].VirtualAddress==pExportData->VirtualAddress
seems to work well with resources and import data. That does not mean that it is correct of course. Good to know that there are still people about like me who are interested in the nuts and bolts. I see too many 'IT Engineers' with high degrees in C# and other synthetic languages, who are neither interested, nor have a notion of how the machine ultimately works. By the way, would you have a link to an article about these latest versions of PE Files. I will also, in time be interested in viewing and displaying Resources, and into drilling into Obj en Lib Files. Matt Pietreck left that always as a minor issue, stating that that was all organised in 'Much the same way'. The devil is in the Detail in these things. Thanks for your contribution :)
Bram van Kampen
Normally it would work for resources, because they're often their own section .rsrc, though they could be anywhere (even outside of any section).
Bram van Kampen wrote:
By the way, would you have a link to an article about these latest versions of PE Files.
That's not really going to work, because the problem is not so much a version difference, but some made-up non-binding conventions - apparently they changed, they're also not exactly consistent across different linkers. I don't think that's really important though, it was always the case that the only reliable thing is following the RVAs from the data directory list in the NT header. Section names don't mean anything, in fact stuff can be outside of any section, then there isn't even a name.. There's something else I can link to that may be interesting, namely this list of weird things you can do with PE files[^], it's pretty wild what you can get away with in the PE format.
-
Normally it would work for resources, because they're often their own section .rsrc, though they could be anywhere (even outside of any section).
Bram van Kampen wrote:
By the way, would you have a link to an article about these latest versions of PE Files.
That's not really going to work, because the problem is not so much a version difference, but some made-up non-binding conventions - apparently they changed, they're also not exactly consistent across different linkers. I don't think that's really important though, it was always the case that the only reliable thing is following the RVAs from the data directory list in the NT header. Section names don't mean anything, in fact stuff can be outside of any section, then there isn't even a name.. There's something else I can link to that may be interesting, namely this list of weird things you can do with PE files[^], it's pretty wild what you can get away with in the PE format.
Hi, Well I agree that section names are meaningless. and that different Compilers and Linkers have their own ways and means. However, there must be documentation about what
Kernel32::LoadLibrary(...};
and
Kernel32::GetProcAddress(...)
expect a PE File to look like, and what it natively expects. It is that sort of documentation that I am after. The Section Table still serves a useful purpose. The PE File is not a memory image of the loaded executable. Trivial areas, such as the BSS, are typically left out of the File, but included in the memory image. The Section table informs the loader where to load each section, irrespective of the Name. The User (Program Writer) may also include Zero Set named sections of interest, for instance an unlimited number of named data sections which are shared between instances (Ouch..., but apparently Allowed). After this loading the Data Directory List points indeed to the correct RVA for each item. The thing is here too, that if something is allowed by the specification, however daft, some one some where in the world may just try that at some time. So, in essence when we get an RVA from the data directory, it appears that we have to decide whether the RVA points into a section,(in which case we need an adjustment to compensate for the loading position vs file position) or, it is an RVA into the File. To muddy the waters further, we may have absolute or relative addressing in a File. In the former case, a relocation may be applied to the RVA. To muddy it further again, DllMain() may modify a lot of daft things. I will probably end up using LoadLibrary() to dig deeper, but, at least as a first sanity check, I need to load the file manually, if for no other reason as to investigate why for instance LoadLibrary() fails on a PE File. Afterall, the purpose of the tool I'm trying to write is not to show that everything is working perfectly, it is to provide a rich environment in which to take things apart to get to the bottom of a problem. Friendly thanks for your reply, :)
Bram van Kampen
-
Hi, Well I agree that section names are meaningless. and that different Compilers and Linkers have their own ways and means. However, there must be documentation about what
Kernel32::LoadLibrary(...};
and
Kernel32::GetProcAddress(...)
expect a PE File to look like, and what it natively expects. It is that sort of documentation that I am after. The Section Table still serves a useful purpose. The PE File is not a memory image of the loaded executable. Trivial areas, such as the BSS, are typically left out of the File, but included in the memory image. The Section table informs the loader where to load each section, irrespective of the Name. The User (Program Writer) may also include Zero Set named sections of interest, for instance an unlimited number of named data sections which are shared between instances (Ouch..., but apparently Allowed). After this loading the Data Directory List points indeed to the correct RVA for each item. The thing is here too, that if something is allowed by the specification, however daft, some one some where in the world may just try that at some time. So, in essence when we get an RVA from the data directory, it appears that we have to decide whether the RVA points into a section,(in which case we need an adjustment to compensate for the loading position vs file position) or, it is an RVA into the File. To muddy the waters further, we may have absolute or relative addressing in a File. In the former case, a relocation may be applied to the RVA. To muddy it further again, DllMain() may modify a lot of daft things. I will probably end up using LoadLibrary() to dig deeper, but, at least as a first sanity check, I need to load the file manually, if for no other reason as to investigate why for instance LoadLibrary() fails on a PE File. Afterall, the purpose of the tool I'm trying to write is not to show that everything is working perfectly, it is to provide a rich environment in which to take things apart to get to the bottom of a problem. Friendly thanks for your reply, :)
Bram van Kampen
Here's some documentation from microsoft: [http://go.microsoft.com/fwlink/p/?linkid=84140\](http://go.microsoft.com/fwlink/p/?linkid=84140) But it doesn't really go into the corner cases. It's more focused on documenting how they think the PE format should be used than on documenting just what sort of insanity is actually accepted by the loader (which of course varies per version of windows). As far as I know MS doesn't even document that, I've only seen it in places such as corkami's github and places that talk about analysis of malware. For example, sections can actually overlap each other in virtual space (wat), with sections that are later in the section table apparently just overwriting the mapping created for an earlier section that extends further than where the later section begins - MS does not even seem to acknowledge that such a thing is possible. Here's an other description of the PE format by corkami, including a lot of useful practical notes (or gory details..) and references to the POCs in the list I linked before: [docs/PE.md at master · corkami/docs · GitHub](https://github.com/corkami/docs/blob/master/PE/PE.md)
-
Hi, Well I agree that section names are meaningless. and that different Compilers and Linkers have their own ways and means. However, there must be documentation about what
Kernel32::LoadLibrary(...};
and
Kernel32::GetProcAddress(...)
expect a PE File to look like, and what it natively expects. It is that sort of documentation that I am after. The Section Table still serves a useful purpose. The PE File is not a memory image of the loaded executable. Trivial areas, such as the BSS, are typically left out of the File, but included in the memory image. The Section table informs the loader where to load each section, irrespective of the Name. The User (Program Writer) may also include Zero Set named sections of interest, for instance an unlimited number of named data sections which are shared between instances (Ouch..., but apparently Allowed). After this loading the Data Directory List points indeed to the correct RVA for each item. The thing is here too, that if something is allowed by the specification, however daft, some one some where in the world may just try that at some time. So, in essence when we get an RVA from the data directory, it appears that we have to decide whether the RVA points into a section,(in which case we need an adjustment to compensate for the loading position vs file position) or, it is an RVA into the File. To muddy the waters further, we may have absolute or relative addressing in a File. In the former case, a relocation may be applied to the RVA. To muddy it further again, DllMain() may modify a lot of daft things. I will probably end up using LoadLibrary() to dig deeper, but, at least as a first sanity check, I need to load the file manually, if for no other reason as to investigate why for instance LoadLibrary() fails on a PE File. Afterall, the purpose of the tool I'm trying to write is not to show that everything is working perfectly, it is to provide a rich environment in which to take things apart to get to the bottom of a problem. Friendly thanks for your reply, :)
Bram van Kampen
-
Lots of information around: msdn: pe file structure - Google Search[^].
Well Richard, Thanks for the links. However, it leads either to Old Documentation (1999), or CE formats. I have the Old Formats already, via the books of Matt Pietrek. Other persons have also contributed, and I have now written a suite of functions that extract imports and exports. The next step is to extract and show resources. Matt Pietrek found that too trivial an issue to pass any remarks on. I suppose it wil take a bit more hard slogging. Regards :)
-
Well Richard, Thanks for the links. However, it leads either to Old Documentation (1999), or CE formats. I have the Old Formats already, via the books of Matt Pietrek. Other persons have also contributed, and I have now written a suite of functions that extract imports and exports. The next step is to extract and show resources. Matt Pietrek found that too trivial an issue to pass any remarks on. I suppose it wil take a bit more hard slogging. Regards :)
Well Bram, The second link from that Google search leads to Download WHDC White Papers and Documentation from Official Microsoft Download Center[^], which includes a document that descripes PE format, dated June 20, 2017. And getting the resources from any executable is indeed a trivial matter, using the LoadLibray[^] and EnumResourceTypes[^] functions.
-
Well Bram, The second link from that Google search leads to Download WHDC White Papers and Documentation from Official Microsoft Download Center[^], which includes a document that descripes PE format, dated June 20, 2017. And getting the resources from any executable is indeed a trivial matter, using the LoadLibray[^] and EnumResourceTypes[^] functions.
Well Richard, Thanks again. I am avoiding LoadLibrary(..), EnumerateResources(..), LoadResource()and similar kernel functions, because I am trying to write a tool that can analyse what went wrong where any of these kernel functions fail. The Kernel functions on an end user computer do not allow for debugging there and then. [Download WHDC White Papers and Documentation from Official Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=19509) looks interesting, but, points me to a site where after selecting Download, I get a Picture Page, prompting me to select a Download, but no way of selecting anything. Very, Very Interested to get a view of this document. Regards, :)
Bram van Kampen
-
Well Richard, Thanks again. I am avoiding LoadLibrary(..), EnumerateResources(..), LoadResource()and similar kernel functions, because I am trying to write a tool that can analyse what went wrong where any of these kernel functions fail. The Kernel functions on an end user computer do not allow for debugging there and then. [Download WHDC White Papers and Documentation from Official Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=19509) looks interesting, but, points me to a site where after selecting Download, I get a Picture Page, prompting me to select a Download, but no way of selecting anything. Very, Very Interested to get a view of this document. Regards, :)
Bram van Kampen
Bram van Kampen wrote:
LoadResource()and similar kernel functions
They are nothing to do with the kernel, but part of the Windows API. If you click your mouse to the left of the document name on the picture page until a sort of square appears, you then get the Next button lighting up so the download works. Took me a couple of seconds to figure out.
-
Bram van Kampen wrote:
LoadResource()and similar kernel functions
They are nothing to do with the kernel, but part of the Windows API. If you click your mouse to the left of the document name on the picture page until a sort of square appears, you then get the Next button lighting up so the download works. Took me a couple of seconds to figure out.
Well, I Agree that some of the mentioned functions are actually part of the Windows API. Nevertheless, I still want to load a PE File and analyse it on my own terms for my stated reasons. By the way, LoadLibrary() is definitely a Kernel function (in as my Program shows, Kernel32.dll). When clicking the Download button on the MS Website, I get a screen which states that I have No File selected for downloading. (Download Summary: You have not selected any file(s) to download. Total Size=0) I have a List: CIDPrintDev.docx 46 KB 32-64bit_install.docx 47 KB OS_Desc_Ext_Prop.zip 144 KB pecoff.docx 206 KB Left clicking anywhere gives me the choice of Select All, or, Print All. The latter just prints this page with the list. The site does not allow me to select the 'pecoff.docx' in any way whatsoever. Spent most of last Saturday and Sunday on trying, Don't understand what is wrong. Could you perhaps send it to me by email? Regards :)
Bram van Kampen
-
Well, I Agree that some of the mentioned functions are actually part of the Windows API. Nevertheless, I still want to load a PE File and analyse it on my own terms for my stated reasons. By the way, LoadLibrary() is definitely a Kernel function (in as my Program shows, Kernel32.dll). When clicking the Download button on the MS Website, I get a screen which states that I have No File selected for downloading. (Download Summary: You have not selected any file(s) to download. Total Size=0) I have a List: CIDPrintDev.docx 46 KB 32-64bit_install.docx 47 KB OS_Desc_Ext_Prop.zip 144 KB pecoff.docx 206 KB Left clicking anywhere gives me the choice of Select All, or, Print All. The latter just prints this page with the list. The site does not allow me to select the 'pecoff.docx' in any way whatsoever. Spent most of last Saturday and Sunday on trying, Don't understand what is wrong. Could you perhaps send it to me by email? Regards :)
Bram van Kampen