using GDB and dealing with breakpoint detection

Question

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
Continuing.
(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?

Did you try to use hardware breakpoints (hbreak gdb command) ? — w s
– w s, Commented 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
– phk, Commented Nov 3, 2015 at 20:53
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
– phk, Commented Nov 3, 2015 at 21:13

alisianoi · Accepted Answer · 2017-10-30 09:27:23Z

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
– phk, Commented Oct 30, 2017 at 12:42

Stack Exchange Network

using GDB and dealing with breakpoint detection

1 Answer 1

Your Answer

Hot Network Questions

using GDB and dealing with breakpoint detection

1 Answer 1

Your Answer

Sign up or log in

Post as a guest

Related

Hot Network Questions