capstone-rs backend?
iximeow opened this issue · comments
I noticed yesterday that much of Xori's instruction decoding maps pretty directly to chunks of Capstone's decoding logic. Since that appears to be the case for so much of xori's decoder, does it make sense to use capstone-rs directly?
I noticed in your slides that you mention fixing a few capstone bugs in the process of rewriting, so maybe those fixes could be upstreamed? If the motivator for decoding in rust is avoiding memory bugs another thought might be to see about parcelling out Xori's x86 decoder and seeing about replacing the capstone decoder upstream?
Barring any of that, it would be good to know that Xori's x86 decoding very closely derives from Capstone's implementation, much like Capstone does in indicating its LLVM origins, especially if bugs were found in Xori's decoder to know that they should be upstreamed - even the disassembly mapping tables are the same as Capstone's and those do change from time to time!
(a nice part of capstone-rs as a backend means the bar for supporting any other Capstone-backed arch is a lot easier!)
Yeah the idea was to convert the logic only using rust since that was a requirement at work. I needed to verify all of the logic by hand to make sure I had parity with other disassemblers I was testing. There were some things in the capstone lib that were extra unused code that was pulled in from llvm libs (more in the printing).
@securedorg Don't you need to credit or attribute somewhere @aquynh / capstone-engine / llvm if you re-use/adapt their code ?
It was explained during the presentation and on the slides sourced here: https://sites.google.com/secured.org/malwareunicorn/xori
For the record, could you post here how you credited Capstone in your slides?
The right way to credit what you derive is to say that in docs (that comes with source code), and in source code itself, but not in some slides.
Cheers.
I think we'd rather put more documentation in the README and in the code to give proper credit (to capstone, LLVM, etc) than just link back to the slides. This is a long holiday weekend so I may not get to it until Tuesday, but ping me if you need it before then. We will get this right as many iterations as it takes. Let me know if there is specific links, wording you'd like etc otherwise I'll look it up and do my best.
As per the original ticket, I'm not against adding capstone-rs as a xori backend. In addition to instant extra arch support, it would allow for better testing and parity between the xori engine and capstone.
Our current roadmap (aka what Amanda and I can do in our free time) doesn't include adding swappable disassembly engines. No matter what we would always want to maintain xori's 'pure rust' engine. I would love to help do the design work such that we could do that in conjunction with some folks w/ capstone experience, but we don't have time ourselves in the foreseeable future to code it up. Also although I don't love the idea, forking xori w/ capstone, xoristone? capxori? could conceivably be easier than making the disassembler a configuration option (or cargo build feature).
#22 is a start at adding some proper acknowledgements.