Fwd: [MPL] How can I make this occupy less space on disk?
Hello, I'm using Boost.MPL to obfuscate sensitive strings during compilation. I wrote a class called obf_string which can be used in the following way: obf_string<'my_d','atab','ase_','pass','word'> password; connect_to_db( password.unobfuscate() ); If someone runs strings.exe on this executable, they will not see "my_database_password" listed there, because it has been XORed with a binary mask. This approach has several benefits over e.g. preprocessing all the source files with a tool that encrypts all strings. The most significant is that I can easily see and change the string. The problem is that my implementation of obf_string is occupying too much space on disk. I have devised a test to compare it with a normal std::string. The test files, which are attached (test_stdstring.cpp and test_obfstring.cpp), contain 50 different strings each. In one file they are used to construct std::strings, in the other one they are obfuscated through obf_string. On average, each new std::string added 188 bytes, while each obf_string occupied 690 bytes. Here's a plot that shows the difference: http://img59.imageshack.us/img59/6417/obfstring.png. Everything was compiled on VC++10 with /O1 (minimize size). I'm using Boost 1.46.1. I would like to understand why obf_strings take up so much space, and figure out ways I can minimize this. This is really important to me - our application currently instantiates obf_string over 600 times, so the overhead is starting to add up. Naturally, I have also attached the full source code of obf_string. Any help would be greatly appreciated! Thanks, Pedro d'Aquino
On Tue, May 17, 2011 at 10:52 AM, Pedro d'Aquino <pedro.daquino@gmail.com> wrote:
I'm using Boost.MPL to obfuscate sensitive strings during compilation. I wrote a class called obf_string which can be used in the following way:
obf_string<'my_d','atab','ase_','pass','word'> password;
If someone runs strings.exe on this executable, they will not see "my_database_password" listed there, because it has been XORed with a binary mask.
[Slightly OT] Out of curiosity, isn't there some remnant of the obf_string<'my_d','atab','ase_','pass','word'> instantiated template in the type system that's visible via demangling the generated binaries, for example via nm or depends.exe? --DD
On Tue, May 17, 2011 at 1:15 PM, Dominique Devienne <ddevienne@gmail.com> wrote:
[Slightly OT] Out of curiosity, isn't there some remnant of the obf_string<'my_d','atab','ase_','pass','word'> instantiated template in the type system that's visible via demangling the generated binaries, for example via nm or depends.exe? --DD
I couldn't find any. Usually this kind of stuff is also visible in a strings dump. For instance, running Sysinternals' strings.exe on test_obfstring.exe uncovers things as ".?AV?$basic_ostream@DU?$char_traits@D@std@@@std@@", but no mention of obf_string. On Tue, May 17, 2011 at 1:17 PM, Ian Bruntlett <ian.bruntlett@gmail.com> wrote:
Hi Pedro,
I don't know if this applies to you but... any halfway decent assembly language programmer with operating system expertise will be able to set a breakpoint for relevant O.S. or library calls. In Linux its even easier - use the strace command and it lists OS calls to stdout.
One place I worked at used the Windows registry to store ODBC and SQL parameters.
I am aware that my obfuscation system is quite breakable. There is, naturally, no good solution for this kind of problem - at the end of the day it's a matter of setting a breakpoint on the right spot. But I believe this does set the bar a bit higher. Anyway, there are no real critical data here, just stuff that would help someone reverse engineer our product (because we're in the security industry, that's something we try to defend against). Any thoughts on the size issue? :) _________________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I've done some more digging up and found out that using boost::mpl::for_each adds a staggering 134kb to my DLL (or 25%). Is there any way of accomplishing what I'm doing without using for_each? Or any tips on how to reduce the bloat? On Tue, May 17, 2011 at 2:02 PM, Pedro d'Aquino <pedro.daquino@gmail.com> wrote:
On Tue, May 17, 2011 at 1:15 PM, Dominique Devienne <ddevienne@gmail.com> wrote:
[Slightly OT] Out of curiosity, isn't there some remnant of the obf_string<'my_d','atab','ase_','pass','word'> instantiated template in the type system that's visible via demangling the generated binaries, for example via nm or depends.exe? --DD
I couldn't find any. Usually this kind of stuff is also visible in a strings dump. For instance, running Sysinternals' strings.exe on test_obfstring.exe uncovers things as ".?AV?$basic_ostream@DU?$char_traits@D@std@@@std@@", but no mention of obf_string.
On Tue, May 17, 2011 at 1:17 PM, Ian Bruntlett <ian.bruntlett@gmail.com> wrote:
Hi Pedro,
I don't know if this applies to you but... any halfway decent assembly language programmer with operating system expertise will be able to set a breakpoint for relevant O.S. or library calls. In Linux its even easier - use the strace command and it lists OS calls to stdout.
One place I worked at used the Windows registry to store ODBC and SQL parameters.
I am aware that my obfuscation system is quite breakable. There is, naturally, no good solution for this kind of problem - at the end of the day it's a matter of setting a breakpoint on the right spot. But I believe this does set the bar a bit higher. Anyway, there are no real critical data here, just stuff that would help someone reverse engineer our product (because we're in the security industry, that's something we try to defend against).
Any thoughts on the size issue? :)
_________________________________________
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Pedro, On 17 May 2011 16:52, Pedro d'Aquino <pedro.daquino@gmail.com> wrote:
Hello,
I'm using Boost.MPL to obfuscate sensitive strings during compilation. I wrote a class called obf_string which can be used in the following way:
obf_string<'my_d','atab','ase_','pass','word'> password; connect_to_db( password.unobfuscate() );
If someone runs strings.exe on this executable, they will not see "my_database_password" listed there, because it has been XORed with a binary mask. This approach has several benefits over e.g. preprocessing all the source files with a tool that encrypts all strings. The most significant is that I can easily see and change the string.
I don't know if this applies to you but... any halfway decent assembly language programmer with operating system expertise will be able to set a breakpoint for relevant O.S. or library calls. In Linux its even easier - use the strace command and it lists OS calls to stdout. One place I worked at used the Windows registry to store ODBC and SQL parameters. Just how hostile are you expecting the end users of your application to be? HTH, Ian -- -- ACCU - Professionalism in programming - http://www.accu.org/
participants (3)
-
Dominique Devienne -
Ian Bruntlett -
Pedro d'Aquino