Re: [Boost-users] Fwd: [MPL] How can I make this occupy less space on disk?

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 wrote:

On Tue, May 17, 2011 at 1:15 PM, Dominique Devienne 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 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