To implement #11 we should add an interactive protocol between ReVa and the disassembler.
A few options:
Directory based
Inbox/Outbox architecture
Easy to implement, no persistent service to maintain in tool
Maybe a simple way to prototype for real time communications later?
Is similar to Ghidra / Git like workflow with checkin/checkout?
Annoying to use? Requires a periodic sync.
Socket based
Add a REST server to the tool
Requires Ghidra plugin, probably in Java due to Ghidraathon limitations on multiple interpreters.
BinaryNinja plugin is probably fine.
Limited to one server if a default port is used? Add negotiation maybe?
Allows real time communication
Need to handle conflicts and state changes. In both Ghidra and BinaryNinja we can use checkpoints/undos, but might conflict with user action?
Sessions
Add a script that does one of the things above, but for a limited time while it runs
Spins and checks directory or hosts REST server for some time?
No need for the server well known port problem
Allows for a unified undo session for the whole automated session, better for user?
No need for persistent connection
In Ghidra (and maybe BinaryNinja), locks the tool UI against user changes, easier to merge?
Maybe annoying?
Like handing the keyboard to a coworker? Maybe familiar workflow?
More questions
Do we move all of ReVa to this model, prefer over the pipeline model? Not too bad to refactor, the design now can be changed to real time json messages instead of prepared local jsons.
How does this work with automation and scripting? Now you can do a pipeline for automation, this is too complex now?
To implement #11 we should add an interactive protocol between ReVa and the disassembler.
A few options:
Directory based
Socket based
Sessions
More questions