capstone-users — Capstone mailing list for users

Re: [Capstone-users] Postincrement or postdecrement?

[Yegor D. <yeg...@gm...>]

On Sun, Oct 05, 2014 at 09:18:31PM +0800, Nguyen Anh Quynh wrote:
> - can you confirm that you are using the latest code from the "next"
> branch?
Yes. Confirm for fe4822.

> - what is the input hexcode for these 2 instructions? are they both in ARM
> mode + little endian?

$ LANG=C /usr/arm-linux-gnueabi/bin/objdump -d postincrement.o 

postincrement.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <.text>:
   0:   000080f4        strdeq  r8, [r0], -r4
   4:   008080f4        strdeq  r8, [r0], r4

Thanks for help.

-- 
Yegor Derevenets

Re: [Capstone-users] Postincrement or postdecrement?

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

On Sun, Oct 5, 2014 at 6:33 PM, Yegor Derevenets <yeg...@gm...
> wrote:

> Hi,
>
> suppose I disassembled the two ARM instructions:
>
>     strdeq r8, sb, [r0], -r4
>     strdeq r8, sb, [r0], r4
>
> How do I find out the sign before r4? I dumped the contents of the
> operands array for the two instructions, and it seems to be the same for
> both instructions:
>

this sounds like a bug.

- can you confirm that you are using the latest code from the "next"
branch?

- what is the input hexcode for these 2 instructions? are they both in ARM
mode + little endian?

thanks,
Q

[Capstone-users] Postincrement or postdecrement?

[Yegor D. <yeg...@gm...>]

Hi,

suppose I disassembled the two ARM instructions:

    strdeq r8, sb, [r0], -r4
    strdeq r8, sb, [r0], r4

How do I find out the sign before r4? I dumped the contents of the
operands array for the two instructions, and it seems to be the same for
both instructions:

op[0].type = 1
op[0].shift.type = 0
op[0].shift.value = 0
op[0].reg = 74
op[1].type = 1
op[1].shift.type = 0
op[1].shift.value = 0
op[1].reg = 75
op[2].type = 6
op[2].shift.type = 0
op[2].shift.value = 0
op[2].mem.base = 66
op[2].mem.disp = 0
op[2].mem.index = 0
op[2].mem.scale = 1
op[3].type = 1
op[3].shift.type = 0
op[3].shift.value = 0
op[3].reg = 70

Any suggestions, other than parsing the textual representation of the
instruction?

Thanks.

-- 
Yegor Derevenets

[Capstone-users] Capstone 3.0-RC1 released!

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

Greetings,

We are pleased to announce the Release Candidate 1 of version 3.0 of
Capstone disassembly framework!

Find the link to source code at
http://capstone-engine.org/Version-3.0-RC1.html

Or get it from the tag name “3.0-rc1” in our Github repo at
https://github.com/aquynh/capstone

Please test and report all the issues you can find.


NOTE: The old bindings from version 2.x are incompatible with this version,
so must be updated.
For Java/Ocaml/Python bindings, see respective README files under bindings/
directory in
the source for how to do fresh-install.


Summary of important changes of version 3.0-rc1:

- New architectures: Sparc, SystemZ & XCore.

- Important bugfixes for Arm, Arm64, Mips, PowerPC & X86.

- X86 engine now can decode 3DNow instructions.

- X86 engine is mature & handles all the malware tricks that we are aware
of. If you have any code that Capstone wrongly processes, please report.

- Mips engine added supports for new hardware modes: Mips3, Mips32R6 &
MipsGP64.

- Support for Microsoft Visual Studio (so Windows native compilation using
MSVC is possible).

- Support CMake compilation.

- Cross-compile for Android.

- Much faster, while consuming less memory for all architectures.

- API version was bumped to 3.0.

- Renamed API cs_disasm_ex to cs_disasm (cs_disasm_ex is marked obsolete to
be removed in future versions)

- Support SKIPDATA mode, so Capstone can jump over unknown data and keep
going from the next legitimate instruction.

- Python binding supports Python3.

- Support Ocaml binding.

Thanks.
Capstone Engine Team

Re: [Capstone-users] llvm tblgen?

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

