Hello, my name is Dave Boone.
Let's delve into the intriguing realm of symbols and stripped binaries in high level source code such
as C code.
We encounter functions and variables with meaningful, human readable names during the compilation process.
Compilers generate symbols which serve as references to keep track of these symbols symbolic names.
So symbols record the correspondence between binary code data and each symbols meaning.
For instance, function symbols provide vital information by mapping high level function names to their
respective addresses and sizes.
This information proves invaluable to the linker when combining object files, resolving functions and
variables, references between modules and aiding in the debugging process.
And here.
Uh, to give you an idea of what symbolic information looks like here, we're going to do red elf s
y m.
S a dot out here.
And this is this is how symbolic information looks like.
So here we used red elf, red elf tool to display the symbols, and you will return to using this red
utility in next lectures and interpreting all its output.
For now, just to keep in mind, among many unfamiliar symbols, there is a symbol for the main function
here.
It should be somewhere.
Main symbol for main function.
My FC abs and it should be 32 object.
And here we're going to write this type is going to has to be function.
It should be global.
Function global.
Here.
And here yes, the sizes 37 type is function global and default and the index is 15.
Here the name is Main.
So here you can see that it specifies this address here.
All right at which Main will reside when the binary is loaded into memory.
So the output also shows the size of Main.
In this case it's 37 bytes and indicates that you are dealing with a function symbol.
And here we have this type function here and the symbolic information can be emitted as part of the
binary itself, as you witnessed earlier, or it can be generated separately in the form of a symbol
file.
So a symbolic information comes in various flavors, ranging from basic symbols required by the linker
to more extensive debugging symbols.
So debugging symbols provide a comprehensive mapping between the source code lines and corresponding
minor level instructions so they go beyond simple address mappings and even describe function parameters,
stack frame information and more.
For elf binaries, elf binaries debugging symbols are typically generated in a dwarf format, while
p binaries like Windows binaries usually use the proprietary Microsoft Portable debugging PDB format,
so the information is usually embedded within the binary, while the PDB comes in the form of a separate
symbol file here.
And symbolic information plays a crucial role in binary analysis.
So, for example, having a well defined set of function symbols greatly simplifies the disassembly
process.
So each function symbol serves as a starting point, ensuring accurate disassembly and minimizing the
risk of mistakenly disassembling data as code, which which would result in incorrect instructions in
the disassembly output.
Understanding which parts of a binary belong to a specific functions and knowing their name facilities
comprehension for human reverse engineers.
It allows them to compartmentalize and comprehend the code's purpose.
Even basic linker symbols, though less extensive than debugging information, provide significant assistance
in numerous binary analysis applications, and to parse symbols, you can utilize tools like Read Elf.
Like we use this here in this lecture as I mentioned.
Or you can also employ libraries such as Lib.
Lib feet here, I think.
Yeah.
Lib feet here, which is this is a separate library that we will use um, in two sections later.
And additionally there are symbolized libraries like Lib Dwarf, like lib dwarf, and specifically designed
for parsing dwarf debug symbols.
However, in this course we will not extensively cover these libraries, but basically we will make
this tutorial for this library.
So regrettably, extensive debugging information is typically excluded from production ready binaries.
In fact, even basic symbolic information is often stripped away to reduce file sizes and hinder reverse
engineering, particularly in the case of a malware or proprietary software.
This means that as a binary analyst, you frequently encounter the more challenging scenario of stripped
binaries devoid of any single symbolic information.
So throughout this course, I take into considerations the absence of symbolic information and focus
on analyzing stripped binaries except when explicitly noted otherwise.
So this approach prepares you for real world scenarios where you may have to tackle the complexities
of reverse engineering without the aid of symbols.
And I'm meeting you in the next lecture.