Hi Shuai, On Fri, Jan 23, 2015 at 9:37 AM, Shuai Wang <[email protected]> wrote:
> By the way, is there any published paper addressing the "statically > disassemble" ability of Dyninst? > > We are writing a paper that covers some latest improvement of Dyninst on statically analyzing binaries. However, the latest published paper on this topic dates back to 2005 ( ftp://ftp.cs.wisc.edu/paradyn/papers/Harris05WBIA.pdf). Many aspects of Dyninst have changed since then. > Thank you a lot! > > On Thu, Jan 22, 2015 at 11:10 PM, Shuai Wang <[email protected]> > wrote: > >> Dear Xiaozhu, >> >> Thank you a lot for your detailed explanation. Now I am much clearer on >> how Dyninst works. >> >> Would you mind to clarify some other details about Dyninst? I really >> appreciate your help! >> >> 1. How Dyninst maintain data dumped from stripped binaries? For example, >> suppose global pointers referring to other global variables and functions >> exist in data sections of original program. As only concrete memory >> addresses, rather than assembly label, can be found in dumped data section >> content, can Dyninst correctly identify all the memory addresses and lift >> them back into symbols? Things could become much harder regarding >> structures or even arrays of structures. >> >> Dyninst borrows the concept of abstract location (You can search for paper "what you see is not what you execute" for more details). An abstract location can be seen as a pair of memory region (heap, stack or global) and an offset inside the region. Dyninst has some decent analysis to identify stack and global abstract locations, but does not have static analysis to deal with dynamically allocated memory regions (like heap). > 2. As essentially there is no function information in stripped binaries, >> can Dyninst (heuristically) identify/recover the function-level information >> from disassembled assembly instructions? Or it just provide users with >> instruction-level information and interface? >> >> Dyninst can identify function entry points in stripped binaries using a machine learning based technique (see the following paper for more details ftp://ftp.cs.wisc.edu/paradyn/papers/Rosenblum08aaai.pdf). Then Dyninst will determine other function-level information from the identified function entry points. > Again, thank you a lot for your reply. Have a good night! >> >> Sincerely, >> Shuai >> >> >> >> >> On Thu, Jan 22, 2015 at 6:16 PM, Xiaozhu Meng <[email protected]> wrote: >> >>> Hi Shuai, >>> >>> Dyninst can handle stripped binaries statically and Improving this >>> capability of Dyninst is an ongoing project. Unfortunately, currently we do >>> not produce the disassembled results in a format that can be directly >>> reassembled. >>> >>> Our handling of stripped binaries tries to be as accurate as possible, >>> but we do not guarantee the recovered program is identical to the original >>> program produced by the compiler and we do not believe such guarantee is >>> realistic. We can give a good approximation of instructions of the >>> original program (Other tools you mentioned also just give approximation). >>> For data, without debugging information, it is very difficult to recover >>> data types for composite data structures. I believe it is impossible to >>> recover function names from stripped binaries. >>> >>> Finally, I would like to response to your question that dyninstAPI >>> requires user to provide function name to do instrumentation. DyninstAPI >>> does not require user to provide function name to do instrumentation. If >>> the user wants to instrument all functions in the program, we can do that >>> without asking for a function name. We need a function name when the user >>> wants to only instrument this particular function. In stripped binaries, >>> There is no function name to specify. So a user will need to use other >>> methods to convey to us where they want to instrument. >>> >>> Thanks >>> >>> --Xiaozhu >>> >>> On Thu, Jan 22, 2015 at 3:04 PM, Shuai Wang <[email protected]> >>> wrote: >>> >>>> Hello list, >>>> >>>> I am new to Dyninst and I am looking for a tool that can recover the >>>> whole assembly program from *stripped* binaries on Linux platform. Is >>>> Dynist able to do that? >>>> >>>> Be specific, existing binary disassembly tools, say, IDA-Pro, BAP and >>>> even objdump, can produce disassembled instructions and data from >>>> *stripped* binaries. But essentially the disassembled program are not >>>> *reassemble-able >>>> *or the reassembled binaries are not semantic equivalent. >>>> >>>> I am wondering whether DyninstAPI/InstructionAPI can be used to >>>> disassemble *stripped* binaries and recover the whole original >>>> assembly program? Especially, the recovered program should be semantically >>>> identical to the compiler produced assembly program (which means it >>>> includes all the instructions, data and meta-information), and the >>>> recovered program can be *directly* re-assembled back (No patching!) >>>> to produce a semantic equivalent binary. >>>> >>>> Can Dyninst meet my requirement? If so, could anyone give me some guide >>>> on how to do that? >>>> I have read the dyninstAPI manual and notice that it requires user to >>>> provide function name in order to instrument statically, does it indicate >>>> that dyninstAPI can not handle stripped (COTS) binaries? >>>> >>>> I really appreciate if anyone can give me some help, thank you. >>>> >>>> Shuai >>>> >>>> _______________________________________________ >>>> Dyninst-api mailing list >>>> [email protected] >>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >>>> >>> >>> >> >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
