How does a debug build make reverse engineering easy?

Some answer here stated that debug info would make it easier to reverse engineer the software. When I use Visual C++ and distribute an executable with debugging information but with开发者_运维技巧out other files (.pdb), will it contain any interesting things?

I looked to the executable with a hex editor and found nothing like symbol names, for now I assume the .exe file just links to information in the .pdb files, right?

Do you know whether it contains

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

Debug builds tend to generate output that can easily be correlated with high-level language constructs. You can identify variables, tests, loops, etc., just by looking at the machine code. You won't get names of variables, but that's usually among the least important considerations when reverse-engineering.

Optimised code, OTOH, rearranges instructions, unfolds loops, reuses slots for multiple variables, shares blocks of code between functions, inlines small functions and so on, making it quite a bit more difficult to discern the original intent. It also makes it more difficult to debug, even if you own the code, since the current line marker is often very misleading, and variables tend to disappear or show random crap.

None of this makes reverse-engineering impossible, though. It's just more work to tease out the meaning.

Build with debugging information isn't "debug build".

"Debug build" is such build when _DEBUG symbol is defined. If so, there are lots of strings useful for reverse-engineer (asserts, etc).

So you can make Release build with debugging information in .pbd, and to decompile the program will be as hard as without debugging information.

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

The structure of the code will "more closely" resemble the original source code - it's unlikely that code will have been inlined, had statements re-ordered, had loops unrolled, etc.

Optimizations make code harder to understand (and also make it harder to correlate between the source and the assembly when debugging your own code with symbols and sources).

A debug build does not include line numbers, function names, nor line numbers, these belong to the PDB. However, every time you use assert() the code will include a string that contains file names and line numbers.

Long time ago the debug information was attached to the executable (in so-called CodeView format). These days it mostly comes separately in PDB files. The exe itself indeed only includes a link to the PDB.

PDBs usually come in two flavors: private and public (aka stripped). Public (e.g. those provided by Microsoft) usually have only names of the functions and global variables. Private ones (e.g. the ones produced when you build your app with debug info) can additionally include type information (structures, enums, classes, types of variables) function prototypes, local variable names and types and line number info.

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