On Fri, Sep 26, 2014 at 12:59 AM, David Brumley <dbr...@cm...> wrote:

> Hi,
> Capstone looks like a really cool engine for parsing instructions.  You
> mentioned it was a port from LLVM.
>

yes, see our Blackhat slides:
http://capstone-engine.org/BHUSA2014-capstone.pdf

i saw BAP tries to implement some independent disassembler inside, which is
not right thing to do on engineering-wise, IMHO.

BAP can switch to use Capstone, which already has Ocaml binding in "v3"
branch

https://github.com/aquynh/capstone/tree/v3/bindings/ocaml

(we will release new version 3.0 soon with Ocaml binding inside)


> One question I have is whether there is a way to update capstone as LLVM
> is updated, e.g., suppose LLVM updates an instruction, is there a way to
> automatically incorporate this into capstone?  It looks like you might be
> using tblgen as a basis; is there code around this that I'm not seeing in
> the project?
>

yes, we try to do everything automatically, but the process of updating
Capstone is still partly manual.
this is the target, but not priority at the moment.


thanks,
Quynh


>

[Capstone-users] llvm tblgen?

[David B. <dbr...@cm...>]

Hi,
Capstone looks like a really cool engine for parsing instructions.  You
mentioned it was a port from LLVM.

One question I have is whether there is a way to update capstone as LLVM is
updated, e.g., suppose LLVM updates an instruction, is there a way to
automatically incorporate this into capstone?  It looks like you might be
using tblgen as a basis; is there code around this that I'm not seeing in
the project?

Thanks,
David

[Capstone-users] Capstone 3.0 & Testimonials

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

hi,

given that quite a lot of time since the last official release, and code
has gone thru major changes, we are preparing to release Capstone 3.
version 3.0-RC1 will be out soon enough.

meanwhile, if you want to try the latest code, see the branch "v3" in our
github repo:

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

towards this major release, we have been collecting testimonials from
Capstone users. you can see what we got so far here:

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

a request: if anybody here is actively using Capstone and happy with that,
please send us more testimonials. this collecting process is never close :-)

cheers,
Q

Re: [Capstone-users] Feature requests

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

On Sat, Sep 20, 2014 at 8:39 PM, Yegor Derevenets <
yeg...@gm...> wrote:

> On Sat, Sep 20, 2014 at 09:34:50AM +0800, Nguyen Anh Quynh wrote:
> > i dont really get this: all you need to include is capstone.h (which
> > internally includes arm.h, x86.h and everything else), so how can you get
> > name conflict here?
>
> Ah. I missed the fact that capstone.h includes arm.h. Then, except the
> fact that the internal header arm.h is globally available as <arm.h>, I
> have no complaints. :)
>
>
but that arm.h is never supposed to be used by anything except capstone.h,
so we have no problem with that "global" arm.h file.



> > if you can fix all those "comparison of integers of different signs:
> 'int'
> > and 'unsigned long'" bugs and send in Pull-request, then great!
>
> Roger. But I will probably make Capstone compile under MSVC 2010 first.
>
>
feel free to copy & use msinttypes from
https://code.google.com/p/msinttypes/.
look forward to your PR :-)

at the same time, you might want to checkout msvc support already available
in msvc/.
this should handle the issue of inttypes.h automatically for VC 2010. see
COMPILE_MSVC.TXT for more info.


thanks.
Q

Re: [Capstone-users] Feature requests

[Yegor D. <yeg...@gm...>]

On Sat, Sep 20, 2014 at 09:34:50AM +0800, Nguyen Anh Quynh wrote:
> i dont really get this: all you need to include is capstone.h (which
> internally includes arm.h, x86.h and everything else), so how can you get
> name conflict here?

Ah. I missed the fact that capstone.h includes arm.h. Then, except the
fact that the internal header arm.h is globally available as <arm.h>, I
have no complaints. :)

> if you can fix all those "comparison of integers of different signs: 'int'
> and 'unsigned long'" bugs and send in Pull-request, then great!

Roger. But I will probably make Capstone compile under MSVC 2010 first.

-- 
Yegor Derevenets

Re: [Capstone-users] Feature requests

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

