How to debug a C program which execute bash shell script with GDB?

Question

I build OpenSSL-1.0.2n with -g 386 shared --prefix=/usr option (to work with basic assembly version) to generate shared library libcrypto.so.1.0.0.

Inside crypto/aes folder, aes-x86_64.s is generated.

To perform AES encryption and decryption I used following commands in linux terminal.

/usr/bin/openssl enc -aes-128-cbc -in secrets.txt -out cipher.bin
/usr/bin/openssl enc -d -aes-128-cbc  -in cipher.bin -out decrypt_cip2.txt 

Using GDB, I am able to debug the execution of above command as follow

gdb openssl

gdb> set args enc -d -aes-128-cbc  -in cipher.bin -out decrypt_cip2.txt 
gdb> b AES_cbc_encrypt
gdb> run
Breakpoint 1, AES_cbc_encrypt () at aes-x86_64.s:1300
1300        cmpq    $0,%rdx

From the above output of gdb debugging, it is verified that AES_cbc_encrypt function of aes-x86_64.s file is called.

I need to verify, if I use a C program where system call is used to execute bash script to perform AES decryption, will the AES_cbc_encrypt function of aes-x86_64.s file still called ?

//test.c
    #include <stdio.h>
    #include <stdlib.h> 

    int main()
    {
    char cmd[500];
    sprintf(cmd, "/usr/bin/openssl enc -d -aes-128-cbc  -in cipher.bin -out decrypt_cip2.txt ");
    system(cmd);
    return 0;
      }
    gcc test.c -o test
    ./test

Will I be wrong, if I say when I execute this C program, it indirectly call openssl library (libcrypto.so) and perform decryption. So it must call AES_cbc_encrypt function of aes-x86_64.o file.

However, when I use GDB to debug this program it is not showing any call to AES_cbc_encrypt function of aes-x86_64.o file. It simply make some calls to /sysdeps/posix/system.c, /sysdeps/unix/sysv/linux/x86_64/sigaction.c etc.

gdb test

gdb> b AES_cbc_encrypt
Function "AES_cbc_encrypt" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (AES_cbc_encrypt) pending.

So, Here is my questions

1. how to debug the above C code using gdb so that it will stop at breakpoint AES_cbc_encrypt of installed OpenSSL?

2. Should I use other than system call in C program to run those bash command which will ensure indirectly calling AES_cbc_encrypt function of aes-x86_64.s file ?

Any help or link to solve this will be greatly appreciable.

I am using Ubuntu 16.04 , gcc-7.0 with debugging symbol on in OpenSSL version-1.0.2n.

Answer 1

However, when I use GDB to debug this program it is not showing any call to AES_cbc_encrypt function of aes-x86_64.o file. It simply make some calls to /sysdeps/posix/system.c

By default GDB will only debug one process (the test program) and that process isn't calling AES_cbc_encrypt -- rather it creates a new process -- $SHELL , which in turn creates another process -- /usr/bin/openssl , and only that grandchild process calls AES_cbc_encrypt .

Since you are debugging the grandparent of openssl , it is entirely expected that GDB does not observe AES_cbc_encrypt being linked into the process you are debugging, and that the breakpoint on AES_cbc_encrypt is never established, nor ever "fires".

how to debug the above C code using gdb so that it will stop at breakpoint AES_cbc_encrypt of installed OpenSSL?

There are a few ways:

1. One way is to modify test such that it invokes gdb instead of invoking openssl :

   sprintf(cmd, "gdb --args /usr/bin/openssl enc -d -aes-128-cbc -in cipher.bin -out decrypt_cip2.txt"); system(cmd);

2. If you can't or don't want to modify the test program, you could rename /usr/bin/openssh to /usr/bin/openssl.exe and place a shell wrapper into /usr/bin/openssl :

   #!/bin/sh exec gdb --args /usr/bin/openssl.exe "$@"

3. If you don't want to do either of above, you could use GDB multiple inferior support. Documentation here and here .

Update:

I am little bit wondering how it will execute ..exe file

UNIX systems don't care about file extensions (they look inside the file, ie at the file contents, to figure out how to run it).

Thus you can rename an executable file to anything you want: openssl.foo , openssl.bar , openssl.exe , openssl.orig , etc. and it will still run correctly.