App Behavior Analysis#

The app has multiple security checks. Here’s what it’s checking for:

1. Location Verification: Are you at the sacred coordinates?
2. Time Verification: Is it the prophecy moment?
3. Anti-Debugging: Are you trying to debug the app?
4. Anti-Emulator: Is this running on an emulator?
5. Anti-Frida: Is dynamic instrumentation present?

The app loads a native library called libvault.so that does the actual flag checking.

IMPORTANT

The key insight is that while the app has multiple protection layers, they all rely on trusting the Android framework and can be bypassed through dynamic instrumentation.

1. The Anti-Analysis Squad (Java Level)#

// In MainActivity.java (decompiled from smali)
private boolean checkDebugger() {
    // Checks if debugger is attached
    // Returns true if debugging detected
}

private boolean checkEmulator() {
    // Looks for emulator artifacts
    // Checks system properties, files, etc.
}

private boolean checkFrida() {
    // Searches for Frida processes
    // Scans /proc for suspicious stuff
}

Security Weakness

These protection functions are implemented in Java, making them easily accessible to Frida hooks. A more robust approach would implement these checks in native code with anti-hooking measures.

2. The Space-Time Police (Location & Time)#

// Sacred coordinates hardcoded (rookie mistake!)
private static final double SACRED_LAT = 30.043801;
private static final double SACRED_LON = 31.334688;
private static final long TARGET_TIMESTAMP = 1754128800; // In seconds

public String getFlag(double lat, double lon, long time) {
    // Native call to libvault.so
    return nativeGetFlag(lat, lon, time);
}

Hardcoded Secrets

Never hardcode sensitive coordinates and timestamps in your application! These values are easily discoverable through static analysis.

3. The Native Bodyguard (libvault.so)#

// Native functions (found via reverse engineering)
FUN_00101270() // Anti-debug check #1
FUN_00101310() // Anti-debug check #2
FUN_001016a0() // Anti-emulator check
FUN_00101750() // Anti-frida check

Reverse Engineering Tip

When you see function names like FUN_00101270, these are auto-generated by disassemblers like Ghidra. The predictable naming makes them easy targets for patching.

1. Neutralize the Native Bodyguard#

First, we patch the native protection functions. We find libvault.so and patch its protection functions to always return “success”:

// Find and patch native protections
const mods = Process.enumerateModulesSync();
const vaultMod = mods.find((m) => m.name.toLowerCase().includes("vault"));

const exportsList = Module.enumerateExportsSync(vaultMod.name);
exportsList
  .filter((e) => /^FUN_00101(?:270|310|6a0|750)$/.test(e.name))
  .forEach((sym) => {
    // Replace with stub that returns 0 (success)
    Interceptor.replace(sym.address, new NativeCallback(() => 0, "int", []));
  });

2. Time Manipulation#

Next, we control the time. Every time the app asks for the current time, we return the target timestamp:

System.currentTimeMillis.implementation = () => {
  return 1754128800 * 1000; // Convert seconds to milliseconds
};

3. Location Spoofing#

Then we spoof the GPS coordinates. When the app asks for location, we return the sacred coordinates:

Location.getLatitude.implementation = () => 30.043801;
Location.getLongitude.implementation = () => 31.334688;

4. Permission Bypass#

Finally, we bypass the permission system by making the app think we have all required permissions:

CtxCompat.checkSelfPermission.implementation = function (ctx, perm) {
  if (perm.includes("LOCATION")) return 0; // PERMISSION_GRANTED
  return this.checkSelfPermission(ctx, perm);
};

Q1: How did we identify all the protection mechanisms?#

Answer: Through systematic static and dynamic analysis:

Static Analysis:

• Decompiled the APK using jadx or apktool
• Examined MainActivity.java for protection function calls
• Found references to libvault.so native library
• Identified hardcoded coordinates and timestamp values

Dynamic Analysis:

• Used Frida to hook Java methods and observe behavior
• Monitored native function calls and their return values
• Traced location and time API calls

Q2: Why are the native protection functions so easily bypassed?#

Answer: Poor implementation choices by the developers:

1. Predictable export names: Functions named FUN_00101270 are auto-generated by disassemblers
2. No obfuscation: Functions are clearly visible in the export table
3. Simple return values: Functions just return 0/1 for success/failure

Q3: How did we know the exact coordinates and timestamp to spoof?#

Answer: Hardcoded values found in the source code:

