Open Maijin opened 6 years ago
Hi Maijin!
Thank you very much for your feedback.
The issue for me is that for example, I don't know an equivalent in json for "axg" nor "px". There is a "axj" command but this one is only for the references and not for a call graph.
Or maybe there is some equivalent commands that put together can do the same thing?
px -> p8
call graph is agj
Ok, perfect for p8 indeed. I didn't catch at first that it was the byte in decimal instead of hex...
But for the agj
it doesn't seem to print the full call graph of the function. It can show the xrefs which is already nice but not the full call graph. Or I am missing something?
oh sorry ax, isn't axj doing what you need ?
Not really. I tried it once and it didn't give me the same result as axg. I can paste a code example, result and expected result later if you want. I think axj gives you the references of the function but not the full call graph. I would expect for example that axj gives you an array of function if one function is called at multiple places for example and it doesn't seem to be the case.
Yes can you open an issue with your result and expected result ? This is very important 👍
Done :)
I created an open request because I don't think that's an issue from axj
.
You know about axtj and axfg ?
No, I didn't know about these 2. axtj seems nice to find xrefs to function. Unfortunately, axfg doesn't seem to work for me. What should it give me?
I could work with axtj to replace some stuffs from exe_stats.py I think. But it won't replace axg in the other script in order to give me all the different possible paths which lead to some function.
Also, I discovered afll which seem to give me a lot of the stuffs I need for exe_stats.py :D and there is a json output available if I remember correctly so it can be another possibility.
axfj not axfg*
and don't use afll but aflj
axfj is indeed super nice!
Aaaaand I didn't remember that I'm already using aflj... <(") So I can have the callrefs super easily since the beginning!
First, Great job!
Now, all commands in r2 can be expressed in JSON and r2pipe provide a simple way to handle this with r2.cmdj which is documented in the README of r2pipe repository:
https://github.com/radare/radare2-r2pipe/tree/master/python#usage-example
The r2.cmdj returns a JSON objects that doesn't need to be reparsed or json.loads, I suggest using r2.cmdj will reduce drastically the code size and reduce manual parsing of output which are highly subject to change unlike the JSON.