Home/ Questions/Q 8137491
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T11:08:32+00:00

I have this habit always a C++ project is compiled and the release is

  • 0

I have this habit always a C++ project is compiled and the release is built up. I always open the .EXE with a hexadecimal editor (usually HxD) and have a look at the binary information.

What I hate most and try to find a solution for is the fact that somewhere in the string table, relevant (at least, from my point of view) information is offered. Maybe for other people this sounds like a schizophrenia obsession but I just don’t like when my executable contains, for example, the names of all the Windows functions used in the application.

I have tried many compilers to see which of them published the least information. For example, GCC leaves all this in all of its produced final exe

libgcj_s.dll._Jv_RegisterClasses....\Data.ald.rb.Error.Data file is corrupt!
....Data for the application not found!.€.@.ř.@.0.@.€.@.°.@.p.@.p.@.p.@.p.@.
¸.@.$.@.€.@°.@.std::bad_alloc..__gnu_cxx::__concurrence_lock_error.__gnu_cxx
::__concurrence_unlock_error...std::exception.std::bad_exception...pure virt
ual method called..../../runtime/pseudo-reloc.c....VirtualQuery (addr, &b, s
ize of(b))............................/../../../gcc-4.4.1/libgcc/../gcc/conf    
ig/i386/cygming-shared-data.c...0 && "Couldn't retrieve name of GCClib share
d data atom"....ret->size == sizeof(__cygming_shared) && "GCClib shared data
 size mismatch".0 && "Couldn't add GCClib shared data atom".....-GCCLIBCYGMI
NG-EH-TDM1-SJLJ-GTHR-MINGW32........

Here, you can see what compiler I used, and what version. Now, a few lines below you can see a list with every Windows function I used, like CreateMainWindow, GetCurrentThreadId, etc.

I wonder if there are ways of not displaying this, or encrypting, obfuscating it.

With Visual C++ this information is not published. Instead, it is not so cross-platform as GCC, which even between two Windows systems like 7 and XP, doesn’t need C++ run-time, frameworks or whatever programs compiled with VC++ need. Moreover, the VC++ executables also contain those procedures entry points to the Windows functions used in the application.

I know that even NASM, for example, saves the name of the called Windows functions, so it looks like it’s a Windows issue. But maybe they can be encrypted or there’s some trick to not show them.

I will have a look over the GCC source code to see where are those strings specified to be saved in the executables – maybe that instruction can be skipped or something.

Well, this is one of my last paranoia and maybe it can be treated some way. Thanks for your opinions and answers.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Windows API functions are loaded from dlls, like kernel32.dll. In order to get the loaded API function’s memory address, a table of exported function names from the dll is searched. Thus the presence of these names.

    You could manually load any Windows API functions you reference with LoadLibrary. The you could look up the functions’ addresses with GetProcAddress and functions names stored in some obfuscated form. Alternately, you could use each function’s “ordinal” — a numeric value that identifies each function in a dll). This way, you could create a set of function pointers that you will use to call API functions.

    But, to really make it clean, you would probably have to turn off linking of default libraries and replace components of the C Runtime library that are implicitly used by the compiler. Doing this is a hasslse, though.

    • 0