Report an Obfuscated Application Not Working

Dealing with problems is never easy, and it becomes even more complex when dealing with code obfuscation.

At ByteHide, we strive to create incredible products that generate an unforgettable user experience. However, unfortunately, errors exist. To be as agile as possible in resolving an error, we propose that when a protected application does not work correctly, you fill out this form with as much information as possible. This will make us very agile, efficient, and quick in helping you.

Error Resolution Form

If you have experienced an error, please fill out this form 👇🏻, we will help you very quickly.

Common Obfuscation Errors

We can also help you eliminate the most common errors in obfuscated applications that you could avoid making.

1. Obfuscating applications that already contain obfuscation

When applications contain obfuscation, they are usually difficult to manipulate. When over-manipulated, it is very common and expected that errors will arise. In any case, avoid this action.

1.1 Tip. Do not obfuscate applications with multiple obfuscation tools

Mixing obfuscation tools will not only lead to errors but also to performance problems.

2. Obfuscate twice with ByteHide Shield

As you should know, Shield not only obfuscates, but in its pro editions, it also adds integrity check methods. If you protect a second time with Shield, the integrity methods will break the assembly after the security checks, and your application will not work.

3. Problems with renaming

The application of renaming is delicate because of the original use of the application, that is, you have to be careful with what is renamed. We will give you a list of tips in order of priority so that you do not suffer problems.

1. Do not rename public members, public members are usually public because they are going to be used externally. If you rename public members of a library (dll) or an application that will be called by another, the calling application will not be able to find them if their name has changed.
2. Do not rename reserved members, in some cases, some members are used dynamically by other processes that you do not control, for example, in ASP .NET, the StartUp method is normally invoked when the server starts. If you rename it, it will not be found in the application and will not start.
3. Do not rename enums, if you use enums in your application and use their name nameof and rename them, the functionality could be erroneous.
4. Do not rename WPF resources or interfaces if not necessary because they are only design elements without importance, it is recommended not to apply any protection to them.
5. Applications with internationalization and translations Shield supports applications that use i18n with language resources, but if it is a very complex case, omit obfuscating the names.

4. Problems with metadata protections

Protections that include invalid metadata, add resources, invalid code, or tables in your application that do not affect functioning but do prevent a decompiler from decompiling your application because it generates an error when loading the module, that's fine.

The problem is that if, for example, a Xamarin, Blazor, or another type of application tries to load the same module, like a decompiler, it may generate errors. Omit this type of protection in special applications (Xamarin, ASP, Blazor).

5. Problems with reflection

If your application uses Reflection, it will be able to perform any original function, but if it reads obfuscated methods or attributes, it will generate errors. Again: