I was debugging my program, then the last line happened, how can I fix it? I used the -fno-builtin to have a look at the strcpy() but it shows that the __strcpy_sse2_unaligned is getting called.
root#19:~/booksrc# gcc -fno-builtin -g char_array2.c
root#19:~/booksrc# gdb -q ./a.out
Reading symbols from ./a.out...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello World!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x708: file char_array2.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x5a0
(gdb) break 8
Breakpoint 3 at 0x71b: file char_array2.c, line 8.
(gdb) run
Starting program: /root/booksrc/a.out
Breakpoint 1, main () at char_array2.c:7
7 strcpy(str_a, "Hello World!\n");
(gdb) cont
Continuing.
Breakpoint 2, __strcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:47
47 ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory.
__strcpy_sse2_unaligned is the implementation of strcpy which is used on your machine. glibc automatically chooses an optimized implementation based on CPU characteristics, using an IFUNC resolver.
This does not have to do anything with GCC and GCC built-ins. GCC emits a call to strcpy. It is just that glibc happens to call the function which it __strcpy_sse2_unaligned.
Related
So I was reading Hacking the Art of Exploitation and in the book, they use the strcpy() function in their C code:
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
They then proceed to compile their source code and analyze it with gdb. He sets a breakpoint on line 6, the strcpy function, and line 8, but when setting a break on strcpy it reads the following:
(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
I understand that this is because the library has not yet been loaded, so it's asking if he wants to have it as a pending breakpoint. Then he runs the program and continues through the breakpoints:
Everything works well for him, but when I tried to re-create this on my computer, I get the following:
frinto#kali:~/Documents/theclang/programs/helloworld$ gcc -m32 -g -o char_array char_array.c
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11b6: file char_array.c, line 6.
(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (strcpy) pending.
(gdb) break 8
Breakpoint 3 at 0x11d7: file char_array.c, line 8.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 3, main () at char_array.c:8
8 printf(str_a);
(gdb) cont
Continuing.
Hello, world!
[Inferior 1 (process 4021) exited normally]
(gdb)
Notice how it completely skipped the strcpy breakpoint? Well, I asked a friend of mine what was the issue here, and he told me that I was missing the argument -fno-builtin when compiling. I did some minimal google searching on this argument and all I really understood is that it lets you set breakpoints on built-in functions. So I compiled the program with the -fno-builtin argument and then tried to re-create this again:
frinto#kali:~/Documents/theclang/programs/helloworld$ gcc -m32 -fno-builtin -g -o char_array char_array.c
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11c6: file char_array.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x1040
(gdb) break 8
Breakpoint 3 at 0x11dc: file char_array.c, line 8.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 2, 0xf7e510b0 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) cont
Continuing.
Breakpoint 3, main () at char_array.c:8
8 printf(str_a);
(gdb) cont
Continuing.
Hello, world!
[Inferior 1 (process 3969) exited normally]
(gdb)
Now it works! I have three questions:
What exactly is the -fno-builtin argument doing?
Why does it show question marks instead of the strcpy function in
Breakpoint 2, 0xf7e510b0 in ?? () from /lib/i386-linux-gnu/libc.so.6
Why doesn't it ask to set the strcpy breakpoint as pending when I use the -fno-builtin argument?
Sorry for the long thread, I just wanted to make sure everything was understood.
From man gcc
-fno-builtin
-fno-builtin-function
Don't recognize built-in functions that do not begin with
__builtin_ as prefix. GCC normally generates special code to
handle certain built-in functions more efficiently; for
instance, calls to "alloca" may become single instructions
which adjust the stack directly, and calls to "memcpy" may
become inline copy loops. The resulting code is often both
smaller and faster, but since the function calls no longer
appear as such, you cannot set a breakpoint on those calls, nor
can you change the behavior of the functions by linking with a
different library. In addition, when a function is recognized
as a built-in function, GCC may use information about that
function to warn about problems with calls to that function, or
to generate more efficient code, even if the resulting code
still contains calls to that function. For example, warnings
are given with -Wformat for bad calls to "printf" when "printf"
is built in and "strlen" is known not to modify global memory.
With the -fno-builtin-function option only the built-in
function function is disabled. function must not begin with
__builtin_. If a function is named that is not built-in in
this version of GCC, this option is ignored. There is no
corresponding -fbuiltin-function option; if you wish to enable
built-in functions selectively when using -fno-builtin or
-ffreestanding, you may define macros such as:
#define abs(n) __builtin_abs ((n))
#define strcpy(d, s) __builtin_strcpy ((d), (s))
function builtins allow to generate a faster code by inlining the function, but as stated in the manual
you cannot set a breakpoint on those calls
Inlining a function means that, instead of generating a function call, its effects are replaced by code directly inserted by the compiler. This saves a function call and can be more efficiently optimized and generally leads to a large improvement in performances.
But, the inlined function no longer exists in the code. Debugger breakpoints are implemented by replacing instructions at specific addresses by some software traps or by using specific hardware to recognize when the breakpointed address is reached. But as the function no longer exists, no address is associated with it, and there is no way to breakpoint it.
Pending breakpoints are a mean to set a breakpoint on some code that will be dynamically loaded later by the program. With -fno-builtin, strcpy is directly available and the bp can be directly set by gdb.
Note that debugging requires specific information in the executable generated by the -g flag. Generally system libraries like libc do not have the debugging information embedded and when entering function in these libraries, gdb indicates the lack of debugging information by ??.
What exactly is the -fno-builtin argument doing?
-fno-builtin means that gcc will not try to replace library functions with builtin compiled code, and you'll not get any weirdness due to such replacements. I've been bitten by replacements of printf("%s", mystr) by puts(mystr), for example - even when I wasn't including stdio.h at all!
Why does it show question marks instead of the strcpy function
Because there's no source file or line from which the "code" of strcpy() was taken - gcc just plugged in some assembly or its GIMPLE IR or whatever, instead of the glibc strcpy() implementation.
Why doesn't it ask to set the strcpy breakpoint as pending when I use the -fno-builtin argument?
Because then you're in the regular case of a plain vanilla function call with a breakpoint, and the debugger doesn't have to scratch its head and ponder what to do.
I'm trying to debug a program in gdb with a functions source code but I always need to set the EXACT path of the C file for that function:
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11c6: file char_array.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x1040
(gdb) break 8
Breakpoint 3 at 0x11dc: file char_array.c, line 8.
(gdb) dir ~/Documents/glibc-2.28/sysdeps/i386/i686/multiarch
Source directories searched: /home/frinto/Documents/glibc-2.28/sysdeps/i386/i686/multiarch:$cdir:$cwd
(gdb) cont
The program is not being run.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 2, strcpy_ifunc () at ../sysdeps/i386/i686/multiarch/strcpy.c:29
29 libc_ifunc_redirected (__redirect_strcpy, strcpy, IFUNC_SELECTOR ());
(gdb) cont
Continuing.
How can I tell gdb to recursively look for strcpy.c in ~/Documents/glibc-2.28 without having to set the exact path every single time?
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11c6: file char_array.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x1040
(gdb) break 8
Breakpoint 3 at 0x11dc: file char_array.c, line 8.
(gdb) dir /home/frinto/Documents/glibc-2.28
Source directories searched: /home/frinto/Documents/glibc-2.28:$cdir:$cwd
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 2, strcpy_ifunc () at ../sysdeps/i386/i686/multiarch/strcpy.c:29
29 ../sysdeps/i386/i686/multiarch/strcpy.c: No such file or directory.
(gdb) cont
Continuing.
Breakpoint 3, main () at char_array.c:8
8 printf(str_a);
(gdb)
I tried just setting the glibc directory but that doesn't work...
It is common to build GLIBC this way:
cd glibc-2.28 && mkdir build && cd build && ../configure --prefix=/usr && make
This results in source paths similar to ../sysdeps/i386/i686/multiarch/strcpy.c (they are relative to the build directory).
So what you want is:
cd ~/Documents/glibc-2.28 && mkdir build; cd -
gdb -ex 'dir ~/Documents/glibc-2.28/build' -q char_array
I'm trying to debug a program with gdb and when I set a breakpoint and continue on the strcpy() function. I get the following response:
frinto#kali:~/Documents/theclang/programs/helloworld$ gcc -fno-builtin -m32 -g -o char_array char_array.c
frinto#kali:~/Documents/theclang/programs/helloworld$ ls
a.out char_array char_array.c firstprog.c helloworld.c
frinto#kali:~/Documents/theclang/programs/helloworld$ ./char_array
Hello, world!
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11c6: file char_array.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x1040
(gdb) break 8
Breakpoint 3 at 0x11dc: file char_array.c, line 8.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 2, strcpy_ifunc () at ../sysdeps/i386/i686/multiarch/strcpy.c:29
29 ../sysdeps/i386/i686/multiarch/strcpy.c: No such file or directory.
(gdb)
I'm on Kali 2.0 and I've installed:
libc6-dbg and libc6-dbg:i386
If it isn't obvious already, I want to get rid of this error message:
../sysdeps/i386/i686/multiarch/strcpy.c: No such file or directory
Thanks in advance for any help!
I want to get rid of this error message:
This isn't an error. GDB is telling you that you've stopped in strcpy_ifunc function (see this description of what IFUNCs are), which is defined in ../sysdeps/i386/i686/multiarch/strcpy.c source file, and that GDB doesn't know how to find that file on the filesystem (and thus can't show you the source of strcpy_ifunc).
The best way to fix this is to tell GDB where to find this source. See (gdb) help directory.
Of course for this to work, you actually need the GLIBC sources. I don't know whether Kali packages sources into libc6-dbg:i386 or not, you may have to install a separate glibc-source package.
So I was reading Hacking the Art of Exploitation and in the book, they use the strcpy() function in their C code:
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
They then proceed to compile their source code and analyze it with gdb. He sets a breakpoint on line 6, the strcpy function, and line 8, but when setting a break on strcpy it reads the following:
(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
I understand that this is because the library has not yet been loaded, so it's asking if he wants to have it as a pending breakpoint. Then he runs the program and continues through the breakpoints:
Everything works well for him, but when I tried to re-create this on my computer, I get the following:
frinto#kali:~/Documents/theclang/programs/helloworld$ gcc -m32 -g -o char_array char_array.c
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11b6: file char_array.c, line 6.
(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (strcpy) pending.
(gdb) break 8
Breakpoint 3 at 0x11d7: file char_array.c, line 8.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 3, main () at char_array.c:8
8 printf(str_a);
(gdb) cont
Continuing.
Hello, world!
[Inferior 1 (process 4021) exited normally]
(gdb)
Notice how it completely skipped the strcpy breakpoint? Well, I asked a friend of mine what was the issue here, and he told me that I was missing the argument -fno-builtin when compiling. I did some minimal google searching on this argument and all I really understood is that it lets you set breakpoints on built-in functions. So I compiled the program with the -fno-builtin argument and then tried to re-create this again:
frinto#kali:~/Documents/theclang/programs/helloworld$ gcc -m32 -fno-builtin -g -o char_array char_array.c
frinto#kali:~/Documents/theclang/programs/helloworld$ gdb -q char_array
Reading symbols from char_array...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 6
Breakpoint 1 at 0x11c6: file char_array.c, line 6.
(gdb) break strcpy
Breakpoint 2 at 0x1040
(gdb) break 8
Breakpoint 3 at 0x11dc: file char_array.c, line 8.
(gdb) run
Starting program: /home/frinto/Documents/theclang/programs/helloworld/char_array
Breakpoint 1, main () at char_array.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) cont
Continuing.
Breakpoint 2, 0xf7e510b0 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) cont
Continuing.
Breakpoint 3, main () at char_array.c:8
8 printf(str_a);
(gdb) cont
Continuing.
Hello, world!
[Inferior 1 (process 3969) exited normally]
(gdb)
Now it works! I have three questions:
What exactly is the -fno-builtin argument doing?
Why does it show question marks instead of the strcpy function in
Breakpoint 2, 0xf7e510b0 in ?? () from /lib/i386-linux-gnu/libc.so.6
Why doesn't it ask to set the strcpy breakpoint as pending when I use the -fno-builtin argument?
Sorry for the long thread, I just wanted to make sure everything was understood.
From man gcc
-fno-builtin
-fno-builtin-function
Don't recognize built-in functions that do not begin with
__builtin_ as prefix. GCC normally generates special code to
handle certain built-in functions more efficiently; for
instance, calls to "alloca" may become single instructions
which adjust the stack directly, and calls to "memcpy" may
become inline copy loops. The resulting code is often both
smaller and faster, but since the function calls no longer
appear as such, you cannot set a breakpoint on those calls, nor
can you change the behavior of the functions by linking with a
different library. In addition, when a function is recognized
as a built-in function, GCC may use information about that
function to warn about problems with calls to that function, or
to generate more efficient code, even if the resulting code
still contains calls to that function. For example, warnings
are given with -Wformat for bad calls to "printf" when "printf"
is built in and "strlen" is known not to modify global memory.
With the -fno-builtin-function option only the built-in
function function is disabled. function must not begin with
__builtin_. If a function is named that is not built-in in
this version of GCC, this option is ignored. There is no
corresponding -fbuiltin-function option; if you wish to enable
built-in functions selectively when using -fno-builtin or
-ffreestanding, you may define macros such as:
#define abs(n) __builtin_abs ((n))
#define strcpy(d, s) __builtin_strcpy ((d), (s))
function builtins allow to generate a faster code by inlining the function, but as stated in the manual
you cannot set a breakpoint on those calls
Inlining a function means that, instead of generating a function call, its effects are replaced by code directly inserted by the compiler. This saves a function call and can be more efficiently optimized and generally leads to a large improvement in performances.
But, the inlined function no longer exists in the code. Debugger breakpoints are implemented by replacing instructions at specific addresses by some software traps or by using specific hardware to recognize when the breakpointed address is reached. But as the function no longer exists, no address is associated with it, and there is no way to breakpoint it.
Pending breakpoints are a mean to set a breakpoint on some code that will be dynamically loaded later by the program. With -fno-builtin, strcpy is directly available and the bp can be directly set by gdb.
Note that debugging requires specific information in the executable generated by the -g flag. Generally system libraries like libc do not have the debugging information embedded and when entering function in these libraries, gdb indicates the lack of debugging information by ??.
What exactly is the -fno-builtin argument doing?
-fno-builtin means that gcc will not try to replace library functions with builtin compiled code, and you'll not get any weirdness due to such replacements. I've been bitten by replacements of printf("%s", mystr) by puts(mystr), for example - even when I wasn't including stdio.h at all!
Why does it show question marks instead of the strcpy function
Because there's no source file or line from which the "code" of strcpy() was taken - gcc just plugged in some assembly or its GIMPLE IR or whatever, instead of the glibc strcpy() implementation.
Why doesn't it ask to set the strcpy breakpoint as pending when I use the -fno-builtin argument?
Because then you're in the regular case of a plain vanilla function call with a breakpoint, and the debugger doesn't have to scratch its head and ponder what to do.
I'm doing a bit of reading about gdb, and I'm having trouble getting gdb (I'm running 7.11.1) to debug a function from a library.
The sample code used to learn about the debugger is quite simple:
#include <stdio.h>
#include <string.h>
int main() {
char str_a[20];
strcpy(str_a, "Hello, world!\n");
printf(str_a);
}
I compiled it with debugging symbols enabled, fired up GDB, and set some breakpoints:
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
(gdb) break 7
Breakpoint 1 at 0x4005ad: file char_array2.c, line 7.
(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (strcpy) pending.
(gdb) break 8
Breakpoint 3 at 0x4005cf: file char_array2.c, line 8.
(gdb) run
Starting program: /home/david/hacking_the_art_of_exploitation/Chapter_2/char_array2
Breakpoint 1, main () at char_array2.c:7
7 strcpy(str_a, "Hello, world!\n");
(gdb) continue
Continuing.
Breakpoint 3, main () at char_array2.c:8
8 printf(str_a);
(gdb) continue
Continuing.
Hello, world!
[Inferior 1 (process 7061) exited normally]
As you can see, the debugger never descends into the strcpy function.
I've tried adding set stop-on-solib-events 1 to my .gdbinit. This leads to different but still undesirable results:
(gdb) run
Starting program: /home/david/hacking_the_art_of_exploitation/Chapter_2/char_array2
Stopped due to shared library event (no libraries added or removed)
I'm at a bit of a loss here. Thanks in advance for any help.
I believe you need the libc-dbg package and the libc source package for debugging a libc function. On Ubuntu you can install it via
sudo apt-get install libc6-dbg
mkdir ~/libc ; cd ~/libc
apt-get source libc6