Panduan Lengkap Android Pentesting dengan NoxPlayer: Setup Lab, ADB, Burp Suite, Frida, Static Analysis, dan Dynamic Analysis - Rebelsec – Cyber Security, Bug Bounty, Linux & Teknologi

Android penetration testing bukan sekadar mencari bug di sebuah aplikasi. Seorang mobile pentester perlu memahami bagaimana aplikasi Android bekerja, bagaimana aplikasi berkomunikasi dengan server, bagaimana data disimpan di perangkat, bagaimana autentikasi dan otorisasi diterapkan, serta bagaimana aplikasi merespons kondisi lingkungan yang berbeda.

Masalahnya, melakukan pengujian keamanan Android menggunakan perangkat fisik tidak selalu praktis.

Dalam sebuah assessment, tester mungkin perlu membandingkan beberapa versi Android, mencoba kondisi perangkat yang berbeda, melakukan debugging, mengamati traffic jaringan, mengulang skenario pengujian, atau mengembalikan environment ke kondisi sebelumnya.

Di sinilah Android emulator dapat menjadi salah satu komponen penting dalam security testing.

Salah satu emulator yang sering digunakan untuk kebutuhan pengujian dan eksperimen adalah NoxPlayer. NoxPlayer menyediakan fitur seperti Multi-Drive yang memungkinkan pengguna membuat beberapa instance emulator dengan konfigurasi Android yang berbeda. Dokumentasi resmi NoxPlayer menjelaskan bahwa Multi-Drive dapat digunakan untuk menjalankan beberapa emulator sekaligus dan memilih versi Android yang tersedia pada instalasi tertentu.

Namun, emulator bukan pengganti sempurna perangkat fisik.

Untuk pengujian keamanan profesional, emulator sebaiknya dipandang sebagai lab terkontrol yang membantu mempercepat proses analisis, bukan sebagai satu-satunya environment yang selalu mewakili perilaku perangkat Android nyata.

Artikel ini akan membahas konsep tersebut secara menyeluruh.

Kita akan mulai dari dasar Android pentesting, memahami fungsi emulator, menyiapkan NoxPlayer, mengenal ADB, menghubungkan emulator dengan Burp Suite, memahami peran Frida, membahas static dan dynamic analysis, memahami keterbatasan emulator, hingga menyusun workflow Android security testing yang lebih profesional.

Seluruh pembahasan teknis ditujukan untuk lab pribadi, aplikasi buatan sendiri, aplikasi latihan, atau sistem yang memang telah memberikan izin pengujian.

Daftar Isi

Apa Itu Android Penetration Testing?
Mengapa Emulator Penting dalam Android Pentesting?
Apa Itu NoxPlayer?
Kelebihan NoxPlayer untuk Lab Security Testing
Keterbatasan NoxPlayer
Memahami Arsitektur Android Secara Singkat
Tools yang Dibutuhkan
Persiapan Lab NoxPlayer
Memahami Multi-Drive
Memahami Root dalam Android Pentesting
Mengenal Android Debug Bridge
Verifikasi Koneksi ADB
Workflow Dasar Android Pentesting
Apa yang Akan Dibahas pada Bagian Berikutnya?

Apa Itu Android Penetration Testing?

Android penetration testing adalah proses pengujian keamanan terhadap aplikasi atau komponen Android untuk mengidentifikasi kelemahan yang dapat berdampak terhadap kerahasiaan, integritas, atau ketersediaan data dan fungsi aplikasi.

Berbeda dengan web penetration testing, mobile application security testing memiliki beberapa lapisan tambahan.

Tester tidak hanya berhadapan dengan server.

Ada setidaknya tiga area besar yang perlu dipahami:

Client-side application — aplikasi Android yang berjalan di perangkat.
Network communication — komunikasi antara aplikasi dan backend.
Backend/API — sistem server yang menyediakan layanan kepada aplikasi.

Selain ketiganya, terdapat juga penyimpanan lokal, permission, komponen Android, konfigurasi aplikasi, library pihak ketiga, mekanisme autentikasi, dan berbagai kontrol keamanan lainnya.

Karena itu, mobile pentesting sebaiknya tidak dipahami sebagai sekadar "mencari vulnerability di APK".

Tujuan sebenarnya adalah memahami security boundary aplikasi secara keseluruhan.

Android Pentesting Bukan Hanya Tentang APK

Ketika seseorang baru belajar Android security, biasanya perhatian pertama tertuju pada file APK.

APK memang penting.

Di dalamnya dapat terdapat berbagai komponen seperti:

AndroidManifest;
resources;
DEX bytecode;
native libraries;
assets;
konfigurasi;
sertifikat;
dan dependency aplikasi.

Namun APK hanyalah salah satu bagian dari keseluruhan sistem.

Sebuah aplikasi mobile modern dapat berkomunikasi dengan berbagai API dan service di backend.

Karena itu, seorang tester harus menghubungkan antara apa yang terlihat di aplikasi dengan apa yang terjadi di server.

Contohnya:

Mobile UI → Application Logic → Network Request → API → Backend → Database

Kerentanan dapat muncul di salah satu lapisan tersebut atau akibat interaksi antar-lapisan.

Mengapa Emulator Penting dalam Android Pentesting?

Bayangkan kamu ingin menguji sebuah aplikasi pada tiga kondisi berbeda.

Android versi pertama.
Android versi kedua.
Environment dengan konfigurasi berbeda.

Jika menggunakan perangkat fisik, kamu membutuhkan beberapa perangkat atau harus melakukan konfigurasi ulang berkali-kali.

Emulator membuat proses tersebut lebih mudah karena environment dapat dibuat secara virtual.

Android Emulator sendiri secara resmi digunakan untuk menjalankan Android secara virtual di komputer dan memungkinkan pengujian pada berbagai versi platform dan ukuran perangkat.

NoxPlayer menawarkan pendekatan serupa dengan fokus pada penggunaan emulator yang mudah dikelola, termasuk fitur Multi-Drive untuk membuat dan menjalankan beberapa instance. Dokumentasi NoxPlayer menjelaskan bahwa Multi-Drive memungkinkan beberapa emulator dijalankan pada PC yang sama dan menyediakan pilihan versi Android tertentu.

Manfaat emulator untuk security testing

Environment dapat dibuat ulang.
Konfigurasi dapat dipisahkan antar-instance.
Testing dapat dilakukan tanpa perangkat fisik tambahan.
ADB dapat digunakan untuk debugging dan observasi.
Traffic aplikasi dapat diarahkan ke proxy lab.
Dynamic analysis dapat dilakukan dalam environment terkontrol.
Reset environment relatif mudah.

Namun manfaat tersebut tidak berarti emulator selalu identik dengan perangkat fisik.

Perbedaan hardware, sensor, arsitektur CPU, implementasi firmware, dan mekanisme anti-emulator dapat menyebabkan hasil pengujian berbeda.

Apa Itu NoxPlayer?

NoxPlayer adalah emulator Android yang berjalan di komputer. Platform ini awalnya sangat dikenal sebagai emulator untuk menjalankan aplikasi Android di desktop, tetapi konsep emulator tersebut juga dapat dimanfaatkan sebagai bagian dari lab pengujian keamanan.

Untuk kebutuhan security testing, fitur yang menarik bukan hanya kemampuan menjalankan aplikasi.

Yang lebih penting adalah kemampuan mengontrol environment.

Beberapa fitur NoxPlayer yang relevan untuk lab antara lain:

Multi-Drive.
Multiple emulator instances.
Pilihan konfigurasi Android tertentu.
ADB connectivity.
Pengaturan jaringan.
Snapshot atau backup melalui mekanisme yang tersedia pada environment.
Kontrol konfigurasi instance.

Dokumentasi resmi NoxPlayer menunjukkan bahwa Multi-Drive memungkinkan pengguna membuat beberapa instance emulator dan memilih konfigurasi Android yang tersedia.

NoxPlayer bukan security tool khusus

Hal ini penting untuk dipahami.

NoxPlayer bukan sebuah tool penetration testing khusus.

Ia adalah environment.

Tools seperti ADB, Burp Suite, Frida, JADX, apktool, dan tool analisis lainnya kemudian digunakan di atas atau di sekitar environment tersebut.

Dengan kata lain:

NoxPlayer = lab environment

ADB = interface untuk berinteraksi dengan Android

Burp Suite = network inspection/proxy

Frida = dynamic instrumentation

JADX/apktool = static analysis support

Kombinasi berbagai komponen tersebut membentuk workflow mobile security testing.

Kelebihan NoxPlayer untuk Lab Android Security

1. Mudah membuat beberapa instance

Multi-Drive memungkinkan beberapa emulator dikelola dari satu komputer. Ini berguna ketika tester ingin memisahkan environment.

Misalnya:

Instance A untuk baseline.
Instance B untuk instrumentation.
Instance C untuk eksperimen konfigurasi.

Dokumentasi resmi NoxPlayer memang menyediakan fitur untuk membuat, menyalin, menghapus, menjalankan, dan mengatur instance melalui Multi-Drive.

2. Environment lebih mudah diulang

Dalam security testing, reproducibility sangat penting.

Jika sebuah observasi terjadi, tester harus dapat mengulang kondisi tersebut.

Environment virtual membantu membuat proses tersebut lebih terkontrol.

3. Cocok untuk eksperimen

Ketika belajar Android security, kesalahan konfigurasi merupakan hal yang biasa.

Dengan environment lab, tester dapat bereksperimen tanpa khawatir merusak perangkat pribadi utama.

4. Terintegrasi dengan workflow ADB

ADB menjadi salah satu komponen fundamental dalam Android testing. Android Developers menjelaskan ADB sebagai bagian dari Android development environment untuk melakukan debugging dan berinteraksi dengan perangkat Android.

Keterbatasan NoxPlayer

Walaupun praktis, NoxPlayer bukan solusi universal.

Perbedaan dengan perangkat fisik

Aplikasi tertentu dapat mendeteksi karakteristik emulator.

Perbedaan dapat muncul pada:

hardware properties;
sensor;
CPU architecture;
GPU behavior;
camera;
telephony;
location;
keystore;
hardware-backed security.

Akibatnya, aplikasi yang berjalan normal pada perangkat fisik dapat berperilaku berbeda di emulator.

Perbedaan arsitektur

Arsitektur CPU juga penting.

