GDB couldn't find real strings most of the time. But, you can find the offset of the string from the local object file and adjust it with dynamic loading information.
From info proc map
:
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x8048000 0x8049000 0x1000 0 /opt/protostar/bin/stack6
0x8049000 0x804a000 0x1000 0 /opt/protostar/bin/stack6
0x804a000 0x806b000 0x21000 0 [heap]
0xb7e96000 0xb7e97000 0x1000 0
0xb7e97000 0xb7fd5000 0x13e000 0 /lib/libc-2.11.2.so
0xb7fd5000 0xb7fd6000 0x1000 0x13e000 /lib/libc-2.11.2.so
0xb7fd6000 0xb7fd8000 0x2000 0x13e000 /lib/libc-2.11.2.so
0xb7fd8000 0xb7fd9000 0x1000 0x140000 /lib/libc-2.11.2.so
...
And from /lib/libc-2.11.2.so
file:
user@protostar:/opt/protostar/bin$ xxd -u /lib/libc-2.11.2.so |grep -B 1 bin/sh
011f3b0: 6600 696E 6974 7900 6E61 6E00 2D63 002F f.inity.nan.-c./
011f3c0: 6269 6E2F 7368 0065 7869 7420 3000 6361 bin/sh.exit 0.ca
Use this info to find static address of /bin/sh
string in virtual address space:
(gdb) x/s 0xb7e97000+0x011f3bf
0xb7fb63bf: "/bin/sh"
I know this is not an answer to your first question about why GDB find shows this behavior when finding strings. I couldn't find anything about that. I used Protostar Stack6 challenge binary and exploit-exercises-protostar-2.iso environment, so addresses must be the same. There is also /bin/csh
string in the same shared object file. You can try to find that address using this method.