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.

Merakit dan Mengupgrade PC

Kebanyakan teman seangkatan saya sudah jarang yang merakit PC. Bahkan kalau dipikir-pikir yang memakai PC (di rumah, bukan di kantor) juga semakin sedikit, kebanyakan hanya punya laptop saja. Saya sendiri sampai saat ini merasa lebih nyaman bekerja di PC yang cepat dengan layar besar dan keyboard mekanis.

Sekarang saya memesan berbagai komponen PC dari jib.co.th atau kadang beli offline jika kebetulan barang yang hendak dibeli tersedia di toko JIB di Airport Plaza. Jika membeli online prosesnya sangat mudah dan cepat. Setelah selesai membayar, barang akan segera dipack, dan saya akan dikirimi URL video pengepakannya. Sayangnya karena jauh dari Bangkok, jadi tetap butuh 2 hari sampai barangnya diterima di Chiang Mai.

Sebenarnya saya mulai malas membongkar PC, memasang komponen baru, mengetes, setting BIOS, memindahkan sistem operasi dsb, tapi saya lebih malas lagi dengan berbagai alternatifnya. Beberapa alternatifnya adalah:

  • membawa semua ke toko, memberi instruksi dan menunggu sampai semua selesai, pulang ke rumah (capek, tetap harus memasang ulang kabel), perlu memberi tahu password ke teknisi (atau membantu mengisi password setiap kali dibutuhkan)
  • membeli komputer baru yang lebih baik (tetap harus memindahkan data/program ke komputer baru)
  • mendatangkan teknisi: saya nggak akan sabar memberi tahu apa yang harus dilakukan, memberi tahu password, dsb

Jadi meskipun saya kurang suka, merakit dan mengupgrade PC tetap saya lakukan sendiri. Contoh beberapa hal yang menyebalkan ketika merakit PC:

  • memasang CPU cooler
  • memasang kabel untuk power/reset/LED HDD/Power, ribet karena kecil
  • mengatur kabel. padahal saya sudah memakai PSU dengan kabel modular
  • memasang backplate. Tapi sekarang tidak lagi, karena sebel sering menyakiti tangan, saya putuskan untuk tidak memasang benda ini. Memang berisiko menambah debu yang masuk, tapi saya lebih memilih membersihkan debu daripada memasang benda ini
Backplate, nggak pernah saya pasang lagi

Sekarang mau cerita konfigurasi desktop saat ini:

  • Casing Chaser MK I (saya beli tahun 2013)
  • Storage M2.NVME 1 TB untuk Windows
  • CPU Intel Core i5 9400F 2.9 GHz (terpikir membeli Core i9, tapi perbedaan performancenya kurang signifikan untuk use case saya)
  • Banyak harddisk
  • Ram DDR4 32 GB

Alasannya cukup panjang, tapi sekarang saya memakai Desktop Windows dan sebuah server Linux. Keduanya saya pakai bekerja. Meskipun rasanya agak ekstrim bekerja dengan dua komputer, tapi menurut saya ini workflow paling enak. Desktop dipakai untuk pekerjaan interaktif, dan Linux dipakai untuk berbagai server (samba, mongo, mysql, http, dsb) dan untuk kompilasi yang memakan waktu lama (compile kernel, compile ROM Android).

Spesifikasi server sekarang:

  • Casing nggak jelas beli second hand
  • SSD 1 TB untuk Linux
  • CPU: AMD Ryzen 5 2600X Six-Core Processor
  • RAM DDR4 16 GB
  • Banyak harddisk

Pemilihan berbagai komponen saya dasarkan pada pengukuran: dengan melihat task manager (windows) dan top (Linux). Dengan memperhatikan tool, umumnya kita bisa melihat apakah kita butuh lebih banyak memori (free memori selalu rendah atau pemakaian swap tinggi), butuh CPU yang lebih baik (CPU usage selalu tinggi), atau butuh SSD/NVME (nilai “wa” di top tinggi, atau akses disk tinggi di task manager).

