Are C++ include files a security breach when supplying a library to 3rd parties?

Question

I am not a C++ expert, I actually prefer C and I am not at the forefront of technology, but I have occasionally provided some scientific software to 3rd parties in the form of libraries. I know that relying on compilation isn't a great way to protect my proprietary interests but I have always trusted my "clients".

It has occurred to me however that a "malicious" third party might abuse my software by editing my include files; changing private: class members to public: is a particular worry.

Are my fears unfounded, if they are not is there a solution, maybe a way to pre-compile headers?

PS I am aware of the pimpl idiom, but some of the people I work with are not into dynamic memory. Also c++11 hasn't reached these parts yet.

Why are you worried that someone messes up what you gave them? It's not your fault if they messed them up. — NathanOliver, Oct 28 '15 at 11:56
I guess my worries are two-fold. 1). They may compromise the system that the software is running on and 2). They may use my software in a way I can't control. — Dave, Oct 28 '15 at 12:02
@Dave, you can never control how other people use your software unless you stand behind them and watch what they do all the time. — SingerOfTheFall, Oct 28 '15 at 12:03
C++ indeed makes it easier to implement implementation hiding via the pimpl idiom. You don't need to worry that your audience isn't into dynamic memory. **They** work with a class that has perfectly normal value semantics. You wrote the class constructors and destructor, so you deal (a bit) with dynamic memory for the pimpl. — MSalters, Oct 28 '15 at 12:57
@MSalters Thanks and agreed. However some people like assurances that the heap has not been used. — Dave, Oct 28 '15 at 17:27
@Dave: I wouldn't bother with those irrational fears. "Welcome to the 21st century" would be an entirely reasonable response. — MSalters, Oct 28 '15 at 18:38

score 3 · Answer 1 · edited May 23 '17 at 11:44

I'm not sure why do you see it as a problem. If people want to mess with your code (and potentially break their own code this way), why not? I would understand if you wanted to protect something like algorithms used in the library from being reverse-ingineered, but simply accessing private variables is not something you should fear.

After all, private does not give any real protection, you can always do tricks like

class My
{
public:
    int i()
    {
        return _i;
    }

private:
    int _i = 5;
};

struct Omg
{
public:
    int _i;
};

int main()
{
    My m;
    Omg * o = (Omg*)(&m);
    o->_i = 10;
    std::cout << m.i();
    return 0;
}

As for the pimpl, it is used in Qt, and you can use it too if you find it convenient and suitable, here is some more info.

score 1 · Accepted Answer · answered Oct 28 '15 at 12:30

1

Many times software that ships to a customer consists of client code and proprietary code. Client code is the part of the software that the customer, or client, is allowed to read and even modify. Proprietary code, on the other hand, is the code that the author of the software wants to protect and make off limits to others including customers.

To protect proprietary code you can put it into separate files and compile it into a DLL. But this is not safe because a hacker can use a decompiler on that DLL and access the source code.

A more reliable method is to use encryption tools but I haven't used any to know how an encrypted file can then be compiled or converted into a library file.

At the end, the client code will link to and call the proprietary code. So whether or not to protect is an early decision that will affect profoundly the whole design of the software.

answered Oct 28 '15 at 12:30

dspfnder

1,049
1
8
12

2

The general division between public headers and effectively obfuscated implementation in library objects is a great point for this question. Regarding *"a hacker can use a decompiler on that DLL and access the source code"* though - no such decompiler exists for C++, but they can disassemble the code to assembly language, or trace through it at that level in a debugger. – Tony Delroy Oct 28 '15 at 12:33
@Tony D. I think this answer gets closest to clarifying my concerns. I think that the obfuscation of library objects is sufficient for my needs. I think my humble offerings are unlikely to attract the attention of somebody with the means to apply a decompiler or disassembler. The include files however are easily edited and may allow a relatively unsophisticated user to access my "private" methods. – Dave Oct 28 '15 at 17:21

score 0 · Answer 3 · answered Oct 28 '15 at 23:38

You can use pure interfaces or the "pimpl idiom" to keep internal details of your classes less accessible to consumers of your SDK. Ultimately, they have the compiled code and can disassemble that and do whatever, but if you want your distributed include files to be less susceptible to misuse by SDK clients, then pure interfaces or pimpl idiom on concrete classes can hide those details from the published headers.

Are C++ include files a security breach when supplying a library to 3rd parties?

3 Answers3