ARM Thumb: disassembly for BL instruction resolves incorrect immediate value.

[rchtsang]

capstone v4.0.2 installed from pip (Mac OSX 12.6 and Ubuntu 20.04)

It seems like the ARM Thumb BL immediate values are being incorrectly decoded.

Manually decoding the instruction b"\xff\xf7\xad\xff" ought to yield bl 0xffffff5a, however, capstone gives the following:

>>> from capstone import *
>>> from capstone.arm_const import *
>>> cs = Cs(CS_ARCH_ARM, CS_MODE_THUMB)
>>> insn = next(cs.disasm(b"\xff\xf7\xad\xff", 4))
>>> insn
<CsInsn 0x4 [fff7adff]: bl #0xffffff62>

I have tried with some other bl instructions and the immediate values are also off by 8.

[rchtsang]

it also seems to affect some unconditional branch instructions, in particular
b'\xfe\xe7' ought to yield b.n 0xfffffffc (b.n -4), but instead

>>> insn = next(cs.disasm(b"\xfe\xe7", 2))
>>> insn
<CsInsn 0x2 [fee7]: b #2>

[rchtsang]

also happening with cbz/cbnz

>>> next(cs.disasm(b'\x13\xb1', 2))
<CsInsn 0x2 [13b1]: cbz r3, #0xa>

expected cbz r3, #0x4

[rchtsang]

This still seems to be failing.

installed via pip install --pre --no-binary capstone capstone per #2147 installs v5.0.1

expecting bl 0xffffff5a

>>> from capstone import *
>>> from capstone.arm_const import *
>>> cs = Cs(CS_ARCH_ARM, CS_MODE_THUMB)
>>> insn = next(cs.disasm(b"\xff\xf7\xad\xff", 4))
>>> insn
<CsInsn 0x4 [fff7adff]: bl #0xffffff62>

Mac M1 Pro, MacOS 14.2.1

[Rot127]

I assume this is because it uses Capstone v5. In the next branch the instruction disassembles correctly:

./cstool -d thumb "\xff\xf7\xad\xff"
 0  ff f7 ad ff  bl	0xffffff5e
	ID: 46 (bl)
	op_count: 1
		operands[0].type: IMM = 0xffffff5e
		operands[0].access: READ
	Registers read: r13
	Registers modified: r14
	Groups: call branch_relative IsThumb

In general I would recommend you to use the next branch. It supports way more instructions and is more correct.
If you can't and have to rely on v5 for now, feel free to open the issue again, we can add it to #2081

[rchtsang]

Thanks for the tip, though I still seem to be getting the issue on next, but only when trying to install the python bindings.

I'm using a conda virtual environment for python 3.11 with pip installed.

$ cd bindings/python
$ sudo make install3

and that should be it?
I rebuilt libcapstone.5.dylib, but can't confirm if setup.py is using it?

I can confirm that cstool disassembles it correctly.

Am I building the bindings wrong or should I actually reopen the issue?

[Rot127]

Have you ran make clean before building next? Python bindings still use the make method unfortunately.

[rchtsang]

I did, yeah.

[Rot127]

Yeah, tried it as well. It is something with the Python bindings. Apologies. We work on better testing. Hope I'll come to it in the next days.

[rchtsang]

Got it, thank you very much for your response! Should I open a new issue re:python bindings?

[Rot127]

Nah, just reopen this one, since it wasn't properly resolved. Thanks!

[rchtsang]

I don't have permission to reopen...

will open a new issue and reference this one (the underlying problem is likely different this time anyways)

[Rot127]

Please do that than. I don't have permission either.