You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 2, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 2, 2020. It is now read-only.
Primarily because capstone didn't exist when binary ninja was started.
That said, for the rewrite that's underway, we tested capstone and it was nearly an order of magnitude slower than the asmx86 library. (See the "Fast Disassembly" section of asmx86.) That performance problem is only going to get worse as we (and by "we", I mean primarily @D0ntPanic) add other planned features like emulation and analysis where the string-based output from capstone is even less appropriate.
That said, it does make sense to use capstone for other architectures since it's a pain writing new disassemblers. That'll likely come in the new rewrite -- we're happy to accept PRs on the python version and will make a best effort to fix critical bugs in it, but we likely won't be porting new features back to it.
The performance test was done on the fast disassembly. Even the "diet" version, which has no string output support, was slower. However, that is comparing our C++ disassembler library with Capstone.
For the Python version here, Capstone would likely be much faster, as native Python code is not fast. Capstone has much more complete instruction set support, and would likely be a better fit for the Python version. Pull requests are welcome.
Activity
psifertex commentedon Apr 20, 2015
Primarily because capstone didn't exist when binary ninja was started.
That said, for the rewrite that's underway, we tested capstone and it was nearly an order of magnitude slower than the asmx86 library. (See the "Fast Disassembly" section of asmx86.) That performance problem is only going to get worse as we (and by "we", I mean primarily @D0ntPanic) add other planned features like emulation and analysis where the string-based output from capstone is even less appropriate.
That said, it does make sense to use capstone for other architectures since it's a pain writing new disassemblers. That'll likely come in the new rewrite -- we're happy to accept PRs on the python version and will make a best effort to fix critical bugs in it, but we likely won't be porting new features back to it.
zachriggle commentedon Apr 20, 2015
Is that slow-down using Capstone with the full semantic information, or the fast disassembler?
D0ntPanic commentedon Apr 20, 2015
The performance test was done on the fast disassembly. Even the "diet" version, which has no string output support, was slower. However, that is comparing our C++ disassembler library with Capstone.
For the Python version here, Capstone would likely be much faster, as native Python code is not fast. Capstone has much more complete instruction set support, and would likely be a better fit for the Python version. Pull requests are welcome.