jz vs je about capstone HOT 22 CLOSED

On Thu, Dec 12, 2013 at 8:29 AM, radare [email protected] wrote:

capstone disassembles 74/75 opcode as 'je/jne' while other disassemblers
use 'jz/jnz'. In fact, both mnemonics are assembled as the same
instruction, so that's just an aesthetical issue.

I personally prefer the 'jz/jnz' form, should we change this? What's your
preference?

no difference, it is all the same to me. we might put this as one option
like CS_OPT* next version?

thanks,
Q

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/36
.

from capstone.

Yep. if that’s not making the code much more complex that can be an option.

On 12 Dec 2013, at 02:19, Nguyen Anh Quynh [email protected] wrote:

no difference, it is all the same to me. we might put this as one option
like CS_OPT* next version?

from capstone.

In that case you should also take a look at the following jump mnemonics (this is taken from BeaEngine Update:

enum BRANCH_TYPE
{
    //JO vs JNO
    JO = 1,
    JNO = -1,
    //JC=JB=JNAE vs JNC=JNB=JAE
    JC = 2,
    JB = 2,
    JNAE = 2,
    JNC = -2,
    JNB = -2,
    JAE = -2,
    //JE=JZ vs JNE=JNZ
    JE = 3,
    JZ = 3,
    JNE = -3,
    JNZ = -3,
    //JA=JNBE vs JNA=JBE
    JA = 4,
    JNBE = 4,
    JNA = -4,
    JBE = -4,
    //JP=JPE vs JNP=JPO
    JP = 6,
    JPE = 6,
    JNP = -6,
    JPO = -6,
    //JL=JNGE vs JNL=JGE
    JL = 7,
    JNGE = 7,
    JNL = -7,
    JGE = -7,
    //JG=JNLE vs JNG=JLE
    JG = 8,
    JNLE = 8,
    JNG = -8,
    JLE = -8,
};

from capstone.

How would this be implemented?
An option per instruction, or one option to toggle all instructions to alternate names?
And how to handle the case of one instruction with 3 alternate names?

from capstone.

this can be done via the cs_option() API.

the idea is to define a new option (like CS_OPT_INSN_NAME), then let user pass the instruction ID & instruction name to it. then at run time, the printer will use this name for the corresponding instruction ID.

the implementation should not be too complicated.

from capstone.

Keep in mind that there should be like 10 options then, jz vs je is not the
only thing.
On 23 Apr 2015 15:30, "Nguyen Anh Quynh" [email protected] wrote:

this can be done via cs_option API.

the idea is to define a new option (like CS_OPT_INSN_NAME), then let
user pass the instruction ID & instruction name to it. then at run
time, the printer will use this name for the corresponding instruction.

the implementation should not be too complicated.

Reply to this email directly or view it on GitHub
#36 (comment).

from capstone.

surely yes, but then we run cs_option() 10 times, one for each of these instructions.

from capstone.

True, or maybe use a bit field?
On 23 Apr 2015 17:35, "Nguyen Anh Quynh" [email protected] wrote:

surely yes, but then we run cs_option() 10 times, one for each of these
instructions.

Reply to this email directly or view it on GitHub
#36 (comment).

from capstone.

Why? This is at the setup stage, so i dont see any issue calling this API even hundreds times. That does not affect performance or anything, so lets keep it simple.

from capstone.

Okay :)
On 23 Apr 2015 17:47, "Nguyen Anh Quynh" [email protected] wrote:

Why? This is at the setup stage, so i dont see any issue calling this API
even hundreds times. That does not affect performance or anything, so lets
keep it simple.

Reply to this email directly or view it on GitHub
#36 (comment).

from capstone.

yeah, my idea was to pass a struct that has the id & name the user wants for it then.
capstone will alloc it's own private copy of the struct, not sure where to store it yet, but ill find a nice place.

from capstone.

you can look at how the option CS_OPT_SKIPDATA_SETUP was implemented.

for keeping data, that should be inside the struct cs_struct (see file cs_priv.h).

thanks.

from capstone.

I was thinking of storing it somewhere in the internal lookup tables,
but that would mean it would have to be done for all arches separately.

In case that it's stored in the cs_struct, it would mean that when a few are selected, they would have to be iterated trough for each instruction.

from capstone.

lets consider this case: you create 2 engines (of X86), and each engine has different setups.
so cs_struct is the only place to keep them independent.

from capstone.

to replace the original mnemonic with the one you want, a good place is to do that in fill_insn() function in cs.c. this code works for all archs, so you do not need to do that separately.

from capstone.

so i implemented a new option CS_OPT_MNEMONIC to customize instruction mnemonic at run-time. this should support all 8 architectures Capstone has at the moment.

this code is now available in the mnem branch at https://github.com/aquynh/capstone/tree/mnem.

you can find how to use this option in the new test code test_customized_mnem.c at https://github.com/aquynh/capstone/blob/mnem/tests/test_customized_mnem.c.

below is the output of test_customized_mnem, which is intuitive & self explanatory.

Disassemble X86 code with default instruction mnemonic
75 01       jne 0x1003

Now customize engine to change mnemonic from 'JNE' to 'JNZ'
75 01       jnz 0x1003

Reset engine to use the default mnemonic
75 01       jne 0x1003

of course you should be able to run cs_option(CS_OPT_MNEMONIC) as many times as you want - so there is no limitation on the number of instructions you can customize.

let me know if you guys have any comment, thanks.

from capstone.

awesome solution! I think you can mark this issue as resolved 👍

from capstone.

thanks. lets see if there are more comments before this is merged into the "next".

@mrexodia btw, can you answer my question on the issue #335? how did you create ".a" file for MingW?

from capstone.

Awesome! Will test it asap. I was also missing the jz namings..

On 26 Apr 2015, at 17:02, Nguyen Anh Quynh [email protected] wrote:

so i implemented a new option CS_OPT_MNEMONIC to customize instruction mnemonic at run-time. this should support all 8 architectures Capstone has at the moment.

this code is now available in the mnem branch at https://github.com/aquynh/capstone/tree/mnem.

you can find how to use this option in the new test code test_customized_mnem.c at https://github.com/aquynh/capstone/blob/mnem/tests/test_customized_mnem.c.

below is the output of test_customized_mnem, which is intuitive & self explanatory.

Disassemble X86 code with default instruction mnemonic
75 01 jne 0x1003

Now customize engine to change mnemonic from 'JNE' to 'JNZ'
75 01 jnz 0x1003

Reset engine to use the default mnemonic
75 01 jne 0x1003
of course you should be able to run cs_option(CS_OPT_MNEMONIC) as many times as you want - so there is no limit on how many instructions you can customize.

let me know if you guys have any comment, thanks.

—
Reply to this email directly or view it on GitHub.

from capstone.

i merged this "mnem" branch into the "next" branch.

Python binding support for new option CS_OPT_MNEMONIC is now ready: see sample code https://github.com/aquynh/capstone/blob/next/bindings/python/test_customized_mnem.py.

the "mnem" branch will be deleted.

from capstone.

some docs for this new option: http://capstone-engine.org/mnemonic.html

from capstone.

can you guys please join this related discussion: #342 ?

thanks.

from capstone.