5

Are there techniques for dynamic analysis of shared libraries? I know for example that DLLs have an entry point, but how about calling other exported functions? Do I need to write a custom executable that calls exports for each DLL I want to analyze?

Improve this question
3
  • 1
    The question is kind of vague. A dynamically linked library has the same executable header and structure as a standard executable. Therefore they can be debugged the same way that a normal executable can be debugged. It might be a bit tricker than usual, because in order to debug it, it has to be loaded into some process, and making that happen could be trivial (i.e. if it's loaded as part of some other program) or it might take some doing. A common technique is to use something like OllyDbg's LoadDll, or write a small program to load the DLL and call interesting exports manually.
    – Rolf Rolles
    Commented May 31, 2013 at 4:27
  • Ok, I see! I just want to avoid having to code up something manually. I was not aware of LoadDll from OllyDbg. I also think it would be cool if there were a tool to automatically generate the program to load the DLL and call exports, with various permutations on the arguments. Edit: If you make your comment an answer I would be happy to accept it.
    – user2142
    Commented May 31, 2013 at 4:38
  • Assuming that you have a DLL and also an application that uses that DLL, you could create a proxy DLL that allows you to monitor and debug each and every call made from the application towards the original DLL.
    – Till
    Commented May 31, 2013 at 9:56

4 Answers 4

Reset to default
8

A dynamically linked library has the same executable header and structure as a standard executable. Therefore they can be debugged the same way that a normal executable can be debugged. It might be a bit tricker than usual, because in order to debug it, it has to be loaded into some process, and making that happen could be trivial (i.e. if it's loaded as part of some other program) or it might take some doing.

A common technique is to use something like OllyDbg's LoadDll. The linked page describes a few examples of calling exports within the DLL directly. Although OllyDbg has some smarts to determine the number of function arguments, it's likely that you will have to do some reverse engineering to figure out what the types of those arguments should be. See this recent question for some advice on how to go about doing that.

Alternative, you can write a small program to load the DLL and call interesting exports manually. This is still subject to the limitations of needing to know how to interface with the DLL, but at the same time, this programming route might prove necessary in order to thoroughly reverse engineer your target. I.e., perhaps you need to call some export in order to create some object that the program is expecting as input for another export. LoadDll will quickly prove cumbersome, and writing this program really ought not to be that difficult.

Improve this answer
2
  • 1
    Would it also be possible to load it using run32dll.exe? I've done this in the past in order to monitor any changes after it's loaded into memory, but not sure if this would also allow you to debug it.
    – Brandon Young
    Commented May 31, 2013 at 13:49
  • 1
    @Brandon You can use rundll32.exe to load and debug if you really want. You would do so in Olly by opening rundll and supplying the right arguments. Then under options, then debug options in the events tab, select break on new modules. Pull up the loaded modules by selecting the 'E' button, then hit F9 till your DLL is loaded in the list. Now right click, dump in CPU then break on the entrypoint of your known export. Deselect your debug option and then run and you should ideally hit your BP. This way is more effort than it's worth IMO, but good to know, there are many ways to skin a cat :)
    – Elias51
    Commented Jun 1, 2013 at 11:39
2

Another method might be using IDA's AppCall feature: After defining a prototype for the relevant exported functions in IDA, you could trigger the function's execution from the IDA console menu in the currently running process's context.

you can more about how this feature works and how to use it in the hexblog relevant post: http://www.hexblog.com/?p=113.

Improve this answer
2

DynamoRIO could be very good for more in-depth dynamic library analysis. DynamoRIO is a dynamic binary translator that works on both Linux and Windows, for both x86 and x86-64.

To analyse DLLs using DynamoRIO, you would register module load and unload events using the dr_register_module_load_event and dr_register_module_unload_event functions, respectively.

You can also register events that allow you to manipulate instructions before they are executed. These events would enable you to isolate code that is executed from a particular DLL, and apply custom instrumentation to that DLL.

Improve this answer
1

The first naive idea would be to list the symbols of the functions and use it as entrypoints to the binary to disassemble each function.

Then, if you are looking for more advanced techniques, you should take a look at the IDA FLIRT signatures. There have been a question about it here, I recommend you to take a look at the answers: What is a FLIRT signature?

Improve this answer
2
  • 2
    Well, the questioner did specifically ask about dynamic analysis, and your answer is purely from a static perspective...
    – Rolf Rolles
    Commented May 31, 2013 at 7:46
  • The questioner did not really explain very well what he wanted and why his question was bound to dynamic analysis only.
    – perror
    Commented May 31, 2013 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.