I'm looking for a way to get the addresses of all the functions in a DLL in the .text section. Is there a way to do it without using a disassembler and moving through the commands? How does IDA know to identify all the functions, even if their start is not the regular "push ebp, mov ebp esp"?


  • 1
    IDA has plenty of heuristics and IDA knows to infer from a call to a location that the location is a function rather than a label or data. But it's by no means trivial, if your task is to actively avoid any kind of disassembler. So why did you use ida and disassemble if your task is to avoid the obvious tools?
    – 0xC0000022L
    Commented Apr 13, 2016 at 12:26
  • I'm trying to write a C++ code that does this. I can use a disassembler in code, but it's not powerful enough for that operations
    – Alex
    Commented Apr 13, 2016 at 13:02

1 Answer 1


You can get a list of all exported functions just by reading the PE headers. But, that won't give you any function names, or expected arguments lists (*), and it won't give you any functions that are internal to the DLL.

In the general case, the only thing you can do is start with exported functions, disassemble from there, follow jmps, and mark everything that's called as a new function and process it in the same way that you process the exported stuff. This is basically what IDA does.

As C0000022L mentioned, this is in no way trivial, especially with C++ methods that are never called directly, but only through vtable pointers, which is why even IDA gets this kind of stuff mostly right, but not completely right.

Ida has another feature though, named FLIRT - it has a database that has signatures of standard library functions for many different compilers. Which is why it can, often, identify standard library function names. But as far as i know, this is a second pass thing; first IDA identifies functions by being called from somewhere, then tries to assign names to those functions using FLIRT. Of course, this helps with standard library functions ONLY, and building this kind of database certainly needs a lot of work as well.

(*) If you're lucky, functions will be exported by name, and if you're very lucky, and the DLL was written in C++, the function name will include the signature. So there are cases when the export list is valuable. But this isn't the generic case, when a function might just be exported by ordinal.

  • One more possibility would be debug symbols, if at all available. They often - but not always - contain names of internal functions and other symbols.
    – 0xC0000022L
    Commented Apr 14, 2016 at 11:59
  • "But as far as i know, this is a second pass thing..." - Correct; FLIRT and FLAIR signatures are only applied after function boundaries have already been identified. Commented Apr 16, 2016 at 0:38

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.