C++ shared library shows internal symbols

3
votes

I have built a shared library (.dll, .so) with VC++2008 and GCC. The problem is that inside both libs it shows the names of private symbols (classes, functions) and they weren't exported.

I don't want my app to display the name of classes/functions that weren't exported. Is any way i can do that?

In GCC i did: Compiled with -fvisibility=hidden and then made public with attribute ((visibility("default")))

In VC++: __declspec(dllexport)

Thanks!

3
c++linkershared-libraries
Unless you are in the habit of naming methods things like TheClientIsAPinhead(), I don't really see what your problem is. – T.E.D.
You have a point there but I'm paranoid and don't want others to check the structure of the program in terms of classes and functions. Just want a shared library that only has the symbols that where exported. – AllDayCpp
What do you mean when you say "it shows"? What is "it"? – Rob Kennedy
In the contents of the .dll or .so it shows the names of most of the classes and functions. – AllDayCpp
Are you saying that, for the VC build for example, classes that you didn't __declspec(dllexport) were still being exported? How exactly are you checking that they are being exported - Dependency Walker? – jon-hanson

3 Answers

1
votes

For GNU tool chains you can use th strip command to remove symbols from object files. It takes various command options to control its behavior. It may do what you want.

1
votes

You can create a header file to obfuscate the internal function and method names you want to be hidden. Ie something like below (need some include guard too)

#define someFunctionName1 sJkahe28273jwknd
#define someFunctionName2 lSKlajdwe98
#define someMethodName1   ksdKLJLKJl22fss
#define someMethodName2   lsk89hHHuhu7g

...and include this in the header files where the real definitions live.

0
votes

The private keyword when used for access specification only effectively works at compile time and is intended as an aid to programmers, not a security feature - as you have found out the "privacy" is implemented using lexical means .

It's easy to see that this must be so - if you implement two private functions with dependencies between each other in two separate .cpp files, the linker has to find the private names in the resulting object (or library) files.

Bottom line - C++ has no code security features - if you give someone the object code of your program, they will always be able to examine it.