Frida sendiri mencatat bahwa emulator dapat digunakan untuk Android instrumentation, tetapi untuk emulator tertentu kompatibilitas arsitektur perlu diperhatikan. Dokumentasi Frida saat ini secara khusus menyebut image emulator Google Android 9 sebagai salah satu opsi yang direkomendasikan dan mencatat bahwa x86 dapat bekerja tetapi telah melalui pengujian yang lebih terbatas.

Ini berarti tester tidak boleh berasumsi bahwa seluruh tool akan bekerja identik pada setiap emulator.

Hardware-backed security

Perangkat modern dapat memiliki mekanisme keamanan yang bergantung pada hardware.

Emulator mungkin tidak merepresentasikan mekanisme tersebut secara sempurna.

Karena itu, pengujian tertentu tetap membutuhkan perangkat fisik.

Memahami Arsitektur Android Sebelum Pentesting

Sebelum menggunakan tools, pahami terlebih dahulu bagaimana aplikasi Android bekerja.

Secara sederhana, sebuah aplikasi Android dapat memiliki:

Activity;
Service;
Broadcast Receiver;
Content Provider;
Application class;
native library;
resources;
dan berbagai dependency.

Semua komponen tersebut dideklarasikan atau berkaitan dengan konfigurasi aplikasi.

AndroidManifest.xml

AndroidManifest.xml merupakan salah satu file paling penting dalam analisis aplikasi.

Manifest dapat memberikan informasi mengenai:

package name;
application component;
permission;
exported component;
intent filter;
minimum SDK;
target SDK;
dan konfigurasi lain.

Dalam static analysis, manifest sering menjadi salah satu titik awal.

DEX

Kode Java atau Kotlin pada aplikasi Android biasanya dikompilasi menjadi format yang dapat dieksekusi oleh runtime Android.

Static analysis dapat digunakan untuk mempelajari struktur tersebut.

Native library

Aplikasi juga dapat memiliki library native dalam bentuk file seperti:

