Cheat dan Anti-Cheat pada Video Game

Salah satu tujuan banyak orang melakukan Reverse Engineering adalah mencurangi (cheating) game. Sudah banyak orang menanyakan ini ke saya, jadi akan saya bahas sekarang ini.

Cheat by Nick Youngson CC BY-SA 3.0 Alpha Stock Images
Cheat by Nick Youngson CC BY-SA 3.0 Alpha Stock Images

Tapi supaya tidak kecewa, saya tekankan dulu: cheating game modern dan populer saat ini (misalnya pubg) sangat sulit. Teknologi anti cheat selalu diupdate, dan tidak ada satu artikel di internet yang bisa membuat Anda bisa mencurangi game terbaru.

Sebagai catatan: banyak video sampah di Youtube yang mengajari cara cheat game padahal yang dijelaskan di situ tidak masuk akal sama sekali.

Cheating Game Jaman Dulu vs Sekarang

Mungkin Anda membaca beberapa artikel lama tentang cheating game dan berpikir cheating itu mudah. Sebelum membahas berbagai teknik cheat dan anti-cheat, saya tuliskan dulu tentang cheating jaman dulu dan sekarang.

Jaman dulu, terutama masa sebelum internet, cheating game relatif mudah. Berbagai perkembangan teknologi (termasuk juga kecepatan CPU, ketersediaan multi core) membuat cheating game makin sulit dilakukan.

Versi Game

Pertama adalah masalah update. Dulu Versi game tidak berubah sejak dirilis karena distribusinya sulit menggunakan CD-ROM/DVD, jadi jika ada game versi 1.0, kemungkinan tidak akan berubah sampe bertahun-tahun kemudian. Di masa awal internet, game juga masih didistribusikan via CD/DVD walau sudah bisa dimainkan online.

Dulu jika ada yang menemukan atau membuat cheat tertentu, maka pembuat game tidak bisa mengupdate kodenya. Sekarang: dalam hitungan hari sudah ada update di play store/app store/steam/dsb. Tentunya masih banyak game sederhana/tidak populer yang dibiarkan saja oleh pembuatnya..

Tulisan/Artikel tentang cheating

Dulu banyak orang dengan sukarela menuliskan ilmu tentang cheat yang dikembangkan, ini tidak apa-apa karena meskipun pembuat game membaca artikelnya, tidak ada yang bisa dilakukan sampai versi berikutnya beberapa tahun lagi atau beberapa bulan lagi.

Sekarang ini jika seseorang menemukan cheat game, mereka akan menyembunyikan atau tidak men-share tekniknya. Kalau dishare, maka pembuat game akan membaca artilel tersebut dan segera mengubah kodenya.

Resource Anti Cheat

Dulu teknik anti cheat dilakukan oleh pembuat game yang teamnya kecil. Mereka ini sering kali adalah programmer game yang bagus, tapi kurang mengerti teknologi cheating. Sekarang ini untuk game besar, sering ada team khusus yang melakukan development anti cheat.

Pekerjaan membuat anti cheat di berbagai perusahaan game yang besar gajinya mencapai puluhan/ratusan ribu USD/tahun (atau dalam rupiah 1-5 milyar/tahun). Game-game ini menghasilkan jutaan USD per bulan. Jadi mereka yang sudah dibayar mahal ini tidak tinggal diam melihat para cheater yang berpotensi mengurangi pendapatan mereka.

Sebagai pembanding: para pembuat cheat kebanyakan sukarela, karena ingin sekedar menang dalam game. Jika levelnya sudah terlalu sulit, mereka akan menyerah. Tapi ada juga group-group yang menjual cheat, motivasi mereka lebih besar dan tentunya mereka tidak mau sharing ilmu karena akan mengurangi pendapatan mereka.

Selain menyewa orang secara khusus, ada juga beberapa perusahaan yang mengembangkan teknologi anti cheat untuk dipakai oleh berbagai game lain. Contohnya adalah BattleEye. Mereka bahkan punya lowongan spesifik: membuat teknologi anti cheat.

Sebenarnya bukan cuma game yang butuh anti cheat. Contoh aplikasi non game yang sering dicurangi orang adalah Snapchat. Biasanya fitur yang diinginkan adalah bisa menyimpan/screencapture foto tanpa ketahuan. Snapchat bahkan sampai mengakuisisi sebuah perusahaan untuk meningkatkan keamanannya.

Kompleksitas Anti-Cheat

Ketika resource CPU masih sangat rendah, game harus sangat dioptimasi, jadi biasanya anti cheat hanya dijalankan sekali saja ketika game dimulai atau ketika pergantian level.

Sekarang ini dengan CPU multi core yang bahkan sudah ada di HP Android low end, bisa ada thread khusus yang melakukan pengecekan berkala. Jika satu pengecekan berhasil dibypass di awal, masih ada pengecekan lain yang dijalankan secara periodik.

Contoh aneka jenis teknik cheating

Jenis cheating untuk berbagai game beraneka ragam, tergantung jenis gamenya. Kadang-kadang cara cheating di satu game tidak berlaku sama sekali di game lain.

Untuk game jenis fighting, misalnya bisa dibuat aimbot yang otomatis mengarahkan (aim) senjata ke target, atau untuk melihat pemain lain meski terhalang dinding. Untuk game jenis puzzle bisa dibuat solver otomatis yang memberi tahu solusi gamenya.

Jadi tidak ada satu jenis cheat, dan teknik anti cheat untuk berbagai jenis cheat juga berbeda-beda. Di sini saya akan bahas contoh saja beberapa jenis cheating yang umum.

Memory/File Editing

Jaman dulu cheating game single player hanya sekedar mengubah jumlah koin di memori atau di file (untuk game yang ada savefile-nya), atau mengaktifkan sesuatu fitur yang seharusnya tidak aktif. Ini sangat mudah dilakukan dengan berbagai tool yang melakukan scanning memori, mencari value, lalu mengganti value tersebut.

Sekarang ini sebagian besar nilai sudah disimpan di server. Jadi meskipun kita mengganti nilai koin di game lokal, ketika gamenya dimulai (atau ketika akan membeli item) game akan meload lagi nilainya dari server via internet dan akan diverifikasi pembeliannya di internet.

Sebagian nilai kadang masih bisa disimpan lokal, misalnya beberapa game ada fitur agar profile kita memakai kostum tokoh tertentu dan pengecekan fitur ini dilakukan lokal/offline.

Logika cheat ini sangat sederhana: misalnya di layar tertampil koin kita 120500, kita search nilai 120500 di memori. Kemungkinan ada beberapa memori yang memiliki nilai itu, berikutnya: kita belanjakan uangnya, misalnya jadi 110000. Lalu kita search lagi nilai 110000 itu, hasilnya: akan ada daftar memori yang berkurang nilainya. Kalau masih ada kandidat lain, kita coba belanjakan koin lagi atau beli koin lagi, sampai ketemu: di memori ini tersimpan nilai koinnya.

Cheating jenis ini levelnya sangat mudah, berlaku untuk banyak game sederhana yang kurang populer. Tool yang dibutuhkan juga banyak tersedia di internet (misalnya Game Guardian untuk Android). Untuk mengedit savefile kadang hanya butuh hex editor saja. Biasanya tidak dibutuhkan coding untuk cheat jenis ini.

Function Hooking/Library Patching

Cheat level berikutnya butuh coding. Fungsi-fungsi tertentu bisa diganti implementasinya dengan milik kita sendiri. Contoh sederhana: jika ada fungsi bernama “isVisible()” yang gunanya untuk mengecek apakah sebuah objek terlihat atau tidak bisa diganti dengan fungsi yang selalu mengembalikan “true”.

Ada banyak library untuk function hooking, tergantung platform/sistem operasi yang dipakai. Contoh: di iOS ada fishhook (untuk hooking fungsi library), substrate (hooking fungsi sembarang). Di Android bisa memakai library Frida (butuh root). Di Windows ada banyak teknik hooking yang bisa dicari sendiri.

Contoh hooking yang lain adalah melakukan intercept terhadap paket jaringan. Sebelum data dikirim ke server, data bisa diubah (misalnya yang tadinya “miss” jadi “hit”). Sebaliknya: data dari server yang tidak ditampilkan oleh game, bisa ditampilkan ke user.

Di level ini cheating sudah butuh coding. Coding biasanya perlu dilakukan di level native code (biasanya C) tapi kadang sampai harus level assembly. Ini semua tergantung proteksi gamenya dan dalam bahasa apa game itu ditulis..

Banyak tutorial cheat di Youtube yang cuma sampah. Mereka memperlihatkan mengedit file .so dengan hex editor saja. Seringkali nilai yang diberikan ngawur, dan jelas tidak akan jalan di versi lain file .so tersebut. File .so isinya adalah kode mesin, untuk memahaminya diperlukan disassembler/decompiler.

