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. 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? 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
