Compatibility - Settings

The third of the four settings tabs. Certain third-party assets require specific configurations to ensure compatibility with obfuscation, owing to the unique way Unity operates.

Common - Settings

The majority of compatibility components are always-on to maintain seamless compatibility with Unity and the vast majority of commonly used third-party assets.

Figure 1 - Default components to ensure the compatibility with Obfuscator.

Animation - Settings

Animations can trigger events, which are methods stored as plain text within the animations and invoked at runtime using Reflection. To prevent obfuscation from breaking these events, this compatibility component scans various assets and prefabs. It searches through model files (including .fbx, .dae, .3ds, .dxf, .obj, and .skp formats), animation files (.anim), and animation controllers (.controller) to identify and exclude these methods from obfuscation.

These methods can also be manually excluded using the DoNotRenameAttribute.

Figure 2 - Simplify the Obfuscator compatibility with animation methods.

Event - Settings

Similar to animation events, UnityEvents assigned through the Unity Inspector (often used for GUI methods) rely on Reflection to invoke their target methods at runtime. To prevent obfuscation from breaking these events, this compatibility component searches through the scenes and prefabs to identify and exclude the associated methods from obfuscation, ensuring that they continue to function as intended.

These methods can also be manually excluded using the DoNotRenameAttribute.

Figure 3 - Simplify the Obfuscator compatibility with UnityEvents.

Reflection - Settings

Unity relies heavily on reflection in its underlying architecture. One notable example of this is the use of coroutines, which can be invoked dynamically by their method names.

// Example: Coroutine that fades the alpha of a material.
IEnumerator Fade()
{
    Color c = renderer.material.color;
    for (float alpha = 1f; alpha >= 0; alpha -= 0.1f)
    {
        c.a = alpha;
        renderer.material.color = c;
        yield return new WaitForSeconds(.1f);
    }
}

// Example: Call the Coroutine via name.
StartCoroutine("Fade");

When Unity invokes a coroutine by its method name, such as Fade, it relies on reflection to locate the corresponding method and execute it. However, if the Fade method is obfuscated, its name will be changed, and reflection will no longer be able to find it. This would result in a runtime error, as Unity would be unable to locate the method to execute as a coroutine.

To prevent this issue, the compatibility component ensures that methods, fields, and classes are excluded from obfuscation when they are accessed via reflection. By doing so, the original names of these elements are preserved, allowing Unity to locate and execute them correctly, even after obfuscation.

To mitigate the problem with coroutines, it is recommended to use the StartCoroutine overload, which takes an IEnumerator parameter, like this:

// Example: Coroutine that fades the alpha of a material.
IEnumerator Fade()
{
    Color c = renderer.material.color;
    for (float alpha = 1f; alpha >= 0; alpha -= 0.1f)
    {
        c.a = alpha;
        renderer.material.color = c;
        yield return new WaitForSeconds(.1f);
    }
}

// Example: Call the Coroutine via IEnumerator.
StartCoroutine(Fade());

Classes and its members can also be manually excluded using the DoNotRenameAttribute.

Figure 4 - Manage the obfuscation of classes and members called via Reflection.

Addressable - Settings

The Addressable-Package is a popular Unity package. It is used to load assets from any location with any collection of dependencies. Unfortunally built addressable bundles are not directly compatible with an obfuscated and built application. Because built addressable bundles mostly include assets that reference to scripts. After obfuscation, these scripts will have different names. So the addressable bundles have to be obfuscated too, so these references get updated.

Figure 5 - Manage the obfuscation off Addressables.

You find the following settings:

• Default Path: Represents the path where the addressable bundles are built to.
• Custom Paths: If you do not build your addressables at the default path. Add the build directory here.

Note

At the moment only the JSON catalog version is supported. Binary catalog support will be added in the future.