Security always works against speed and usability. That's why it's important to keep the right balance between them.
There is no such thing as absolute security. There is always a tradeoff between security, usability and speed. So, the best solution is to provide the point of balance between those ends. Eazfuscator.NET provides the balanced solution: your code will be in safety and it will work fast.
At the same time, obfuscation does not stop well-planned attacks on a particular method or a class. For example, it is not a so big deal to try to crack the licensing portion of your code. Going beyond the obfuscation, code virtualization technology covers this scenario making it extra hard and costly for an intruder.
You can just look inside
C:\Program Files (x86)\Eazfuscator.NET\Eazfuscator.NET.exe file
with a decompiler to get an example of Eazfuscator.NET vision.
Yes, you see some calls or instructions but you are unable to comprehend inner constructs, crack or resell the product.
So, as you can see, the obfuscation is the art of balance.
While Eazfuscator.NET does its best to automatically provide the balanced solution, there are situations when it may get distorted by human factors.
Let's overview some human factors that may come into play.
The factor comes into play when a person decides that code virtualization is the only reliable protection technique. While virtualization is indeed a decent protection scheme, it has its drawbacks. The assembly gets larger and virtualized code becomes 50x slower.
In general, virtualization should not be applied to every class and every method. Instead, it should be carefully used to protect the most important parts of your application. For example, licensing algorithms are perfect target for virtualization.
The factor applies when a person wants to improve obfuscation coverage. This is a noble aim and it is perfectly achievable by following general best practices.
But what the person should beware of and avoid is trying to shoot himself in the foot by renaming the unrenamable.
For example, the person can decide that he needs to get serializable classes renamed while they are used by binary serializer to work with interchangeable file formats. This is a conflict situation: either class names are kept intact or the file serialization gets broken.
The factor comes into play when a person decides that his whole application should be deployed as a single file. Single file deployment may be a requirement for portable applications despite the fact of known performance implications.
If the person is not bound to portable application requirements then he should thoroughly ask himself whether single file deployment is really needed. More often than not, single file deployment is not a necessity.
Once person drops “The Single File” mantra, he becomes more open to careful and responsible usage of assembly embedding and merging features. As a result, the larger applications will likely have better runtime performance and memory footprint together with more granular and simpler build process during development.
The rule of a thumb goes as follows:
- Keep your assembly sizes below 10 MB, preferably below 5 MB
- Neither embed nor merge third-party libraries (A good exception from this rule is licensing libraries)
Of course, it all depends on your particular scenario and you should not take these suggestions as a dogma.