Bentuknya apa function hooking ini? bisa berupa aplikasi baru yang melakukan injeksi ke aplikasi asli atau bisa berupa library (dll di Windows, .so di Linux/Android .dylib di OSX/iOS). Library ini bisa berupa library baru, atau hasil patch dari library lama.

Bot

Bentuk cheat lain yang umum adalah bot. Artinya: bukan manusia yang main gamenya, tapi program lain. Jenis bot ini bisa banyak: ada yang full bisa memainkan game dari awal, atau ada yang dipakai untuk melakukan aksi tertentu saja (mengumpulkan koin, dsb).

Bot ada yang bisa dijalankan di device, ada yang bisa dijalankan di PC. Bot ada yang butuh aplikasi gamenya, dan ada juga bahkan yang hanya berupa skrip yang langsung melakukan request ke server.

In App Purchase (IAP) Hack

Untuk game di mana pemain bisa membeli koin dengan in app purchase, maka ini bisa dicurangi untuk game yang tidak mengecek di sisi server. Semua game besar/populer punya server untuk mengecek receipt dari app store dan biasanya tidak bisa dicurangi.

Flow pembelian adalah: aplikasi meminta app store untuk meminta uang dari user. Setelah selesai, app store akan memberi tahu aplikasi bahwa pembelian selesai, dan ini tanda terima (receiptnya). Aplikasi kemudian bisa mengecek ke server app store untuk memeriksa apakah receiptnya valid. Nah masalahnya: jika aplikasi meminta langsung ke app store, fungsi ini bisa dihook dan hasilnya: “ok ini receiptnya valid”.

Anti Cheating

Setelah memberi contoh teknik cheating, saya akan menjelaskan “anti cheating” yang umum dilakukan. Saya akan mengambil contoh dari teknik cheating di atas.

Anti Memory/File Editing

Supaya savefile tidak dimodifikasi, filenya bisa dihash dengan digital signature. Jika signature tidak valid, maka game tidak mau meload savefile-nya. Jadi jika file diedit dengan hex editor, hasilnya: game tidak mau meload filenya karena signaturenya tidak valid lagi.

Bagaimana dengan nilai di memori? misalnya kita ingin menyimpan nilai score, bisa saja scorenya disamarkan, misalnya dengan minus N. Jadi jika nilai koin saat ini 100000, dengan N = 12000, maka tersimpan di memori: 88000. Ketika akan ditampilkan di layar, nilai N-nya ditambah dulu dengan 12000. Teknik anti cheating ini terlalu sederhana, dan beberapa engine cheating bisa mendeteksi seperti ini. Tentunya kita bisa juga menggunakan enkripsi yang lebih rumit seperti AES.

Sebagai programmer, tentunya banyak kreativitas yang bisa dilakukan untuk menyembunyikan nilai koin ini. Misalnya bisa saja nilainya disimpan di 10 tempat, masing-masing ditambah/dikurangi dengan nilai berbeda. Tiap kali gamenya dijalankan bisa juga dibuat nilai random untuk mengecoh fitur “value finder” dari sebuah cheat engine.

Cara paling efektif adalah: nilai koin disimpan di server, dan segala pembelian item diproses oleh server, sehingga cheat jenis ini tidak bisa dilakukan.

Anti Function Hooking/Library Patching

Jika sudah belajar teknik malware tingkat lanjut, kita akan tahu bahwa mengganti fungsi akan meninggalkan jejak. Cara termudah mengecek ini adalah: dengan melakukan checksum binary di memori, lalu nilainya dikirimkan ke server. Server bisa mengecek apakah nilai sesuai seharusnya.

Cara lain adalah dengan mengecek header tiap fungsi, apakah ada tanda-tanda bahwa fungsi tersebut sudah di-hook/intercept. Ketika melakukan patching kode, berbagai library akan mengubah header fungsi dengan instruksi assembly untuk “jump”. Jika ini terdeteksi, maka berarti fungsi sudah diubah.

Anti Bot

Ketika diluncurkan, banyak sekali orang yang membuat bot Pokemon Go. Versi pertama aplikasi ini proteksinya kurang bagus, jadi seseorang bisa mempelajari dengan mudah. Versi-versi berikutnya menjadi sangat sulit dan sekarang tidak ada lagi library yang bisa dipakai untuk melakukan koneksi ke server Pokemon Go.

Teknik anti bot yang mereka pakai adalah gabungan dari banyak hal. Mereka membuat koneksi yang dihash secara custom, versi pertama masih bisa dibongkar. Berikutnya mereka membuat versi berikutnya yang terenkripsi. Selain itu mereka mendeteksi berbagai macam perilaku (behavior) bot yang tidak masuk akal atau tidak konsisten. Ini digabung dengan berbagai cara untuk mendeteksi function hooking/library patching.

Anti IAP Hack

Jika sebuah aplikasi/game cukup sukses, developer bisa memiliki server yang bisa mengecek receipt In App Purchase dengan melakukan koneksi ke server. Jadi ketika seseorang membeli koin:

  • Transaksi dilakukan di device
  • Aplikasi mengirimkan receipt ke server pembuat aplikasi
  • Server pembuat aplikasi akan melakukan validasi ke server apple/google (koneksi langsung tidak bisa diintercept)
  • Status koin/fitur di server pembuat aplikasi akan diupdate jika valid
  • Aplikasi mendapatkan informasi dari server
  • Ketika akan menggunakan koin untuk membeli item, server memakai informasi yang ada di server, jadi tidak bisa diubah oleh aplikasi

Kadang masih ada kebocoran, terutama jika ada metode lain seseorang bisa mendapatkan koin misalnya jika pengguna aplikasi bisa mendapatkan koin/reward dari menonton iklan.

Anti-anti Cheating

Apakah para cheater segera menyerah dengan adanya berbagai teknologi anti cheat? Tentunya tidak. Tapi di level ini sudah dibutuhkan pemahaman kode yang dalam.

Anti-anti memory patching/editing

Jika sebuah nilai hanya disamarkan di memori, maka dengan melakukan reverse engineering (membaca disassembly dan hasil dekompilasi) bisa ditemukan nilai apa yang dikurangi/ditambah. Jika sudah tahu perubahannya, maka teknik pertama kembali bisa dilakukan, cukup dengan menambah/mengurangi/melakukan decrypt terhadap nilai di memori.

Jika aplikasi mendapatkan nilai dari server, mungkin nilainya bisa diintercept dengan function hooking agar bisa diubah sebelum sampai ke aplikasi.

Jika memang aplikasi butuh nilai di memori dan terlalu lambat untuk meminta nilainya dari server, apakah pembuat aplikasi akan menyerah di level ini? pembuat aplikasi bisa mengubah metodenya tiap rilis baru gamenya. Cheat yang berjalan di versi 1.0, tidak akan jalan lagi di versi minggu depan.

Anti-anti function patching

Dalam kasus anti function patching: ada kode yang memeriksa apakah fungsi ini diubah atau tidak. Kode pemeriksa ini bisa dipatch agar hasilnya selalu mengembalikan OK. Tentunya mencari kode pemeriksa ini juga tidak mudah, butuh reverse engineering lagi.

Lalu apa respond pembuat game? sekarang sebagian game memiliki kode (X) yang akan mengecek apakah ada patching. Lalu ada kode (Y) yang memeriksa apakah fungsi pengecek (X) tersebut tidak dipatch. Contoh lain: ada game yang memiliki dua fungsi yang saling mengecek satu sama lain.

Apakah para pembuat cheat menyerah? tidak juga, banyak teknik yang bisa dipakai misalnya emulasi kode menggunakan emulator tertentu (misalnya Unicorn Engine atau Qemu), merelokasi kode (misalnya dengan Gum Relocator bagian dari Frida) dan mempatch kode aslinya.

Anti-Anti IAP

Khusus untuk In App Purchase, di sini cheater memiliki keterbatasan. Untuk pengecekan di sisi server, tidak ada lagi yang bisa dilakukan, kecuali ada yang nekat menghack servernya.

Untuk game yang punya fitur voucher/kode: sering kali hacker membeli voucher dengan kartu kredit curian, lalu menjual vouchernya. Di dalam kasus lain, kadang server penjual voucher yang dihack untuk mendapatkan kode voucher gratis.

Anti Reverse Engineering

Berbagai teknik anti cheat bisa dipelajari jika kita bisa membaca kodenya. Untuk mempersulit, kebanyakan game memakai teknik Anti-RE. Biasanya yang paling dasar adalah obfuscation.

