Re: static dll's for windows buffer overflows

Date: 09/24/01

Date: Mon, 24 Sep 2001 06:07:03 -0700
Message-ID: <>
To: Franklin DeMatto <>
Subject: Re: static dll's for windows buffer overflows

Hey Franklin,

FD> Windows buffer overflows almost always require knowledge of offsets in
FD> dll's. Even if rva is used, usually one offset is still known, to jmp to
FD> where the code is (e.g., let's say the shellcode is pointed to by eax, we
FD> need to know the offset of somewhere to jmp eax). Which dll's are the most
FD> static? For the jmp instruction, we can use any dll, as long as it has
FD> those bytes (i.e., we are not limited to kernel, user, and gdi). Which
FD> dll's are the best to use, and why?

There are of course other ways to attack the problem. If you happen to
know the exact version number of the application you're attacking, it
might be wise to use DLLs belonging to that application as they can be
version-fingerprinted remotely (e.g. Netscape Enterprise 3.6 SP2 is
announced in the banner so you know pretty well what host you're
attacking). Under NT, DLL's (especially system DLL's) can vary quite a
bit depending on SP, hotfix number and even language installed.

FD> (BTW, I would like to suggest that the term "buffer overflow" be replaced
FD> with the term "memory overwrite," as there are many forms besides buffer
FD> overflow, such as format string, malloc (0) mangling, etc. )

And especially with these new breeds of attacks more reliable ways of
exploiting them (especially under NT) seem to become available.
Halvar Flake's speech blabber looks reasonably interesting in relation
to this.

Thomas Dullien