3

Some days ago I accidentally opened a C++ executable of a commercial application in Notepad++ and found out that there's quite a lot information about the original source code stored in the executable.

Inside the executable I could find file names (app.c, dlgstat.c, ...), function names (GetTickCount, DispatchMessageA, ...) and small pieces of source code, mostly conditions (szChar != TEXT('\0'), iRow < XTGetRows( hwndList )). After that I checked another QT executable and: yes again source file names and method signatures.

Because of that I am wondering how much source code information is really stored in a C/C++ executable (e.g., compiled using QT or MinGW). Is this probably some kind of debug build still containing the original source? Is this information used for some reflection stuff? Is there any reason why publishers don't remove this stuff?

Improve this question
6
  • 6
    The conditions are probably string literals from the assert macro (and a build that doesn't define NDEBUG). Commented Sep 26, 2012 at 22:06
  • A lot of stuff is included if you compile with the debugging information (ie. '-g' if you're an old timer) but not if you turn off debugging information and optimize (ie. '-O3'). Commented Sep 26, 2012 at 22:07
  • It was probably compiled with debug symbols stored in it. Or perhaps as @R.MartinhoFernandes suggested. Commented Sep 26, 2012 at 22:08
  • @PaulTomblin: notice that -g and -O3 are more or less orthogonal concepts: you can have unoptimized binaries without debugging informations, as well as optimized binaries with debugging information (although the information for line-by-line debugging will be less accurate). Commented Sep 26, 2012 at 22:22
  • That's true now. I'm pretty sure that in the old pcc (Portable C Compiler) you couldn't mix them. And if you try to debug an object that's been compiled with -O3 you're going to have a really bad time. Lines will be re-arranged, loops unrolled, variables eliminated - good luck trying to match up the code being executed with the line number displayed in the debugger. Commented Sep 26, 2012 at 22:25

3 Answers 3

Reset to default
11

How much source code information is really stored in a C/C++ executable?

In practice, not much. The source code is not required at runtime. The strings you name come from two things:

  • The function names (e.g. GetTickCount) are the names of functions imported from other modules. The names are required at runtime because the functions are resolved dynamically (by calling GetProcAddress with the function name).

  • The conditions are likely assertions: the assert macro stringizes its argument so that when it fires you know what condition was not met.

If you build a DLL, it will also contain a names of all of the functions it exports, so they can be resolved at runtime (the same is likely true for other shared object formats).

Debug symbols may also contain some of the original source code, though it depends on the format used by the debug symbols. These symbols may be contained either in the binary itself or in an auxiliary file (for example, .pdb files used on Windows).

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks, that makes sense. I think the parts I've found are definitely asserts, they are all conditional expressions. I guess the asserts also ensure the path to the source file is packed into the binary.
2

Windows function names: they probably are there just because they are being accessed dynamically - somewhere in your program there's a GetProcAddress to get their address. Still, no reason to worry, every application uses WinAPIs, so there's not much to discover about your executable from that information.

Conditions: probably from some assert-like macro; they are included to allow assert to print what failed condition triggered the failed assertion. Anyhow, in release mode assertions should be removed automatically.

Source file names and method signatures: probably from some usage of __FILE__ and __func__ macros; probably, again, from assert.

Other sources of information about the inner structure of your program is RTTI, that has to provide some representation for every type that typeid could be working on. If you don't need its functionality, you can disable it (but I don't know if that is possible in Qt projects).

Improve this answer

Comments

0

Mixed into the binary of a C++ app you will find the names of most global symbols (and debugging symbols if enabled in the compiler), but with extra 'decoration text' that encodes the calling signature of the symbol if it is a function or method. Likewise, the literals of character strings are embedded in clear text. But no where will you find anything like the actual source code that the compiler used to create the binary executable. That information is lost during the compilation process, and it is especially hard to reverse engineer if C++ templates are employed in the build.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.