Obfuscation adalah teknik untuk membuat kode lebih sulit dibaca oleh manusia, dan tetap bisa dieksekusi langsung oleh mesin. Jangan kaget misalnya ketika melakukan reverse engineering berbagai aplikasi, bahkan IDA Pro bisa diakali agar tidak mengenali function boundary (mana awal/akhir fungsi). Decompiler juga bisa menghasilkan kode yang membuat kita pusing.

Untuk native code, standar yang dipakai saat ini adalah LLVM Obfuscator. Versi lama bisa ditangani dengan plugin khusus IDA Pro. Tapi banyak perusahaan memiliki varian khusus dari obfuscator ini sehingga tools deobfuscator sederhana tidak bisa digunakan.

Selain itu teknik RE yang lain adalah anti debugging. Dengan ini kode program tidak bisa dengan mudah dijalankan dalam debugger.

Anti-anti-anti …

Untuk setiap teknik cheat yang diciptakan, akan ada teknik anti-cheat. Dan untuk tiap teknik anti-cheat, akan ada teknik anti-anti-cheat, sampai batas tertentu.

Pembuat game bisa membuat anti cheat yang sangat hebat dan rumit, tapi jika terlalu rumit dan membuat gamenya terlalu lambat dimainkan atau butuh spec terlalu tinggi, atau membuat HP menjadi sangat panas, maka pemain akan berhenti bermain. Jadi pembuat game punya batasan pemeriksaan yang bisa dilakukan.

Tiap platform punya batasan masing-masing sehingga tidak semua teknik anti cheat bisa dipakai. Misalnya aplikasi iOS yang masuk ke app store tidak mungkin memiliki self modifying code seperti di Android

Sementara biasanya batasan pembuat cheat adalah kesabaran. Jika pembuat game mengubah anti cheatnya tiap bulan, lama-lama mereka akan lelah. Ingat: pembuat anti cheat dibayar mahal, sedangkan pembuat cheat biasanya pendapatannya tidak seberapa.

Tiap level baru membutuhkan skill baru. Untuk bisa melakukan hacking game modern, minimal perlu pengetahuan reverse engineering yang dalam, plus pengetahuan spesifik untuk platform tertentu (Android/iOS/yang lain).

Selain itu ada banyak teknologi spesifik yang perlu dipelajari, tergantung gamenya. Ada game yang dibuat menggunakan Unity, dan untuk patching gamenya kita perlu mengenai engine Unity. Game dengan Unity gampang diedit jika masih menggunakan mode .NET murni, tapi jadi sulit jika ditranslasikan ke C (dengan il2cpp) dan dilewatkan ke obfuscator. Ada game yang memakai game engine Corona yang memakai Lua jadi perlu mengenal bahasa pemrograman Lua.

Sampai di titik tertentu, ketika sudah paham berbagai hal low level, banyak hacker game yang akhirnya memilih jalan lain. Menjadi programmer atau melakukan pekerjaan security yang pendapatannya lebih besar. Di jangka panjang, menjadi pembuat cheat juga cukup membuat stress karena tiap versi bisa ada proteksi baru yang perlu dipelajari.

Resource

Saya bisa menyarankan resource-resource ini untuk mulai mengenal dunia hacking game:

Atau cari informasi spesifik mengenai teknik yang ingin Anda ketahui. Contohnya teknik anti reversing di Android ada di resource ini. Sebagai catatan: ini baru resource untuk memulai, ketika mulai berusaha cheating, akan ada banyak hal lain yang perlu dipelajari: tentang berbagai format data, tentang enkripsi, dan masih banyak lagi.

Jika ingin yang bentuknya video, sudah ada yang membuat serial belajar game hacking (ketik artikel ini ditulis, levelnya masih sampai level dasar, tidak akan bisa mencurangi game modern dengan yang diajarkan di level ini):

https://guidedhacking.com/threads/squally-cs420-game-hacking-course.14191/

Penutup

Saran saya buat yang ingin hacking game: cobalah dari game yang sederhana. Lebih bagus lagi kalau Anda mencoba membuat game sendiri supaya lebih paham mengenai struktur sebuah game.

Buat Anda yang ingin terjun sampai game yang sulit: silakan saja, tapi jika modalnya hanya ingin mengedit file dengan hex editor saja, Anda tidak akan sampai ke mana-mana. Keahlian Reverse Engineering wajib dikuasai.

Dan jangan tanya saya bagaimana memakai tools IDA Pro, Ghidra, Radare. Berbagai tools tersebut banyak tutorialnya di Internet. Tapi intinya bukan pada toolnya, tapi kemampuan membaca kode. Mengajari memakai microsoft Word bisa dilakukan dengan cepat, tapi mengajari cara membuat Novel yang indah dengan Microsoft Word akan butuh waktu sangat lama. Word di sini hanyalah sekedar tool.

Sebenarnya saya juga tidak keberatan berdiskusi mengenai berbagai teknik cheat/anti-cheat. Tapi kalau level ilmunya masih terlalu jauh, maaf saya nggak sabar, karena harus banyak sekali menjelaskan segala sesuatu. Seringkali yang bertanya:

  • Tidak menyebutkan apa gamenya, untuk platform apa (iOS/Android/PC), padahal tekniknya berbeda untuk berbagai OS
  • tidak pernah memakai IDA pro atau tool sejenis
  • tidak pernah memakai debugger
  • tidak tahu berbagai teknik cheat, hanya ingin tahu bagaimana bypass anti cheat. Padahal setiap bagian anti cheat itu dibuat karena jenis cheat tertentu

Ini seperti anak kelas 2 Sekolah Dasar yang minta dijelaskan matematika untuk pemrograman game 3D, tapi (sesuai kurikulum kelas 2 Sekolah Dasar ):

  • belum bisa mengalikan bilangan besar
  • belum tahu perpangkatan
  • belum tahu notasi matriks
  • belum tahu berbagai konsep geometri (koordinat 3D), fungsi trigonometri (sin, cos, tan), dsb.

Nah jika ada anak SD bertanya seperti itu, apakah Anda mau menjelaskan? apakah bisa punya kesabaran menjelaskan setiap bagian sampai anak SD-nya mengerti? dan andaikan bisa, kira-kira akan butuh berapa lama? bersedia menjelaskan itu semua tanpa dibayar? Atau Anda akan menyuruh anak SD itu untuk belajar dulu dasar-dasarnya?

Jika pertanyaannya sangat spesifik, maka saya bisa memberikan petunjuk, seperti misalnya bagaimana mendeteksi method swizzling di Objective C? (banyak dipakai untuk mencurangi game/aplikasi iOS) dan bagaimana membypass deteksinya?

Jangan juga meminta saya membuat cheat untuk game tertentu. Saya sudah pernah menulis biaya reverse engineering itu mahal. Kalau ingin gratis ya silakan belajar sendiri.

Jawaban di Reddit yang saya temukan ini cukup mewakili jawaban saya terhadap yang ingin bertanya tentang cara reverse engineering anti cheat pada sebuah game. Intinya adalah: “get good”.

Certificate pinning dan unpinning

Certificate pinning adalah suatu cara agar sebuah aplikasi bisa memastikan bahwa koneksi SSL/TLS dilakukan terhadap server yang seharusnya. Topik yang sering ditanyakan ke saya adalah bagaimana membypass SSL pinning agar dapat melakukan pentest terhadap sebuah aplikasi. Di sini saya akan membahas beberapa teknik unpinning, terutama untuk mobile OS (iOS dan Android).

Sebelum masuk ke topik pinning, saya review dulu sedikit mengenai komunikasi sebuah browser/ aplikasi ke sebuah server. Agar lebih singkat: browser dan aplikasi akan saya sebut sebagai aplikasi saja, karena browser juga adalah sebuah aplikasi.

DNS

Ketika kita mengunjungi blog.compactbyte.com, aplikasi akan bertanya: apa alamat IP untuk blog.compactbyte.com? pertanyaan ini ditujukan ke server DNS (domain name system). Dan setelah tahu alamat IP-nya aplikasi bisa melakukan koneksi ke server tersebut.

Dari proses awal ini saja sudah ada dua kemungkinan masalah: pertama adalah server DNS mana yang kita pakai?

Lanjutkan membaca “Certificate pinning dan unpinning”

Membongkar Ransomware

Rasanya tiap beberapa hari ada yang bertanya tentang bagaimana mengatasi ransomware tertentu di berbagai group, terutama di group reverse engineering. Jawaban saya untuk yang terkena ransomware tetap sama: buat backup, restore dari backup, atau jika beruntung mungkin sudah ada yang membuat dekriptornya.

