Hi Guys,
Is it possbile to place 'defines / macros' inside a .lib file to hide the definitions from people?
Thanks in advance :)
Keeping code from prying eyes
I think there are two basic approaches you can use consistently to achieve this.
Approach 1. If you are ok with using extern variables, then you can simply declare them in the header file and define their value once in some cpp file. These are usually better for debugging than defines.
Approach 2. If you must have your macros/defines as preprocessor directives, you can create two sets of header files. A set of "Private" header files that are only used during your library compilation but not available to external SDK users. This is tricky and requires more work but it works.
Is it possible? There are code obfuscators out there that rename things. For languages like JavaScript this can even be less about obscurity and more about minimizing data transfers. Exactly how well the systems work at keeping things hidden depends on the language.
There usually is very little need to obscure. Anyone who has the skill sets necessary to reverse engineer your program will also have the skill sets necessary to figure out any missing or obscured function names. Those who don't have the skills also probably don't have the skills to make use of the function. Either way the obfuscation is not a limiting factor.
There usually is very little need to obscure. Anyone who has the skill sets necessary to reverse engineer your program will also have the skill sets necessary to figure out any missing or obscured function names. Those who don't have the skills also probably don't have the skills to make use of the function. Either way the obfuscation is not a limiting factor.
Is it possbile to place 'defines / macros' inside a .lib file to hide the definitions from people?
No. The very definition of a macro is that it's textual replacement. If the text isn't available, the replacement can't happen.
If you want to keep code out of public headers, it has to be behind an externed function or an externed variable. e.g. not a macro, not an inlined function, not a template.
Have you considered using something like the Pimpl idiom to hide your implementations? It is a bit more complex than just creating the base functionality, but if you choose a few main classes to obscure with it, then it can be quite effective.
if you choose a few main classes to obscure with it, then it can be quite effective.
No, not more effective at all against "prying eyes". Someone who wants to reverse engineer a product can recognize and break it easily. All it does is add a trivial wrapper. Pimpl is useful to help reduce compile times, but does not add any security or obscurity. The functionality is still paired with a descriptive name, it simply has to go through an easily identified pointer first.
I think reverse engineering goes beyond the scope of the original question, but I will say that obfuscators are not as effective as one might hope they would be.
Case in point: some years ago I was lead engineer on a Java-based software product (not a game) where we used an obfuscator to protect our valuable intellectual property. We had a single client who had paid many hundreds of thousands of dollars for this piece of software and if they wanted a new feature all they needed to do would have been to ask. Even so, they apparently felt it was more cost effective to reverse engineer our code so they could insert about 10 extra instructions. Every time we sent them a new release they would have to reverse engineer the program all over again because we had configured the obfuscator to use a new random seed with every build. We finally caught them at it when they filed a bug with a stack trace that I *knew* could not possibly have been generated by our code.
It says something about how (in)effective obfuscators are when it's easier to disassemble Java bytecode than it is to send an e-mail that says "Pretty please add feature X" (when that feature would take literally two lines of code).
No, not more effective at all against "prying eyes". Someone who wants to reverse engineer a product can recognize and break it easily. All it does is add a trivial wrapper. Pimpl is useful to help reduce compile times, but does not add any security or obscurity. The functionality is still paired with a descriptive name, it simply has to go through an easily identified pointer first.if you choose a few main classes to obscure with it, then it can be quite effective.
pImpl code also costs you an extra indirection, allocation, and deallocation. If you're writing a library for distribution your customers may not be willing to pay those costs (even if you are). You should be focusing on making your library easy to use and hard to misuse - not worried about some "trade secret" that 10 other people have already figured out in their own code around the world.
In the end, as other people have stated here, if I want to see your code, I'm going to see your code. I may be pulling my hair out cause I'll be looking at optimized assembly, but I'm going to get at your algorithm anyway.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
