Application security is an ever-evolving arms race: bad actors constantly try to circumvent protections, while good actors constantly work to stop them. To be most effective, every app security strategy should employ defense-in-depth. PreEmptive provides several distinct layers of protection, such as Renaming, Control Flow, String Encryption, and Tamper Defense. Make Synthetic is another handy feature, but it should be used only in certain contexts.
Make Synthetic causes a class, method, or field to appear compiler-generated. Because of this, decompilers cannot correctly render code, and often choose to skip these sections altogether. This closes another avenue a hacker could use to spy on code.
As with other obfuscation transforms, Make Synthetic is fully configurable. It can be enabled or disabled independent of other protections. You also have the granular control to include or exclude packages, classes, methods, and fields:
If you’re creating a library or exposing an API, Make Synthetic should not be used because it may impact how external callers work. For this reason, it is disabled by default as part of PreEmptive’s “first do no harm” principle. If your app is fully self-contained, Make Synthetic can be explicitly enabled in the DashO project settings.
As decompilers evolve, we constantly observe how they respond to obfuscated code. When used effectively, DashO’s Make Synthetic feature provides another distinct layer of protection as part of an overall defense-in-depth strategy.
If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please contact us.
