search

radareorg / radare2

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

Invalid instructions in disassembly view when loading an AArch64 binary #15706

Closed cx9527 closed 4 years ago

cx9527 commented 4 years ago

This issue was transfered from radareorg/cutter to radareorg/radare2 by @ITAYC0HEN .

Environment information

Describe the bug

edit: Binary is available in the comments It can't disassemble aarch64 binary correctly, it shows invalid in the disassembly view.

Screenshots

微信截图_20191225133906

ITAYC0HEN commented 4 years ago

Hi! Thank you for your report. Is it possible for you to share the binary? It will be very helpful for us when investigating.

Does it happen for you immediately after opening cutter? Or is it related to debug? Does Cutter detected other functions in which you can see code?

cx9527 commented 4 years ago

Hi,

Here is the binary. abb.zip

And yes, it happens immediately after opening cutter and loading the binary. Other functions are all invalid.

ITAYC0HEN commented 4 years ago

I was able to reproduce the bugs. A lot of errors are thrown by radare2 when analyzing this file. I tried to open it with radare2 and it has the same issue, thus - the problem is in the analysis process in radare2. I am moving this issue to the radare2 repository and it will be tracked there. Thank you for reporting it!

radare commented 4 years ago

This screenshot looks like cutter not like r2 and you disnt shared the binary. Please provide binary and test in r2 or report the issue in cutter

On 25 Dec 2019, at 08:37, cx9527 notifications@github.com wrote:

 Environment information

Operating System: Ubuntu 18.04 Cutter version: Version 1.10.0 Using r2-4.1.1 Based on Qt 5.12.1 (GCC 7.4.0, 64 bit) Obtained from: Built from source Downloaded from release Distribution repository File format: ELF64 (AArch64) Describe the bug

It can't disassemble aarch64 binary correctly, it shows invalid in the disassembly view.

Screenshots

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

ITAYC0HEN commented 4 years ago

@trufae @radare please use your browser to read this issue,probably the email is not showing some stuff.

First line is saying : "This issue was transfered from radareorg/cutter to radareorg/radare2 by @ITAYC0HEN ."

First line of bug description is saying: "edit: Binary is available in the comments"

and finally read my comment which says:

"I was able to reproduce the bugs. A lot of errors are thrown by radare2 when analyzing this file. I tried to open it with radare2 and it has the same issue, thus - the problem is in the analysis process in radare2. I am moving this issue to the radare2 repository and it will be tracked there. Thank you for reporting it!"

radare commented 4 years ago

just use the omfg command. the code containing executable code have no read permissions, so it fails to read

radare commented 4 years ago

proposed fix: https://github.com/radareorg/radare2/pull/15718

radare commented 4 years ago

can we upload this abb bin to the testsuite?

gur111 commented 4 years ago

I've encountered this error as well. Analyzed libc compiled for arm from an Android 10 firmware. It didn't happen on Android 9. It's relatively heavy compared to the given binary though.

ITAYC0HEN commented 4 years ago

Closed in #15718 . Please let us know if this problem still occurs. This change will affect Cutter as soon as we will update our version of radare2. If you build from the source it would probably be somewhere in the next week. If you are using the release version, it will come with the new release. cheers! :)

LRitzdorf commented 2 years ago

Sorry to bring back this old issue, but I seem to be experiencing something similar.

Just for fun, I compiled a basic C "hello world" from Termux on my Android phone (Pixel 4a, on ARM, obviously). When analyzing the binary in R2 (both on that phone and on a modern x86-64 Linux PC), I get an invalid instruction in the middle of the sym.main function.

Speaking of which, my compiled binary seems to have its main function in a rather odd place. However, sym.main is located more reasonably (near the other compiler-generated functions) and seems to contain the actual main code. This might be an entirely unrelated issue, or even normal behavior (I'm not very experienced with ARM assembly). In either case, :s main doesn't behave as I'd expect it to.

The binary is attached, but reproducing this should be simple. Just compile int main() { printf("Hello World!\n"); return(0); } on Android, and you should see the same behavior.

image

Executable (renamed with a .jpg extension, because of GitHub's attachment restrictions): hello

trufae commented 2 years ago

This invalid instruction is outside the function scope. If you enable asm.esil=true you will see where its read and used. It's data. A negative number that is probably used as a delta for a relative reference

LRitzdorf commented 2 years ago

Ah, all right. Thanks for the quick response!

drsn00ker commented 1 year ago

Similar issue as OP. Running Latest Cutter appimage in Kali (tried Debian as well) On a Intel core2 duo. Trying to study an ARM32EL v8 program. Debug shows the incorrect x86 code in Disassembly window (but proper ARM registers (see picture). Importantly debug does complete the execution successfully! Just wish I could see what it's doing in the code.

I will also add that the emulator even shows the X86 registers and tries to (and fails) to run the code as x86, even though it is ARM. Lastly, I hope you will add the option of command line parameters for the emulator! Thanks for all the great work!

trufae commented 1 year ago

You are refering to the wrong project. Radare2 have nothing to do with cutter. Try iaito if you want to test properly

drsn00ker commented 1 year ago

Oops. Sorry about that!

drsn00ker commented 1 year ago

Well, wasn't expecting to be back here so soon. Radare2 might not have anything to do with cutter but it shows the exact same behavior. Debugging an ARM program on an x86 machine gives a x86 disassembly code, with ARM registers. But debug completes the program without errors. Also the emulator does not take command line parameters. (and shows x86 registers)

trufae commented 1 year ago

You cant natively debug programs from a different arch. So not sure how did you achieved that but it looks wrong in many ways indeed as you say. R2 can emulate properly so it must be a bug in iaito. Feel free to open a ticket in the iaito repo with the steps to reproduce.

Thank you