I am trying to solve a reverse engineering challenge using using gdb. I can run the program inside it but when I set a breakpoint at main then I get

Program received signal SIGSEGV, Segmentation fault.

Setting it at something even earlier like _init (there are two BTW) also was not very fruitful, could it be that the program might be corrupting itself at some point that I didn't catch? Have a look at the backtrace for that matter:

#0  0x47048474 in ?? ()
#1  0x0804864a in __handle_global_ctors ()
#2  0x080488c5 in __do_global_ctors_aux ()
#3  0x08048349 in _init ()

Now I tried to statically decompile it using a simple recursive traversal disassembler (not IDA) but I couldn't find any traces of CC (INT 3) so I guess another layer of obfuscation has been added.

I also tried record with no success:

Breakpoint 5, 0x0804833a in _init ()
(gdb) record
(gdb) c
(null)Process record: failed to record execution log.

Oh and I couldn't find the hex string "47048474" either.

Any more ideas what can help in such a situation? Maybe detecting the self-modification?

  • 2
    Did you try to use hardware breakpoints (hbreak gdb command) ?
    – w s
    Nov 2, 2015 at 9:20
  • Good idea! But sadly it says: "No hardware breakpoint support in the target." :/ (x86 executable on x86_64, file says ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.4.1, not stripped)
    – phk
    Nov 3, 2015 at 20:53
  • 1
    Oops, as mentioned at reverseengineering.stackexchange.com/questions/11225/… the prog simply has to be started first for hbreak to work. Finally I can continue.
    – phk
    Nov 3, 2015 at 21:13
  • What challenge is it? Can you link it?
    – savram
    Oct 30, 2017 at 11:29

1 Answer 1


So, just to clarify what is already present in the comments:

gdb's break will place an ordinary breakpoint, which works by taking the in-memory image of the process and swapping its original instruction for a specific interrupt instruction. If I understand correctly, hbreak tells the OS to monitor every instruction an compare the address of current instruction to the address of breakpoint (i.e. no modification of the in-memory image). However, the number of hardware breakpoints available at a time is limited.

To place a hardware breakpoint with hbreak, your program must be already running with gdb's run. To achieve that, you should place an ordinary breakpoint somewhere at the very beginning (let's say, _start function), successfully break there, place a hardware breakpoint and then remove the original ordinary breakpoint.

  • Is the OS really the one doing the monitoring? I thought this is where the hardware assistance comes into play.
    – phk
    Oct 30, 2017 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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