lib/arm64-v8a/*.so
lib/armeabi-v7a/*.so
lib/x86/*.so
lib/x86_64/*.so

Library native penting karena sebagian logic aplikasi dapat berada di sana.

Tools yang Dibutuhkan

Untuk membuat lab Android pentesting yang cukup lengkap, kamu tidak perlu langsung memasang puluhan tools.

Mulailah dari komponen fundamental.

1. NoxPlayer

Berfungsi sebagai Android environment.

Gunakan sumber resmi NoxPlayer untuk memperoleh installer. Dokumentasi NoxPlayer secara eksplisit menyarankan pengguna mengunduh dari website resminya.

2. Android SDK Platform Tools

Komponen terpentingnya adalah ADB.

ADB memungkinkan komputer berkomunikasi dengan environment Android.

3. Burp Suite

Burp Suite dapat digunakan sebagai HTTP/S proxy untuk mengamati komunikasi aplikasi.

Dokumentasi resmi PortSwigger menjelaskan bahwa Burp Proxy dapat berfungsi sebagai proxy antara client dan target, memungkinkan traffic HTTP/S diintercept, diperiksa, dan dimodifikasi dalam konteks pengujian.

4. Frida

Frida merupakan dynamic instrumentation toolkit yang dapat digunakan untuk mengamati dan memodifikasi perilaku aplikasi saat runtime dalam environment pengujian.

Dokumentasi Frida menyediakan workflow Android berbasis ADB dan frida-server.

5. Static analysis tools

Beberapa kategori tools yang dapat digunakan antara lain:

DEX decompiler.
APK analyzer.
Resource decoder.
String analyzer.
Native binary analyzer.

Tujuannya bukan menggunakan tool sebanyak mungkin, melainkan memilih tool berdasarkan pertanyaan yang ingin dijawab.

Persiapan Lab NoxPlayer

Sebelum menginstal aplikasi target, buatlah environment yang memang ditujukan untuk security testing.

Jangan menggunakan akun pribadi atau data sensitif jika tidak diperlukan.

Checklist awal

☐ Komputer mendukung virtualisasi.
☐ NoxPlayer diperoleh dari sumber resmi.
☐ Android SDK Platform Tools tersedia.
☐ ADB dapat dijalankan dari terminal.
☐ Burp Suite tersedia jika diperlukan.
☐ Frida tersedia jika diperlukan.
☐ Aplikasi latihan atau aplikasi yang telah diizinkan sudah disiapkan.
☐ Environment dipisahkan dari data pribadi.

Android Emulator sendiri juga membutuhkan dukungan sistem yang sesuai. Android Developers menyarankan pemeriksaan system requirements sebelum membuat dan menjalankan virtual device.

Memilih Spesifikasi Komputer

Emulator membutuhkan resource komputer.

Jika komputer terlalu terbatas, menjalankan emulator bersamaan dengan Burp Suite, decompiler, IDE, dan tool lain dapat menyebabkan sistem menjadi lambat.

Komponen yang paling perlu diperhatikan:

CPU;
RAM;
storage;
virtualization support;
GPU;
dan ruang penyimpanan.

Jangan langsung menjalankan banyak instance

Multi-Drive memang memungkinkan beberapa instance, tetapi jumlah instance yang ideal tergantung kemampuan komputer.

Dokumentasi NoxPlayer juga mengingatkan bahwa jumlah Multi-Drive harus disesuaikan dengan spesifikasi PC karena terlalu banyak instance dapat menyebabkan masalah performa.

Untuk belajar, satu instance sudah lebih dari cukup.

Memahami Multi-Drive NoxPlayer

Multi-Drive adalah salah satu fitur yang paling menarik untuk lab.

Konsepnya sederhana:

Satu instalasi NoxPlayer → beberapa Android instance.

Dokumentasi resmi NoxPlayer menyebut Multi-Drive sebagai fitur untuk menjalankan lebih dari satu emulator secara bersamaan dan memungkinkan pengguna menambahkan instance dengan versi Android tertentu yang tersedia.

Mengapa berguna untuk pentesting?

Karena kamu dapat memisahkan eksperimen.

Contoh:

Instance	Tujuan
Lab-Baseline	Pengujian aplikasi dalam kondisi standar
Lab-Network	Pengujian traffic melalui proxy
Lab-Dynamic	Eksperimen instrumentation

Pemisahan seperti ini membantu menjaga eksperimen tetap terorganisasi.

Memahami Root dalam Android Pentesting

Root sering dibicarakan dalam Android security karena akses yang lebih tinggi dapat membantu tester mengamati bagian sistem yang tidak tersedia pada environment biasa.

Namun root bukan tujuan utama pentesting.

Root hanyalah salah satu kondisi environment.

Kenapa root berguna?

Dalam lab, akses dengan privilege tinggi dapat membantu aktivitas seperti:

mengamati file aplikasi;
memeriksa proses;
menjalankan instrumentation tertentu;
mengakses area sistem untuk kebutuhan debugging;
dan melakukan eksperimen security research.

Kenapa root juga menjadi keterbatasan?

Karena aplikasi produksi dapat memiliki mekanisme yang mendeteksi kondisi tersebut.

Selain itu, environment rooted tidak selalu merepresentasikan kondisi pengguna normal.

Karena itu, idealnya tester memiliki setidaknya dua perspektif:

Non-rooted baseline
Controlled rooted lab

Dengan membandingkan keduanya, tester dapat memahami apakah suatu perilaku hanya terjadi karena environment lab.

Mengenal Android Debug Bridge atau ADB

Android Debug Bridge (ADB) adalah salah satu tools paling fundamental dalam Android testing.

ADB memungkinkan komputer berkomunikasi dengan perangkat atau emulator Android.

Android Developers mendokumentasikan ADB sebagai bagian dari workflow debugging dan pengujian Android.

Secara konseptual, hubungan tersebut dapat digambarkan sebagai:

Computer → ADB → Android Emulator

Dengan ADB, tester dapat melakukan berbagai aktivitas administratif dan debugging yang diperlukan dalam lab.

Memeriksa apakah ADB tersedia

Di terminal, perintah berikut dapat digunakan untuk memeriksa versi ADB:

adb version

Jika ADB telah terpasang dan PATH sudah benar, terminal akan menampilkan informasi versi.

Memeriksa Device yang Terhubung

Setelah emulator berjalan, perintah dasar berikut dapat digunakan:

adb devices

Output umumnya akan menampilkan daftar device yang dikenali ADB.

Contoh konseptual:

List of devices attached
emulator-device    device

Nama atau identifier yang muncul dapat berbeda tergantung environment.

Jika device tidak muncul

Jangan langsung menganggap NoxPlayer rusak.

Periksa beberapa hal:

Apakah emulator sedang berjalan?
Apakah ADB dapat menemukan instance?
Apakah terdapat konflik antara beberapa instalasi ADB?
Apakah port atau koneksi ADB sesuai?
Apakah emulator mengizinkan debugging?
Apakah firewall mengganggu koneksi?

Gunakan pendekatan troubleshooting bertahap.

Melihat Informasi Android melalui ADB

ADB juga dapat digunakan untuk membaca informasi environment.

Contoh:

adb shell getprop

Perintah tersebut dapat menghasilkan banyak informasi.

Untuk kebutuhan pembelajaran, informasi yang menarik antara lain:

Android version;
device model;
CPU architecture;
build information;
dan konfigurasi sistem lainnya.

Untuk melihat versi Android secara lebih spesifik, konsepnya dapat menggunakan property sistem yang relevan.

Informasi tersebut berguna ketika troubleshooting compatibility.

Mengapa ADB Sangat Penting?

Karena hampir seluruh workflow Android security testing membutuhkan cara untuk berinteraksi dengan environment.

ADB menjadi jembatan tersebut.

Contoh workflow:

NoxPlayer → ADB → Install APK → Jalankan aplikasi → Observasi → Ambil log → Analisis

Untuk dynamic instrumentation:

NoxPlayer → ADB → Frida environment → Instrumentation → Observation

Untuk network testing:

NoxPlayer → Proxy Configuration → Burp Suite → HTTP/S Observation

Menginstal APK ke Lab

Untuk aplikasi latihan yang memang kamu miliki atau diizinkan untuk diuji, APK dapat dipasang ke emulator melalui mekanisme Android/ADB.

Secara umum:

adb install nama-aplikasi.apk

Jika instalasi berhasil, aplikasi dapat muncul di launcher emulator.

Untuk aplikasi yang memiliki dependency tertentu, proses instalasi dapat membutuhkan konfigurasi tambahan.

Catatan penting mengenai APK

Jangan mengunduh APK sembarangan dari sumber tidak terpercaya hanya karena ingin melakukan latihan.

Gunakan:

aplikasi buatan sendiri;
aplikasi latihan yang memang dibuat untuk security testing;
sample resmi;
atau aplikasi yang kamu memiliki izin untuk analisis.

Lab Vulnerable App untuk Belajar

Salah satu metode terbaik mempelajari Android pentesting adalah menggunakan aplikasi yang memang sengaja dibuat rentan.

Keuntungan pendekatan ini:

legal untuk latihan sesuai lisensinya;
vulnerability memang dirancang untuk pembelajaran;
hasil dapat direproduksi;
tidak ada risiko terhadap sistem produksi;
dan tester dapat fokus pada metodologi.

Dengan lab seperti ini, kamu dapat belajar konsep seperti:

insecure storage;
weak authentication;
improper authorization;
insecure communication;
exposed components;
hardcoded secrets;
dan masalah konfigurasi.

Workflow Dasar Android Pentesting

Setelah environment tersedia, jangan langsung mencari vulnerability.

Gunakan workflow yang terstruktur.

Scope — pastikan aplikasi memang boleh diuji.
Recon — kumpulkan informasi aplikasi.
Static analysis — pahami APK tanpa menjalankannya.
Environment setup — siapkan emulator dan tools.
Dynamic analysis — observasi aplikasi saat berjalan.
Network analysis — pahami komunikasi aplikasi.
Data storage analysis — periksa bagaimana data lokal digunakan.
Component analysis — pahami komponen Android.
Validation — konfirmasi dugaan.
Evidence — simpan bukti.
Reporting — dokumentasikan risiko dan rekomendasi.

Urutan tersebut tidak selalu linear.

Dalam assessment nyata, static dan dynamic analysis sering dilakukan secara berulang.

Static Analysis vs Dynamic Analysis

Aspek	Static Analysis	Dynamic Analysis
Target	APK/code/resources	Aplikasi saat berjalan
Execution	Tidak wajib menjalankan aplikasi	Aplikasi berjalan
Fokus	Struktur dan implementasi	Perilaku runtime
Contoh	Manifest, strings, code	Process, network, runtime behavior
Kelebihan	Melihat banyak bagian aplikasi	Melihat perilaku aktual
Keterbatasan	Logic runtime tertentu sulit terlihat	Tidak semua code path mudah dipicu

Kombinasi keduanya jauh lebih kuat daripada hanya menggunakan satu metode.

Kenapa Static Analysis Harus Dilakukan Lebih Awal?

Static analysis dapat membantu membangun mental model sebelum aplikasi dijalankan.

Misalnya kamu menemukan:

beberapa Activity;
beberapa Service;
API base URL;
permission tertentu;
third-party SDK;
native library.

Informasi tersebut dapat membantu menentukan area yang perlu diamati saat dynamic analysis.

Dengan demikian, tester tidak menjalankan aplikasi secara acak.

Kenapa Dynamic Analysis Tetap Dibutuhkan?

Karena kode tidak selalu menjelaskan seluruh perilaku aplikasi.

Sebuah nilai dapat dibentuk saat runtime.

Endpoint dapat diperoleh dari konfigurasi dinamis.

Logic tertentu dapat hanya berjalan setelah kondisi tertentu terpenuhi.

Komunikasi jaringan juga baru dapat diamati ketika aplikasi benar-benar berinteraksi dengan backend.

Karena itu:

Static analysis menjelaskan kemungkinan struktur.

Dynamic analysis menjelaskan perilaku aktual.

Memahami Peran Burp Suite

Dalam mobile security testing, Burp Suite sering digunakan untuk memahami komunikasi HTTP/S antara aplikasi dan backend.

PortSwigger mendokumentasikan workflow mobile testing yang menggunakan perangkat atau emulator sebagai client yang diarahkan melalui Burp Proxy.

Secara sederhana:

Android App → Burp Proxy → Internet/Test Server

Dengan konfigurasi yang benar, tester dapat melihat request dan response yang memang melewati proxy.

Apa yang dapat dipelajari dari traffic?

endpoint API;
HTTP method;
request headers;
response headers;
parameter;
authentication flow;
session behavior;
error response;
data format;
dan pola komunikasi aplikasi.

Traffic analysis sangat membantu menghubungkan mobile application dengan backend.

Konsep Proxy pada Android Emulator

Secara konseptual, komputer menjalankan Burp Suite pada sebuah port.

Emulator kemudian dikonfigurasi agar menggunakan komputer tersebut sebagai HTTP/S proxy.

Dokumentasi PortSwigger menjelaskan bahwa pada emulator, konfigurasi proxy dapat dilakukan melalui pengaturan jaringan emulator dan diarahkan ke alamat IP mesin yang menjalankan Burp serta port listener yang digunakan.

Jangan menganggap port tertentu selalu wajib digunakan.

Port dapat disesuaikan dengan konfigurasi lab.

Burp CA Certificate dan HTTPS

HTTPS menggunakan TLS untuk memastikan komunikasi terlindungi.

Ketika tester ingin melihat HTTPS traffic di dalam lab, Burp membutuhkan CA certificate yang dipercaya oleh environment Android.

PortSwigger menjelaskan bahwa setiap instalasi Burp memiliki CA sendiri dan CA tersebut dapat diekspor untuk digunakan pada perangkat atau environment pengujian.

Namun ada perbedaan penting antara:

Android mempercayai CA yang ditambahkan pengguna;
aplikasi mempercayai user-added CA;
aplikasi menggunakan network security configuration tertentu;
dan aplikasi menerapkan certificate pinning.

Karena itu, berhasil memasang CA belum tentu berarti seluruh HTTPS traffic aplikasi akan dapat dilihat.

Certificate Pinning: Konsep Dasar

Certificate pinning merupakan mekanisme yang dapat digunakan aplikasi untuk memperketat validasi identitas server.

Secara konseptual, aplikasi tidak hanya mengandalkan trust store umum, tetapi dapat mengharapkan sertifikat atau public key tertentu.

Akibatnya, proxy interception dapat gagal walaupun CA proxy telah dipasang.

PortSwigger sendiri mencatat bahwa mobile HTTPS interception dapat menjadi kompleks dan salah satu penyebabnya adalah TLS certificate pinning.

Dalam lab yang memang kamu miliki atau diizinkan untuk diuji, kondisi tersebut dapat dipelajari untuk memahami bagaimana aplikasi menerapkan kontrol TLS.

Untuk artikel edukasi ini, fokusnya adalah memahami konsep dan proses validasi, bukan memberikan resep untuk menghindari kontrol keamanan aplikasi pihak lain.

Memahami Frida

Frida adalah dynamic instrumentation toolkit yang dapat membantu security researcher mengamati dan menganalisis perilaku aplikasi ketika berjalan.

Dalam konteks Android, Frida dapat digunakan bersama ADB dan frida-server.

Dokumentasi resmi Frida menunjukkan workflow yang meliputi pemeriksaan arsitektur perangkat, penggunaan ADB, penempatan frida-server, pemberian permission, menjalankan server, dan kemudian memeriksa proses menggunakan tool Frida.

Kenapa dynamic instrumentation berguna?

Karena tidak semua informasi dapat diperoleh dengan membaca APK saja.

Dengan instrumentation, researcher dapat mempelajari:

fungsi yang dipanggil;
argument tertentu;
return value;
alur eksekusi;
perilaku runtime;
dan interaksi antar-komponen.

Frida pada dasarnya membantu membuka perspektif baru:

"Apa yang sebenarnya dilakukan aplikasi ketika berjalan?"

Arsitektur Frida dalam Lab Android

Secara sederhana:

Desktop → Frida Client → ADB/Transport → Frida Server → Android Process

Jika arsitektur atau binary tidak sesuai, koneksi dapat gagal.

Karena itu, salah satu langkah penting adalah mengetahui ABI atau arsitektur CPU environment.

Frida mendokumentasikan penggunaan adb shell getprop ro.product.cpu.abilist sebagai salah satu cara untuk memeriksa arsitektur yang tersedia.

Kenapa Arsitektur CPU Penting?

Bayangkan kamu memiliki binary untuk satu arsitektur tetapi emulator menggunakan arsitektur berbeda.

Binary tersebut mungkin tidak dapat dijalankan.

Beberapa arsitektur yang umum ditemui dalam Android antara lain:

armeabi-v7a;
arm64-v8a;
x86;
x86_64.

Karena itu, sebelum memasang tool low-level, selalu periksa environment terlebih dahulu.

Checklist Environment Sebelum Mulai Testing

☐ NoxPlayer berjalan normal.
☐ Instance Android sudah dipilih.
☐ ADB mendeteksi emulator.
☐ Versi Android sudah diketahui.
☐ Arsitektur CPU sudah diketahui.
☐ APK latihan tersedia.
☐ Burp Suite tersedia jika diperlukan.
☐ Proxy listener sudah disiapkan jika diperlukan.
☐ CA certificate lab sudah dipahami.
☐ Frida tersedia jika diperlukan.
☐ Data pribadi tidak digunakan dalam lab.
☐ Scope pengujian jelas.

Kesalahan Pemula Saat Membuat Lab Android Pentesting

1. Menginstal semua tools sekaligus

Ini membuat troubleshooting menjadi sulit.

Lebih baik lakukan secara bertahap:

NoxPlayer → ADB → APK → Burp → Frida → Static Analysis

2. Tidak mengetahui arsitektur emulator

Ini sering menyebabkan binary atau instrumentation tidak kompatibel.

3. Tidak membuat environment terpisah

Gunakan instance khusus untuk security testing.

4. Tidak menyimpan catatan

Catat konfigurasi yang berhasil.

5. Menganggap emulator sama dengan perangkat nyata

Ini salah satu kesalahan konseptual terbesar.

6. Langsung fokus pada bypass

Pahami mekanisme keamanan terlebih dahulu.

Jika kamu belum memahami mengapa certificate pinning digunakan, mempelajari cara menghindarinya tidak banyak memberikan nilai edukasi.

Emulator vs Physical Device

Aspek	Emulator	Physical Device
Biaya	Relatif rendah	Lebih tinggi
Reset environment	Mudah	Lebih merepotkan
Multi-version testing	Mudah	Membutuhkan beberapa perangkat
Sensor nyata	Terbatas/berbeda	Lebih representatif
Hardware-backed security	Tidak selalu representatif	Lebih representatif
Debugging	Sangat praktis	Praktis dengan konfigurasi
Anti-emulator behavior	Dapat terdeteksi	Tidak memiliki karakteristik emulator

Karena itu, pendekatan terbaik untuk assessment serius biasanya bukan memilih salah satu secara absolut.

Gunakan emulator untuk rapid iteration dan gunakan physical device ketika pengujian membutuhkan validasi hardware atau kondisi nyata.

NoxPlayer sebagai Lab, Bukan Bukti Final

Ini adalah prinsip penting yang sering dilupakan.

Jika sebuah aplikasi berjalan dengan perilaku tertentu di NoxPlayer, jangan langsung menyimpulkan bahwa seluruh pengguna Android akan mengalami hal yang sama.

Hasil emulator harus diberi konteks.

Contohnya:

"Pada environment emulator Android X dengan konfigurasi Y, aplikasi menunjukkan perilaku Z."

Kalimat tersebut jauh lebih akurat daripada:

"Aplikasi selalu melakukan Z."

Perbedaan bahasa tersebut sangat penting dalam laporan profesional.

Workflow Belajar yang Direkomendasikan

Jika kamu benar-benar baru belajar Android pentesting, gunakan urutan berikut:

Pelajari dasar Android.
Pelajari APK dan Manifest.
Instal NoxPlayer.
Pelajari ADB.
Instal aplikasi latihan.
Pelajari static analysis.
Pelajari HTTP dan API.
Hubungkan emulator dengan Burp.
Pelajari network analysis.
Pelajari dynamic analysis.
Pelajari Frida.
Pelajari secure storage.
Pelajari authentication dan authorization.
Pelajari Android component security.
Pelajari reporting.

Urutan tersebut membangun fondasi secara bertahap.

Kesimpulan Bagian 1

NoxPlayer dapat menjadi titik awal yang praktis untuk membangun lab Android penetration testing, terutama bagi pembelajar yang ingin memahami hubungan antara aplikasi Android, emulator, ADB, proxy, dan dynamic analysis.

Namun emulator bukan pengganti universal perangkat fisik.

Security testing yang baik membutuhkan pemahaman mengenai perbedaan environment, arsitektur CPU, Android version, hardware behavior, serta mekanisme keamanan yang diterapkan aplikasi.

Di tahap awal, fokus utama bukanlah menghafal perintah.

Fokuslah pada pemahaman:

Bagaimana aplikasi bekerja?

Data apa yang diproses?

Ke mana data dikirim?

Bagaimana aplikasi menyimpan data?

Bagaimana aplikasi menentukan siapa yang boleh melakukan sesuatu?

Kontrol keamanan apa yang diterapkan?

Setelah pertanyaan tersebut dipahami, tools seperti ADB, Burp Suite, Frida, dan static analysis tools akan menjadi jauh lebih mudah dipahami.

Pada Bagian 2, pembahasan dapat dilanjutkan ke tahap yang lebih praktis: static analysis APK, AndroidManifest, permission, exported components, local storage, API discovery, konfigurasi Burp Suite, analisis HTTPS, log Android, dan dasar dynamic analysis.

Seluruh contoh tetap diarahkan pada aplikasi latihan atau environment yang memiliki izin pengujian.

Bagian 2 — Static Analysis, AndroidManifest, API, Storage, dan Dynamic Analysis

Pada bagian sebelumnya kita sudah membahas konsep dasar Android penetration testing, alasan menggunakan emulator, fungsi NoxPlayer, ADB, Burp Suite, dan Frida, serta perbedaan antara emulator dengan perangkat Android fisik.

Sekarang kita masuk ke tahap yang lebih penting dalam workflow seorang mobile security tester, yaitu memahami aplikasi sebelum melakukan pengujian lebih jauh.

Banyak pemula langsung menjalankan aplikasi kemudian mencoba berbagai hal secara acak. Cara tersebut memang bisa menghasilkan temuan, tetapi tidak efisien.

Pendekatan yang lebih baik adalah membangun mental model terlebih dahulu.

Bayangkan kamu mendapatkan sebuah APK dari aplikasi latihan yang memang boleh diuji. Sebelum menjalankannya, ada beberapa pertanyaan yang sebaiknya dijawab:

Aplikasi ini memiliki komponen apa saja?
Permission apa yang diminta?
Activity apa yang tersedia?
Apakah ada komponen yang dapat diakses aplikasi lain?
Apakah aplikasi berkomunikasi dengan API tertentu?
Apakah terdapat konfigurasi sensitif?
Bagaimana data disimpan secara lokal?
Apakah terdapat library native?
Apakah aplikasi menggunakan third-party SDK?
Bagaimana mekanisme autentikasinya?

Jawaban atas pertanyaan tersebut dapat membantu menentukan area yang perlu diperiksa ketika aplikasi dijalankan.

Apa Itu Static Analysis pada Android?

Static analysis adalah proses menganalisis aplikasi tanpa harus menjalankan seluruh logic aplikasi tersebut.

Dalam konteks Android, objek yang dianalisis dapat berupa:

APK;
AndroidManifest.xml;
DEX;
resources;
strings;
assets;
native libraries;
configuration files;
dan dependency.

Tujuan static analysis bukan sekadar mencari string seperti password atau api_key.

Tujuan utamanya adalah memahami bagaimana aplikasi dibangun dan menemukan area yang membutuhkan pemeriksaan lebih lanjut.

Static analysis sebagai peta

Anggap aplikasi sebagai sebuah gedung.

Static analysis adalah proses mempelajari denah gedung tersebut sebelum masuk.

Kamu ingin mengetahui:

berapa banyak pintu;
ruangan apa saja yang tersedia;
mana pintu utama;
mana pintu yang tidak terlihat;
dan bagaimana ruangan saling terhubung.

Dalam aplikasi Android, konsep tersebut dapat diterjemahkan menjadi:

Activity;
Service;
Broadcast Receiver;
Content Provider;
Intent;
deep link;
API endpoint;
storage;
dan native library.

Memahami Struktur APK

APK adalah paket aplikasi Android.

Secara sederhana, APK dapat dipandang sebagai container yang berisi berbagai komponen aplikasi.

Beberapa file dan direktori yang sering ditemui antara lain:

AndroidManifest.xml
classes.dex
resources.arsc
res/
assets/
lib/
META-INF/

Struktur sebenarnya dapat berbeda tergantung aplikasi dan proses build.

AndroidManifest.xml

Manifest memberikan informasi penting mengenai aplikasi dan komponennya.

classes.dex

File DEX berisi bytecode yang digunakan oleh runtime Android.

resources

Berisi berbagai resource aplikasi seperti string, layout, drawable, dan resource lainnya.

assets

Direktori ini dapat berisi file yang dibundel bersama aplikasi.

lib

Direktori ini dapat berisi native libraries.

Contohnya:

lib/
├── arm64-v8a/
├── armeabi-v7a/
├── x86/
└── x86_64/

Keberadaan native library merupakan indikasi bahwa sebagian functionality aplikasi mungkin diimplementasikan menggunakan native code.

Menganalisis AndroidManifest.xml

Jika kamu hanya memiliki waktu terbatas untuk melakukan preliminary assessment terhadap sebuah APK, AndroidManifest.xml adalah salah satu tempat yang sangat berguna untuk memulai.

Manifest dapat membantu menjawab pertanyaan seperti:

Apa package name aplikasi?
Versi minimum Android yang didukung?
Target SDK?
Permission apa yang diminta?
Activity apa yang tersedia?
Service apa yang tersedia?
Receiver apa yang tersedia?
Content Provider apa yang tersedia?
Apakah terdapat intent filter?
Komponen mana yang dapat diakses dari luar?

Package name

Package name merupakan identifier aplikasi dalam environment Android.

Contohnya dapat berbentuk:

com.example.trainingapp

Package name sangat berguna ketika menggunakan ADB maupun tools analisis lainnya.

Menganalisis Permission

Permission merupakan mekanisme Android yang membatasi akses aplikasi terhadap capability atau resource tertentu.

Dalam security assessment, permission perlu dilihat berdasarkan konteks bisnis aplikasi.

Jangan langsung menyimpulkan bahwa setiap permission berlebihan adalah vulnerability.

Misalnya, aplikasi kamera memang dapat membutuhkan akses kamera.

Aplikasi navigasi mungkin membutuhkan lokasi.

Aplikasi komunikasi mungkin membutuhkan notification atau contact-related capability.

Pertanyaan yang lebih tepat adalah:

"Apakah permission yang diminta memang diperlukan untuk fungsi aplikasi?"

Contoh kategori permission

Camera;
Location;
Microphone;
Contacts;
Storage;
Notifications;
Bluetooth;
Network;
dan berbagai capability lainnya.

Dalam laporan profesional, permission sebaiknya dianalisis berdasarkan least privilege.

Memahami Android Components

Android menggunakan beberapa jenis application component utama.

1. Activity

Activity biasanya merepresentasikan satu layar atau bagian dari user interface aplikasi.

Namun Activity bukan sekadar halaman.

Activity dapat menjadi entry point yang dipanggil melalui Intent.

2. Service

Service digunakan untuk menjalankan pekerjaan tertentu yang tidak selalu berhubungan langsung dengan UI.

3. Broadcast Receiver

Receiver memungkinkan aplikasi merespons broadcast tertentu.

4. Content Provider

Content Provider menyediakan mekanisme untuk mengelola atau berbagi data antara aplikasi.

Dalam security testing, keempat jenis komponen tersebut perlu dipahami karena konfigurasi yang tidak tepat dapat memperluas attack surface aplikasi.

Apa Itu Exported Component?

Salah satu konsep penting dalam Android security adalah component exposure.

Sebuah component yang dapat diakses dari aplikasi lain harus memiliki alasan dan kontrol yang tepat.

Jika suatu component tidak seharusnya dapat diakses dari luar tetapi ternyata terbuka, hal tersebut dapat menjadi area pemeriksaan.

Namun sekali lagi:

Exported bukan otomatis vulnerability.

Penilaian harus mempertimbangkan:

fungsi component;
permission protection;
input validation;
authorization;
data yang dapat diakses;
dan dampak bisnis.

Contoh pola berpikir

Jangan berpikir:

"Component exported = vulnerability."

Gunakan pertanyaan:

"Apa yang dapat dilakukan pihak lain jika component ini dapat dipanggil?"

Itulah cara berpikir security tester.

Memahami Intent

Intent adalah salah satu mekanisme penting dalam Android untuk meminta action dari component lain.

Intent dapat digunakan untuk:

membuka Activity;
menjalankan Service;
mengirim broadcast;
dan membawa data antar-component.

Dalam security testing, Intent menarik karena data yang dikirim melalui Intent dapat menjadi input bagi component lain.

Pertanyaan pentingnya adalah:

Apakah input divalidasi?
Apakah component memerlukan authentication?
Apakah authorization diterapkan?
Apakah data sensitif dapat dikirim melalui Intent?
Apakah aplikasi mempercayai input dari caller?

Deep Link dan App Link

Modern Android application sering menyediakan link yang dapat membuka bagian tertentu dari aplikasi.

Contohnya:

https://example.test/account/profile

Ketika link tersebut dibuka, Android dapat mengarahkan pengguna ke component tertentu.

Dalam security assessment, deep link perlu diperiksa karena parameter URL dapat menjadi input aplikasi.

Contohnya:

https://example.test/reset?id=123

Yang perlu dianalisis bukan hanya apakah link tersebut bekerja.

Tanyakan:

Bagaimana parameter diproses?
Apakah authentication diperlukan?
Apakah authorization diperiksa?
Apakah data sensitif muncul?
Apakah aplikasi mempercayai parameter dari URL?

Menganalisis Strings dalam APK

String analysis dapat menjadi cara cepat untuk memperoleh gambaran awal mengenai aplikasi.

Beberapa string yang menarik untuk diperhatikan antara lain:

domain;
URL;
API path;
error message;
feature flag;
configuration value;
environment identifier;
dan nama service.

Contoh:

https://api.example.test
https://staging.example.test
/api/v1/login
/api/v1/profile
/api/v1/upload

String seperti itu belum tentu merupakan vulnerability.

Namun informasi tersebut dapat membantu membangun attack surface map.

Hardcoded Secret: Jangan Langsung Menyimpulkan

Salah satu hal yang sering dicari oleh pemula adalah password atau API key yang tersimpan di dalam APK.

Memang, credential yang benar-benar sensitif dan dapat digunakan untuk mengakses resource penting merupakan masalah keamanan.

Namun tidak semua string yang terlihat seperti key merupakan secret yang valid.

Contohnya:

public API identifier;
test value;
placeholder;
public client identifier;
build configuration;
atau token yang sudah tidak aktif.

Karena itu, static finding harus divalidasi.

Prinsipnya:

Static analysis menemukan indikasi. Validasi menentukan apakah indikasi tersebut benar-benar menjadi vulnerability.

Analisis Local Storage

Aplikasi Android sering menyimpan data secara lokal.

Beberapa bentuk penyimpanan yang perlu dipahami:

SharedPreferences;
SQLite database;
file;
cache;
application-specific storage;
Keystore-related mechanisms;
dan database/library pihak ketiga.

Dalam security assessment, pertanyaan utamanya bukan:

"Apakah aplikasi menyimpan data?"

Melainkan:

"Data apa yang disimpan, mengapa disimpan, dan bagaimana data tersebut dilindungi?"

SharedPreferences

SharedPreferences sering digunakan untuk menyimpan konfigurasi sederhana.

Contohnya:

user preference;
feature flag;
status login;
konfigurasi aplikasi;
dan data sederhana lainnya.

Security tester perlu memperhatikan apakah data sensitif disimpan di sana tanpa perlindungan yang sesuai.

Namun konteks tetap penting.

Menyimpan tema aplikasi di SharedPreferences jelas berbeda dengan menyimpan credential atau token sensitif.

SQLite Database

Aplikasi yang membutuhkan struktur data lebih kompleks dapat menggunakan database SQLite.

Contohnya:

cache data;
history;
local records;
application state;
dan data offline.

Dalam security assessment, database lokal dapat diperiksa untuk mengetahui apakah data sensitif tersimpan secara tidak semestinya.

Pertanyaan penting

Apakah password disimpan?
Apakah token disimpan?
Apakah informasi pribadi disimpan?
Apakah data terenkripsi?
Apakah encryption key dikelola dengan aman?
Apakah data dapat diakses oleh pihak lain?

Analisis Log Android

Log sangat berguna dalam dynamic analysis.

Android menyediakan mekanisme logging yang dapat diamati menggunakan tooling seperti ADB.

Salah satu perintah yang umum digunakan dalam lab adalah:

adb logcat

Output dapat berisi informasi dalam jumlah besar.

Karena itu, jangan hanya menjalankan logcat tanpa tujuan.

Gunakan log untuk menjawab pertanyaan tertentu.

Contoh hal yang dapat dicari

error aplikasi;
exception;
debug message;
state transition;
network-related information;
dan informasi diagnostik.

Jika aplikasi mencetak data sensitif ke log dalam production build, hal tersebut dapat menjadi security concern.

Debug Logging dan Data Sensitif

Bayangkan aplikasi mencetak:

DEBUG: user_token=...
DEBUG: password=...
DEBUG: authorization=...

Jika informasi tersebut benar-benar sensitif dan dapat diakses dalam kondisi yang tidak semestinya, maka ada potensi masalah.

Tetapi sekali lagi, validasi diperlukan.

Security testing bukan kompetisi menemukan sebanyak mungkin string.

Yang dicari adalah risiko nyata.

Menemukan API dari Aplikasi

Sebagian besar aplikasi modern tidak bekerja sendirian.

Aplikasi berkomunikasi dengan backend melalui API.

API dapat ditemukan melalui beberapa sumber:

static analysis;
network traffic;
application configuration;
documentation;
log;
dan dynamic behavior.

Static analysis mungkin menunjukkan:

https://api.example.test/v1/

Sedangkan network analysis dapat menunjukkan request seperti:

POST /v1/login
GET /v1/profile
GET /v1/orders

Kedua perspektif tersebut kemudian dapat digabungkan.

Menghubungkan NoxPlayer dengan Burp Suite

Setelah memahami konsep aplikasi, kita dapat mulai melihat komunikasi jaringan.

Workflow konseptualnya:

Android Application → Android Proxy → Burp Suite → Destination Server

PortSwigger menyediakan dokumentasi khusus mengenai konfigurasi Android device/emulator untuk menggunakan Burp Proxy. ([portswigger.net](https://portswigger.net/burp/documentation/desktop/mobile/config-android-device?utm_source=chatgpt.com))

Langkah konseptual

Jalankan Burp Suite.
Buat Proxy listener pada interface yang dapat dijangkau emulator.
Catat IP komputer host.
Catat port listener.
Konfigurasikan proxy pada environment Android.
Pastikan koneksi menuju proxy berhasil.
Gunakan aplikasi latihan.
Amati request yang muncul.

Jangan langsung mengubah banyak konfigurasi sekaligus.

Jika traffic tidak muncul, troubleshooting satu komponen pada satu waktu.

Memahami Proxy Listener

Burp membutuhkan listener agar dapat menerima koneksi dari client.

Misalnya listener dikonfigurasi pada:

HOST:PORT

Dalam lab, gunakan interface yang memang dapat dijangkau oleh emulator.

Jangan menganggap 127.0.0.1 selalu berarti komputer host dari perspektif emulator.

Ini adalah salah satu konsep networking yang sering membingungkan pemula.

Masalah Umum Proxy Tidak Bekerja

1. Salah alamat IP

Emulator mungkin tidak dapat menjangkau alamat yang kamu gunakan.

2. Salah port

Port di Android harus sesuai dengan listener.

3. Firewall

Firewall host dapat memblokir koneksi.

4. Aplikasi menggunakan HTTPS

Traffic HTTPS membutuhkan trust configuration yang sesuai.

5. Certificate pinning

Aplikasi mungkin melakukan validasi sertifikat tambahan.

6. Aplikasi tidak menggunakan proxy sistem

Beberapa aplikasi atau library dapat memiliki perilaku networking berbeda dari browser.

Memahami HTTPS Interception

HTTPS tidak berarti traffic tidak dapat dianalisis dalam lab.

Namun interception harus dilakukan melalui mekanisme yang benar.

Konsepnya:

Client percaya CA lab → Burp membuat koneksi TLS untuk sesi interception → Burp meneruskan koneksi ke server tujuan.

Untuk environment yang memang diizinkan, CA certificate Burp dapat digunakan sesuai dokumentasi PortSwigger. ([portswigger.net](https://portswigger.net/burp/documentation/desktop/tools/proxy/manage-certificates?utm_source=chatgpt.com))

Namun modern Android dan aplikasi dapat menerapkan berbagai trust policy.

Karena itu, keberhasilan instalasi CA tidak selalu berarti seluruh traffic akan terlihat.

Apa Itu Dynamic Analysis?

Dynamic analysis berarti mempelajari aplikasi ketika aplikasi sedang berjalan.

Jika static analysis bertanya:

"Apa yang terdapat di dalam aplikasi?"

Maka dynamic analysis bertanya:

"Apa yang dilakukan aplikasi ketika kondisi tertentu terjadi?"

Contoh aktivitas dynamic analysis:

menjalankan aplikasi;
login menggunakan akun lab;
mengamati request;
mengamati response;
memeriksa log;
mengamati perubahan state;
mengamati file/database;
dan menggunakan instrumentation bila diperlukan.

Memahami Frida dalam Dynamic Analysis

Frida dapat digunakan ketika observasi biasa tidak cukup.

Contohnya, kamu ingin memahami bagaimana suatu fungsi bekerja ketika aplikasi berjalan.

Dengan instrumentation, researcher dapat mengamati pemanggilan fungsi dan nilai yang berkaitan dengan fungsi tersebut.

Dokumentasi Frida menyediakan workflow Android untuk menjalankan Frida pada environment yang sesuai dan berkomunikasi dengan proses aplikasi. ([frida.re](https://frida.re/docs/android/?utm_source=chatgpt.com))

Namun Frida bukan magic button.

Jika kamu belum memahami class, method, process, memory, dan runtime behavior, penggunaan Frida akan terasa seperti menjalankan mantra tanpa memahami hasilnya.

Static + Dynamic = Workflow yang Lebih Kuat

Misalnya static analysis menemukan:

AuthManager
LoginActivity
TokenManager
ApiClient

Kemudian dynamic analysis menunjukkan bahwa setelah login, aplikasi melakukan request tertentu.

Kedua informasi tersebut dapat digabungkan.

Hasilnya menjadi:

Static: menemukan struktur.

Dynamic: menemukan perilaku.

Network: menemukan komunikasi.

Manual analysis: menentukan makna security-nya.

Inilah workflow yang lebih matang.

Membangun Attack Surface Map

Setelah melakukan preliminary analysis, buat tabel sederhana.

Area	Temuan Awal	Status	Perlu Validasi?
Manifest	Component tersedia	Observed	Ya
Network	API endpoint ditemukan	Observed	Ya
Storage	Local database	Observed	Ya
Logging	Debug message	Observed	Ya
Native library	File .so tersedia	Observed	Jika relevan

Dengan tabel seperti ini, kamu tidak mudah kehilangan konteks.

Jangan Mengubah "Temuan" Menjadi "Vulnerability" Terlalu Cepat

Ini salah satu perbedaan antara pemula dengan security tester yang lebih berpengalaman.

Misalnya kamu menemukan:

Finding: aplikasi memiliki Activity exported.

Itu belum tentu:

Vulnerability: attacker dapat mengambil data sensitif.

Masih ada beberapa pertanyaan:

Apakah Activity dapat dipanggil tanpa authentication?
Apakah Activity menerima input?
Apakah input divalidasi?
Apakah data sensitif dapat diakses?
Apakah authorization dilakukan?
Apakah terdapat mitigasi lain?

Barulah setelah validasi kamu dapat menentukan severity.

Memahami Severity Secara Konseptual

Security finding sebaiknya dinilai berdasarkan dampaknya.

Beberapa aspek yang perlu dipertimbangkan:

confidentiality impact;
integrity impact;
availability impact;
authentication requirements;
privileges required;
user interaction;
attack complexity;
dan business impact.

Jangan memberikan label Critical hanya karena sebuah temuan terlihat menarik.

Severity harus dapat dipertanggungjawabkan.

Pentingnya Evidence

Setiap temuan yang valid sebaiknya memiliki evidence.

Evidence dapat berupa:

screenshot;
log;
request/response;
potongan konfigurasi;
hasil static analysis;
hasil dynamic analysis;
atau langkah reproduksi yang relevan.

Evidence harus cukup untuk menjelaskan masalah tanpa membocorkan data sensitif yang tidak diperlukan.

Contoh Struktur Catatan Pentest

Finding:
Exposed Android Component

Location:
Application Component

Observation:
Component dapat dipanggil dari environment eksternal.

Validation:
Dilakukan pada aplikasi latihan.

Impact:
Perlu dianalisis apakah component memberikan akses
terhadap fungsi atau data yang seharusnya dibatasi.

Evidence:
Screenshot + log + reproduction steps

Recommendation:
Batasi exposure dan terapkan authorization
sesuai kebutuhan fungsi.

Format tersebut jauh lebih berguna daripada sekadar menulis:

"Ada exported Activity, severity high."

Mindset Security Tester

Tools hanyalah alat.

Skill utama seorang pentester adalah kemampuan menghubungkan informasi.

Misalnya:

Manifest menunjukkan component.

↓

Static analysis menunjukkan logic.

↓

Dynamic analysis menunjukkan perilaku.

↓

Burp menunjukkan komunikasi API.

↓

Storage analysis menunjukkan data lokal.

↓

Manual reasoning menentukan risiko.

Itulah inti Android penetration testing.

Checklist Static dan Dynamic Analysis

Static Analysis

☐ Package name.
☐ AndroidManifest.
☐ Permission.
☐ Activities.
☐ Services.
☐ Receivers.
☐ Providers.
☐ Intent filters.
☐ Deep links.
☐ URLs.
☐ API endpoints.
☐ Configuration.
☐ Strings.
☐ Native libraries.
☐ Third-party SDK.

Dynamic Analysis

☐ Application startup.
☐ Authentication.
☐ Authorization.
☐ Network traffic.
☐ Logging.
☐ Local storage.
☐ Application behavior.
☐ Error handling.
☐ Component interaction.
☐ Runtime behavior.

Kesimpulan Bagian 2

Setelah environment NoxPlayer dan ADB siap, tahap berikutnya bukan langsung melakukan eksploitasi.

Langkah yang jauh lebih penting adalah memahami aplikasi.

Static analysis membantu kita melihat struktur aplikasi.

AndroidManifest membantu memetakan component dan permission.

Network analysis membantu memahami komunikasi dengan backend.

Local storage analysis membantu mengetahui bagaimana aplikasi menyimpan data.

Log membantu melihat informasi runtime.

Dynamic analysis kemudian membantu memvalidasi bagaimana aplikasi benar-benar berperilaku.

Jika seluruh informasi tersebut digabungkan, kita mulai mendapatkan gambaran lengkap mengenai attack surface aplikasi.

Dan di sinilah NoxPlayer mulai menunjukkan manfaat sebenarnya.

Bukan karena emulator tersebut secara otomatis menemukan vulnerability, tetapi karena emulator menyediakan environment yang dapat dikontrol untuk melakukan observasi dan eksperimen.

Pada bagian berikutnya, kita dapat masuk lebih dalam ke praktik network security testing pada Android menggunakan NoxPlayer dan Burp Suite, termasuk konsep proxy, HTTPS, certificate trust, API discovery, request/response analysis, authentication flow, session management, serta cara membedakan masalah client-side dengan masalah backend.

Setelah itu, pembahasan dapat dilanjutkan ke Frida dan dynamic instrumentation, sehingga keseluruhan workflow Android pentesting menjadi semakin lengkap.

Bagian 3 — Android Network Security Testing dengan NoxPlayer dan Burp Suite

Pada bagian sebelumnya kita sudah membahas static analysis, AndroidManifest, permission, application component, local storage, log, API discovery, serta konsep dynamic analysis.

Sekarang kita masuk ke salah satu bagian paling menarik dalam Android penetration testing: menganalisis komunikasi jaringan aplikasi.

Hampir semua aplikasi Android modern berkomunikasi dengan backend. Login, registrasi, profile, transaksi, upload file, sinkronisasi data, notifikasi, dan berbagai fungsi lainnya biasanya melibatkan komunikasi antara aplikasi dengan server.

Karena itu, network traffic dapat memberikan gambaran yang sangat berharga mengenai bagaimana aplikasi bekerja.

Dengan kombinasi NoxPlayer + Burp Suite + ADB, security tester dapat membangun lab yang memungkinkan pengamatan traffic aplikasi secara terkontrol.

Apa Itu Network Security Testing pada Android?

Network security testing pada aplikasi Android adalah proses mengevaluasi bagaimana aplikasi berkomunikasi dengan service atau backend melalui jaringan.

Tujuannya bukan sekadar melihat request HTTP.

Security tester perlu memahami:

server apa yang dihubungi aplikasi;
endpoint apa yang digunakan;
method HTTP yang digunakan;
parameter apa yang dikirim;
header apa yang digunakan;
bagaimana authentication bekerja;
bagaimana session dikelola;
bagaimana error ditangani;
bagaimana data sensitif dikirim;
dan apakah kontrol keamanan diterapkan secara konsisten.

Dengan kata lain, kita tidak hanya bertanya:

"Apa request yang dikirim aplikasi?"

Tetapi:

"Apa model keamanan yang dapat kita pahami dari komunikasi tersebut?"

Memahami Arsitektur Traffic Android

Sebelum melakukan konfigurasi, pahami terlebih dahulu alur sederhananya.

Android App
     |
     v
Android Network Stack
     |
     v
Proxy Configuration
     |
     v
Burp Suite
     |
     v
Internet / API Server

Dalam lab, Burp Suite bertindak sebagai perantara yang memungkinkan traffic diamati.

Jika konfigurasi berhasil, kamu dapat melihat informasi seperti:

Request
POST /api/login HTTP/1.1
Host: api.example.test
Content-Type: application/json

{
  "username": "lab-user",
  "password": "********"
}

Dan response:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "authenticated": true
}

Contoh di atas hanya ilustrasi untuk aplikasi latihan. Jangan menguji credential, token, atau data pengguna nyata tanpa otorisasi.

Menyiapkan Burp Suite untuk Lab

Langkah pertama adalah memastikan Burp Suite berjalan pada komputer host.

Burp Suite menyediakan fitur Proxy yang dapat digunakan untuk menerima dan menganalisis traffic dari client yang telah dikonfigurasi.

PortSwigger mendokumentasikan proses konfigurasi perangkat Android untuk menggunakan Burp Proxy melalui dokumentasi resminya.

Dokumentasi PortSwigger — Configuring an Android device to work with Burp Proxy

Konsep konfigurasi

Secara umum, kamu perlu menentukan:

alamat interface host yang dapat dijangkau emulator;
port listener Burp;
proxy configuration pada Android;
dan trust configuration untuk HTTPS pada lab.

Jangan terburu-buru mengubah banyak konfigurasi.

Jika traffic belum terlihat, lakukan troubleshooting secara bertahap.

Memahami Proxy Listener

Proxy listener adalah service yang menunggu koneksi dari client.

Misalnya:

127.0.0.1:8080

Konfigurasi tersebut berarti listener hanya menerima koneksi pada loopback interface.

Dalam skenario emulator, alamat tersebut belum tentu dapat digunakan dengan cara yang kamu bayangkan.

Inilah alasan mengapa memahami networking lebih penting daripada sekadar mengikuti tutorial konfigurasi.

Pertanyaan troubleshooting

Apakah emulator dapat menjangkau host?
Apakah listener berjalan?
Apakah port dapat dijangkau?
Apakah firewall mengizinkan koneksi?
Apakah proxy Android sudah benar?
Apakah aplikasi menggunakan proxy tersebut?

Memahami Proxy dari Perspektif Android

Ketika sebuah aplikasi menggunakan HTTP client, request dapat dipengaruhi oleh konfigurasi jaringan environment.

Namun tidak semua aplikasi berperilaku sama.

Browser, WebView, library networking, dan native networking stack dapat memiliki karakteristik yang berbeda.

Karena itu, jangan menganggap:

"Kalau browser sudah melewati Burp, berarti semua aplikasi Android pasti melewati Burp."

Itu tidak selalu benar.

Mengapa HTTPS Membutuhkan Perhatian Khusus?

HTTPS dirancang untuk memberikan confidentiality dan integrity pada komunikasi.

Ketika melakukan interception dalam lab, kita harus memahami konsep certificate trust.

Secara sederhana:

Normal HTTPS:

Application
    |
    | TLS
    v
Server


HTTPS melalui interception lab:

Application
    |
    | TLS
    v
Burp
    |
    | TLS
    v
Server

Burp berada di tengah komunikasi sebagai proxy.

Agar aplikasi dapat mempercayai koneksi interception tersebut, environment pengujian perlu dikonfigurasi sesuai mekanisme trust yang berlaku.

PortSwigger menyediakan dokumentasi mengenai penggunaan CA certificate Burp dalam pengujian mobile.

Dokumentasi PortSwigger — Burp CA certificates

Apa Itu Certificate Pinning?

Salah satu konsep yang hampir pasti akan kamu temui dalam Android security testing adalah certificate pinning.

Pada validasi TLS biasa, aplikasi dapat mempercayai certificate chain berdasarkan trust store.

Certificate pinning menambahkan pemeriksaan tambahan terhadap certificate atau public key tertentu.

Tujuannya adalah mempersempit certificate yang dianggap valid oleh aplikasi.

Konsekuensinya, memasang CA certificate pada environment belum tentu cukup untuk membuat traffic aplikasi terlihat melalui proxy.

Bagaimana mengetahui ada indikasi pinning?

Misalnya:

browser dapat menggunakan proxy;
aplikasi lain dapat menggunakan proxy;
tetapi aplikasi target gagal melakukan koneksi ketika interception aktif.

Situasi tersebut dapat menjadi indikasi adanya trust configuration khusus, termasuk kemungkinan certificate pinning.

Namun jangan langsung menyimpulkan.

Masalah DNS, proxy, TLS version, certificate chain, network security configuration, atau konfigurasi server juga dapat menyebabkan gejala serupa.

Membaca HTTP Request

Ketika traffic berhasil ditangkap, jangan langsung mencari vulnerability.

Pertama-tama pahami request tersebut.

Contoh:

POST /api/v1/login HTTP/1.1
Host: api.example.test
Content-Type: application/json
Authorization: Bearer [REDACTED]

{
  "username": "lab-user",
  "password": "[REDACTED]"
}

Perhatikan beberapa bagian:

HTTP method;
path;
host;
headers;
authentication information;
content type;
request body;
dan parameter.

Memahami HTTP Method

Beberapa HTTP method yang sering terlihat dalam API antara lain:

GET
POST
PUT
PATCH
DELETE

Method tersebut tidak otomatis menentukan tingkat keamanan sebuah endpoint.

Namun method membantu kita memahami tujuan request.

Contoh konseptual:

GET    /api/profile
POST   /api/login
PATCH  /api/profile
DELETE /api/session

Setelah memahami endpoint, kita dapat mulai memetakan application flow.

Membangun API Flow

Misalnya hasil observasi menunjukkan:

POST /login
      |
      v
POST /session
      |
      v
GET /profile
      |
      v
GET /orders
      |
      v
POST /orders

Informasi tersebut jauh lebih berguna daripada daftar endpoint tanpa konteks.

Kita mulai mengetahui urutan interaksi aplikasi.

Kenapa API flow penting?

Karena vulnerability sering muncul bukan dari satu request saja, tetapi dari hubungan antar-request.

Misalnya:

login menghasilkan session;
session digunakan untuk profile;
profile menghasilkan identifier;
identifier digunakan pada endpoint berikutnya.

Dengan memahami flow, security tester dapat memahami dependency antar fitur.

Menganalisis Authentication Flow

Authentication menjawab pertanyaan:

"Siapa kamu?"

Dalam aplikasi mobile, authentication dapat melibatkan:

username/password;
OTP;
access token;
refresh token;
biometric authentication;
OAuth/OIDC;
session cookie;
atau mekanisme lainnya.

Security tester perlu memahami bagaimana mekanisme tersebut bekerja dari awal hingga akhir.

Contoh flow

Login
  |
  v
Credential validation
  |
  v
Access token
  |
  v
Authenticated API request
  |
  v
Refresh token
  |
  v
New access token

Setelah flow diketahui, setiap tahap dapat dianalisis secara terpisah.

Authentication Bukan Authorization

Ini adalah konsep yang sangat penting.

Authentication menjawab siapa pengguna.

Authorization menjawab apa yang boleh dilakukan pengguna.

Misalnya:

User A berhasil login.

Itu berarti authentication berhasil.

Tetapi apakah User A boleh membaca data User B?

Itulah pertanyaan authorization.

Kesalahan pada authorization dapat menjadi masalah serius pada API.

Konsep Object-Level Authorization

Dalam aplikasi yang memiliki resource berdasarkan identifier, security tester perlu memahami bagaimana server memastikan bahwa user memang berhak mengakses resource tersebut.

Contoh konseptual:

GET /api/users/100/profile

Jika pengguna yang login adalah user 100, akses mungkin sah.

Pertanyaan pengujian pada lab adalah:

Apakah server tetap memverifikasi ownership ketika identifier berubah?

Jika server hanya mempercayai identifier dari client tanpa melakukan authorization check, dapat muncul masalah seperti Broken Object Level Authorization.

Pengujian seperti ini hanya boleh dilakukan terhadap aplikasi yang memang berada dalam scope.

Memahami HTTP Status Code

Status code memberikan petunjuk penting mengenai hasil request.

Contoh:

200 OK
201 Created
204 No Content
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
429 Too Many Requests
500 Internal Server Error

Security tester sebaiknya tidak hanya memperhatikan status code.

Response body juga penting.

Misalnya sebuah endpoint mengembalikan:

{
  "success": false,
  "message": "Invalid request"
}

Bandingkan dengan response ketika input valid.

Perbedaan response dapat memberikan informasi mengenai application logic.

Error Handling dan Information Disclosure

Error message sangat berguna bagi developer.

Namun error yang terlalu detail dapat memberikan informasi tambahan kepada pihak yang tidak seharusnya mengetahuinya.

Contohnya, production API sebaiknya tidak membocorkan:

stack trace lengkap;
internal filesystem path;
database query;
secret configuration;
credential;
internal host information;
atau detail debugging yang tidak diperlukan.

Security tester perlu membedakan antara error yang membantu debugging internal dengan error yang berpotensi menjadi information disclosure.

Menganalisis HTTP Headers

Header dapat memberikan informasi penting mengenai komunikasi.

Beberapa header yang sering menarik untuk diamati:

Authorization
Cookie
Content-Type
User-Agent
Accept
Origin
Referer

Tidak semua header merupakan security control.

Jangan menganggap keberadaan atau ketiadaan satu header sebagai vulnerability tanpa memahami konteksnya.

Memahami Token

Aplikasi modern sering menggunakan token untuk mempertahankan session atau authorization.

Token dapat memiliki berbagai bentuk.

Salah satu format yang populer adalah JWT.

Contoh bentuk JWT:

xxxxx.yyyyy.zzzzz

Struktur JWT umumnya terdiri dari tiga bagian:

header.payload.signature

Dalam security assessment, token perlu dianalisis dari sisi:

lifetime;
scope;
audience;
issuer;
signature validation;
storage;
revocation;
dan penggunaan token.

Jangan pernah memasukkan token nyata ke dalam artikel, screenshot publik, atau repository.

Session Management

Authentication yang kuat belum cukup jika session management lemah.

Beberapa pertanyaan yang dapat digunakan dalam assessment:

Kapan session dibuat?
Kapan session berakhir?
Apakah logout benar-benar membatalkan session?
Apakah refresh token dapat digunakan kembali secara tidak semestinya?
Bagaimana session disimpan?
Apakah session tetap aktif setelah perubahan password?

Semua pengujian tersebut harus dilakukan dengan akun dan data lab.

Konsep Request Replay

Salah satu kemampuan penting ketika bekerja dengan proxy adalah memahami request yang telah diamati.

Dalam environment pengujian, request dapat dipelajari kembali untuk mengetahui apakah perubahan tertentu memengaruhi behavior aplikasi.

Tujuan utamanya bukan sekadar mengulang request.

Tujuannya adalah memahami:

input mana yang benar-benar digunakan server;
field mana yang wajib;
field mana yang opsional;
bagaimana server melakukan validasi;
dan apakah authorization diterapkan.

Input Validation

Semua data yang berasal dari client sebaiknya dianggap sebagai untrusted input.

Client Android bukan sumber kebenaran.

Misalnya aplikasi mengirim:

{
  "quantity": 1,
  "price": 10000
}

Security tester dapat bertanya:

Apakah server menghitung ulang nilai penting atau hanya mempercayai data dari client?

Ini merupakan prinsip fundamental dalam application security.

Server harus melakukan validasi dan authorization sendiri.

Jangan Menganggap Client Sebagai Trusted Environment

Ini merupakan salah satu prinsip paling penting dalam mobile application security.

Aplikasi Android berada di sisi client.

Client dapat dimodifikasi, dianalisis, di-debug, atau dijalankan dalam environment yang dikontrol oleh tester.

Karena itu:

Security control penting tidak boleh hanya bergantung pada client.

Contohnya:

harga transaksi;
hak akses;
role pengguna;
status pembayaran;
ownership resource;
dan authorization.

Semua hal tersebut perlu divalidasi oleh server.

Client-Side Security vs Server-Side Security

Misalnya aplikasi menyembunyikan tombol:

Delete Account

Apakah itu berarti user tidak dapat melakukan delete account?

Belum tentu.

Jika backend tetap menerima request tanpa authorization yang benar, menyembunyikan tombol hanya menjadi kontrol UI.

Security control yang sebenarnya harus berada di server.

Inilah alasan network testing sangat penting dalam Android pentesting.

API Discovery Secara Sistematis

Daripada mencatat endpoint secara acak, buat inventory.

No	Method	Endpoint	Auth	Fungsi	Status
1	POST	/api/login	Public	Login	Observed
2	GET	/api/profile	Required	Profile	Observed
3	GET	/api/orders	Required	Orders	Observed
4	POST	/api/orders	Required	Create order	Observed

Inventory tersebut kemudian dapat digunakan sebagai dasar pengujian.

Workflow Burp Suite untuk Android Pentesting

Workflow sederhana yang dapat digunakan pada lab:

Jalankan NoxPlayer.
Pastikan aplikasi latihan terpasang.
Pastikan konektivitas Android berfungsi.
Jalankan Burp Suite.
Konfigurasikan proxy listener.
Konfigurasikan proxy pada environment Android.
Validasi koneksi.
Jalankan aplikasi.
Amati request.
Kelompokkan endpoint.
Identifikasi authentication flow.
Identifikasi data sensitif.
Catat behavior yang menarik.
Validasi temuan secara terkontrol.
Dokumentasikan evidence.

Workflow ini lebih baik daripada langsung mencoba payload secara acak.

Troubleshooting Ketika Traffic Tidak Muncul

Masalah 1 — Tidak ada request sama sekali

Periksa:

apakah aplikasi benar-benar melakukan koneksi;
apakah emulator memiliki internet;
apakah proxy sudah aktif;
apakah listener Burp berjalan;
dan apakah alamat host benar.

Masalah 2 — Browser terlihat tetapi aplikasi tidak

Kemungkinan penyebab:

aplikasi menggunakan networking configuration berbeda;
proxy tidak digunakan;
certificate trust berbeda;
atau terdapat mekanisme tambahan seperti certificate pinning.

Masalah 3 — HTTPS gagal

Periksa:

CA configuration;
trust model Android;
network security configuration;
dan implementasi TLS aplikasi.

Masalah 4 — Aplikasi crash

Gunakan log untuk mengetahui penyebabnya.

adb logcat

Jangan mengasumsikan crash selalu disebabkan oleh Burp.

Apa yang Harus Dicari Saat Menganalisis Traffic?

Berikut beberapa kategori pemeriksaan yang relevan dalam authorized assessment:

1. Authentication

Apakah endpoint sensitif membutuhkan authentication?

2. Authorization

Apakah server memastikan user memiliki hak terhadap resource?

3. Sensitive Data Exposure

Apakah data sensitif dikirim atau dikembalikan tanpa perlindungan yang tepat?

4. Input Validation

Apakah server memvalidasi data dari client?

5. Session Management

Apakah session dikelola dengan benar?

6. Error Handling

Apakah response error membocorkan informasi internal?

7. Rate Limiting

Apakah endpoint sensitif memiliki kontrol abuse yang sesuai?

8. Business Logic

Apakah workflow aplikasi dapat disalahgunakan dengan cara yang tidak sesuai aturan bisnis?

Business Logic: Bagian yang Tidak Bisa Digantikan Tools

Ini merupakan salah satu area yang membuat mobile penetration testing menjadi menarik.

Tools dapat menemukan endpoint.

Tools dapat menangkap request.

AI dapat membantu mengelompokkan response.

Tetapi memahami apakah sebuah workflow masuk akal secara bisnis membutuhkan manusia.

Misalnya aplikasi memiliki workflow:

Add Product
      ↓
Create Order
      ↓
Payment
      ↓
Confirmation

Security tester harus memahami aturan bisnis:

Kapan order dianggap valid?
Kapan harga ditentukan?
Kapan pembayaran dianggap selesai?
Siapa yang boleh membatalkan?
Apakah status dapat berubah kembali?

Kesalahan business logic sering tidak dapat ditemukan hanya dengan mencari string tertentu.

Konsep Rate Limiting

Endpoint tertentu dapat menjadi target abuse jika tidak memiliki pembatasan request yang memadai.

Contohnya secara konseptual:

login;
OTP;
password reset;
kode verifikasi;
search;
resource creation.

Dalam lab, tester dapat mengevaluasi apakah mekanisme pembatasan bekerja sesuai requirement.

Pengujian harus dilakukan secara terkontrol agar tidak mengganggu service.

Data Sensitif dalam Traffic

Perhatikan data seperti:

password;
access token;
refresh token;
session identifier;
personal information;
financial information;
location;
dan informasi rahasia lainnya.

Jangan memasukkan data tersebut ke screenshot artikel atau repository publik.

Jika perlu membuat evidence, lakukan redaction.

Contoh:

Authorization: Bearer eyJ...REDACTED

Bukan:

Authorization: Bearer [real production token]

Mengapa Redaction Penting?

Hasil penetration testing sering mengandung informasi yang sangat sensitif.

Screenshot Burp dapat mengandung:

token;
cookie;
email;
identifier;
alamat internal;
API key;
atau data pelanggan.

Sebelum evidence dibagikan, lakukan sanitasi.

Gunakan:

[REDACTED]
[LAB-USER]
[EXAMPLE-TOKEN]
[INTERNAL-HOST]

Tujuannya agar pembaca tetap memahami temuan tanpa mendapatkan rahasia sebenarnya.

API Security dan Android Pentesting

Hal penting yang harus dipahami adalah bahwa Android pentesting dan API security sering saling berhubungan.

Aplikasi Android hanyalah salah satu client.

Backend API merupakan komponen yang sebenarnya memproses banyak keputusan penting.

Karena itu, security tester sebaiknya melihat sistem sebagai:

Mobile Client
     |
     v
API Gateway
     |
     v
Application Backend
     |
     +---- Database
     |
     +---- Authentication Service
     |
     +---- Third-party Service

Jika hanya menguji UI Android, sebagian besar attack surface backend dapat terlewat.

Menggunakan OWASP sebagai Kerangka Berpikir

Untuk mempelajari mobile application security secara terstruktur, salah satu referensi yang sangat berguna adalah OWASP Mobile Application Security.

OWASP menyediakan Mobile Application Security Testing Guide atau MASTG yang membahas methodology dan teknik pengujian keamanan aplikasi mobile.

OWASP Mobile Application Security Testing Guide

Selain MASTG, OWASP juga menyediakan Mobile Application Security Verification Standard atau MASVS sebagai standar untuk kebutuhan keamanan aplikasi mobile.

OWASP Mobile Application Security Verification Standard

Gunakan framework seperti ini agar proses pengujian tidak hanya berdasarkan intuisi.

Checklist Network Security Testing

Environment

☐ NoxPlayer berjalan.
☐ Aplikasi latihan tersedia.
☐ ADB terhubung.
☐ Network emulator berfungsi.
☐ Burp Suite berjalan.
☐ Proxy listener aktif.

Traffic

☐ Request berhasil diamati.
☐ Host berhasil diidentifikasi.
☐ Endpoint dicatat.
☐ HTTP method dicatat.
☐ Authentication flow dipahami.
☐ Session flow dipahami.
☐ Response dianalisis.

Security

☐ Authentication diperiksa.
☐ Authorization diperiksa.
☐ Sensitive data diperiksa.
☐ Error handling diperiksa.
☐ Input validation diperiksa.
☐ Rate limiting diperiksa.
☐ Business logic dipahami.

Documentation

☐ Evidence dikumpulkan.
☐ Data sensitif di-redact.
☐ Reproduction steps dicatat.
☐ Impact dijelaskan.
☐ Recommendation dibuat.

Kesalahan Pemula Saat Menggunakan Burp untuk Android Pentesting

Kesalahan 1 — Menganggap semua traffic harus terlihat

Setiap aplikasi memiliki konfigurasi dan behavior berbeda.

Kesalahan 2 — Langsung mencari vulnerability

Pahami traffic terlebih dahulu.

Kesalahan 3 — Mengabaikan backend

UI hanyalah salah satu bagian dari sistem.

Kesalahan 4 — Tidak mencatat endpoint

Tanpa inventory, assessment mudah menjadi tidak terstruktur.

Kesalahan 5 — Tidak melakukan validasi

Response yang terlihat aneh belum tentu vulnerability.

Kesalahan 6 — Menggunakan data produksi

Gunakan akun dan data yang memang disediakan untuk pengujian.

Kesalahan 7 — Menguji terlalu agresif

Traffic berlebihan dapat mengganggu service dan bahkan mengubah kondisi pengujian.

Bagaimana AI Membantu Network Analysis?

AI dapat membantu mengurangi pekerjaan repetitif ketika jumlah request sangat banyak.

Misalnya sebuah aplikasi menghasilkan ratusan request.

AI dapat membantu mengelompokkan berdasarkan:

endpoint;
HTTP method;
status code;
parameter;
response pattern;
authentication state;
dan fungsi aplikasi.

Contoh output yang ideal bukan:

"Ini vulnerability critical."

Melainkan:

"Endpoint berikut tampaknya menangani resource milik pengguna. Periksa apakah server melakukan object-level authorization."

Dengan pendekatan seperti itu, AI menjadi assistant untuk analisis, bukan mesin pembuat klaim vulnerability.

Jangan Percaya Output AI Secara Mentah

AI dapat salah memahami:

HTTP response;
business logic;
authentication mechanism;
token;
framework;
dan konteks aplikasi.

Karena itu, workflow yang lebih aman adalah:

Raw Traffic
     ↓
AI-assisted Analysis
     ↓
Human Review
     ↓
Controlled Validation
     ↓
Evidence
     ↓
Final Finding

Dengan workflow tersebut, AI membantu mempercepat pekerjaan tanpa mengambil alih keputusan security tester.

Kesimpulan

Network analysis merupakan bagian penting dalam Android penetration testing karena aplikasi mobile modern sangat bergantung pada API dan backend.

NoxPlayer menyediakan environment yang praktis untuk melakukan pengujian, sedangkan Burp Suite membantu security tester memahami komunikasi HTTP/S.

Dari traffic tersebut kita dapat mempelajari:

API endpoint;
authentication;
authorization;
session management;
input validation;
error handling;
data sensitif;
business logic;
dan berbagai aspek security lainnya.

Namun kemampuan terpenting bukanlah sekadar mampu menangkap request.

Kemampuan terpenting adalah mampu memahami mengapa request tersebut ada, apa yang dilakukan server, dan apakah behavior tersebut sesuai dengan security requirement.

Pada tahap berikutnya, kita dapat masuk ke topik yang lebih dalam, yaitu dynamic instrumentation dengan Frida.

Di bagian tersebut kita akan membahas konsep process, runtime, hook, method observation, penggunaan Frida dalam lab Android, cara membaca hasil instrumentation, serta bagaimana menggabungkan static analysis dan dynamic instrumentation tanpa menjadikan proses pengujian sekadar copy-paste script.

Catatan penting: seluruh teknik dalam artikel ini ditujukan untuk aplikasi, emulator, perangkat, dan sistem yang kamu miliki atau telah kamu mendapatkan izin untuk mengujinya. Untuk latihan, gunakan aplikasi vulnerable/lab yang memang disediakan untuk security testing.