radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.68k stars 3k forks source link

r2 / rasm2 valid AVR opcodes are disassembled and shown as "invalid" #9166

Open rob2e opened 6 years ago

rob2e commented 6 years ago
Questions Answers
OS/arch/bits (mandatory) Debian
File format of the file you reverse (mandatory) AVR prog file
Architecture/bits of the file (mandatory) bin file
r2 -v full output, not truncated (mandatory)

radare2 2.3.0-git 16829 @ linux-x86-32 git.2.2.0-20-g4968a55da commit: 4968a55da80c384d70d14dbbe41f06ef41df0753 build: 2018-01-06__23:47:19

| r2 -V full output in a pastebin document (mandatory) |

Expected behavior

All valid opcodes of the AVR code disassembly should be recognized, but about 1% of Opcodes are shown as "invalid". This happens in "r2 -a avr " and is reproduceable with "rasm2 -a avr -d " as well I figured out, that when you make a byteswap of the opcode word, then you get the right translation. It seems that sometimes ther is a byteswap of the opcode word before entering avr_instructionset.c The rules in this file are o.k.

Steps to reproduce the behavior

The opcode for "ldi r31, 0x9a" is 0xe9fa !!! rasm2 -a avr -d 0xe9fa --> "invalid" rasm2 -a avr -d 0xfae9 --> "ldi r31, 0x9a"

radare commented 6 years ago

I dont think hexpairs are expressed as 0x...

On 9 Jan 2018, at 20:34, rob2e notifications@github.com wrote:

Questions Answers OS/arch/bits (mandatory) Debian File format of the file you reverse (mandatory) AVR prog file Architecture/bits of the file (mandatory) bin file r2 -v full output, not truncated (mandatory)
radare2 2.3.0-git 16829 @ linux-x86-32 git.2.2.0-20-g4968a55da
commit: 4968a55 build: 2018-01-06__23:47:19
| r2 -V full output in a pastebin document (mandatory) |

Expected behavior

All valid opcodes of the AVR code disassembly should be recognized, but about 1% of Opcodes are shown as "invalid". This happens in "r2 -a avr " and is reproduceable with "rasm2 -a avr -d " as well I figured out, that when you make a byteswap of the opcode word, then you get the right translation. It seems that sometimes ther is a byteswap of the opcode word before entering avr_instructionset.c The rules in this file are o.k.

Steps to reproduce the behavior

The opcode for "ldi r31, 0x9a" is 0xe9fa !!! rasm2 -a avr -d 0xe9fa --> "invalid" rasm2 -a avr -d 0xfae9 --> "ldi r31, 0x9a"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

radare commented 6 years ago

Also that opcode is 0xfae9

Hexpairs ar not affected by endian, numbers do

On 9 Jan 2018, at 20:34, rob2e notifications@github.com wrote:

Questions Answers OS/arch/bits (mandatory) Debian File format of the file you reverse (mandatory) AVR prog file Architecture/bits of the file (mandatory) bin file r2 -v full output, not truncated (mandatory)
radare2 2.3.0-git 16829 @ linux-x86-32 git.2.2.0-20-g4968a55da
commit: 4968a55 build: 2018-01-06__23:47:19
| r2 -V full output in a pastebin document (mandatory) |

Expected behavior

All valid opcodes of the AVR code disassembly should be recognized, but about 1% of Opcodes are shown as "invalid". This happens in "r2 -a avr " and is reproduceable with "rasm2 -a avr -d " as well I figured out, that when you make a byteswap of the opcode word, then you get the right translation. It seems that sometimes ther is a byteswap of the opcode word before entering avr_instructionset.c The rules in this file are o.k.

Steps to reproduce the behavior

The opcode for "ldi r31, 0x9a" is 0xe9fa !!! rasm2 -a avr -d 0xe9fa --> "invalid" rasm2 -a avr -d 0xfae9 --> "ldi r31, 0x9a"

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

rob2e commented 6 years ago

O.K. I tried it, you don't need the 0x in front of the opcode, but try it yourself, what you get as disassembly for fae9 or for e9fa !

radare commented 6 years ago

you are confused by the crappy endianness use of other tools

rob2e commented 6 years ago

No! No! No! It's not that simple! 99% of the opcodes work when you enter them as described in the Atmel documentation and for 1% of opcodes you take the same order as described by Atmel you get an invalid. Only this one percent Need a byteswap to be interpreted correctly?

radare commented 6 years ago

Can you send a pr fixing tjis? If this is just an issue with 1 opcode should be 1 line fix. Maybe @killabytenow can have a look

On 10 Jan 2018, at 14:20, rob2e notifications@github.com wrote:

No! No! No! It's not that simple! 99% of the opcodes work when you enter them as described in the Atmel documentation and for 1% of opcodes you take the same order as described by Atmel you get an invalid. Only this one percent Need a byteswap to be interpreted correctly?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

rob2e commented 6 years ago

It's not only one opcode. Here is a grep searching for "invalid" in one prog file. I found 27 opcodes disassembled as "invalid". I checked each of them, they are valid opcodes: 0afa invalid 0afd invalid 0aff invalid 0ef8 invalid 2994 invalid 2b92 invalid 2bfa invalid 2bfc invalid 3df9 invalid 3dfc invalid 4af9 invalid 4afa invalid 4afc invalid 4afd invalid 4afe invalid 4aff invalid 4d00 invalid 5ffa invalid 6494 invalid 68fe invalid 6af9 invalid 6df9 invalid 6efb invalid 6efd invalid 78f8 invalid 78f9 invalid 78fb invalid So there is something wrong for sure !!! The definition in avr_instructionset.c is o.k. !!!

Maijin commented 6 years ago

Did you check changing the e asm.cpu value ? e asm.cpu=? to see the value

Maijin commented 6 years ago

I checked the first one i checked every asm.cpu doesn't change anything though

XVilka commented 6 years ago

Can you please craft the tests for the testsuite? so it wont be broken next time after fixing?

radare commented 6 years ago

ping

radare commented 6 years ago

cc @killabytenow what do u know about those instructions?

dukebarman commented 6 years ago

@rob2e where do you recheck valid opcodes? IDA / avr-objdump / atmel site / etc.