Reverse Engineering Aplikasi iOS

Sudah lama saya menuliskan tentang reverse engineering Android tapi sampai saat ini belum menuliskan untuk iOS. Tulisan ini akan memperkenalkan cara reverse engineering aplikasi iOS dengan berbagai pendekatan. Tujuan utamanya di sini adalah untuk pentesting. Reversing untuk tujuan lain (misalnya Tweak development) sebagian akan sama, tapi masih butuh usaha dan tool ekstra dan hanya akan saya bahas sekilas.

Mesin macOS dan XCode

Memiliki mesin macOS akan sangat membantu dalam reverse engineering. Mesin ini bisa fisik asli dari Apple (Macbook, MacMini atau yang lain), mesin tidak resmi (Hackintosh), atau bahkan Virtual Machine. Pengunaan utamanya adalah untuk menjalankan Xcode terbaru dan iTunes.

Sebenarnya ini tidak 100% wajib, karena kebanyakan tool bisa berjalan di OS Lain. Misalnya di Linux saya memakai libimobiledevice untuk menginstall IPA, membaca log dari device, dsb. Tapi biasanya jika ada iOS baru, berbagai tool di luar OS X akan berhenti bekerja sampai beberapa hari atau bulan, menunggu developernya memahami apa yang diubah Apple dan bagaimana memperbaikinya.

Device iOS dan Simulator

Di dunia Android, kita bisa menjalankan hampir semua APK Android di Emulator kecuali beberapa yang butuh akses hardware tertentu. Emulator Android mengemulasikan keseluruhan hardware dan bisa menjalankan APK meskipun APK tersebut memakai kode biner ARM/ARM64.

Tapi saat ini tidak ada emulator iOS yang bisa diakses umum dengan mudah. Hanya ada satu perusahaan bernama Correlium yang menyediakan emulator dan inipun saat ini clientnya masih sangat dibatasi. Masih lebih mudah dan murah membeli iPhone bekas daripada mendapatkan akses ke Correlium.

Apple hanya menyediakan simulator untuk x86, artinya kita harus mengcompile khusus source code kita supaya jalan di simulator yang disediakan. Jika kita mendownload IPA dari App Store, binarynya pasti ARM/ARM64/ARM64e dan tidak akan jalan di simulator.

Jadi jika kita ingin melakukan analisis dinamik, maka kita perlu hardware iOS tergantung aplikasinya mungkin akan butuh iPhone atau iPad. Beberpa aplikasi bisa juga berjalan di iPod Touch (tapi aplikasi banking yang butuh verifikasi SMS sering kali tidak mau jalan di iPod Touch).

Ketika membeli hardware iPhone/iPad bekas, harap diperhatikan versi iOS yang masih didukung dan kira-kira masih akan didukung atau tidak dalam waktu dekat ini. Contoh: saya membeli iPhone 5S baru sekitar 5 tahun yang lalu dan hardware ini masih bisa dipakai sampai sekarang (mendukung iOS 12), tapi kemungkinan besar tidak akan disupport lagi akhir tahun ini (kemungkinan tidak akan mendukung iOS 13). Update setelah WWDC: iPhone 5S tidak termasuk dalam device yang bisa memakai iOS 13, minimum adalah iPhone 6S.

Ketika tulisan ini dibuat (Mei 2019), jika ingin membeli iPhone, hardware minimal yang saya sarankan adalah iPhone 7 Plus. Alasannya:

  • Versi baru ponsel ini masih dijual oleh Apple
  • Harga second hand benda ini mulai reasonable
  • Prosessornya A10, sama seperti yang dipakai iPod Touch generasi 7 yang baru saja diluncurkan
  • versi 7 Plus memiliki RAM 3 GB (versi 7 saja tanpa plus, hanya 2 GB) jadi kemungkinan akan bisa dipakai untuk beberapa iOS mendatang

Jika dana terbatas belilah iPhone 6S yang bisa dipakai setidaknya setahun lagi. Jika ingin lebih jauh lagi, menurut saya iPhone XR merupakan pilihan yang baik:

  • Harganya cukup jauh di bawah iPhone XS
  • Sudah memakai A12, bisa belajar Pointer Authentication

Tapi tentu saja jika ada dananya, silakan saja beli iPhone terbaru dan termahal.

File IPA

Jika di Android kita memakai file APK untuk instalasinya, maka di iOS kita memakai format IPA. Seperti APK, format IPA ini sebenarnya juga hanya file berformat zip yang di dalamnya berisi resource (gambar, suara, dsb) dan program. Tapi tentu saja walau sama-sama file ZIP, keduanya tidak kompatibel karena isinya benar-benar berbeda.

Khusus untuk format PNG, Apple memakai optimasi khusus sehingga perlu dikonversi kembali. Di OS X ini bisa dilakukan dengan pngcrush. Perlu dicatat pngcrush di OS lain tidak memiliki opsi yang sama, jadi gunakan tool lain untuk mengembalikan PNG agar bisa dilihat. Ini hanya contoh kecil mengapa memiliki hardware macOS plus XCode bisa memudahkan proses RE.

Tanda tangan digital dan Enkripsi

Setiap aplikasi yang berjalan di iOS harus ditandatangani secara digital. Selain itu setiap aplikasi dari App Store dienkrip (memakai DRM Fair Play) dan hanya bisa dipakai di account tertentu. Artinya saya tidak bisa mendownload file IPA dari app store dengan account saya dan langsung ditransfer ke iPhone orang lain.

Jika ingin disebarkan ke orang lain, sebuah program perlu didekrip. Proses dekripsi butuh iPhone/iPad yang sudah dijailbreak. Saat ini belum ada yang berhasil mengekstrasi key dari account, jadi sebuah hardware wajib dimiliki. Program yang dienkrip tidak bisa direverse engineer. Bisa saja dipaksa dibuka di disassembler, tapi instruksinya tidak masuk akal.

Dalam proses pentesting kadang client meminta kita testing dari app store dan kadang dari developer. Proses enkripsi ini dilakukan oleh Apple di server apple, jadi aplikasi yang belum diupload ke App Store masih dalam kondisi tidak terenkripsi. Jika kita dibolehkan meminta dari developer, maka akan lebih mudah melakukan reversing tanpa perlu hardware untuk mendekrip.

Jailbreak

Saat ini jailbreak sangat penting untuk security researcher iOS. Tidak semua versi iOS bisa dijailbreak dan pada semua versi iOS beberapa tahun terakhir kita tidak bisa dengan mudah downgrade ke versi sebelumnya. Satu-satunya cara untuk pindah ke sebuah versi tertentu adalah jika kita punya yang namanya SHSH blob untuk versi tersebut yang spesifik untuk device kita. Di ponsel dengan CPU A12, proses ini lebih kompleks lagi.

Jadi jika kita membeli ponsel dengan software terbaru dan belum ada jailbreaknya, tidak ada yang bisa kita lakukan selain menunggu sampai ada yang menjailbreak. Selagi menunggu, kita bisa menyimpan blob SHSH untuk versi berikutnya. Jadi misalnya kita ada di versi 12.3 (belum ada jailbreak) dan sudah ada versi 13 (belum ada jailbreak juga), kita bisa menyimpan blob untuk versi 13. Nanti misalnya ada jailbreak untuk versi 13 kita bisa upgrade ke versi tersebut.

Biasanya ketika ada jailbreak untuk versi tertentu (misalnya 13), dan Apple sudah merilis vesi lebih baru (misalnya 13.1) maka “signing window” akan ditutup, artinya kita tidak bisa lagi upgrade ke versi 13 tapi harus langsung ke 13.1. SHSH blob hanya bisa dipakai di device yang sudah dijailbreak karena perlu akses root untuk set nonce.

Ini berbeda dengan sebagian device Android yang mengijinkan unlocked bootloader. Pada device Android dengan unlocked bootloader, kita bisa me-root ponsel kita dengan sangat mudah. Di Android APK dari playstore juga tidak dienkripsi (hanya ditandatangi digital) jadi rooting juga tidak wajib dilakukan.

Perlu diperhatikan: banyak website menyesatkan yang menyatakan bisa jailbreak iOS terbaru. Informasi terkini dan valid mengenai berbagai device dan versi iOS yang bisa dijailbreak serta tool untuk jailbreaknya bisa dilihat di:

https://www.reddit.com/r/jailbreak/wiki/escapeplan/guides/jailbreakcharts

Setelah jailbreak, tool yang bisa digunakan untuk mendekrip aplikasi adalah Clutch (iOS versi lama), bfinject (iOS 11) dan CrackerXI (iOS 12).

Developer Account

Untuk device yang tidak dijailbreak, semua aplikasi yang diinstall harus ditandangani digital. Dulunya kita perlu memiliki developer account (99 USD/tahun) untuk bisa menjalankan aplikasi apapun di device kita. Ini termasuk juga aplikasi/IPA yang sudah didekrip tetap perlu ditandatangani agar berjalan di device kita.

Tapi sekarang sudah ada kelonggaran: kita bisa menandatangani gratis tapi hanya berlaku 7 hari. Artinya setelah 7 hari, aplikasi tersebut tidak bisa berjalan, kita harus menandatangani (sign) dan menginstall lagi tiap 7 hari. Maksimum dalam satu waktu kita bisa menginstall 3 aplikasi dengan account gratis ini dan maksimum hanya 2 device per Apple ID. Proses reinstall ini butuh waktu dan butuh komputer. Saat ini cara termudah instalasi tanpa developer account dan tanpa jailbreak adalah dengan Cydia Impactor.