Untuk CPU saya mendasarkan pemilihan pada benchmark dari http://cpubenchmark.net/ . Pertimbangan lain adalah harga, saya tidak mau menghabiskan uang 2X lipat jika performance yang didapatkan hanya bertambah sedikit (lebih baik menunggu sampai harga turun).

Perlu diperhatikan juga program spesifik yang kita pakai, contohnya IDA Pro butuh waktu lama untuk mendecompile fungi kompleks, tapi proses dekompilasi ini tidak multi thread, dan juga tidak memakai 100% CPU. Jadi memakai CPU yang 2x lebih cepat sama sekali tidak membantu mempercepat proses dekompilasi.

Sekedar tips, jika ingin merakit PC dan ingin melakukannya jangka panjang, maka:

  • belilah casing yang bagus, akan tahan lama
  • belilah PSU yang bagus dan modular, walau kabel tetap berantakan tapi sedikit lebih baik
  • belilah keyboard yang bagus (kalau suka mekanis, beli yang mekanis) karena akan tahan lama

Demikian cerita singkat ngalor-ngidul mengenai merakit dan mengupdate PC. Berikutnya saya perlu menambah storage di Thinkpad X230 saya.

Insiden Google Play: CC Niaga dicharge 100x lipat

Cerita ini tentang kejadian yang saya alami dua hari lalu: membeli koin game seharga 5 ribu rupiah di Google Play tapi tercharge 500 ribu rupiah di CC Niaga (5 transaksi, jadi 2.5 juta rupiah). Masalahnya bisa diselesaikan setelah menelpon dan juga membatalkan transaksi dari Google Play. Nah sekarang cerita lengkapnya.

Saya cukup jarang membeli koin game dari Google Play. Pernah membeli agak banyak karena pernah dapet voucher Google Play, tapi dalam kasus tersebut tidak ada masalah, karena tidak terhubung ke kartu kredit. Koin yang saya beli adalah untuk game Pokemon Go dari perusahaan Niantic.

Niantic memiliki sistem pricing yang aneh: akan lebih murah membeli 100 koin berkali-kali dibandingkan langsung mengeluarkan uang banyak. Perhatikan gambar ini:

  • 100 Pokecoin 5 ribu rupiah
  • 550 Pokecoin 75 ribu rupiah

Sedangkan jika saya membeli 100 pokecoin x 6 = 600 pokecoin, dengan hanya 5 rb x 6 = 30 ribu rupiah. Ini saya jelaskan supaya bisa dimengerti alasan kenapa saya perlu membeli berkali-kali. Saya memilih menggunakan account indonesia, karena dengan account Thailand, harga koin menjadi hampir 2x lipat (harga 100 pokeoin 5000 rupiah menjadi 20 baht atau 9200 rupiah).

Perhatikan juga: tidak ada item yang harganya tepat 500 ribu rupiah, ada yang lebih dan ada yang kurang, tapi tidak ada yang tepat 500 ribu rupiah. Yang paling dekat adalah 589 ribu, dan di bawahnya 299 ribu. Jadi tidak mungkin saya salah beli/salah tekan yang hasilnya 500 ribu rupiah.

Saya berencana membeli 14 kali (1400 koin), totalnya seharusnya 70 ribu rupiah. Pembelian pertama sampai kelima berhasil, tapi ketika yang keenam saya dapat pesan: kartu ditolak. Saya pikir: hmm mungkin ada fraud detection. Mungkin karena ada banyak pembelian berulang dalam waktu singkat, jadi kartunya ditolak.

Saya teringat lagi bahwa saya masih punya pulsa XL karena dulu pernah dapat dari menemukan bug di situs isi pulsa (bug sudah dilaporkan dan dapat reward). Dan ternyata dengan account Google Indonesia saya bisa membeli memakai pulsa XL. Dan saya teruskan pembeliannya dengan XL, 9 pembelian berikutnya berhasil.

Saya mendapat notifikasi (14 email) dari Google via email. Semua sesuai yang diharapkan. Perhatikan: 100 koin dengan harga 5000 rupiah. Total 5000 rupiah.

Tapi beberapa jam kemudian saya dapat SMS Horror. Saya bukan dicharge 5 ribu rupiah, tapi 500 ribu rupiah, per transaksi. Meski hanya ada 3 SMS, tapi CS niaga memastikan bahwa jumlah transaksinya 5, bukan 3.

