I'm trying to debug the program remotely with gdbserver.
The following works fine:
gdbserver :1234 ./test-program
But I need to debug the program with preloaded .so file.
And this doesn't work:
gdbserver :1234 'LD_PRELOAD=./libefence.so ./test-program'
How to do this?
Tried also to use exec wrapper, but this doesn't work either:
gdbserver --wrapper 'LD_PRELOAD=./libefence.so' -- :1234 ./test-program
Found the solution:
gdbserver --wrapper env 'LD_PRELOAD=./libefence.so' -- :1234 ./test-program
Related
I'm trying to exploit the binaries from Damn vulnerable Router Firmware but I have issues with debuggging with gdb.
to run the program i use this command :
sudo chroot . ./qemu-mipsel-static ./pwnable/Intro/stack_bof_01
and it works but when i try to run gdb with :
sudo chroot . ./qemu-mipsel-static gdb ./pwnable/Intro/stack_bof_01
I have that :
(gdb) r
Starting program: /pwnable/Intro/stack_bof_01
qemu: Unsupported syscall: 4026
Cannot exec /bin/bash: No such file or directory.
qemu: Unsupported syscall: 4026
Could not open /proc/12532/status
I tried to copy the binary in a qemu VM but I don't have the whole system so it don't work.
So , please , what's is the best way to debug a program from a firmware on a different architecture than x86 ?
In qemu user mode, run the program using the command with the option -g:
sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof_01
then start the gdb-multiarch (or gdb that corresponds to that architecture), and attach to it like this:
target remote 127.0.0.1:1234
then you can debug it happily.
I have a setup with openocd and arm-none-eabi-gdb and I'm trying to debug a FreeRTOS fw.
I start openocd with:
openocd -f /usr/local/share/openocd/scripts/board/stm32f0discovery.cfg -c "stm32f0x.cpu configure -rtos auto"
That command works fine.
Then I run arm-none-eabi-gdb -tui and at the end of my .gdbinit I have:
target remote localhost:3333
monitor reset halt
file build/fw.elf
load
continue
focus next
But when I try to stop <ctrl>-c and start continue my fw all I get is the error:
Cannot execute this command without a live selected thread.
What am I missing?
I'm using a JLink Base debug probe.
My case is a bit different than yours, with a setup using QtCreator and its Baremetal plugin, but found a bug report where they state a workaround:
https://bugreports.qt.io/browse/QTCREATORBUG-18436
The workaround is pretty easy:
in GDB Init commands add "info threads" after load command. It fixes issue.
I tried it, and it worked, the error message was removed, and now I can see the different tasks in FreeRTOS.
I am using gdb and gdbserver for debugging my exe. My target is same as local host currently. I start the gdbserver using
gdbserver.exe :6000 MyTest.exe 1> NUL 2> NUL
and my gdb is started using
gdb.exe -ex "set target-async on" -ex "target remote :6000"
But when I try info threads or set or get a global variable , I get cannot execute command target running. I tried to use interrupt before set but this doesn't change anything. Does any one know what could be wrong or what I'm doing wrong?
There is no input file to the gdb.exe in your code. Provide the same MyTest.exe file to gdb on host so that gdb can load the symbols
gdb.exe MYTest.exe
(gdb)set target-async on
(gdb)set target remote :6000
Qemu terminated with the log : "QEMU: Terminated via GDBstub" when I tried to connect to QEmu from GDB .
I started the QEMU with the following command in one terminal :
qemu-system-arm -serial telnet:localhost:1235,server,nowait,ipv4 -serial telnet:localhost:1236,server,nowait,ipv4 -serial telnet:localhost:1238,server,nowait,ipv4 -gdb tcp:localhost:1234,server,ipv4 -kernel ./build/final.elf -M versatilepb -nographic -m 256 -S
And then in another terminal I started GDB with the command :
arm-none-eabi-gdb --command=~/.gdbinit
And the file .gdbinit contains the text:
set history save on
set logging on
target remote localhost:1234
load ./build/final.elf
sym ./build/final.elf
b break_virtual
Can you please let me know whats going wrong here?
GDB automagically loads ~/.gdbinit
so when you load .gdbinit via --command=~/.gdbinit
it runs the script twice,
when it gets to the 2nd invocation of target remote localhost:1234
gdb hangs up its initial connection, qemu quits,
then gdb fails to reconnect to it because it is no longer running.
Either get rid of the --command option or rename the file.
I have a program using LD_PRELOAD. The program should be run like
this, "LD_PRELOAD=/path/to/libfoo.so qemu -U LD_PRELOAD a.out", if
without gdb.
Here are what I did while running gdb.
(gdb) set environment LD_PRELOAD=/nfs_home/chenwj/tools/lib/libdbo.so
(gdb) file /nfs_home/chenwj/tools/bin/qemu-i386
(gdb) r -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1
But gdb gave me the error below
Starting program: /nfs_home/chenwj/tools/bin/qemu-i386 -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1
bash: open "/bin/bash" failed: Permission denied
During startup program exited with code 66.
Any sugguestion appreciated.
Regards, chenwj
GDB does not invoke your executable directly. Instead, it does
bash -c '/nfs_home/chenwj/tools/bin/qemu-i386 -U LD_PRELOAD bzip2_base.i386-m32-gcc44-annotated input.source 1'
This is done so that bash takes care of I/O redirection (which you are not using).
My guess is that /bin/bash doesn't work when LD_PRELOAD=libdbo.so is in effect, though I don't understand the exact nature of failure.
One way to work around this problem is to create a wrapper executable, implementing C equivalent of this:
export LD_PRELOAD=/nfs_home/chenwj/tools/lib/libdbo.so
exec /nfs_home/chenwj/tools/bin/qemu-i386 "$#"
and debug that executable (without setting LD_PRELOAD). You'll see an extra SIGTRAP when the wrapper execve()s the wrapped qemu-i386, which you should ignore and continue.