Mobile Malware · Inside a Malicious App · Lesson 2 of 5

Obfuscation & Packing

Why some code is hard to read, and why hard to read isn't the same as malicious.

Code that's hard to read on purpose

Once analysts open an app's code, they sometimes find it deliberately hard to follow. Making code harder to understand without changing what it does is called obfuscation. It comes in a few common forms, and recognizing them is part of reading any app.

• Renamed code. Meaningful names like BankOverlay or sendSms are replaced with short, meaningless ones like a, b and c. The app runs the same. A human just loses the clues.
• Encrypted strings. Web addresses, commands and file names are stored scrambled and only turned back into readable text while the app runs. That defeats the simple string scan you saw in the last module.
• Indirect calls. Instead of calling a feature directly, the code looks it up by name at runtime, so a quick read doesn't show which phone features it touches.

Here's the catch: honest apps obfuscate too. You saw in Secrets in the Code that R8, the standard tool that shrinks Android apps at build time, renames classes and methods by default to make the app smaller. So most apps from the Play Store contain names like a.b.c. Seeing them tells you almost nothing. Companies also obfuscate to protect their own ideas and to make cheating in games or fraud against banking apps harder. The OWASP mobile security standard lists these protections as reasonable defenses for apps that guard valuable assets.

So what do analysts actually look for? Context. Renamed code is normal. Encrypted strings in a flashlight app, combined with an accessibility request and a debug signer, are something else. Obfuscation raises a question. The rest of the evidence answers it.

It also shapes how analysts work. When text is scrambled until runtime, the easiest way to read it is often to let the app unscramble it itself while someone watches, which leads into dynamic analysis later in this course.

Packers and payloads that show up later

Obfuscation makes code hard to read. Packing goes a step further and hides the code entirely. A packer wraps the real program in an encrypted container. What you see in the APK is a small piece of starter code, sometimes called a stub. When the app runs, the stub unwraps the real code in memory and hands control to it. That's the pattern from the triage lab: a tiny classes.dex sitting next to a large encrypted asset file.

MITRE ATT&CK, the shared catalog of attacker behavior you'll meet later in this course, lists software packing as a way mobile malware hides (technique T1406.002). One of its examples is Android spyware that hid its payload using a packer made by a large, well-known tech company, not by the attackers.

There's a related trick that leaves even less to find: not shipping the bad code at all. The app installs clean, then downloads new code or a whole second app after installation. ATT&CK calls this Download New Code at Runtime (T1407). In 2025, Zscaler ThreatLabz described Anatsa droppers that decrypted their strings only at runtime and fetched the banking trojan from a server, disguised as an update. Reviewers looking at the original app saw a working document reader.

Again, packing alone isn't proof. Some legitimate apps, especially banking and gaming apps, use commercial protection tools that encrypt their code to resist tampering and fraud. An analyst reasons with questions like these:

• Does a packed app also ask for permissions it doesn't need?
• Who signed it, and is it from the real developer?
• Is the protector a known commercial product, or something custom?
• What does the unpacked code actually do when it's observed?

That last question matters most. Hiding code makes static analysis harder, but the code still has to run eventually. Watching it run is often how analysts see past the wrapper.