Sejujurnya, walau sering dapat SMS notifikasi tapi sering kali tidak saya perhatikan seksama karena biasanya bank selalu benar. Asalkan saya merasa memang melakukan transaksi, ya notifikasinya pasti benar. Tapi untungnya kali ini saya perhatikan dengan seksama jumlah nolnya.

Pikiran pertama saya adalah: mungkin sistem notifikasinya salah. Saya cek saldo kartu kredit online: benar, semua limit kartu kredit saya habis. Untungnya limit kartu saya ini sangat rendah (< 3 juta rupiah), kartu ini lebih sering saya pakai untuk pentesting.

Berikutnya: saya telepon ke Niaga. Tips: lihat SMS dengan seksama, ada nomornya di situ. Saya sempat mencoba +622114041 (yang tercantum di web niaga) tapi selalu gagal. Konyolnya, saya sempat salah tekan bukan 14041, tapi 14045 dan nyasar ke McD.

  • Memakai 006/001, dia langsung +622114041 tidak bisa dari Thailand
  • Memakai Skype bisa, tapi ketika mulai berbicara dengan CS, tiba-tiba audionya beralih ke call orang lain (sepertinya bug Skype, saya coba 2x hasilnya sama)

Saya menghubungi CS karena ingin benar-benar yakin bahwa transaksinya 500 ribu rupiah, dan bukan kesalahan di sistem notifikasi dan web CIMB Niaga. Jawaban CS adalah: benar transaksinya sebesar itu, coba kirim bukti-bukti ke [email protected]

Sebelum mengirimkan bukti, saya segera terpikir untuk segera membatalkan transaksi di Google Play. Sayangnya di Google Play opsi alasan yang ada hanya sangat sedikit. Sebenarnya tidak ada alasan yang cocok dengan masalah saya. Tidak ada cara mudah menghubungi Google, jadi saya pilih alasan apa saja. Empat transaksi pertama berhasil dibatalkan, tapi yang kelima gagal.

Akhirnya saya kirim bukti-bukti ke Niaga dan segera dibalas dengan meminta nomor kartu saya. Sebenarnya saya merasa kurang nyaman dan aman mengirimkan nomor CC via email (karena pada dasarnya email itu tidak aman), tapi karena limitnya sangat rendah, ya sudah lah.

Hari ini saya belum mendapat kabar resmi dari Niaga (katanya memang akan dihubungi dalam 3 hari, jadi masih wajar). Tadi saya cek online semua saldo kartu kredit sudah kembali normal, jadi saya putuskan untuk menuliskan ceritanya. Sampai saat ini saya tidak tahu salah siapa ini, dan apakah banyak yang terpengaruh. Kalau Anda belum lama ini berbelanja di Google Play dengan kartu kredit, coba cek tagihannya.

Penutup

Siapa saja bisa menjadi korban “sial” sistem komputer. Setiap sistem bisa bermasalah, atau dalam kasus saya dua sistem yang berhubungan bisa memiliki bug. Sekarang saya selalu berusaha memiliki backup untuk berbagai hal yang sifatnya terkomputerisasi, misalnya:

  • memiliki dua rekening bank, masing-masing memiliki kartu ATM
  • memiliki dua nomor telepon (dan tetap memelihara nomor Indonesia andaikan ada masalah)
  • memiliki backup di cloud provider terpisah

Saya bersyukur karena banyak hal:

  • Masalahnya bisa diselesaikan dengan cepat
  • Kartu yang saya pakai memiliki limit yang rendah sehingga gagal di transaksi ke-5. Andaikan limitnya tinggi, saya akan tercharge 7 juta rupiah.
  • Tidak sedang butuh memakai kartunya segera

Bisa dibayangkan betapa sedihnya kalau gara-gara game, kartu terblokir, lalu butuh itu untuk membayar tagihan penting.

Tulisan ini sekaligus juga sebagai pengingat: periksalah berbagai SMS dan Email notifikasi yang masuk dari Bank.

