options to protect source code

[jender624]

Hey all,

 

Could somebody give me any resources that discuss options on how to protect source code from any efforts to reverse engineer it from the built executable? I've read about the Dotfuscator utility that comes with the visual studio 2005 beta... I'd like to learn about how to encrypt the exe, and any other techniques out there. Can anybody help me?

 

Thanks,

 

jender624

[PlausiblyDamp]

Clicky mentions some possible tools for obfuscating your application - however as the same thread also discusses is it worth the time and trouble to do so?

[jender624]

Our project manager has decided that we're going to employ some method to protect from decompilation, so the "if" question has been answered. It's the "how" that I need to figure out.

 

Thanks for the other thread reference...the Salamander Protector that was suggested looks interesting. If anything, it's something that I can throw out on the table as a reference.

 

If anybody thinks of anything else, I'd love to hear about it.

 

Thanks,

 

jender624

[jender624]

An additional question; does anybody know if it's possible or practical to first enfuscate an exe, then apply an encryption method, whether it be using something like exeshield or otherwise?

 

Thanks,

 

jender624

[neodammer]

You can obfuscate your code all day but if a person who really knows his/her assembly/binary/hex really well they can with enough time figure out how things are working at the very least.

 

Note: Like PD stated its a time question. I mean seriously you have to ask yourself would elite programmers/hackers/crackers :rolleyes: be after your program? Second would they really want the material inside for any given purpose? Usually I see firms that have apps for personaly business use paranoid about reverse engineering. CC numbers, passwords, etc.. if they are hardcoded to begin with is a flawed program. Besides all those things are usually stored server side up and with better security anyway. And unless your revolutionizing or coming up with a unique program I wouldnt worry about obfuscating anything other than the serials for the program etc.. Cause todays methods are broken very quick.

[jender624]

As I've said, the "if" question is not really applicable anymore...it's already been decided that we will be protecting our app in some way. I'm just trying to get the options. I realize that none of these options will prevent determined individuals from cracking into the .exe, but we do want to at least make them work harder to do so.

 

Here's another one...does anybody know of any way to only partially protect/encrypt an .exe file? For example, say I only wanted to protect certain assemblies, but not others. Just wondering if anybody has heard of something like this being done.

 

Thanks!

 

jender624

[IngisKahn]

A common (but easily hackable) method is to use a loader app to decrypt your assembly to the user's temp directory and run it.

[sgt_pinky]

My personal stance is simply to incorporate Dotfuscator into my release process using the batch file mode.

 

It is very quick to set up, and just run on your exe's, dll's, etc, before you compile your installer project. You just have to make sure all the exe's, etc, go where the installer project is expecting to pick them up from.

 

I have heard a lot that a hacker with patience will crack it anyway, so why bother. Well, I have seen my own code obfuscated, and I have a hard time working out what's going on, so good luck to any hacker trying to piece my app back together. Sure, it's possible, but I bet he/she will get bored first.

 

I heard a story once about a company that shredded sensitive documents. Someone collected the shredded documents from their garbage, and took them to India where they paid some carpet makers to piece them back together. :D