Artikel ini untuk anda yang ingin membongkar ransomware dan ingin membuat dekriptor sendiri. Perlu saya peringatkan bahwa ini tidak mudah, dan seringkali mustahil membuat dekriptornya. Setelah membaca ini semoga Anda paham bahwa: meminta membuat dekriptor khusus untuk ransomware yang kena ke komputer Anda itu seperti minta uang semilyar dari orang di pinggir jalan.

Jumlah ransomware baru tiap hari sangat banyak. Mudah sekali membuat ransomware dari nol, atau memodifikasi dari yang sudah ada (banyak yang bisa dicari di github, saya tidak akan melink langsung). Jadi kemungkinannuya cukup besar Anda terkena ransomware yang belum pernah didengar orang lain atau tidak dibahas di Internet.

Dalam tulisan ini saya akan menggunakan contoh soal dari Flare On 2019, sebuah ransomware bernama Mugatu. Karena Mugatu hanyalah soal CTF, ini sengaja dibuat agar hanya mengenkrip file yang sangat spesifik dan memiliki kelemahan dalam enkripsinya. Ini merupakan contoh yang cukup baik untuk dipelajari karena:

  • Malwarenya memakai teknik anti analisis (seperti malware yang sesungguhnya)
  • Malwarenya tidak berbahaya untuk dianalisis oleh pemula (tidak akan menginfeksi PC lain di jaringan)
  • Memiliki contoh enkripsi yang lemah

Silakan dibaca writeup mugatu dari pembuatanya:

https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/FlareOn6_Challenge10_Solution_Mugatu.pdf

Inti dari membuat dekriptor ransomware adalah:

  • melakukan reverse engineering malware
  • memahami enkripsi dan membuat dekriptor

Sebelum membahas jauh dan memberi harapan palsu. Saya ingin menekankan dulu: tidak semua ransomware bisa dibuat dekriptornya, dan andaikan bisa dibuat dekriptornya, reverse engineering butuh waktu lama.

Tidak semua ransomware bisa dibuat dekriptornya

Kenapa sebuah ransomware bisa tidak ada dekriptornya? apakah tidak ada ahli yang mampu membuat dekriptornya? Ini bukan masalah keahlian, tapi batasan teknis.

Kalau misalnya ketemu ponsel rusak seperti gambar di bawah ini, kemungkinan tidak akan bisa diperbaiki tukang reparasi. Kalaupun bisa, waktu yang dibutuhkan untuk memperbaiki sangat besar, dan nggak sebanding dengan harga ponselnya. Tentunya di kasus seperti ini Anda tidak akan bilang: wah tukang reparasinya nggak jagoan.

Sumber https://www.flickr.com/photos/glenbowman/3511874961

Contoh masalah teknis:

  • Ada ransomware yang entah salah coding atau sengaja merusak file dan tidak bisa dikembalikan lagi (menimpa isi file dengan random)
  • Ada ransomware yang cara enkripsinya tidak memiliki kelemahan. Silakan baca artikel saya mengenai unbreakable encryption.

Kalau Anda benar-benar malas membaca berbagai tulisan dan buku mengenai dasar enkripsi, minimal bacalah artikel saya mengenai unbreakable encryption. Tulisan tersebut sudah saya usahakan sangat sederhana dan harusnya bisa dimengerti oleh orang awam sekalipun, supaya tidak ngeyel bahwa “tiap enkripsi pasti bisa dibongkar”.

Intinya begini: meskipun sudah mendapatkan source code lengkap dan penjelasan lengkap tentang bagaimana ransomwarenya bekerja, tetap saja beberapa ransomware mustahil dibuat dekriptornya (kecuali kita tahu keynya).

Reverse Engineering butuh waktu lama

Jangan kira sebuah ransomware bisa dipahami dan dibuat dekriptornya dalam hitungan jam saja. Mungkin ada ransomware sederhana yang bisa dibongkar dalam hitungan jam, tapi kebanyakan akan butuh beberapa hari sampai beberapa minggu, dan butuh beberapa orang. Saya juga pernah menulis tentang mahalnya biaya reverse engineering.

Jika membongkar ransomware bisa sangat mudah dan selesai dalam 1-2 hari oleh orang yang kemampuannya baru belajar RE, maka perusahaan security dan antivirus akan rame-rame mempekerjaan banyak pemula, dan produknya akan jadi yang paling banyak dicari orang untuk mengembalikan data dari ransomware. Kenyataannya sekarang ini kebanyakan perusahaan antivirus dan security hanya bisa membuat dekriptor untuk beberapa ransomware saja, karena butuh waktu dan keahlian yang tinggi.

Prioritas perusahaan security biasanya adalah pada malware yang populer (menyebar luas), dan biasanya mereka tidak akan menghabiskan banyak waktu untuk ransomware yang kurang populer atau menyebar di wilayah tertentu saja. Jadi jika Anda beruntung, mungkin Anda bisa mendapatkan dekriptor gratis, tapi kemungkinannya makin sedikit dengan banyaknya jumlah ransomware.

Fakta bahwa reverse engineering butuh waktu lama sangat penting, karena kebanyakan orang sudah menyerah duluan setelah beberapa jam atau beberapa hari belum bisa maju. Aplikasi yang tidak memiliki proteksi khusus saja bisa butuh waktu lama, contohnya saya butuh waktu sekitar sebulan untuk mereverse engineer Pokemon Go Plus.

Nah sekarang jika memang sudah sangat berniat, maka langkah berikutnya adalah:

  • Belajar dasar reverse engineering malware
  • Belajar dasar enkripsi

Dasar Reverse Engineering Malware

Topik reverse engineering malware sendiri sangat luas. Sudah ada banyak buku yang membahas ini misalnya:

Saya juga sudah pernah membuat tulisan mengenai pengantar reverse engineering (tapi tidak spesifik malware).

Jangan berharap bisa mengerti dari sekedar membaca jawaban singkat dari bertanya di group chat atau dari menonton satu dua video saja. Reversing malware ini butuh kesabaran dan banyak latihan.

Saran saya ketika memulai: gunakan virtual machine yang tidak terhubung ke jaringan (networking dimatikan). Jangan merasa jagoan ketika baru pertama kali berurusan dengan ransomware, jika Anda membuat kesalahan, semua PC di jaringan bisa terinfeksi (contoh kasus: WannaCry).

Ibaratnya seperti belajar kalkulus, 99.99% orang akan butuh waktu dan latihan selama beberapa semester untuk bisa memahaminya (mungkin ada 0.01% orang super jenius yang bisa belajar kalkulus sendiri dalam beberapa jam atau beberapa hari). Coba bayangkan apakah Anda bisa diminta menjelaskan kalkulus via chatting? mengajari integral dan differensial dasar bisa dilakukan relatif cepat, tapi ketika sudah masuk topik rumit, segala macam trik dasar tidak bisa dipakai lagi.

Sebuah program biasa biasanya tidak terlalu sulit dibongkar/reverse engineer. Tapi sebuah ransomware biasanya tidak mudah dibongkar, ada trik-trik yang mempersulit analisis, atau membuat analisisnya jadi salah. Di contoh CTF Mugatu ada trik supaya IAT (import address table) jadi kacau jika langsung dibuka dengan disassembler/decompiler.

The first-stage malware shouldn’t seem too difficult when looking at it in a disassembler. However, something should start to feel amiss after you’ve looked at the API calls and how they are used. While some seem legitimate, others seem completely wrong.
The malware uses a trick I designed that involves running code before WinMainCRTStartup.


This function is responsible for the C-runtime initialization. Most disassemblers will skip this
function and start in WinMain, which corresponds to the main function for the code you programmed. . By skipping WinMainCRTStartup, you may miss my insidious trick.

Writeup Mugatu

Jadi kalau baru sekedar bisa membongkar aplikasi dengan Ghidra atau IDA Pro, ketika membongkar Mugatu akan langsung bingung karena API call-nya kok semuanya salah. Perlu dicatat bahwa ini hanya satu obfuscation sederhana, masih ada puluhan teknik lain misalnya:

  • String encryption
  • Anti debugging
  • Anti disassembly
  • Anti decompilation
  • Virtual Machine based protection
  • Heaven’s Gate (hanya untuk Windows 8 ke bawah), salah satu teknik yang cukup rumit

Dasar ilmu Enkripsi

Ransomware adalah malware yang mengenkripsi file korbannya. Jadi langkah logis berikutnya adalah: memahami enkripsinya.

Pertama yang saya sarankan adalah: cobalah membuat program yang mengenkrip dan mendekrip file. Lebih bagus lagi kalau membuat enkriptor dalam satu bahasa dan dekriptor dalam bahasa lain, supaya lebih paham berbagai variasi API enkripsi dalam berbagai bahasa.

