On Jul  3 14:10, Jon Turney wrote:
> 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.

Ok, but you have the filename, so you can map the file and read it's
header and thus imagebase.  Still not nice, sure... but it would work
without guessing, I guess? :)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Reply via email to