Pendahuluan
Setiap kali sebuah aplikasi Android dipasang, seluruh logikanya ikut berpindah ke perangkat pengguna. Aturan bisnis, kunci API, endpoint internal, algoritma perhitungan harga, hingga pemeriksaan lisensi semuanya dibawa dalam satu berkas APK yang, secara teknis, kini berada di tangan siapa pun yang memasangnya. Developer sering menganggap kode yang sudah dikompilasi sebagai kotak hitam yang aman. Kenyataannya, kompilasi hanya menyembunyikan, bukan menghilangkan.
Reverse engineering APK adalah praktik membongkar kembali berkas aplikasi untuk memahami cara kerjanya: membaca kode, menelusuri alur data, dan menemukan apa yang sebenarnya terjadi di balik antarmuka. OWASP MASTG, panduan pengujian keamanan aplikasi mobile yang menjadi rujukan industri, menempatkan tampering dan reverse engineering sebagai bab tersendiri karena keduanya adalah dasar dari hampir semua pengujian keamanan mobile yang serius.[1][7]
Artikel ini menelusuri apa yang bisa ditemukan dari sebuah APK, alat apa yang dipakai, dan mengapa "logika bisnis yang disembunyikan" jarang benar-benar tersembunyi dari analis yang tahu ke mana harus melihat. Perspektifnya adalah perspektif penguji keamanan: memahami rute ini untuk membantu developer menutupnya, bukan untuk menyalahgunakannya.
Anatomi Sebuah APK
Sebuah APK pada dasarnya adalah arsip terkompresi. Di dalamnya terdapat beberapa komponen yang masing-masing menyimpan bagian berbeda dari aplikasi. Berkas DEX (Dalvik Executable) memuat bytecode yang dijalankan oleh runtime; spesifikasi formatnya didokumentasikan secara terbuka oleh Android Open Source Project.[17] AndroidManifest.xml mendeklarasikan komponen aplikasi, permission, dan kompatibilitas perangkat, sehingga menjadi peta pertama yang dibaca setiap analis.[18]
Kode itu tidak berjalan langsung di prosesor. Android Runtime (ART), yang menggantikan mesin Dalvik lama, adalah lingkungan yang mengeksekusi bytecode aplikasi.[19] Selain DEX, sebuah APK sering memuat native libraries dalam format .so, yaitu kode yang dikompilasi ke instruksi mesin ARM atau x86, biasanya untuk bagian yang menuntut performa atau justru sengaja disembunyikan dari analisis tingkat Java. Dokumentasi resmi Android menegaskan bahwa aplikasi dipaketkan sebagai APK atau app bundle dengan model manifest dan sandbox yang khas.[16]
Struktur berlapis inilah yang menentukan strategi analisis. Logika di lapisan DEX relatif mudah dibaca kembali menjadi Java; logika di lapisan native menuntut pembongkaran biner yang jauh lebih menantang. Analis yang berpengalaman membaca manifest lebih dulu untuk memahami permukaan aplikasi, baru memutuskan lapisan mana yang perlu dibongkar.
Menyembunyikan Bukan Berarti Menghilangkan
Ada kesalahpahaman yang bertahan lama di kalangan developer: bahwa memindahkan pemeriksaan keamanan ke sisi klien membuatnya aman. Pemeriksaan lisensi yang dilakukan di dalam aplikasi, kunci enkripsi yang ditanam di kode, atau logika perhitungan yang dianggap rahasia dagang, semuanya berada di perangkat yang sepenuhnya dikuasai calon penyerang.
OWASP mengangkat persoalan ini sebagai risiko M7, Insufficient Binary Protection, yang menyoroti binari aplikasi yang rentan terhadap reverse engineering dan tampering karena proteksi biner yang tidak memadai.[4] Prinsipnya sederhana namun sering diabaikan: apa pun yang dieksekusi di perangkat pengguna pada akhirnya bisa dibaca oleh pemilik perangkat. Rahasia yang benar-benar rahasia harus tetap berada di server, bukan di dalam APK.
Static Analysis: Membaca Kode Tanpa Menjalankannya
Analisis statis membongkar aplikasi tanpa menjalankannya, dan biasanya menjadi langkah pertama karena murah, cepat, dan tidak memerlukan perangkat aktif. MASTG menempatkan static analysis sebagai salah satu dari dua pendekatan inti, berdampingan dengan analisis dinamis.[7]
Dekompilasi ke Java dengan jadx
Alat yang paling sering menjadi titik awal adalah jadx, dekompiler yang mengubah bytecode Dalvik dari APK, dex, aar, maupun aab menjadi kode sumber Java yang bisa dibaca, tersedia dalam versi antarmuka grafis maupun baris perintah.[9] Hasil dekompilasi jadx jarang identik dengan kode asli developer, tetapi cukup untuk menelusuri alur logika, menemukan nama kelas dan metode, serta mengikuti bagaimana data berpindah antar komponen. Bagi banyak pengujian, membuka APK di jadx sudah cukup untuk menjawab pertanyaan pertama: apa yang sebenarnya dilakukan aplikasi ini.
Turun ke Level Smali dengan Apktool dan baksmali
Ketika dekompilasi Java gagal atau ketika analis perlu memodifikasi lalu membangun ulang aplikasi, tingkat yang lebih rendah dibutuhkan. Apktool melakukan reverse engineering terhadap resource APK, mengurai dan membangun kembali resource serta kode dalam representasi smali.[10] Smali adalah bahasa assembly untuk format DEX; baksmali, disassembler-nya, dipelihara di bawah proyek smali milik Google.[15] Bekerja pada level ini lebih melelahkan, tetapi memberi kontrol penuh: setiap instruksi bytecode bisa dibaca dan diubah, sesuatu yang mustahil dilakukan hanya dengan dekompilasi Java.
Sebagai pelengkap, dex2jar mengonversi berkas .dex menjadi .class atau .jar sehingga bisa dianalisis dengan perkakas Java biasa, membuka jalan bagi kombinasi alat yang lebih luas.[14]
Membongkar Native Libraries dengan Ghidra
Logika yang sengaja dipindahkan ke native code menuntut pendekatan berbeda. Ghidra, framework reverse engineering open-source dari National Security Agency, melakukan disassembly dan dekompilasi terhadap biner native seperti berkas .so di dalam APK.[13] Membaca hasil dekompilasi native jauh lebih sulit dibanding Java, karena tidak ada nama variabel yang bermakna dan strukturnya sudah dioptimasi kompiler. Justru karena itulah sebagian developer memindahkan logika sensitif ke lapisan native: bukan untuk membuatnya mustahil dibaca, melainkan untuk menaikkan biaya analisis.
Yang Sering Ditemukan
Hasil paling umum dari analisis statis, dan sering kali yang paling berdampak, adalah rahasia yang ditanam langsung di dalam kode. MITRE mengategorikan kelemahan ini sebagai CWE-798, Use of Hard-coded Credentials, yaitu kredensial atau kunci yang ditulis di dalam kode dan dapat diekstrak melalui reverse engineering.[22] Dalam praktik pengujian, temuan seperti kunci API layanan pihak ketiga, kredensial basis data, token statis, atau endpoint internal yang seharusnya tidak publik muncul dengan frekuensi yang mengejutkan.
Selain rahasia, analis sering menemukan logika bisnis yang diasumsikan aman karena tersembunyi: aturan diskon yang bisa dimanipulasi, pemeriksaan lisensi yang bisa dilewati, atau feature flag yang membuka fungsi tersembunyi. Semua ini masuk dalam kategori risiko yang lebih luas, termasuk Security Misconfiguration (M8) yang mencakup konfigurasi default tidak aman dan pengaturan aplikasi yang keliru.[5] Pola berulangnya sama: keamanan yang bergantung pada asumsi bahwa tidak ada yang akan melihat ke dalam.
Dampak dari temuan semacam ini melampaui aplikasi itu sendiri. Sebuah kunci API layanan pihak ketiga yang bocor bisa membuka akses ke akun cloud, layanan pembayaran, atau basis data yang jauh lebih luas dari aplikasi mobile-nya. Karena satu APK terpasang di ribuan atau jutaan perangkat, satu rahasia yang ditanam di dalamnya secara efektif menjadi rahasia publik begitu satu orang berhasil mengekstraknya. Inilah yang membuat hardcoded secret menempati peringkat tinggi dalam prioritas hampir setiap pengujian mobile.
Obfuscation dan Batasnya
Obfuscation adalah respons paling umum developer terhadap reverse engineering, dan penting memahami apa yang sebenarnya dilakukannya. R8, yang kini menggantikan ProGuard sebagai perkakas bawaan, melakukan code shrinking, optimasi, dan obfuscation berupa penggantian nama (name obfuscation) pada kelas, metode, dan field.[21] Setelah diproses, metode bernama validatePurchase bisa berubah menjadi a, dan kelas PricingEngine menjadi b.
Yang perlu ditegaskan: penggantian nama menaikkan biaya membaca, bukan membuatnya mustahil. Alur program tetap utuh, dan analis yang sabar bisa merekonstruksi makna dari konteks pemanggilan, string yang tersisa, dan interaksi dengan API sistem. Teknik yang lebih agresif seperti enkripsi string atau pengaburan alur kendali umumnya berasal dari perkakas komersial di luar R8, dan masing-masing tetap memiliki batas: string yang dienkripsi harus didekripsi saat runtime, dan titik dekripsi itu sendiri bisa diamati. Obfuscation adalah lapisan yang memperlambat, bukan tembok yang menghentikan.
Alur Kerja Tipikal
Dalam praktik, kedua pendekatan di atas jarang berdiri sendiri. Sebuah pengujian reverse engineering yang tertata biasanya bergerak dari yang murah ke yang mahal. Analis membuka manifest lebih dulu untuk memahami permukaan aplikasi: komponen apa yang diekspor, permission apa yang diminta, dan endpoint apa yang tersirat.[18] Setelah itu, dekompilasi dengan jadx memberi gambaran alur logika secara keseluruhan, sekaligus menandai lokasi yang menarik untuk didalami.[9]
Ketika bagian yang menarik ditemukan, misalnya rutin yang menangani otentikasi atau perhitungan harga, analis turun ke level smali untuk membaca instruksi persisnya, atau ke Ghidra bila logika itu ternyata berada di native library.[10][13] Barulah, untuk memverifikasi perilaku yang tidak bisa dipastikan dari kode statis, analisis dinamis dijalankan. Urutan ini bukan aturan kaku, melainkan cara menghemat usaha: sebagian besar pertanyaan terjawab jauh sebelum tahap termahal, dan analisis dinamis dicadangkan untuk hal-hal yang hanya terlihat saat aplikasi berjalan.
Satu titik peralihan yang sering menentukan adalah batas antara kode Java dan native. Interaksi keduanya, yang berjalan melalui Java Native Interface, adalah tempat logika sensitif kerap disembunyikan, dan menelusuri panggilan lintas batas ini sering menjadi bagian tersulit sekaligus paling berharga dari sebuah pengujian.
Dynamic Analysis: Frida dan Instrumentasi Runtime
Sebagian perilaku aplikasi hanya terlihat saat berjalan. Di sinilah analisis dinamis masuk. Frida adalah toolkit dynamic instrumentation yang menyuntikkan skrip ke dalam proses aplikasi untuk mengaitkan (hook) fungsi Java maupun native saat runtime.[11] Dengan hooking, analis bisa membaca argumen yang masuk ke sebuah metode, mengubah nilai yang dikembalikannya, atau memaksa cabang logika tertentu diambil, semuanya tanpa mengubah berkas APK di disk.
Kemampuan ini mengubah cara pemeriksaan dilakukan. Pemeriksaan lisensi yang mengembalikan nilai benar atau salah bisa dipaksa selalu mengembalikan benar. Nilai yang dihitung di sisi klien bisa diamati langsung sebelum dan sesudah transformasi. Untuk aplikasi yang menyembunyikan logika di balik enkripsi, titik saat data didekripsi menjadi jelas ketika prosesnya diamati dari dalam.
Melewati Certificate Pinning
Salah satu penggunaan analisis dinamis yang paling praktis adalah melewati certificate pinning agar lalu lintas jaringan aplikasi bisa diperiksa. objection, toolkit berbasis Frida untuk eksplorasi runtime aplikasi mobile, menyediakan fungsi seperti bypass SSL pinning dan bypass root detection tanpa memerlukan proses rooting permanen.[12] Setelah pinning dilewati, lalu lintas API aplikasi bisa dibaca melalui proxy, dan seluruh kontrak antara aplikasi dan server terbuka untuk dianalisis.
Anti-Reversing dan Ketahanan
Developer yang serius soal ketahanan menambahkan lapisan pertahanan terhadap analisis itu sendiri. OWASP mengategorikannya di bawah MASVS-RESILIENCE, yang mendefinisikan kontrol ketahanan terhadap reverse engineering dan tampering, mulai dari anti-tamper hingga deteksi instrumentasi.[6] Bab khusus Android di MASTG membahas pertahanan ini secara rinci: root detection, anti-debugging, deteksi Frida dan instrumentasi, serta anti-tampering, sekaligus cara mengujinya.[8]
Penting dipahami bahwa pertahanan ini bersifat probabilistik, bukan absolut. Deteksi root bisa dilewati, deteksi Frida bisa dielakkan, dan pemeriksaan integritas bisa di-patch. Nilai sesungguhnya dari lapisan resiliensi bukan menjadikan analisis mustahil, melainkan menaikkan biaya dan keahlian yang dibutuhkan sehingga tidak sepadan bagi sebagian besar penyerang. Untuk aplikasi yang menangani transaksi keuangan atau data sensitif, kenaikan biaya itu bermakna.
Cara memandang lapisan resiliensi yang sehat adalah dengan model ekonomi, bukan model tembok. Setiap lapisan menambah waktu, keahlian, dan alat yang harus dikeluarkan penyerang, sampai pada titik ketika usaha itu tidak lagi sepadan dengan hasilnya bagi mayoritas penyerang. Yang tidak boleh terjadi adalah menganggap satu lapisan mana pun sebagai jaminan, karena setiap pertahanan yang berjalan di perangkat pengguna pada prinsipnya bisa dianalisis oleh pemilik perangkat itu.
Repackaging dan Tanda Tangan Ulang
Setelah dimodifikasi, aplikasi perlu dibangun kembali dan ditandatangani ulang agar bisa dipasang. Apktool menangani proses membangun ulang dari smali,[10] sementara apksigner, perkakas resmi Android, menandatangani APK dan memverifikasi tanda tangannya.[20] Karena Android menolak memasang APK tanpa tanda tangan yang valid, setiap aplikasi hasil modifikasi akan membawa tanda tangan yang berbeda dari aslinya. Fakta ini sekaligus menjadi peluang pertahanan: aplikasi bisa memeriksa tanda tangannya sendiri saat runtime untuk mendeteksi apakah ia telah dikemas ulang.
Standar sebagai Kerangka Kerja
Semua teknik di atas berada dalam kerangka yang terstruktur, bukan kumpulan trik lepas. MASVS memberi standar verifikasi yang membagi kontrol ke sejumlah kategori, termasuk penyimpanan, kriptografi, autentikasi, jaringan, platform, kode, dan ketahanan.[2] MASTG menerjemahkan standar itu menjadi metodologi dan test case teknis yang bisa dijalankan.[1] Di atas keduanya, OWASP Mobile Top 10 edisi 2024 memberi peta risiko tingkat tinggi, dengan Insufficient Binary Protection dan Security Misconfiguration sebagai dua kategori yang paling relevan dengan reverse engineering.[3] Bagi penguji, ketiga dokumen ini mengubah pengujian dari eksplorasi acak menjadi cakupan yang bisa dipertanggungjawabkan.
Batasan Etis dan Legal
Reverse engineering adalah teknik netral yang legalitasnya bergantung pada konteks dan otorisasi. Membongkar aplikasi milik sendiri, atau aplikasi klien dalam engagement resmi dengan izin tertulis, berbeda secara fundamental dari membongkar aplikasi pihak lain tanpa hak. Di Indonesia, akses dan perbuatan terhadap sistem elektronik diatur dalam Undang-Undang Nomor 11 Tahun 2008 tentang Informasi dan Transaksi Elektronik, yang telah diubah terakhir dengan Undang-Undang Nomor 1 Tahun 2024.[23][24]
Aspek hak cipta juga relevan, karena kode program adalah ciptaan yang dilindungi Undang-Undang Nomor 28 Tahun 2014 tentang Hak Cipta, yang mengatur batasan penggandaan dan pengubahan program komputer.[25] Bila temuan reverse engineering menyangkut data pengguna, kewajiban perlindungannya tunduk pada Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi.[26] Prinsip operasionalnya tetap sama seperti seluruh pengujian keamanan: hanya atas otorisasi, dalam ruang lingkup yang disepakati, dengan tujuan memperbaiki keamanan.
Kesimpulan
Reverse engineering APK memperlihatkan sebuah kebenaran yang tidak nyaman bagi banyak developer: apa pun yang dikirim ke perangkat pengguna pada akhirnya bisa dibaca. Kode yang dikompilasi, nama yang diaburkan, string yang dienkripsi, dan logika yang dipindahkan ke native semuanya menaikkan biaya analisis, tetapi tidak satu pun benar-benar menyembunyikan logika dari analis yang tekun dan berbekal alat yang tepat.
Implikasi praktisnya bukan menyerah pada perlindungan biner, melainkan menempatkannya pada posisi yang benar. Rahasia yang tidak boleh diketahui harus tetap di server; pemeriksaan yang menentukan keamanan tidak boleh hanya bergantung pada sisi klien; dan lapisan obfuscation serta resiliensi diperlakukan sebagai penambah biaya penyerang, bukan jaminan. Pengujian reverse engineering yang baik menunjukkan dengan tepat asumsi mana yang tidak bertahan ketika aplikasi berada di tangan yang salah.
Jika Anda ingin mengetahui apa yang bisa ditemukan dari aplikasi mobile Anda melalui reverse engineering, tim Security Squad LOGIQUE siap membantu.
Daftar Referensi
[1] OWASP Foundation. "OWASP MASTG - Mobile Application Security Testing Guide." https://mas.owasp.org/MASTG/
[2] OWASP Foundation. "OWASP MASVS - Mobile Application Security Verification Standard." https://mas.owasp.org/MASVS/
[3] OWASP Foundation. "OWASP Mobile Top 10 - Final release 2024." https://owasp.org/www-project-mobile-top-10/
[4] OWASP Foundation. "M7: Insufficient Binary Protection." https://owasp.org/www-project-mobile-top-10/2023-risks/m7-insufficient-binary-protection.html
[5] OWASP Foundation. "M8: Security Misconfiguration." https://owasp.org/www-project-mobile-top-10/2023-risks/m8-security-misconfiguration.html
[6] OWASP Foundation. "MASVS-RESILIENCE: Resilience Against Reverse Engineering and Tampering." https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/
[7] OWASP Foundation. "Mobile App Tampering and Reverse Engineering." https://mas.owasp.org/MASTG/0x04c-Tampering-and-Reverse-Engineering/
[8] OWASP Foundation. "Android Anti-Reversing Defenses." https://mas.owasp.org/MASTG/0x05j-Testing-Resiliency-Against-Reverse-Engineering/
[9] Skylot. "jadx - Dex to Java decompiler." GitHub repository. https://github.com/skylot/jadx
[10] Tumbleson, Connor (iBotPeaches). "Apktool." https://apktool.org/
[11] Frida. "Welcome - Frida Documentation." https://frida.re/docs/home/
[12] SensePost. "objection - runtime mobile exploration." GitHub repository. https://github.com/sensepost/objection
[13] National Security Agency. "Ghidra - Software Reverse Engineering (SRE) Framework." GitHub repository. https://github.com/NationalSecurityAgency/ghidra
[14] Pan, Bob (pxb1988). "dex2jar - Tools to work with android .dex and java .class files." GitHub repository. https://github.com/pxb1988/dex2jar
[15] Google. "smali/baksmali." GitHub repository. https://github.com/google/smali
[16] Android Developers. "Application fundamentals." https://developer.android.com/guide/components/fundamentals
[17] Android Open Source Project. "Dalvik Executable format." https://source.android.com/docs/core/runtime/dex-format
[18] Android Developers. "App manifest overview." https://developer.android.com/guide/topics/manifest/manifest-intro
[19] Android Open Source Project. "Android runtime and Dalvik." https://source.android.com/docs/core/runtime
[20] Android Developers. "apksigner." https://developer.android.com/tools/apksigner
[21] Android Developers. "Enable app optimization with R8." https://developer.android.com/topic/performance/app-optimization/enable-app-optimization
[22] MITRE. "CWE-798: Use of Hard-coded Credentials." https://cwe.mitre.org/data/definitions/798.html
[23] Republik Indonesia. "Undang-Undang Nomor 11 Tahun 2008 tentang Informasi dan Transaksi Elektronik." https://peraturan.bpk.go.id/Details/37589/uu-no-11-tahun-2008
[24] Republik Indonesia. "Undang-Undang Nomor 1 Tahun 2024 tentang Perubahan Kedua atas Undang-Undang Nomor 11 Tahun 2008." https://peraturan.bpk.go.id/Details/274494/uu-no-1-tahun-2024
[25] Republik Indonesia. "Undang-Undang Nomor 28 Tahun 2014 tentang Hak Cipta." https://peraturan.bpk.go.id/Details/38690/uu-no-28-tahun-2014
[26] Republik Indonesia. "Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi." https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022
