3

The aim is to get the address of the precomputed tables in the openssl implementation of AES. These tables are contained in the aes_core.c file and named Te0, Te1, etc. I am trying to do it using the info address SYMBOL_NAME command in gdb.

So these are the steps I followed so far:

  • Disable ASLR (sudo sysctl kernel.randomize_va_space=0)
  • Compile openssl (version 101e) with configure -d shared to keep debugging symbols
  • Link a program to the above mentioned version of openssl (I made sure of that using info sharedlibrary in gdb)
  • Run the program in gdb and use info address Te0 (or any other table)

Result: No symbol "Te0" in current context.

The same doesn't happen for, e.g., the function private_AES_set_encrypt_key (also in aes_core.c). In fact the result, in this case, is: Symbol "private_AES_set_encrypt_key" is at 0x7ffff7a483f0 in a file compiled without debugging. which is exactly what I need.

My idea: these tables are declared as static const so I guess they might be optimized somehow but then again I am intentionally compiling openssl with support for debugging. So why can't I see those symbols in gdb?

Thank you in advance for your help!

Marco Chiappetta
  • 53
  • 5
  • It sounds like the symbols are being optimized out. Try building the library with `CFLAGS=-g3 -ggdb -O0`. `-g3` means maximum debugging info is available including `#define's`. With GCC 5.0, you may be able to use `-Og`. However, I've found symbols are still optimized away with `-Og`, so I use `-g3 -O0`. – jww Apr 16 '16 at 20:37

1 Answers1

1

It turns out many modern processors (e.g. Intel Core i3+) implement AES in hardware which leaves aes_core.c (and any other AES related C file) out of the compilation. To solve the problem openssl must be compiled with the ./configure flag no-hw. Also the flag no-asm might be useful (although I think the tables would still be loaded in memory).

This way I was finally able to see the address using gdb. :)

Marco Chiappetta
  • 53
  • 5