Renaming

Renaming is the process by which PreEmptive Protection™ DashO™ for Android & Java renames entities such as classes, methods, fields, annotations, and packages in order to make Java bytecode more compact and more difficult to reverse engineer.

The names of classes, methods, fields, etc. that you specify in your source code carry a wealth of information about what individual components of your software do. These names are retained in the resulting bytecode for a variety of reasons – they are important if you want to invoke a main method of a given class, or reference a method in another project. Much of the time, however, these names are not needed after compilation and only serve to make your application easier for an attacker to understand.

Renaming can replace these semantic names with meaningless names (e.g., a, b).

NOTE: In Android Mode, DashO expects renaming to be handled by R8 and DashO's renaming is unavailable. Ensure that you enable R8 when using Android Mode.

Configuring Renaming

You can enable or disable renaming altogether via the DashO GUI, or by editing your DashO Project File. You can also control whether or not classes are renamed at all, whether or not members are renamed at all, and whether or not internally defined annotations are renamed at all.

Packages and Class Prefixes

If you are renaming classes, you can control the packages in which the classes are placed. By default, DashO will flatten the package hierarchy, putting all renamed classes into the same package (the default package, by default).

A Class Prefix can be specified in order to specify a package or otherwise prepend text to the name of each renamed class. Here is the above table with some sample class prefixes applied:

Without package flattening, DashO will keep each class in its original package, only renaming the class itself. Here is the previous example with no package flattening and no class prefix:

Configuring an Alphabet

You can specify the alphabets used to create the new names for classes and members. You can select one of the predefined alphabets or enter your own. When creating your own alphabet the following restrictions apply:

• The minimum length of the alphabet is two characters. Using three or more characters is recommended for larger projects.

• The initial characters of the alphabet must be valid starting characters for Java identifiers. You must have at least one starting character.

• The remaining characters of the alphabet must be valid characters for Java identifiers.

You can configure this alphabet on the Renaming - Options page in the DashO GUI, or in the <renaming> element of your project file.

Minimum Length

You can specify a minimum length for names of classes or members created by renaming. I.e., if you set a minimum length of 3 for classes, then DashO will start with names like aaa for classes and will not produce any shorter names.

Randomized Renaming

You can configure DashO to Randomize the sequence in which it chooses names, for classes and/or members. When randomized renaming is enabled, the renaming process will choose names randomly from the pool of shortest available names. This ensures that the sequence is not consistent between runs of DashO, barring Incremental Obfuscation features.

Given an alphabet abc, DashO would generate the following sequence of names without randomized renaming:

a, b, c, aa, ab, ac, ba, bb, bc, ca, cb, cc...

With randomized renaming, it might choose the following sequence instead:

c, a, b, bc, ab, cc, bb, cb, ca, aa, cc, ac...

Note that all 1-character names are chosen before any 2-character names are chosen.

Entry Points and Renaming Exclusions

Some elements in your software, such as static void main(String[]) methods and classes that contain them, may need to be excluded from renaming if they are to operate correctly. You can mark these as Entry Points or exclude them from renaming.

Reflection

If a class or its members are accessed via reflection, DashO may not be able to rename them in a way that will allow the reflection to still work properly.

If you check the "Determine Reflected Classes" checkbox on the Input - Options, then DashO will attempt to determine which classes are accessed via reflection and exclude them from renaming in order to avoid breaking reflection calls. If you additionally check the "Rename Reflected Classes" checkbox on the same page, then instead of excluding the reflected classes from renaming, DashO will attempt to update references to these classes in String constants to match the new names. It is generally more reliable to manually mark classes and members accessed via reflection as Entry Points, or to exclude them from renaming.

Note:
DashO cannot detect reflection-based access of methods or fields.

See Dynamic Class Loading for more details on detecting reflection.

Map Files

DashO can produce a Renaming Map File, which maps the original names of classes, methods, etc. to the names used in the protected software.

These files are useful for understanding stack traces produced by exceptions. If your protected software encounters an exception, any reported stack trace will use the renamed package, class, and method names. DashO will let you decode the stack trace using the renaming map file preserved from the build. You can also use the separate DashO Lucidator utility to decode these stack traces. Renaming Map Files are also required if you would like to employ Incremental Obfuscation

You can configure where DashO should place the resulting map file, as well as a location of an input map file for Incremental Obfuscation, on the Renaming - Map Files page in the DashO GUI. In addition to the default DashO-compatible Map File, you can create an R8/ProGuard-compatible Map File for use with third party tools that depend on them.

Accidental loss of this file can destroy your chances of incrementally updating your application in the future. Therefore, proper backup of this file is crucial. For this reason, DashO does not automatically overwrite this file if an existing one is found. You can allow DashO to overwrite this file by checking the "Overwrite" checkbox on the Renaming - Map Files page of the DashO GUI.

Renaming Report

DashO can additionally provide a more human-readable renaming report file. You can specify this on the Output - Reports page of the DashO GUI.

Overload Induction™

DashO can employ a technique called Overload Induction to induce maximum reuse of individual method names via overloading. For example, if Overload Induction is enabled, a method foo(), a method bar(int), and a method baz(String) could be renamed to a(), a(int), and a(String) with different signatures. Otherwise, if Simple Renaming is enabled, foo(), bar(int), and baz(String) would all be renamed to completely different names (e.g., a(), b(int), and c(String)).

Reusing short names via Overload Induction results in more difficult-to-understand code as well as more compact bytecode. It reduces the number of constant pool entries that are required to define names in the processed classes, and the entries that are still required take up substantially less space because the underlying names are shorter.

You can enable or disable Overload Induction via Renaming - Options page of the DashO GUI.