On 02/07/2020 08:48, Corinna Vinschen wrote:
On Jul 2 09:43, Corinna Vinschen wrote:
On Jul 1 22:25, Jon Turney wrote:
I think this would always have been neeeded, but is essential on x86_64,
as kernel32.dll has an ImageBase of 00000001:80000000 (but is always
Great, but that shouldn't matter much given that system DLLs are
ASLRed all the time.
+parse_pe (const char *file_name, exclusion * excl_list, LPVOID base_address)
{
if (file_name == NULL || excl_list == NULL)
return 0;
@@ -104,7 +104,19 @@ parse_pe (const char *file_name, exclusion * excl_list)
}
bfd_check_format (abfd, bfd_object);
- bfd_map_over_sections (abfd, &select_data_section, (PTR) excl_list);
+
+ /* Compute the relocation offset for this DLL. Unfortunately, we have to
+ guess at ImageBase (one page before vma of first section), since bfd
+ doesn't let us get at backend-private data */
+ bfd_vma imagebase = abfd->sections->vma - 0x1000;
VirtualQueryEx? The AllocationBase is identical to the base address
of the DLL loaded at that address.
Uhm... right. Always assuming you get at the Windows process handle
from bfd...
The problem is in the opposite direction.
We have the actual base address the DLL was loaded at in the process
being dumped, and it's filename, from the LOAD_DLL_DEBUG_EVENT event.
(To my amazement) we then read that DLL using bfd, and examine it for
sections with the 'CODE' or 'DEBUGGING' flags, the address ranges
corresponding to which we believe we want to exclude from the dump.
Unfortunately, these addresses are based on the ImageBase in the PE header.
If that's different to the actual base address the PE was loaded at, we
need to adjust these addresses appropriately. But libbfd doesn't appear
to provide a public interface to get at the ImageBase.