// Found in MainActivity.java (decompiled)
private static final double SACRED_LAT = 30.043801;
private static final double SACRED_LON = 31.334688;
private static final long TARGET_TIMESTAMP = 1754128800;

Why this is a security flaw:

• Hardcoding secrets in the app makes them discoverable through static analysis
• Any reverse engineer can extract these values
• The app should have fetched these from a secure server

Q4: What makes the location and time spoofing so trivial?#

Answer: Android’s security model limitations:

Location Spoofing Works Because:

// App calls standard location APIs
Location.getLatitude.implementation = () => 30.043801;
Location.getLongitude.implementation = () => 31.334688;

Time Spoofing Works Because:

// App trusts system time
System.currentTimeMillis.implementation = () => {
  return 1754128800 * 1000;
};

Why this is vulnerable:

• Apps cannot verify GPS authenticity without additional hardware
• System time can be manipulated by root access or framework hooking
• No cryptographic verification of location/time data

“The myth was that the app was secure. The reality was that it trusted everyone!”

App Behavior Analysis#

The app implements multiple layers of “security”:

1. Dynamic Password Generation: Creates a random UUID at runtime
2. Password Validation: Checks user input against generated password
3. Launch Counter: Tracks app launches for alternative access
4. Intent Navigation: Attempts to launch SecondActivity on success
5. Crash on Success: App crashes when correct password is entered (the bug!)

Intent Bug

The main vulnerability lies in the Intent creation logic that passes null instead of the target activity class.

1. The Password Generation System (MainActivity.smali)#

# In MainActivity onCreate method:
invoke-static {}, Ljava/util/UUID;->randomUUID()Ljava/util/UUID;  # Generate UUID
move-result-object p1
invoke-virtual {p1}, Ljava/util/UUID;->toString()Ljava/lang/String;  # Convert to string
move-result-object p1
const/4 v0, 0x0      # Start index 0
const/16 v1, 0x14    # Length 20 (0x14 = 20 in decimal)
invoke-virtual {p1, v0, v1}, Ljava/lang/String;->substring(II)Ljava/lang/String;  # Take first 20 chars
move-result-object p1
iput-object p1, p0, Lcom/hacking/test/MainActivity;->v:Ljava/lang/String;  # Store in field 'v'

Why this is exploitable: The password is generated at runtime and stored in a predictable field that we can access through Smali modification.

Smali Analysis

The key insight is following the data flow: UUID generation → substring → field storage → comparison. This predictable pattern makes the password extractable.

2. The Broken Intent System (H0/a.smali)#

# The problematic Intent creation
const/4 v1, 0x0  # NULL class - This is the bug!
new-instance v0, Landroid/content/Intent;
invoke-direct {v0, p1, v1}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

# Should be:
const-class v1, Lcom/hacking/test/SecondActivity;
new-instance v0, Landroid/content/Intent;
invoke-direct {v0, p1, v1}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

Why this crashes: Android cannot launch an Intent with a null target class, causing a NullPointerException.

SUSS Error

This is either a genuine bug or intentional obfuscation. No production app should crash on successful authentication!

3. The Counter Bypass Mechanism (SecondActivity.smali)#

# In SecondActivity onCreate:
const/16 v0, 0x14           # Generate random number 1-20
invoke-virtual {p1, v0}, Ljava/util/Random;->nextInt(I)I
add-int/lit8 p1, p1, 0x1    # threshold = random(1-20)

# Get current launch count
const-string v2, "launch_count"
invoke-interface {v0, v2, v1}, Landroid/content/SharedPreferences;->getInt(Ljava/lang/String;I)I
move-result v3

# Check TWO conditions:
if-eqz v4, :cond_0          # If from_password is true, OR
if-lt v3, p1, :cond_1       # If launch_count >= threshold
    goto :goto_0            # Show secret (layout 0x7f0b001d)
else
    invoke-virtual {p0}, Landroid/app/Activity;->finish()V  # Close activity

Why this exists: Provides an alternative access method maybe ? , but our Intent fix makes this unnecessary.

Alternative Path

The counter mechanism shows that there are often multiple ways to achieve the same goal in reverse engineering challenges.

1. Password Extraction via Logging#

We inject logging code right after password generation to capture the UUID:

Code injection point:

# Right after this line:
iput-object p1, p0, Lcom/hacking/test/MainActivity;->v:Ljava/lang/String;
# We can add our logging code here because 'p1' still contains the password

