Re: [DynInst_API:] Function Entry Point Recognition in Stripped Binaries

[Bill Williams <bill@xxxxxxxxxxx>]

On 01/06/2016 02:15 PM, Shuai Wang wrote:

Hello Bill,

Thank you for your information. I am wondering, besides the machine learning-based method, is there any other mechanism implemented in DynInst?Â

For example, would you consider address 0x80102030 is a function entry point if a call instruction (call 0x80102030) can be found in the disassembled output?

Naturally; we use the entry point of the binary, available function symbols, and internal control flow to generate function entry points as well. The machine learning approach is used to cover the gaps in the binary where authoritative information is missing.

(And, of course, we also use the calls made by functions that are discovered through gap parsing to find further function entry points. The rationale here is derived from Nate Rosenblum's earlier gap parsing work; the intuition is that if code reachable from a likely (probability P) FEP F includes "call G", G is a FEP with probability Q >= P.)

--bw

Sincerely,

Shuai

On Wed, Jan 6, 2016 at 12:08 PM, Bill Williams <bill@xxxxxxxxxxx> wrote:

On 01/06/2016 10:43 AM, Shuai Wang wrote:

Dear list,

I am writing to ask how to use DynInst to recognize function entry points (memory addresses) in stripped binaries.

I successfully installed the 32-bit DynInst 9.10, and I use a DynInst script to iterate all the functions with the following commands to dump all the function entry point addresses from stripped binaries.

          Â.......

          Âvector<BPatch_module *> * modules = appImage->getModules();

          Â......Â

          Âvector<BPatch_function *> * funcs = (*module_iter)->getProcedures();

          Âvector<BPatch_function *>::iterator func_iter;

          Âfor(func_iter = funcs->begin(); func_iter != funcs->end(); ++func_iter) {

             char functionName[1024];

             (*func_iter)->getName(functionName, 1024);

             cout << "-- Function : " << functionName << " --" << endl;

          Â......Â

I extract the function entry point addresses from the function names. Â Â Â Â Â Â Â Â Â ÂÂ

I test some LLVM compiler CoreUtil binaries with O2 optimization level. And the precision/recall rate is general very good! ÂPrecision: 0.99; ÂRecall: 0.91

According to this paper, Section 6.2, on average DynInst can have over 0.97 precision, and 0.93 recall on 32-bit ELF binaries. It is very consistent with my test! But still, I am not sure whether I did everything correct.Â

So here are my questions:

1. It seems that by leveraging machine learning method to recognize functions, DynInst needs a training process before recognition, but I didn't do any training Â(although the results are pretty good), is there anything in particular I have to do before using DynInst?Â

The training step has been done once and the resulting model is baked into the Dyninst code base. Your experimental setup should be correct.

2. If there is a "pre-trained" model installed in DynInst 9.10 already, what kind of binaries does this model include? For example, can I use it to test 32-bit ELF binaries compiled from LLVM with O3? or ICC with O3?Â

Dyninst was trained on the test set of binaries produced by the BAP group at CMU, which includes binutils and coreutils binaries built with gcc and icc at O0 through O3 (as well as Windows binaries, though that's of course producing a separate model). I expect the model to generalize decently to LLVM binaries, and we'd be interested to hear your results. Our initial indications are that these models, applied to modern compiler versions, are not terribly sensitive to the toolchain used.

--bw

Am I clear enough? I appreciate if anyone can give me some help!

Sincerely,

Shuai

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