Cerita hacking dari masa lalu

Sebagian teman angkatan di Informatika ITB tahu kalau saya dan Deny dulu hampir di-DO karena “ngehack” kampus, tapi cerita detailnya belum pernah saya tuliskan. Nah kali ini dengan persetujuan dan encouragement dari Deny, Tintin, dan Okta saya akan tuliskan ceritanya. Karena ini cerita lama (lebih dari 20 tahun yang lalu), saya akan banyak memberikan latar belakang cerita.

Cerita ini sudah sangat lama, sebagian detail sangat saya ingat, tapi sebagian lagi benar-benar lupa. Ketika bertanya ke Tintin dan Deny mereka juga banyak lupa detailnya, jadi saya ceritakan saja di sini sekarang sebelum tambah lupa lagi.

Kenalan dengan Hacker

Saya awali dulu dengan cerita ketemu Deny. Sekedar background: kok bisa ketemu dengan orang lain yang suka ngehack?

Saya ketemu Deny kali pertama waktu kuliah di Informatika ITB, tahun 1998. Di ITB tingkat 1 adalah Tahap Persiapan Bersama, di tahun pertama semua jurusan pelajarannya sama yaitu ilmu-ilmu dasar dengan tujuan agar ilmunya seragam di tingkat berikutnya. Pelajaran yang diberikan misalnya: Fisika, Kimia, Matematika (Kalkulus), Bahasa Inggris, dan bahkan ada juga pelajaran Olah Raga.

ITB

Nah saya jadi ngobrol dengan Deny karena waktu itu saya membawa buku komputer. Kalau tidak salah ingat judul bukunya: Meningkatkan Dayaguna Komputer dengan Turbo Pascal karangan Busono. Buku ini mengajarkan cara mengakses hardware komputer secara low level (serial port, parallel port, dsb) dengan Turbo Pascal.

Perlu dicatat bahwa saat itu (nggak tau sekarang) banyak yang masuk Informatika ITB tapi pengetahuannya mengenai komputer sangat dasar sekali. Informatika ITB dipilih banyak orang karena passing grade-nya waktu itu adalah yang tertinggi. Jadi saya senang ketemu dengan seseorang yang bisa ngobrol programming selagi programming belum diajarkan di kelas.

Meski belum diajarkan programming, HMIF (Himpunan Mahasiswa Informatika) ITB memberikan pelatihan dasar Linux pada seluruh mahasiswa baru setelah selesai masa OSPEK. Pelajarannya sangat dasar: bagaimana mengakses Linux, mengakses email, membuat file, mengedit dengan vi, dsb.

Di pelatihan itu (Agustus 1998) kali pertama saya dan Deny belajar mengenai Linux. Sebelumnya kami cuma memakai DOS dan Windows. Setelah masa pelatihan selesai, mahasiswa (tingkat manapun, termasuk tingkat 1) boleh bebas mengakses lab ketika tidak ada praktikum. Bahkan kadang diperbolehkan juga pada jam praktikum kalau kenal dengan asistennya, selama masih ada komputer kosong di belakang dan tidak mengganggu sesi praktikum.

Lab

Di semua waktu luang tingkat 1, saya dan Deny menghabiskan sebagian besar waktu ngoprek di Lab. Waktu itu belum ada Google (tepatnya lagi baru September 1998 Google didirikan, itupun tidak langsung populer), jadi sumber utama ilmu kami adalah:

  • Majalah Phrack
  • Halaman manual (man page), bahkan saya pernah memprint banyak sekali manual page “perl” untuk dibaca di kost
  • Mailing list (misalnya bugtraq)
  • Beberapa website dan e-Zine

Entah kenapa saya dan Deny tidak tertarik sama sekali untuk join dengan berbagai “group hacker” seperti hackerlink, kecoak elektronik, dsb. Tapi saya dapat cerita dari teman kami Tintin (sekelas/seangkatan juga), bahwa group yang ada itu ya cuma bisa compile exploit dari Packet Storm, dan bahkan kadang mereka bingung kalau ketemu error waktu compile.

