Menu
▾
▴
capstone-users — Capstone mailing list for users
You can subscribe to this list here.
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(11) |
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
(12) |
Feb
(3) |
Mar
(7) |
Apr
(4) |
May
(31) |
Jun
(2) |
Jul
(4) |
Aug
(2) |
Sep
(16) |
Oct
(13) |
Nov
(2) |
Dec
(25) |
| 2015 |
Jan
(28) |
Feb
(9) |
Mar
(7) |
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(12) |
Sep
|
Oct
(11) |
Nov
(4) |
Dec
|
| 2016 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
(4) |
Jun
(6) |
Jul
(9) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(7) |
Dec
(2) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
(1) |
Jun
(4) |
Jul
(6) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Moshe K. <mkr...@ho...> - 2014-07-23 09:20:12
|
Hi, Could you let me know what is the best way to have a cross platform binary files parser, so I can open any of ELF, PE, Mach-O, find the code and then use capstone to process it? I haven't seen this kind of functionality provided by capstone itself... Regards,Moshe |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-06-27 14:43:01
|
hi, we now have one more new binding for Capstone: C++ binding. this great work is made & maintained by Peter Hlavaty (@*zer0mem)* <https://twitter.com/zer0mem>: https://github.com/zer0mem/cccapstone another good news: Ocaml binding is now working in the "next" branch thanks to super effort of Guillaume Jeanne. check it out at https://github.com/aquynh/capstone/blob/next/bindings/ocaml/README cheers, Q |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-06-18 14:59:54
|
hi, Capstone has seen some major improvement in performance in the core thanks to some optimizations: it uses a lot less heap memory now, but significantly faster for all 8 archs in our benchmarks. especially, X86 engine is around 3 times faster than before. besides, we have fixed a serious use-after-free bug in Python binding, so if you are using the "next" branch, you should definitely update. check it out in the "next" branch at https://github.com/aquynh/capstone/tree/next more information on other recent changes: https://github.com/aquynh/capstone/wiki/ChangeLog cheers, Q |
|
From: Greg L. <gre...@gm...> - 2014-05-30 00:57:32
|
This is great! Thanks DPistelli! Good to know you're still around wrecking shit! On Wed, May 28, 2014 at 10:54 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > hi, > > Capstone has just reached another milestone: support CMake! This work was > contributed by Daniel Pistelli, thanks! > > this means now Capstone can be built by all the compilers & IDE supported > by CMake: Windows's NMake, Visual Studio of all versions, KDE, Eclipse, > Ninja, etc > > Note: this does nott mean we give up on the existing Makefile: we still > maintain Makefile & CMake in parallel,and users can decide what to use for > their convenience. > > At the moment this feature is only available in the "next" branch. See > https://github.com/aquynh/capstone/blob/next/COMPILE_CMAKE.TXT for usage > instructions. > > cheers, > Q > > > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > > -- regards, G Lindor |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-28 15:48:29
|
On Wed, May 28, 2014 at 1:56 PM, Jay Oster <ja...@ko...> wrote: > Hi, > > I just finished support for XCore in node-capstone! I'm using the same > branching strategy, so you can find it in the "next" branch: > > https://github.com/parasyte/node-capstone/tree/next > you are amazingly quick :-) thanks, Q > > On May 27, 2014, at 8:51 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > hi, > > lets welcome the 8th architecture of Capstone: XCore! check it out in the > “next” branch at > > https://github.com/aquynh/capstone/tree/next > > at the moment, Python & Java binding already supported this new arch. > > cheers, > Q > > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk_______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > > > > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > > |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-28 14:54:44
|
hi, Capstone has just reached another milestone: support CMake! This work was contributed by Daniel Pistelli, thanks! this means now Capstone can be built by all the compilers & IDE supported by CMake: Windows's NMake, Visual Studio of all versions, KDE, Eclipse, Ninja, etc Note: this does nott mean we give up on the existing Makefile: we still maintain Makefile & CMake in parallel,and users can decide what to use for their convenience. At the moment this feature is only available in the "next" branch. See https://github.com/aquynh/capstone/blob/next/COMPILE_CMAKE.TXT for usage instructions. cheers, Q |
|
From: Jay O. <ja...@ko...> - 2014-05-28 06:22:13
|
Hi, I just finished support for XCore in node-capstone! I'm using the same branching strategy, so you can find it in the "next" branch: https://github.com/parasyte/node-capstone/tree/next On May 27, 2014, at 8:51 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > hi, > > lets welcome the 8th architecture of Capstone: XCore! check it out in the “next” branch at > > https://github.com/aquynh/capstone/tree/next > > at the moment, Python & Java binding already supported this new arch. > > cheers, > Q > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk_______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-27 15:51:41
|
hi,
lets welcome the 8th architecture of Capstone: XCore! check it out in the
“next” branch at
https://github.com/aquynh/capstone/tree/next
at the moment, Python & Java binding already supported this new arch.
cheers,
Q
|
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-26 12:20:32
|
On Mon, May 26, 2014 at 5:44 PM, Jay Oster <ja...@ko...> wrote: > > On May 23, 2014, at 1:33 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > On Fri, May 23, 2014 at 3:54 PM, Jay Oster <ja...@ko...> wrote: > >> >> I can't support the new SKIPDATA mode yet, because I have no interface >> for providing callback functions to native code. I'll have to write a new >> native module for node that can support passing callbacks into native land. >> (Such a module does not exist yet.) Everything I'm using is all built on >> libffi, and I should be able to implement generic callbacks using >> ffi_closure. But this will be a nice little detour, anyway. >> > > i see, but you can take time working on that, as the next release is not > out very soon yet (still deciding on when is a good time for it) > > > I was able to get the callback working properly, and is now fully > supported in node-capstone. (node-ffi has callback support, it's just > undocumented.) > > With that, I think the node bindings are ready for 2.2! There might be > some API changes along the way, but all of the new features are ready to go. > great, this is quick! i took a look at your "next" branch, and you need to correct the instructions on installing the core: users cannot install the 2.2 core from Brew, or from any available packages, as they are not ready yet. the only way to have 2.2 core is to build from source of the "next" branch from https://github.com/aquynh/capstone/tree/next thanks, Q |
|
From: Jay O. <ja...@ko...> - 2014-05-26 09:44:55
|
On May 23, 2014, at 1:33 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > On Fri, May 23, 2014 at 3:54 PM, Jay Oster <ja...@ko...> wrote: > > I can't support the new SKIPDATA mode yet, because I have no interface for providing callback functions to native code. I'll have to write a new native module for node that can support passing callbacks into native land. (Such a module does not exist yet.) Everything I'm using is all built on libffi, and I should be able to implement generic callbacks using ffi_closure. But this will be a nice little detour, anyway. > > i see, but you can take time working on that, as the next release is not out very soon yet (still deciding on when is a good time for it) I was able to get the callback working properly, and is now fully supported in node-capstone. (node-ffi has callback support, it's just undocumented.) With that, I think the node bindings are ready for 2.2! There might be some API changes along the way, but all of the new features are ready to go. > cheers, > Q > |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-23 08:34:11
|
On Fri, May 23, 2014 at 3:54 PM, Jay Oster <ja...@ko...> wrote: > > On May 21, 2014, at 2:17 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > On Wed, May 21, 2014 at 3:42 PM, Jay Oster <ja...@ko...> wrote: > >> I just published a minor revision that fixes the instruction structure >> returned by the disasm method. The biggest change in this release is in the >> unit tests. Now I'll start working toward supporting the `next` branch and >> Capstone 2.2! >> >> > > yes, supporting 'next' would be great, as that branch is going to be the > next version. > > if you have any doubt, consult the Python binding (which is always updated > to the core), or let me know if you need any help. > > > I can't support the new SKIPDATA mode yet, because I have no interface for > providing callback functions to native code. I'll have to write a new > native module for node that can support passing callbacks into native land. > (Such a module does not exist yet.) Everything I'm using is all built on > libffi, and I should be able to implement generic callbacks using > ffi_closure. But this will be a nice little detour, anyway. > i see, but you can take time working on that, as the next release is not out very soon yet (still deciding on when is a good time for it) cheers, Q > On May 20, 2014, at 1:23 AM, Jay Oster <ja...@ko...> wrote: > > > On May 20, 2014, at 1:21 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > Jay, this is amazing! >> >> i just forwarded this to some lists, and put the news out on Twitter to >> make sure people get this hot toy! >> > > > Jay, i linked to your Github repo in the Download page at > http://capstone-engine.org/download.html > > > Nice, thanks! I should probably do some tweeting, too. I'm @kodewerx > > > |
|
From: Jay O. <ja...@ko...> - 2014-05-23 07:54:59
|
On May 21, 2014, at 2:17 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > On Wed, May 21, 2014 at 3:42 PM, Jay Oster <ja...@ko...> wrote: > I just published a minor revision that fixes the instruction structure returned by the disasm method. The biggest change in this release is in the unit tests. Now I'll start working toward supporting the `next` branch and Capstone 2.2! > > > > yes, supporting 'next' would be great, as that branch is going to be the next version. > > if you have any doubt, consult the Python binding (which is always updated to the core), or let me know if you need any help. > I can't support the new SKIPDATA mode yet, because I have no interface for providing callback functions to native code. I'll have to write a new native module for node that can support passing callbacks into native land. (Such a module does not exist yet.) Everything I'm using is all built on libffi, and I should be able to implement generic callbacks using ffi_closure. But this will be a nice little detour, anyway. > > cheers, > Q > > > > > > On May 20, 2014, at 1:23 AM, Jay Oster <ja...@ko...> wrote: > >> >> On May 20, 2014, at 1:21 AM, Nguyen Anh Quynh <aq...@gm...> wrote: >> >>> >>> Jay, this is amazing! >>> >>> i just forwarded this to some lists, and put the news out on Twitter to make sure people get this hot toy! >>> >>> >>> Jay, i linked to your Github repo in the Download page at http://capstone-engine.org/download.html >>> >> >> Nice, thanks! I should probably do some tweeting, too. I'm @kodewerx > > |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-21 09:17:44
|
On Wed, May 21, 2014 at 3:42 PM, Jay Oster <ja...@ko...> wrote: > I just published a minor revision that fixes the instruction structure > returned by the disasm method. The biggest change in this release is in the > unit tests. Now I'll start working toward supporting the `next` branch and > Capstone 2.2! > > yes, supporting 'next' would be great, as that branch is going to be the next version. if you have any doubt, consult the Python binding (which is always updated to the core), or let me know if you need any help. cheers, Q > On May 20, 2014, at 1:23 AM, Jay Oster <ja...@ko...> wrote: > > > On May 20, 2014, at 1:21 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > Jay, this is amazing! >> >> i just forwarded this to some lists, and put the news out on Twitter to >> make sure people get this hot toy! >> > > > Jay, i linked to your Github repo in the Download page at > http://capstone-engine.org/download.html > > > Nice, thanks! I should probably do some tweeting, too. I'm @kodewerx > > > |
|
From: Jay O. <ja...@ko...> - 2014-05-21 07:42:34
|
I just published a minor revision that fixes the instruction structure returned by the disasm method. The biggest change in this release is in the unit tests. Now I'll start working toward supporting the `next` branch and Capstone 2.2! On May 20, 2014, at 1:23 AM, Jay Oster <ja...@ko...> wrote: > > On May 20, 2014, at 1:21 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > >> >> Jay, this is amazing! >> >> i just forwarded this to some lists, and put the news out on Twitter to make sure people get this hot toy! >> >> >> Jay, i linked to your Github repo in the Download page at http://capstone-engine.org/download.html >> > > Nice, thanks! I should probably do some tweeting, too. I'm @kodewerx |
|
From: Jay O. <ja...@ko...> - 2014-05-20 08:29:37
|
On May 20, 2014, at 1:21 AM, Nguyen Anh Quynh <aq...@gm...> wrote: > > Jay, this is amazing! > > i just forwarded this to some lists, and put the news out on Twitter to make sure people get this hot toy! > > > Jay, i linked to your Github repo in the Download page at http://capstone-engine.org/download.html > Nice, thanks! I should probably do some tweeting, too. I'm @kodewerx |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-20 08:21:37
|
On Tue, May 20, 2014 at 3:59 PM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > > On Tue, May 20, 2014 at 3:45 PM, Jay Oster <ja...@ko...> wrote: > >> Hi everyone! >> >> After a rough week fighting off a cold, I'm back to announce that >> node-capstone, the binding for Node.js, has been released! The initial >> version is 2.1.0, matching roughly the Capstone version that it supports. I >> will be using the tertiary number as a revision for the bindings, otherwise >> the version number matches the major and minor components, as returned by >> cs_version(). >> >> Here are some relevant links: >> >> - Source code: https://github.com/parasyte/node-capstone >> - Documentation (incomplete): >> http://parasyte.github.io/node-capstone-docs/ >> - NPM registry: https://www.npmjs.org/package/capstone >> >> Released under the terms of the MIT license. >> >> Feel free to contact me here, via email, or in the github issues if you >> find bugs or need help! >> > > Jay, this is amazing! > > i just forwarded this to some lists, and put the news out on Twitter to > make sure people get this hot toy! > Jay, i linked to your Github repo in the Download page at http://capstone-engine.org/download.html cheers, Q |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-20 07:59:59
|
On Tue, May 20, 2014 at 3:45 PM, Jay Oster <ja...@ko...> wrote: > Hi everyone! > > After a rough week fighting off a cold, I'm back to announce that > node-capstone, the binding for Node.js, has been released! The initial > version is 2.1.0, matching roughly the Capstone version that it supports. I > will be using the tertiary number as a revision for the bindings, otherwise > the version number matches the major and minor components, as returned by > cs_version(). > > Here are some relevant links: > > - Source code: https://github.com/parasyte/node-capstone > - Documentation (incomplete): > http://parasyte.github.io/node-capstone-docs/ > - NPM registry: https://www.npmjs.org/package/capstone > > Released under the terms of the MIT license. > > Feel free to contact me here, via email, or in the github issues if you > find bugs or need help! > Jay, this is amazing! i just forwarded this to some lists, and put the news out on Twitter to make sure people get this hot toy! cheers, Q |
|
From: Jay O. <ja...@ko...> - 2014-05-20 07:46:32
|
Hi everyone! After a rough week fighting off a cold, I'm back to announce that node-capstone, the binding for Node.js, has been released! The initial version is 2.1.0, matching roughly the Capstone version that it supports. I will be using the tertiary number as a revision for the bindings, otherwise the version number matches the major and minor components, as returned by cs_version(). Here are some relevant links: - Source code: https://github.com/parasyte/node-capstone - Documentation (incomplete): http://parasyte.github.io/node-capstone-docs/ - NPM registry: https://www.npmjs.org/package/capstone Released under the terms of the MIT license. Feel free to contact me here, via email, or in the github issues if you find bugs or need help! Cheers, Jay |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-19 13:39:52
|
hi,
Capstone has just reached a new milestone: support Visual Studio to compile
on Windows! thanks to this, you no longer need to rely on MingW
cross-compilation for native Windows binaries!
all credits go to Axel "0vercl0k" Souchet (@0vercl0k) & Alex Ionescu. we
cannot thank them enough for dedicating their amazing efforts for this
important feature!
for now, this feature is only available in the “next” branch in our Github
repo at:
https://github.com/aquynh/capstone/tree/next.
see https://github.com/aquynh/capstone/blob/next/COMPILE_MSVC.TXT for
instructions on how to build Capstone with Visual Studio 2010+.
one more thing: recently, the “next” branch also got some important bug
fixes for Arm, Arm64 & x86. check it out here for further details:
https://github.com/aquynh/capstone/wiki/ChangeLog
cheers,
Q
|
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-11 14:12:09
|
On Sun, May 11, 2014 at 9:07 PM, Jason Oster <ja...@ko...> wrote:
> I've started to refactor the constants in the node bindings to closer
> match the C library. Which lead me to also refactor the documentation
> comments. And now I'm in a grand rathole reinventing the documentation
> build system and templates. :) It was something I desperately needed to do
> anyway.
>
> After I finish the refactoring and unit tests, I will release the node
> bindings. The documentation can be polished afterward.
>
sounds very cool ;-) let me know if you need any help.
looks forward to your release. cheers,
Q
> On May 8, 2014, at 8:42 PM, Greg Lindor <gre...@gm...> wrote:
>
> Hey,
> great project you have, I would love to test your js bindings when its
> ready for testing :)
>
>
> On Thu, May 8, 2014 at 12:47 AM, Nguyen Anh Quynh <aq...@gm...>wrote:
>
>>
>>
>>
>> On Thu, May 8, 2014 at 12:34 PM, Jason Oster <ja...@ko...> wrote:
>>
>>> On the JS binding, I added a little helper method to some of the
>>> dictionaries (registers, instructions, and groups) which will convert a
>>> register index to a string representation. Here's a contrived example:
>>>
>>> var capstone = require("capstone");
>>>
>>> var reg = capstone.x86.REG.RSP;
>>> expect(reg).toEqual(44);
>>>
>>> var output = capstone.x86.REG.toString(reg);
>>> expect(output).toEqual("rsp");
>>>
>>> This is in contrast to having constants like `capstone.x86.REG_RSP` and
>>> a method named `capstone.x86.regToString` or `capstone.x86.INS_PUSHQ` and
>>> `capstone.x86.insToString`
>>>
>>> What are your thoughts? The way I have it now feels more natural in
>>> JavaScript. But I want to stay true to the common Capstone API.
>>>
>>
>> in general, it is best if you can implement the interface like the C API.
>> this is the principle all the bindings are following so far, because users
>> can easily switch from one binding to another without having to adapt too
>> much.
>>
>> but in fact each language has different way to do things, so if you think
>> your way is more natural, then just do it.
>> just try to keep it as clean, simple & close to C API, as possible.
>>
>> thanks,
>> Q
>>
>>
>>
>>
>>
>>
>>
>>>
>>> On May 7, 2014, at 8:23 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>>>
>>>
>>>
>>>
>>> On Thu, May 8, 2014 at 11:01 AM, Jay Oster <ja...@ko...> wrote:
>>>
>>>> Bringing the conversation back to the list.
>>>>
>>>> Thanks for the comments! I'm looking forward to getting the binding
>>>> out. It will be compatible with 2.1.x initially. And hopefully 2.2.x soon
>>>> after you release it! I'll reconsider the structure of the constants in the
>>>> binding.
>>>>
>>>
>>> yes, the NodeJS binding will be awesome to have!
>>>
>>>
>>>
>>>> Very valuable feedback so far! Also, I'll try to update the LLVM
>>>> backend work I did, and we can collaborate to get NEC V8xx as a new
>>>> architecture. Cool!
>>>>
>>>>
>>> great! look forward to your NEC arch.
>>>
>>>
>>> cheers,
>>> Q
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> On Wed, May 7, 2014 at 7:11 AM, Nguyen Anh Quynh <aq...@gm...>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote:
>>>>>
>>>>>> Hi List,
>>>>>>
>>>>>> I've been writing JavaScript (Node.js) bindings for Capstone,
>>>>>
>>>>>
>>>>> very cool! do you have any plan publishing your binding?
>>>>>
>>>>>
>>>>>> and would like to start experimenting with adding new architectures
>>>>>> to the lib.
>>>>>
>>>>>
>>>>> which arch do you want to add? so far, the "next" branch of our main
>>>>> repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86.
>>>>>
>>>>> The first question I have about the process is, how does one go about
>>>>>> creating the *.inc files? I'm familiar with the concept from LLVM (I spent
>>>>>> a few weeks writing a new backend for it).
>>>>>>
>>>>>> The Capstone source tree is unusual for two reasons: First, it is
>>>>>> written in C (TableGen outputs C++) and second, the repo does not contain
>>>>>> any Table Description files to generate the *.inc files. Does that mean all
>>>>>> of the *.inc files have been hand-written?
>>>>>>
>>>>>>
>>>>> this is a bit complicated: i let LLVM compile their .td files, and get
>>>>> generated .inc files, then did a bunch of magic tricks (with some manual
>>>>> fixes), and have the .inc files for Capstone.
>>>>> you can see that our .inc files are quite different from LLVM's.
>>>>>
>>>>> I'm interested in any tips or pointers!
>>>>>
>>>>>
>>>>> that is it, but frankly what you are asking should not affect your
>>>>> binding and how you implement it.
>>>>>
>>>>> In the meantime, I've got 4 of the 5 architectures in 2.1.2 working
>>>>>> from JavaScript. The new SystemZ and Sparc architectures should be easy to
>>>>>> do, as well.
>>>>>>
>>>>>
>>>>> this is great! thanks for letting us know. cant wait to hear more
>>>>> about your progress :-)
>>>>>
>>>>> cheers,
>>>>> Q
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find
>> out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
>>
>
>
> --
> regards,
> G Lindor
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce_______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>
>
|
|
From: Jason O. <ja...@ko...> - 2014-05-11 13:07:37
|
I've started to refactor the constants in the node bindings to closer match the C library. Which lead me to also refactor the documentation comments. And now I'm in a grand rathole reinventing the documentation build system and templates. :) It was something I desperately needed to do anyway.
After I finish the refactoring and unit tests, I will release the node bindings. The documentation can be polished afterward.
On May 8, 2014, at 8:42 PM, Greg Lindor <gre...@gm...> wrote:
> Hey,
> great project you have, I would love to test your js bindings when its ready for testing :)
>
>
> On Thu, May 8, 2014 at 12:47 AM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>
>
> On Thu, May 8, 2014 at 12:34 PM, Jason Oster <ja...@ko...> wrote:
> On the JS binding, I added a little helper method to some of the dictionaries (registers, instructions, and groups) which will convert a register index to a string representation. Here's a contrived example:
>
> var capstone = require("capstone");
>
> var reg = capstone.x86.REG.RSP;
> expect(reg).toEqual(44);
>
> var output = capstone.x86.REG.toString(reg);
> expect(output).toEqual("rsp");
>
> This is in contrast to having constants like `capstone.x86.REG_RSP` and a method named `capstone.x86.regToString` or `capstone.x86.INS_PUSHQ` and `capstone.x86.insToString`
>
> What are your thoughts? The way I have it now feels more natural in JavaScript. But I want to stay true to the common Capstone API.
>
> in general, it is best if you can implement the interface like the C API. this is the principle all the bindings are following so far, because users can easily switch from one binding to another without having to adapt too much.
>
> but in fact each language has different way to do things, so if you think your way is more natural, then just do it.
> just try to keep it as clean, simple & close to C API, as possible.
>
> thanks,
> Q
>
>
>
>
>
>
>
> On May 7, 2014, at 8:23 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>>
>>
>>
>> On Thu, May 8, 2014 at 11:01 AM, Jay Oster <ja...@ko...> wrote:
>> Bringing the conversation back to the list.
>>
>> Thanks for the comments! I'm looking forward to getting the binding out. It will be compatible with 2.1.x initially. And hopefully 2.2.x soon after you release it! I'll reconsider the structure of the constants in the binding.
>>
>> yes, the NodeJS binding will be awesome to have!
>>
>>
>>
>> Very valuable feedback so far! Also, I'll try to update the LLVM backend work I did, and we can collaborate to get NEC V8xx as a new architecture. Cool!
>>
>>
>> great! look forward to your NEC arch.
>>
>>
>> cheers,
>> Q
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 7, 2014 at 7:11 AM, Nguyen Anh Quynh <aq...@gm...> wrote:
>>
>>
>>
>> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote:
>> Hi List,
>>
>> I've been writing JavaScript (Node.js) bindings for Capstone,
>>
>> very cool! do you have any plan publishing your binding?
>>
>> and would like to start experimenting with adding new architectures to the lib.
>>
>> which arch do you want to add? so far, the "next" branch of our main repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86.
>>
>> The first question I have about the process is, how does one go about creating the *.inc files? I'm familiar with the concept from LLVM (I spent a few weeks writing a new backend for it).
>>
>> The Capstone source tree is unusual for two reasons: First, it is written in C (TableGen outputs C++) and second, the repo does not contain any Table Description files to generate the *.inc files. Does that mean all of the *.inc files have been hand-written?
>>
>>
>> this is a bit complicated: i let LLVM compile their .td files, and get generated .inc files, then did a bunch of magic tricks (with some manual fixes), and have the .inc files for Capstone.
>> you can see that our .inc files are quite different from LLVM's.
>>
>> I'm interested in any tips or pointers!
>>
>> that is it, but frankly what you are asking should not affect your binding and how you implement it.
>>
>> In the meantime, I've got 4 of the 5 architectures in 2.1.2 working from JavaScript. The new SystemZ and Sparc architectures should be easy to do, as well.
>>
>> this is great! thanks for letting us know. cant wait to hear more about your progress :-)
>>
>> cheers,
>> Q
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>
>
>
>
> --
> regards,
> G Lindor
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce_______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
|
|
From: Greg L. <gre...@gm...> - 2014-05-09 03:42:17
|
Hey,
great project you have, I would love to test your js bindings when its
ready for testing :)
On Thu, May 8, 2014 at 12:47 AM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>
>
> On Thu, May 8, 2014 at 12:34 PM, Jason Oster <ja...@ko...> wrote:
>
>> On the JS binding, I added a little helper method to some of the
>> dictionaries (registers, instructions, and groups) which will convert a
>> register index to a string representation. Here's a contrived example:
>>
>> var capstone = require("capstone");
>>
>> var reg = capstone.x86.REG.RSP;
>> expect(reg).toEqual(44);
>>
>> var output = capstone.x86.REG.toString(reg);
>> expect(output).toEqual("rsp");
>>
>> This is in contrast to having constants like `capstone.x86.REG_RSP` and a
>> method named `capstone.x86.regToString` or `capstone.x86.INS_PUSHQ` and
>> `capstone.x86.insToString`
>>
>> What are your thoughts? The way I have it now feels more natural in
>> JavaScript. But I want to stay true to the common Capstone API.
>>
>
> in general, it is best if you can implement the interface like the C API.
> this is the principle all the bindings are following so far, because users
> can easily switch from one binding to another without having to adapt too
> much.
>
> but in fact each language has different way to do things, so if you think
> your way is more natural, then just do it.
> just try to keep it as clean, simple & close to C API, as possible.
>
> thanks,
> Q
>
>
>
>
>
>
>
>>
>> On May 7, 2014, at 8:23 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>>
>>
>>
>>
>> On Thu, May 8, 2014 at 11:01 AM, Jay Oster <ja...@ko...> wrote:
>>
>>> Bringing the conversation back to the list.
>>>
>>> Thanks for the comments! I'm looking forward to getting the binding out.
>>> It will be compatible with 2.1.x initially. And hopefully 2.2.x soon after
>>> you release it! I'll reconsider the structure of the constants in the
>>> binding.
>>>
>>
>> yes, the NodeJS binding will be awesome to have!
>>
>>
>>
>>> Very valuable feedback so far! Also, I'll try to update the LLVM backend
>>> work I did, and we can collaborate to get NEC V8xx as a new architecture.
>>> Cool!
>>>
>>>
>> great! look forward to your NEC arch.
>>
>>
>> cheers,
>> Q
>>
>>
>>
>>
>>
>>
>>
>>>
>>> On Wed, May 7, 2014 at 7:11 AM, Nguyen Anh Quynh <aq...@gm...>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote:
>>>>
>>>>> Hi List,
>>>>>
>>>>> I've been writing JavaScript (Node.js) bindings for Capstone,
>>>>
>>>>
>>>> very cool! do you have any plan publishing your binding?
>>>>
>>>>
>>>>> and would like to start experimenting with adding new architectures to
>>>>> the lib.
>>>>
>>>>
>>>> which arch do you want to add? so far, the "next" branch of our main
>>>> repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86.
>>>>
>>>> The first question I have about the process is, how does one go about
>>>>> creating the *.inc files? I'm familiar with the concept from LLVM (I spent
>>>>> a few weeks writing a new backend for it).
>>>>>
>>>>> The Capstone source tree is unusual for two reasons: First, it is
>>>>> written in C (TableGen outputs C++) and second, the repo does not contain
>>>>> any Table Description files to generate the *.inc files. Does that mean all
>>>>> of the *.inc files have been hand-written?
>>>>>
>>>>>
>>>> this is a bit complicated: i let LLVM compile their .td files, and get
>>>> generated .inc files, then did a bunch of magic tricks (with some manual
>>>> fixes), and have the .inc files for Capstone.
>>>> you can see that our .inc files are quite different from LLVM's.
>>>>
>>>> I'm interested in any tips or pointers!
>>>>
>>>>
>>>> that is it, but frankly what you are asking should not affect your
>>>> binding and how you implement it.
>>>>
>>>> In the meantime, I've got 4 of the 5 architectures in 2.1.2 working
>>>>> from JavaScript. The new SystemZ and Sparc architectures should be easy to
>>>>> do, as well.
>>>>>
>>>>
>>>> this is great! thanks for letting us know. cant wait to hear more about
>>>> your progress :-)
>>>>
>>>> cheers,
>>>> Q
>>>>
>>>
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>
>
--
regards,
G Lindor
|
|
From: Jason O. <ja...@ko...> - 2014-05-08 06:10:58
|
On May 7, 2014, at 10:50 PM, Nguyen Anh Quynh <aq...@gm...> wrote: > > > > On Thu, May 8, 2014 at 2:02 AM, Jason Oster <ja...@ko...> wrote: > > On May 7, 2014, at 7:11 AM, Nguyen Anh Quynh <aq...@gm...> wrote: >> >> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote: >> Hi List, >> >> I've been writing JavaScript (Node.js) bindings for Capstone, >> >> very cool! do you have any plan publishing your binding? > > Yes, I will be publishing the bindings to npm when complete (probably in a few days). > >> and would like to start experimenting with adding new architectures to the lib. >> >> which arch do you want to add? so far, the "next" branch of our main repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86. > > Mostly I'm interested in supporting older architectures (currently not available in LLVM) and some esoteric machine codes: > > - The 65xx family to start with. > - Then the NEC V8xx family (this was my earlier LLVM project, so I have the *.inc files started for it already) > - Bytecodes for JVM, CIL, ActionScript, etc. > > i find this really cool: so far Capstone only disasm machine code, but there is no reason why it doesnt do bytecode. of course we will not have the same thing like LLVM's opcode tables and such, but we can wrap it around to expose the information to the same interface. > > regarding JVM, CIL, etc: do you have anything in mind? do these come from some public projects, or made by yourself? > > thanks, > Q > Good question... I don't actually have anything to base the bytecode disassemblers at the moment. JVM and CIL are open platforms, though, and well documented: * JVM: http://docs.oracle.com/javase/specs/jvms/se7/html/ and http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings * CIL: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf and http://en.wikipedia.org/wiki/List_of_CIL_instructions LLVM should be able to use either as a backend itself. A quick search reveals a JVM project that can translate LLVM IR to Jasmin assembly language, bypassing LLVM's backends: https://github.com/davidar/lljvm and there was a CIL backend in LLVM for a while, when it was still called MSIL. But it was removed about 4 years ago because no one really used it: https://github.com/llvm-mirror/llvm/commit/885b661e1004978f39cd1d74e586f193dfc0b0a6 |
|
From: Nguyen A. Q. <aq...@gm...> - 2014-05-08 04:47:32
|
On Thu, May 8, 2014 at 12:34 PM, Jason Oster <ja...@ko...> wrote:
> On the JS binding, I added a little helper method to some of the
> dictionaries (registers, instructions, and groups) which will convert a
> register index to a string representation. Here's a contrived example:
>
> var capstone = require("capstone");
>
> var reg = capstone.x86.REG.RSP;
> expect(reg).toEqual(44);
>
> var output = capstone.x86.REG.toString(reg);
> expect(output).toEqual("rsp");
>
> This is in contrast to having constants like `capstone.x86.REG_RSP` and a
> method named `capstone.x86.regToString` or `capstone.x86.INS_PUSHQ` and
> `capstone.x86.insToString`
>
> What are your thoughts? The way I have it now feels more natural in
> JavaScript. But I want to stay true to the common Capstone API.
>
in general, it is best if you can implement the interface like the C API.
this is the principle all the bindings are following so far, because users
can easily switch from one binding to another without having to adapt too
much.
but in fact each language has different way to do things, so if you think
your way is more natural, then just do it.
just try to keep it as clean, simple & close to C API, as possible.
thanks,
Q
>
> On May 7, 2014, at 8:23 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>
>
>
> On Thu, May 8, 2014 at 11:01 AM, Jay Oster <ja...@ko...> wrote:
>
>> Bringing the conversation back to the list.
>>
>> Thanks for the comments! I'm looking forward to getting the binding out.
>> It will be compatible with 2.1.x initially. And hopefully 2.2.x soon after
>> you release it! I'll reconsider the structure of the constants in the
>> binding.
>>
>
> yes, the NodeJS binding will be awesome to have!
>
>
>
>> Very valuable feedback so far! Also, I'll try to update the LLVM backend
>> work I did, and we can collaborate to get NEC V8xx as a new architecture.
>> Cool!
>>
>>
> great! look forward to your NEC arch.
>
>
> cheers,
> Q
>
>
>
>
>
>
>
>>
>> On Wed, May 7, 2014 at 7:11 AM, Nguyen Anh Quynh <aq...@gm...>wrote:
>>
>>>
>>>
>>>
>>> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote:
>>>
>>>> Hi List,
>>>>
>>>> I've been writing JavaScript (Node.js) bindings for Capstone,
>>>
>>>
>>> very cool! do you have any plan publishing your binding?
>>>
>>>
>>>> and would like to start experimenting with adding new architectures to
>>>> the lib.
>>>
>>>
>>> which arch do you want to add? so far, the "next" branch of our main
>>> repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86.
>>>
>>> The first question I have about the process is, how does one go about
>>>> creating the *.inc files? I'm familiar with the concept from LLVM (I spent
>>>> a few weeks writing a new backend for it).
>>>>
>>>> The Capstone source tree is unusual for two reasons: First, it is
>>>> written in C (TableGen outputs C++) and second, the repo does not contain
>>>> any Table Description files to generate the *.inc files. Does that mean all
>>>> of the *.inc files have been hand-written?
>>>>
>>>>
>>> this is a bit complicated: i let LLVM compile their .td files, and get
>>> generated .inc files, then did a bunch of magic tricks (with some manual
>>> fixes), and have the .inc files for Capstone.
>>> you can see that our .inc files are quite different from LLVM's.
>>>
>>> I'm interested in any tips or pointers!
>>>
>>>
>>> that is it, but frankly what you are asking should not affect your
>>> binding and how you implement it.
>>>
>>> In the meantime, I've got 4 of the 5 architectures in 2.1.2 working from
>>>> JavaScript. The new SystemZ and Sparc architectures should be easy to do,
>>>> as well.
>>>>
>>>
>>> this is great! thanks for letting us know. cant wait to hear more about
>>> your progress :-)
>>>
>>> cheers,
>>> Q
>>>
>>
>>
>
>
|
|
From: Jason O. <ja...@ko...> - 2014-05-08 04:34:23
|
On the JS binding, I added a little helper method to some of the dictionaries (registers, instructions, and groups) which will convert a register index to a string representation. Here's a contrived example:
var capstone = require("capstone");
var reg = capstone.x86.REG.RSP;
expect(reg).toEqual(44);
var output = capstone.x86.REG.toString(reg);
expect(output).toEqual("rsp");
This is in contrast to having constants like `capstone.x86.REG_RSP` and a method named `capstone.x86.regToString` or `capstone.x86.INS_PUSHQ` and `capstone.x86.insToString`
What are your thoughts? The way I have it now feels more natural in JavaScript. But I want to stay true to the common Capstone API.
On May 7, 2014, at 8:23 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>
>
> On Thu, May 8, 2014 at 11:01 AM, Jay Oster <ja...@ko...> wrote:
> Bringing the conversation back to the list.
>
> Thanks for the comments! I'm looking forward to getting the binding out. It will be compatible with 2.1.x initially. And hopefully 2.2.x soon after you release it! I'll reconsider the structure of the constants in the binding.
>
> yes, the NodeJS binding will be awesome to have!
>
>
>
> Very valuable feedback so far! Also, I'll try to update the LLVM backend work I did, and we can collaborate to get NEC V8xx as a new architecture. Cool!
>
>
> great! look forward to your NEC arch.
>
>
> cheers,
> Q
>
>
>
>
>
>
>
> On Wed, May 7, 2014 at 7:11 AM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
>
>
> On Wed, May 7, 2014 at 3:45 PM, Jason Oster <ja...@ko...> wrote:
> Hi List,
>
> I've been writing JavaScript (Node.js) bindings for Capstone,
>
> very cool! do you have any plan publishing your binding?
>
> and would like to start experimenting with adding new architectures to the lib.
>
> which arch do you want to add? so far, the "next" branch of our main repo already supported 7 archs: Arm, Arm64, Mips, PPC, Sparc, SystemZ & X86.
>
> The first question I have about the process is, how does one go about creating the *.inc files? I'm familiar with the concept from LLVM (I spent a few weeks writing a new backend for it).
>
> The Capstone source tree is unusual for two reasons: First, it is written in C (TableGen outputs C++) and second, the repo does not contain any Table Description files to generate the *.inc files. Does that mean all of the *.inc files have been hand-written?
>
>
> this is a bit complicated: i let LLVM compile their .td files, and get generated .inc files, then did a bunch of magic tricks (with some manual fixes), and have the .inc files for Capstone.
> you can see that our .inc files are quite different from LLVM's.
>
> I'm interested in any tips or pointers!
>
> that is it, but frankly what you are asking should not affect your binding and how you implement it.
>
> In the meantime, I've got 4 of the 5 architectures in 2.1.2 working from JavaScript. The new SystemZ and Sparc architectures should be easy to do, as well.
>
> this is great! thanks for letting us know. cant wait to hear more about your progress :-)
>
> cheers,
> Q
>
>
|
