Analisis Statis APK dengan Apktool & JADX

Artikel ini menjabarkan langkah-langkah praktis untuk melakukan static analysis pada file APK menggunakan Apktool dan JADX, meliputi persiapan lingkungan, perintah yang dijalankan, temuan utama (minimal 3), analisis risiko, dan rekomendasi mitigasi untuk developer.

Environment & Tools

1. OS Kali Linux (Rolling)
2. ADB Android Debug Bridge version 1.0.41 (Android SDK Platform-Tools 34.0.5)
3. Apktool
4. JADX (build from source via Gradle)
5. EmulatorLDPlayer (Android 9)
6. Target Aplikasi com.mkulesh.micromath.plus (target.apk, size 5.9 MB)

Langkah Kerja

1. Mengambil Target APK dari Emulator

Menemukan package yang mengandung kata “math”:

adb shell pm list packages | rg -i "math" || true

Menampilkan path APK dari package tersebut:

adb shell pm path com.mkulesh.micromath.plus

Menyalin APK ke host machine:

adb pull /data/app/com.mkulesh.micromath.plus-*/base.apk ./target.apk

Verifikasi hasil:

ls -lh target.apk
file target.apk

List isi APK (struktur zip):

unzip -l target.apk | head

2. Dekompilasi Manifest & Resources dengan Apktool

Decode APK agar manifest dan resources dapat dibaca:

apktool d target.apk -o target_apktool

Memeriksa isi manifest:

grep -n "allowBackup" target_apktool/AndroidManifest.xml
grep -n "debuggable" target_apktool/AndroidManifest.xml
grep -n "exported" target_apktool/AndroidManifest.xml

3. Dekompilasi DEX → Java Source dengan JADX

Dekompilasi ke bentuk kode Java-like:

jadx -d ~/target_jadx ~/target.apk

4. Mencari BuildConfig (sering berisi DEBUG = true)

find ~/target_jadx/sources -name "BuildConfig.java"

cat ~/target_jadx/sources/com/mkulesh/micromath/plus/BuildConfig.java | head -20

Atribut DEBUG = false menandakan:

• Aplikasi sudah dibuild dengan konfigurasi production/release, sehingga debugger dan logging sensitif tidak aktif.
• Ini adalah konfigurasi aman, berbeda dengan DEBUG = true yang bisa membuka celah debugging, log leaks, dan bypass proteksi.

5. Mencari Hardcoded Data & API Key

Cari pola umum kredensial:

rg -i "api_key|apikey|secret|token|password|http" target_jadx || true

📜 Hasil: Tidak ditemukan API key / secret, hanya beberapa link dokumentasi:

https://docs.google.com/viewer?url=https://github.com/mkulesh/microMathematics/raw/supplement/doc/microMathematics-v2.23.2.pdf

serta beberapa string UI seperti:

passwordToggleDrawable
passwordToggleEnabled

5. Analisis Kriptografi & Jaringan

Cari penggunaan API kriptografi:

rg "javax.crypto|Cipher|MessageDigest|AES|RSA|Base64" target_jadx || true

📜 Hasil: Ditemukan pemanggilan:

import android.util.Base64;
byte[] bArrDecode = Base64.decode(str, 3);
MessageDigest messageDigest = MessageDigest.getInstance("SHA-1");

Cari penggunaan network/webview:

rg "HttpURLConnection|OkHttpClient|WebView|HttpsURLConnection" target_jadx || true

📜 Hasil: Ditemukan:

import android.webkit.WebView;
return WebView.findAddress(str);

Hasil & Temuan

Temuan 1 — Backup Data Aktif (android:allowBackup="true")

Bukti singkat AndroidManifest.xml:

<application android:allowBackup="true" ... >

Mengapa ini berisiko & contoh eksploitasi

• android:allowBackup="true" mengizinkan utilitas backup Android (mis. adb backup) untuk membuat cadangan data aplikasi tanpa autentikasi per-app.
• Penyerang dengan akses fisik ke perangkat (atau akses ADB) dapat menjalankan:

adb backup -f app.ab com.mkulesh.micromath.plus

lalu mengekstrak konten app.ab dan membaca file, preferences, database SQLite, cache, dsb.

