SLP Code Protector Discussion For conversations regarding usage of Code Protector and issues pertaining to SVM protected code.
InishTech Support Forums > SLP Code Protector Discussion > Mixing Obfuscation and other techniques for optimum protection Login to add this as a favourite.
User avatar
Member
Member
td - 4/21/2010 8:31:35 PM
   
Mixing Obfuscation and other techniques for optimum protection

I have been evaluating the SLP Code Protector and a number of questions have popped up that I hope someone will be able to assist with.

First of all I have been advised to limit the number of methods I protect with SLP Code Protector.  While this is okay for alot of the code, there is still a substantial portion that I would like to protect in someway.

I have been looking at the following approach as a possible solution:

a)      Obfuscate original assembly using .NET Reactor (or other tool).
b)      Use SLP CP to process the obfuscated assembly
c)       Use .NET Reactor's anti-tampering techniques, suppress de-compilation and create a x86 windows exe stub from the file produced by SLP CP. 

However, I am aware that obfuscation and other security techniques can cause problems. I suspect that, when coupled with SLP, an inexpensive obfuscator would offer similar protection.   

Is anyone able to advise on the best practical approach to obfuscation when using it in conjunction with SLP? And - Is there anything in commonly found in obfuscation tools that could cause problems for SLP?

Many thanks in advance!

PS. I would also like to avoid using Pre-Emptives Dotfuscator


User avatar
InishTech Dev
InishTech Dev
RBartelink - 4/26/2010 10:21:51 AM
   
RE:Mixing Obfuscation and other techniques for optimum protection

The primary thing regarding combining Code Protection with obfuscation is - (as you've identified) that any obfuscation take place before the code protection.

In general, we recommend using integrated protection via http://www.inishtech.com/KB12 if possible, as it allows one to make the protection an intrinsic part of the build cycle rather than something that takes an extra click that either Makes You Think or can end up being skipped.

In order to fulfill the two aforementioned aims, one would ideally want to have an obfuscation system that integrates into the MSBuild compilation flow, rather than something that requires you to do a manual step at some point in every compile for test or release. Whether this is possible (it pretty much universally is) and how clean this is will depend on the specific obfuscator.

Our aim is to fit with any obfuscation solution of your choosing - our MSBuild integration allows one to Protect your code transparently as part of the MSBuild flow and hence should not impose any constraints on your selection of an obfuscation product. Even if that were not the case, you can still use our Command Line protection (see http://www.inishtech.com/KB2 ) to integrate with your obfuscator appropriately (our MSBuild integration is build on top of our standard Command Line Protection)

Hopefully other readers will take the time to submit a quick summary of approaches/packages that they use (and/or stuff they had to rule out). (Note: We deliberately didnt answer right away in order to allow others who will have far more direct experience of the tradeoffs in choosing an obfuscator to step in with up to date information including key factors in their decision making process)


1

There are currently no users on-line.

  • Sticky
  • Locked sticky
  • Hot sticky
  • Hot locked sticky
  • Thread
  • Hot thread
  • Locked thread