ds,
/Pete
On 2025.03.04 03:37, LIU Hao wrote:
在 2025-03-04 01:14, Pete Batard via Mingw-w64-public 写道:
Considering that the current approach to fighting DLL side-loading
vulnerabilities for MinGW generated executables is to manually run
them through something like procmon, to see if they attempt to
Hi,
By default, the gcc generated PE binaries do not appear to have
directory entry #11, a.k.a 'Load Configuration', whereas MSVC generated
ones do:
$ objdump -x mingw/rufus.exe | grep "Load Configuration"
Entry a Load Configuration Directory
$ objdump -x vs2022/ruf
Further update to mention that this does appear to be a known ld bug
that was reported 12 years ago:
https://sourceware.org/bugzilla/show_bug.cgi?id=14339
I have therefore asked for the priority of this bug to be raised.
Regards,
/Pete
On 2024.07.16 17:45, Pete Batard wrote:
Thanks again Je
Thanks again Jemery.
I have updated my sample to include recompiling with your explicit
reference workaround, and I have just submitted the issue to the
binutils mailing list:
https://sourceware.org/pipermail/binutils/2024-July/135736.html
Regards,
/Pete
On 2024.07.11 19:43, Jeremy Drake w
wrote:
I was looking into delayload stuff a while back, and was pretty
disappointed with how it works in binutils. I suspect some sort of bug in
binutils here. Here are some random thoughts, none of which actually
help.
On Wed, 10 Jul 2024, Pete Batard via Mingw-w64-public wrote:
Hi
Hi,
# Description
This whole issue is better illustrated (and replicated) with the sample
code provided at https://github.com/pbatard/delayload and is the result
of a longstanding issue that I've been battling with when trying to use
DLL delay loading with MinGW in Rufus, per
https://github.