On Sat, Sep 20, 2014 at 1:17 AM, Yegor Derevenets <
yeg...@gm...> wrote:

> On Sat, Sep 20, 2014 at 12:22:24AM +0800, Nguyen Anh Quynh wrote:
> > i think the current setup is standard method. projects using Capstone
> must
> > set the including paths properly with -I, which is trivial.
>
> Which directory you mean one should write after -I? Writing
> -Icapstone/include is somewhat ugly, because it makes headers with
> relatively widespread names like arm.h become available as <arm.h>. If
> every library would require doing so, there would be name clashes and
> surprises.
>


i dont really get this: all you need to include is capstone.h (which
internally includes arm.h, x86.h and everything else), so how can you get
name conflict here?




>
> > > 3. MSVC 2010 is famous for not providing <inttypes.h>. Is there a
> > > workaround planned to make Capstone compilable by MSVC 2010?
> > hmm, perhaps we should use msinttypes when MSVC version < vs2010?
> > something like:
> >
> > #if defined(_MSC_VER) && _MSC_VER < 1700
> > #include "msvc/inttypes.h"
> > #endif
>
> Makes sense. I would write a special header file that includes either
> one or the other inttypes.h, depending on _MSC_VER.
>
> > > 4. Any plans about fixing warnings produced by GCC/Clang with -Wall?
> > > There are tons of complaints about unused function arguments.
> > can you post all the warnings here?
>
> Sorry, I really meant -Wextra. A build log is attached.
>

if you can fix all those "comparison of integers of different signs: 'int'
and 'unsigned long'" bugs and send in Pull-request, then great!

on the "warning: unused parameter" issue: this is not critical, we can
focus on that later.

thanks.
Q

Re: [Capstone-users] Feature requests

[Yegor D. <yeg...@gm...>]

On Sat, Sep 20, 2014 at 12:22:24AM +0800, Nguyen Anh Quynh wrote:
> i think the current setup is standard method. projects using Capstone must
> set the including paths properly with -I, which is trivial.

Which directory you mean one should write after -I? Writing
-Icapstone/include is somewhat ugly, because it makes headers with
relatively widespread names like arm.h become available as <arm.h>. If
every library would require doing so, there would be name clashes and
surprises.

> > 3. MSVC 2010 is famous for not providing <inttypes.h>. Is there a
> > workaround planned to make Capstone compilable by MSVC 2010?
> hmm, perhaps we should use msinttypes when MSVC version < vs2010?
> something like:
> 
> #if defined(_MSC_VER) && _MSC_VER < 1700
> #include "msvc/inttypes.h"
> #endif

Makes sense. I would write a special header file that includes either
one or the other inttypes.h, depending on _MSC_VER.

> > 4. Any plans about fixing warnings produced by GCC/Clang with -Wall?
> > There are tons of complaints about unused function arguments.
> can you post all the warnings here?

Sorry, I really meant -Wextra. A build log is attached.

-- 
Yegor Derevenets

Re: [Capstone-users] Feature requests

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

On Fri, Sep 19, 2014 at 6:14 PM, Yegor Derevenets <
yeg...@gm...> wrote:

> Hi,
>
> I am using Capstone (namely, its 'next' branch) inside a project using
> CMake as a build system. Here is a list of improvements that would be
> great to have.
>
> 1. Add some prefix to all the CMake configuration options, e.g.:
> BUILD_STATIC -> CAPSTONE_BUILD_STATIC. Otherwise, Capstone pollutes the
> CMake cache with names that do not show any relation to the library.
>

this is really trivial. do you mind fixing this and sending a pull-request
on Github for this?


>
> 2. Header files currently located in 'include' should be moved to
> something like 'include/capstone'. Otherwise, when one uses system-wide
> Capstone installation, one has to write #include <capstone/capstone.h>,
> and when one uses Capstone as a subproject, one has to write #include
> <include/capstone.h> or <capstone.h> (depending on what one gave to
> include_directories()).
>
>
i think the current setup is standard method. projects using Capstone must
set the including paths properly with -I, which is trivial.




