Re: Cannot access memory at address 0x90909090

[fr0stman <fr0stman () sun-tzu-security net>]

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