Module 8 — Application Patching, Repackaging, and Tamper Testing

Por

Ethical Reminder:
The techniques in this module are powerful and must only be used in authorized labs with intentionally vulnerable APKs or apps for which you have explicit written permission. Patching, bypassing controls, and redistributing APKs without consent is illegal. Here, we focus on understanding risks, testing robustness, and helping developers improve defenses.

8.0 Learning Objectives

By the end of this module, you will be able to:

  • Understand the concept of application patching and repackaging.
  • Learn how attackers typically modify APKs to disable security checks.
  • Explore common tools used for decompilation, modification, and recompilation.
  • Practice safe labs demonstrating patching workflows on intentionally insecure apps.
  • Document tamper-resistance gaps in a reproducible, ethical way.
  • Recommend hardening techniques to defend against patching and tampering.

8.1 What is Application Patching?

Application patching is the process of:

  1. Unpacking an APK (extracting resources, bytecode, native libraries).
  2. Modifying its behavior by editing code, removing or altering checks.
  3. Repackaging and resigning the modified APK.
  4. Running the patched app to confirm bypasses.

For example, attackers might patch out:

  • Root detection checks (return false instead of true).
  • License validation (skip purchase checks).
  • SSL pinning enforcement (remove certificate checks).
  • Security prompts (disable 2FA or warning popups).

8.2 Patching Workflow Overview

  1. Acquire APK
    • Use adb pull or download a lab APK.
  2. Decompile
    • Tools: apktool (resources & smali code), JADX (readable Java).
  3. Identify Targets
    • Search for strings: "isRooted", "checkIntegrity", "validateLicense".
    • Locate smali or Java methods.
  4. Modify Behavior
    • Edit smali code (low-level) or recompile modified classes.
  5. Repackage
    • Build APK again with apktool.
  6. Re-sign
    • Apps must be signed; use apksigner or uber-apk-signer.
  7. Install & Test
    • Deploy to emulator or lab device.
  8. Document Evidence
    • Capture before/after behavior and changes made.

8.3 Core Tools

8.3.1 Apktool

  • Decompiles resources and smali code.
  • Command: apktool d app.apk -o app_src → Produces smali/ directory with human-readable bytecode.

8.3.2 JADX

  • Decompiles DEX → Java source (read-only for analysis).
  • Useful for locating target functions before smali edits.

8.3.3 Smali/Baksmali

  • Tools to disassemble/assemble Dalvik bytecode.
  • Required for fine-grained editing.

8.3.4 Signing Tools

  • apksigner (official Android SDK) apksigner sign --ks mykey.jks --out patched.apk dist/app.apk
  • Uber APK Signer for automation.

8.4 Practical Lab Example

Scenario: Root Detection Patch

  1. Decompile APK apktool d InsecureBank.apk -o InsecureBank_src
  2. Locate Check
    Inside smali/com/vulnlab/security/RootCheck.smali find: .method public static isRooted()Z const/4 v0, 0x1 return v0 .end method → Always returns true (device is rooted).
  3. Patch Code
    Change return value: .method public static isRooted()Z const/4 v0, 0x0 return v0 .end method → Now app thinks device is never rooted.
  4. Rebuild apktool b InsecureBank_src -o InsecureBank_patched.apk
  5. Re-sign apksigner sign --ks labkey.jks --out InsecureBank_signed.apk InsecureBank_patched.apk
  6. Install & Test adb install -r InsecureBank_signed.apk → Root warning bypassed.

8.5 Tamper Testing & Validation

As pentesters, our goal is not just to patch but to report how easy it was. Consider:

  • Effort required: Was the app obfuscated? Did you need custom scripts or just one line?
  • Impact: What protection did this patch disable? Root check, SSL pinning, license verification?
  • Evidence: Always provide proof (before vs. after screenshots, code diffs, logs).

Deliver this as part of a Tamper Resistance Evaluation in your report.

8.6 Defensive Hardening Recommendations

To make patching harder, developers should:

  • Enable code obfuscation with ProGuard/R8.
  • Use NDK (C/C++) for critical checks (harder to patch than smali).
  • Implement runtime integrity checks (e.g., checksum verification of classes).
  • Use server-side enforcement for critical logic (never trust client-only).
  • Leverage Play Integrity API / hardware-backed attestation.
  • Enable anti-tampering frameworks (e.g., Appdome, DexGuard).

8.7 Common Pitfalls

  • Assuming signature check = safety: Attackers can re-sign with their own key.
  • Relying solely on client checks: Anything on the client can be patched.
  • Unobfuscated smali code: Makes patching trivial.
  • Failing to validate on server: Example: server trusts isRooted=false blindly.

8.8 Practical Lab Exercises

Lab 8-A — String Modification

  • Find and modify a hardcoded API endpoint in smali code.
  • Test whether the modified app points to attacker-controlled server.

Lab 8-B — Logic Flip

  • Change a license check method from returning false to true.
  • Document impact on app’s premium features.

Lab 8-C — Tamper Detection Test

  • If app has self-checking mechanisms, patch them and note whether it continues to run.

8.9 Deliverables

  • Tamper Report: Describe patched methods, effort required, risks.
  • Evidence Bundle: Original vs. patched APK hashes, screenshots, logs.
  • Developer Checklist: Practical defenses against patching attempts.

Key Takeaways

  • Patching and repackaging are real-world attack vectors.
  • Attackers can modify client logic with tools like apktool and smali.
  • Pentesters must demonstrate feasibility in labs and recommend stronger controls.
  • Client-side checks alone are never enough; server-side validation is essential.
  • Deliver reports with evidence, emphasizing effort vs. impact.