> 3. MSVC 2010 is famous for not providing <inttypes.h>. Is there a
> workaround planned to make Capstone compilable by MSVC 2010?
>
>
hmm, perhaps we should use msinttypes when MSVC version < vs2010?
something like:

#if defined(_MSC_VER) && _MSC_VER < 1700
#include "msvc/inttypes.h"
#endif




4. Any plans about fixing warnings produced by GCC/Clang with -Wall?
> There are tons of complaints about unused function arguments.
>
>
can you post all the warnings here?
btw, this issue is trivial to handle. would be great if you just go ahead
fixing them and send in the pull-request, i will merge it.



thanks.
Q



>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>

[Capstone-users] Feature requests

[Yegor D. <yeg...@gm...>]

Hi,

I am using Capstone (namely, its 'next' branch) inside a project using
CMake as a build system. Here is a list of improvements that would be
great to have.

1. Add some prefix to all the CMake configuration options, e.g.:
BUILD_STATIC -> CAPSTONE_BUILD_STATIC. Otherwise, Capstone pollutes the
CMake cache with names that do not show any relation to the library.

2. Header files currently located in 'include' should be moved to
something like 'include/capstone'. Otherwise, when one uses system-wide
Capstone installation, one has to write #include <capstone/capstone.h>,
and when one uses Capstone as a subproject, one has to write #include
<include/capstone.h> or <capstone.h> (depending on what one gave to
include_directories()).

3. MSVC 2010 is famous for not providing <inttypes.h>. Is there a
workaround planned to make Capstone compilable by MSVC 2010?

4. Any plans about fixing warnings produced by GCC/Clang with -Wall?
There are tons of complaints about unused function arguments.

Thank you.

-- 
Yegor Derevenets

Re: [Capstone-users] LLVM Bitcode as Input File

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

On Tue, Sep 16, 2014 at 11:20 PM, Peter Lucia <pe...@ro...> wrote:

> Yes, I want disassemble LLVM bitcode to LLVM assembly.  Basically I want
> to do exactly what llvm-dis does, but I'd like to have
> the programmatic bindings that capstone provides; ie: get list of all the
> instructions with each instruction object having it's opcode,
> source registers, and destination registers broken out in nice
> Python/Ruby/C#/Java/etc. objects.  Ideally, I'd like to use some of the
> same tools already built (or that I build in the future) using capstone but
> with LLVM bitcode files as source instead of *insert architecture here*
> machine code files.  Sorry for not being clear at first.
>
> I'll take a look at the llvm-dis source, the question really is how hard
> will it be to integrate that source into capstone so we have API parity
> with the other supported input machine languages.  Thanks for any further
> thoughts you have now or in the future regarding this!
>

the difference is that you would have to feed Capstone the whole LLVM
bitcode binary file, not just a chunk of binary bytes like with machine
code.

i havent looked that the code of llm-dis, but i dont think this is too
hard, as it does not involve any backend here.

if you make it, please share the code. i am curious ....

thanks.



> Peter
>
> On Tue, Sep 16, 2014 at 10:10 AM, Nguyen Anh Quynh <aq...@gm...>
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 10:06 PM, Nguyen Anh Quynh <aq...@gm...>
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 16, 2014 at 9:51 PM, Peter Lucia <pe...@ro...>
>>> wrote:
>>>
>>>> Any thoughts on how hard it would be to implement?  Note that I'm only
>>>> trying to go to LLVM assembly code, not some other architecture's assembly
>>>> code.  Thanks
>>>>
>>>
>>> do you mean generating machine code from LLVM bitcode? this involves the
>>> backends of all related archs, and is quite different from what Capstone is
>>> doing. so extending Capstone to do this is not the choice, but you need to
>>> do that from scratch.
>>>
>>> to have a better idea, look at the source of llvm-dis. that is certainly
>>> a lot of works.
>>>
>>
>> i think i misunderstood your question: you actually want to disassemble
>> LLVM bitcode to LLVM assembly, right?
>>
>> then it is much easier than generating machine code from LLVM bitcode,
>> but again you should look at the source of llvm-dis.
>>
>>
>> cheers,
>> Q
>>
>>
>>>
>>>
>>>> Peter
>>>>
>>>> On Tue, Sep 16, 2014 at 8:24 AM, Nguyen Anh Quynh <aq...@gm...>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Is LLVM Bitcode itself a supported input architecture?  I have some
>>>>>> files that have not yet been fully compiled to PowerPC or MIPS, but instead
>>>>>> are still in LLVM Bitcode format (in other words, clang with the -
>>>>>> emit-llvm option) and I'd love to use capstone to disassemble them
>>>>>> pragmatically.
>>>>>>
>>>>>> If this is not already implemented, how hard would it be to do?  Is
>>>>>> there some other better way to do this?  I'm using llvm-dis now, but it's
>>>>>> not ideal for all the reasons capstone would seem to excel.
>>>>>>
>>>>>>
>>>>> unfortunately no. the main idea of Capstone is to disassemble machine
>>>>> binary code back to assembly code. so Capstone does not, and will never
>>>>> convert LLVM bitcode back to assembly for you.
>>>>>
>>>>>
>>>>> thanks.
>>>>> Q
>>>>>
>>>>
>>>>
>>>
>

