Open rob2e opened 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.
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.
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 !
you are confused by the crappy endianness use of other tools
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?
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.
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. !!!
Did you check changing the e asm.cpu value ? e asm.cpu=? to see the value
I checked the first one i checked every asm.cpu doesn't change anything though
Can you please craft the tests for the testsuite? so it wont be broken next time after fixing?
ping
cc @killabytenow what do u know about those instructions?
@rob2e where do you recheck valid opcodes? IDA / avr-objdump / atmel site / etc.
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"