I am stuck when using pwntools for a program in remote server.
I tried gdbserver --multi and gdbserver --attach at server-side during pwn.gdb.attach((ip,port)) at client-side but it wasn't work.
Related
I am trying to attach GDB to QEMU for my bare-metal project on RISC-V. However, it is unable to connect. My host is a Ubuntu by WSL on a Windows machine. I am using the firmware supplied by openSBI to launch my custom "bootloader" (boot.bin).
I run QEMU (in Ubuntu WSL):
qemu-system-riscv64.exe --machine virt -m 256 -bios ./opensbi/build/platform/generic/firmware/fw_jump.bin -kernel ./boot.bin --nographic -s -S
Then I open a new command line (new Ubuntu WSL window) and start GDB:
riscv-gnu/bin/riscv64-unknown-elf-gdb
and specify a target:
target remote localhost:1234
After a few seconds this gives me the error: localhost:1234: Connection timed out.
Has anyone else had this issue, would be greatful for your help!
Usually WSL has an IP address in a different network so if you want to make a connection between WSL and Windows you need to provide correct IP and not just localhost.
Check ipconfig under Windows and in gdb provide IP of the correct network.
In my case Windows has a local address of 192.168.1.24 and WSL has 172.190.0.1. So to connect gdb from WSL to qemu running on Windows I need to type target remote 192.168.1.24.
I have a docker container running with -p 2000:2000, which is running a gdbserver on port 2000.
When trying to connect from my host machine through gdb I get the following:
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
The application running in the docker container is written in C++, behind a fcgi (gdbserver :2000 spawn-fcgi -p 8000 -n ./myBinary)
Host
OS: osx
gdb version: 8.0.1 (installed with --with-all-targets)
Container
OS: ubuntu 14.04
gdb version: 7.7.1
Any help would be appreciated.
i meet the same question ，when i run my qemu ，and i want connect gdb with qemu inner gdbserver.
i do the follow job:
run qemu in system mode.
run gdbserver inside qemu
run gdb in Host computer and connect gdbservr inside gdb.
the software version are below:
QEMU emulator version 2.12.92
gdb 7.11.1
GNU gdbserver (GDB) 7.8
at first i cannot connect gdbserver,the error is
(gdb) target remote 192.168.240.136:1234
Remote debugging using 192.168.240.136:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
i solve the problem by change to high level kernel when start start qemu. from vmlinux-2.6.32-5-4kc-malta to vmlinux-3.2.0-4-4kc-malta,then the command start qemu changed to below:
sudo qemu-system-mips -M malta \
-kernel vmlinux-3.2.0-4-4kc-malta \
-hda debian_squeeze_mips_standard.qcow2 \
-append "root=/dev/sda1 console=tty0" \
-net nic,macaddr=00:16:3e:00:01:01 \
-net tap \
-nographic
then the error was solved ,i can connect gdbserver with gdb.
the possible solve ways also include
bash setting
conflict
serial setting error
I can find instructions online to break on accesses to memory addresses using gdb (Watch a memory range in gdb?) but I can't figure out how to do so for memory addresses on the guest machine when I use qemu.
You start qemu with gdb server listening on port 1234 by supplying -s to the qemu comman line. From qemu man page:
-s Shorthand for -gdb tcp::1234, i.e. open a gdbserver on TCP port
1234.
In additon to this, you can also use option -S which will stop Qemu from progressing until you connect gdb to it and issue continue command.
-S Do not start CPU at startup (you must type 'c' in the monitor).
From gdb, you connect to the gdb server running on qemu, by starting gdb (version of gdb that fits you guest architecture). Then connect to the gdb server by command (if qemu is running on the same machine):
(gdb) target remote :1234
References:
http://wiki.qemu.org/Documentation/Debugging
How to debug the Linux kernel with GDB and QEMU?
I used to the St-write to burn .bin to the STM32F4 and saw the message which I expected. Now, I hope to understand how GPIO init. Hence, I use OpenOCD and arm-none-eabi-gdb to do that. Here, it is my process.
$ minicom
$ openocd -f /opt/openocd/share/openocd/scripts/board/stm32f4discovery.cfg
$ arm-none-eabi-gdb main.elf
(gdb) target remote localhost:3333
(gdb) localhost:3333: Connection timed out.
How do I check the port of OpenOCD? Why does it occur timeout?
That certainly means that openocd did not start or that the port is busy.
Usually, you use :
openocd -f board/stm32f4discovery.cfg
You should check that your session is running.
Are you running a virtual linux machine on a windows host?
If so, you probably need to replace localhost with 10.0.0.2 (or whatever your windows IP is).
A good way to know, is to telnet to the openOCD address and port 4444 and see if you get the openOCD prompt, and can type a few commands.
Does anyone know why I can't use Eclipse CDT to remotely debug a device when I manage it on the command-line with gdb using target remote command? I do get a warning when connecting, but other than that it seems to work fine.
With Eclipse I should have the correct settings and gdbserver informs me on the remote machine that a connection was establised but after that Eclipse gives an error: 'Launching Debug' has encountered a problem. The request failed: Target is not responding (timed out). Remote device also says "Killing inferior" (which I don't get with gdb). The error log shows nothing else either.
I am using the same process, binary and gdb executable in both cases and connecting to the same device & port. I'm using gdb 7.1 and the host is 64-bit Ubuntu Lucid.
I had same issue and found that iptables was generating issues.
Have you tried stopping or disabling your firewall? In case of iptables you have to do:
/etc/init.d/iptables stop
On the other hand, after you start your application (before connecting your debugger) have you checked the debug port availability through netstat?
#On linux
netstat -nap
#On windows
netstat -nab
Hope to help.