Obfuscation and the software life cycle?

Anyone have any tips and trick they would like to share with how you have integrated obfuscation into your build cycle?  I'm curious how people are making obfuscation part of the software life cycle. 

When do you starting considering the fact that things will be obfuscated? 
Do your developers have to consider obfuscation? or just your build engineer?
How does this effect your design? 
Does it effect your unit testing? (are these run before and after the obfuscation step?)
Do you test before and after obfuscation?
How does it effect your deployment?
Do you use continuous integration?
What build tools do you use?

posted on Sunday, April 23, 2006 5:38 AM

Feedback

# re: Obfuscation and the software life cycle?

Alot of these are very good questions but the set that really struck out at me were...

Do your developers have to consider obfuscation? or just your build engineer?
How does this effect your design?

Obviously an answer of build engineer only to the first question pretty much answers the second question. There is however an implicit design decisision which must be made in order to allow for this to happen. You cannot use reflections to dynamically load items based upon name. If you did there would necesarily be a dependency of in depth knowledge on the part of the build engineer.

I personally use obfusication at times (rarely) as I find it to be of little actual protection. If someone seeing your object structure will allow trade secrets to be revealed or will allow them to by-pass security in some way; you have much bigger problems. Keep in mind that with obfusication your code is still intact .. just looks a bit different. While it may take someone longer to realize the relationship between A2332 and C3423 than it would for them to realize the relationship between Customer and Orders ... they can still learn it.

For a process ... it is generally accepted that obfusication should occur as part of your staging or release cycle. Generally speaking unit tests are not run as part of the obfusication process (obfusication should by its very nature be transparent) but integration tests ARE generally run. The integration tests should pick up things such as not being able to dynamically load a type through reflections.

Because it is generally applied during the staging or release cycle other things such as continuous integration are generally not effected.


Hope this is useful for you.

Cheers,

Greg
4/25/2006 3:10 AM | Greg Young

# re: Obfuscation and the software life cycle?

Thanks for the comments!

What do you use for integration testing (do you have any suggestions for typical business applications?) What I am after is how do you automate the testing to find out if the obfuscation broke the application?
4/25/2006 4:16 AM | Jason Haley

# re: Obfuscation and the software life cycle?

One possible way is to run peverify.exe to check if everything has been done properly.

Below is a nice wrapper for peverify that can be integrated into the build cycle:

http://www.jasonbock.net/JB/Default.aspx?blog=entry.7ab7c272169848ef866c52174e9a8ee9
4/25/2006 5:37 AM | Vladimir Klisic

# re: Obfuscation and the software life cycle?

There is an app called assembly lockbox that encrypts the assemblies after they have been compiled. You dont need the encrypted versions of the assemblies at all until it is time to ship. For debugging you can just drop the unencrypted assemblies into the application folder and they will be used automatically instead of the encrypted versions.

You can find it at http://alb.gibwo.com
7/2/2007 6:23 PM | Gerald Gibson

Post Comment

Title  
Name  
Url
Comment   
Please enter the following code into the box below to stop spammers

  
Enter Code Here *