Waktu tahun kami masuk, kondisi mesin di lab sedang cukup parah. Baru dua tahun setelah itu ada dana baru sehingga mesinnya diupgrade secara signifikan. Dulu sudah jaman Pentium tapi mesin di lab masih 486 DX dan keyboardnya banyak yang mulai error. Mesinnya bisa dual boot: network boot ke Linux (diskless, memakai NFS) dan ke Novell Netware. Dari Netware kita bisa telnet ke salah satu server yang bisa diakses mahasiswa (Puntang/x86 dan kerinci/Sparc).

Sebagai catatan: di berbagai jurusan lain (misalnya Teknik Elektro) waktu itu yang banyak dipakai adalah BSD (biasanya FreeBSD), tapi di jurusan Informatika yang banyak dipakai adalah Linux dari awal. Dari setup yang dilakukan, bisa dilihat bahwa adminnya (mas Budi Aprianto mahasiswa yang dipandu oleh dosen, Pak Riza Satria Perdana ) sangat capable dan sudah mensetup sistemnya dengan baik:

  • Network boot dengan PXE waktu itu belum umum, harus burn EPROM di Network Card
  • Diskless boot juga tidak terlalu umum. Server NFS-nya memakai Solaris di server dengan CPU SPARC

Awalnya rasanya aneh memakai Linux, beberapa ilmu DOS seperti TSR, mengakses layar secara langsung atau memakai Library “<conio.h>” untuk mewarnai layar tidak berlaku di Linux. Tapi saya dan Deny cukup rajin belajar mengimplementasikan banyak hal, dari network programming (bikin port scanner dengan full TCP connect), sampai termasuk juga yang berhubungan dengan security.

Di tahun 1998 sebenarnya mekanisme shadow password sudah disupport di Linux, tapi entah kenapa belum diimplementasikan di distribusi yang kami pakai. Salah satu “hack” pertama yang kami lakukan adalah membuat program untuk membrute force password seseorang. Waktu itu password requirement belum diterapkan, jadi passwordnya masih relatif gampang ditebak.

Seperti yang saya jelaskan: kondisi lab waktu itu cukup parah, banyak keyboard yang error, kadang menekan 1 huruf tapi hurufnya tertekan 2 kali atau malah tidak tertekan. Ini biasanya jadi masalah ketika mengganti password (ada kelebihan/kekurangan huruf). Daripada selalu merepotkan admin, waktu itu kami membantu teman yang lupa password dengan mencoba-coba otomatis menambah dan mengurangi karakter dari password terakhir yang diingat.

Perpustakaan

Lab di Informatika ITB tutup di sore hari (lupa jam 4 atau 5), tapi ada rental Internet di perpustakaan ITB yang tutup sampai jam 7 malam. Jika saya belum ingin pulang (toh di kost nggak banyak yang bisa dikerjakan) saya akan menghabiskan uang untuk nongkrong di rental internet perpustakaan (memakai Windows 97).

Perpustakaan ITB

Akses internet di perpustakaan ITB adalah per 30 menit: bayar dulu, komputer tertentu akan diaktifkan, dan jika waktu habis koneksi akan dimatikan otomatis. Tapi lama-lama kan mahal, jadi saya mempelajari bagaimana prosesnya sejak memberi uang, dapat akses internet, sampai aksesnya dimatikan lagi.

Ternyata operator akan melakukan telnet ke sebuah server dan dari situ ada skrip untuk membuka akses internet. Saya perhatikan juga bahwa ada admin yang suka memakai salah satu komputer di dalam ruangan rental.

Saya menulis sendiri keylogger yang memakai API windows. Tepatnya sebenarnya bukan keylogger karena tidak mencatat semua tombol, tapi hanya akan mencari semua single line textbox dan password textbox dan melog teks serta passwordnya ke file. Di Windows lama (95 sampai ME) ini sangat mudah, kita cukup mengenumerasi handle Window dan mengirimkan WM_GETTEXT (waktu itu tidak ada sistem permission di Windows). Dengan teknik tersebut, segala macam password yang sudah tersimpan juga bisa didapatkan passwordnya (tidak hanya yang diketik manual).

