Closed ivg closed 2 years ago
Have you considered Cutter integration? It also allows to run Python plugins. Maybe it makes sense to share some common code between all three.
//cc @xarkes
I did not yet, but PRs are very welcome :)
Besides, it should be really trivial to integrate Primus with Cutter, since the existing IDA integration uses Qt5, and there are only 2 or 3 IDA specific callbacks, such as the goto(addr)
and traceadd(addr,tid)
, so if Cutter has at least the first, it should be a piece of cake.
Yes, I should try to do this myself. Will try to do next week.
A few pointers,
Only the third module has any dependencies on IDA, which could be easily factored out. Note also, that I've implemented a CLOS-like multimethods to make it easier to handle different model events (we have many events, and using Python/C++ish overriding doesn't really scale).
The idea, is all these three modules should be factored out from the bap-idap-python repository, probably into bap-python
(we then can submodule bap-python
into bap-ida-python
to make it available again in IDA).
Implemented in #1326 and #1364
Ghidra is an NSA alternative to IDA Pro, that might become the new de facto tool for reverse engineering and binary analysis. It comes with lots of stuff on board and is also freely available with the majority of the code made public under permissive license.
First of all, since Ghidra has an embedded Python interpreter it should be quite easy to port the bap-for-ida part of our IDA integration tools, i.e., an ability to run bap analysis from Ghidra and annotate the source tree along with the disassembly.
Second, it looks like that Ghidra could be run in a headless mode (not sure whether we need to start server for that), so it implies that we can use Ghidra to provide services for bap, like rooter, reconstructor, symbolizer, etc.
Finally, and this is the gem, Ghidra comes with Sleigh (this is the name of their IR) specifications for each supported processor (see
Ghidra/Processors/<CPU>/Data/Languages/*
). Sleigh is an explicit language, with a concrete syntax that is quite similar to BIL. The goal is to be able to read those specifications. As Sleigh might become a de facto ISA semantics specification language, especially given the amount of work that is already done (~200kLOC of pure specifications, which are quite terse). At first glance it would be very easy to add support for Sleigh in BAP 2.0 semantics. Given that the sleigh specification could be translated to xml, using the provided toolsleigh
, there is even no need to implement a parser.