capstone-users — Capstone mailing list for users

Re: [Capstone-users] TableGen

[Jay O. <ja...@ko...>]

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.

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!


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
>

Re: [Capstone-users] TableGen

[Nguyen A. Q. <aq...@gm...>]

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
>>
>
>

Re: [Capstone-users] TableGen

[Nguyen A. Q. <aq...@gm...>]

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

[Capstone-users] TableGen

[Jason O. <ja...@ko...>]

Hi List,

I've been writing JavaScript (Node.js) bindings for Capstone, and would like to start experimenting with adding new architectures to the lib. 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?

I'm interested in any tips or pointers! 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.

Cheers,
Jay

[Capstone-users] Capstone packaged for Debian.

[David M. M. <en...@de...>]

	Hello, guys.  I just packaged capstone 2.1.2 and the Python bindings for Debian
(testing/unstable).  They're in the NEW queue for now, but I wrote a blog post
with more instructions and a place to get the packages for now.

http://thesaltflats.blogspot.com/2014/05/capstone-packaged-for-debian.html

	Enjoy!


		Ender.

Re: [Capstone-users] bad regs_read_count and regs_write_count for x86-64 code?

[Nguyen A. Q. <aq...@gm...>]

On Sun, May 4, 2014 at 8:16 AM, Jann Horn <ja...@th...> wrote:

> On Sun, May 04, 2014 at 08:11:44AM +0800, Nguyen Anh Quynh wrote:
> > i think this is explained quite clear in the docs (capstone.h): what we
> get
> > back from these APIs are the *implicit* registers read/written by the
> > instructions.
>
> Oh, thanks. Sorry for the noise.
>

no problem. perhaps this is not clear enough, and should get emphasized
more in the docs.

cheers,
Q

Re: [Capstone-users] bad regs_read_count and regs_write_count for x86-64 code?

[Jann H. <ja...@th...>]

On Sun, May 04, 2014 at 08:11:44AM +0800, Nguyen Anh Quynh wrote:
> i think this is explained quite clear in the docs (capstone.h): what we get
> back from these APIs are the *implicit* registers read/written by the
> instructions.

Oh, thanks. Sorry for the noise.

Re: [Capstone-users] bad regs_read_count and regs_write_count for x86-64 code?

[Nguyen A. Q. <aq...@gm...>]

On Sun, May 4, 2014 at 6:39 AM, Jann Horn <ja...@th...> wrote:

> Hello,
> I have heard about capstone in the past and wanted to play with it a bit.
> Looks
> like a cool project! I'm having some trouble with its API though – I'm
> getting
> wrong values for regs_read_count and regs_write_count in struct cs_detail.
>
> Here's a testcase:
>
> --------------------------------------------------------------------------
> #include <stdio.h>
> #include <inttypes.h>
> #include <capstone/capstone.h>
>
> #define CODE
> "\x48\x85\xff\x74\x0b\x48\x8b\x07\x48\x8b\x40\x00\xff\xe0\x66\x90\xf3\xc3"
>
> int main(void) {
>   csh handle;
>   if (cs_open(CS_ARCH_X86, CS_MODE_64, &handle) != CS_ERR_OK) return -1;
>   if (cs_option(handle, CS_OPT_DETAIL, CS_OPT_ON) != CS_ERR_OK) return -1;
>   cs_insn *insn = NULL;
>   size_t count = cs_disasm_ex(handle, (unsigned char*)CODE,
> sizeof(CODE)-1, 0x1000, 0, &insn);
>   for (size_t j = 0; j < count; j++) {
>     cs_detail *dt = insn[j].detail;
>     printf("nread:%hhu\tnwrite:%hhu\t%s %s\n", dt->regs_read_count,
> dt->regs_write_count, insn[j].mnemonic, insn[j].op_str);
>   }
>   cs_free(insn, count);
>   cs_close(&handle);
>   return 0;
> }
> --------------------------------------------------------------------------
>
> This is the output I get:
> nread:0 nwrite:1        test rdi, rdi
> nread:1 nwrite:0        je 0x1010
> nread:0 nwrite:0        mov rax, qword ptr [rdi]
> nread:0 nwrite:0        mov rax, qword ptr [rax]
> nread:0 nwrite:0        jmp rax
> nread:0 nwrite:0        nop
> nread:1 nwrite:1        rep ret
>
>
i think this is explained quite clear in the docs (capstone.h): what we get
back from these APIs are the *implicit* registers read/written by the
instructions.


