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.
Related
I am trying to do a stackoverflow for a course at university. The binary I am to exploit has a canary, however, there is a way to leak that canary to stdout. The canary of course consists of some random bytes so I can't just read them from the string that the program outputs to stdout.
For this reason I am using the python and pwntools like p.recv(timeout = 0.01).encode("hex").
(I'm using pwntools only because I don't know another way to read the output in hex format, if there is an easier way I can of course use something else)
This works more or less works as expected, I manage to write the memory area that is past the canary. However, I get a segfault, so I obviously have some problem with the stackoverflow I am causing. I need a way of debugging this, like seeing the stack after I provide the input that causes the stackoverflow.
And now without any further ado the actual question: Can I debug a process that I started with pwntools (like process("./myprog")) in GDB or some other program that can show me the content of the stack?
I already tried getting the pid in python and using gdb attach to attach to that pid, but that didn't work.
Note: The binary I am trying to exploit has the guid set. Don't know if that matters tho.
You can use the pwnlib.gdb to interface with gdb.
You can use the gdb.attach() function:
From the docs:
bash = process('bash')
# Attach the debugger
gdb.attach(bash, '''
set follow-fork-mode child
break execve
continue
''')
# Interact with the process
bash.sendline('whoami')
or you can use gdb.debug():
# Create a new process, and stop it at 'main'
io = gdb.debug('bash', '''
# Wait until we hit the main executable's entry point
break _start
continue
# Now set breakpoint on shared library routines
break malloc
break free
continue
''')
# Send a command to Bash
io.sendline("echo hello")
# Interact with the process
io.interactive()
The pwntools template contains code to get you started with debugging with gdb. You can create the pwntools template by running pwn template ./binary_name > template.py. Then you have to add the GDB arg when you run template.py to debug: ./template.py GDB.
If you get [ERROR] Could not find a terminal binary to use., you might need to set context.terminal before you use gdb.
If you're using tmux, the following will automatically open up a gdb debugging session in a new horizontally split window:
context.terminal = ["tmux", "splitw", "-h"]
And to split the screen with the new gdb session window vertically:
context.terminal = ["tmux", "splitw", "-v"]
(Note: I never got this part working, so idk if it'll work. Tell me if you get the gdb thing working).
(To use tmux, install tmux on your machine, and then just type tmux to start it. Then type python template.py GDB.
If none of the above works, then you can always just start your script, use ps aux, find the PID, and then use gdb -p PID to attach to the running process.
I'd like to collect just the stacktrace for crashes which would normally result in very large coredumps. It seems like one option is to attach to the process when it's in a crashed but not yet cleaned up state. I tried gstack which uses gdb but gdb didn't like the fact that the process had already crashed.
Does anyone know if libunwind could do this?
This question seemed relevant:
How to get a "backtrace" (like gdb) using only ptrace (linux, x86/x86_64)
and contained a reference to this example:
http://git.savannah.gnu.org/cgit/libunwind.git/plain/tests/test-ptrace.c?h=v1.0-stable
Thanks a bunch!
My understanding is that gdb can monitor the complete state of a running program. Can I save a gdb session that is paused at a breakpoint and resume the session later?
My first attempt was simply generating a core dump in a first gdb session that was paused at a breakpoint and then using the core dump to start a second gdb session.
Saving core file in gdb
This resulted in the following error.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
So breakpoint information is inserted into the program state, interesting. On my second attempt I did the same but this time I added the same breakpoint to the second session as were in the first session.
Getting gdb to save a list of breakpoints?
Still, I get the same error.
Can I save and restart a gdb session? If so, how?
I don't think this is directly relevant but I'm also getting this warning.
warning: core file may not match specified executable file.
Is gdb simply stating that such a thing is possible in general or does gdb believe this may have happened in the running session? I'm confident that the same executable that produced the core dump is being run under gdb.
Edit: For anyone else who comes along, this question: Save a process' memory for later use? adds to Mats Petersson's answer and links to this article: http://blogs.msdn.com/b/oldnewthing/archive/2004/04/20/116749.aspx which is an interesting read. The linked question also has the suggestion of wrapping the process up in a VM.
I doubt that will ever work. Handles for files and any other resources (semaphores, shared memory, serial ports, network connections and lots of other things) that the program has opened/created will be lost when you save the core-file. You can inspect it, but you can't "continue". A core-file is simply a copy of all the memory that original program was using. Anything else is "lost" when the program terminates. In other words, a core-file will only be useful to inspect things later on, but you can't run, step or continue in a core-file debug session. Only "look at things". And if you can't execute, breakpoints won't really work either... ;)
I just started using gdb for basic debugging of active processes. I know I can use disassemble or diassemble(memory address) or disassemble (start), (end). However, I want to disassemble the whole program at once. Is there any way to get the end address of a process I've attached to?
Edit: And I would like to do so without using layout asm
[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.