Re: [DynInst_API:] Indirect Control Flow Target Deduction in CFG


Date: Tue, 05 Dec 2017 08:26:05 -0600
From: Xiaozhu Meng <mxz297@xxxxxxxxx>
Subject: Re: [DynInst_API:] Indirect Control Flow Target Deduction in CFG
Hi Buddhika,

Using backward slicing to resolving indirect calls is possible, but there is no guarantee that this would work in general. For example, a common pointer-based control flow pattern is to call a callback function passed in as a function pointer. Calling such function pointer leads to an indirect call in the binary. However, when we perform backward slicing on the indirect call, we will need to slice across function boundary to determine where the function pointer comes from. Inter-procedural slicing is very expensive. In addition, even inter-procedural slicing does not guarantee to find all indirect call targets as it is also possible that the function pointer may comeÂfrom other libraries or executables. It is in general very difficult to accurately, statically resolve indirect call targets. I guess you have a better chance if you focus on specific types of indirect calls, such as the ones implementing virtual function calls.

Your comment on providing examples in the repository is helpful. I will try to add stand-alone complete code files.

Thanks,

--Xiaozhu

On Sun, Dec 3, 2017 at 5:20 PM, Buddhika Chamith Kahawitage Don <budkahaw@xxxxxxxxxxxx> wrote:
Hi Xiaozhu,

Thanks for the reply. I see DataFlow API supports certain kind of analyses like backward slices. Do you think they would be helpful with indirect calls etc? It would really help if these examples in the documentation are available in the Dyninst repository in the form of executable examples. I find it bit hard to piece together whole working code from the snippets in the documentation at some places.

Thanks
Buddhika


On Mon, Nov 13, 2017 at 9:37 AM, Xiaozhu Meng <mxz297@xxxxxxxxx> wrote:
Hi Buddhika,

I am sorry for the late response. In terms of how ParseAPI handle indirect control flows, ParseAPI will try to resolve indirect jumps and if these indirect jumps correspond to a switch statement in the source code, ParseAPI typically can finds the indirect jump targets. You can get these targets by traverse the control flow graph, as shown in the example of the ParseAPI manual and you can check the edge type of control flow edges to determine whether they are indirect or not. For indirect calls and indirect tail calls, ParseAPI has little support to resolve their targets.Â

For your purpose of implementing a control flow integrity prototype, you either allow indirect calls to call all functions (disallowing calling any non-function-entry address), or you will need to do other analysis on top of Dyninst to better estimate the possible call targets.Â

Hope this helps.Â

Thanks,

--Xiaozhu

On Fri, Nov 10, 2017 at 7:56 AM, Buddhika Chamith Kahawitage Don <budkahaw@xxxxxxxxxxxx> wrote:
Hi All,

I am thinking of implementing a control flow integrity prototype for which I require doing some static analysis to approximate control flow targets of indirect control flow instructions.Â

How does parseAPI handle indirect control flows when deriving the CFG? What facilities does the API provide me order to obtain such information? (e.g: which control flows are indirect and what are the possible targets given an indirect control flow instruction)

Regards
Buddhika

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api



[← Prev in Thread] Current Thread [Next in Thread→]