How to encript header files.

[Haro Panosyan]

My appologies, this is not directly C/C++ related.

I have a C++ library, which is going to be shipped
as compiled library, but the header files are going
to be as source code, so people can include them for
API access.

Are there any tools to encript C++ header files?

-haro

 

[Victor Bazarov]

I have a C++ library, which is going to be shipped
as compiled library, but the header files are going
to be as source code, so people can include them for
API access.

Are there any tools to encript C++ header files?

What for?

 

[Howard]

My appologies, this is not directly C/C++ related.

I have a C++ library, which is going to be shipped
as compiled library, but the header files are going
to be as source code, so people can include them for
API access.

Are there any tools to encript C++ header files?

-haro

If the header files are encrypted, how would anyone use them? There are
many tools available to encrypt files, but I know of no compiler that has
such tools. Why do you want to hide the contents of header files? As long
as you're not supplying the implementation (.cpp) files, and as long as the
implementation code isn't in the headers, you're not exposing the internal
workings of your software, just the interfaces, which the users need anyway
in order to know *how* to call your API.

-Howard

 

[Haro Panosyan]

Howard and Victor,
Thanks for you notes.

Two main reasons:
1.My header files contain lots of implementation as inline functions.
2.The interface header files with ton's of comments could lead open ideas.

Howard,

If the header files are encrypted, how would anyone use them?

I have heard there are some tools to "encrypt" header files, so they
still stay as header files, but not readable.

-haro

 

[Chris Jefferson]

My appologies, this is not directly C/C++ related.

I have a C++ library, which is going to be shipped
as compiled library, but the header files are going
to be as source code, so people can include them for
API access.

Are there any tools to encript C++ header files?

A while ago someone asked me to try doing this for their project. While
it is possible to somewhat complicate the headers, it's not really
possible to obfuscate them that much without harming performance. It's
really much easier, and will make you many more friends in the long run,
to just distribute clean headers (in particular, if you ship a debugging
version of your library, then the source code will be mostly visable
anyway, and lots of people won't use libraries without a debuggin
version, myself included)

Chris

 

[Victor Bazarov]

Howard and Victor,
Thanks for you notes.

Two main reasons:
1.My header files contain lots of implementation as inline functions.

If that's how you intended it to be used, that's how it has to stay.

2.The interface header files with ton's of comments could lead open ideas.

Remove the comments. Change the variable names to something short and/or
without meaning. There are tools that can help you obfuscate code. Do
a search for "C++ obfuscator".

Howard,


I have heard there are some tools to "encrypt" header files, so they
still stay as header files, but not readable.

Not encrypt. Obfuscate. They are definitely not usable if the compiler
cannot read them. Besides, where did you hear that?

V

P.S. Please don't top-post.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

1.My header files contain lots of implementation as inline functions.

- Doctor, it hurts when I do that.
- Dont' do it.

 

[Haro Panosyan]

Thank you all,

I will look for "C++ obfuscator" or otherwise I will
make header files more cleaner.

-haro

 

[vivekiyer]

Well I have a suggestion. Why don't you define an class with only pure
virtual functions (Lets call it interfaceA for simplicity sake). Now in
this class place all the function you would like to export and make
sure that they are pure virtual. Now change the header file that you
currently have (the one which you do not want to send to your client)
and derive the class in this header from interfaceA. Now this way you
need not send your header file to your client since all your client
needs to see is the header containing interfaceA. Also the amount of
code you need to change is minimal. Hope this helps

 

[Siemel Naran]

Well I have a suggestion. Why don't you define an class with only pure
virtual functions (Lets call it interfaceA for simplicity sake). Now in
this class place all the function you would like to export and make
sure that they are pure virtual. Now change the header file that you
currently have (the one which you do not want to send to your client)
and derive the class in this header from interfaceA. Now this way you
need not send your header file to your client since all your client
needs to see is the header containing interfaceA. Also the amount of
code you need to change is minimal. Hope this helps

But that would make the functions non-inline, which seems to be what the OP
wants to avoid (inline for performance reasons I guess). However, if the
functions are complex enough that exposing them exposes the implementation
details of your algorithms, then I guess they're probably non-trivial
functions and should not be inline anyway. Therefore I like this
suggestion, though it does not have to be an abstract base class with pure
virtual functions, but rather any class with non-inline functions.

Also, off topic but worth mentioning: if the algorithms are that complex,
then consider getting patents on them.

 

[Elias Pouloyiannis]

You can allways use the pimpl idiom to seperate the public interface
from the underlying implementation.

 

[Ira Baxter]

You want an obfuscator. See
http://www.semdesigns.com/Products/Obfuscators/CppObfuscator.html
This will let you obfuscate the non-public part of your header files.

A while ago someone asked me to try doing this for their project. While
it is possible to somewhat complicate the headers, it's not really
possible to obfuscate them that much without harming performance.

An obfuscator that simply scrambles symbol names
has no effect on performance.

It's really much easier, and will make you many more friends in the long run,
to just distribute clean headers (in particular, if you ship a debugging
version of your library, then the source code will be mostly visable
anyway, and lots of people won't use libraries without a debuggin
version, myself included)

If you are only going to offer "public" APIs, and you gave those
definitions good names, and leave those names un-obfuscated
(our tool will help you do this),
you'll have as many friends after obfuscation as before,
if they aren't interested in stepping into your code,
because they will be able to see all the names of interest
to them.