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: Derrick M. <der...@gm...> - 2019-07-30 12:46:01
|
I think I am mostly done with the C implementation, and have updated the
bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc files.
The existing files for ARM and x86 seem to contain the read/write
information for every instruction, sorted by enum name. They also say that
they were autogenerated, but I guess that isn't quite correct. I am
thinking that I can write a Python script that reads in a YAML file, and
outputs the properly sorted inc file containing all the information
(including comments) currently in existing InsnOp.inc files. The YAML file
will have a structure like the following:
output: "MipsMappingInsnOp.inc"
Insns:
- enum: MIPS_INS_ADD
example: "add $d, $t, $s"
operands:
- read: No
write: Yes
- read: Yes
write: No
- read: Yes
write: No
Thoughts?
On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...> wrote:
> Those .inc files involved a lot of manual work, that is why it takes time.
>
> What is your progress?
>
> Cheers.
>
> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...> wrote:
>
>> Hi,
>>
>> I am beginning to add support for regs_access for MIPS and PPC.
>> Currently, I am following what has been done for ARM and x86, which as far
>> as I can tell for PPC involves adding a new access member to the
>> cs_ppc_op struct, writing a new PPC_regs_access function, and setting
>> the regs_access function pointer in cs_struct in PPC_global_init. My
>> question is how is the access member set? For both ARM and x86, there is a
>> MappingInsnOp.inc file that appears to be autogenerated, which contains the
>> access information. How was this file generated?
>>
>> --
>> Derrick McKee
>> Phone: (703) 957-9362
>> Email: der...@gm...
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>
--
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...
|
|
From: Nguyen A. Q. <aq...@gm...> - 2019-07-30 05:24:13
|
Those .inc files involved a lot of manual work, that is why it takes time. What is your progress? Cheers. On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...> wrote: > Hi, > > I am beginning to add support for regs_access for MIPS and PPC. > Currently, I am following what has been done for ARM and x86, which as far > as I can tell for PPC involves adding a new access member to the cs_ppc_op > struct, writing a new PPC_regs_access function, and setting the > regs_access function pointer in cs_struct in PPC_global_init. My > question is how is the access member set? For both ARM and x86, there is a > MappingInsnOp.inc file that appears to be autogenerated, which contains the > access information. How was this file generated? > > -- > Derrick McKee > Phone: (703) 957-9362 > Email: der...@gm... > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > |
|
From: Derrick M. <der...@gm...> - 2019-07-29 15:46:47
|
Hi, I am beginning to add support for regs_access for MIPS and PPC. Currently, I am following what has been done for ARM and x86, which as far as I can tell for PPC involves adding a new access member to the cs_ppc_op struct, writing a new PPC_regs_access function, and setting the regs_access function pointer in cs_struct in PPC_global_init. My question is how is the access member set? For both ARM and x86, there is a MappingInsnOp.inc file that appears to be autogenerated, which contains the access information. How was this file generated? -- Derrick McKee Phone: (703) 957-9362 Email: der...@gm... |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-06-06 02:57:47
|
hi,
as i said, you should use the "next" branch, not "master", because "next"
now supports all the latest instructions of X86, Arm & Arm64.
try with our "cstool" on the input you provided:
$ cstool x64att "0x62, 0xd2, 0xf5, 0x78, 0xb8, 0xd1"
0 62 d2 f5 78 b8 d1 vfmadd231pd {rz-sae}, %zmm9, %zmm1, %zmm2
let me know if you need more help.
Thanks,
Quynh
On Thu, Jun 6, 2019 at 5:21 AM Xiaozhu Meng <mx...@gm...> wrote:
> Hi Quynh,
>
> Thanks for your reply!
>
> I have 8 AVX instructions that are currently missing in Dyninst. I tried
> Capstone’s master branch and it correctly decodes 7 of the 8. For the
> remaining one, I would like double check with you whether the test itself
> is correct.
>
> The bytes are "0x62, 0xd2, 0xf5, 0x78, 0xb8, 0xd1”. I am using the test1
> example from the capstone c tutorial and it prints ""ERROR: Failed to
> disassemble given code!” for this one. Objdump says these bytes is "vfmadd231pd
> {rz-sae},%zmm9,%zmm1,%zmm2”.
>
> I have to admit that this is something we collected about two years ago,
> and I cannot confirm from which binary I got them. So, I am not sure that
> whether my recorded test is actually correct or not. In general, it looks
> very promising for integrating capstone with Dyninst. I will send followup
> emails if I need further help.
>
> Thanks,
>
> —Xiaozhu
>
>
>
>
> On Jun 3, 2019, at 9:57 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
> hi,
>
> On Mon, Jun 3, 2019 at 11:15 PM Xiaozhu Meng <mx...@gm...> wrote:
>
>> Hi,
>>
>> I am a developer from the Dyninst project (
>> https://github.com/dyninst/dyninst). For a long time, Dyninst has its
>> own instruction decoder. However, we have been falling behind on
>> instruction decoding in recent years, due to our focuses on binary analysis
>> and instrumentation. We are considering integrating with external
>> instruction decoder to better support our binary analysis and
>> instrumentation functionality. Dyninst's main target architectures are x86,
>> Power, and ARM.
>>
>
> yes, i understand the pain of maintaining/developing a subproject which is
> as complicated as disassembler.
> using a third party instead is a smart approach, IMO.
>
>
>>
>> Capstone is a good candidate we are considering because it covers the
>> three main architectures we are supporting and provides thread-safe
>> instruction decoding (Dyninst's parallel binary analysis needs thread-safe
>> instruction decoder).
>>
>> I have a couple of specific questions on this topic:
>>
>> (1) Dyninst's own instruction decoder mainly failed on vector
>> instructions, especially on AMD extensions such as XOP and FMA4 and ARM's
>> SVE. We recently improved our decoder for Power vector instructions, but
>> there are still many missing ones. How is capstone's current status for
>> those different vector instructions?
>>
>
> check it out our "next" branch at
> https://github.com/aquynh/capstone/tree/next
> in this branch, we support the latest instructions sets for X86, Arm &
> AArch64.
> as far as i know, we do not miss anything.
>
>
>
>> (2) Dyninst will need to translate Capstone's instruction decoding
>> results from Capstone instruction representation to Dyninst instruction
>> representation. We will need instruction length (how many bytes),
>> instruction opcode, operands (both explicit and implicit operands), and
>> operands types (such as IMM, mem, or register), and the addressing mode for
>> constructing our AST representation for effective address. I believe
>> Capstone provides all the information we need, but would like to confirm
>> whether it is indeed the case.
>>
>
> yes, we can confirm that we provide these information for X86, Arm & Arm64.
>
>
>> (3) I am aware that Capstone is thread-safe, which is great and necessary
>> for us. I would like to ask whether there are going to any scalability
>> concerns as we run Dyninst's parallel binary analysis on dozens to hundreds
>> cores.
>>
>>
> yes, Capstone is thread-safe by design.
>
> let me know if you need any helps integrating with Dyninst.
>
>
> Thanks,
> Quynh
>
> http://www.keystone-engine.org
> http://www.capstone-engine.org
> http://www.unicorn-engine.org
>
>
>
>
>
>> I am looking forward to hearing from you folks.
>>
>> Thanks,
>>
>> --Xiaozhu
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
>
>
|
|
From: Xiaozhu M. <mx...@gm...> - 2019-06-05 21:21:20
|
Hi Quynh,
Thanks for your reply!
I have 8 AVX instructions that are currently missing in Dyninst. I tried Capstone’s master branch and it correctly decodes 7 of the 8. For the remaining one, I would like double check with you whether the test itself is correct.
The bytes are "0x62, 0xd2, 0xf5, 0x78, 0xb8, 0xd1”. I am using the test1 example from the capstone c tutorial and it prints ""ERROR: Failed to disassemble given code!” for this one. Objdump says these bytes is "vfmadd231pd {rz-sae},%zmm9,%zmm1,%zmm2”.
I have to admit that this is something we collected about two years ago, and I cannot confirm from which binary I got them. So, I am not sure that whether my recorded test is actually correct or not. In general, it looks very promising for integrating capstone with Dyninst. I will send followup emails if I need further help.
Thanks,
—Xiaozhu
> On Jun 3, 2019, at 9:57 PM, Nguyen Anh Quynh <aq...@gm...> wrote:
>
> hi,
>
> On Mon, Jun 3, 2019 at 11:15 PM Xiaozhu Meng <mx...@gm... <mailto:mx...@gm...>> wrote:
> Hi,
>
> I am a developer from the Dyninst project (https://github.com/dyninst/dyninst <https://github.com/dyninst/dyninst>). For a long time, Dyninst has its own instruction decoder. However, we have been falling behind on instruction decoding in recent years, due to our focuses on binary analysis and instrumentation. We are considering integrating with external instruction decoder to better support our binary analysis and instrumentation functionality. Dyninst's main target architectures are x86, Power, and ARM.
>
> yes, i understand the pain of maintaining/developing a subproject which is as complicated as disassembler.
> using a third party instead is a smart approach, IMO.
>
>
> Capstone is a good candidate we are considering because it covers the three main architectures we are supporting and provides thread-safe instruction decoding (Dyninst's parallel binary analysis needs thread-safe instruction decoder).
>
> I have a couple of specific questions on this topic:
>
> (1) Dyninst's own instruction decoder mainly failed on vector instructions, especially on AMD extensions such as XOP and FMA4 and ARM's SVE. We recently improved our decoder for Power vector instructions, but there are still many missing ones. How is capstone's current status for those different vector instructions?
>
> check it out our "next" branch at https://github.com/aquynh/capstone/tree/next <https://github.com/aquynh/capstone/tree/next>
> in this branch, we support the latest instructions sets for X86, Arm & AArch64.
> as far as i know, we do not miss anything.
>
>
>
> (2) Dyninst will need to translate Capstone's instruction decoding results from Capstone instruction representation to Dyninst instruction representation. We will need instruction length (how many bytes), instruction opcode, operands (both explicit and implicit operands), and operands types (such as IMM, mem, or register), and the addressing mode for constructing our AST representation for effective address. I believe Capstone provides all the information we need, but would like to confirm whether it is indeed the case.
>
> yes, we can confirm that we provide these information for X86, Arm & Arm64.
>
>
> (3) I am aware that Capstone is thread-safe, which is great and necessary for us. I would like to ask whether there are going to any scalability concerns as we run Dyninst's parallel binary analysis on dozens to hundreds cores.
>
>
> yes, Capstone is thread-safe by design.
>
> let me know if you need any helps integrating with Dyninst.
>
>
> Thanks,
> Quynh
>
> http://www.keystone-engine.org <http://www.keystone-engine.org/>
> http://www.capstone-engine.org <http://www.capstone-engine.org/>
> http://www.unicorn-engine.org <http://www.unicorn-engine.org/>
>
>
>
>
> I am looking forward to hearing from you folks.
>
> Thanks,
>
> --Xiaozhu
> _______________________________________________
> Capstone-users mailing list
> Cap...@li... <mailto:Cap...@li...>
> https://lists.sourceforge.net/lists/listinfo/capstone-users <https://lists.sourceforge.net/lists/listinfo/capstone-users>
|
|
From: Nguyen A. Q. <aq...@gm...> - 2019-06-04 02:58:10
|
hi, On Mon, Jun 3, 2019 at 11:15 PM Xiaozhu Meng <mx...@gm...> wrote: > Hi, > > I am a developer from the Dyninst project ( > https://github.com/dyninst/dyninst). For a long time, Dyninst has its own > instruction decoder. However, we have been falling behind on instruction > decoding in recent years, due to our focuses on binary analysis and > instrumentation. We are considering integrating with external instruction > decoder to better support our binary analysis and instrumentation > functionality. Dyninst's main target architectures are x86, Power, and ARM. > yes, i understand the pain of maintaining/developing a subproject which is as complicated as disassembler. using a third party instead is a smart approach, IMO. > > Capstone is a good candidate we are considering because it covers the > three main architectures we are supporting and provides thread-safe > instruction decoding (Dyninst's parallel binary analysis needs thread-safe > instruction decoder). > > I have a couple of specific questions on this topic: > > (1) Dyninst's own instruction decoder mainly failed on vector > instructions, especially on AMD extensions such as XOP and FMA4 and ARM's > SVE. We recently improved our decoder for Power vector instructions, but > there are still many missing ones. How is capstone's current status for > those different vector instructions? > check it out our "next" branch at https://github.com/aquynh/capstone/tree/next in this branch, we support the latest instructions sets for X86, Arm & AArch64. as far as i know, we do not miss anything. > (2) Dyninst will need to translate Capstone's instruction decoding results > from Capstone instruction representation to Dyninst instruction > representation. We will need instruction length (how many bytes), > instruction opcode, operands (both explicit and implicit operands), and > operands types (such as IMM, mem, or register), and the addressing mode for > constructing our AST representation for effective address. I believe > Capstone provides all the information we need, but would like to confirm > whether it is indeed the case. > yes, we can confirm that we provide these information for X86, Arm & Arm64. > (3) I am aware that Capstone is thread-safe, which is great and necessary > for us. I would like to ask whether there are going to any scalability > concerns as we run Dyninst's parallel binary analysis on dozens to hundreds > cores. > > yes, Capstone is thread-safe by design. let me know if you need any helps integrating with Dyninst. Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org > I am looking forward to hearing from you folks. > > Thanks, > > --Xiaozhu > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > |
|
From: Xiaozhu M. <mx...@gm...> - 2019-06-03 15:15:29
|
Hi, I am a developer from the Dyninst project ( https://github.com/dyninst/dyninst). For a long time, Dyninst has its own instruction decoder. However, we have been falling behind on instruction decoding in recent years, due to our focuses on binary analysis and instrumentation. We are considering integrating with external instruction decoder to better support our binary analysis and instrumentation functionality. Dyninst's main target architectures are x86, Power, and ARM. Capstone is a good candidate we are considering because it covers the three main architectures we are supporting and provides thread-safe instruction decoding (Dyninst's parallel binary analysis needs thread-safe instruction decoder). I have a couple of specific questions on this topic: (1) Dyninst's own instruction decoder mainly failed on vector instructions, especially on AMD extensions such as XOP and FMA4 and ARM's SVE. We recently improved our decoder for Power vector instructions, but there are still many missing ones. How is capstone's current status for those different vector instructions? (2) Dyninst will need to translate Capstone's instruction decoding results from Capstone instruction representation to Dyninst instruction representation. We will need instruction length (how many bytes), instruction opcode, operands (both explicit and implicit operands), and operands types (such as IMM, mem, or register), and the addressing mode for constructing our AST representation for effective address. I believe Capstone provides all the information we need, but would like to confirm whether it is indeed the case. (3) I am aware that Capstone is thread-safe, which is great and necessary for us. I would like to ask whether there are going to any scalability concerns as we run Dyninst's parallel binary analysis on dozens to hundreds cores. I am looking forward to hearing from you folks. Thanks, --Xiaozhu |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-05-08 07:32:02
|
Hi, Just want to share with you some good news: Capstone disassembler just received an important update for PowerPC architectures. Many issues have been fixed, and more instructions are handled now. Check it out our "next" branch: https://github.com/aquynh/capstone/tree/next Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-04-10 10:06:44
|
Hi, Good news: Capstone just received a huge update for AArch64, so that now we can handle latest instructions from v8.2 ~ v8.4a specs! Check it out from our Github "next" branch. https://github.com/aquynh/capstone/tree/next On the other hand, soon we are going to release the maintenance version 4.0.2, which fixes some important issues. Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-03-16 10:19:12
|
Hi, Good news for Sunday: Capstone just received a huge update on ARM, so that now we can handle latest instructions from v8.1a ~ v8.4a specs! Check it out from our Github "next" branch. https://github.com/aquynh/capstone/commits/next Thanks, Quynh |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-03-09 01:09:17
|
Capstone disassembler just received its 17th architecture in #RISCV!
Big thanks to porto703, @citypw, @fanfuqiang & @hardenedlinux for this
amazing work!
Check it out in our "next" branch:
https://github.com/aquynh/capstone/tree/next
Thanks,
Quynh
http://www.keystone-engine.org
http://www.capstone-engine.org
http://www.unicorn-engine.org
|
|
From: Nguyen A. Q. <aq...@gm...> - 2019-03-03 09:56:24
|
On Sun, Mar 3, 2019, 03:36 Phil Moore <pwm...@gm...> wrote: > Hiya, > > I saw in the latest message from yesterday you were planning on > working on updating ARM64 for Capstone; does this include ARMv8.3 and > the new Pointer Authentication instructions? Yes, that should include all the latest extensions. I have been thinking > about trying to add support for those myself, and if you are planning > on adding that support I would be happy to help out in any way I can. > Or if you weren't planning on adding those, I could go ahead and give > it a try. > How do you want to help? Cheers. > -- > Phillip Moore > > > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > |
|
From: Phil M. <pwm...@gm...> - 2019-03-02 19:36:47
|
Hiya, I saw in the latest message from yesterday you were planning on working on updating ARM64 for Capstone; does this include ARMv8.3 and the new Pointer Authentication instructions? I have been thinking about trying to add support for those myself, and if you are planning on adding that support I would be happy to help out in any way I can. Or if you weren't planning on adding those, I could go ahead and give it a try. -- Phillip Moore |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-03-01 10:16:22
|
Hi, Just want to share a good news: Capstone just received a major update for X86, so we can now handle the latest Intel CPU extensions! Together with various bugfixes, X86 core is also faster than before. Check it out in the "next" branch: https://github.com/aquynh/capstone/tree/next Next, I am working to update ARM & ARM64. At the same time, Capstone just got the 16th architecture in BPF, which is also available in the "next" branch. Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-02-01 16:31:42
|
hi, a good news: we just added WebAssembly support to Capstone, which came in a new architecture CS_ARCH_WASM. currently this is only available in the "next" branch, which will be released as v5.0 when it is ready. https://github.com/aquynh/capstone/tree/next please report if you find any bugs, thanks. Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Nguyen A. Q. <aq...@gm...> - 2019-01-10 14:40:43
|
Greetings, We are happy to announce version 4.0.1 of Capstone disassembler framework! This release fixes some bugs of v4.0, and introduces some improvements for the Python binding. We encourage all users of v4.0 to upgrade. In no particular order, we would like to thank NowSecure <https://www.nowsecure.com/>, Verichains <https://verichains.io>& Vsec <https://vsec.com.vn/en/>for sponsoring this release! We also wish to express our sincere gratitude to all contributors & donators, who generously supported us to maintain Capstone project! More details are available at http://www.capstone-engine.org/Version-4.0.1 (For those who do not know, Capstone is an open source multi-arch, multi-platform disassembly engine, with homepage at http://capstone-engine.org). Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Nguyen A. Q. <aq...@gm...> - 2018-12-18 17:12:17
|
Greetings, We are super excited to announce version 4.0 of Capstone disassembler framework! Exactly 5 years ago, on December 18th of 2013, we published the first version. Today, this release 4.0 marks 5 years of our project! Such a long journey, which is impossible without huge community support! In no particular order, we would like to thank Thinkst Canary <https://canary.tools/>, NowSecure <https://www.nowsecure.com/>, ECQ <https://e-cq.net/>, Senrio <https://senr.io/>, GracefulBits <https://gracefulbits.com/> & Catena Cyber <https://catenacyber.fr/> for sponsoring this release! We also wish to express our sincere gratitude to all contributors & donators, who generously supported us to maintain Capstone project! More details are available at http://capstone-engine.org/Version-4 <http://capstone-engine.org/Version-4.0> (For those who do not know, Capstone is an open source multi-arch, multi-platform disassembly engine, with homepage at http://capstone-engine.org) Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org |
|
From: Özgür D. O. <ozg...@gm...> - 2018-12-04 14:57:41
|
Hi,
I have faced with a problem while trying to disassemble a file, Capstone
disassembling stops when there is a bad opcode. I shared the code, Capstone
and objdump outputs below, and I'll appreciate if there is any workaround
for this case.
Kind Regards,
Ozgur
The code is as shown below.
from capstone import *
md = Cs(CS_ARCH_X86, CS_MODE_64)
eop = 0x200
data = pe.get_memory_mapped_image()[eop:]
for i in md.disasm(data, 0x1000):
print("0x%x:\t%s\t%s" %(i.address, i.mnemonic, i.op_str))
The output is:
0x1000: pop r10
0x1002: push rax
0x1003: add byte ptr [rdx], al
0x1005: add byte ptr [rax], al
0x1007: add byte ptr [rax + rax], al
However, the objdump output is:
"\x4d\x5a" \\rex.WRB pop r10
"\x50" \\push rax
"\x00\x02" \\add BYTE PTR [rdx],al
"\x00\x00" \\add BYTE PTR [rax],al
"\x00\x04\x00" \\add BYTE PTR [rax+rax*1],al
"\x0f\x00" \\(bad)
"\xff" \\(bad)
"\xff\x00" \\inc DWORD PTR [rax]
...
|
|
From: Riccardo S. <si...@gm...> - 2018-11-19 16:12:38
|
Hi Quynh, any news on this? On Mon, Nov 12, 2018 at 1:45 PM Riccardo Schirone <si...@gm...> wrote: > > Sorry for being insistent, but could you detail a bit more your "soon"? There was already an "ASAP" in the referenced issue in my first email and also a supposed "TODO list" for the release, but months have passed. So, again, sorry for keep asking but I think users and package maintainer needs to know what's the status of the project. > > It is also perfectly fine if you don't have time, just be clear about it please. > > As co-maintainer of capstone in Fedora I need to know if/when I can expect capstone updates, because I want to plan what to do with Fedora 30 (which will be released in about 6 months from now, but we need to be ready before that because other packages depend on capstone). Also, as maintainer of radare2 I need to know how to deal with capstone dependency, because depending on the system provided capstone (v3.0.5) is not a solution right now as it's not capable of handling even the simple binaries like /bin/ls on x86_64. As it is right now, users already have to depend on a very old capstone version until Fedora 30 will be released, which is a pity. I guess other distributions have the same problems. > > I'll be waiting for a more detailed answer. > Thanks for your replies and for your time. > > On Mon, Nov 12, 2018 at 12:47 PM Nguyen Anh Quynh <aq...@gm...> wrote: >> >> i will announce the plan soon. >> >> Thanks, >> Quynh >> >> http://www.keystone-engine.org >> http://www.capstone-engine.org >> http://www.unicorn-engine.org >> >> >> >> >> On Mon, Nov 12, 2018 at 6:31 PM Riccardo Schirone <si...@gm...> wrote: >>> >>> Hi, >>> What is the plan around v4 release? There has been some movements in July on https://github.com/aquynh/capstone/issues/1096 , but things got stuck again I guess, since v4 wasn't released yet. >>> >>> Distributions are still using capstone v3.0.5 which is very old. For example, on Fedora we cannot even analyze the binary shipped with the distribution like /bin/ls, because of Indirect Branch Tracking instructions. This is just one of the many things that v3.0.5 misses. >>> >>> At https://github.com/aquynh/capstone/issues/1096#issuecomment-380179605 it says a TODO list will be put online for v4 release. Where is it? >>> >>> What's the status for v4? Expected release date? What are the blocking issues to make this happen? How can the community help with it? Please make us aware of what's going on, because multiple projects depend on capstone. >>> >>> Thanks, >>> >>> Riccardo >>> >>> _______________________________________________ >>> Capstone-users mailing list >>> Cap...@li... >>> https://lists.sourceforge.net/lists/listinfo/capstone-users >> >> _______________________________________________ >> Capstone-users mailing list >> Cap...@li... >> https://lists.sourceforge.net/lists/listinfo/capstone-users |
|
From: Riccardo S. <si...@gm...> - 2018-11-12 12:45:46
|
Sorry for being insistent, but could you detail a bit more your "soon"? There was already an "ASAP" in the referenced issue in my first email and also a supposed "TODO list" for the release, but months have passed. So, again, sorry for keep asking but I think users and package maintainer needs to know what's the status of the project. It is also perfectly fine if you don't have time, just be clear about it please. As co-maintainer of capstone in Fedora I need to know if/when I can expect capstone updates, because I want to plan what to do with Fedora 30 (which will be released in about 6 months from now, but we need to be ready before that because other packages depend on capstone). Also, as maintainer of radare2 I need to know how to deal with capstone dependency, because depending on the system provided capstone (v3.0.5) is not a solution right now as it's not capable of handling even the simple binaries like /bin/ls on x86_64. As it is right now, users already have to depend on a very old capstone version until Fedora 30 will be released, which is a pity. I guess other distributions have the same problems. I'll be waiting for a more detailed answer. Thanks for your replies and for your time. On Mon, Nov 12, 2018 at 12:47 PM Nguyen Anh Quynh <aq...@gm...> wrote: > i will announce the plan soon. > > Thanks, > Quynh > > http://www.keystone-engine.org > http://www.capstone-engine.org > http://www.unicorn-engine.org > > > > > On Mon, Nov 12, 2018 at 6:31 PM Riccardo Schirone <si...@gm...> > wrote: > >> Hi, >> What is the plan around v4 release? There has been some movements in July >> on https://github.com/aquynh/capstone/issues/1096 , but things got stuck >> again I guess, since v4 wasn't released yet. >> >> Distributions are still using capstone v3.0.5 which is very old. For >> example, on Fedora we cannot even analyze the binary shipped with the >> distribution like /bin/ls, because of Indirect Branch Tracking >> instructions. This is just one of the many things that v3.0.5 misses. >> >> At https://github.com/aquynh/capstone/issues/1096#issuecomment-380179605 >> it says a TODO list will be put online for v4 release. Where is it? >> >> What's the status for v4? Expected release date? What are the blocking >> issues to make this happen? How can the community help with it? Please make >> us aware of what's going on, because multiple projects depend on capstone. >> >> Thanks, >> >> Riccardo >> > _______________________________________________ >> Capstone-users mailing list >> Cap...@li... >> https://lists.sourceforge.net/lists/listinfo/capstone-users >> > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > |
|
From: Nguyen A. Q. <aq...@gm...> - 2018-11-12 11:46:51
|
i will announce the plan soon. Thanks, Quynh http://www.keystone-engine.org http://www.capstone-engine.org http://www.unicorn-engine.org On Mon, Nov 12, 2018 at 6:31 PM Riccardo Schirone <si...@gm...> wrote: > Hi, > What is the plan around v4 release? There has been some movements in July > on https://github.com/aquynh/capstone/issues/1096 , but things got stuck > again I guess, since v4 wasn't released yet. > > Distributions are still using capstone v3.0.5 which is very old. For > example, on Fedora we cannot even analyze the binary shipped with the > distribution like /bin/ls, because of Indirect Branch Tracking > instructions. This is just one of the many things that v3.0.5 misses. > > At https://github.com/aquynh/capstone/issues/1096#issuecomment-380179605 > it says a TODO list will be put online for v4 release. Where is it? > > What's the status for v4? Expected release date? What are the blocking > issues to make this happen? How can the community help with it? Please make > us aware of what's going on, because multiple projects depend on capstone. > > Thanks, > > Riccardo > _______________________________________________ > Capstone-users mailing list > Cap...@li... > https://lists.sourceforge.net/lists/listinfo/capstone-users > |
|
From: Riccardo S. <si...@gm...> - 2018-11-12 10:30:35
|
Hi, What is the plan around v4 release? There has been some movements in July on https://github.com/aquynh/capstone/issues/1096 , but things got stuck again I guess, since v4 wasn't released yet. Distributions are still using capstone v3.0.5 which is very old. For example, on Fedora we cannot even analyze the binary shipped with the distribution like /bin/ls, because of Indirect Branch Tracking instructions. This is just one of the many things that v3.0.5 misses. At https://github.com/aquynh/capstone/issues/1096#issuecomment-380179605 it says a TODO list will be put online for v4 release. Where is it? What's the status for v4? Expected release date? What are the blocking issues to make this happen? How can the community help with it? Please make us aware of what's going on, because multiple projects depend on capstone. Thanks, Riccardo |
|
From: Prasad D. <pd...@ic...> - 2018-11-07 02:49:44
|
Thanks for the response. I am using latest version (3.0.5?) available on the web site. Attached is the code (capstone.c) that I am using from a kernel driver. I am building capstone_static_winkernel.lib with CAPSTONE_X86_REDUCE defined and then using it from my kernel driver. In this configuration, when I am disassembling the function that contains "lea r15, [someaddress]" instruction, it stops disassembling at this instruction. e.g. If the function that I am disassembling has 100 instructions and 25th instruction is "lea r15, [someaddress]", cs_diasm returns me 24 as the instruction count. If I use static library capstone_static_winkernel.lib compiled with CAPSTONE_X86_REDUCE_NO, it disassembles fine. Let me know if you need any more information. Thanks. -Prasad On Nov 06, 2018, at 05:51 PM, Nguyen Anh Quynh <aq...@gm...> wrote: which Capstone version are you using? please post a minimal code to reproduce this issue, so i can debug it. thanks. |
|
From: Nguyen A. Q. <aq...@gm...> - 2018-11-07 01:51:53
|
which Capstone version are you using? please post a minimal code to reproduce this issue, so i can debug it. thanks. |
|
From: Prasad D. <pd...@ic...> - 2018-11-06 09:47:29
|
Hello, I am using capstone library compiled with CAPSTONE_X86_REDUCE for doing a disassembly on a function. It prematurely stops in the middle of function at the following instruction. lea r15, [someaddress] The web page at https://www.capstone-engine.org/x86reduce.html lists the instructions that are removed in CAPSTONE_X86_REDUCE mode. However, my instruction doesn't belong to the list. Any advice? Thanks. -Prasad |
