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 On Tuesday, March 12, 2013 9:55:20 PM UTC+1, Albert Skara wrote: > > > 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 > > > On Tuesday, March 12, 2013 1:35:48 PM UTC-4, Hajo Nils Krabbenhöft wrote: >> >> It seems Google Groups deletes my attachment, so please look at the GIST >> URL. >> >> >> On Tuesday, March 12, 2013 6:34:38 PM UTC+1, Hajo Nils Krabbenhöft wrote: >>> >>> 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 >>> >>> -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