• Backup bisa juga dilakukan pada perangkat yang tidak di-root jika opsi backup diizinkan dan membuka jalur eksfiltrasi data.

Dampak potensial

• Eksfiltrasi token, kredensial tersimpan, session cookies, data pribadi pengguna, dokumen/app data.
• Pelanggaran privasi pengguna; jika aplikasi menyimpan data sensitif (catatan, worksheet berisi info pribadi), data tersebut bocor.
• Bypass autentikasi lokal jika credential tersimpan di preference.

Rekomendasi mitigasi (developer)

1. Tutup backup untuk release builds (manifest):

<application android:allowBackup="false" ... >

2. Jika backup berguna, batasi konten yang di-backup menggunakan fullBackupContent (whitelist/blacklist) dan enkripsi data sensitif:

• res/xml/backup_rules.xml:

<full-backup-content>   
<exclude domain="file" path="sensitive/"/> 
</full-backup-content>

• manifest:

<application android:fullBackupContent="@xml/backup_rules" ...>

3. Jangan menyimpan credential/token plaintext di SharedPreferences atau file. Simpan secret di Android Keystore, dan encrypt data sebelum menulis ke storage publik.

4. Tambahkan pemeriksaan di CI bahwa allowBackup = false di release manifest (linting/automation).

Temuan 2 — Komponen Diekspos (android:exported="true" pada Activity)

Bukti singkat Contoh di AndroidManifest.xml:

<activity android:name="com.mkulesh.micromath.plus.MainActivityPlus"
          android:exported="true" ... />

Mengapa ini berisiko & contoh eksploitasi

• android:exported="true" membuat komponen (Activity/Service/Receiver/Provider) dapat dipanggil oleh aplikasi lain lewat Intent.
• Jika komponen melakukan operasi sensitif (mengakses file internal, menerima data tanpa validasi, menjalankan logic perubahan), aplikasi jahat bisa mengirim Intent crafted untuk memicu operasi tersebut.
• Contohnya activity yang menerima extra Intent dan langsung menulis file bisa dimanfaatkan untuk injection; service yang mengeksekusi perintah berdasarkan extra dapat dijadikan RCE-like vector.

Dampak potensial

• Component hijacking: aplikasi jahat memicu fungsi internal, menyebabkan kebocoran data, perubahan konfigurasi, atau mengeksekusi tindakan yang seharusnya terbatas.
• Escalation: menggabungkan exported component + intent injection bisa membuka jalur lebih jauh (mis. mengganti file konfigurasi).

Rekomendasi mitigasi (developer)

1. Set exported hanya bila perlu. Sebagai aturan:

<activity android:name="..."           
          android:exported="false" />

2. Jika perlu diexport, batasi akses dengan permission atau pengecekan signature:

<activity android:name="..."           
          android:exported="true"           
          android:permission="com.example.MY_PERMISSION">

• definisikan MY_PERMISSION dengan protectionLevel="signature" untuk membatasi ke app yang signed sama.

3. Validasi semua input Intent di runtime: cek getCallingPackage(), validasi extras, dan jangan jalankan perintah/membuka file tanpa izin.

4. Audit manifest dan lakukan automated check: pastikan hanya Launcher Activity atau yang memang public yang diexport.

5. Dokumentasikan komponen publik dan gunakan scoped URIs / ContentProviders dengan permission jika perlu berbagi data.

Temuan 3— Penggunaan Base64 untuk Encoding (bukan Enkripsi)

Bukti singkat

Mengapa ini berisiko & contoh eksploitasi

• Base64 hanya memetakan data binari ke teks, bukan metode enkripsi. Siapa pun yang menemukan string Base64 dapat decode kembali ke data asli.
• Risiko muncul bila developer menyimpan data sensitif (mis. hasil perhitungan pengguna, file, token) hanya setelah di-Base64 tanpa enkripsi.

Dampak potensial

• Data sensitif yang “ter-encode” mudah dipulihkan → eksfiltrasi & penyalahgunaan.
• False sense of security: developer mengira data aman padahal mudah diakses.

Rekomendasi mitigasi (developer)

1. Gunakan enkripsi bukan hanya encoding. Contoh enkripsi AES-GCM (Android):

• Gunakan Android Keystore (untuk menyimpan key) dan Cipher AES/GCM/NoPadding.
• Contoh singkat (konsep):

KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256);
SecretKey key = keyGen.generateKey();
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, key);
byte[] iv = cipher.getIV();
byte[] ciphertext = cipher.doFinal(plaintext);
// simpan iv + ciphertext (iv tidak perlu rahasiakan, tapi harus random untuk setiap enkripsi)

• Simpan key di Android Keystore atau gunakan asymmetric wrapping.

2. Jika tetap perlu transfer text-safe, encrypt → Base64( cipherText ), bukan sebaliknya.

3. Hindari menyimpan file terenkripsi di storage publik tanpa perlindungan tambahan.

4. Audit semua penggunaan Base64: pastikan hanya dipakai untuk data non-sensitive (image embedding, data URI).

Temuan 4— Penggunaan SHA-1 (MessageDigest.getInstance("SHA-1"))

Bukti singkat

MessageDigest md = MessageDigest.getInstance("SHA-1");

Mengapa ini berisiko & contoh eksploitasi

• SHA-1 panjang telah diketahui rentan terhadap collision attack, dua input berbeda dapat menghasilkan hash yang sama.
• Jika SHA-1 digunakan untuk tanda tangan, checksum, atau mekanisme integritas, penyerang bisa memanipulasi konten dan membuat hash tetap sama.
• Untuk password hashing, SHA-1 sangat tidak cocok perlu salt & algoritma kuat (bcrypt/argon2).

Dampak potensial

• Integritas dipalsukan, bypass verifikasi, potensi pembuatan collision untuk menyalahgunakan pemrosesan data.
• Jika digunakan untuk kunci derivation/password verification → sangat berisiko.

Rekomendasi mitigasi (developer)

1. Ganti SHA-1 dengan SHA-256/ SHA-3 jika hanya butuh hashing umum:

MessageDigest md = MessageDigest.getInstance("SHA-256");

2. Untuk penyimpanan password gunakan password hashing functions yang tahan brute-force seperti bcrypt, scrypt, atau Argon2 (server-side).

3. Untuk HMAC gunakan HmacSHA256:

Mac mac = Mac.getInstance("HmacSHA256");

4. Audit library yang menggunakan SHA-1, update dependency ke versi yang memakai algoritma modern.

Temuan 5— Penggunaan WebView API (WebView.findAddress(str))

Bukti singkat

import android.webkit.WebView;
return WebView.findAddress(str);

Mengapa ini berisiko & contoh eksploitasi

• WebView jika dikonfigurasi tanpa aman (mengaktifkan JavaScript, file access, addJavascriptInterface tanpa validasi) dapat membuka XSS, RCE, dan eksfiltrasi data lokal.
• Jika aplikasi memuat konten user-controlled ke WebView, skrip berbahaya dapat berjalan dalam konteks aplikasi.

Dampak potensial

• Eksekusi skrip berbahaya di konteks aplikasi → pencurian cookie, localStorage, atau akses fungsi Java native yang terekspos.
• Penyebaran malware via content yang dimuat.

Rekomendasi mitigasi (developer)

1. Default secure settings:

webView.getSettings().setJavaScriptEnabled(false); 
webView.getSettings().setAllowFileAccess(false); 
webView.getSettings().setAllowContentAccess(false);

2. Jika JavaScript diperlukan, batasi domain yang boleh dimuat (whitelist) dan gunakan shouldOverrideUrlLoading untuk validasi.

3. Gunakan Network Security Configuration untuk membatasi konektivitas dan enforce HTTPS.

4. Lakukan sanitasi input sebelum menampilkan konten di WebView.

Kesimpulan

Dari praktik analisis keamanan APK yang telah dilakukan menggunakan apktool dan jadx, dapat disimpulkan bahwa proses dekompilasi sangat efektif untuk mengidentifikasi potensi celah keamanan dalam aplikasi Android. Melalui langkah-langkah ini, berhasil ditemukan beberapa temuan penting seperti pengaturan allowBackup yang aktif, penggunaan algoritma hash lemah (SHA-1), serta adanya hardcoded string dan Base64 encoding yang berpotensi disalahgunakan. Praktik ini menunjukkan pentingnya pemeriksaan keamanan aplikasi secara menyeluruh sebelum distribusi agar risiko kebocoran data dan eksploitasi dapat diminimalisir.