Contohnya begini: jika kita ingin mengenkrip file, maka ada banyak cara:

  • Kita mengimplementasikan sendiri algoritma AES/RSA atau bahkan algoritma custom
  • Kita menggunakan library yang sudah ada, misalnya: CryptoPP (C++), openssl (C dengan binding ke banyak bahasa), Bouncycastle (Java, .NET)
  • Kita bisa menggunakan library built in dari sistem operasi (misalnya wincrypt di Windows)

Jadi pembuat ransomware bisa memilih salah satu dari cara di atas. Bagaimana misalnya kalau dia memilih Wincrypt, dan kita sudah bisa mendekompilasi kodenya. Apakah Anda akan bisa memahami proses enkripsi dan membuat dekriptornya? jika ransomwarenya memakai CryptoAPITransform, apakah Anda bisa membuat dekriptornya?

Cobalah membaca dan memahami berbagai jenis enkripsi. Jika kita bahkan tidak tahu enkripsi apa yang dipakai oleh ransomware, bagaimana kita bisa tahu apa kelemahannya?

Kelemahan Implementasi Enkripsi

Ini adalah topik yang paling sulit saya jelaskan, karena kebanyakan yang bertanya tidak paham mengenai dasar enkripsi. Saya sebenarnya sudah menulis sebagian topik dasar ini, misalnya beberapa artikel ini, tapi belum lengkap dan menyeluruh (topik enkripsi ini sangat luas):

Beberapa contoh kelemahan dalam implementasi enkripsi ini misalnya:

  • Keynya ada di ransomware itu sendiri/fixed key
  • Keynya berdasarkan MAC address komputer (atau nomor seri harddisk, atau sesuatu yang lain yang bisa dicari)
  • Keynya random, tapi ada kelemahan dalam cara menghasilkan bilangan randomnya (tidak menggunakan secure random)
  • Salah memanggil fungsi enkripsi (misalnya salah parameter)
  • Salah mengimplementasikan algoritma enkripsi
  • Memakai stream cipher dengan key yang sama untuk setiap file

Di soal Flare On Mugatu, ternyata kelemahannya adalah: hanya 4 byte key yang dipakai untuk enkripsi. Dan ini bisa dibruteforce dengan cepat menggunakan C.

Salah satu cara untuk mendapatkan gambaran berbagai kelemahan enkripsi adalah dengan mengikuti CTF kategori crypto, atau minimal membaca berbagai writeup di kategori crypto. Untuk saat ini saya sarankan dari CTF di luar negeri, karena kebanyakan CTF di Indonesia masih basic sekali soal kriptografinya.

Contoh beberapa malware yang memiliki kelemahan enkripsi: LockCrypt dan ACCDFISA. LockCrypt memakai enkripsi lemah dan random number generator (RNG) yang lemah, sedangkan ACCDFISA yang membuat password dengan RNG yang lemah. Untuk contoh lain ransomware yang tidak bisa dibongkar tapi pembuatnya menyerah dan memberikan keynya: Teslaware.

Pernah juga ada kasus di mana kelemahan malware bukan di malware itu sendiri tapi di server pembayaran tebusan/ransom. Servernya berhasil di hack, dan keynya bisa diambil dari server.

Penutup

Mungkin sebagian tulisan ini terasa mengecewakan, dan mungkin sebagian akan berpikir: wah susah ya, kalau begitu gak jadi deh, saya menyerah aja. Kalau memang memiliki niat, sebaiknya jangan menyerah.

Tidak semua pembuat ransomware jagoan, mungkin ada ransomware buatan lokal dan hanya menyebar lokal di kota tertentu (bahkan sangat lokal, misalnya cuma area kampus tertentu), dan ada kemungkinan enkripsinya tidak rumit atau memiliki kelemahan. Anda bisa mencoba-coba membuat dekriptornya, dan menyelamatkan minimal orang-orang di sekitar Anda.

Semoga tulisan ini cukup untuk menjawab Anda yang ingin belajar membongkar sendiri ransomware. Jika ada pertanyaan lebih lanjut bisa ditanyakan ke saya (lihat side bar mengenai cara menghubungi saya).

Flare-On 2019 dan pembahasan soal no 6

Flare On ke-6 sudah selesai dan solusi dari panitia juga sudah diberikan. Ini tahun ke-5 saya menyelesaikan seluruh soal Flare On.Tidak seperti tahun-tahun sebelumnya di mana saya ingin buru-buru selesai, tahun ini saya sangat santai dan selesai di peringkat 148. Tahun ini ada 308 orang yang selesai semua dari total 5790 yang mendaftar. Kalau tidak sibuk, tahun depan saya rencana tetap ikut dalam mode santai seperti ini.

Menurut saya Flare On ini sangat berguna untuk mengasah ilmu reverse engineering dan mengenal berbagai teknik baru yang tidak/belum saya ketahui. Soal tahun ini sejak nomor satu sudah lebih sulit dari tahun-tahun sebelumnya, tapi ada 3228 yang berhasil menyelesaikan soal pertama. Menurut saya soal-soal nomor tinggi justru lebih mudah dari tahun-tahun sebelumnya tapi butuh banyak kesabaran. Sama seperti tahun-tahun sebelumnya, di akhir kita akan ditanya apakah ingin mengirimkan CV ke Fire Eye.

Tahun ini ada dua orang yang saya kenal dari Indonesia yang berhasil menyelesaikan Flare On: 0xf4c0 dan Visat (dari team PDKT), seperti biasa karena alamat pengiriman hadiah di Thailand saya dihitung dari Thailand.

Dulu saya cukup rajin untuk menuliskan solusi semuanya, sekarang karena solusi dari panitia sudah datang cepat, saya malas menuliskannya, kecuali jika ada pendekatan saya yang berbeda. Tahun lalu saya hanya menuliskan dasar ilmu apa yang dibutuhkan untuk menyelesaikan tiap soal.

BMPHIDE

Hari ini ada yang bertanya apakah saya bisa menuliskan cara saya menyelesaikan soal No 6 (BMPHIDE), karena saya punya waktu, jadi saya tuliskan saja sekarang (kebetulan juga sekarang Flare On ke-6, jadi saya bahas soal No 6 saja). Di soal ini kita diberi sebuah program dan file bitmap (BMP). Soalnya bernama bmphide, dari namanya saja sudah terpikir bahwa ini adalah soal steganografi, tapi tentunya bukan soal steganografi biasa.

Sebelum membaca solusi saya, sebaiknya baca dulu solusi resmi dari Flare On (PDF), lalu kembali ke sini. Ada beberapa hal yang tidak akan saya bahas detail, misalnya: ada anti debug sehingga program tidak bisa didebug. Dari pengalaman di Flare On tahun-tahun sebelumnya: jika ada anti debug, maka saya akan berusaha tidak memakai debugger karena biasanya anti debugnya sangat kompleks dan memakan waktu lama. Bahkan di beberapa soal di tahun sebelumnya: jika dijalankan di debugger malah tidak bisa ketemu flagnya.

Tidak ada instruksi untuk menjalankan program yang diberikan, tapi karena programnya ditulis dalam .NET kita bisa membongkarnya dengan dnspy untuk melihat kodenya. Bagian main-nya seperti ini:

Dari membaca kodenya, Program BMPHIDE.EXE dipakai untuk menyembunyikan data di dalam file bitmap. Jika dibaca sekilas bagian enkripsi (Program.h()) dan menyembunyikan data dalam bitmap (Program.i()) cukup jelas. Ini steganografi standar dengan menggunakan LSB.

Pendekatan saya tidak memakai debugger adalah dengan membuat ulang programnya di project Visual Studio. Ternyata jika kode hasil dekompilasi ini kita copy paste ke project baru di Visual Studio, hasilnya tidak seperti yang diharapkan. Jadi pasti ada sesuatu yang ajaib yang dilakukan oleh program.

Jadi akhirnya saya mulai membaca lagi lebih teliti programnya. Ada method aneh bernama VerifySignature. Dari melihat sekilas saja, sepertinya ini akan membuat agar pointer method1 jadi pointer method2. Setelah membaca-baca beberapa artikel (contohnya ini), memang itu yang dilakukan.

Mungkin ada yang heran: dari mana tahu bahwa ini kode penting? Saya tahu dasar .NET, jadi terbayang kira-kira apa yang bisa dan tidak bisa dilakukan di .NET, jadi dari dasar ilmu itu bisa mencari di Internet mengenai MethodHandle di .NET dan apa yang bisa dilakukan.

Sekarang hal pertama sudah diketahui: ada method yang ditukar implementasinya, jadi andaikan kita memanggil method X, yang dipanggil sebenarnya Y. Tapi method mana yang ditukar? tidak dengan mudahnya mereka menuliskan tukar method bernama X dengan Y, tapi mereka membuat kode seperti ini:

