Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[python, x86] Mismatch between operand type and type constant #2274

Open
cristianassaiante opened this issue Feb 15, 2024 · 2 comments
Open
Labels
Milestone

Comments

@cristianassaiante
Copy link

Hi,

I just found out that starting from version 5.0.1, the value of CS_OP_MEM (accessed from the python library) has changed, from 3 to 128, potentially causing issues in automated tools that make use of such constant value to check the type of the operands of an instruction.

Below a python run that shows the difference, using as example the x86 instruction mov eax, dword ptr [rsp + 0x14]:

Capstone version 5.0.0

>>> import capstone as cs
>>> md = cs.Cs(cs.CS_ARCH_X86, cs.CS_MODE_64)
>>> md.detail = True
>>> md.disasm("\x8b\x44\x24\x14", 0)
>>> ins = md.disasm(b"\x8b\x44\x24\x14", 0).__next__()
>>> ins
<CsInsn 0x0 [8b442414]: mov eax, dword ptr [rsp + 0x14]>
>>> ins.operands[1].type
3
>>> cs.CS_OP_MEM
3

Capstone version 5.0.1

>>> import capstone as cs
>>> cs.debug()
'python-standard-arm-arm64-bpf-evm-m680x-m68k-mips-mos65xx-ppc-riscv-sparc-sysz-tms320c64x-xcore-x86-c5.0-b5.0'
>>> md.disasm("\x8b\x44\x24\x14", 0)
>>> md.detail = True
>>> ins = md.disasm(b"\x8b\x44\x24\x14", 0).__next__()
>>> ins
<CsInsn 0x0 [8b442414]: mov eax, dword ptr [rsp + 0x14]>
>>> ins.operands[1].type
3
>>> cs.CS_OP_MEM
128

So my question is: is this an issue or is there another constant available to check the operand type?

Thanks in advance for the support.

@Rot127
Copy link
Collaborator

Rot127 commented Feb 16, 2024

Thanks for pointing this out. Turns out this was accidentally pulled in, because we wanted to have the TriCore architecture being part of v5. TriCore used the new auto-sync updater (will be released with v6) for creation. And architectures using it require to distinguish registers/immediate values used for memory and non memory registers/immediate values.

TriCore though probably doesn't require the value change? @imbillow

Here is the PR reverting it: #2275

I propose to change it back for v5.0.2? It's annoying to have this inconsistency between those versions. But IMHO it is still better, because people can get a clear pre-AutoSync version and a post-AutoSync version of Capstone.
cc @kabeor @XVilka (candidate for #2081)

@XVilka
Copy link
Contributor

XVilka commented Feb 16, 2024

See also #2144

@Rot127 Rot127 added bug X86 Arch labels Mar 19, 2024
@Rot127 Rot127 added this to the v5.0.2 milestone Mar 19, 2024
@Rot127 Rot127 modified the milestones: v5.0.4, v5.0.5 Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants