XPosed: Framework sakti untuk modifikasi Android

Topik kali ini agak advanced, tapi juga pratis. XPosed  adalah sebuah framework open source yang memungkinkan kita membuat modul untuk memodifikasi sistem dan aplikasi Android yang ditulis menggunakan Java. Dari sudut pandang programming, framework ini menarik karena memungkinkan kita menambahkan dan mengintersepsi kode pada aplikasi closed source Android, sedikit mirip Aspect Oriented Programming.

Screenshot_2016-08-21-07-33-48.png

XPosed bekerja dengan memodifikasi runtime Android (Dalvik/Art) sehingga menjadi mungkin untuk memanggil kode custom di awal atau akhir sebuah method apapun. Perhatikan bahwa yang dimodifikasi adalah runtime Android saja, jadi hanya kode yang ditulis dalam Java dan diinterpretasikan oleh Dalvik atau Art runtime saja yang bisa diintersepsi, kode native tidak bisa. Ada framework lain, misalnya Cydia yang bisa mengintersepsi kode native juga, tapi Cydia versi Android ini agak lambat perkembangannya (saat ini belum mendukung Android 5 dan 6).

Untuk memakai XPosed, yang harus Anda lakukan adalah: menginstall recovery alternatif (CWM, TWRP, dsb) dan menginstall frameworknya (tergantung ponsel Anda, ini mungkin bisa membatalkan garansi). Anda juga perlu menginstall XPosed installer yang akan memanage modul mana saja yang aktif.

Mari kita mulai dengan contoh yang praktis tentang intersepsi kode. Jika kita punya kode seperti ini:

Kita bisa mengintersepsi ini dengan mengembalikan agar isValidLicense selalu menjadi true. Kita juga bisa memodifikasi agar  validateLicense segera kembali (tidak melakukan apapun, jadi tidak akan melempar exception). Dalam kasus yang sebenarnya, kita harus teliti, misalnya mungkin di dalam ada validateLicense kode lain untuk mensetup versi premium jika license valid (jadi tidak bisa kita patch agar selalu kembali).

Dalam contoh di atas method checkRoot melakukan pemeriksaan apakah device di-root oleh pengguna, dan cara memeriksanya adalah dengan menggunakan XML yang berisi daftar command dan package yang harus diperiksa. Dalam kasus seperti ini (ini penyederhanaan dari kasus nyata yang saya temui), maka kita bisa juga mengganti parameter input XML menjadi XML kosong.

Berikut ini contoh kode untuk mem-patch agar isValidLicense selalu mengembalikan true.

Beberapa baris pertama hanya mengimpor package yang kita butuhkan. Berikutnya kita perlu mengimplementasikan IXposedHookLoadPackage. Di dalam handleLoadPackage, kita bisa memfilter untuk package aplikasi mana saja hooking ini akan kita lakukan. Dalam kasus ini saya hanya tertarik pada satu aplikasi saja. Dalam kasus tertentu kita ingin menghook semua aplikasi, misalnya kita bisa membuat modul untuk melakukan SSL Unpinning untuk semua aplikasi.

Berikutnya yang harus kita ketahui adalah signature dari method yang akan kita hook. Untuk aplikasi yang sourcenya terbuka, atau untuk aplikasi yang mudah didekompilasi karena tidak diobfuscate, hal ini mudah dicari. Jika aplikasi di-obfuscate, hal ini agak lebih sulit. Dalam contoh ini package yang dimaksud adalah es.yohan.example dan methodnya adalah isValidLicense yang memiliki parameter berupa String.

Ada dua hook yang tersedia: beforeHookedMethod dan afterHookedMethod. Dalam beforeHookedMethod, kita bisa mengubah parameter yang masuk ke program (atau bisa juga sekedar melakukan logging atau mengirimkannya ke tempat lain), dan dalam afterHookedMethod kita bisa menerima dan atau mengubah nilai kembalian method. Dalam contoh di atas, saya hanya mengeset agar hasilnya selalu true.

Mungkin sekarang Anda bisa melihat kelemahan XPosed: modifikasi hanya bisa dilakukan di awal dan di akhir method. Jika Anda ingin memodifikasi sesuatu di tengah-tengah, misalnya mengubah konstanta yang tertanam di logika program (misalnya if (x>2127)), atau sekedar mengubah “kurang dari” menjadi “lebih dari” maka sulit melakukannya dengan XPosed.

Jika masih ingin mengubah detail sebuah method dengan XPosed, caranya adalah dengan menulis ulang method itu, dan di beforeHookedMethod kita memberitahu XPosed framework agar tidak memanggil method aslinya. Dalam kasus tertentu lebih mudah mengedit file APK-nya.