Intinya seluruh method dibuat checksum kodenya, lalu method yang checksumnya sekian akan ditukar dengan yang checksumnya sekian. Di project visual studio saya, saya perlu meload bmphide.exe ini agar bisa dilihat semua methodnya dan dibuat checksumnya. Ini bisa dilakukan dengan kode semacam ini (kuncinya di sini adalah Assembly.LoadFrom):

Dari sini saya bisa mengetahui method mana yang ditukar. Tapi ternyata tidak cukup di sini triknya. Ada method yang bernama IncrementMaxStack (namanya menyesatkan, tidak ada hubunganya sama sekali dengan stack), yang berisi kode untuk mem-patch alamat memori dengan isi tertentu (lihat “writeByte” dan “writeInt32”). Dari nama fieldnya (ILCode) sudah jelas bahwa yang dipatch adalah IL (Intermediate Language) code, tapi kode yang mana yang dipatch?

Kali ini method tidak dicari berdasarkan isi checksumnya tapi berdasarkan metadata tokennya. Jadi sekali lagi saya meloop semua method dan mencetak MetadataToken-nya untuk mendapatkan dua method yang dipatch. Saya bahas saja salah satu method yang dipatch yaitu program.g, hasil dekompilasi asli seperti ini:

Tapi kode ini dipatch di offset 6 dengan angka baru dan offset 18 (atau 12 hexa) dengan angka baru.

Jika kita lihat IL code-nya, akan terlihat apa artinya offset 6 dan 12 hexa ini (lihat kolom kedua, dengan header “offset”). Di sini tidak ada offset 6, tapi ada offset 5. Di offset 5 ada instruksi ldc (load constant), yang meload bilangan -0x12477CE0. Bilangan ini yang dipatch menjadi 309030853. Hal yang sama juga dilakukan untuk offset 12 heksa.

Jadi setelah diperbaiki, fungsi g menjadi seperti ini:

Setelah mendapatkan versi benar dari semua methodnya, saya bisa mengcompile bmphide saya sendiri, dan bisa mendebugnya dan memahami algoritmanya dengan mudah. Sisanya hanya membuat dekriptor dan ekstraktornya.

Pendekatan saya sebenarnya antara pendekatan 1 dan 2: saya membrute force per byte dengan memanggil fungsi enkrip. Loopnya seperti ini:

Tidak seperti solusi di flare-on di mana hasil brute force (solusi 1) tidak jelas, hasil brute force ini akan jadi image yang bersih.

Penutup

Soal ini sebenarnya hanya “pemanasan” dalam hal enkripsi, tepatnya bagaimana sebuah enkripsi yang relatif sederhana bisa disembunyikan dengan trik sehingga sulit dibaca meskipun menggunakan decompiler. Soal berikutnya yang lebih serius ada di no 10. Di soal 10 kita diberi “ransomware” (bernama mugatu) yang memiliki kelemahan di bagian enkripsinya.

Bagi yang ingin merasakan betapa lamanya memahami enkripsi dan membuat dekriptor sebuah ransomware, silakan mencoba menyelesaikan soal no 6 dan 10. Ini soalnya masih sangat sederhana dan malware yang sebenarnya akan butuh waktu yang lebih lama lagi.

Mengenal Frida untuk Reverse Engineering

Salah satu tools reverse engineering yang sering saya pakai adalah Frida. Frida memungkinkan kita meng-intercept fungsi dalam C/native code (di berbagai sistem operasi), Java (di Android) dan Objective C (di macOS/iOS) dengan menggunakan JavaScript. Mungkin bagi sebagian orang deskripsi ini masih agak terlalu mengawang-awang, jadi akan saya berikan contoh nyata apa maksudnya mengintercept fungsi.

Saya berikan contoh program kecil seperti ini dalam C, yang hanya melakukan loop membuka satu file, mencetak sebaris dari file tersebut, lalu program akan sleep selama 1 detik. Program ini akan saya intercept dengan Frida.

Saya mengisi file1 dengan string “Yohanes Nugroho” dan file2 dengan string “Risnawaty”, jadi ketika dijalankan outputnya seperti ini:

Jenis intercept pertama adalah hanya sekedar memonitor pemanggilan fungsi. Dalam kasus ini saya memakai cara mudah memakai frida-trace dan meminta agar fungsi “open” ditrace. Pertama kita jalankan test-open di satu window, dan frida-trace di Window lain.

Sebagai catatan: fungsi C fopen akan memanggil fungsi “open”. Jadi kita juga bisa mengintercept “open”, dan hasilnya seperti ini:

Saya lebih suka bekerja dengan fungsi yang levelnya lebih dekat ke kernel, karena tidak perlu khawatir dengan berbagai detail implementasi di library C. Contohnya: fungsi fwrite akan membuffer penulisan ke file, sedangkan jika kita memakai write, akan langsung dituliskan. Contoh masalahnya ketika memakai fwrite kadang bingung: loh kenapa isi filenya masih sama? oh ternyata belum di-flush.

Dari contoh ini sudah bisa terlihat satu kegunaan tools ini: untuk melihat parameter sebuah fungsi. Dalam kasus tertentu ini sangat berguna, misalnya Kita bisa melihat key apa yang dipakai oleh sebuah fungsi enkripsi dengan memonitor fungsi enkripsi. Selain memonitor, kita bisa mengubah mengganti sesuatu, tidak sekedar memonitor.

Program frida-trace akan otomatis membuat file javascript sesuai nama fungsinya di direktori __handlers__. Dalam kasus ini didapati ada dua fungsi open: didalam libc dan libpthread. Dalam kasus ini yang akan terpakai adalah open di dalam libc. File Javascript yang dihasilkan oleh frida-trace seperti ini:

Intinya adalah: ketika masuk ke fungsi open, maka log/cetak parameter fungsinya. Sekarang kita bisa mengganti agar jika file1 dibuka, kita ganti dengan file2, seperti ini:

Sekarang kita bisa mencoba lagi menjalankan frida-trace. Di Window atas adalah program sebelumnya. Di bawahnya saya menjalankan frida-trace (dengan Javascript yang sudah dimodifikasi). Hasilnya di awal program akan mencetak “Yohanes Nugroho”, dan ketika frida-trace dijalankan, file yang dibuka diganti dengan file2 yang berisi “Risnawaty”. Ketika frida-trace dihentikan, fungsi dikembalikan seperti semua.

Perhatikan bahwa saya tidak mengubah sama sekali program test-open. Program tersebut dijalankan apa adanya seperti semula. Dengan kemampuan untuk mengubah parameter (dan juga kembalian fungsi, dalam onLeave), maka kita bisa membypass berbagai proteksi sederhana misalnya membuat isJailbroken() mengembalikan false, atau membuat layar administrator di aplikasi mobile bisa diakses user biasa. Dalam kasus tertentu ini bisa gawat jika ternyata checking hanya dilakukan lokal dan bukan di server.

Ketika mengintercept fungsi, Frida bisa memetakan dari calling convention menjadi objek javascript, misalnya register RDI di calling convention x86_64 menjadi isi args[0], dan ketika mengubah args[0] ini dipetakan agar mengubah RDI. Translasi calling convetion ini otomatis, jadi kita tidak perlu tahu di ARM memakai register apa untuk parameter pertama. Selain intercept fungsi, frida juga bisa mengintercept alamat tertentu (satu titik). Di mode ini, kode kita akan dipanggil tiap kali alamat tersebut dilewati (seperti breakpoint di debugger) tapi tidak ada pemetaan register atau stack ke argumen, jadi register dan memori perlu diakses manual.

Dalam banyak kasus, Frida bisa menggantikan peran debugger. Biasanya ketika melakukan RE Native Code, saya akan membaca kodenya, memahaminya, lalu biasanya perlu tahu nilai sebuah register atau isi memori tertentu. Dengan debugger, saya akan melakukan breakpoint di sebuah fungsi, lalu melihat isi registernya di titik itu atau mengubah nilai registernya. Dengan Frida, saya bisa menulis skrip untuk mengintercept alamat tertentu, dan di situ saya bisa melakukan aksi apapun dengan Javascript, misalnya:

  • Memprint isi register (atau mengubah registernya)
  • Mencetak backtrace fungsi (mengetahui fungsi mana yang memanggil fungsi ini)
  • Memprint isi memori (atau bahkan mengubahnya)

Perlu diperhatikan bahwa: kita perlu tahu dengan tepat fungsi apa yang perlu diintercept. Ini bisa dilakukan dengan static analysis (menggunakan disassembler/decompiler). Seperti contoh yang saya berikan: kita bisa melakukan intercept pada fungsi/API yang umum (open) tanpa mengetahui kodenya.