Saya hanya memasang logger di komputer yang saya tahu dipakai admin. Dengan logger itu saya bisa mendapatkan akses internet unlimited di perpustakaan. Supaya tidak mencurigakan biasanya saya akan membayar 30 menit pertama dan hanya meneruskan kalau sepi. Di semester baru, saya baru tahu dari Deny kalau dia bawa logger saya dan dia pakai di warnet di Medan.

Tempat Lain

Lab IF dan Perpustakaan sebenarnya bukan satu-satunya tempat nongkrong. Banyak tempat lain di ITB yang punya lab komputer dan jadi tempat belajar untuk banyak orang, misalnya ada PAU (Pusat Antar Universitas), unit ARC (Amateur Radio Club), berbagai lab di berbagai jurusan.

Masing-masing orang punya kisahnya di tempat mereka, dari mulai kisah teknis seperti kami, sampai ada yang ketemu pasangan di tempat-tempat tersebut. Saya sendiri dulu sempat juga main ke ARC sebentar, tapi karena merasa kurang cocok, jadi lebih sering di lab IF (sementara Deny cukup sering ke ARC).

Root

Saya tidak ingat kapan kami mulai berani mengakses root. Tapi ini terjadi kira-kira akhir tahun (sekitar 3-4 bulan sejak kami belajar Linux). Akses root pertama kami dapatkan dari backdoor di port yang kami temukan dengan port scan. Selain cara itu, waktu itu ada banyak sekali eksploit yang bisa dipakai asalkan kita mencari di Internet (atau melihat mailing list bugtraq).

Sebagai catatan: dari adanya backdoor berarti sudah ada yang lebih dulu dari kami mendapatkan root. Salah satu teman kami, Okta juga dapet root dengan eksploit sendmail.

Salah satu alasan kami mendapatkan root adalah: untuk mengakses internet dari lab IF ITB. Di semester pertama kami cuma dapat akses email. Kami berusaha mencari host yang memiliki akses internet dan/atau username/password proxy yang bisa dipakai.

Berikutnya setelah jadi root di satu host, mau ngapain? Bagian pertama adalah: jadi root di host lain. Kami bisa telnet ke mesin x86 dan Sparc. Di mesin x86 kami sudah punya root, tapi di Sparc kami nggak punya exploit apa-apa. Kami bisa mengakses home dir yang sama (via NFS). Jadi pertama adalah pivoting: mengcopy shell di Sparc ke home directory, lalu di-chmod setuid root dari server x86. Sekarang kami punya akses di kedua server utama. Dari mana dulu tahu ilmu ini? sebenarnya semuanya cuma logika dasar aja. Setelah tahu konsepnya, mengembangkan hal-hal dasar seperti itu tidak sulit.

Keisengan berikutnya muncul: Deny mendownload source code program “login”, lalu menambahkan kode logging agar password disimpan ke file. Executable baru itu dipakai untuk menggantikan program login asli di kedua server. Hasilnya: kami dapat password semua orang.

Sebagai catatan: programming itu sangat perlu untuk seorang hacker. Sekarang ini banyak yang mengaku “hacker”, tapi kalau saya berikan source code saja dan saya minta untuk menambahkan logging kebanyakan tidak bisa.

Meskipun mendapatkan akses ke semua account, kami tidak tertarik membaca email atau file-file orang lain. Segala macam yang kami lakukan waktu itu cuma karena penasaran aja. Kami juga nggak mau mencoba teknik-teknik yang kami anggap nggak butuh skill teknis, contoh yang tidak kami lakukan:

  • Denial Of Service
  • Email bombing
  • Social engineering

Bagian social engineering ini: kami nggak pengen seseorang jadi merasa bersalah jadi korban Social engineering. Tujuan hacking waktu itu adalah: belajar teknis.

Tertangkap

Saya tidak tahu tepatnya apa yang membuat kami tertangkap. Seingat saya kami sudah sangat teliti: tidak memakai home directory sendiri, tapi memakai home directory dua mahasiswa ITB yang diterima tapi pindah keluar negeri. Kalau tidak salah ingat: ada keanehan di sistem dan itu menyebabkan penelusuran yang mendalam di sistem dan malah mengarah ke kami berdua.