Secara praktis apa saja yang bisa dilakukan dengan kemampuan XPosed ini? Sudah banyak orang menuliskan modul untuk Xposed, dari mulai sekedar mengubah kosmetik Android (mengubah tampilan ini dan itu), menambahkan fitur tertentu (misalnya menambahkan Zoom ke aplikasi Instagram), memblokir iklan di berbagai aplikasi (termasuk juga Youtube yang sekarang memasukkan iklan bukan hanya di awal video tapi juga di tengah video jika videonya panjang), memperbaiki offset GPS di China, dan masih banyak lagi.

Ada juga modul untuk meningkatkan privasi (misalnya XPrivacy dan PMP), dengan memblok berbagai request dari aplikasi Android yang nakal atau mengembalikan data palsu. Contoh: banyak sekali aplikasi yang meminta akses ke contact list, ternyata mengupload seluruh phonebook kita ke server mereka (dengan berbagai alasan, misalnya untuk fitur referal, dsb).

Penghematan batere juga bisa dilakukan, misalnya dengan memblok aplikasi agar tidak bisa auto start, membatasi akses sensor, dsb.

Kebanyakan modul di repository XPosed berguna untuk mengatasi masalah sangat spesifik yang dimiliki oleh pengguna (misalnya ada yang nggak suka jika app yang baru diinstall langsung memiliki shortcut di home screen, ada yang nggak suka jika VPN meminta konfirmasi, dsb). Menurut saya itu kelebihan utama XPosed: kita bisa memodifikasi Android dengan mudah sesuai kemauan kita. Sebagai programmer, modifikasi ini bisa dilakukan meskipun kita tidak memiliki source code aplikasinya.

Secara praktis bagai saya pribadi: Sebagai pentester, saya kadang menemui aplikasi yang melakukan pengecekan root dengan cara yang unik dan modul XPosed seperti RootCloak tidak cukup. Saya kadang melakukan patching aplikasi langsung (jika masih testing tahap development), dan mengembangkan frameworknya (jika aplikasi sudah di appstore, karena biasanya sudah stabil)

Kadang saya juga perlu mengintersepsi komunikasi dengan enkripsi yang custom (misalnya memakai AES dua kali), dalam kasus ini intercept via proxy tidak cukup (datanya sudah dienkrip, dan tidak bisa dengan mudah didekripsi karena formatnya custom). Di dalam kodenya pasti ada sesuatu yang mengenkrip data sebelum dikirim dan mendekrip data yang diterima, dengan mengintercept titik tersebut, saya tidak perlu menulis program khusus untuk dekrip/enkrip ketika testing.

Saya juga pernah membuat modul khusus untuk intersepsi Blackberry Messenger (BBM). Cara kerja modulnya seperti ini: saya membuat web server di Android yang bisa menerima pesan untuk dikirimkan, dan pesan itu saya inject langsung ke proses BBM. BBM selalu menyimpan message dalam format internalnya setelah diterima, jadi kita bisa mengakses message dari conversation manapun. Perlu dicatat bahwa modul ini bisa saya kembangkan dengan mudah karena di versi awal mereka tidak melakukan obfuscation, dan ketika sudah diobfuscate, saya masih bisa melihat mapping class/methodnya berdasarkan berbagai pesan error yang ada di method tersebut.

Untuk membuat XPosed module sendiri, sudah ada berbagai tutorial di Internet, tapi saya akan memberikan panduan singkat, sekaligus sebagai catatan untuk diri sendiri.

Pertama: buat proyek baru dengan Android studio. Pastikan instant run dimatikan karena tidak kompatibel dengan Xposed. Tidak perlu template khusus untuk membuat modul XPosed.

Kedua: edit file gradle dengan menambahkan dependensi: provided 'de.robv.android.xposed:api:82'. Tentunya versi 82 bisa diganti dengan versi terbaru.

Ketiga: implementasikan IXposedHookLoadPackage, ini sudah dicontohkan di atas.

Keempat: buat file app/src/main/assets/xposed_init yang adalah file teks dan isinya adalah nama package + kelas yang mengimplementasikan IXposedHookLoadPackage tersebut. Ini akan dipakai oleh Xposed untuk mendari kelas mana yang akan diload saat booting.

Terakhir: edit file manifest agar dikenali sebagai modul XPosed. Pertama tambahkan atribut xmlns:tools="http://schemas.android.com/tools" di tag manifest (ini sekedar untuk menghilangkan warning). Lalu tambahkan beberapa metadata berikut di dalam tag application:

<meta-data  android:name="xposedmodule"
android:value="true" />

<meta-data  android:name="xposedminversion"
android:value="54" />

<meta-data  android:name="xposeddescription"
android:value="Joe Hack Module"
tools:ignore="ManifestResource" />

Tentu saja bagian tersulit adalah mencari tahu bagian mana yang perlu dihook untuk mengimplementasikan fungsionalitas tertentu. Tapi menurut saya ini juga sekaligus menjadi bagian yang paling menarik: kita jadi lebih mengerti internal sistem Android.

Modifikasi dengan XPosed framework melengkapi hack Android yang lain. Rooting aplikasi tidak cukup untuk mengubah internal program (contohnya untuk pentest aplikasi custom). Modifikasi dan compile ROM sendiri bisa mengubah hal-hal yang di luar kemampuan XPosed, tapi tetap tidak bisa mengubah aplikasi. Modifikasi aplikasi dengan cara patching manual bisa dilakukan, tapi cara ini lebih repot, dan akan sulit jika kita ingin mempatch banyak aplikasi sekaligus.

Sebagai pembuat aplikasi, mengobfuscate aplikasi Anda adalah salah satu cara untuk mempersulit hooking dengan XPosed framework. Contohnya: aplikasi Youtube sering diobfuscate dan sering diupdate sehingga modul seperti YoutubeAdaway tidak jalan.

Programming dan Penetration Testing

Pentest adalah kegiatan menyerang sistem komputer untuk mencari kelemahan security, atau dari Wikipedia:

A penetration test, or the short form pentest, is an attack on a computer system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data.

Pentesting dilakukan atas permintaan client, jadi bukan hacking ke sembarang website. Contoh sederhana pentesting seperti ini: coba jebol website perusahaan kami, apakah ada bug securitinya? atau: coba pergi ke lobi atau tempat parkir perusahaan kami, apakah ada WIFI terbuka, apakah dari situ bisa masuk ke sistem internal perusahaan kami?. Kami punya app mobile, apakah bisa “dijebol” (misalnya apakah kita bisa membuat request ke server supaya memberikan data user lain).

Karena ini blog mengenai programming, saya tidak akan membahas banyak mengenai pentesting, hanya ingin menunjukkan betapa keahlian programming bisa sangat berguna untuk pentesting. Dari contoh yang saya sebutkan di atas, scope dari pentesting bisa sangat banyak, mulai dari yang on site: datang dan mengecek kabel, wireless network, dsb, sampai ke level network dan aplikasi (baik web, desktop, mobile). Saya hanya ingin membahas aspek programming, untuk mendorong peminat bidang security agar mau belajar programming.

Perkiraan saya mungkin sekitar 70% pekerjaan pentesting bisa dilakukan dengan tools yang sudah tersedia, baik yang open source maupun komersial, tanpa butuh keahlian scripting ataupun programming. Sisanya bakal butuh programming. Bahkan saya yakin 100% beberapa jenis bug tidak bisa ditemukan tanpa keahlian programming.

Screenshot_2014-11-27-18-19-36

Kemampuan programming minimal yang dibutuhkan adalah bisa mengcompile atau menjalankan program dalam berbagai bahasa. Kadang di sebuah server tidak tersedia tool tertentu, jadi kita perlu mengcompile dari source karena OS di server itu sudah terlalu lama (misalnya masih banyak yang memakai RHEL 4). Jika tidak tahu bagaimana menjalankan sesuatu, maka sudah game over di titik ini. Pernah saya baca di blog pak Budi Rahardjo mengenai kompetisi CDC (Cyber Defense Competition):

Salah satu soal yang disampaikan adalah men-decode data base64 yang kemudian menjadi skrip Python, yang tinggal dijalankan. Lucunya ada banyak yang gak tahu Python. ha ha ha. Mereka kebingungan menjalankannya. Padahal tinggal “python namaskrip.py”. Mereka tidak perlu tahu bahasanya. hi hi hi. Ada yang pura-pura tahu dan me-rename menjadi bahasa C, menambahkan “#include ” dibagian awalnya, kemudian mencoba compile. Ya gak bakalan jalanlah. he he he.

Kejadian semacam di atas itu yang mendorong saya menulis tulisan seperti ini.

Keahlian lain adalah mencari program atau menulis program kecil dalam bahasa tertentu yang kadang tidak terlalu umum atau sudah kuno. Contoh: jika sebuah web server bisa menerima upload file, dan web server itu hanya bisa menjalankan ASP versi klasik, ya kita harus bisa mencari shell dalam ASP Classic (bukan ASP.NET). Berbeda dengan software development biasa di mana kita bisa memilih bahasa pemrograman atau teknologi yang ingin kita pakai, di sini kita dipaksa mengikuti apa yang tersetup di server.

