Internal and External Calls

Dynamic Proxy can be applied to two categories of calls, selected by the proxy mode:

See Configuration to select a mode from the command line, MSBuild or Babel Desktop.

Internal Proxy Calls

Using Dynamic Proxy for internal method calls offers several advantages in terms of code obfuscation and protection. Here are some key benefits:

1. Concealing Implementation Details: By generating dynamic proxies for internal types, the actual implementation details of those types are hidden from external code and potential attackers. The dynamic proxies act as intermediaries, shielding the internal logic and structure of the types, making it harder for malicious actors to understand and manipulate your code.
2. Shield over Method Calls: When using dynamic proxies for internal types, decompilers face challenges in reconstructing the call flow for a method. Decompilers analyze compiled code to generate a high-level representation of the original source code. However, dynamic proxies introduce an additional layer of indirection, making it difficult for decompilers to accurately trace the sequence of method calls.
3. Enhanced Obfuscation: The use of dynamic proxies for internal types adds an extra layer of obfuscation to your codebase. The proxies introduce complexity and indirection, making it more difficult for reverse engineers to understand the underlying structure and relationships of your code. This can deter reverse engineering attempts and protect your intellectual property.

By using Dynamic Proxy for internal calls, you create a barrier that hinders decompilers from accurately reconstructing the call flow within your code. This adds an additional layer of protection and makes it more challenging for attackers or reverse engineers to understand the underlying logic and behaviour of your application.

External Proxy Calls

External proxy calls in Babel Obfuscator provide an effective defense mechanism against decompilers that attempt to reconstruct local variable names based on their inferred types. Decompilers often rely on the available metadata, such as the variable types, to reconstruct the original names of variables.

For instance, in the reflected code below, the tool inferred the list1 and count variable names from the call to the instance constructor for List<string> type and the get_Count() method, respectively.

var list1 = new List<string>();
int count = list1.Count;

When external proxy calls are enabled, Babel Obfuscator replaces direct method calls to external code with calls to dynamically generated proxy classes. These proxy classes act as intermediaries, intercepting and redirecting the method calls. As a result, the original method calls, and their associated local variable names are hidden and obfuscated.

And the above code with Dynamic Proxy enabled will become the following:

var local1 = new a();
int local2 = local1.b();

Decompilers that rely solely on metadata to reconstruct variable names will encounter difficulties when faced with external proxy calls. Since the original method calls are replaced with proxy calls, the inferred variable types alone will not provide any meaningful information about the original variable names. This effectively disrupts the decompiler’s ability to reconstruct the original names based on type inference alone.