Saya ingat waktu itu ada kuliah di salah satu gedung di tengah ITB (lupa tepatnya, antara Oktagon atau TVST), dosennya adalab Bu Putri. Kami sadar ada yang salah, karena di akhir kuliah tiba-tiba beliau memanggil: yang namanya Yohanes Nugroho mana ya? (saya berdiri), terus “kalau Deny Saputra?” (Deny berdiri). Terus udah: “silakan duduk, cuma pengen tahu yang mana sih orangnya”. Urutan memanggilnya begitu, karena NIM saya lebih rendah dari Deny.

Selesai kuliah itu saya dan Deny sudah tahu bahwa kami tertangkap. Saya diwawancara oleh Pak Riza Satria Perdana, lalu Deny juga (wawancaranya terpisah). Setelah semuanya selesai, kami diberi tahu bahwa sebenarnya yang kami lakukan itu bisa membuat kami di DO. Tapi Pak Riza mau memberi kesempatan, bahkan akhirnya saya menjadi administrator jaringan Informatika ITB.

Saya sebutkan di atas bahwa Okta juga mendapatkan root, tapi lolos dari interogasi. Kenapa? karena waktu interogasi, saya ditanya itu setuid shell punya siapa? saya bilang “nggak tau, mungkin Deny yang taruh situ”, dan ketika Deny ditanya: “nggak tau, mungkin Yohanes yang taruh di situ”.

Supaya jelas: meskipun kami sering ngehack bareng , bukan berarti tiap hari duduk berdua dan ngobrol berdampingan. Kami hacking terpisah, dan banyak diskusi. Kadang saya dan Deny duduk di lab terpisah dan berbicara dengan software “talk“. Jadi kami nggak tahu 100% apa yang dilakukan yang lain.

Penutup

Sejak kami tertangkap, kami jadinya pelan-pelan meninggalkan dunia security dan lebih fokus ke programming. Memasuki tahun kedua, sudah ada banyak tantangan dari berbagai tugas kuliah yang diberikan, jadi sudah tidak bosan lagi. Tapi masih ada juga sedikit jejak yang saya lakukan di bidang security setelah itu (misalnya ini).

Setelah itu saya banyak terlibat berbagai kegiatan lain, misalnya mengurus TOKI, ikut jadi programmer pengolah data di ITB, ikut proyek dosen, jadi asisten di universitas swasta, memberi les, dsb). Sedangkan Deny mengambil jalan hidup lain (silakan tanya sama Deny buat yang ketemu, nggak akan diceritakan di sini). Okta sekarang jadi expat di Timur Tengah.

Baru tahun 2014 saya mulai terlibat lagi di dunia security. Kerjanya hanya part time pentesting (sampai sekarang masih part time). Part time di sini artinya: dari Senin sampai Jumat saya kerja di perusahaan di Thailand sini menjadi programmer yang tidak ada hubungannya dengan produk security dan cuma di malam hari/weekend saya melakukan pentesting.

Tahun 2016 ikutan ngajak Deny untuk ikutan Flare On dan Pentesting. Ternyata ilmu Deny di bidang RE dan pentesting masih tajam walau tidak pernah khusus pentesting. Contohnya kelakuan hardcorenya ketika mengerjakan RHME (Hardware CTF): reversing statik assembly AVR (bukan kode C hasil decompiler), pake listing HTML dari IDA, di handphone, di kereta pulang sambil berdiri (dan flagnya ketemu).

Kami minta maaf buat yang dulu merasa kesal dengan kelakuan kami. Kami juga mengucapkan terima kasih untuk Pak Riza dan para dosen lain yang masih memberi kesempatan pada kami untuk bertobat dari kenakalan kami dan bisa meneruskan di ITB.

Setelah lama lulus, dapet cerita dari Tintin, ternyata kelakuan kami dulu sangat menginspirasi dia untuk belajar security. Bahkan Tintin sekarang sudah mengambil S2 security dari Carnegie Mellon University. Syukurlah, ternyata yang kami lakukan nggak sepenuhnya berefek negatif untuk orang lain :).