Jika beruntung, sudah ada orang yang menuliskan program standar (web shell) yang memiliki fungsi seperti “file manager/file upload” (untuk mengupload tool tambahan), “shell” (untuk mengeksekusi command apapun di sisi server), dan “database shell” (untuk mengirimkan query apapun ke database). Jika tidak beruntung, atau ada batasan tertentu di server, mungkin kita perlu membuat tool baru. Contoh sederhana: jika server membatasi upload hanya 100 KB saja, sementara binary nmap yang ingin diupload (plus librarnya) besarnya beberapa megabyte, maka kita perlu membuat program kecil untuk mengupload parsial lalu menggabungkan hasil uploadnya.

Keahlian membaca kode dalam berbagai bahasa juga diperlukan. Dalam beberapa kasus, kita bisa mendapatkan akses ke source code aplikasi web (karena bug, karena salah konfigurasi, karena lupa ikut mengupload direktori “.git”, dsb). Setelah punya source code, kita bisa menemukan bug tambahan dengan membaca kodenya. Sebagai pentester, tentunya Anda tidak akan bilang: wah ternyata dia pake Python, saya nggak tau cara ngehack aplikasi web dengan Python.

Dengan membaca source code, hal paling minimal adalah mengerti di mana file konfigurasi supaya bisa mengekstrasi user/password database, berikutnya adalah mencari bug-bug tambahan seperti SQL Injection, hidden functionality, dsb.

Dengan maraknya OS Mobile, sekarang pentesting juga masuk ke ranah mobile. Di sini ilmu reverse engineering sangat diperlukan. Untuk OS Android, reverse engineering bisa dilakukan dengan decompiler yang bisa mengembalikan kode Java ke bentuk semula (kecuali sudah diobfuscate), jadi kembali keahlian membaca kode diperlukan.

Setelah mengetahui kodenya, biasanya kita perlu melakukan fuzzing request, alias mencoba-coba berbagai kemungkinan request. Untuk aplikasi berbasis HTTP, kita masih bisa memakai proxy (misalnya ZAP) dan mengubah-ubah request untuk tahu reaksi server (bagaimana jika nilaiya negatif, bagaimana jika nama file mengandung “../”, dsb). Tapi untuk aplikasi yang memakai protokol khusus via SSL, kita perlu memahami, lalu mengimplementasikan ulang client sendiri yang bisa melakukan fuzzing.

Pengetahuan mengenai best practice dalam sebuah bahasa juga diperlukan dalam membuat aplikasi yang aman. Contoh: untuk menghasilkan bilangan random untuk kriptografi di Java gunakan SecureRandom (jangan Random). Di Android untuk melakukan koneksi SSL menggunakan socket, jangan gunakan SSLFactory tapi gunakan SSLCertificateSocketFactory, dsb. Pekerjaan pentester cukup mudah di sini, hanya menyarankan saja, dan programmer yang akan mengimplementasikan saran tersebut.

Saya sudah banyak menemukan bug yang memerlukan banyak coding. Ada bug yang terkait dengan penyimpanan password (terenkripsi) yang disimpan lokal di device yang seharusnya aman, tapi ternyata saya bisa membuat tool yang cukup optimal untuk bisa mengcrack dalam 1 jam karena banyak hal kecil yang lupa dilakukan oleh programmer (lupa menginisialisasi IV, memakai EBC). Saya pernah menemukan bug fatal yang berhubungan dengan menggunakan algoritma hashing yang tidak aman (tidak memakai Cryptographic Hash Function). Dengan tools yang tersedia saja, tanpa pengetahuan programming (dan kriptografi), kedua bug itu tidak akan bisa ditemukan.

Jadi saran saya: untuk mereka yang tertarik di bidang security, pelajari juga bagian programmingnya. Ini saya masih bicara level pentesting yang kebutuhkan programmingnya masih minimal. Di bagian lagin security, keahlian programming lebih dibutuhkan lagi, misalnya membuat exploit butuh pemahaman yang lebih mendalam tentang sistem dan low level programming.

Dalam full security audit, selain pentesting kadang client menginginkan juga review kode mereka, jadi kita perlu bisa membaca, menjalankan, dan memberi saran yang berkaitan dengan security.

Buat saya sendiri sebagai programmer, saya jadi rajin membaca mengenai best security practice untuk berbagai bahasa dan framework. Jika ada yang bertanya: buat apa sih belajar bahasa X atau teknologi Y, saya bisa bilang: mungkin suatu saat ada sistem yang memakai teknologi itu yang perlu saya test.