[b77d0424] open("etc/shadow",0_RDONLY) = -1 EACCESS (Permission denied)
every time i run [b77d0424] changed to another address
i can not use gdb b *0xb77d0424 and then c to find lib64/libc.so.6
it seems not the same mentioned in a linux programming book
after running ubuntu 13.04 in virtual box
every time i run [b77d0424] changed to another address
This is happening because of address space layout randomization, which you can disable with setarch -R command.
GDB also disables address randomization by default, but the chance that the same address you'll get in GDB and under strace is quite small, as the execution environment under the two tools is quite different. You don't actually need to find the address under strace, you can find it in GDB:
catch syscall open
run
You are now looking at one of the open system calls your program does. Use continue until you stop at the one you are interested in. Now use info registers to find the address of the first parameter, and set a watchpoint on that address.
Related
I know how to set up kernel debugging with qemu-gdbserver using -s switch. In Linux, kernel memory is non-swapable. Hence, the kernel virtual address remains the same for all processes in the system. Setting a breakpoint on a kernel address is a non-issue. However, there are multiple processes running on the system with potentially overlapping address ranges, but on their very own address spaces. Is there any means to set a breakpoint on (a) a specific process which is already running, and I know the PID of? (b) a specific process that is going to be created and I know the name of the binary/application?
QEMU's gdbstub is essentially a "system level" debug, similar to what you would get from a JTAG debugger. Any support for knowledge of guest-OS-specific concepts like user processes is something that would need to be in the debugger (where it works by knowing enough about guest OS internals to query the OS process table, set breakpoints for when the OS switches tasks, etc).
You might look at whether the kernel's gdb helper scripts have anything useful here, though I'm not sure if they get as sophisticated as "breakpoints in user processes":
https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-debugging.html
I'm currently playing around with GDB and want to debug a native processor in Android, specifically /system/bin/lmkd.
But I'm having trouble on how to stop GDB once that processor is invoked.
This is what I've tried so far:
Android-side:
./gdbserver tcp:5039 /system/bin/lmkd
Client-side:
gdb
target remote localhost:5039
From here, I typed in info shared, so I could get the base address of the native processor, set the breakpoint, continue, invoke the processor, then it would stop.
But info shared only shows address for shared object files.
Any recommendation on how to set breakpoint on the processor that I don't know the address to?
You should be able to find where the executable itself is mapped in the process's address space with info proc mappings in gdb. If you know the relative offset where you need a breakpoint, you can probably add it to something in there to get the final virtual address to break at.
But it sounds like you might be barking up the wrong tree with respect to getting breakpoints in this process; can't you set breakpoints by symbol name? Can you rebuild the binary with debugging symbols?
I'm trying to execute print *((int*)0x00401000) command on Kmines(a minesweeper game) with gdb and gdb/mi. While using gdb the command works and returns the output $1=0. But while using same command with gdb/mi it returns the ^error,msg="Cannot access memory at address 0x400000" error. Gdb can definitely access that location, there's no doubt for it. But why gdb/mi can't while gdb can?
I forgot to mention that I use non-stop mode. So because of it, gdb lets the debuggee run while it executes commands and gdb has to stop the process to access proc/pid/mem and read values from it.So gdb won't be able to access the memory if no thread has been stopped.
Edit: Some memory-examination functions such as disas works while some others such as print and x does not. So unfortunately, this answer is partially true.
I am using GDB along with a JTAG device, an Abatron BDI2000, to debug a programs running on a Motorola M68332.
The 68332 does not have any hardware breakpoint registers. It has very primitive debugging features.
The build tools do not generate 'elf' files, so no symbols for GDB to use.
Also the program I'm debugging is running in Flash.
In fact the 68332 has only one debug instruction, ti. ti by itself steps to the next assembly instruction. ti xxx steps until the address xxx is reached. [Yes, this is caveman days, cold hammer and chisel :)]
I am able to use GDB with target remote to connect to the BDI2000 and issue the GDB commands 'nexti'. Due to the limitations of the 68332, 'stepi' is equivalent to 'nexti'.
Single stepping is only command available.
The monitor command 'monitor ti ' states change the program counter to and step.
If one uses a 'monitor' command that changes the registers, then GDB does not know about the command and its register cache become out of sync. I have created GDB functions which have the GDB command 'flushregs' at the end of each of them. This marks the register cache dirty. The GDB command will fetch a new set of registers.
I would like to create a symbol table file for debugging, but have not found any documentation on the GDB symbol file format.
Are there alternatives to what I have setup?
I do have a RAM overlay for the Flash area. Would this allow software breakpoints?
Thanks in advance for any advice.
I found I can use 'convenience' variables as a substitute for symbols, since I'm not using ever symbol in the program all at once.
set $Symbol=(unsigned int*)<address>
Each 'Symbol' is declared a pointer to an unsigned int at an address. One can put these statements in .gdbinit, and add to them over time.
One can then state
break $Symbol
I show a GDB command function that can be passed one of these 'convenience' variables in the question linked below.
How do I write a GDB function to make a comparison to the program counter
To learn a bit more about FreeBSD and *nix systems in general, I'm starting to look at the binaries from the DEFCON 17 Capture The Flag game. Right now, I'm reversing the tucod binary. Here's some possibly useful information on tucod:
tucod: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, stripped
Some other possibly useful information gained from some brief static analysis is that tucod binds on port 0xDEAD (cute, eh?) and if you give it a specific password ("HANGEMHIGH!") it will play a game of hang-man with you.
The problem that I'm encountering is that I'm not hitting my breakpoints in gdb. Specifically, the breakpoint that I'm trying to reach is in the code that handles the client connection. Without breakpoints, the code executes as expected. When I set a breakpoint on that code, the child exits (instead of breaking into gdb, as expected). If I set breakpoints before the server forks off the child, I can hit those fine but after hitting "continue" the child does not continue to process my connection (that is, it won't ask me for a password or play hang-man).
Since the daemon forks when it receives a new connection, I try to tell gdb to follow the child with this command:
(gdb) set follow-fork-mode child
But after single-stepping the instructions after the fork, it appears that this isn't working.
I've tried looking for calls to signal, thinking they implemented a custom SIGINT handler (or similar), but the only call to signal that I can see handles SIGCHLD.
My breakpoint in gdb currently looks like this:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
And 0x080497d0 is the address I want to break on in the client processing code.
I'm sort of new to analyzing software on *nix systems and could use some pointers. How else should I go about troubleshooting why GDB will not hit my breakpoints? Or is there something major I'm just overlooking?
There's a torrent available with all of the game binaries for those interested in seeing the binary first-hand.
Look here for the answer. In short, it looks like GDB supports child debug mode only on HP-UX and Linux.