Re: [boost] [encrypted strings]

Subject: Re: [boost] [encrypted strings]
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-04-28 02:00:07

[DISCLAIMER: this post of mine, and the recent part of the thread, is  
completely OT unless it is brought into a discussion about actual  
compile-time conversions of strings]

On Apr 28, 2009, at 1:30 AM, Raindog wrote:

> Sid Sacek wrote:
>> Does boost have any compile-time classes for string encryption? Is it
>> even possible?
>>
>>
>> When a hacker dumps an executable, they can see all of the strings  
>> the
>> program might use, and some of those strings may contain sensitive
>> information. Does boost have any classes that can encode the  
>> strings at
>> compile-time? Ideally, the third string in the code below would never
>> compile the "secret" string into the final binary.
>>
>>
>> Regards,
>>
>> -Sid
>>
>>
> Sid,
>
> I made my original suggestion based on being both a virus analyst by  
> profession and game hacker by hobby. No offense to the suggestions  
> that have been made by others on this mail list[1], but they all  
> appear to suffer the same problem in that laymen are suggesting  
> solutions that not even professionals have completely solved.

One should (i) separate obfuscating from securing, as has been  
mentioned before in this thread and indicated by you, and (ii) not  
underestimate the power of the former, when it comes to avoid less  
experienced "hackers" (kids using readily available tools, and having  
not more than double-clicking as their skill set), curious IT-savvy  
guys and the accidental potential eavesdropper - often on a public  
WiFi where an 'exe' is sent in in an e-mail (with a simplistic mail  
server setup), but (iii) not overestimate the power of the former.

So, obfuscation is a good tool for such "spurious" attacks/ 
eavesdropping. For really securing stuff? Of course not.

> I understand that you are looking for simple techniques to "thwart  
> noobs from haxxing your shizzle", but in reality, anyone unable to  
> bypass the methods suggested would be unable to bypass a plain text  
> target.

I do not agree, partly from intuition but more importantly from  
experience: simple obfuscation has made a huge difference for two of  
my products, whereof one deployed to many millions of users. I.e., a  
lot of people who could bypass a plain text target but much fewer who  
could deal with a simple obfuscation.

> Rolling your own solution has so many problems that I cannot even  
> begin to tackle them here.

I think it is easy to tackle it, and it is just one problem: it will  
be simple obfuscation, which is breakable by a good hacker, but  
*might* protect you from simple eavesdropping (Wiresharked or not -  
after all, it does not take a brain surgeon to install and run  
Wireshark :-) )

> You'll be much better off using an off the shelf protection mechanism.

Depends on the needs and integrity needs.

> If you're really itching to try your hand, look at pecompact which  
> allows you to provide your own decryption/encryption algorithm on  
> top of their packer.

I have not used it; will check it out. I have dealt extensively with  
PE compression (and obfuscation) in the form of .NET PE's the last  
year, so it could be refreshing to review PE's from a "native" angle  
again :-)

> [1]. Edouard's suggestion appears to imply that he has at least a  
> cursory introduction to the problems faced by anti-piracy/anti- 
> reverse engineering experts.

I think (hope?) most people involved in this thread, and similar  
threads, have more than a cursory knowledge of this domain, and I  
think (still hope?) that most of them have hacked a game at some point  
in their youth ;-)

/David