Cara kerja Frida

Ada banyak tulisan mengenai Frida, tapi kebanyakan hanya membahas satu hal kecil saja (kebanyakan untuk intercept API di Android saja). Di sini akan saya bahas sedikit lebih luas, supaya bisa memakai Frida di platform mana saja, bukan hanya untuk intercept aplikasi mobile.

Secara umum sebagian besar kode Frida ditulis dalam C dan bahasa Vala. Karena Frida memakai Javascript sebagai bahasa untuk mengontrol target, sebagian API Frida ditulis dalam Javascript. Tools command line Frida ditulis dengan Python, dan API utama Frida adalah dalam C. API Frida juga bisa diakses berbagai bahasa (Python/Java/.NET/Node dsb).

Hal pertama yang harus dipahami adalah: Frida perlu berjalan di address space proses yang menjadi target. Ada beberapa cara frida bisa masuk ke address space proses lain:

  • Kita compile source code kita dengan menginclude library Frida (dengan frida-gum-devkit, atau frida-gumjs-devkit)
  • Kita load library Frida (frida-gadget) dengan fitur OS tertentu, misalnya LD_LIBRARY_PATH di berbagai OS sejenis Unix (misalnya Linux), atau injeksi dylib di iOS/macOS. Intinya kita mengubah program atau lingkungan program agar library Frida diload sebelum program berjalan.
  • Injeksi program yang sudah berjalan menggunakan ptrace atau API sejenis. Injeksi bisa dilakukan secara langsung atau menggunakan frida-server.

Injeksi ke proses menggunakan API ptrace hanya bisa dilakukan jika kita memiliki permission untuk melakukan debugging pada proses tersebut (di iOS kita butuh jailbreak jika ingin memakai cara ini). Program frida-server berguna jika kita ingin mengakses API dari device lain, misalnya di Android yang sudah di-root, kita bisa memakai frida-server untuk melakukan injeksi dan sekaligus menjadi jembatan agar API-nya bisa diakses dari PC.

Saya tidak akan membicarakan dengan detail bagaimana melakukan berbagai langkah di atas, karena tiap OS butuh penjelasan yang detail. Contoh di iOS (tanpa jailbreak) kita harus mengekstrak IPA (harus unencrypted), mengcopy library, mengedit load command di binary utama, menandatangani file IPA. Masing-masing langkah butuh penjelasan yang tidak singkat. Intinya adalah: kita harus bisa membuat Frida berjalan di aplikasi target.

Setelah bisa berjalan di address space target, Frida akan menulis ulang implementasi assembly fungsi yang kita intercept supaya melakukan jump ke library frida yang sudah ada di address space proses tersebut. Di sini ada magic yang dilakukan Frida: frida akan melakukan tracing statik untuk mengetahui di mana saja titik keluar fungsi dan membuat hook juga di situ untuk onLeave.

Frida kemudian akan bisa memanggil kode Javascript yang kita tulis. Ada dua opsi engine Javascript yang bisa dipakai: V8 dan Duktape, secara umum V8 lebih cepat, tapi butuh lebih banyak memori, dan duktape sebaliknya: lebih lambat tapi hemat memori. Ketika melakukan detach, frida akan mengembalikan kode yang diubah kembali seperti semula.

Modul Frida

Jika melihat halaman release frida, akan ada banyak sekali file yang bisa didownload. Ini mungkin akan sangat membingungkan buat pemula, jadi akan saya jelaskan secara singkat berbagai file yang bisa didownload di situ.

Frida tertarget sangat spesifik untuk sistem operasi tertentu, jadi ada banyak rilis Berdasarkan sistem operasi (android, ios, windows, dsb). Frida juga perlu dicompile spesifik untuk arsitektur CPU tertentu, jadi ada banyak arsitektur CPU: x86-64, arm, arm64, dsb. Jadi pertama kita bisa menyaring untuk OS dan CPU mana yang ingin kita pakai.

Frida dipisahkan menjadi banyak modul:

  • Kita bisa menginjeksikan kode langsung dengan memanggil API Frida dalam C. Jika ingin melakukan ini downloadlah frida-core-devkit
  • Jika kita ingin memakai frida di aplikasi yang ada source codenya, kita bisa mendownload frida-gum-devkit atau frida-gumjs-devkit
  • Jika kita ingin menginjeksi satu proses saja di iOS/Android, kita bisa memakai frida-inject
  • Jika kita ingin menginjeksi berbagai proses mengaksesnya dari device lain (misalnya injeksi Android/iOS dan akses API-nya dari PC) kita bisa memakai frida-server
  • Jika kita ingin manual memasukkan library dengan LD_LIBRARY_PATH atau dylib injection, kita bisa memakai frida-gadget

Selain kode di atas, ada beberapa API bindings untuk berbagai bahasa: Python, nodejs, Java, QML (Qt), Swift, dan .NET. Untuk pemula: sebaiknya gunakan Python saja, ada banyak contohnya, sedangkan untuk bahasa lain masih minim.

Secara praktis, berikut ini yang perlu dilakukan untuk pemula:

  • Di desktop: “pip install frida frida-tools” ini sudah cukup untuk debugging aplikasi lokal di desktop
  • Di Android: sebaiknya root HP Anda, lalu gunakan frida-server
  • Di iOS (karena Jailbreak semakin sulit): gunakan frida-gadget

Penutup

Sudah ada banyak sekali contoh penggunaan Frida di berbagai situs lain, misalnya untuk: disable certificate pinning, mendapatkan key enkripsi, bypass jailbreak check, dsb. Jadi silahkan dicari sendiri sesuai kebutuhan. Di Artikel lain saya akan membahas beberapa trik yang saya pelajari setelah cukup lama memakai Frida.

Menurut saya Frida merupakan tools yang sangat powerful yang bisa membantu banyak task reverse engineering. Tahun lalu saya banyak menyelesaikan Flare-On dengan Frida. Bahkan saya juga memakai Frida ini untuk debugging secara umum di aplikasi saya yang ditulis dalam C/C++.

Meskipun demikian Frida juga memiliki berbagai masalah: dokumentasi Frida cukup terbatas dan sering kali saya harus membaca source codenya untuk memahami berbagai hal. Selain itu Frida juga masih terus diupdate, sering kali versi baru membawa banyak fitur baru, tapi seringkali juga membuat error baru. Tadinya saya ingin membuat contoh yang lebih sederhana, tapi terkena error ini (saat artikel ini ditulis: belum ada solusinya).

Saran saya: cobalah memakai Frida. Tools ini masih terus dikembangkan secara aktif. Frida juga cross platform, jadi toolsnya akan terpakai di banyak tempat tidak seperti tools spesifik OS tertentu (misalnya WinDBG yang hanya untuk Windows).

Biaya Reverse Engineering

Saya pernah menuliskan mengenai mahalnya membuat aplikasi mobile. Saya juga pernah menulis mengenai ransomware dan RE dan betapa sulitnya hal tersebut. Tapi sepertinya banyak yang belum paham bahwa RE juga mahal (untuk yang tidak tahu apa itu RE, silakan baca FAQ berbahasa Indonesia di sini). Ini untuk menjawab berbagai pertanyaan orang yang ini minta bantuan untuk: Reverse engineering game, reverse engineering malware/ransomware, cracking software tertentu, dan segala macam bantuan yang berhubungan dengan reverse engineering.

Jumlah orang yang bisa melakukan reverse engineering di dunia ini tidak banyak. Sesuai hukum supply dan demand: karena yang bisa melakukan RE relatif sedikit maka harga jasanya jadi mahal. Reverse engineering juga butuh waktu cukup lama. Jangan bayangkan RE ini sekedar membuka IDA Pro atau tool sejenis dan langsung bisa menemukan di mana harus patch sesuatu atau menemukan algoritma tertentu.

Coba minta seorang programmer membaca kode program di github dan minta dia memodifikasi sesuatu. Berapa banyak yang langsung bisa memahami isi sebuah program yang lumayan kompleks? Banyak programmer bahkan sudah menyerah duluan karena tidak bisa mengcompile programnya. Reverse engineering kode biner akan butuh waktu jauh lebih lama dari membaca source code yang lengkap ada komentar dan dokumentasinya.

Harga jasa RE juga akan lebih mahal jika program memiliki proteksi kompleks. Jika harga sebuah software hanya puluhan hingga ratusan USD: masih lebih murah membeli software tersebut daripada membayar orang untuk mengcracknya. Ditambah lagi tiap versi proteksinya bisa diperbarui oleh pembuat programnya.

