[PATCH v3] bfd: fill in PE load config directory entry.

[LIU Hao]

在 2025-3-21 15:04, Jan Beulich 写道:
> On 20.03.2025 19:22, Jeremy Drake wrote:
>> On Thu, 20 Mar 2025, Jan Beulich wrote:
>>> Furthermore, having checked two random executables each from two random VC
>>> installations, I find that the size in the data directory and the value at
>>> the start of the referenced RVA aren't the same: In all four cases the data
>>> directory says 0x40 while the 32-bit item at the indicated RVA is 0x48.
>>
>> That's odd.  This matches what LLD does (though they do indeed do some
>> sanity checking):
>> https://github.com/llvm/llvm-project/blob/49f06075a6d298bd13564c9bffcf51281bed4962/lld/COFF/SymbolTable.cpp#L576
> 
> As one more data point, a quote from MS doc: "For Windows XP, the size must
> be specified as 64 for x86 images." It looks odd to me though that the exact
> same size is stated for both the 32- and 64-bit struct.
> 
> Since hopefully hardly anyone still cares about XP, doing what you do (and
> what llvm does) is likely fine, but imo wants to come with a code comment
> then.

There's quite a little information floating around on the Internet. Most of the materials about reverse 
engineering are in Chinese however I have found an English one which you might have a little interest [1].

It looks like SafeSEH was introduced in Visual Studio 2003 and became the default in Visual Studio 2005. 
If that's true then it's predated by Windows XP. So when XP was released, the load configure directory 
must have had a size of 64 (0x40). When SafeSEH was implemented in the operating system (around XP SP2, I 
suspect) two fields (`SEHandlerTable` and `SEHandlerCount`) were added, increasing the size of 
`IMAGE_LOAD_CONFIG_DIRECTORY32` to 72 (0x48), but perhaps the DLL loader was not updated and it was 
checking for 64, but the structure always has a `Size` field with value 72, so it must be a special case 
for the loader to handle that.


[1] 
https://www.cyberark.com/resources/threat-research-blog/a-modern-exploration-of-windows-memory-corruption-exploits-part-i-stack-overflows


-- 
Best regards,
LIU Hao
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/binutils/attachments/20250323/190b1076/attachment.sig>