3

When I type gdb a.out and then run inside the gdb itself I get stuck on the empty line:

jericho-laptop:exploit.education jericho$ gdb a.out 
GNU gdb (GDB) 9.1
...
Reading symbols from a.out...
(No debugging symbols found in a.out)
(gdb) run
Starting program: /Users/jericho/Desktop/exploit.education/a.out 
[New Thread 0x2703 of process 53514]
[New Thread 0x2603 of process 53514]

  <<< STUCK IN HERE >>>

It obviously says 2 threads of a process 53514 were created. Though the program is not multi-threaded it is a simple tiny C crackme with only a main function.

The console gets stuck, I can type whatever I want but I can't get it to continue and I can't get it to quit. I have to forcibly close the terminal window.

What am I doing wrong?

I don't know what to do. The GDB does the same for any other binary I try to run. I am using MacOS with gdb 9.1 which I codesigned.

Improve this question
4
  • 1
    Dod you try some static analysis to check if maybe there aren’t any anti-debugging tricks? – Paweł Łukasik Feb 20 '20 at 14:29
  • @PawełŁukasik there aren't any anti-debugging tricks. I know that because I have the C source code :-) Intentionally I am trying to analyze the resulting binary. And as I said already, even if I run it on any other binary the result is the same, the GDB gets stuck. – user3732445 Feb 20 '20 at 14:34
  • This issue looks similar to the one listed here: github.com/Homebrew/homebrew-core/issues/34750 . If this problem occurs whenever gdb is used regardless of which binary is being debugged, clearly it’s a problem with that build of gdb. – julian♦ Apr 5 '20 at 14:40
  • On line 5: "(No debugging symbols found in a.out)". Did you compile with debugging info (-g flag for gnu compilers)? Anyhow, this will probably not fix the hanging issue, which was reported to gdb developers sourceware.org/bugzilla/show_bug.cgi?id=24069 – honey_badger Apr 13 '20 at 21:43
3

It looks like the problem is partially fixed by running set startup-with-shell off inside the gdb. Why? I don't know, no clue, I just read it somewhere.

If anyone has a different solution or know why this works, please, tell us here.

Improve this answer
2

If you've only opened the program in GDB and used run, then your program will start without stopping to let you debug it. GDB will typically only begin prompting you for input on an exception, signal, or breakpoint.

What you most likely need to do is to set a breakpoint on main, or some other function of interest, and then use run. This will make gdb stop at the breakpoint and prompt you for what to do next.

A handy alternative to b main; run is the start command. start will drop a breakpoint at main, or any other appropriate entry point in the binary, and immediately begin running the program.

In summary, the following should work:

$ gdb a.out
...

(gdb) b main
...

(gdb) run <args>

Or with start:

$ gdb a.out
...

(gdb) start <args>
...

More information and detail is available here:

Improve this answer
2

I think you're not doing anything wrong, you're experiencing this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24069

Usually if you retry several times you might get it to work eventually; it looks like a race condition.

The patch proposed in the bug report kind of works for me on macOS 10.15.5: instead of just hanging, GDB errors out upon run with:

During startup program terminated with signal ?, Unknown signal

but at least it does not hang. You can then retry run (or start) until it works.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.