Untuk proyek jangka pendek dan untuk testing, account gratis ini sudah cukup. Tapi jika kita perlu sering melakukan ini, developer account akan sangat membantu. Tanpa developer account, beberapa hal cukup mengesalkan, misalnya:

  • Cydia Impactor sering tidak jalan di iOS terbaru (harus menunggu rilis terbaru),
  • Kita perlu membuat password iCloud spesifik untuk Cydia Impactor (dan kadang password ini expire, harus diset ulang)
  • Cydia impactor ini tidak mengingat password (harus ketik ulang atau copy paste)
  • Jika instalasi gagal, harus memasukkan ulang password
  • Jika ada banyak pekerjaan pentest, batas jumlah aplikasi akan terlampaui

Jika ponsel sudah dijailbreak, kita bisa memakai Reprovision yang berjalan di ponsel dan otomatis menandatangani ulang aplikasi tiap 7 hari. Tapi tentunya batasan jumlah aplikasi tetap berlaku.

Karena hasil dari testing iOS ini sudah jauh lebih besar dari harga developer account per tahun, saya memilih memakai developer account. Selain itu accountnya bisa saya pakai untuk development.

Membuat Aplikasi iOS

Mengenal cara sebuah aplikasi dibuat akan sangat membantu dalam proses reverse engineering. Khusus untuk pentesting, kadang developer meminta saran pada kita bagaimana memperbaiki sesuatu. Terkadang memberikan link saja sudah cukup, tapi di kasus tertentu sebuah solusi tidak bisa dipakai dan kita akan dipandang sebagai pentester yang baik jika kita bisa memberi saran perbaikannya.

Aplikasi iOS dulunya hanya ditulis dengan Objective C. Objective-C masih merupakan bahasa utama yang dipakai di seluruh sistem operasi, sama seperti Java di Android. Seluruh API utama masih menggunakan Objective C. Selain itu sekarang Apple mendukung bahasa Swift.

Sebuah aplikasi iOS akan dikompilasi menjadi format MachO. Format ini berbeda dengan ELF (Linux) dan PE (Windows) sehingga tool yang dipakaipun berbeda. Program bawaan XCode adalah otool yang bisa dipakai untuk men-dump file MachO (seperti objdump di Linux). Selain itu ada jtool yang fungsinya lebih banyak.

Saya sangat menyarankan reverser iOS memahami minimal C dan Objective C. Jika memahami Swift akan lebih baik lagi karena aplikasi modern sekarang ditulis menggunakan Swift. Cobalah membuat aplikasi Objective-C sederhana, lalu reverse engineer aplikasinya.

