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. http://www.blackhat.com/html/bh-europe-01/bh-europe-01-speakers.html Halvar Flake's speech blabber looks reasonably interesting in relation to this. Cheers, Thomas Dullien
This archive was generated by hypermail 2b30 : Mon Sep 24 2001 - 08:32:33 PDT