Skip to content
Platform
android
MASVS v1 MSTG-RESILIENCE-9
MASVS v2 MASVS-RESILIENCE-3
Last updated: May 08, 2023

Testing Obfuscation

Overview

Static Analysis

Decompile the APK and review it to determine whether the codebase has been obfuscated.

Below you can find a sample for an obfuscated code block:

package com.a.a.a;

import com.a.a.b.a;
import java.util.List;

class a$b
  extends a
{
  public a$b(List paramList)
  {
    super(paramList);
  }

  public boolean areAllItemsEnabled()
  {
    return true;
  }

  public boolean isEnabled(int paramInt)
  {
    return true;
  }
}

Here are some considerations:

  • Meaningful identifiers, such as class names, method names, and variable names, might have been discarded.
  • String resources and strings in binaries might have been encrypted.
  • Code and data related to the protected functionality might be encrypted, packed, or otherwise concealed.

For native code:

Some of these techniques are discussed and analyzed in the blog post "Security hardening of Android native code" by Gautam Arvind and in the "APKiD: Fast Identification of AppShielding Products" presentation by Eduardo Novella.

For a more detailed assessment, you need a detailed understanding of the relevant threats and the obfuscation methods used. Tools such as APKiD may give you additional indications about which techniques were used for the target app such as obfuscators, packers and anti-debug measures.

Dynamic Analysis

You can use APKiD to detect if the app has been obfuscated.

Example using the UnCrackable App for Android Level 4:

apkid owasp-mastg/Crackmes/Android/Level_04/r2pay-v1.0.apk
[+] APKiD 2.1.2 :: from RedNaga :: rednaga.io
[*] owasp-mastg/Crackmes/Android/Level_04/r2pay-v1.0.apk!classes.dex
 |-> anti_vm : Build.TAGS check, possible ro.secure check
 |-> compiler : r8
 |-> obfuscator : unreadable field names, unreadable method names

In this case it detects that the app has unreadable field names and method names, among other things.

Resources