Well, this becomes a 2 sided problem. The wrapper dll system assumes a wrapped dll for any dll that you want to watch. if a program uses a dll you do not wrap, of course it will not be logged. Also, dll's also import from other dll's, so if your wrapped dll calls another dll that you haven't wrapped, you won't see it. Now wrapping WinInet.dll will tell you whenever it gets loaded and potentially each export will let you know who calls what and when, in that dll. If you are looking for watching a single process, a custom (or general) debug process is in order. The Win32 debugging api offers an event whenever a debugged process loads a dll, and from this, you can tell which dll's a process is loading. This works well for both compiletime linkages and dynamic runtime linkages. You can use a program like depends.exe from the visual studio tools package that will tell you all of the compile time linkages that a single PE will use, along with the preestablished entry points that are included. This, however, will not work with dynamic runtime linkages(ie, loadlibrary/getprocaddress to a function pointer inside your program). Hopefully this clears this up a bit. Signed, Ryan Permeh eEye Digital Security Team http://www.eEye.com/Retina -Network Security Scanner http://www.eEye.com/Iris -Network Traffic Analyzer http://www.eEye.com/SecureIIS -Stop Known and Unknown IIS Vulnerabilities ----- Original Message ----- From: "Hector Herrera" <hectorhat_private> To: "Ryan Permeh" <ryanat_private>; <meghaniat_private>; <secprogat_private> Sent: Tuesday, January 08, 2002 12:24 PM Subject: Re: DLL Watching > At 11:20 AM 08/01/02 -0800, Ryan Permeh wrote: > >by using "wrapper" dll's, or api hooking, you can do this. basically, you > >create a shell dll that exports all of the same functions and each export > >logs and calls the equivilent actuall dll export. this is a software > >cracker / reverse engineer trick that has a lot of applicibility in research > >context. > > The problem with this approach is that you are assuming > that the "third party" is using the standard interfaces > to perform file i/o. > > As soon as the "third party" uses a different api, such > as the "defrag" api, then the standard file i/o dlls will > never be used, and your "wrapper" will not log the activity. > > Hector > >
This archive was generated by hypermail 2b30 : Tue Jan 08 2002 - 14:10:56 PST