How to compile Crypto++ 5.6.0 without RTTI (= with fake RTTI using templates)

[Hajo Nils Krabbenhöft]

Hi guys,

and first off, thanks for the great Crypto++ library. 

We had a client requirement to do encryption but were not allowed to use RTTI because our client fears that the RTTI information will make reverse engineering of the product easier. To make this work, I used a template function to replace typeid() and then created explicit instantiations for all needed types. Compiled with my fake RTTI, Crypto++ passes all tests. In case that matters, I'm using the Intel Compiler and Crypto++ 5.6.0. 

Here's the steps I took and the resulting source code:

https://gist.github.com/fxtentacle/5145014

(and attached as markdown)

Cheers, 

Hajo Nils Krabbenhöft

[Hajo Nils Krabbenhöft]

It seems Google Groups deletes my attachment, so please look at the GIST URL.

[Albert Skara]

Interesting approach. I also ran into the RTTI issue, for the same reason (attempting to implement a modest amount of protection). In Crypto++ 5.6.2, I found a single occurrence of a dynamic_cast, in the StreamTransformationFilter constructor. It turns out that my code does not use that, so I just put a guard statement in there and built the static library with /GR-. While the RTTI data is now gone, there are still plenty of occurrences of "CryptoPP" and of obviously crypto++-related error messages in strings inside the executable. I'm now considering whether it's worth doing something about those, such as replacing them with meaningless important-sounding text. Any recommendations? Your client did not seem to mind those apparently...

Albert

[Hajo Nils Krabbenhöft]

I think the /GR- option works only in the Microsoft compiler, and we needed cross-platform (Linux, Mac, Win) so i had to make it work on GCC and Intel Compiler.

We're producing a shared library which includes CryptoPP for data protection as well as the secret algorithms to work on the data. Enabling RTTI would cause the compiler to include type information for all the classes in our shared library, thereby greatly facilitating the process of reverse engineering our secret algorithms. Hex-Rays (C decompiler) has a presentation about that:

http://www.hexblog.com/wp-content/uploads/2011/08/Recon-2011-Skochinsky.pdf

Since we are not trying to hide the fact that we are using Crypto++, there is no problem with having strings inside the binary. We just wanted to make reverse engineering of the stuff that is included besides Crypto++ as hard as possible.

If you want to get really creative with hiding the fact that you are using Crypto++, you can use DUMPBIN (win) or NM (mac/linux) to collect a list of all class and function names and then put a prefix header inside cryptlib.h to #define those class names to random identifiers. That way, even the linked library will not export any symbol with a usable name :) but in your source code, you can just include your header file and use the normal Crypto++ names.

For strings, you could also use dumpbin/nm to collect all of them and then replace them with string constants. We've used something like this before:

In the source code: "Hello World %s" is replaced with csHelloWorld_s (= "cs" + string in CamelCase )

We then used sed to create a #define map where every string is just numbered, e.g.:

#ifdef _DEBUG

#define csHelloWorld_s "Hello World %s"

#else

#define csHelloWorld_s "0001: %s"

#endif

That way, all your release errors and exceptions will consist only of numbers, which are meaningless to any hacker, but you can easily look up which number corresponds to which string constant and find the locations where they are being used. Since you seem to work with Windows, I can also wholeheartedly recommend symserver and procdump. That way you can get good stack traces (and view them with source in Visual Studio) even if your users only have stripped and debug-less release binaries.

However, for our current project i think just keeping the .SO and .DLL safe from HexRays and IDA Pro will be enough. As I said, the secret part are the algorithms and not the fact that we use Crypto++ for authentication.

Regards,

Hajo Nils Krabbenhöft

[Albert Skara]

Hajo, thanks for the great suggestions.

Regards,

Albert

[Mohammed Abuhendi]

Hajo, Thank you very much, I also need to compile crypto++ with RTTI switched off, I tried your procedure, but something seems to be going wrong using MS VC compiler!
i'm getting compile time error! (on the Blue line).

class HajoMkType : public std::type_info {

public:

   inline HajoMkType(const char* name) : std::type_info(name) {} <= "error C2664: 'type_info::type_info' : cannot convert parameter 1 from 'const char *' to 'const type_info &'" 

   inline virtual ~HajoMkType() {}

};

Is there anything I can do, to fix it?