2. Intent Fix#

Replace the null class reference with the correct SecondActivity class:

# Replace this line:
const/4 v1, 0x0

# With this:
const-class v1, Lcom/hacking/test/SecondActivity;

Modified MainActivity.smali (Password Logging)#

# Add after password storage
iput-object p1, p0, Lcom/hacking/test/MainActivity;->v:Ljava/lang/String;

# Logging injection
const-string v2, "PASSWORD_DEBUG"
invoke-static {v2, p1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

Modified H0/a.smali (Intent Fix)#

# Replace the null Intent creation
const-class v1, Lcom/hacking/test/SecondActivity;  # Fixed line
new-instance v0, Landroid/content/Intent;
invoke-direct {v0, p1, v1}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

Q1: How did we know the UUID was the password?#

Answer: By reading the MainActivity.smali code systematically:

# In MainActivity onCreate method:
invoke-static {}, Ljava/util/UUID;->randomUUID()Ljava/util/UUID;  # Generate UUID
move-result-object p1
invoke-virtual {p1}, Ljava/util/UUID;->toString()Ljava/lang/String;  # Convert to string
move-result-object p1
const/4 v0, 0x0      # Start index 0
const/16 v1, 0x14    # Length 20 (0x14 = 20 in decimal)
invoke-virtual {p1, v0, v1}, Ljava/lang/String;->substring(II)Ljava/lang/String;  # Take first 20 chars
move-result-object p1
iput-object p1, p0, Lcom/hacking/test/MainActivity;->v:Ljava/lang/String;  # Store in field 'v'

Then in H0/a.smali (click handler):

iget-object v1, p1, Lcom/hacking/test/MainActivity;->v:Ljava/lang/String;  # Get stored password
invoke-virtual {v0, v1}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z  # Compare with input

Methodology:

• Reverse engineering requires following data flow
• We traced: UUID generation → substring → storage → comparison
• The field ‘v’ clearly holds the password for comparison

Data Flow Analysis

Always trace how data moves through an application. Understanding the data flow is key to finding exploitation points.

Q2: How did we know we could read and print the UUID?#

Answer: In Android/Java, we can modify any application’s behavior by:

1. Adding logging calls: Android provides Log.d(), Log.i() functions
2. Adding Toast messages: Toast.makeText() for UI display
3. Smali is modifiable: Unlike compiled binaries, Smali is human-readable bytecode

Why this works:

• The UUID generation happens at runtime in onCreate()
• We can inject code RIGHT AFTER generation but BEFORE use
• Android logging system is always available to applications

Injection Timing

The key is injecting code at the right moment - after the password is generated but before it’s used for comparison.

Q3: Is setting Intent to null a common practice?#

Answer: ABSOLUTELY NOT - this is either:

1. A bug in the original app - developer forgot to specify target activity
2. Intentional obfuscation - to make reverse engineering harder
3. Anti-tampering mechanism - app designed to crash on “success”

Normal Intent creation looks like:

# Correct way:
const-class v1, Lcom/package/TargetActivity;
new-instance v0, Landroid/content/Intent;
invoke-direct {v0, p1, v1}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

# What we found (WRONG):
const/4 v1, 0x0  # NULL class
new-instance v0, Landroid/content/Intent;
invoke-direct {v0, p1, v1}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

This is suspicious because:

• No legitimate app would intentionally crash on successful authentication
• It suggests the challenge creator wanted to test our debugging skills

Q4: How did we know changing null to SecondActivity would work?#

Answer: Logical deduction + file structure analysis:

1. File enumeration: We saw SecondActivity.smali exists in the APK
2. Intent analysis: The Intent was setting "from_password" = true extra
3. SecondActivity logic: Reading SecondActivity.smali showed it checks for "from_password" extra
4. Common Android patterns: Activities are typically organized as flows

Evidence from SecondActivity.smali:

# SecondActivity checks for this exact extra:
const-string v5, "from_password"
invoke-virtual {v4, v5, v1}, Landroid/content/Intent;->getBooleanExtra(Ljava/lang/String;Z)Z
move-result v4
if-eqz v4, :cond_0  # If from_password is true, show secret

Reasoning: If the Intent sets from_password=true, and SecondActivity checks for this, then SecondActivity is clearly the intended destination.

“The trouble was doubled: random passwords AND broken navigation. But every bug is just another door waiting to be opened!”