> Shouldn't the test instruction read rdi and write flags?


because FLAGS is implicit register here, but RDI is explicit, so not
counted.



> Shouldn't the jump
> write into RIP but not read anything? And those mov instructions both read
> and
> write registers, right? And why doesn't the second jump read anything?
>

same reason for all these instructions. and in all the case EIP/RIP is
always modified after each instruction, no matter what, so that is never
counted because it is *explicit*.

i suppose there can be a mistake in some instruction regarding this
"implicit" register information, so please report if you find anything
wrong.

thanks,
Q

[Capstone-users] bad regs_read_count and regs_write_count for x86-64 code?

[Jann H. <ja...@th...>]

Hello,
I have heard about capstone in the past and wanted to play with it a bit. Looks
like a cool project! I'm having some trouble with its API though – I'm getting
wrong values for regs_read_count and regs_write_count in struct cs_detail.

Here's a testcase:

--------------------------------------------------------------------------
#include <stdio.h>
#include <inttypes.h>
#include <capstone/capstone.h>

#define CODE "\x48\x85\xff\x74\x0b\x48\x8b\x07\x48\x8b\x40\x00\xff\xe0\x66\x90\xf3\xc3"

int main(void) {
  csh handle;
  if (cs_open(CS_ARCH_X86, CS_MODE_64, &handle) != CS_ERR_OK) return -1;
  if (cs_option(handle, CS_OPT_DETAIL, CS_OPT_ON) != CS_ERR_OK) return -1;
  cs_insn *insn = NULL;
  size_t count = cs_disasm_ex(handle, (unsigned char*)CODE, sizeof(CODE)-1, 0x1000, 0, &insn);
  for (size_t j = 0; j < count; j++) {
    cs_detail *dt = insn[j].detail;
    printf("nread:%hhu\tnwrite:%hhu\t%s %s\n", dt->regs_read_count, dt->regs_write_count, insn[j].mnemonic, insn[j].op_str);
  }
  cs_free(insn, count);
  cs_close(&handle);
  return 0;
}
--------------------------------------------------------------------------

This is the output I get:
nread:0 nwrite:1        test rdi, rdi
nread:1 nwrite:0        je 0x1010
nread:0 nwrite:0        mov rax, qword ptr [rdi]
nread:0 nwrite:0        mov rax, qword ptr [rax]
nread:0 nwrite:0        jmp rax
nread:0 nwrite:0        nop 
nread:1 nwrite:1        rep ret 

Shouldn't the test instruction read rdi and write flags? Shouldn't the jump
write into RIP but not read anything? And those mov instructions both read and
write registers, right? And why doesn't the second jump read anything?

-- Jann

[Capstone-users] Python3 support

[Nguyen A. Q. <aq...@gm...>]

hi,

a quick annoucement: Capstone now supports Python3. most of the hard work
was done by Fenuks!

see https://github.com/aquynh/capstone/wiki/ChangeLog for more details.

cheers,
Q

[Capstone-users] new SKIPDATA mode for Capstone

[Nguyen A. Q. <aq...@gm...>]

hi,

Capstone stops disassembling when it encounters a broken instruction. but i
got quite a few requests to make Capstone keep going by skipping some data
until it hits a legitimate instruction again.

so here is the new mode: SKIPDATA. see the code in the "next" branch, and
docs at

    http://capstone-engine.org/skipdata.html

when SKIPDATA mode is turned ON, the output can be like the text at the
bottom (note ".byte" lines).

any comment?

thanks,
Q

************
Platform: X86 32 (Intel syntax)
Code: 0x8d 0x4c 0x32 0x08 0x01 0xd8 0x81 0xc6 0x34 0x12 0x00 0x00 0x00 0x91
0x92
Disasm:
0x1000:    lea    ecx, dword ptr [edx + esi + 8]
0x1004:    add    eax, ebx
0x1006:    add    esi, 0x1234
0x100c:    .byte    0x00
0x100d:    xchg    eax, ecx
0x100e:    xchg    eax, edx

