MSP430: byte operations sign-extend into registers instead of zero-extending

Open
#8,517 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
reverse-engineering

Research direction

Start in arch/msp430/src/lift.rs and inspect the byte-handling arms, including Instruction::Mov, where the issue identifies il.sx(2, ...) as suspect. Load sx_repro.bin or use the provided printf command, then compare LLIL at offset 0 and the resulting HLIL value against the documented zero-extension behavior. Done means byte register operations produce 0x80 + arg1 rather than 0xff80 + arg1.

Written by the indexing model from the issue text.

Description

Version and Platform (required):

  • Binary Ninja Version: 5.0.7648
  • Edition: Non-Commercial
  • OS: Ubuntu
  • OS Version: 24.04
  • CPU Architecture: x64

Bug Description:
A byte instruction with a register destination is lifted with a sign-extension. Per slau144 §3.2.5, Figure 3-7 (Byte-Register Operation), the high byte of the destination register is filled with 0h — byte operations zero-extend into registers.

Image

The result is an incorrect constant in HLIL for any byte value with bit 7 set.

Steps To Reproduce:
printf '\x7b\x40\x80\x00\x0f\x5b\x30\x41' > sx_repro.bin or open sx_repro.bin attached and look at sub_0 (if sub_0 does not exist, create a function at 0).

Expected Behavior:
The returned value should be 0x80 + arg1 and not 0xff80 + arg1.
LLIL at offset 0 should not sign-extend.

Confirmed against the mspdebug simulator (v0.22): with r11 = 0xdead and r15 = 0x1234 set beforehand, mov.b #0x80, r11 leaves r11 = 0x0080. The subsequent add r11, r15 gives 0x12b4.

Screenshots/Video Recording:

Image

Binary:
sx_repro.zip

Suspected cause (hypothesis):
The byte arms in arch/msp430/src/lift.rs use il.sx(2, ...) where il.zx(2, ...) is required — e.g. in Instruction::Mov:

OperandWidth::Byte => il
                    .sx(2, lift_source_operand(inst.source(), size, il))
                    .build()

This appears in several instruction arms, so the fix is likely needed in more than one place.

Dominant language
C++
Stars
1.3k
Forks
298
Avg merge
5d 5h
Merged PRs (30d)
19

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Vector35/binaryninja-api

All issues in Vector35/binaryninja-api

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.