Re: [Capstone-users] LLVM Bitcode as Input File

[Peter L. <pe...@ro...>]

Yes, I want disassemble LLVM bitcode to LLVM assembly.  Basically I want to
do exactly what llvm-dis does, but I'd like to have
the programmatic bindings that capstone provides; ie: get list of all the
instructions with each instruction object having it's opcode,
source registers, and destination registers broken out in nice
Python/Ruby/C#/Java/etc. objects.  Ideally, I'd like to use some of the
same tools already built (or that I build in the future) using capstone but
with LLVM bitcode files as source instead of *insert architecture here*
machine code files.  Sorry for not being clear at first.

I'll take a look at the llvm-dis source, the question really is how hard
will it be to integrate that source into capstone so we have API parity
with the other supported input machine languages.  Thanks for any further
thoughts you have now or in the future regarding this!

Peter

On Tue, Sep 16, 2014 at 10:10 AM, Nguyen Anh Quynh <aq...@gm...> wrote:

>
>
> On Tue, Sep 16, 2014 at 10:06 PM, Nguyen Anh Quynh <aq...@gm...>
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 9:51 PM, Peter Lucia <pe...@ro...> wrote:
>>
>>> Any thoughts on how hard it would be to implement?  Note that I'm only
>>> trying to go to LLVM assembly code, not some other architecture's assembly
>>> code.  Thanks
>>>
>>
>> do you mean generating machine code from LLVM bitcode? this involves the
>> backends of all related archs, and is quite different from what Capstone is
>> doing. so extending Capstone to do this is not the choice, but you need to
>> do that from scratch.
>>
>> to have a better idea, look at the source of llvm-dis. that is certainly
>> a lot of works.
>>
>
> i think i misunderstood your question: you actually want to disassemble
> LLVM bitcode to LLVM assembly, right?
>
> then it is much easier than generating machine code from LLVM bitcode, but
> again you should look at the source of llvm-dis.
>
>
> cheers,
> Q
>
>
>>
>>
>>> Peter
>>>
>>> On Tue, Sep 16, 2014 at 8:24 AM, Nguyen Anh Quynh <aq...@gm...>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Is LLVM Bitcode itself a supported input architecture?  I have some
>>>>> files that have not yet been fully compiled to PowerPC or MIPS, but instead
>>>>> are still in LLVM Bitcode format (in other words, clang with the -emit
>>>>> -llvm option) and I'd love to use capstone to disassemble them
>>>>> pragmatically.
>>>>>
>>>>> If this is not already implemented, how hard would it be to do?  Is
>>>>> there some other better way to do this?  I'm using llvm-dis now, but it's
>>>>> not ideal for all the reasons capstone would seem to excel.
>>>>>
>>>>>
>>>> unfortunately no. the main idea of Capstone is to disassemble machine
>>>> binary code back to assembly code. so Capstone does not, and will never
>>>> convert LLVM bitcode back to assembly for you.
>>>>
>>>>
>>>> thanks.
>>>> Q
>>>>
>>>
>>>
>>

Re: [Capstone-users] LLVM Bitcode as Input File

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