Kalau dari ingatan Tintin, ada banyak hal iseng lain yang kami lakukan, tapi karena saya nggak ingat, saya tidak ceritakan di sini. Walau mungkin dulu sengaja saya lupakan karena terlalu iseng. Seingat saya sih saya nggak pernah berniat jahat.

Tapi saya harap yang kami lakukan di atas tidak ditiru mentah-mentah. Jangan menghack kampus, sudah ada banyak cara lain yang legal untuk belajar security:

  • Ada bug bounty
  • Ada berbagai CTF
  • Ada berbagai sertifikasi yang bisa diambil

Hal yang patut ditiru adalah:

  • Semangat membaca artikel teknis
  • Semangat mencoba berbagai hal teknis secara umum
  • Semangat belajar programming

Kalau bisa ketemu orang atau kelompok yang membantu bertumbuh akan lebih baik lagi.

Happy Hacking

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

Pinjaman Online Ilegal dan Data Anda

Beberapa waktu yang lalu sempat ada berita tentang pinjaman online (ilegal) yang servernya terbuka dan ternyata di dalamnya ada banyak data lain, termasuk data dari provider seperti Telkomsel, XL, Go-Jek dsb. Saya tidak akan membahas mengenai kasus ini secara spesifik karena informasinya sudah diserahkan ke kominfo dan OJK via Xynexis dan saat ini sedang diproses.

Saya hanya ingin membahas: dari mana pinjaman online ini mendapatkan berbagai data pribadi. Data yang saya maksud contohnya data telkomsel ( berapa sisa saldo, kapan terakhir kali mengisi), gojek ( data perjalanan yang pernah dilakukan), dan berbagai layanan lain.

Jawabannya sangat sederhana: dari user itu sendiri secara sukarela. Loh kok ada yang mau memberikan data secara sukarela? karena ada rewardnya. Dalam kasus pinjaman online: jika user bersedia login ke layanan tertentu, maka limit pinjamannya akan dinaikkan.

Perlu diketahui ada beberapa perusahaan (setahu saya semuanya dari China) yang menyediakan SDK (software development kit) untuk memudahkan mendapatkan data dari user Jadi sebuah perusahaan pinjaman tidak perlu repot-repot mempelajari bagaimana protokol Go-jek atau Telkomsel, cukup install SDK tersebut maka aplikasi bisa menerima data dari pengguna.

Contoh penggunaan SDK

Sumber data yang bisa diminta sangat banyak, ini contohnya dari satu perusahaan saja bisa menyediakan ini semua. Masih ada juga beberapa perusahaan yang menyediakan sumber data lain, misalnya BPJS.

Tentunya pihak ketiga tersebut juga bisa menyimpan data untuk tiap orang yang datanya diambil. Jadi jangan kaget kalau data yang tidak pernah diinput di satu aplikasi bisa didapatkan oleh aplikasi lain.

Dengan data ekstra ini para pemberi pinjaman online akan bisa melakukan banyak hal, misalnya:

  • melakukan profiling apakah seseorang punya risiko tinggi untuk kabur
  • mengetahui semua alamat pengiriman belanja online
  • memberi tahu debt collector untuk menunggu Anda di tempat yang biasa Anda datangi dengan Gojek

Penutup

Saya menyarankan: jangan pakai jasa peminjaman online. Alasan utamanya: bunganya sangat tinggi. Untuk yang ilegal, ada banyak masalah:

  • Mereka kadang menggunakan cara kasar untuk penagihan
  • Data pribadi Anda bisa bocor ke mana-mana (dengan sengaja oleh mereka)
  • Mereka tidak menginvestasikan uang untuk keamanan server, jadi data Anda bisa tersebar ke mana-mana karena server mereka dijebol orang lain (atau bahkan kadang terbuka di Internet)
  • Anda juga membocorkan data orang lain (data orang-orang di phonebook Anda)

Kalau bisa sih, jangan miskin supaya tidak butuh pinjaman, tapi tentunya ini sulit.

Sumber dari Video: Lessons from the longest study on human development | Helen Pearson

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.

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. 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, 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 mengcrack software untuk Anda (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.