Thanks for the advise! I've tried compressing my executable with UPX. My first impression was great, but when I run my compressed application directly from a CD-ROM it can't find some of the windows resources (.rc) that are not PRELOAD.
Another software group at my company uses Crypkey SDK for copy protection, and aside from some tech support issues that come with any sucessful company, it's worked pretty well. I tried the Stealth product on my executable, and I must have to make some changes to the executable (some Crypkey SDK calls or something, which I think I have to buy another application-to-be-protected license) because the resulting Stealth-ed application immediately crashes when it's run. I also can bulid Mac and Linux version of the software, and Crypkey would only help me on windows. So my approach at the moment is just to obfuscate the executable as much as I can, and call the different security checks from several seemingly random places, and make it so that several different places would have to be cracked before the application is completely compromised. I say obfuscate the executable, because what my co-worker did to crack the application is search for the error message that I show when the security check fails, then search for the address of the message, find where the MessageBox is that references that address, then find the previous jne and make it a je. If I encode the error messages (as hex or something non-text) then I'll be making life just a little harder for a cracker. Michael and Shawn: great suggestions, but more effort (and skill) than I can manage for this tiny app. -Jim > -----Original Message----- > From: Michael Hunley [mailto:[EMAIL PROTECTED] > Sent: Monday, February 02, 2004 11:27 AM > To: [EMAIL PROTECTED] > Subject: Re: [inbox] RE: protecting the executable itself > > > At 08:37 AM 2/2/2004 -0500, you wrote: > > I did a lot of work in trusted computing in a > hostile environment a > >few years ago. So long as the person running the code can > alter the code > >you can not prevent this, period. Of course you can make it > more difficult, > >but never prevent it. Try compressing the executable with > one of the tools > >available. Also make sure you strip the executable before > sending it out. > >Anything more will probably involve OS specific alterations. > > In addition to Shawn's suggestion, why not embed core pieces > of your app, > the parts the user wants your app for, in an encrypted code > block. Inside > the encrypted code block, verify the code sig with a SHA (or > whatever) and > sprinkle this *inline* code into the algorithm, effectively > scrambling the > real code with crypt code (don't just cache the sha, make it > volatile). When the user performs an operation, he would > have to hack the > results of the decrypt each time, not just once. Possible to > automate, but > much harder. > > HTH. > michael > >