****************
Platform: Arm
Code: 0xed 0x00 0x00 0x00 0x00 0x1a 0x5a 0x0f 0x1f 0xff 0xc2 0x09 0x80 0x00
0x00 0x00 0x07 0xf7 0xeb 0x2a 0xff 0xff 0x7f 0x57 0xe3 0x01 0xff 0xff 0x7f
0x57 0xeb 0x00 0xf0 0x00 0x00 0x24 0xb2 0x4f 0x00 0x78
Disasm:
0x1000:    andeq    r0, r0, sp, ror #1
0x1004:    svceq    #0x5a1a00
0x1008:    stmibeq    r2, {r0, r1, r2, r3, r4, r8, sb, sl, fp, ip, sp, lr,
pc} ^
0x100c:    andeq    r0, r0, r0, lsl #1
0x1010:    bhs    #-0x5023e4
0x1014:    .byte    0xff, 0xff, 0x7f, 0x57
0x1018:    .byte    0xe3, 0x01, 0xff, 0xff
0x101c:    rsceq    r5, fp, pc, ror r7
0x1020:    strhs    r0, [r0], #-0xf0
0x1024:    stmdavc    r0, {r1, r4, r5, r7, r8, sb, sl, fp, lr}

[Capstone-users] Capstone 2.1.2 released!

[Nguyen A. Q. <aq...@gm...>]

(Sorry, the last annoucement mail was without tittle)

Greetings,

On the occasion of Syscan 2014, we are happy to announce Capstone
disassembly framework version 2.1.2!

This stable release makes no update on the API, so bindings from version
2.1 can still be used with this new release 2.1.2 just fine.

Important changes:

- Support cross-compilation for all iDevices (iPhone/iPad/iPod).
- X86: do not print memory offset in negative form.
- Fix a bug in X86 where Capstone cannot handle some short instructions.
- Print negative numbers in range [-9, -1] without prefix 0x (Arm, Arm64,
Mips).
- Correct the SONAME setup for library versioning on Linux, *BSD & Solaris.
- Set library versioning for dylib of Mac OSX.

Source code, precompiled binaries & further details are available at
http://www.capstone-engine.org


Thanks,
Quynh

[Capstone-users] (no subject)

[Nguyen A. Q. <aq...@gm...>]

Greetings,

On the occasion of Syscan 2014, we are happy to announce Capstone
disassembly framework version 2.1.2!

This stable release makes no update on the API, so bindings from version
2.1 can still be used with this new release 2.1.2 just fine.

Important changes:

- Support cross-compilation for all iDevices (iPhone/iPad/iPod).
- X86: do not print memory offset in negative form.
- Fix a bug in X86 where Capstone cannot handle some short instructions.
- Print negative numbers in range [-9, -1] without prefix 0x (Arm, Arm64,
Mips).
- Correct the SONAME setup for library versioning on Linux, *BSD & Solaris.
- Set library versioning for dylib of Mac OSX.

Source code, precompiled binaries & further details are available at
http://www.capstone-engine.org


Thanks,
Quynh

Re: [Capstone-users] [Capstone-Beta] Compact X86 engine - new compile time option

[Sergi A. <pa...@no...>]

I dont think 'compact' means removing groups of supported instructions. Otherwise i would prefer a different name like 'strippeddown' or 'reduced (instruction set)' or 'general purpose instructions' ... What about choosing which instruction set groups do we want to support and make this available for all the arches?



> On 26 Mar 2014, at 12:51, Nguyen Anh Quynh <aq...@gm...> wrote:
> 
> hi,
> 
> i had some discussions with Alex (at Syscan), and decided that Capstone's X86 engine should be made smaller for kernel/firmware embedding. 
> 
> as a result, i just added a new compile option: CAPSTONE_X86_COMPACT. all you need to do is to modify its value (from ‘no’ to ‘yes’) in config.mk, then recompile.
> 
> thanks to this option, Capstone binary size for X86 can be reduced 60%, to just under 200KB. so nobody should complain about the lib size now :-)
> 
> internally, this is done by removing some exotic instruction sets such as MMX, SEE, FPU, etc. therefore, this option is only feasible if the code you disasm does not use these instructions, such as in OS kernel.
> 
> find further details at http://capstone-engine.org/x86compact.html
> 
> the code is available in the “next” branch at https://github.com/aquynh/capstone/tree/next
> 
> cheers,
> Q
> 
> -- 
> You received this message because you are subscribed to the Google Groups "capstone-engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap...@go....
> To post to this group, send email to cap...@go....
> For more options, visit https://groups.google.com/d/optout.

