Several questions on C# obfuscation (SmartAssembly, internal functions)

[Molkan]

Hello! We are caring experiments with several obfuscators. We want to protect our source code from using once more with somebody else. Our main task is to make exe (or dll) analysis for getting original source code structure as complicated as possible. In other words it must be easier to develop application on your own, than to use our sources restored from exe (or dll). At the moment we are testing SmartAssembly 6. We deobfuscate result exe and dll with de4dot. The result is evaluated in Reflector. Thereby we have several questions (It is implicated that analyzed exe (or dll) was obfuscated with SmartAssembly).

Questions:

1. Is there any method (deobfuscation, process dumping, debugging etc) to recover sources of internal and private functions (which are not called from public functions) without extensive and long work (I mean long time spent on recovering process)? If it is possible - please specify the method.

2. The same questions about internal and private function parameter names and local variable names.

3. Which obfuscator (protector etc) you think we should use instead of SmartAssembly to achieve our goals as best as possible (with license cost less than 200$)?

Several observations from our experiments:

1. De4dot does not recover local var names after SmartAssembly (just renames basing on var types to facilitate the analysis http://prntscr.com/78puxr ). But public function code structure and parameter names are recovered pretty good.

2. internal and private functions was not found with Reflector in De4dot recovered file http://prntscr.com/78pvh4 . Besides, their source cannot be found even if public functions is called from them (I mean from internal or private function source) http://prntscr.com/78pxcf .

3. However if private function is called by public one, it can be found with Reflector and its structure is easily recognized http://prntscr.com/78q5pm

[jamieakers]

Hello! We are caring experiments with several obfuscators. We want to protect our source code from using once more with somebody else. Our main task is to make exe (or dll) analysis for getting original source code structure as complicated as possible. In other words it must be easier to develop application on your own, than to use our sources restored from exe (or dll). At the moment we are testing SmartAssembly 6. We deobfuscate result exe and dll with de4dot. The result is evaluated in Reflector. Thereby we have several questions (It is implicated that analyzed exe (or dll) was obfuscated with SmartAssembly).

Questions:

1. Is there any method (deobfuscation, process dumping, debugging etc) to recover sources of internal and private functions (which are not called from public functions) without extensive and long work (I mean long time spent on recovering process)? If it is possible - please specify the method.

2. The same questions about internal and private function parameter names and local variable names.

3. Which obfuscator (protector etc) you think we should use instead of SmartAssembly to achieve our goals as best as possible (with license cost less than 200$)?

Several observations from our experiments:

1. De4dot does not recover local var names after SmartAssembly (just renames basing on var types to facilitate the analysis http://prntscr.com/78puxr ). But public function code structure and parameter names are recovered pretty good.

2. internal and private functions was not found with Reflector in De4dot recovered file http://prntscr.com/78pvh4 . Besides, their source cannot be found even if public functions is called from them (I mean from internal or private function source) http://prntscr.com/78pxcf .

3. However if private function is called by public one, it can be found with Reflector and its structure is easily recognized http://prntscr.com/78q5pm

 

Having spent inordinate amounts of time researching this in the past, your best options are:

 

• Use a language that doesn't compile to CLR; for example use .NET Native to properly compile to binary, or use a proper native language like C++
• Protect your IP (Intellectual Property); for example patent your innovation or use EULA's prohibiting disassembly.
• Accept that your code can be reverse-engineered given enough effort regardless of what obfuscation technology you use.

Aside: The project I worked on went with the second option as this represented the best value proposition.