What you are finding is one of the age old problems of trusted
computing. If someone has given you a requirement to protect the integrity
of a user space application, the question is against what level of effort.
Anything more then a few man days from a skilled attacker is not going to be
achievable without the OS supporting signing of applications.
I guess you could turn the application into an Application Service
Provider setup. That would make it much harder for someone to open up the
application :-).
73,
Shawn
> -----Original Message-----
> From: James Carroll [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 03, 2004 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: RE: RE: protecting the executable itself
>
>
> 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
> >
> >