On Tue, Sep 16, 2014 at 10:06 PM, Nguyen Anh Quynh <aq...@gm...> wrote:

>
>
> On Tue, Sep 16, 2014 at 9:51 PM, Peter Lucia <pe...@ro...> wrote:
>
>> Any thoughts on how hard it would be to implement?  Note that I'm only
>> trying to go to LLVM assembly code, not some other architecture's assembly
>> code.  Thanks
>>
>
> do you mean generating machine code from LLVM bitcode? this involves the
> backends of all related archs, and is quite different from what Capstone is
> doing. so extending Capstone to do this is not the choice, but you need to
> do that from scratch.
>
> to have a better idea, look at the source of llvm-dis. that is certainly a
> lot of works.
>

i think i misunderstood your question: you actually want to disassemble
LLVM bitcode to LLVM assembly, right?

then it is much easier than generating machine code from LLVM bitcode, but
again you should look at the source of llvm-dis.


cheers,
Q


>
>
>> Peter
>>
>> On Tue, Sep 16, 2014 at 8:24 AM, Nguyen Anh Quynh <aq...@gm...>
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> Is LLVM Bitcode itself a supported input architecture?  I have some
>>>> files that have not yet been fully compiled to PowerPC or MIPS, but instead
>>>> are still in LLVM Bitcode format (in other words, clang with the -emit-
>>>> llvm option) and I'd love to use capstone to disassemble them
>>>> pragmatically.
>>>>
>>>> If this is not already implemented, how hard would it be to do?  Is
>>>> there some other better way to do this?  I'm using llvm-dis now, but it's
>>>> not ideal for all the reasons capstone would seem to excel.
>>>>
>>>>
>>> unfortunately no. the main idea of Capstone is to disassemble machine
>>> binary code back to assembly code. so Capstone does not, and will never
>>> convert LLVM bitcode back to assembly for you.
>>>
>>>
>>> thanks.
>>> Q
>>>
>>
>>
>

Re: [Capstone-users] LLVM Bitcode as Input File

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

On Tue, Sep 16, 2014 at 9:51 PM, Peter Lucia <pe...@ro...> wrote:

> Any thoughts on how hard it would be to implement?  Note that I'm only
> trying to go to LLVM assembly code, not some other architecture's assembly
> code.  Thanks
>

do you mean generating machine code from LLVM bitcode? this involves the
backends of all related archs, and is quite different from what Capstone is
doing. so extending Capstone to do this is not the choice, but you need to
do that from scratch.

to have a better idea, look at the source of llvm-dis. that is certainly a
lot of works.


cheers,
Q




> Peter
>
> On Tue, Sep 16, 2014 at 8:24 AM, Nguyen Anh Quynh <aq...@gm...>
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...> wrote:
>>
>>> Hello,
>>>
>>> Is LLVM Bitcode itself a supported input architecture?  I have some
>>> files that have not yet been fully compiled to PowerPC or MIPS, but instead
>>> are still in LLVM Bitcode format (in other words, clang with the -emit-
>>> llvm option) and I'd love to use capstone to disassemble them
>>> pragmatically.
>>>
>>> If this is not already implemented, how hard would it be to do?  Is
>>> there some other better way to do this?  I'm using llvm-dis now, but it's
>>> not ideal for all the reasons capstone would seem to excel.
>>>
>>>
>> unfortunately no. the main idea of Capstone is to disassemble machine
>> binary code back to assembly code. so Capstone does not, and will never
>> convert LLVM bitcode back to assembly for you.
>>
>>
>> thanks.
>> Q
>>
>
>

Re: [Capstone-users] LLVM Bitcode as Input File

[Peter L. <pe...@ro...>]

Any thoughts on how hard it would be to implement?  Note that I'm only
trying to go to LLVM assembly code, not some other architecture's assembly
code.  Thanks

Peter

On Tue, Sep 16, 2014 at 8:24 AM, Nguyen Anh Quynh <aq...@gm...> wrote:

