4

I found out that there are symbols with binding=LOCAL and visibility=HIDDEN in the symbol table (.symtab) of ELF executables/libraries. What are they needed for? They are not involved in the relocation process nor can be invoked externally. Are they included in the symbol table for exception handling?

5

Symbol Binding and Symbol Visibility

What are they needed for?

There must be a way for the link editor (ld) to determine the scope of a symbol during link-time. In other words, symbol binding allows the link editor to differentiate between symbols visible only within a particular file being linked (local scope) vs. symbols that can be referenced from within functions located in other files (global scope).

Symbol visibility attributes (default, protected, hidden or internal) have special meaning for the runtime- (dynamic) linker (ld-linux.so.*), telling it which symbols in the symbol table are used by the executable internally vs. which symbols may be used by other executables dynamically linked to it at program runtime.

From Why symbol visibility is good:

ELF has two related concepts for managing symbols in your programs. The first concept is the symbol binding. Global binding means the symbol is visible outside the file being built; local binding is the opposite and keeps the symbol local only (static) and weak is like global, but suggests that the symbol can be overridden.

This is all well and good, but starts breaking down when you want to load many different modules and keep strict API's (such as, say, dynamic libraries!).

Binding attributes are useful for the linker putting together object files; but aren't a complete solution.

To combat this, ELF provides for visibility attributes. Symbols can be default, protected, hidden or internal. Using these attributes, we can flag extra information for the dynamic loader so it can know which symbols are for public consumption, and which are for internal use only.

The most logical way to use this is to make all symbols by default hidden with -fvisibility=hidden and then "punch holes in the wall" for those symbols you want visible.

Symbols and Relocation

They are not involved in the relocation process

This is false.

From the System V ABI Edition 4.1 (generic), Chapter 4: Object Files, Relocation:

Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution.

From the Oracle Linker and Libraries Guide, Part I: Using the Link-Editor and Runtime Linker, Section 2: Link Editor Symbol Processing:

During input file processing, all local symbols from the input relocatable objects are passed through to the output file image. All global symbols from the input relocatable objects, together with globals symbols from shared object dependencies, are accumulated internally within the link-editor.

Symbols and Program Runtime

nor can they be invoked externally

Symbols are never invoked during program runtime. During runtime the instruction pointer in the CPU jumps to the memory addresses in virtual memory of instructions located at offsets calculated by the link-editor (relocation). If symbols were relevant during runtime the symbol table could not be removed (stripped) from executable binaries.

  • 1
    This is a really bad ass answer. Love the links. – Evan Carroll Oct 2 '18 at 0:24
  • @EvanCarroll thank you, I am glad you found it useful. – julian Oct 2 '18 at 0:28
  • I like most of your stuff @SYS_V. Your contributions on [re.se] are frequently above and beyond the call of duty. Keep up the good work, you've got at least one fan on the interwebs. – Evan Carroll Oct 2 '18 at 0:31
  • @EvanCarroll much appreciated. I look forward to reading your CTF writeups in which you use r2 – julian Oct 2 '18 at 0:35
  • I got a lot of learning do. It's been humbling and consuming moving to this level. But it's really cool being in the communities with all the big shots. You do anything with Reverse Engineering, and names like MegaBeet, SYS_V, Peter Cordes, and Stephen Kitt are the names the seem to monopolize much of Google and what I'm looking for. – Evan Carroll Oct 2 '18 at 0:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.