Dalam kasus malware dan ransomware : jarang sekali malware yang tidak diproteksi, jadi proses reversingnya tidak sebentar. Belum lagi ada banyak sekali varian ransomware yang masing-masing versinya sudah berbeda sama sekali. FireEye dulu menyediakan jasa decrypt ransomware, tapi kemudian terlalu banyak varian yang ada, jadi mereka sudah tidak mau lagi menghabiskan sumber daya untuk ini:

If your computer has recently been infected with ransomware, chances are that the infection has been caused by one of the many copycat attacks that use the same or similar name and method of operation. Since these new ransomware variants use different encryption keys, we have discontinued the DecryptCryptoLocker website and its associated decryption service.

https://www.fireeye.com/blog/executive-perspective/2014/08/your-locker-of-information-for-cryptolocker-decryption.html

Saat ini saya tidak tertarik untuk mereverse engineer ransomware, apalagi jika diminta tolong secara gratis. Analisis malware butuh waktu minimal beberapa jam dan bisa sampai berhari-hari. Meskipun jika sedang tidak ada proyek lain, saya lebih senang menghabiskan waktu ini bersama keluarga. Saya sudah menulis lebih banyak mengenai ransomware di posting ini.

Orang yang ahli dan terbukti bisa melakukan RE biasanya sudah punya pekerjaan. Ada banyak jalan untuk menghasilkan uang dari skill RE, baik jalan legal, ilegal, atau yang di tengah-tengah. Orang-orang yang sudah mendapatkan banyak uang dari aktivitas-aktivitas tersebut biasanya akan malas menerima pekerjaan baru.

Melakukan RE pada aplikasi tertentu secara rutin biasanya akan lebih mudah. Kode program biasanya tidak berubah drastis dari satu versi ke berikut, jadi jangan heran juga jika seseorang lebih memilih melakukan pekerjaan RE yang rutin daripada menerima proyek yang sesekali datang.

Pekerjaan RE Legal

Pekerjaan RE legal biasanya di bidang software security (walau tidak selalu). Ada beberapa pekerjaan yang berhubungan dengan RE:

  • Reversing malware. Kerjanya membongkar berbagai malware/virus baru tiap hari
  • Mencari bug di software dan membuat exploit untuk software tersebut
  • Mencari bug di hardware dan membuat eksploit untuk hardware tersebut
  • Memberikan training. Banyak perusahaan mulai memperhatikan masalah security, jadi para engineer diharapkan bisa membongkar sendiri hasil kerja mereka apakah aman atau tidak
  • Pentesting aplikasi (baik resmi ataupun untuk bug bounty)
  • Rekonstruksi program berdasarkan program lama yang source codenya hilang

Saat ini kebanyakan pekerjaan legal seperti ini didapatkan dari luar Indonesia karena belum terlalu banyak riset security tingkat lanjut di Indonesia. Negara paling dekat yang membutuhkan banyak reverse engineer adalah Singapura.

Ada juga jalan legal unik yang dilakukan oleh Jane Wong. Dia melakukan RE berbagai aplikasi mobile untuk mengetahui fitur apa yang belum dirilis. Dalam artikel tersebut dituliskan bahwa dia menghabiskan 18 jam sehari untuk melakukan reverse engineering berbagai aplikasi.

Dengan jalan legal, gaji yang didapatkan bisa cukup banyak. Semakin tinggi skillnya, makin besar yang bisa didapatkan. Gaji terendah sudah setara dengan gaji programmer level menengah. Untuk kasus yang sangat ekstreem: jika sudah sangat jago RE, maka bisa menemukan dan membuat eksploit zero day yang harga per eksploitnya puluhan ribu hingga ratusan ribu USD. Bahkan exploit untuk iOS bisa dihargai hingga 1 juta USD.

Pekerjaan RE ilegal

Bagaimana dengan yang ilegal? Ada banyak hal ilegal yang bisa dilakukan, misalnya:

  • Cracking aplikasi (menghilangkan proteksi tertentu)
  • Hacking game (modifikasi game)
  • Hacking aplikasi (mengubah/menambah fungsionalitas tertentu, misalnya aplikasi Go-Jek)

Apakah bisnis ilegal ini menghasilkan uang banyak? jawabannya: iya, banyak sekali uangnya. Baru-baru ini Niantic (pembuat Pokemon Go) menuntut group Hacker yang membuat mod IPA game Pokemon Go dan Wizards Unite. Dalam tuntutannya disebutkan bahwa para hacker ini menggunakan Patreon di mana para pengguna bisa membayar biaya bulanan untuk mendapatkan modnya. Para pengguna harus membayar minimum 5 USD per bulan, dan jumlah total pengguna sudah lebih dari 10 ribu orang. Artinya mereka mendapatkan minimum 50 ribu USD per bulan.

Pokemon Go bukan satu-satunya game yang dicurangi hacker, masih ada banyak contoh game yang lain, hanya saja yang lain lebih susah dilacak karena memakai cryptocoin dan memakai group yang tertutup. Biasanya proses mencurangi game bukan sekedar membaca kode, tapi juga menulis kode baru. Contoh game lain juga masih banyak, misalnya ada hacker yang didenda 5.1 juta dollar karena hacking PUBG dan mencuri informasi user. Bahkan tanpa RE pun, cheating di berbagai game ini imbalannya sangat menjanjikan, misalnya ada contoh kisah bagaimana seorang remaja 16 tahun mendapatkan 200 ribu USD dari hacking game.

Di dalam negeri Indonesia ada juga mereka yang memodifikasi APK Gojek dan Grab (contoh berita: Grab rugi 6 milyar dari order fiktif). Saya tidak tahu berapa jumlah pengguna yang memakai APK yang dimodifikasi ini, tapi dari pengamatan saya di berbagai forum internet, jumlahnya setidaknya ribuan orang. Saat ini ada lebih dari 2 juta driver Go-jek, jadi mungkin perkiraan saya itu terlalu rendah, mungkin ada puluhan ribu orang yang memakai APK yang dimodifikasi. Uang bulanan untuk mendapatkan APK antara puluhan sampai ratusan ribu rupiah. Jadi para hacker ini mendapatkan setidaknya puluhan juta rupiah per bulan.

Di Singapore, Aplikasi Grab dan GO-JEK juga dihack dengan tarif 200-350 SGD/bulan. Andaikan bagian RE mendapatkan 10% saja (20-35 USD per driver), dari 100 driver bisa didapatkan 2000-3500 SGD (20-35 juta rupiah per bulan). Angka tersebut merupakan perkiraan yang sangat rendah, baik dari share untuk RE (bisa 25% atau lebih), maupun jumlah usernya (bisa ribuan).

Dengan banyaknya kesempatan mendapatkan uang dari RE ilegal, jangan heran jika tidak banyak yang mau membantu Anda mengcrack software (meskipun Anda berani membayar). Kemungkinan sudah ada pekerjaan ilegal lain yang hasilnya lebih besar dan lebih teratur.

Pekerjaan RE abu-abu

Lalu bagaimana dengan yang abu-abu? contohnya adalah reverse engineering aplikasi untuk mendapatkan API-nya, reverse engineering hardware untuk membuat clonenya atau membuat aksesori tambahan. Di beberapa negara ini ilegal, di tempat lain bisa dianggap legal karena bertujuan untuk interoperabilitas.

Contoh hal lain yang abu-abu adalah membongkar skrip trading untuk mengetahui strategi apa yang dipakai seseorang. Selama strateginya tidak dicopy dan disebarkan umum, ini sulit dituntut karena tujuannya hanya untuk mempelajari sesuatu.

Penutup

Seperti saran saya di tulisan mengenai aplikasi mobile: jika Anda merasa memakai jasa orang lain terlalu mahal, cobalah belajar sendiri RE. Sering kali orang merasa sesuatu terlalu mahal, tapi tidak mau juga belajar sendiri.

Saya sendiri jarang sekali menerima pekerjaan RE ekstra dari yang sudah saya lakukan sehari-hari. Jika ditanya siapa kenalan yang bisa melakukan RE, saya juga sering bingung karena mereka masing-masing juga sudah penuh dengan pekerjaan legal/ilegal/abu-abu.

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.

Update November 2019: Dengan exploit checkm8 (misalnya https://checkra.in/), kita bisa menjailbreak semua device iOS yang tidak memakai SOC A12 ke atas. Artinya semua iPhone sampai iPhone X bisa dijailbreak.

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/12) 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 tidak bisa diakali dengan memakai beberapa Apple ID. Jika device tidak dijailbreak, 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 tapi sekarang Apple juga mendukung bahasa Swift. Objective-C masih merupakan bahasa utama yang dipakai di seluruh sistem operasi, sama seperti Java di Android. Seluruh API utama masih menggunakan Objective C.

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).