MSP430 disassembly, missing indicator for Immediate Value or Memory Location

[mattmattandmatt]

• Operating System: Windows 10
• Cutter version: 2.3.4
• Obtained from: Downloaded release from Cutter website or GitHub
• File format: RAW Binary

After I have disassembled a MSP430 binary, I do not see an "#" or "(0x1234)" or "@" to show it is a Immediate Value or Memory Location. It just shows the plain hex numbers. There are some parenthesis that appear. But they show only when Memory offsets are used.

[XVilka]

@moste00 since you are working on MSP430 RzIL and updating disassembly, could you please check this one as well?

[moste00]

Hello @mattmattandmatt, could you provide the binary you were working on, or a any reproducing binary?

[mattmattandmatt]

Hello, here is the binary. Fluke-1652-Analog2-rom-v108.zip Also here is another binary from the same device, but a different board: Fluke-1652-Digital-rom-v112.zip

EDIT: oh the config data stored at [0x1000] - [0x1073] in Analog2 maybe incorrect. So its best to ignore that (even though the checksum is correct)

[moste00]

@XVilka @mattmattandmatt Hello guys, here's an investigation of this issue:

1- The MSP430 disassembly plugin is fine. As a matter of fact, invoking rz-asm with -s att will correctly print the value indicator. Here's a reproducing command rz-asm -s att -a msp430 -d 3f401000, this is supposed to print mov #0x0010, r15.

(Shoutout to the great person behind https://github.com/Swiftloke/MSProbe, a Python disassembler for msp430 which I used to assemble mov #10, r15 into its binary equivalent.)

2- Which brings us to the main reason the indicators aren't showing: Assembly syntax. That is, this if condition in librz/arch/p/asm/asm_msp430.c checks whether the assembly is NOT the AT&T syntax, if so, it simply removes any indicator like # and &. I don't know why it does this, I have always thought that the whole Intel vs. AT&T mini-war is about the x86, it's a surprise for me that this convention standoff exists in other architectures and assembly languages.

3- As for why the assembly is not AT&T, that's simply the initialization logic for RzAsm configuration structure, here. The Intel syntax is the default.

So that's the whole issue in a nutshell, different assembly syntaxes make the MSP430 plugin remove the #s and the &s for some reason.

The quickest and cleanest fix is to simply make the default syntax to be AT&T, but it's also worth asking why does other syntaxes than AT&T necessarily mandate removal of # and &, indeed if the whole notion of different syntaxes for the MSP430 (which is nearly universally written with a single syntax in nearly all other resources I saw) makes sense at all.

[mattmattandmatt]

@moste00 Thank you for the investigation. I was not aware of the Intel/AT&T thing.

[XVilka]

@moste00 the Intel syntax still should show these indicators, so this has to be fixed.