Building a Control-flow Graph using results from Objdump - TagMerge
4Building a Control-flow Graph using results from ObjdumpBuilding a Control-flow Graph using results from Objdump

Building a Control-flow Graph using results from Objdump

Asked 9 months ago
4 answers

You should use an IL that was designed for program analysis. There are a few.

The DynInst project ( has a lifter that can translate from ELF binaries into CFGs for functions/programs (or it did the last time I looked). DynInst is written in C++.

BinNavi uses the ouput from IDA (the Interactive Disassembler) to build an IL out of control flow graphs that IDA identifies. I would also recommend a copy of IDA, it will let you spot check CFGs visually. Once you have a program in BinNavi you can get its IL representation of a function/CFG.

Function pointers are just the start of your troubles for statically identifying the control flow graph. Jump tables (the kinds generated for switch case statements in certain cases, by hand in others) throw a wrench in as well. Every code analysis framework I know of deals with those in a very heuristics-heavy approach. Then you have exceptions and exception handling, and also self-modifying code.

Good luck! You're getting a lot of information out of the DynamoRIO trace already, I suggest you utilize as much information as you can from that trace...

Source: link


I found your question since I was interested in looking for the same thing. I found nothing and wrote a simple python script for this and threw it on github:

Note that I have some heuristics to deal with functions that never return, the gcc stack protector on 32bit x86, etc... You may or may not want such things.

I treat indirect calls similar to how you do (basically have a node in the graph that is a source when returning from an indirect).

Hopefully this is helpful for anyone looking to do similar analysis with similar restrictions.

Source: link


I was also facing a similar issue in the past and wrote asm2cfg tool for this purpose: Tool has support for GDB disassembly and objdump inputs and spits out CFG as a dot or pdf.

Hopefully someone finds this helpful!

Source: link


Assuming I understand the question, maybe this will get you started. Relative jumps are pc based.
d: eb 04 jmp 13
To understand how that address is computed. The pc is at 0xD when it starts to fetch the instruction, it takes two bytes, so the pc is at 0xD+2 = 0xF when it is ready to execute this instruction. The offset is 0x4 so 0xF+0x4 = 0x13 the destination address.
20: 75 ed jne f
Note these are grepped from a larger program, not sequential code, just a collection of isolated examples.
400a81:   0f 8f 07 01 00 00       jg     400b8e 
  400a8f:   0f 8f e6 00 00 00       jg     400b7b 
  400a9d:   0f 8f c5 00 00 00       jg     400b68 
  400aab:   0f 8f a4 00 00 00       jg     400b55 
  400ab9:   0f 8f 83 00 00 00       jg     400b42 
  401d76:   0f 8f 31 01 00 00       jg     401ead

Source: link

Recent Questions on c

    Programming Languages