Sekarang ada banyak teknologi yang bisa dipakai untuk mengembangkan aplikasi iOS misalnya:

  • Cordova dan teknologi lain berbasis HTML
  • Unity (berbasis C#)
  • RubyMotion (Ruby)

Saya akan mengasumsikan aplikasi yang akan direverse engineer menggunakan Objective C atau Swift. Jika menggunakan bahasa lain, maka pelajarilah teknologi tersebut (di luar scope artikel ini). Ketika belajar Objective-C jangan lupa belajar teknik tingkat lanjut seperti Method Swizzling yang bisa dipakai untuk runtime patching sebuah method/class Objective C.

Assembly ARM64

iPhone versi awal memakai Thumb/ARM32, tapi saat ini semua device iOS terbaru memakai instruction set ARM64 jadi jika Anda belum pernah belajar ARM 32 bit bisa langsung skip ke ARM64. Secara teori jika kita memakai decompiler kita tidak perlu memahami level assembly, tapi kenyataanya:

  • Decompiler sering salah atau tidak lengkap hasil dekompilasinya
  • Beberapa aplikasi menggunakan proteksi yang menyulitkan decompiler
  • Untuk patching, kita tetap perlu paham assembly

Jadi saran saya: pelajarilah dasar assembly ARM64. Semakin dalam eksplorasi yang dilakukan, pengetahuan ARM64 yang dibutuhkan juga semakin banyak.

Untuk memulai belajar ARM, saya menyarankan website https://azeria-labs.com/. Websitenya sangat lengkap dan berfokus pada ARM secara umum (tidak spesifik ke teknologi untuk iOS).

Contoh dekompilasi dengan Ghidra

Langkah-langkah reverse engineering

Secara umum langkah-langkah reverse engineering Aplikasi iOS adalah sebagai berikut:

  • Dapatkan versi aplikasi yang tidak terenkripsi (langkah wajib). Bisa dari developernya atau dari dekrip aplikasinya
  • Opsional: gunakan class-dump untuk mendapatkan gambaran aplikasi
  • Bongkar aplikasinya dengan disassembler/decompiler
  • Opsional: lakukan dynamic reverse engineering dengan Frida atau Cycript
  • Opsional: lakukan patching aplikasi jika ada jailbreak detection

Langkah pertama sudah jelas, dan langkah-langkah berikutnya pada dasarnya adalah memakai berbagai tool.

Class-dump

Tool class-dump dapat digunakan untuk menghasilkan header objective-c dari binary Mach-O. Berbagai decompiler seperti Hopper, IDA Pro dan juga Ghidra bisa mengekstrak informasi ini secara otomatis, tapi class dump ini masih berguna karena:

  • Prosesnya cepat
  • Setelah mendapatkan header kita bisa dengan cepat melihat-lihat nama fungsi yang ada

Disassembler/Decompiler

Baik jtool maupun otool bisa mendisassemble file MachO, tapi untuk file yang berukuran besar proses membaca assembly memakan waktu lama. Biasanya sama memakai gabungan decompiler dan disassembler untuk memahami sebuah program.

Ghidra tools gratis dari NSA

Dulu satu-satunya decompiler untuk iOS adalah IDA Pro yang harganya mahal. Sekarang ini ada opsi gratis: Ghidra (pernah saya bahas di sini) dan ada opsi yang harganya relatif murah: Hopper. Kualitas dekompilasi Ghidra lebih bagus dan bisa berjalan cross platform, sementara tampilan Hopper lebih menarik.

Frida dan Cycript

Seringkali reversing statik sulit dilakukan dan modifikasi dinamik lebih cepat untuk memahami sebuah aplikasi. Ada dua tool yang berguna untuk ini: Frida dan Cycript. Untuk saat ini saya lebih menyarankan Frida karena masih dipelihara terus.

Frida bisa dijalankan di ponsel yang sudah dijailbreak (bisa meng-hook semua aplikasi) atau pada satu aplikasi di ponsel yang tidak dijailbreak. Untuk yang sudah dijailbreak, langkahnya lebih sederhana. Untuk yang belum dijailbreak:

  • Ekstrak IPA-nya (harus sudah didekrip)
  • Edit binarynya agar meload Frida (misalnya dengan insert_dylib)
  • Masukkan shared library Frida ke dalam aplikasi

Aplikasi kemudian perlu dijalankan dalam mode debug, karena tanpa ini beberapa fungsionalitas Frida tidak akan berjalan. Setelah frida berjalan, kita bisa menulis skrip dalam javascript untuk menginspeksi atau mengubah jalannya program.

Binary Patching

Jika jailbreak detection dilakukan di satu method terpisah (misalnya: isJailBroken) maka ini biasanya bisa diintercept oleh Frida dan tinggal diganti agar mengembalikan falses (“return 0”). Tapi kadang deteksi jailbreak dilakukan sambil melakukan hal lain. Kelemahan frida adalah: kita hanya bisa menambah/mengubah sesuatu di awal/akhir fungsi, jadi dalam kasus tertentu kita masih butuh melakukan patching.

Tidak ada yang istimewa dalam patching file MachO. Asalkan kita bisa mengerti ARM64, kita bisa mempatch opcode seperti biasa dengan hex editor.

Tweaks

Jika kita memakai iOS yang dijailbreak, maka kita bisa menginstall Tweaks. Tweaks ini pada dasarnya adalah shared library (dylib) yang akan diinjeksikan oleh daemon jailbreak ke proses target. Ada tweak tertentu yang bisa membantu proses reverse engineering/pentesting, misalnya ssl-kill-switch 2 untuk mendisable SSL Pinning.

Kita juga bisa membuat sendiri Tweaks untuk iOS dengan menggunakan Xcode, tapi biasanya tweaks dibuat menggunakan Theos. Kelebihan Theos dibandingkan Xcode adalah tersedianya SDK dengan private headers, yang berisi interface fungsi-fungsi yang tidak publik.

Penutup

Artikel ini masih merupakan perkenalan dan baru menyentuh hal-hal dasar reversing aplikasi iOS. Seperti bisa dilihat bahwa untuk terjun ke reversing iOS secara nyaman dibutuhkan uang yang lumayan (untuk membeli hardware macOS dan iPhone) atau waktu yang cukup banyak (setup Hackintosh).

Beberapa aplikasi dan game terkenal memakai berbagai teknik yang membuat reverse engineering iOS menjadi cukup sulit. Karena tingkat kesulitannya. para hacker game iOS bisa mendapatkan uang cukup banyak dari hacking berbagai game dan aplikasi iOS (contohnya developer ini).

Ghidra Tools Reverse Engineering dari NSA

Baru-baru ini NSA (National Security Agency) Amerika merilis tools RE baru bernama Ghidra yang gratis. Rencananya ini akan open source, tapi saat ini repositorynya masih kosong. Ghidra ini merupakan saingan IDA Pro yang saat ini harganya sangat mahal. Sebagai informasi: harga license IDA Pro paling murah ratusan USD (versi starter edition), sampai totalnya puluhan ribu USD jika kita ingin paket lengkap (IDA Pro dengan semua plugin decompilernya).

Ghidra

Tulisan kali ini merupakan kesan pertama memakai Ghidra. Perlu dicatat bahwa pekerjaan utama saya bukan reversing. Ini sekedar hobi buat saya. namun demikian saya sudah melakukan reversing beraneka hal baik yang populer seperti Windows/Linux/Mac/Android/iOS maupun berbagai target yang unik, misalnya hardware Pokemon Go Plus (berbasis ARM), berbagai challenge Flare-On (campuran), Challenge BEVX (Arm), dan RHME (AVR).

Sebelum memakai Ghidra ini saya sudah mencoba berbagai tool disassembler/decompiler, termasuk juga: IDA Pro, retdec, radare (dan interface GUI-nya: Cutter), Hopper, Binary Ninja. Bahkan untuk menyelesaikan challenge RHME, saya memakai objdump + editor teks karena tidak ada tool yang bagus untuk reversing AVR. Secara singkat: fitur Ghidra ini sangat bagus dibandingkan berbagai tool yang sudah pernah saya coba.

Ghidra ditulis dalam bahasa Java dengan GUI Swing dan tentunya memakai beberapa library native juga. Perlu diperhatikan: Ghidra ini butuh JDK11, jadi ketika mendownload Ghidra, jangan lupa sambil download JDK-nya dari Oracle.

Daftar prosessor yang didukung Ghidra. IDA Pro mendukung lebih banyak prosessor, tapi tidak semuanya bisa dekompilasi, sedangkan Ghidra bisa mendekompilasi apa saja

Hal pertama yang akan saya bahas adalah decompilernya. Ada banyak tool decompiler di dunia ini, tapi selain IDA Pro, hasilnya banyak yang kacau dan sangat menyesatkan. Hasil dekompilasi Ghidra ini sangat bagus, dan dibandingkan IDA Pro: dia mendukung dekompilasi semua arsitektur yang disupport (IDA hanya mendukung: X86 32/64 bit, ARM 32/64 bit, PowerPC 32/64 bit). Contohnya jika kita ingin melakukan reverse engineering router (banyak yang memakai MIPS) maka dekompilasi bisa dilakukan.

Dekompilasi kode MIPS dengan struktur flow-control yang kompleks

Untuk arsitektur 8 bit yang saya coba, dekompilasi bisa dilakukan, tapi sering kali tetap sulit dibaca manusia. Jadi dengan adanya decompiler ini tidak berarti seorang pemula tiba-tiba akan bisa melakukan RE apa saja.

Dekompilasi challenge AVR Secret Sauce dari RHME

Challenge Flare On kadang memberikan soal DOS (X86) 16 bit. IDA Pro tidak mendukung dekompilasi kode 16 bit, tapi Ghidra bisa melakukannya. Sayangnya tool ini tidak memahami parameter untuk interrupt. Untungnya decompilernya memiliki kelebihan lain: jika kita mengklik pada sebuah instruksi, maka instruksi yang bersangkutan akan dihighlight di bagian disassembly, jadi kita bisa melihat secara manual parameter untuk sebuah interrupt.

Ghidra ini mendukung sistem plugin, jadi menambahkan support processor baru dapat dilakukan dengan relatif mudah, setidaknya itu kesan pertama ketika membaca dokumentasinya. IDA Pro juga memiliki SDK, tapi SDK-nya sangat ribet. Di masa depan sepertinya akan ada semakin banyak prosessor baru yang didukung.

Salah satu kelemahan besar IDA Pro adalah tidak adanya kemampuan Undo/Redo. Artinya jika kita salah menekan “U” (undefine) di satu blok kode yang sudah kita beri komentar atau kita ubah tipe datanya, tiba-tiba kita bisa kehilangan semuanya. Menekan “C” lagi bisa mengembalikan data menjadi kode, tapi semua perubahan lain sudah hilang. Dalam kasus tertentu bahkan ini membuat semua jadi error. Jadi biasanya flow kerja memakai ida pro adalah: jika kita sudah puas dengan sesuatu kita harus save, dan jika membuat kesalahan: load ulang. Ghidra mendukung Undo/Redo, jadi tidak ada masalah ini.

Membahas mengenai shortcut “U” dan “C” di atas mengingatkan saya pada masalah shortcut: berbagai shortcut Ghidra berbeda dengan IDA Pro. IDA Pro karena muncul pertama kali, maka shortcutnya ditiru berbagai tool lain. Tapi Ghidra ini memakai shortcut yang berbeda yang membuat saya harus berpikir keras. Contoh yang mengganggu: di IDA Pro “C” adalah untuk mengubah menjadi kode dan “D” untuk mengubah menjadi data. Di Ghidra “D” dipakai untuk melakukan disassembly (mengubah menjadi kode) dan “C” dipakai untuk Clear Code bytes (mengubah menjadi undefined).

Contoh kecil lain: X untuk cross reference di berbagai tool menjadi Control-Shift-F. Sebenarnya ini semua bisa diubah (ada opsinya) tapi defaultnya terasa membingungkan.

Ada fitur yang akan berguna untuk team: shared project. Ini sesuatu yang tidak bisa dilakukan oleh IDA Pro ataupun tools disassembler/decompiler lain. Karena saya tidak pernah mengerjakan reverse engineering bersama orang lain, maka saya tidak mencoba fitur ini.

Dalam mode debug, ada sedikit kecerobohan dalam skrip startup yang mensetup JDWP (Java Debug Wire Protocol) sehingga listen ke * (semua interface) dan bukan ke 127.0.0.1. Dengan ini orang yang berada di jaringan yang sama bisa mengeksekusi kode di mesin kita melalui port itu. Ini mudah diperbaiki, hanya perlu edit skrip launchernya saja. Sebagian orang menyebut ini backdoor, tapi menurut saya ini sekedar kecerobohan karena lupa untuk setup debugging (gunanya JDWP adalah untuk mendebug program Java). Perhatikan sekali lagi: ini hanya akan terbuka dalam mode debug, defaultnya mode ini tidak aktif, kita harus secara manual menjalankan dari command line dengan parameter tertentu untuk masuk mode debug ini.

Meskipun Dalvik tercantum dalam daftar prosessor, tapi saya tidak berhasil meload classes.dex dari file APK (walaupun saya malah bisa membuka berbagai library native yang ada di dalam APK). File JAR bisa dibuka, tpai tool ini tidak lebih baik dari decompiler khusus untuk Java. Jadi secara umum: untuk tujuan khusus, Ghidra ini masih kurang bagus dibandingkan tool lain.

Demikian review singkat tool Ghidra ini. Saya berencana akan lebih banyak lagi memakai tool ini untuk menggantikan berbagai tool yang saya pakai saat ini. Saya berharap source code lengkap Ghidra segera dirilis sehingga akan ada banyak kontribusi dari banyak pihak agar Ghidra lebih nyaman dipakai dan mendukung lebih banyak arsitektur.

Root check dan jailbreak check pada aplikasi mobile

Artikel ini akan membas mengenai metode untuk mengecek root (pada Android) atau jailbreak (pada iOS) dan mengapa pemeriksaan ini diperlukan. Berikut saya akan membahas bagaimana melakukan bypass pengecekan ini supaya seorang pentester bisa melakukan testing pada aplikasi mobile.

Apa itu rooting/jailbreak?

Baik rooting maupun jailbreak gunanya adalah untuk mendapatkan hak akses setara administrator pada mobile device yang kita miliki. Di Android kita bebas menginstall aplikasi apa saja, di iOS sebuah aplikasi hanya bisa diinstall dalam mode development, dengan jailbreak maka aplikasi tambahan bisa diinstall.

Jika device sudah dijailbreak/root maka sebuah aplikasi kemudian bisa diberi hak untuk melakukan apa saja, termasuk juga membaca data privat aplikasi lain. “Melakukan apa saja” bisa berarti positif, misalnya kita bisa mengganti berbagai aplikasi sistem dengan versi yang lebih baik, menghapus aplikasi bawaan sistem yang tidak terpakai, dsb.

Biasanya seseorang dengan sengaja melakukan rooting/jailbreaking pada devicenya sendiri supaya bisa melakukan hal-hal yang sebelumnya tidak bisa diijinkan oleh sistem. Contohnya: kita bisa mengganti isi file hosts untuk memblokir iklan di berbagai aplikasi, atau meningkatkan privasi dengan menggunakan aplikasi tertentu yang mencegat berbagai kebocoran informasi (misalnya dengan XPrivacyLua), atau bahkan sekedar untuk mencurangi game tertentu.

Tapi proses rooting/jailbreak ini juga bisa dilakukan oleh pihak lain, misalnya penjahat atau agen pemerintahan agar bisa menginstall aplikasi untuk mengendalikan ponsel kita, memata-matai menggunakan kamera/mikrofon, mencuri data bank, dsb. Proses jailbreak/rooting ini kadang bisa dilakukan secara remote (diinstall menggunakan eksploit tertentu tanpa sepengetahuan user), dan bisa juga melalui aplikasi yang diinstall dengan menipu user (contohnya di Android bisa berpura-pura jadi aplikasi cheat untuk game populer).

Memeriksa Jailbreak/rooting

Sebuah aplikasi yang penting (misalnya aplikasi bank) tidak ingin uang nasabahnya dicuri oleh program lain. Jadi logikanya begini:

  • Jika device dijailbreak/root, maka ada program lain yang bisa mencuri/mengubah data di aplikasi banking
  • Ada kemungkinan user tidak tahu bahwa devicenya dijailbreak/root, jadi aplikasi perlu mendeteksi dan memberitahu user

Setelah bisa mendeteksi device dijailbreak atau tidak, maka aplikasi bisa melakukan ini:

  • Meneruskan program, tapi memberi peringatan dulu ke user bahwa device dijailbreak
  • Tidak mau meneruskan, karena ada risiko bahwa user tidak mengerti apa itu root/jailbreak serta risikonya dan jika diberi pilihan dalam bentuk pertanyaan apapun maka user akan menjawab apapun asalkan programnya jalan terus

Proses pemeriksaan jailbreak/rooting

Proses pemeriksaan bisa banyak, ini bisa dilakukan dengan coding manual, atau menggunakan library yang sudah ada untuk mengecek ini (misalnya rootbeer). Apapun yang digunakan, biasanya pemeriksaannya seperti ini:

  • Cek apakah file tertentu ada atau tidak, ada file-file standar yang diciptakan oleh program root/jailbreak
  • Cek apakah ada aplikasi tertentu yang biasanya diinstall bersama dengan root/jailbreak
  • Cek apakah direktori tertentu bisa dibaca/ditulis

Untuk Android, ada juga pemeriksaan level sistem yang bisa dilakukan dengan menggunakan Safety Net.

Rooting/Jailbreak untuk pentesting

Sebagai pentester, memiliki HP dengan akses root/jailbreak sangat membantu untuk banyak hal:

  • Di iOS jailbreak dibutuhkan untuk mendekrip agar aplikasi dari app store bisa dianalisis dengan menggunakan disassembler/decompiler
  • Di Android rooting bisa dipakai untuk menginstall berbagai aplikasi seperti wireshark atau nmap (atau bahkan sebuah distribusi seperti Kali Linux) yang memungkinkan kita menggunakan Android sebagai device pentesting

Anti Rooting/Jailbreak detection

Nah sekarang kita memiliki masalah:

  • Memiliki HP yang diroot/jailbreak membantu proses pentesting
  • Aplikasi tertentu tidak mau jalan karena sudah kita root, dan aplikasi tersebut melalukan root/jailbreak detection

Ada beberapa pendekatan agar aplikasi menyangka bahwa device saat ini tidak diroot/jailbreak

  1. Memakai aplikasi penyembunyi, misalnya di Android ada RootCloak, Magisk dsb, di iOS ada Flex 2, Liberty Lite dsb. Tool-tool ini saling berlomba dengan pembuat detektor jailbreak, jadi di masa depan mungkin akan muncul tool-tool lain
  2. Modifikasi aplikasi agar aplikasi tersebut terus jalan walaupun device sudah diroot/jailbreak. Modifikasi bisa dilakukan temporer (dengan skrip Frida) atau permanen (dengan mengedit file smali-nya).

Cara pertama merupakan cara termudah, tinggal install aplikasi tertentu dan harapannya aplikasi akan mau terus berjalan. Sayangnya ini tidak selalu berhasil. Beberapa aplikasi memiliki proses deteksi yang sering tetap bisa mendeteksi anti jailbreak ini. Sebagai catatan: untuk saat ini Magisk bisa tersembunyi dari hampir semua aplikasi. Kelemahan Magisk adalah: kita tidak bisa menginstallnya bersamaan dengan XPosed Framework, jika diinstall bersamaan, maka akan terdeteksi dengan metode Safety Net.

Cara patching selalu berhasil, tapi masalahnya adalah ini tidak mudah. Diperlukan skill reverse engineering untuk mencari tahu di mana proses deteksi dilakukan, dan bagaimana modifikasinya agar aplikasi tetap jalan terus.

Jika aplikasi sifatnya tidak diobfuskasi (not obfuscated), maka pemeriksaan ini biasanya mudah dicari, apalagi jika namanya sangat jelas. Contohnya jika aplikasi memakai library RootBeer, pemeriksaannya sangat jelas karena nama methodnya “isRooted” mudah dilihat.

Pemeriksaan root dengan RootBeer

Tapi jika sebuah aplikasi sudah diobfuskasi (obfuscated), maka semua nama menjadi kurang jelas. Jika kode diatas sudah obfuscated, maka bisa muncul kira-kira seperti ini:

Kode yang sama, obfuscated, tentunya komentar tidak akan muncul ketika kode didekompilasi

Biasanya kode seperti ini bisa dicari dengan melihat berbagai string yang ada. Contohnya, jika root ketemu, maka aplikasi menampilkan dialog dengan string “Ponsel Anda diroot”. Untuk ini kita hanya perlu mencari string “Ponsel Anda diroot” dan bisa ditebak kondisi “if” mana yang perlu diubah.

Tentunya programmer bisa membuat pengecekan ini ini jadi semakin sulit. String bisa dienkripsi, jadi jika dicari tidak akan ketemu (kecuali kita dekrip dulu). Proses pemeriksaan root dan pengecekan juga bisa dipisah. Misalnya di kelas utama hanya mengeset variabel “z” menjadi true jika diroot. Di View yang lain baru kita cek isi variabel z. Proses pemeriksaan bisa dipanggil beberapa kali (jadi perlu dicek dibypass di banyak tempat, misalnya di waktu login, awal transaksi dan di akhir transaksi). Dan masih banyak lagi cara mempersulit agar pemeriksaan root tidak gampang dibypass.

Meski tidak gampang, tapi cara patching ini selalu berhasil jika penyerang cukup bisa memahami aplikasnya. Agar lebih sulit lagi, sebuah aplikasi kadang melakukan pemeriksaan terhadap signature packagenya, agar yakin bahwa aplikasi tersebut tidak diubah (ketika di-sign ulang, signature akan berubah). Dalam kasus ini pemeriksaan signature ini harus dipatch juga oleh pentester.

Protektor

Saat ini ada beberapa software protektor komersial yang memiliki proteksi yang cukup sulit. Contoh bentuk proteksinya:

  • File DEX dienkrip dan diload ketika aplikasi berjalan (runtime)
  • Pemeriksaan dilakukan di native library (harus memahami assembly)
  • Digunakan berbagai teknik antidebug dan anti tamper untuk mempersulit modifikasi

Semua proteksi ini bisa dibypass, tapi akan butuh waktu. Kadang ada orang yang menuliskan dengan detail teknik bypass protektor tertentu, tapi menurut saya ini agak sia-sia: setiap kali ada tulisan seperti itu, pembuat protektor akan mengubah sesuatu (kadang kecil sekali) sehingga langkah detail yang diberikan tidak lagi bisa dipakai.

Menurut saya yang lebih perlu adalah mengajarkan langkah umum bagaimana melakukan reversing. Dengan ini jika ada perubahan maka ilmunya akan tetap terpakai. Saya pernah menuliskan ini di blog saya yang lain.

Penutup

Banyak pentester pemula yang masih bingung dengan teknik pengecekan rooting seperti ini, jadi semoga artikel ini bisa membantu. Saat ini jika Anda tidak memakai XPosed Framework, maka Magisk bisa menyelesaikan 99% masalah deteksi rooting.

Di kesempatan lain saya berencana akan menulis lebih banyak mengenai SSL Pinning dan bagaimana melakukan unpinning. Topik SSL pinning ini merupakan topik sejenis yang sering dianggap sulit oleh pentester pemula. Tidak seperti rooting yang bisa diselesaikan dengan Magisk, berbagai aplikasi memakai teknik SSL pinning yang tidak standar sehingga butuh lebih banyak teknik manual.

Ransomware, Reverse Engineering dan Backup

Cukup banyak yang bertanya ke saya mengenai ransomware, selain itu sering juga di group reverse engineering ada yang bertanya: saya kena ransomware (dengan scren capture layar permintaan tebusan), diteruskan dengan: apa yang harus saya lakukan? Tulisan ini akan berusaha menjawab kenapa sulit mengatasi ini, kenapa percuma meminta tolong ke group reverse engineering, dan kenapa sebaiknya Anda perlu membackup file Anda.

Ransomware

Ransomware adalah jenis malware (software jahat) yang memaksa Anda mengirimkan uang ke pembuatnya melalui berbagai cara. Cara yang saat ini paling banyak dipakai adalah mengenkripsi file Anda, lalu jika Anda mengirim uang tebusan, maka Anda akan dikirimi key atau program untuk membuka file Anda. 

Jawaban singkat untuk yang kena ransomware: cobalah ke situs No More Ransom. Jika Anda beruntung, file Anda bisa kembali. Jika tidak, maka harapannya sangat kecil. Coba juga search nama ransomwarenya (jika ada nama yang unik yang muncul di layar ransom) dan coba baca apakah sudah ada yang membuat tool gratis untuk membukanya. Bagian berikut artikel ini hanya ingin menjelaskan kenapa file Anda sulit kembali.

Alternatif lain: Anda bisa membayar tebusan, tapi perlu dicatat: Andaikan Anda membayar uang tebusan, belum tentu file Anda bisa kembali. Tidak ada jaminan dari para penjahat ini bahwa file Anda masih aman. Sebagian ransomware merusak file tanpa bisa dikembalikan dengan cara apapun (membayar atau pun cara lain).

Jika Anda beruntung, kadang sebagian file bisa dikembalikan dengan program untuk melakukan undelete/data recovery. Sebagian malware membuat file baru hasil enkripsi dari file lama, lalu kemudian menghapus file lama. Kadang kala file lama (yang belum dienkrip ini) bisa dikembalikan.

Tips paling utama adalah: backuplah data Anda, sehingga jika ada ransomware maka Anda bisa memformat disk, menginstall ulang OS dan merestore backup.

Reverse Engineering

Saat ini ada ribuan varian ransomware yang mengenkripsi file Anda. Sebagian ini ada yang menginfeksi jutaan komputer, sebagian lagi menginfeksi puluhan atau ratusan komputer saja. Sebagian dari ribuan varian malware ini ada yang berhasil ditemukan kelemahannya dan berhasil dibuat program untuk mengembalikan file tanpa harus membayar ke pembuat malwarenya. 

Bagaimana kelemahan berbagai metode enkripsi di ransomware bisa ditemukan? dengan melakukan Reverse Engineering (bisa dibaca apa itu Reverse Engineering dari tanya jawab di situs ini). Tapi tidak semua enkripsi bisa dibongkar, kadang harus brute force. Dalam kasus tertentu, terkadang key masih ada di memori jika komputer belum dimatikan dan mungkin bisa diekstrak.

Reverse engineering sebuah malware (atau ransomware pada khususnya) butuh waktu lama. Setelah berhasil dibongkar pun, kelemahannya belum tentu ada.  Meminta seseorang melakukan reverse engineering ransomware secara gratis, sama seperti minta tolong ke penyelam untuk secara gratis mengambilkan makanan Anda yang terjatuh ke laut: menyelam itu butuh tenaga, waktu, oksigen, dan kemungkinan makanan Anda sudah dimakan ikan.

Jika Anda ingin belajar membongkar ransomware, maka datang ke group reverse engineering adalah langkah yang tepat. Dari mulai meminta contoh malware, belajar teknik reverse engineering dsb. Tapi jika Anda terkena malware, maka yang harus dilakukan adalah langkah yang sudah saya sebutkan di atas: mencari informasi apakah malwarenya sudah ada yang membongkar dan membuat tool dekripsinya.

Ilmu reverse engineering itu seperti ilmu researcher yang sedang meneliti penyakit tertentu, bukan berfokus pada orang yang kena penyakit tertentu. Dalam kasus orang terkena penyakit (ransomware) maka dia akan pergi ke dokter (Google, administrator sistem, teknisi), yang akan memberi obat hasil penelitian researcher. Jika ternyata penyakitnya baru (ransomware baru) maka diperlukan riset yang tidak sebentar.

Berhati-hatilah ketika Online

Ransomware bisa berjalan di komputer Anda karena beberapa hal:

  • Ada bug di sistem operasi/browser/aplikasi sehingga ketika Anda mengunjungi situs tertentu atau membuka dokumen tertentu, otomatis ransomwarenya berjalan di komputer Anda
  • Ada malware menyebar dari komputer lain di jaringan (contoh kasus Wannacry). 
  • Anda tertipu sehingga menjalankan program ransomware. Tipuan ini biasanya berupa attachment yang tampak seperti dokumen.

Beberapa hal penting yang perlu diperhatikan adalah:

  • Backup data Anda
  • Updatelah sistem operasi dan software yang Anda pakai
  • Aktifkan antivirus (sekarang sudah built in di Windows)
  • Jangan mengunjungi situs-situs yang mencurigakan
  • Jangan tergiur berbagai macam hadiah yang tidak jelas
  • Jangan menginstall software yang tidak jelas
  • Hati-hati membuka file yang diterima dari siapapun

Backup

Selain masalah ransomware, kadang saya masih menemukan post di Facebook mengenai orang yang kehilangan laptop beserta semua datanya padahal semuanya sangat penting. Misalnya ada yang kerjaan kantor dan ada juga yang berisi data skripsi bertahun-tahun. Ini sangat menggemaskan karena sekarang membackup data sudah mudah sekali dilakukan dengan berbagai layanan online seperti DropBox, Google Drive, OneDrive, dsb. Di sini saya tidak akan membicarakan backup untuk kantor/enterprise, hanya sekedar backup data pribadi.

Semua layanan drive online punya aplikasi desktop dan mobile yang bisa mengotomasi upload file hanya ketika file tersebut berubah. Jika takut dengan masalah privasi (atau takut misalnya password layanan tersebut suatu hari jebol), kita bisa mengenkripsi file itu sebelum disimpan ke direktori yang di sinkronisasi ke cloud. Aplikasi seperti Word dan Excel juga punya fitur password, jadi file bisa diproteksi ekstra sebelum diupload ke cloud.

Meski menyimpan ke cloud sangat nyaman dan mudah, saya perlu memperingatkan bahwa penyedia jasa cloud bisa menghentikan layanannya kapan saja. Saya menuliskan ini setelah membaca kasus di mana seseorang kehilangan semua datanya di blogger. Ini terjadi terutama jika Anda bandel, misalnya sharing file yang dilindungi undang-undang HAKI (buku, film, app bajakan, dsb).

Hati-hati juga jika Anda suka sharing sesuatu yang bisa dianggap hate speech. Jangan sampai karena ingin menghina pemimpin atau tokoh tertentu, membuat account Anda jadi diblokir. Setidaknya jika memang ingin melakukan itu, pisahkan dari account utama Anda.

Dropbox

We also reserve the right to suspend or end the Services at any time at our discretion and without notice.

Google Drive

Google may also stop providing Services to you, or add or create new limits to our Services at any time.

OneDrive

You or Microsoft may terminate this Agreement immediately for any reason or no reason without notice

Meskipun kasus penutupan tiba-tiba ini relatif jarang, tapi ada banyak contoh yang bisa ditemukan di Internet. Bisa saja seseorang tidak suka pada Anda lalu melaporkan account Anda, dan tergantung orang yang menerima laporan tersebut, mungkin account Anda bisa diblok atau ditutup.

Jika mungkin, backuplah di berbagai layanan sekaligus, jadi jika ada masalah di satu layanan kita bisa memakai layanan yang lain. Saya tahu ini kadang ini tidak bisa karena kendala kuota internet, tapi lakukanlah untuk file-file super penting.

Saya sendiri memakai berbagai kombinasi backup offline dan online. Untuk file-file yang ada di desktop saya memakai layanan yang sudah umum (Google Drive, OneDrive dan Dropbox) serta memakai Backblaze. Bedanya dengan yang lain: Backblaze ini unlimited dan bisa membackup semua harddisk yang ada di komputer, tidak hanya folder tertentu. Untuk hal-hal yang berhubungan dengan development, saya punya server git personal dengan backup ke Amazon S3.

Backup online juga bisa menjadi target hacker. Sudah ada kejadian username/password Dropbox yang pernah bocor. Perlu diperhatikan juga bahwa fitur cloud kadang berbahaya di tangan peretas. Contohnya adalah kisah beberapa tahun lalu ketika seorang wartawan Wired diretas dan datanya dihapus secara remote dengan fitur security Apple.

Ini membawa saya ke topik berikutnya: buatlah backup offline untuk data super penting Anda. Backup offline ini maksud saya adalah yang non-cloud jadi bisa berupa NAS di rumah, atau bahkan sekedar USB disk.

20160221_145813

Harga USB disk 8 GB (sepertinya ini paling kecil saat ini) sudah sangat murah, di sini sekitar 100 baht (40 ribu rupiah). Jika Anda tidak menyimpan file super besar (seperti film), dan sekedar menyimpan dokumen skripsi/thesis, 8 gb sudah cukup. Kalau menurut Microsoft 5 GB saja sudah banyak:

OneDrive free with 5 GB: enough space for approximately 6,600 Office documents or 1,600 photos

Bahkan handphone yang Anda pegang juga bisa menjadi sarana backup. Jika tidak punya media backup lain, setidaknya copy lah file terpenting ke handphone. Jika filenya sangat penting (misalnya berisi password) maka file itu sebaiknya dienkrip (bahkan ponsel Android dan iOS sekarang sudah memiliki fitur enkripsi built in, jadi datanya cukup aman).

Tentunya jangan tempelkan terus USB-nya ke laptop Anda. Bagaimana jika laptopnya dicuri? hilang juga data backupnya. Backup sebaiknya berada di tempat terpisah (off site). Contoh kejadian yang mungkin terjadi adalah: kebakaran atau bencana lain. Seperti pernah diberitakan: seorang penulis nekat menerjang api untuk menyelamatkan laptopnya yang berisi novel yang ditulisnya.

Jangan lupa sesekali mengetes backup Anda, periksalah bahwa filenya bisa dibuka dan isinya benar, lengkap dan merupakan yang terbaru. Kalau tidak ingat untuk membackup setiap hari, dan bingung menggunakan software backup otomatis, minimal buatlah reminder di kalendar Anda tiap bulan. Andaikan ada masalah, setidaknya Anda nggak perlu mengulangi kerjaan skripsi dua tahun, tapi maksimum hanya sebulan terakhir.

Sebagai pembanding: jaman dulu backup data tidak mudah. Backup bisa dilakukan dengan floppy disk, tapi reliabilitasnya cukup rendah (atau yang cukup punya uang bisa memakai ZIP Drive). Layanan backup online juga belum seperti sekarang ini (teringat kisah pernah ada yang nekat nitip data di FTP kampus, tapi kemudian servernya diformat ulang jadi datanya hilang).

IMG_1190_d57bcd54aaab4b36e7fc2d722996a24a

Jika semua kemudahan sudah ada, tapi Anda tidak menggunakannya karena malas, maka jangan salahkan siapa-siapa selain Anda sendiri.

Flare-On 5 (2018)

Ini sudah keempat kalinya saya mengikuti challenge tahunan Flare-On dari FireEye. Saya sudah pernah menuliskan tentang Flare-On ini di posting saya yang lain, tapi akan saya ulangi sedikit.

Flare-On adalah challenge reverse engineering, alias tantangan membongkar program. Bentuk Flare-On adalah challenge, semua yang selesai adalah pemenang. Ini ibaratnya seperti marathon, semua yang berhasil menyelesaikan disebut sebagai finisher. Ini berbeda dari CTF lain yang biasanya sifatnya adalah lomba (seperti lari Sprint) di mana yang duluan memecahkan adalah pemenangnya (contoh seperti ini adalah ketika saya menang hadiah ke Hong Kong dari reverse engineering). 

Hadiah Flare-On Tahun ini

Panitia sudah memberikan write-up tentang bagaimana caranya menyelesaikan berbagai soal yang ada, jadi saya tidak akan membuat write-up.  Tapi ada permintaan supaya saya menuliskan: ilmu apa sih yang dibutuhkan buat menyelesaikan masing-masing level? memang kadang membaca sebuah write-up itu terasa membingungkan kalau belum tahu dasar ilmunya. Jadi di posting ini akan saya tuliskan deskripsi challengenya, dan ilmu apa yang perlu diketahui untuk menyelesaikan tiap challengenya. Tahun ini dari Indonesia hanya Faco lagi yang solve, dan dari Thailand ada 2 orang lain selain saya.

Chal 1: Minesweeper Championship Registration

Ini adalah bentuk challenge reverse engineering paling sederhana. Ini sekedar memfilter orang-orang yang blank sama sekali soal reverse engineering. Misalnya ada yang bertanya di Twitter apa invitation codenya, padahal itulah soalnya (mencari invitation code).

Solusi untuk soal ini sangat sederhana, dengan decompiler Java didapatkan jawabannya, hanya sebuah if saja yang perlu dibaca. Hal yang perlu diketahui hanya ini: sebuah program bisa ditulis dalam berbagai bahasa, setelah mengetahui bahasanya, kadang kita bisa mendapatkan decompilernya dan bisa membaca kodenya.

Meskipun soal ini terlihat amat sangat sederhana, bukan berarti tidak terpakai. Sekitar 20 tahun yang lalu ada banyak aplikasi shareware yang proteksinya segampang ini, hanya ada satu password statik saja. Bahkan beberapa tahun terakhir ini  ketika para ahli security membongkar firmware router, ditemukan juga perbandingan statik seperti ini (account  backdoor dengan password statik).

Chal 2: Ultimate minesweeper

Tantangan ini mulai agak serius: hacking game. Gamenya sangat sederhana, hanya minesweeper. Tugas kita hanya satu: mencari tahu di mana yang bukan bom, tapi kebanyakan isinya adalah bom (900 sel dan hanya 3 yang bukan bom).

Cara yang manual adalah dengan mengklik satu per satu 900 kali untuk mencari tahu lokasi yang bukan bomb karena posisinya tidak akan berubah. Cara yang lebih cerdas adalah dengan membaca kode atau melakukan debugging untuk melihat isi memori, supaya tahu mana yang ada bombnya.

Ini adalah contoh di mana pengetahuan programming diperlukan. Jika Anda adalah programmer, maka akan terbayang bahwa perlu ada struktur data board (biasanya dalam bentuk array 2 dimensi) yang isinya apakah di suatu posisi ada bomb atau tidak. Jika Anda programmer yang membuat program semacam ini tentunya akan bisa mendebug program sendiri dan bisa menentukan di mana bom dan bukan bom.

Challenge ini sederhana karena 90% nama bisa dibaca dan tidak menyesatkan. Hanya ada satu bagian kecil saja yang dibuat agak membingungkan (bagian mengisi lokasi yang bukan bom).

Ini masih game yang super sederhana dan banyak yang menyerah tapi orang-orang ini sebagian ingin bisa membongkar dan mengakali game di App Store/Play Store. Untuk game yang serius, ada lebih banyak lagi hal-hal yang perlu dicatat oleh game, lokasi pemain, jumlah koin, kondisi musuh dsb. Jika Anda tahu cara kerja game (meskipun tidak pernah memprogram langsung), Anda akan terbayang data apa saja yang disimpan.

Secara teknis, program ini dibuat dengan .NET, diperlukan pengetahuan bahwa ada banyak debugger sekaligus decompiler .NET. Cara termudah adalah dengan dnspy yang bisa mendecompile dan mendebug. Menelusuri program bisa dilakukan cukup jelas, mulai dari klik sampai dia membaca memori yang berisi struktur data board.

Chal 3: FLEGGO

Di sini tantangan sudah masuk lebih serius: membongkar native code alias kode assembly. Ini hanya sedikit lebih sulit dari challenge pertama, karena di challenge pertama kita bisa mendapatkan kodenya dengan membaca source code Java. Kali ini yang dibaca adalah assembly, tapi string passwordnya masih jelas di file.  

Masalah utamanya adalah: ada 48 file. Ini masih bisa dilakukan satu per satu, tapi butuh waktu lama. Di sini diperlukan otomasi, bagaimana mengulangi proses yang sama 48 kali.  Proses otomasi ini juga penting dalam dunia nyata, contohnya FireEye pernah harus mengecek 10 ribu komputer untuk mengetahui apakah BIOS-nya diinfeksi malware atau tidak.

Orang yang tidak bisa mengotomasi ini sering saya temui dalam hidup, dulu saya pernah menuliskan tentang admin yang membuat secara manual 100 account dan menginstall satu per satu semua software. Inti dari otomasi adalah membuat program atau skrip untuk mengulangi berbagai pekerjaan manual.

Jadi ilmu dasar untuk menyelesaikan soal ini adalah: keahlian membaca assembly dasar dan memprogram untuk mengotomasi pembuatan solusi.

Chal 4: binstall

Ini contoh serius dari sebuah malware yang disederhanakan dan dijinakkan. Ini merupakan versi sederhana dari trojan banking sejenis Zeus dan sejenis berbagai malware lain yang membajak browser. Di sini sudah banyak dipakai berbagai teknik yang mulai rumit, seperti obfuscation dan dll injection. Karena malware ini sudah disederhanakan, ilmu dari berbagai buku dan tutorial website masih bisa digunakan.

Challenge ini mengkombinasikan .NET (installer), .dll (native code) dan .js (javascript).  “Malware” ini  akan menginjeksikan skrip pada website flare on dan menambahkan command baru. Malware yang sesungguhnya akan aktif di sebuah situs banking dan mencuri password kita, atau mengubah tujuan transfer ke nomor lain.

Ada banyak sekali ilmu dasar analisis malware yang perlu dimengerti untuk menyelesaikan soal ini. Saran saya adalah: bacalah salah satu buku analisis malware, dan coba praktikkan ilmunya pada soal ini.

Chal 5: Web 2.0

Beberapa tahun lagi WebAssembly akan populer. Saat ini WebAssembly sudah disupport semua browser, tapi masih belum banyak dipakai oleh berbagai website. Sebagai reverse engineer, kita harus berpikir maju dan mulai belajar membaca kode yang akan populer, bukan yang sudah populer.

Challenge di bab ini adalah untuk memahami kode WASM, dan sebenarnya setelah dipelajari bisa diselesaikan dengan sangat mudah menggunakan debugger yang ada di browser. Saat ini belum banyak resource reverse engineering web assembly, jadi kita perlu membaca banyak dasar teori untuk menyelesaikan soal ini.

Chal 6: Magic

Soal ini adalah mengenai binary Linux. Soalnya rada mengada-ada, kita diminta mengisi 666 password yang dihasilkan dari algoritma tertentu. Ada banyak cara menyelesaikan ini, baik dengan otomasi, ataupun memahami algoritma supaya tidak perlu menjawab sama sekali.

Dalam mencari bug di dunia nyata, kita tidak akan diberi program sederhana yang mudah dibongkar. Berbagai program di Linux ukurannya besar dan hasil compile  dari ratusan ribu atau jutaan baris kode. Soal ini sekedar mensimulasikan bahwa kadang kita harus memahami beberapa algoritma yang ada di sebuah file biner dan memahaminya dengan benar.

Dasar ilmu untuk menyelesaikan soal ini adalah: kriptografi (dasar) dan pengetahuan debugging binary Linux. Beberapa tool juga bisa dipelajari (misalnya pexpect, frida, gdb) untuk mengotomasi solusinya.

Chal 7: WOW

Soal ini hanya bisa dijalankan di Windows 7 64 bit karena memakai teknik Heaven’s Gate. Ini hanyalah salah satu contoh teknik aneh yang dipakai oleh malware. Ada banyak sekali teknik-teknik lain yang dipakai oleh malware untuk mempersulit debugging.

Secara umum untuk menyelesaikan soal semacam ini kita perlu banyak mengikuti perkembangan malware dan teknik-teknik terbaru yang dipakai oleh malware untuk menyulitkan debugging.

Chal 8: Doogie Hacker

Challenge ini sebenarnya bisa dianggap sebagai selingan saja. Pengetahuan yang perlu dimiliki adalah melakukan reverse engineering boot sector. Jaman dulu banyak virus boot sector sederhana, dan sekarang ini ada yang namanya “bootkits” yang kompleks (rootkit yang bisa menginfeksi boot sector/MBR).

Hanya diperlukan keahlian dasar membaca kode 16 bit plus sedikit ilmu kriptografi untuk menyelesaikan ini. Soal ini juga merupakan pengantar untuk soal terakhir yang lebih kompleks. Soal sederhana seperti ini diberikan supaya pemain merasa sedikit tenang.

Chal 9: leet editr

Ini contoh lain penggunakan teknik yang digunakan oleh malware. Kali ini yang dipakai adalah VirtualAlloc dan VirtualProtect yang mempersulit debugging. Tapi sayangnya soal ini masih kurang kompleks sehingga ada beberapa shortcut untuk menyelesaikannya. Seperti challenge no 7, diperlukan pemahaman cukup dalam mengenai trik malware dan internal Windows untuk menyelesaikan soal ini.

Chal 10: golf

Ini soal yang luar biasa,  berupa penggunaan hypervisor dengan menggunakan VT-X Extension dari Intel. Diperlukan pemahaman yang cukup dalam mengenai prosessor dan hypervisor untuk bisa menyelesaikan soal ini. Pembuat CTF tidak main-main dalam mengimplementasikan soal ini. Teknik semacam ini hanya dipakai oleh malware tingkat lanjut.

Di sini fitur Intel VT-X digunakan untuk mengimplementasikan sebuah instruction set khusus tapi tetap memakai register prosessor itu sendiri. Untuk menyelesaikan soal ini diperlukan banyak membaca mengenai hardware virtualization.

Chal 11: malware skillz

Ini soal tahun lalu yang disederhanakan. Jika sudah membaca soal dan solusi tahun lalu, tentunya akan tahu betapa panjangnya proses memahami soal ini. Bagi yang sudah menyelesaikan soal tahun lalu, menyelesaikan ini sangat gampang, segala macam tipuannya sudah terbaca dari awal dan soalnya sudah disederhanakan dari tahun sebelumnya.

Ini adalah soal yang paling dekat dengan malware yang sesungguhnya. Di soal ini juga diberikan file pcap yang merupakan hasil sniffing jaringan yang perlu kita analisa.

Untuk menyelesaikan soal ini diperlukan kombinasi dari berbagai hal:

  • Pengetahuan jaringan (Wireshark, protokol DNS dan SMB)
  • Reverse engineering native code
  • Enkripsi, hashing, dan berbagai algoritma lainnya
  • Reverse engineering .NET
  • Pengetahuan mengenai git

Chal 12: Suspicious Floppy Disk

Soal ini awalnya seperti soal no 8, kita perlu melakukan reverse engineering kode 16 bit pada sebuah floppy disk. Di sini berbagai teknik DOS yang lama seperti intercepting interrupt digunakan. Saya menyangka tantangan kali ini akan memanfaatkan berbagai trik DOS yang kompleks (misalnya kode polymorphic) sehingga saya mempersiapkan diri membuat custom instrumentation untuk Bochs.

Dengan menuliskan kode instrumentasi saya bisa mencatat berbagai perintah yang dieksekusi sejak titik tertentu (minta password) sampai ada hasilnya. Ternyata jumlah instruksi yang dieksekusi banyak sekali. Setelah dipelajari lebih dalam lagi, ternyata isinya adalah sebuah virtual machine untuk arsitektur one instruction set computer (OISC) subleq.

Untuk yang menyelesaikan soal tahun lalu, tentunya akan ingat bahwa ini adalah soal no 11 tahun lalu. Ada pembahasan yang cukup dalam mengenai soal ini (jumlah halaman solusinya: 81 halaman). Saya juga membaca berbagai pendekatan lain untuk memahami yang dilakukan kode ini, termasuk juga membuat plot instruction pointer terhadap waktu. 

Di sini diperlukan pengetahuan bagaimana sebuah interpreter bekerja. Saya mengimplementasikan ulang virtual machine subleq dalam C, lalu menjalannya. Bedanya dengan tahun lalu: kode subleq ini sangat panjang.  Ada sekitar 500 ribu instruksi dieksekusi untuk menampilkan pesan dan mengecek password. Tahun lalu ini relatif pendek dan bisa dianalisis cukup cepat.

Akhirnya mau tidak mau saya harus membaca kode subleqnya, ternyata kodenya dipenuhi dengan sampah untuk mempersulit pembacaan. Contoh sampah adalah operasi aritmatika yang hasilnya dibuang. Ternyata kode subleq ini merupakan virtual machine juga. Jadi ini adalah virtual machine di dalam virtual machine. Virtual machine yang diimplementasikan oleh kode subleq adalah RSSB (Reverse subtract and skip if borrow), salah satu jenis one instruction set computer selain subleq.

Kode RSSB jauh lebih sulit dibaca dari subleq, dan saya perlu membuat kode python custom untuk menyederhanakan kode RSSB-nya. Ternyata kode inipun dipenuhi dengan sampah sehingga sulit dibaca.  Di sini menurut saya yang dibutuhkan adalah ketekunan. Ini seperti kembali ke awal belajar membaca kode assembly (tanpa decompiler).

Jadi intinya untuk menyelesaikan soal ini butuh sedikit membaca teori dan banyak kesabaran.

BEVX Conference

Tanggal 20-21 September saya mengikuti BEVX Conference di Hong Kong. Hari pertama adalah training dan saya mengambil  iOS Sandbox Escape Vulnerability and Exploitation oleh Hao Xu/Pangu.  Team Pangu ini sempat terkenal karena Jailbreaknya yang dirilis umum untuk iOS 7/8/9. Team ini masih aktif, tapi tidak lagi merilis jailbreak umum, di pelatihan yang dibahas adalah exploit iOS 11 dan mereka sudah punya jailbreak untuk iOS 12.

Biaya training plus conferencenya cukup mahal (1000 USD), tapi saya mendapatkannya gratis, plus tiket pesawat dan hotel juga. Ini saya dapatkan dari challenge Reverse Engineering yang saya kerjakan bulan April lalu. Writeup untuk challengenya saya tulis di blog saya yang berbahasa Inggris.

Sebagai informasi, saya ini bukan profesional di bidang Security, hanya part time saja melakukan pentesting secara remote. Saya juga tidak rajin mencari bug di berbagai website atau app, kadang-kadang saja saya menemukan bug ketika sedang iseng. Bidang security dan reverse engineering ini sekedar hobi bagi saya. Saya belum pernah menghadiri conference security (pernah ke HITB sekedar CTF saja). Saya cukup senang hobi ini tahun lalu mengantar saya ke Belanda dan tahun ini sekeluarga ke Hong Kong.

Training

Sekarang ke cerita trainingnya. Biasanya materi training iOS ini diberikan dalam 2 hari, dan baru kali ini pengajarnya berusaha mengkompres materinya menjadi 1 hari. Bagi yang tidak punya background development di macOS dan iOS akan sangat sulit mengikuti semuanya, untungnya walau sudah lama tidak develop macOS dan iOS saya masih mengikuti perkembangannya. Sayangnya di akhir kurang bisa cukup praktiknya, hanya sempat sampai membuat device crash.

Saya menyarankan bagi yang ingin mengikuti training sejenis ini agar mempersiapkan diri dulu dengan berbagai ilmu development iOS dan macOS (Objective C dan berbagai konsepnya). Seluruh dasar teori selama sehari penuh diperlukan untuk menjelaskan satu eksploit saja.

Materi training yang diberikan meskipun sangat banyak, tapi hanya menyentuh hal-hal dasar saja. Untuk menjadi ahli dalam mencari bug iOS, sampai membuat jailbreak masih perlu banyak membaca dan praktik. Sifat iOS yang sourcenya hanya terbuka parsial juga mempersulit eksplorasi. Setiap jailbreak baru dirilis, Apple juga segera membuat perubahan supaya segala bug sejenis tidak muncul lagi, jadi tingkat kesulitan eksploitasi iOS ini memang cukup tinggi.

Penyelenggara conference menyediakan beberapa tiket training dan conference gratis untuk student (dengan slot terbatas tentunya) tapi tidak membayari pesawat/hotel. Saya pikir dengan adanya tawaran ini maka akan ada  banyak mahasiswa lokal, tapi ternyata kebanyakan mahasiswa justru dari jauh (Eropa dan  Amerika) dan mereka ini rajin juga ikutan CTF.

Keynote

Bagian keynote BEVX ini cukup menarik, jadi akan saya tuliskan di sini sedikit, plus komentar dari saya.  Keynote BEVX ini membahas tentang tiga jenis “kompetisi security”, yang meliputi CTF, Bug Bounty, dan Pwn2Own, dan bagaimana membuat CTF yang lebih baik berdasarkan jenis lomba yang lain. Semua jenis “lomba” ini memiliki tempatnya masing-masing. CTF bertujuan untuk menghibur diri, untuk belajar, dan merupakan suatu bentuk dari deliberate practice. Tujuan CTF bukan untuk ketenaran dan uang. Karena waktunya terbatas, biasanya soal CTF harus disederhanakan supaya selesai dalam 1-2 hari.

Program bug bounty ditawarkan oleh berbagai perusahaan, intinya: siapa yang menemukan bug di  website atau produk akan dibayar. Tujuan program semacam ini adalah mengamankan produk/website tertentu. Bug bounty bisa disebut kompetisi karena ada juga “ranking” dari para pencari bug ini (contohnya di bugcrowd ada sistem point). Kalau dilihat, sebagian besar bug yang ditemukan hanya yang itu-itu saja (masih lebih banyak variasi soal CTF).

Kompetisi pwn2own dan sejenisnya mencari bug 0day di sebuah software, artinya bug yang belum pernah ditemukan siapapun sebelumnya. Bug ini biasanya dihargai sangat mahal (puluhan hingga ratusan ribu USD), dan level kesulitan menemukan bug jenis ini sangat tinggi. Targetnya adalah software yang dipakai banyak orang (browser, sistem operasi, office, dsb).

Jadi tiap lomba ini memiliki tujuan masing-masing, dan bisa saling melengkapi. Hampir mustahil seorang pemula tiba-tiba bisa mencari bug dan mendapatkan hadiah dari pwn2own, tapi CTF merupakan titik awal yang baik untuk belajar. Dari berbagai soal CTF kadang kita juga bisa belajar tentang bug tertentu yang bisa dicoba cari di program bug bounty.

Pembicara keynote menemui bahwa saat ini beberapa CTF sudah mulai memakai bug dunia nyata, dan menyarankan agar lebih banyak CTF mulai memakai banyak software di dunia nyata (dengan bug 0day).  Software yang dipilih bisa yang kurang populer. Tujuannya adalah: membantu menambah keamanan pada proyek yang kurang populer, dan peserta CTF bisa benar-benar memakai software di dunia nyata.

Ada satu bagian menarik di keynote mengenai CTF. Di CTF kita memiliki mindset “ini pasti ada bugnya”, karena jika tidak maka soalnya tidak bisa diselesaikan. Mindset itu harus dibawa ke dunia di luar CTF: setiap software pasti ada bugnya. Jika dipikir, ini memang fakta, tiap software ada bugnya, dan mungkin tidak ketahuan sekarang. Lihat saja berapa banyak bug Windows, Linux, dsb yang baru ditemukan bertahun-tahun (kadang sampai belasan tahun) kemudian.

CTF

Acara BEVX ini tidak disertai dengan acara CTF (saat ini banyak conference yang memiliki acara CTF juga). Dari ngobrol-ngobrol dengan beberapa orang di conference tersebut, hal yang menarik bagi saya adalah: masih banyak ahli security level dunia yang masih rajin ikutan CTF (walaupun tidak semua, karena sebagian katanya sudah tidak punya waktu lagi). Saya jarang bertemu security expert Indonesia yang masih ikutan CTF. Saya sendiri masih ikut CTF tapi biasanya yang waktunya lama (seperti Flare-On) dan sesekali yang waktunya sebentar.

Saat ini banyak sekali CTF yang mudah, dan juga CTF yang sangat sulit (misalnya DEFCON), tapi sayangnya masih kurang CTF yang level menengah. Untuk pemula yang sudah berhasil ikutan CTF mudah biasanya akan kesulitan untuk melompat ke level berikutnya karena tiba-tiba menjadi terlalu sulit. Kalau dilihat dari berbagai writeup CTF Indonesia, saat ini kebanyakan soal levelnya masih sederhana dan mulai mendekati menengah.

Jadi saran saya: untuk yang belum ikutan CTF, cobalah ikutan CTF. Kalau merasa suatu CTF terlalu mudah, cobalah ke CTF lain yang lebih sulit, jadi jangan sombong menganggap semua CTF itu mudah. Saya pengen banget melihat team Indonesia di CTF tingkat dunia seperti DEFCON.

Bagi yang sudah ikutan CTF tapi merasa masih mentok, cobalah pelajari topik yang masih belum dikuasai. Kalau masih belum bisa exploitation ya pelajarilah itu dimulai dari yang paling sederhana. Luangkan waktu untuk berlatih.

Conference

Conference BEVX berfokus pada offensive security, tentang bagaimana mengeksploitasi sesuatu. Ini bukan jenis conference yang berisi konsep, tapi berisi kode program dan cara eksploitasinya. Tidak ada presentasi BEVX yang tidak menyertakan kode program, jadi ini bukan sesuatu yang mengawang-awang.

 Badge yang bisa jadi captive portal

Jadwal lengkap bisa dilihat di sini. Meskipun ada 2 track, saya hanya mengikuti Track 1 karena menurut saya lebih menarik. Talk pertama tentang bug yang ada di kernel Linux selama 17 tahun. Ini menarik karena selama 17 tahun tidak ada yang memperhatikan kode itu ternyata memiliki bug, dan cara eksploitasinya merupakan cara baru (heap spray dengan userfaultd).

Talk kedua mengenai smart card juga cukup menarik, tapi tidak terlalu advanced. Tapi ini mengingatkan saya bahwa smart card yang ditamper bisa jadi vektor masuk untuk software atau sistem tertentu.

Talk sebelum makan siang: (De)coding an iOS vulnerability membahas bug iOS. Ini menarik, tapi presentasinya terlalu detail dan panjang sehingga lebih dari waktu yang ditentukan.

Setelah makan siang di hotel (bagian dari harga tiket), diteruskan dengan “Dual booting modern iOS devices” yang memakai bug iOS untuk dual boot 2 versi iOS.  Masalah dengan eksplorasi iOS adalah: jika kita sudah maju ke versi yang tidak ada bugnya, maka kita tidak bisa mundur lagi ke versi sebelumnya dengan mudah. Ini sebenarnya akan sangat menarik jika kodenya dirilis, tapi sayangnya karena masih development maka ini terbatas untuk keperluan riset saja.

Thinking Outside the Virtual Box yang menjelaskan eksploitasi bug Virtual Box untuk “escape to host”. Artinya di Virtual Box yang memiliki bug ini, virtual machine yang berjalan bisa mengakses komputer host. Bug yang ditemukan sangat menarik dan eksploitasinya juga sangat keren.

Topik “Bypass Android Security Mechanisms using Custom Android” sebenarnya tidak terlalu advanced, tapi sangat praktis untuk pentesting aplikasi Android. Intinya adalah: dengan custom kernel kita bisa membuka semua proteksi berbagai aplikasi Android.

Semua presentasi sangat low level

Crashing to root: How to escape the iOS sandbox using abort() menurut saya adalah yang paling menarik. Idenya sangat menarik, implementasinya menakjubkan, dan pembicaranya menyampaikan topiknya dengan sangat terstruktur dan dengan suara yang sangat jelas. Silakan dibaca file presentasinya dan deskripsi di githubnya.

Pembicara terakhir adalah Halvar Flake (Thomas Dullien) dari Google. Topiknya agak teoretis tapi bagi saya sangat menarik. Dia ingin membuat tool untuk bisa mengidentifikasi berbagai library yang direuse oleh banyak pihak. Singkatnya semacam FLIRT dari IDA tapi lebih advanced.

Penutup

Berbagai eksploitasi yang ditayangkan di conference ini sangat menarik dan dalam banyak kasus saya berkata dalam hati: wow kok mereka kepikiran ya memakai cara ini . Untuk mengeksploitasi sebuah sistem kadang diperlukan banyak bug yang sepertinya tidak terlalu penting dan bisa digabung jadi satu.

Dari situ yang terpikirkan oleh saya adalah: dengan bug-bug kecil yang “tidak sengaja”, mereka bisa merangkainya untuk mengambil alih sebuah sistem. Andaikan para penemu bug di conference BEVX diminta membuat backdoor yang tidak terdeteksi, kemungkinan besar mereka akan bisa melakukannya. 

Mereka bisa  sengaja membuat berbagai bug kecil yang tampaknya tidak penting. Jadi backdoornya bukan sejenis hardcoded password atau sekedar kondisi dengan sebuah if saja, tapi memakai sifat dari berbagai library dan syscall yang tidak mudah dimengerti kaitannya.

Ini menunjukkan betapa mengerikannya memakai berbagai produk yang tidak kita ketahui. Bahkan dengan code review sekalipun, bug-bug yang mereka temukan ini akan bisa lolos. Sepertinya langkah terbaik untuk sebuah negara adalah mengembangkan sendiri berbagai software penting untuk keperluan critical.

Saya cukup menikmati keseluruhan acara ini. Semoga lain kali saya juga tidak hanya jadi pendengar saja, tapi jadi pembicara juga di acara sejenis ini.

Trik Reverse Engineering Kode Python

Entah kenapa akhir-akhir ini saya banyak melihat pertanyaan mengenai reverse engineering kode Python yang sudah di-obfuscate, baik di Facebook maupun Telegram. Sudah ada beberapa artikel dalam Bahasa Indonesia yang membahas ini misalnya Bermain dengan Python Bytecode dan  Reverse Engineering Python Bytecode. Kedua artikel itu sudah bagus, jadi saya sarankan untuk membaca kedua artikel itu untuk dasar reversing bytecode Python.

Artikel ini hanya ingin membahas trik untuk mempermudah revers engineering proteksi tertentu yang memakai marshal dan gagal didekompilasi. Lanjutkan membaca “Trik Reverse Engineering Kode Python”