When starting gdb from emacs, emacs says that gdb should be started as
gdb -i=mi
The option -i is not defined in the gdb man page. If gdb is invoked from the command line with option -i=mi, it works. So it must be specific to gdb. Where is the documentation for the -i option?
gdb -i=mi is equivalent to gdb --interpreter=mi.
In short, --interpreter=mi makes gdb present a machine-oriented text interface rather than the human-oriented command prompt you get without it. Emacs's gud buffer parses the output from this interface and presents something resembling the normal gdb interface to you.
The --interpreter flag is documented here, and the GDB/MI interface is documented here. That -i is an alias for --interpreter is mentioned in passing here.
Related
I'm new to exploit development and looking for advice.
My question is: how can I keep giving input from one terminal and debug my program on another?
I usually use gdb.debug from pwntools when having graphical interface, but now I can only SSH remote to the machine which runs the binary, which means gdb.debug cannot create a new terminal.
I saw a video of a demonstration doing that technique in VIM. How can I achieve that?
gdb.debug should still work if you're using SSH as long as you set context.terminal to the right value (e.g. tmux).
How to use pwnlib.gdb
Here's a copy and paste of a response to a similar question:
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"]
(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.
Vim Explanation
You don't need to use vim to use pwntools's gdb features like the guy did in the video you linked, but here's an explanation on what he did (vim's also a nice tool regardless):
While editing his pwn script in vim, the guy first executed the following command:
:!./%
: enters command mode in vim
! executes a shell command
% is basically the name of the file you're currently editing in vim
So if your exploit script was named template.py running :!./% in vim would be the same as running ./template.py in your terminal. This just runs the exploit and enters interactive mode.
It's just a way shortcut to execute your script in vim.
Later, the guy also uses :!./% GDB to actually launch the pwntools gdb session. It's the same thing as running python template.py GDB.
I've got this EFL file which I need to debug/step-through. It's a reverse engineering competition. All I need to do is to find out the value of a register at a particular point in time and in a particular place. I used Hopper Disassembler to find out the address of interest.
Here's the problem. I don't know how to debug an ELF file. It's my first time debugging in a Linux environment. Learning how to execute the ELF file itself took me a while. I execute by using
ld-linux.so.2 ./[EFLFILE] [arguments]
Is there a way I can atleast attach a debugger onto the proess? I can't even find it with the ps command. Also, I've heard that it's possible to have remote debugger; to have a debugger running on a windows machine and have the binary to be examined running on a linux.
Could anyone help me achieve just any of this?
Usually an ELF file can be executed as follows:
$ /path/to/elffile [arguments]
To debug it using GDB you can do:
$ gdb /path/to/elffile
Or passing arguments:
$ gdb --args /path/to/elffile arguments...
In your case:
$ gdb --args ./[EFLFILE] [arguments]
Then type run or simly r and press < Enter >.
Type help to get help on the gdb commands.
Note: if your program needs some external libs, before running it, you should define LD_LIBRARY_PATH pointing on the folder containing those libs (export LD_LIBRARY_PATH=/the/path/to/libs)
Is there some way to keep the gdb log in a file.
I found:
$gdb run.o
(gdb) set logging file mylog.txt
(gdb) set logging on
(gdb)r
But it just keeps the logs of commands.
is there any option to have all the logs in a file ?
Yes, and no.
GDB cannot do it because output from the program being debugged is not visible to it.
The poor-man's way to do it is using tee:
gdb <blah> | tee logfile
That will work, but you'll find that the interactive features of GDB are missing (autocomplete, paging, etc.).
My preferred method is to use the logging feature in my terminal. I use "Terminator" with its "logger" plugin enabled, but I'm sure there are other options.
is there any option to have all the logs in a file
From man script:
script makes a typescript of everything printed on your terminal.
It is useful for students who need a hardcopy record of an interactive
session as proof of an assignment, as the typescript file can be
printed out later with lpr(1).
I've just tried using gdb on BackTrack Linux and I must say that its awesome. I wonder how gdb in backtrack is configured to act this way.
When I set a breakpoint, all the register values, a part of the stack, a part of the data section and the next 10-15 instructions to be executed are printed. The same happens when I step or next through the instructions.
I find this amazing and would love to have this on my Ubuntu machine too; how could I go about doing this?
They seem to be using this .gdbinit file:
https://github.com/gdbinit/Gdbinit/blob/master/gdbinit
I'm guessing that this is done using a post command hook:
http://sourceware.org/gdb/current/onlinedocs/gdb/Hooks.html#Hooks
inside of a system wide gdbinit:
http://sourceware.org/gdb/onlinedocs/gdb/System_002dwide-configuration.html
which may or may not reference shell commands and/or use gdb python scripts.
try:
strace gdb /bin/echo 2>&1 | grep gdbinit
I'm now extending more my x86 Assembly knowledge and one of the best tools for learning is DEBUG. When I was learning Assembly(past 4 years) I was on Windows, but now I'm on Linux Ubuntu and the DEBUG tool is only for Windows. Then I want to know is there is any port or equivalent for Linux.
Remember that I don't want to debug my code, but do things like the command -r, -t, -e...
-r = info registers
-t = stepi
-e = no direct equivalent; taviso wrote a macro providing similar functionality
debug with no args starts up with some blank 64k of memory that you can play around with; GDB doesn't. That really only made sense on DOS anyhow; you'll have to start with some binary.
Maybe assemble some blank slate like so?
$ echo .globl main >a.s
$ echo main: >>a.s
$ for i in {1..65536}; do echo 'int $3'; done >>a.s
$ cc a.s
$ gdb a.out
(gdb) run
gdb is pretty much the debugger on the Linux platform. You don't specify what features you require, but it probably has them :)
I used DEBUG mostly to assemble rather than "debugging"... if that's your goal,
NASM is a good assembler with more similar syntax
Use gdb to then run the code, allow disassembly, and examine memory
gdb - the GNU project debugger is the Linux standard debugger. It is far more powerful than DEBUG (if by that you mean the old DOS tool) and you should really learn at least the basics of how to use it if you are programming on Linux.