* Hypothetically if the user's current directory contains a malicious DLL that DLL
could be loaded instead of the one in System32.
* Whereas the previous patch should have taken care of the one DLL referenced by
Rufus that may be vulnerable to this attack (version.dll), we nonetheless add
delay loading for all the libraries we reference as a precautionary measure.
* One can confirm that this works by using dumpbin.exe /IMPORTS to make sure
a specific DLL is delay loaded. Then putting a breakpoint in the delay load
hook should also confirm that the hook is used.
* Closes#1838
* This is part of #1838, where we need to sort the version.dll sideloading problem for MinGW.
* A subsequent patch will be applied to MSVC, to more generally delay the loading of DLLs.
* Also fix a typo with an assert expression.
* Use sources/compatresources.dll, when available, to try to detect the Windows ISO version and build.
* Also report what facility we use for formatting.
Yes!!! We are finally *much* faster than 7-zip for SHA-256, even though
we are also computing MD5 and SHA-1 in parallel. Here are some averaged
comparative results, against the 5.71 GB Win10_20H2_EnglishInternational_x64.iso
(SHA-256 = 08535b6dd0a4311f562e301c3c344b4aefd2e69a82168426b9971d6f8cab35e1):
* Windows' PowerShell Get-FileHash: 48s
* 7-zip's SHA-256 : 31s
* Rufus (64-bit release version) : 23s
* Instead of x86_32 and x86_64.
* This should aid with our appxbundle creation and if Microsoft want to
be wholly incorrect in their arch designations, who am I to judge?...
* *THIS* is what you need to do to replace Microsoft's broken SetDllDirectory("")
implementation and mitigate DLL sideloading from local directories.
* Also fix some comment typos