>
>
> On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...> wrote:
>
>> Hello,
>>
>> Is LLVM Bitcode itself a supported input architecture?  I have some files
>> that have not yet been fully compiled to PowerPC or MIPS, but instead are
>> still in LLVM Bitcode format (in other words, clang with the -emit-llvm option)
>> and I'd love to use capstone to disassemble them pragmatically.
>>
>> If this is not already implemented, how hard would it be to do?  Is there
>> some other better way to do this?  I'm using llvm-dis now, but it's not
>> ideal for all the reasons capstone would seem to excel.
>>
>>
> unfortunately no. the main idea of Capstone is to disassemble machine
> binary code back to assembly code. so Capstone does not, and will never
> convert LLVM bitcode back to assembly for you.
>
>
> thanks.
> Q
>

Re: [Capstone-users] LLVM Bitcode as Input File

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

On Tue, Sep 16, 2014 at 6:20 AM, Peter Lucia <pe...@ro...> wrote:

> Hello,
>
> Is LLVM Bitcode itself a supported input architecture?  I have some files
> that have not yet been fully compiled to PowerPC or MIPS, but instead are
> still in LLVM Bitcode format (in other words, clang with the -emit-llvm option)
> and I'd love to use capstone to disassemble them pragmatically.
>
> If this is not already implemented, how hard would it be to do?  Is there
> some other better way to do this?  I'm using llvm-dis now, but it's not
> ideal for all the reasons capstone would seem to excel.
>
>
unfortunately no. the main idea of Capstone is to disassemble machine
binary code back to assembly code. so Capstone does not, and will never
convert LLVM bitcode back to assembly for you.


thanks.
Q

[Capstone-users] LLVM Bitcode as Input File

[Peter L. <pe...@ro...>]

Hello,

Is LLVM Bitcode itself a supported input architecture?  I have some files
that have not yet been fully compiled to PowerPC or MIPS, but instead are
still in LLVM Bitcode format (in other words, clang with the -emit-llvm option)
and I'd love to use capstone to disassemble them pragmatically.

If this is not already implemented, how hard would it be to do?  Is there
some other better way to do this?  I'm using llvm-dis now, but it's not
ideal for all the reasons capstone would seem to excel.

Thanks!

Peter

[Capstone-users] slides for Capstone presentation in BHUSA 2014

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

hi,

the BHUSA 2014 slides of Capstone disassembly framework is now available at
http://capstone-engine.org/BHUSA2014-capstone.pdf

let me know if you have any comments.

cheers,
Quynh

[Capstone-users] Blackhat USA 2014

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

hi,

i am now in Mandalay Bay hotel for BHUSA. wondering if anybody in this list
is here?

would be great to meet up you guys!

cheers,
Quynh

[Capstone-users] Announcement: CEnigma tool!

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

Greetings,

We are happy to announce a little web-based tool named CEnigma to
disassemble input hexcode! CEnigma offers some advantages:

- Fast, simple & easy to use: just paste your hexstring, choose
architecture/mode/syntax, then submit to receive back assembly code

- User-friendly: accept input of all kind of formats (as long as it
contains hexcode inside)

- Provide instruction details (just hover the mouse on instructions)

- Link to assembly manual (just click into instructions)

- Save output for future references (choose "duration" before submitting)

- Update to modern instructions on all 8 architectures supported: Arm,
Arm64, Mips, PPC, Sparc, SystemZ, XCore, X86 (+X86_64)


Find more at http://www.cenigma.org

Cheers,
Quynh

Re: [Capstone-users] Binary files parser

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

On Wed, Jul 23, 2014 at 5:20 PM, Moshe Kravchik <mkr...@ho...>
wrote:

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

yes, Capstone is designed to be simple and only does one work (and tries to
do that well): Capstone only (and will only) focus on disassembling binary
code. it is your job to get the code out yourself to feed that to Capstone.

on how to extract code from different binary formats, you can take a look
at ROPgadget (https://github.com/JonathanSalwan/ROPgadget): this tool also
has to take the code out of executable files to build ROP gadgets.

thanks,
Q

Re: [Capstone-users] Binary files parser

[David <li...@ed...>]

On 2014-07-23 10:20, Moshe Kravchik wrote:
> 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...

This page is a good place to start if you're using Python:

http://pythonarsenal.erpscan.com/

I'm not aware of any current tools/libraries that wrap it all into one 
like you're asking.

David