Capstone 4.0.1 support #23
Conversation
|
I'm looking into the build failures still. On my macOS machine the TestTest suite runs fine but on Travis the diffs aren't matching. |
|
So I had the failing TestTest print out the size of the strings it was comparing. On the Travis CI machines I get this: len(fs) = 6525 On my machine I get len(fs) = 6525 I'm not sure why Travis CI would have this happen. It's not failing to read the fail. The test explicitly checks if |
knightsc
force-pushed
the
capstone4
branch
3 times, most recently
from
7c4a283 to
41c14df
Compare
|
Ok, I figured out what was going on. Someone on Gophers slack pointed out the issue. Capstone 3.0.4 had the test generator named test.c and in 4.0.1 it got renamed to test_basic.c. I updated the genspec script in 85692e3 which fixes the issue with no output. But I realize now that it's expected for the gapstone output to exactly match the capstone output. In order for that to happen I think I need to implement the new cs_regs_access function in the Engine and update the test output in Gapstone to output immediate and external registers that are modified. The local |
The C standard says that an enum is not defined to be an unsigned or signed value. While running the test suite under Go 1.11.4 there were errors about CS_MODE_BIG_ENDIAN overflowing the uint value. It seems similar to this: golang/go#24523 Since the mapping of Capstone constants to Go constants is untyped it means that the values are of type int. To solve this I changed the engine mode to be of type int. I think another potential way to solve this is to explicitly specify a type for the engine mode constants.
Since the cs_regs_access function takes a pointer to an cs_insn and we free this memory after decomposition we populate all read and written registers while filling in the generic header.
|
Ok I think this branch is ready for review. Please note the Travis CI builds are still failing because of a bug in the capstone Also commit cebe3ed has the support for cs_regs_access. I'm not sure if there's a better way to do it but it's awkward since that API takes a pointer to a cs_insn and we don't keep that memory around. |
See capstone-engine/capstone#1365 The capstone output is incorrect. Disabling genspec for now so the test suite uses the checked in version for now
|
@bnagy Is this project maintained anymore? Should I just commit this to my own fork? |
|
@bnagy Any chance of getting this PR'ed merged? |
|
@guitmz I've considered just making this a PR on my fork and then merging it into master and trying to get the Capstone project to update links. I'm happy to continue contributing to this repo directly though since this is where all the community links actually go |
|
@knightsc would be nice if you could merge your changes into your own fork (so I don't have to create one myself, you did a very good job with this branch). At least until we get an answer from @bnagy we can use it and perhaps see about the future of this repo. Not sure why he is not replying us, he is active in social media recently... |
|
@guitmz You should just be able to do something like this
And that should use the branch that I have pushed up versus creating a fork yourself |
|
Hi! Sorry, I don't read git notifications often, and they don't go to any of the email addresses I use. If someone is happy to maintain the bindings, I would suggest that you take my code and run - I'm not active in infosec or RE at present, and may not be again. If there's a working fork that's up to date, then I am happy to update the README here to push people towards it, and I'll let Q know that he should change any links at the capstone end. |
|
Hi @bnagy , could you also update the README.md of Ruby bindings crabstone? I have a fork works for capstone 4 support and I will keep maintaining. |
|
@bnagy Thanks for merging. I think I'm willing to take over gapstone ownership. If you could update the README here to go to point folks towards https://github.com/knightsc/gapstone and let Q know on the capstone side that would be great. Thanks! |
|
@bnagy, please approve the change at capstone-engine/capstone#1532. cheers. |
|
Hopefully we're all done here. Thanks all, and thanks @knightsc for volunteering to take over :) |
5 participants
Using both the capstone source diffs between 3.0.4 and 4.0.1 as well as this story from the Capstone project I've updated the Go bindings to support 4.0.1
capstone-engine/capstone#1315
I had one change to the Engine structure based on some weirdness with running the test suite. See the comment on a9fe16a
I purposely left off the new engines from this PR as I didn't want this PR to get to large to review. But I intend to create 4 separate PRs for the 4 new engines: EVM, M68K, M680X & TMS320C64x