[Capstone-users] Compact X86 engine - new compile time option

[Nguyen A. Q. <aq...@gm...>]

hi,

i had some discussions with Alex (at Syscan), and decided that Capstone's
X86 engine should be made smaller for kernel/firmware embedding.

as a result, i just added a new compile option: CAPSTONE_X86_COMPACT. all
you need to do is to modify its value (from 'no' to 'yes') in config.mk,
then recompile.

thanks to this option, Capstone binary size for X86 can be reduced 60%, to
just under 200KB. so nobody should complain about the lib size now :-)

internally, this is done by removing some exotic instruction sets such as
MMX, SEE, FPU, etc. therefore, this option is only feasible if the code you
disasm does not use these instructions, such as in OS kernel.

find further details at http://capstone-engine.org/x86compact.html

the code is available in the "next" branch at
https://github.com/aquynh/capstone/tree/next

cheers,
Q

[Capstone-users] SystemZ arch is live!

[Nguyen A. Q. <aq...@gm...>]

hi,

i have just added SystemZ arch support to the "next" branch of Capstone.

    https://github.com/aquynh/capstone/tree/next

what does this mean? this means you can reverse your IBM mainframe code now
(http://www-03.ibm.com/systems/z/hardware/)

for sample C code, see tests/test*.c.
for sample Python code, see bindings/python/test*.py
for sample Java code, see bindings/java/Test*.java

like always, this comes with full breakdown details on disassembled
instructions & their semantics.

cheers,
Q

[Capstone-users] CEbot: disasm from your Twitter account

[Capstone E. <cap...@gm...>]

Hi,

We are running CEbot, a tool that lets you reverse hexcode from your own
Twitter!

How? Do this in 2 easy steps:

- Tweet your hex string with either hashtag #2ce (read as:
"To-Capstone-Engine"), or #cebot.
- Wait 1~2 seconds, the assembly code will be sent back, also via Twitter.
Be sure to check the "Notifications" tab if you do not see it soon enough.


Few examples on tweets accepted by CEbot:

x32 909090 #2ce
    Reverse x86 32-bit code with hex-string of 3 bytes 909090. The result
sent back would be 3 NOP instructions.

x64 att 0x90 0x90 0x90 #2ce
    Reverse x86-64 code with hex-string of the same 3 bytes, but get back
assembly in AT&T syntax.

arm #2ce "\x04\xe0\x2d\xe5"
    Reverse ARM code. Note that the hashtag can be put anywhere in the
tweet.

m64 be 0C,10,00,97 #2ce
    Reverse Mips 64-bit code in big-endian mode.


For further details, see http://capstone-engine.org/bot.html

This is mainly for fun, but hopefully it can be useful for those who are on
Twitter all the time :-)
Any suggestions, let us know.

Cheers,
Capstone Engine

[Capstone-users] Capstone disassembly framework 2.1.1 released!

[Nguyen A. Q. <aq...@gm...>]

Greetings,

We are glad to announce Capstone disassembly framework version 2.1.1!

This stable release fixes some bugs deep in the core. There is no update to
any architectures or bindings, so bindings version 2.1 can still be used
with this version 2.1.1 just fine.

Core changes:

- Fix a buffer overflow bug in Thumb mode (ARM).

- Fix a crash when embedding Capstone into OSX kernel. This should also
enables Capstone to be embedded into other systems with similarly limited
stack memory size such as Linux kernel or some firmwares.

- Use a proper SONAME for library versioning (Linux).

More information is available in our homepage at
http://www.capstone-engine.org

Thanks,
Quynh

[Capstone-users] Sparc & 2.2 API

[Nguyen A. Q. <aq...@gm...>]

hi,

i have just added Sparc as the 6th arch supported by Capstone into the
"next" tree.

due to this core change, the API version was bumped to from 2.1 to 2.2

    https://github.com/aquynh/capstone/wiki/ChangeLog

if you see any bugs, please report.

thanks,
Q

[Capstone-users] Capstone disassembly framework 2.1 released!

[Nguyen A. Q. <aq...@gm...>]

Greetings,

We are excited to announce Capstone 2.1!

The source code & all the software packages are available at
http://capstone-engine.org.

