Vector35/debugger

Debugger not working correctly on Aarch64 Linux

Closed this issue · 4 comments

joelreymont commented

Version and Platform (required):

  • Binary Ninja Version: 4.1.5278-dev, 83324703
  • OS: ubuntu
  • OS Version: 22.04
  • CPU Architecture: arm64

Internal binary major dine favor.

I can set a breakpoint at DjiCore_SetSerialNumber in gdb and quickly get to the function.

When I try to do this in BN it

  1. Stops in _start.
  2. Starts to analyze the binary, even though I have the database open.
  3. Gets stuck in analysis for a while.
  4. Gives me the this screenshot. It's probably related to the function I want since I see a serial number in the debugger window
Screenshot 2024-05-15 at 5 02 59 PM
  1. Gives me this when I try to continue
Screenshot 2024-05-15 at 5 03 35 PM
  1. Sometimes gives me this afterwards
Screenshot 2024-05-15 at 5 00 16 PM

  1. Stops as if the binary being debugged exited with code 255 but I have to kill the binary in the terminal since it's still running.

  2. Prints this to the log

[Default] Unknown system register 55303 @ 0xfffff7d59098: S3_3_c0_c0_7, using generic system register instead
xusheng6 commented

There is not enough information to work on this issue. A few things that are actually expected (but it could be surprising to a user):

  1. The debugger creates a fresh binary view every time it debugs, so it is not unexpected when it needs to do some analysis. That said, the analysis should finish pretty fast.
  2. When the target stops at a location that is not originally in the database, e.g., in a library function, then the analysis can take significantly longer, since it needs to analyze a lot of new code
  3. The user needs to understand what has happened and where has the target stopped at. From the screenshot you send, I am not 100% sure but chances are the target has stopped at an unusual location, you will need to understand what has happened and why the debugger stops there. There are many possible reasons, e.g., exceptions, anti-debugging, or a bug in our debugger. Without further information, there is no way to understand what happened and see if it is a bug in our debugger
joelreymont commented

Internal binary major dine favor, mea culpa.

Please try debugging it.

There's nothing fancy going on. No protection and no jumps to external libraries.

xusheng6 commented

I have tested in an aarch64 Ubuntu 22.04 VM running on top of apple silicon. Everything seems to be working fine for me:

Screen.Recording.2024-05-29.at.1.01.52.PM.mov
xusheng6 commented

Closing this for now -- the debugger passes our CI and unit test on arm64 Linux