Any better way to handle obfuscation?

[ElJaviLuki]

Hi guys, for now I am managing the obfuscation of the symbols through the Obfuscation.kt file, which basically simulates the use of the symbols and classes as if they were not obfuscated. The obfuscation is therefore hidden in a kind of semi-interface so to speak. However, with new updates, the class hierarchy is expected to become more complex as new hooks are added; and possibly soon the Obfuscation file will bring severe headaches.

Do you think there is a better solution to deal with this problem? Could we use some data structure that resolves unobfuscated symbols into obfuscated; respecting the class hierarchy; both those that are nested in others as well as independent classes?

Feel free to talk about your thoughts on this regard.

[Lanchon]

there is code obfuscation -in which bytecode itself is complicated- and layout obfuscation.

code obfuscation typically slows down an app a bit. it starts with encrypting strings, and goes all the way to on-the-fly generating a randomized virtual machine and a compiler for it, compiling the code to be protected into bytecode for the strange one-off VM, and packaging the VM and bytecode as a deliverable.

layout obfuscation is simply changing the name of stuff, not the bytecode.

there are lots of tools for the former, if that is a problem. but for the later, the information has been lost and cannot be regenerated.

unless...

enter AI. you can train an AI on loads of open source code and it can identify and recover open source libs in the app and common code snippets, and use all that to regenerate names.

this is very old, probably does not work with recent androids, but take a look anyway:
http://apk-deguard.com/
https://files.sri.inf.ethz.ch/website/papers/deguard.pdf

that can help you analyze code much faster.

also you could investigate this:
if you ran such a tool on different versions of grindr, although the "deobfuscated" names it will generate for code might not be accurate, it will tend to select the same names for the same code. the result being that a specific routine you might want to hook will be most likely always mapped to the same name (wrong or right). so you can reverse lookup a name to hook in the deobfuscation map output and hook that. if you automate this, you simply have to provide the new map output when grindr releases a new version.

if you are not using AI, you can simply name each thing you want to hook and look that name up in a properties file. you create a prop file for each grindr version. if you feel like it, you can look up the current grindr app version and use it as the property filename, so the same module can hook several grindr versions. you can even look the prop file up from a github repo as a raw file, so you can add version support without having to publish a new module.

[Lanchon]

of course in the properties file you can do nested lookups if needed to ease manual work. something like:

ui.ProfileActivity=X3hd
ui.ProfileActivity.onStart=[ui.ProfileActivity].onStart
ui.ProfileActivity.onStop=[ui.ProfileActivity].onStop
ui.ProfileActivity.blockProfile=[ui.ProfileActivity].xwmd

but you could just do this isntead:

ui.ProfileActivity=X3hd
ui.ProfileActivity.onStart=onStart
ui.ProfileActivity.onStop=onStop
ui.ProfileActivity.blockProfile=xwmd

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html

4.2.2. Unqualified Names
Names of methods, fields, and local variables are stored as unqualified names. An unqualified name must not contain any of the ASCII characters . ; [ / (that is, period or semicolon or left square bracket or forward slash).