Capstone users are strongly recommended to upgrade to this version, which
brings many important changes:

- Update all 5 arches with new instructions & bug fixes: Arm, Arm64, Mips,
PPC & X86.

- Library size is around 40% smaller, but framework is faster. Especially,
X86-only binary is about 3 times smaller than in version 2.0: it is only
780 KB now.

- Support "diet" compilation option to minimize the framework, making
Capstone more suitable for embedding into OS kernel or firmware. Example:
X86-only engine is only 480 KB now.

- Consume less memory: around 40% less than version 2.0.

- Python binding offers some new lighter APIs that can improve performance
up to 30%.

- Fixed some memory leaking issues of Java & Cython bindings.

- Lots of minor bugfixes.

- API version bumped to 2.1.


IMPORTANT:

1. We make some minor changes to API. See
http://capstone-engine.org/version_2.1_API.html for how to adapt your
existing code to this version.

2. Make sure to (re)install the Python/Java bindings coming with this
version, as the old bindings from 2.0 are *incompatible* with the new core.
Same applies for C#, Go, Ruby & Vala bindings provided by community.

Thanks,
Quynh

[Capstone-users] Version 2.1-RC1 is out!

[Nguyen A. Q. <aq...@gm...>]

Greetings,

We are pleased to announce Capstone version 2.1-RC1!

The source code tarball is available at:

  http://capstone-engine.org/download/2.1/capstone-2.1-rc1.tgz

And also at the tagname 2.1-rc1 in our Github repo at:

  https://github.com/aquynh/capstone/releases/tag/2.1-rc1

This version brings some important changes:

- Library size is around 40% smaller, but framework is faster. Especially,
X86-only binary is about 3 times smaller than in version 2.0: only 780 KB
now.

- Support diet compilation option to minimize the framework, making
Capstone more suitable for embedding into OS kernel or firmware. Example:
X86-only engine is only 480 KB now.

- Consume less memory: around 40% less than version 2.0.

- Python binding offers some new lighter APIs that can improve performance
up to 30%.

- Fixed some memory leaking issues of Java & Cython bindings.

- Lots of bugfixes.

- API version bumped to 2.1.


Changelog details are available at:

  https://github.com/aquynh/capstone/wiki/ChangeLog

Please test and report your findings via our contact at
http://www.capstone-engine.org/contact.html

IMPORTANT: make sure to install the Python/Java bindings coming with this
version, as the old
bindings from version 2.0 are incompatible with the new core.


Thanks,
Quynh

[Capstone-users] Towards next version of Capstone

[Nguyen A. Q. <aq...@gm...>]

hi,

we are going to release next version of Capstone very soon. please help to
test the code in "next" branch to keep it as less buggy as possible.

we have updated all 5 arches, with new instructions supported, especially
X86. we got some important bug fixes too, so you might want to check it out.

an important change: Capstone now is around 3 times smaller than in 2.0. if
you compile X86-only (by modifying config.mk before compiling), the lib
size reduces from 2MB to around 700KB.
so it is easier than ever to embed Capstone anywhere.

see https://github.com/aquynh/capstone/wiki/ChangeLog for more details.

thanks,
Q

[Capstone-users] MSVC compilation for Capstone

[Nguyen A. Q. <aq...@gm...>]

hi,

Alex Ionescu provided a port of Capstone, so we can use Visual Studio to
compile our framework. you can find the code at "msvc" branch, at:

https://github.com/aquynh/capstone/tree/msvc

you can also get .ZIP file at
https://github.com/aquynh/capstone/archive/msvc.zip

at the moment, this is for MSVS 2013, and support 32bit only.

please give it a try, and if you can make it work with earlier MSVS +
64bit, please ping me.

cheers,
Quynh

Re: [Capstone-users] python 3.x

[Nguyen A. Q. <aq...@gm...>]

On Mon, Jan 27, 2014 at 5:26 AM, Benoit Lecocq <bl...@ar...> wrote:

> Hi,
>
> Is it possible to use Python 3.x with capstone ?
> I only read reference to Python 2.x.
>
>
no, Python 3 is not supported yet.

do you want to submit a patch for that?

thanks.
Q

[Capstone-users] python 3.x

[Benoit L. <bl...@ar...>]

Hi,

Is it possible to use Python 3.x with capstone ?
I only read reference to Python 2.x.

Cheers,
benoit