| View previous topic :: View next topic |
| Author |
Message |
Rajat
Joined: 28 Mar 2004 Posts: 1718
|
Posted: Mon May 23, 2005 4:10 am Post subject: DLL Export Viewer |
|
|
This utility displays the list of all exported functions and their virtual memory addresses for the specified DLL files.
http://www.nirsoft.net/utils/dll_export_viewer.html
(Try it on corrupt's nice Cmdret dll) _________________
 |
|
| Back to top |
|
 |
corrupt
Joined: 29 Dec 2004 Posts: 2436
|
Posted: Mon May 23, 2005 5:05 am Post subject: |
|
|
Very handy. Thanks  |
|
| Back to top |
|
 |
PhiLho
Joined: 27 Dec 2005 Posts: 6721 Location: France (near Paris)
|
Posted: Tue Dec 27, 2005 3:27 pm Post subject: Dependency Walker |
|
|
| I don't know the software you recommand, but for such functionnality and (perhaps) more, I usually use Dependency Walker which is free and powerful: it can even find runtime dependencies (LoadLibrary). |
|
| Back to top |
|
 |
mario_a
Joined: 12 Dec 2004 Posts: 51
|
Posted: Sun Jan 01, 2006 8:12 am Post subject: Re: Dependency Walker |
|
|
| This is not true. Dependencies due to LoadLibrary calls are not detected by Dependency Walker. |
|
| Back to top |
|
 |
PhiLho
Joined: 27 Dec 2005 Posts: 6721 Location: France (near Paris)
|
Posted: Sun Jan 01, 2006 1:50 pm Post subject: |
|
|
Maybe I wasn't clear enough.
DW doesn't detect statically dependencies created by LoadLibrary.
This is not possible, or at least extremly difficult, supposing to disassemble the code to find a call to this library. And even then, if the name of the called DLL is dynamically built, it is not possible to know it.
But if you run the analyzed program, or a program calling the analyzed DLL, DW will be able to detect a call to LoadLibrary and know which DLL is loaded (and which functions are called).
Of course, it will detect only the DLLs called at runtime: a program may dynamically depend, say on a JPeg reading library, but if you never load such image in your testing, you will not see it.
HTH. |
|
| Back to top |
|
 |
mario_a
Joined: 12 Dec 2004 Posts: 51
|
Posted: Sun Jan 01, 2006 3:37 pm Post subject: |
|
|
| PhiLho wrote: |
DW doesn't detect statically dependencies created by LoadLibrary.
|
Dependencies created by LoadLibrary are usually not referred to as static dependencies. Static dependencies are those when a DLL is linked using an export library (.lib) file.
| PhiLho wrote: |
But if you run the analyzed program, or a program calling the analyzed DLL, DW will be able to detect a call to LoadLibrary and know which DLL is loaded (and which functions are called).
|
Sorry, I don't understand. What do you mean by "run the analyzed program, or a program calling the analyzed DLL" ? Which analyzed program are you talking about ? |
|
| Back to top |
|
 |
PhiLho
Joined: 27 Dec 2005 Posts: 6721 Location: France (near Paris)
|
Posted: Sun Jan 01, 2006 6:15 pm Post subject: |
|
|
| mario_a wrote: | | PhiLho wrote: |
DW doesn't detect statically dependencies created by LoadLibrary.
|
Dependencies created by LoadLibrary are usually not referred to as static dependencies. Static dependencies are those when a DLL is linked using an export library (.lib) file. |
I didn't wrote about static dependencies, but, statically detecting dependencies, ie. without running analyzed code.
| mario_a wrote: | | PhiLho wrote: |
But if you run the analyzed program, or a program calling the analyzed DLL, DW will be able to detect a call to LoadLibrary and know which DLL is loaded (and which functions are called).
|
Sorry, I don't understand. What do you mean by "run the analyzed program, or a program calling the analyzed DLL" ? Which analyzed program are you talking about ? |
LoadLibrary can be called from within a program ("the analyzed program") or from a DLL routine, which must be called from an external program, even if it is just RunDLL32 or AutoHotkey. AFAIK, a DLL can't run alone, it is a piece of code designed to extend a program, to be called by a program (or another DLL). So to perform a dynamic analysis of a DLL, you must have a program calling the functions inside the DLL. |
|
| Back to top |
|
 |
|