How does debug assembly facilitate reverse engineering?

Question

Some answer here states that debugging information will simplify reverse engineering software. When I use Visual C ++ and distribute an executable file with debugging information, but without other files (.pdb), will it contain any interesting things?

I looked at the executable file with a hex editor and did not find anything like symbol names, since now I assume that the .exe file simply refers to the information in the .pdb files, right?

Do you know what it contains

• variable names?
• function / member names?
• line numbers?
• something interesting?

Answer 1

Debug builds tend to generate output that can easily be matched to high-level language constructs. You can identify variables, tests, loops, etc. just by looking at the machine code. You will not get variable names, but this usually refers to the least important considerations when reverse engineering.

The optimized code, OTOH, reorders instructions, expands loops, repeats the use of slots for several variables, divides code blocks between functions, built-in small functions, etc., which makes it difficult to determine the initial intention. It also makes debugging difficult, even if you own the code, as the current line marker is often misleading, and variables tend to disappear or show random crap.

All this makes reverse engineering impossible. It is just more effort to tease the point.

Answer 2

Building with debugging information is not a "debugging assembly."

"Debug build" is such an assembly when the _DEBUG symbol is defined. If so, there are many lines useful for reverse engineers (approves, etc.).

So, you can build Release with debugging information in .pbd, and decompiling the program will be as difficult as without debugging the information.

Answer 3

The executable file must not contain variable names or line numbers. It may contain function / member names for any such names that are exported (more likely for lib / dll than exe).

The structure of the code will be "closer" to the original source code - it is unlikely that the code was embedded, had overridden statements, expanded loops, etc.

Answer 4

A long time ago, debugging information was attached to an executable file (in the so-called CodeView format). These days it is mostly shipped separately in PDB files. Exe itself really only includes a link to the PDB.

PDBs usually come in two versions: private and public (it is also divided). Public (for example, provided by Microsoft) usually have only the names of functions and global variables. Private ones (for example, those created when creating your application with debugging information) may additionally include type information (structures, enumerations, classes, variable types), function prototypes, names and types of local variables, and information about the line number.

If you want to test your PDBs, check out the DIA2Dump in the "DIA SDK" folder in your Visual Studio installation.

Answer 5

Optimization makes code easier to understand (and also makes correlation between source and assembly more difficult when debugging your own code with characters and sources).

The debug build does not include line numbers, function names, and line numbers; they relate to the PDB. However, every time you use assert (), the code will contain a line containing file names and line numbers.