Hajo, thanks for the great suggestions. Regards, Albert
On Tuesday, March 12, 2013 8:27:55 PM UTC-4, Hajo Nils Krabbenhöft wrote: > > 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.
