[Code-Crunchers] Tiny PE new approach for using GetProcAddress

[Arkon]

You can play with the base address so it will be aligned eventually, but
that's still a big minus for this approach, especially among different
versions.

Unaligned scanning is still lesser...

rep scasd ; 2 bytes
becomes:

lbl:
inc edi ; 1 byte
cmp eax, [edi] ; 2 bytes
jnz lbl ; 2 bytes

but still investigation is required, maybe we don't need it at all.

> -----Original Message-----
> From: Peter Ferrie [mailto:pferrie at symantec.com]
> Sent: Saturday, October 21, 2006 10:22 PM
> To: code-crunchers at whitestar.linuxbox.org
> Subject: Re: [Code-Crunchers] Tiny PE new approach for using
> GetProcAddress
> 
> The problem is that you are relying on a dword-aligned value, which can
> obviously move around depending on the version.
> Still, it might be worth investigating.
> 
> ________________________________
> 
> From: Arkon [mailto:arkon at ragestorm.net]
> Sent: Fri 10/20/2006 10:26 PM
> To: Peter Ferrie; code-crunchers at whitestar.linuxbox.org
> Subject: Re: [Code-Crunchers] Tiny PE new approach for using
> GetProcAddress
> 
> 
> 
> Well, the problem with URLDownloadToFileA is that its name is too damn
> long,
> 0x13 bytes including null. So here is a new approach, let me know what you
> think. We still loadlibrary the urlmon dll, then we have the base address,
> and we load eax with a DWORD of a special value which will be a 32bits
> signature to find that URLDownloadToFileA, of course this signature won't
> be
> the start of the function itself, because the proluges usually are too
> common and are found in most of the functions, so you will have to add a
> distance-offset to the address the signature was found at. And then you
> save
> some more bytes. The serious drawback here is whether you can find a
> constant single DWORD signature with constant offset from the function
> start
> address which will be generic to work on all urlmon versions. ;)
> 
> It will be something like this:
> call [ebx+imm8] ; LoadLibraryA ;
> xchg eax, edi ; mov edi, eax ; 1 byte
> mov eax, <imm32 sig> ; 5 bytes
> repne scasd ; 2 bytes ; assumes ecx is set to some big enough garbage
> sub edi, <imm8 distance> ; 3 bytes
> 
> This is 11 bytes to get the URLDownloadToFileA address in memory.
> So we shave 8 bytes, hehe :)
> 
> We can even read the imm32 from memory, if we have another register point
> to
> it or something, so we spare 2 more bytes...
> 
> I am not sure how practical it is, but it's cool. :)
> Sometimes we write code for a specific machine, so it could be more
> practical. But then we can use the absolute function address from the
> beginning...
> Although aiming for all platforms is more challenging.
> 
> 
> > -----Original Message-----
> > From: Peter Ferrie [mailto:pferrie at symantec.com]
> > Sent: Saturday, October 21, 2006 5:59 AM
> > To: code-crunchers at whitestar.linuxbox.org
> > Subject: Re: [Code-Crunchers] Tiny PE: now 274 bytes
> >
> > Ah, that's too bad.  I didn't read the rules.
> > Okay, that will add probably 20 bytes.
> > Maybe tomorrow.
> >
> > ________________________________
> >
> > From: Gil Dabah [mailto:distorm at gmail.com]
> > Sent: Fri 10/20/2006 7:09 PM
> > To: Peter Ferrie; code-crunchers at whitestar.linuxbox.org
> > Subject: RE: [Code-Crunchers] Tiny PE: now 274 bytes
> >
> >
> >
> > That's a nice achievement.
> > But that is against the rules I posted, WinExec must not be viewable as
> > well
> > as the urlmon and other api's.
> >
> > I said only GetProcAddress and LoadLibraryA, but if that's not for the
> > challenge then fine :)
> >
> > > -----Original Message-----
> > > From: Peter Ferrie [mailto:pferrie at symantec.com]
> > > Sent: Saturday, October 21, 2006 3:19 AM
> > > To: code-crunchers at whitestar.linuxbox.org
> > > Subject: [Code-Crunchers] Tiny PE: now 274 bytes
> > >
> > > Imported WinExec avoids the LoadLibraryA call, moved "WinExec" after
> the
> > > "MZ", "kernel32.dll" and "LoadLibraryA" strings moved into the PE
> > header,
> > > "GetProcAddress" string is in the section table.
> > >
> > > _______________________________________________
> > > Code-Crunchers mailing list
> > > Code-Crunchers at whitestar.linuxbox.org
> > > http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers
> >
> >
> >
> > _______________________________________________
> > Code-Crunchers mailing list
> > Code-Crunchers at whitestar.linuxbox.org
> > http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers
> 
> _______________________________________________
> Code-Crunchers mailing list
> Code-Crunchers at whitestar.linuxbox.org
> http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers
> 
> 
> _______________________________________________
> Code-Crunchers mailing list
> Code-Crunchers at whitestar.linuxbox.org
> http://whitestar.linuxbox.org/mailman/listinfo/code-crunchers