Trik Reverse Engineering Kode Python

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

Artikel ini hanya ingin membahas trik untuk mempermudah revers engineering proteksi tertentu yang memakai marshal dan gagal didekompilasi.

Setelah membaca kedua artikel tersebut, beberapa hal yang penting diketahui adalah:

  1. Sebuah fungsi atau modul (file) python bisa didapatkan byte codenya (dengan marshal yang merupakan modul bawaan Python)
  2. Kita bisa mengeksekusi hasil marshal dengan exec marshal.loads(bytecode)
  3. File pyc sebenarnya hanyalah file marshal dengan header
  4. Bytecode bisa dilihat versi teksnya dengan dis (modul bawaan Python juga)
  5. Ada decompiler (uncompyle6) yang bisa mengembalikan (mendekompilasi) kode pyc  kembali menjadi kode Python, tapi ini tidak selalu berhasil

Beberapa proteksi yang dilakukan secara umum seperti ini:Kode python dicompile menjadi pyc, headernya dihapus, dan dijadikan string, jadinya:

exec marshal.loads(bytecode);

Seperti sudah dibahas di artikel lain, untuk mendekompilasi kita bisa mengambil bytecode, menuliskan ke file dan menambah header, lalu kita decompile dengan kode seperti ini:

bytecode = '....' #isi bytecode di sini

import imp
magic_number = imp.get_magic()

import struct, time
timestamp = struct.pack('i', int(time.time()))

with open('temp.pyc', 'wb') as f:
    f.write(magic_number)
    f.write(timestamp)
    f.write(bytecode)

Lalu kita coba decompile filenya (uncompyle6 temp.pyc). Tapi kadang dekompilasi ini gagal, contohnya adalah di artikel: Reverse Engineering Python Bytecode. Cara yang pasti berhasil adalah dengan membaca bytecodenya (seperti dijelaskan di artikel tersebut), walau kadang ini sulit jika kodenya rumit.

Di sini saya akan menjelaskan trik untuk proteksi sejenis. Perhatikan bahwa di dalam bytecode file tersebut diakhiri dengan:

12     >> 39161 LOAD_NAME                0 (marshal)  #
          39164 LOAD_ATTR                8 (loads)    #
          39167 LOAD_NAME                2 (e)        #
          39170 CALL_FUNCTION            1            # marshal.loads(e)
          39173 LOAD_CONST               1 (None)     #
          39176 DUP_TOP                               #
          39177 EXEC_STMT                             # exec(marshal.loads(e))
          39178 LOAD_CONST               1 (None)     #
          39181 RETURN_VALUE                          #

Yang artinya, pasti ada kode dekripsi, dan terakhir memanggil: exec marshal.loads. Dalam kasus ini saya tidak peduli proses dekripsinya bagaimana. Tapi saya memperhatikan bahwa tidak ada fungsi berbahaya yang dipanggil selain marshal.loads.

Sekarang trik cara mendapatkan kodenya yang terdekrip tanpa harus membaca dan memahami bytecodenya: kita bisa memaksa agar tidak memanggil marshal, tapi marshax (saya ganti huruf terakhir), lalu membuat modul marshax yang akan menuliskan hasil dekripsi ke file.

Contohnya begini: saya simpan kode yang sudah di-marshal ke file temp, lalu saya baca, ganti teks marshal dengan marshax dan eksekusi. Karena sudah diubah, maka ini akan error karena modul marshax tidak ada,

import marshal

with open("temp", "rb") as f:
  c = marshal.loads(f.read().replace("marshal", "marshax"))
exec c

Tujuan kita adalah untuk menangkap kode yang sudah didekrip. Jadi untuk ini kita buat file marshax.py di direktori yang sama dengan isi:

def loads(x):
    with open("temp2", "w") as f:
        f.write(x)

Hasilnya, ketika exec c dipanggil, fungsi loads di marshax yang akan dipangil dan akan menuliskan kode yang sudah didekrip ke dalam file temp2.

Sekarang file temp2 bisa dicoba diberi header dan didecompile lagi. Jika dekompilasi gagal dan masih berakhir dengan marshal.loads lagi, ulangi langkah yang sama.

Demikian trik kecil dari saya. Semoga bisa membantu reverse engineering file Python lain. Teknik serupa (mengganti implementasi kode) juga bisa diterapkan di kasus lain. Semoga semakin banyak lagi yang menuliskan artikel reverse engineering dalam bahasa Indonesia, sehingga mudah saya link seperti di posting ini.

Membedah e-KTP

Posting ini sekedar membahas tentang kartu tanda penduduk elektronik (e-KTP). Sampai saat ini saya belum pulang ke Indonesia untuk mengurus e-KTP karena KTP lama masih berlaku. Waktu orang tua saya datang ke sini tahun lalu saya sudah sempat ngoprek e-KTP mereka sedikit, dan sekarang selagi mereka berkunjung saya teruskan dan tuliskan hasil eksplorasi saya.

Sebagian isi tulisan ini didapat dari reverse engineering, dan sebagian lagi dari berbagai informasi yang tersebar di Internet. Ada juga bagian yang merupakan spekulasi saya dari informasi yang ada.

Security sebuah smart card

Sebuah smart card adalah sebuah komputer kecil, di dalamnya ada CPU, RAM, dan juga storage. Smart card diakses menggunakan reader, secara umum ada dua jenis: contact (menggunakan konektor fisik seperti SIM card) dan contactless (tanpa konektor fisik seperti kartu e-Money berbagai bank saat ini). Dari sisi programming keduanya sama saja. Kartu smart card yang baru umumnya juga sudah tahan (immune) terhadap side channel attack (DPA/SPA/FI dsb).

Hal yang membuat smart card penting untuk security adalah kemampuan smart card untuk melakukan komputasi (menghitung, melakukan hasing, enkripsi, dekripsi, dsb), dan sangat sulit untuk melakukan ekstraksi data dari smart card. Bayangkan seperti disuruh mengekstrak data di sebuah komputer yang dicor dan dimasukkan ke lemari besi.

Dari segi security, kita bisa memandang smart card ini seperti komputer remote yang melakukan komputasi yang tidak kita ketahui, dan kita tidak bisa mengekstrak informasi jika tidak ada bug pada implementasinya. Bayangkan sebuah sevice php seperti ini

<?php echo hash_hmac (“sha256”, $_GET[“q”], “[email protected]!ku” );?>

Jika kita tidak memiliki akses ke source code program tersebut, maka kita bisa mencoba-coba berbagai input, dan dengan melihat outputnya kita tidak akan bisa mengetahui bahwa kita memakai key “[email protected]!ku”.

Untuk berkomunikasi dengan smart card, kita mengirimkan perintah dalam bentuk byte-byte (dinamakan PDU atau protocol data unit), dan dibalas oleh card dengan status dan byte-byte hasil. Sebenarnya ini tidak berbeda jauh dari komunikasi lain seperti HTTP: kita mengirimkan request, dan card akan mengirimkan status dan balasan. Bahkan smart card generasi baru memang memasukkan server HTTP di dalamnya.

Riset smart card di level protokol (bukan level serangan fisik) bisa dilakukan dengan biaya relatif rendah. Card reader jenis contact dengan konektor USB bisa didapatkan dengan dengan harga kurang dari 10 USD, dan versi contactless (NFC) dengan konektor USB harganya sekitar 30 USD (atau jika punya Raspberry Pi atau Arduino, harga modul NFC-nya saja bisa kurang dari 5 USD).

Perhatikan bahwa: sebuah smart card bisa diisi program. Programnya bisa melakukan apa saja, baik itu memenuhi standar tertentu, atau melakukan sesuatu yang sifatnya custom. Sebagai informasi, kebanyakan  (tapi tidak semua) card sekarang ini diprogram menggunakan Java (teknologi JavaCard). Eksperimen Java Card bisa dilakukan di PC tanpa kartu menggunakan JCardSim.

Smart card juga memiliki protokol standar untuk filesystem. Kita bisa memilih Master File/Dedicated File (MF/DF) yang merupakan struktur direktori, dan EF (Elementary File) yang merupakan file. Semua “nama” pada file hanyalah bilangan yang umumnya dituliskan dalam notasi heksa desimal. Sebuah MF/DF/EF bisa diproteksi dan hanya bisa diakses dalam kondisi tertentu saja (dalam kondisi lain statusnya access denied)

SAM (Secure Access Module/Secure Application Module)

Jika komputer biasa digunakan untuk melakukan komputasi kriptopgrafi untuk dimasukkan ke e-KTP maka programnya akan rawan sekali diubah dan keynya gampang dicuri. Untuk mengatasi hal ini digunakan smart card lain yang dinamakan SAM. Ini hanya merupakan nama peran/role untuk smart card. Sebuah smart card biasa bisa menjadi SAM. Jadi sebuah SAM juga bisa diberi program apa saja. SAM ini bisa berupa chip yang ditanam di hardware, atau berupa kartu biasa. Biasanya SAM ini akan menggunakan jenis kartu contact.

Sekarang masalah security berpindah ke SAM. Tentunya SAM ini berbahaya jika jatuh ke tangan yang salah, jadi ada mekanisme keamanan yang diterapkan pada SAM e-KTP. Mekanismenya cukup sederhana, sehingga jika cukup niat bisa diakali. Ketika Kartu SAM diberikan untuk dipakai dengan aplikasi di sebuah komputer, file konfigurasi diberikan. File konfigurasi ini dienkrip dengan “Machine ID” (yang bisa dengan mudah didapatkan oleh program apapun).

Dengan menggunaakan file konfigurasi yang di XOR dengan machine ID, didapatkan key untuk mengakses Kartu SAM. Kartu tidak bisa dengan mudah dipakai di komputer lain tanpa mengakali program dan/atau mengganti machine ID. Jika N kali salah memasukkan machine ID, maka kartu SAM akan terblokir, dan harus meminta kartu SAM baru.

Keamanan ini hanya sekedar menghindari SAM yang “tercecer” di jalan agar tidak bisa sembarang dipakai. Jika ada yang berniat mengambil kartu SAM dan tahu dipakai di komputer mana (atau device mana), maka keamanan ini tidak membantu. Jadi bisa saja seoarang operator meminjam kartu SAM, dibawa pulang dan dipakai di rumah.

Data Pada e-KTP

Data yang disimpan pada e-KTP pada MF/DF 7F0A. Untuk memilih MF/DF ini bisa digunakan PDU

00A40000027F0A

Beberapa data yang ada di kartu:

  1. Data kontrol kartu (Card Control, pada EF: 6FF0), terbuka tapi spesifikasinya tidak diketahui
  2. Foto (EF: 6FF2), data ini terbuka
  3. Data Demografik/Biodata (6FF1), datanya diproteksi
  4. Data sidik jari: Minutiae1 (6FF4) dan Minutiae2 (6FF5), datanya diproteksi
  5. Scan tanda tangan (6FF3), datanya diproteksi
  6. ECDSA Signature (6FF6), datanya diproteksi

Mengekstrak Foto dari e-KTP

Foto dapat diekstrak dari e-KTP karena memang tidak diproteksi. Cara membacanya cukup mudah, pertama pilih MF/DF dan EF foto, lalu baca 2 byte pertama

00A40000027F0A
00A40000026FF2
00B0000002

Pada 2 byte pertama terdapat panjang (ukuran) data JPEG yang perlu dibaca.  Perhatikan bahwa apapun perintahnya akan selalu ada 2 byte status kembalian (9000 artinya adalah OK, bisa dibandingkan dengan HTTP Code 200):

=> 00 a4 00 00 02 7f 0a
<= 90 00 
Response : 
=> 00 a4 00 00 02 6f f2
<= 90 00 
Response : 
=> 00 b0 00 00 02
<= 06 fe 90 00
Response : 06 fe

Dalam kasus ini panjang file adalah 0x6fe byte = 1790 byte.

Berikutnya data bisa dibaca dengan mengirimkan PDU berikut ini berulang sampai selesai terbaca. Misalnya kita membaca dari offset 2 sebanyak 16 byte, berikutnya dari offset 18 sebanyak 16 byte, dst.

00BB<Offset High><Offset Low><Size>

Jika kita memiliki offset: 0x1234, maka Offset High adalah 0x12 dan Offset Low 0x34.  Teorinya kita bisa membaca sampai 255 byte sekali baca, kenyataannya card readernya bisa error. Di aplikasi e-KTP digunakan 112 byte sekali baca tapi di salah satu card reader saya, saya perlu memakai ukuran 16 byte sekali baca supaya reliable.

Data yang didapatkan adalah file JPEG biasa dengan ukuran 96×96 piksel.


Autentikasi Kartu

Untuk membaca data yang diproteksi, diperlukan key yang berada di SAM. Langkah pertama adalah mutual authentication untuk mendapatkan session key. Berdasarkan hasil reverse engineering,  protokol ini sepertinya berdasarkan Doc 9303 ICAO (Machine Readable Travel Documents) terutama Part 11 (Security Mechanisms for MRTDs).

Di dalam dokumen di atas, diasumsikan mesin pembaca memiliki key dalam memori komputer. Dalam dokumen itu protokolnya seperti ini (hanya garis besar, lihat contoh Appendix D di dokumen 9303 Part 11). Masing-masing pihak (kartu dan app desktop) memiliki SEED yang menjadi dasar untuk pembuatan key:

  • To Card: 0084000008 (request challenge/random number)
  • From Card: 8 byte random
  • From App: Generate random X1 (8 byte) dan X2 (16 byte), lalu  hoitung P1 = 3DES(X1 + RandomFrom Card +X2) , P2 = MAC(P1), hasilnya P1 + P2 ukurannya 40 byte, kirimkan ini ke kartu
  • From Card: kartu melakukan perhitungan serupa dan mengembalikan 40 byte
  • App melakukan komputasi dan menghasilkan session key.

Sedangkan protokolnya e-KTP seperti ini:

  • To SAM: Reset 00FF000000
  • From SAM: OK
  • To CARD: Get Challenge: 0084000008
  • From Card: challenge (8 byte)
  • To SAM: GenerateMutualAuth 00F10000 + CardControl + UID (8) + Challenge (8)
  • From SAM: 40 byte
  • To Card: ExternalAuth: 0082000028 + response from SAM
  • From Card: 40 byte
  • To SAM: VerifyMutualAuth: 00F2000028 + Response From Card

Perbedaannya adalah ada data Card Control dan UID kartu yang dikirim ke SAM. Sepertinya Card Control ini berisi informasi untuk pembuatan SEED, tapi tanpa source code ini tidak bisa diketahui detailnya.

Akan sangat panjang untuk membuktikan bahwa ini aman, tapi pada dasarnya: jika kita tidak punya key enkripsinya, meskipun kita bisa mengubah apapun di sisi app, maka kita tidak bisa mencari tahu key-nya.

Secure Messaging

Berdasarkan pada session key yang didapat pada proses autentikasi, maka setiap PDU yang dikirim akan dienkrip  dulu sebelum dikirim ke kartu dan yang diterima akan didekrip dulu sebelum diproses. Deskripsi ini cukup panjang, tapi ada gambar di dokumen yang menjelaskan ini.

Karena session key tidak pernah di simpan di PC, tapi di SAM, maka secara praktis yang terjadi adalah:

  1. Aplikasi membuat PDU unprotected (misalnya select EF)
  2. Aplikasi mengirimkan PDU unprotected ke SAM
  3. SAM membalas dengan PDU versi Secure Messaging
  4. Aplikasi mengirimkan PDU terenkripsi ke kartu e-KTP
  5. Kartu e-KTP membalas dalam PDU yang terenkrip
  6. Aplikasi mengirimkan PDU terenkrip dari e-KTP ke SAM
  7. SAM akan mendekrip PDU dan hasilnya dibaca oleh aplikasi di PC

Jadi dalam proses ini, meskipun kita mengetahui data terenkripsi dan hasil dekripsinya, kita tetap tidak tahu key yang digunakan (session ini selalu random dalam setiap koneksi).

Emulasi SAM dan e-KTP

Untuk membuat aplikasi e-KTP tanpa memiliki SAM. kita bisa menggunakan SAM dan e-KTP buatan kita sendiri dengan key yang kita masukkan sendiri tentunya ini tidak akan jalan di e-KTP “beneran” sampai kita memiliki akses untuk SAM yang benar. Hal ini sudah pernah diimplementasikan oleh BPPT dalam paper PERANCANGAN EMULATOR KTP ELEKTRONIK BERBASIS JAVA CARD UNTUK MENDUKUNG PENGUJIAN FUNGSIONALITAS PEMBACA KTP ELEKTRONIK INDUSTRI NASIONAL.

Dalam paper ini disebutkan bahwa metode key derivation yang digunakan e-KTP sifatnya rahasia dan mereka mengimplementasikan sendiri algoritma yang sekedar bisa dipakai oleh kartu SAM dan kartu KTP mereka sendiri.

Amankah e-KTP

Aman tergantung dari sudut pandang mana: dari pembuatan KTP, dan dari pemilik/pengguna KTP. Keamanan e-KTP ada pada SAM-nya.  Ini berarti beberapa hal:

  • Kartu SAM harus dijaga ketat, karena jika bisa dipinjam, maka bisa digunakan membuat KTP Aspal
  • Semoga key generation-nya aman. Saya sudah pernah menemukan kode SAM yang aman, tapi cara membuat key yang random hanya mengandalkan fungsi random biasa (bukan secure random) dan menggunakan seed waktu saat ini.
  • Semoga key utama disimpan dengan baik oleh kemendagri

Saat ini data foto sama sekali tidak diproteksi, sehingga seseorang bisa mengambil foto dari dompet yang tertutup. Menurut standar security MRTD, seharusnya data yang bisa dibaca dienkrip dengan informasi yang tertera di kartu. Misalnya untuk paspor, dari nomor paspor, tanggal lahir, tanggal kadaluarsa. Informasi ini tertera di kartu, jadi seseorang yang berusaha membaca dokumen tidak bisa membaca jika memang tidak memegang kartunya. Dengan ini kita bisa memastikan apakah benar isi data elektronik sama dengan data yang dicetak.

Sempat ada aplikasi POC reader e-KTP tapi sayangnya sudah dihapus dari Google Play (tapi masih bisa didownload dari sini). Aplikasi ini membaca data foto seperti saya jelaskan di atas. Sebenarnya agak berbahaya mempercayai data ini, karena mudah sekali membuat card yang jika dibaca dengan aplikasi tersebut akan keluar foto.

Semoga programmernya handal dan tidak membuat kesalahan implementasi. Saya agak khawatir membaca kode seperti ini di salah satu aplikasi yang saya dekompilasi.

Dari mana bisa tahu ini semua?

Pertama adalah mencari dulu aplikasi desktop e-ktp. Ini bisa dicari dengan query berikut di Google.

“index of” e-ktp inurl:.go.id/

Sekarang sepertinya sudah cukup sadar sehingga installernya lebih sulit dicari, tapi tahun lalu ini mudah sekali dicari. Programnya ditulis dalam .NET tanpa obfuscation sehingga mudah dibuka.

Berikutnya eksperimen diteruskan dengan e-KTP orang tua saya. Saya sudah mencoba beberapa attack yang umum, dan sepertinya semuanya aman.

Saat ini saya baru menemukan hal-hal kecil yang undocumented. Seperti halnya web server yang bisa dicari direktori tersembunyi dengan teknik “forced browsing”, kita bisa mengirimkan perintah berurutan ke smart card untuk mencari tahu perintah mana yang menghasilkan sesuatu tapi tidak terdokumentasi.

Demikian hasil oprekan e-KTP untuk saat ini. Mungkin di masa depan akan saya teruskan lagi. Saat ini belum ada ide serangan baru.

 

Reverse Engineering APK

Saya sudah menulis beberapa artikel terpisah mengenai reverse engineering APK Android (misalnya di http://yohan.es/security/android/) . Di posting ini saya ingin menggabungkan berbagai tulisan yang pernah saya buat dalam satu posting, supaya lebih gampang dibaca. Topik yang lebih umum mengenai Pengantar Reverse Engineering sudah pernah saya bahas di blog ini (tidak spesifik Android).

 

Tujuan Reversing

Pertama, tentukan tujuannya apa ingin bisa reversing APK. Ini bisa digolongkan jadi dua bagian: apakah ingin mengetahui cara kerjanya? (sekedar membaca kode) atau ingin mengubah aplikasinya? (memodifikasi kode) Yang termasuk dalam kategori pertama: apakah ingin ekstrak API-nya, ingin membaca file yang dibuat oleh aplikasi, ingin tahu protokol aplikasi.

Tujuan yang kedua lebih rumit: intinya ingin memodifikasi aplikasi. Beberapa tujuannya: memperbaiki bug, mengubah sifat aplikasi, menambah fitur, mencurangi game, dsb.

APK itu apa?

Pertama APK itu apa? APK adalah format aplikasi Android, berupa file ZIP yang di dalamnya ada classes.dex yang berisi kode Java, resource dalam bentuk XML (yang diencode khusus), file-file gambar, video, suara, dsb.

Selain itu ada juga bagian lain seperti native code (kode dalam bahasa mesin) yang ditulis dalam C/C++/Rust atau bahasa lain. Jika APK dibuat dengan teknologi selain Java, maka kemungkinan ada file-file dalam bahasa lain (misalnya pyc untuk Python, JS untuk JavaScript dsb).

Bagaimana APK dibuat?

APK dibuat dari kode program yang umumnya ditulis dalam bahasa Java dan C/C++, tapi tidak selalu harus demikian. APK bisa dibuat dengan kode HTML dan JavaScript, dari kode Python, Ruby, Unity, dsb. Semuanya sangat fleksibel.

Sebenarnya yang didukung langsung oleh Android hanya bisa ada dua jenis kode: Java atau Native. Native artinya kode yang dikompilasi ke bahasa mesin, biasanya ditulis dalam bahasa C/Assembly. Tapi baik kode Java maupun Native bisa meload interpreter bahasa lain, misalnya dari Java kita bisa langsung menggunakan komponen WebView yang mendukung JavaScript. Dari Java kita juga bisa menggunakan library JRuby/JPython untuk menjalankan kode Ruby/Python (dan masih banyak juga library untuk bahasa lain). Dari bahasa C kita juga bisa meload library apapun (termasuk juga interpreter Python, Ruby, Lua, dsb) dan menjalankan kode dalam bahasa itu.

Tapi fakta ini disembunyikan jika kita menggunakan tools tertentu. Misalnya ketika memakai cordova, maka kode Java disembunyikan dari programmer, dan programmer hanya memikirkan kode dalam HTML/JavaScript saja. Demikian juga dengan Unity, programmer tidak akan melihat kode Java dan Native yang disertakan oleh unity untuk menjalankan kode .NET.

Kode Java akan dikompilasi menjadi .class (file Class Java) lalu dikonversi menjadi bytecode dalvik.   Satu aplikasi terdiri dari banyak kelas dan semua ini disimpan dalam file DEX. Bytecode dalvik ini sifatnya biner, agar lebih mudah dibaca, dibuatlah format kode smali yang berupa teks. Dengan format smali, bytecode menjadi lebih mudah diedit.

Supaya lebih terbayang, berikut ini contoh kode dalam bahasa Java

    public int nextInt(int i) {
                return f++;
   }

Versi .class (bytecode Java):

  public int nextInt(int);
    Code:
       0: getstatic     #2                  // Field f:I
       3: dup
       4: iconst_1
       5: iadd
       6: putstatic     #2                  // Field f:I
       9: ireturn

Versi smali

.method public nextInt()I
    .locals 2
    .prologue
    .line 15
    sget v0, LMyRandom;->f:I
    add-int/lit8 v1, v0, 0x1
    sput v1, LMyRandom;->f:I
    return v0
.end method

Ketika sebuah aplikasi dibongkar, maka minimal ada sedikit kode Java. Lebih tepatnya lagi dari DEX kita bisa kembalikan menjadi file-file .class atau .smali, dan dengan decompiler biasanya bisa dikembalikan ke java.Jika APK tidak dibuat dengan bahasa Java, maka biasanya logika utama aplikasi berada di file lain, dan file Java ini hanya me-load file tersebut.

Membaca Source Code

Sebelum membongkar sebuah APK. Coba tanyakan dulu pada diri sendiri: andaikan saya diberikan source code lengkap sebuah aplikasi, apakah saya bisa akan paham? Andaikan diberi source code yang diberi nama jelas, diberi komentar, diberi dokumentasi tetap belum bisa mengerti, maka sebaiknya Anda kembali ke dasar dulu.

Intinya tool-tool untuk membongkar APK paling jauh hanya akan bisa mengembalikan menjadi source code. Bahkan terkadang jika ada proteksi tertentu, source codenya bisa salah, sulit dimengerti, atau bahkan source code tidak bisa dihasilkan, dan kita harus melihat ke smali code. Jadi jika source code saja tidak bisa dimengerti, maka langkah berikutnya akan sulit.

Mendapatkan APK

Sekarang jika sudah siap reverse engineering APK. Pertama adalah mendapatkan APK. Ini bisa didapatkan dari berbagai situs, misalnya APKPure. Perhatikan APK yang didapat mungkin bukan yang terbaru di Play Store.

APK juga bisa diterima dari programmer yang mengirimkan Anda file APK-nya. Pada kegiatan pentest, biasanya metode ini yang dipakai karena aplikasi belum diterbitkan.

APK juga bisa diekstrak dari aplikasi yang sudah terinstall di  handphone dengan berbagai aplikasi  di handphone misalnya Apk Extractor, ES File Explorer, dsb). APK juga bisa diambil dari desktop melalui Android Debug Bridge (ADB).

Android Debug Bridge (ADB)

Sebelum Anda mulai lebih jauh, pelajari juga tools dasar Android, terutama ADB. Carilah cara untuk mengaktifkan developer mode pada ponsel Anda, dan ikuti tutorial untuk menjalankan ADB, masuk ke shell adb, mem-push dan pull file ke/dari device, menginstall dan uninstall APK. Untuk device tertentu kadang Anda perlu menginstall device driver khusus untuk bisa melakukan koneksi ke ADB.

Hal penting lain adalah mendapatkan log dengan adb logcat dan memfilter isi log. Kemungkinan besar aplikasi akan crash ketika dimodifikasi, jadi mengetahui log akan membantu mencari tahu di mana crash terjadi.

Ekstraksi APK

Sekarang APK bisa diekstrak dengan apktool. Tool ini adalah tool command line yang sangat dasar. Ada beberapa tool lain yang “membungkus” tool ini agar lebih mudah dipakai dengan klik saja. Menurut saya, jika masih pemula, justru bagus untuk bisa mengetahui cara manual ekstraksi file.

Untuk orang yang tujuannya hanya ingin memahami kode Java saja, maka tool jadx akan lebih mudah dipakai. Tool ini juga memiliki GUI yang memudahkan kita membuka file dan melakukan dekompilasi langsung menjadi kode dalam Java. Tool ini memiliki kelemahan: ketika kode dipoteksi maka akan sulit memahami kodenya. Kelemahan lainnya adalah: kita tidak bisa memodifikasi kodenya, ini hanya sekedar untuk melihat saja.

Sebagai catatan: sebagian orang suka menggunakan dua langkah: dex2jar yang akan mengubah APK menjadi file  Jar (yang berisi file .class Java), lalu mendekompilasi file jar-nya dengan decompiler Java (misalnya JD atau CFR).

Perhatikan bahwa jika program tidak ditulis dalam bahasa Java, maka Anda harus memakai tools lain untuk reverse engineering. Beberapa teknologi yang pernah saya temui misalnya:

  • Unity. Ada yang masih memakai kode .NET, dan ada yang dikompilasi menjadi native code dengan il2cpp.
  • HTML/JS (Apache Cordova)
  • Ruby
  • Python
  • Cocos-2DX (native code), kadang dicampur Lua

Teknologi non-Java berada di luar scope posting blog ini. Jika memang tertarik, carilah informasi di internet mengenai masing-masing teknologi untuk tahu cara membongkarnya.

Memahami Program

Jika sudah berhasil diekstrak, maka langkah berikutnya adalah memahami programnya. Bagian ini adalah tersulit. Kembali lagi ke nasihat awal: jika diberikan source code sebuah program apakah Anda bisa mengerti? Jika dihapus semua nama fungsi-nya dan diganti dengan “a”, “b”, “c” apakah kira-kira Anda masih mengerti bahwa sebuah kode melakukan “sorting” atau “searching”?

Selain dengan membaca kode, seorang programmer bisa berusaha memahami program dengan menggunakan “debugger”. Ini juga bisa diaplikasikan ketika melakukan reverse engineering: debugger bisa membantu memahami cara kerja program. Selain itu programmer juga bisa menambahkan logging untuk membantu memahami alur program.

Seorang programmer yang baik akan menggunakan berbagai library yang populer. Pengetahuan mengenai library populer ini akan sangat berguna ketika mereverse engineer sesuatu. Kita bisa mengabaikan banyak kode yang bukan inti dari aplikasi. Misalnya jangan sampai pusing  dan berkutat membaca kode di package android.support.

Modifikasi kode

Sama halnya dengan modifikasi kode: jika ada kode open source di github, apakah Anda bisa menambahkan sendiri fitur yang Anda inginkan? misalnya sekedar mengganti teks, memindahkan tombol, menambah tombol. Jika jawabannya adalah: tidak bisa, maka memodifikasi APK juga akan sulit dilakukan.

Beberapa modifikasi sederhana, seperti bypass root checking, atau SSL Pinning mungkin masih bisa dilakukan dengan sekedar mengubah sebuah kondisi atau if. Tapi modifikasi seperti: mengganti user interface atau menambahkan fitur baru akan sangat sulit dilakukan jika Anda tidak mengerti bagaimana memprogram Android.

Jika ingin mulai dengan benar, belajarlah dulu membuat Aplikasi Android dasar. Materi untuk ini bisa didownload secara gratis. Tutorial dalam bentuk video juga banyak tersedia. Beberapa cara modifikasi APK baik secara permanen maupun temporer pernah saya tuliskan di sini.

Sangat sering saya temui orang yang ingin memodifikasi APK tapi masih bingung dengan konsep app signing. Bertanya: kenapa hasil modifikasi saya nggak  bisa diinstall? (masih lebih bagus jika pertanyaannya eksak seperti ini, ada yang bertanya: kenapa aplikasi saya nggak jalan? lalu setelah muter nanya jauh, ternyata maksudnya tidak bisa diinstall). Tanpa modifikasi apapun, jika aplikasi diunpack dan dipack ulang tapi tidak disign maka tidak bisa diinstall (dengan perkecualian Androidnya sudah dipatch dengan aplikasi tertentu agar mengabaikan code signing, tapi ini berbahaya dari segi security).

Sebelum belajar melakukan modifikasi, minimal belajar dulu packaging ulang aplikasi: ekstrak aplikasi, tidak usah dimodifikasi, lalu package ulang, sign ulang dan install ulang. Pelajari apa itu “signing”, dan bagaimana caranya signing aplikasi. Program tanpa proteksi harusnya akan berjalan normal setelah repackage (tanpa modifikasi).

Jika aplikasi berjalan normal ketika direpackage sebelum dimodifikasi, tapi  kemudian program crash setelah dimodifikasi maka kemungkinan Anda salah memodifikasi. Lihat pesan pada logcat untuk mencari tahu kenapa.

Proteksi

Untuk aplikasi yang diproteksi, maka proses reverse engineerig menjadi lebih sulit. Misalnya proteksi yang paling sederhana sekedar obfuscation. Nama-nama method dan variabel diubah agar sulit dimengerti. Ini bisa sekedar menjadi a,b,c, d tapi juga agar namanya tidak valid untuk OS Windows (misalnya CON atau NUL).

Contoh kode yang gagal didekompilasi

Proteksi tingkat lanjut juga ada, misalnya dengan mengenkrip kode program yang kemudian diload ketika program berjalan. Di tingkat yang lebih lanjut lagi, digunakan native code sehingga harus melihat kode assembly (bahasa mesin) bukan sekedar kode smali.

Ketika proteksi mulai digunakan, maka yang berikutnya dipahami adalah berbagai trik dan pengalaman. Misalnya konstanta MD5/SHA1/AES bisa digunakan untuk mencari tahu algoritma apa yang digunakan. Kadang yang paling mudah adalah dari berbagai string yang muncul dalam sebuah method, misalnya ada pesan tentang error AES, maka kemungkinan kelas itu berhubungan dengan enkripsi AES. Bahkan kemungkinan besar seluruh package tempat kelas tersebut berada berhubungan dengan AES.

Menelusuri Kode

Ketika seseorang bertanya: kok tahu kalau kode enkripsinya ada di kelas yang ini? Jawabannya biasanya adalah: dari pengalaman dan dari penelusuran kode program.

Yang saya maksud dengan menelusuri kode adalah membaca secara manual dan kadang dicampur dengan logging untuk melihat apakah method tertentu dipanggil. Contohnya begini: jika kita tahu di Activity tertentu teks dimasukkan (dalam bentuk plaintext alias belum dienkrip), dan ketika di kirimkan melalui HTTP sudah terenkrip, maka kita bisa menelusuri method yang dipanggil sampai data terkirim untuk mencari di mana method enkripsi.

Secara umum, computational thinking membantu sekali karena ini seperti menyelesaikan sebuah puzzle. Kadang kita harus menelusuri dari belakang, dari depan, atau dari tengah.

Library

Pemakaian library tertentu menunjukkan programmer menggunakan paradigma tertentu dalam memprogram. Contohnya adalah jika library RX Java digunakan maka reactive programming digunakan.

Penggunakan AspjectJ menunjukkan bahwa Aspect Oriented Programming digunakan. Dalam kasus seperti ini, pengetahuan mengenai berbagai paradigma pemrograman akan sangat berguna.

Malware Android

Berbagai malware memiliki proteksi yang di atas rata-rata software biasa. Proteksi malware tertentu sangat kompleks, karena mungkin hanya menargetkan HP jenis tertentu, dan jika crash ya sudah (emangnya ada yang mau kirim bug report?), jadi berbagai proteksi yang sifatnya advanced bisa diterapkan.

Banyak software banking juga memiliki proteksi tapi biasanya lebih mudah dari malware, karena sebuah aplikasi banking dibatasi oleh beberapa hal: mereka ingin aplikasinya tetap berjalan di berbagai ponsel, mereka tidak ingin terdeteksi sebagai malware, mereka tidak ingin aplikasi menjadi terlalu lambat, mereka tetap ingin bisa mendebug aplikasi jika ada masalah.

Jadi secara umum: membongkar malware levelnya lebih susah. Sebuah malware juga kadang mengandung exploit yang mewajibkan kita mengerti internal Android untuk bisa mengerti eksploitnya.

Security

Jangan kira jika sudah berhasil membongkar sebuah APK kita pasti bisa menemukan masalah security. Sebuah APK biasanya hanyalah salah satu “client” dari sebuah aplikasi server. Artinya segala pemrosesan dilakukan di server, dan jika aplikasinya bagus, maka bagaimanapun kita akali, tetap akan dicek di server.

Contohnya dalam aplikasi banking: jika kita bisa mengubah request kita ke bank, maka seharusnya tidak mungkin kita mengubah jumlah saldo, nilai transaksi, nomor rekening, dsb.

Tapi bukan berarti kita langsung menyerah membongkar APK penting karena dianggap sudah aman. Dalam beberapa kasus saya pernah menemukan bahwa aplikasi yang penting dan sudah dipakai umum masih memiliki bug. Saya pernah menemukan bisa mentransfer dari rekening orang ke diri sendiri. Bug itu tidak ditemukan oleh yang lain karena aplikasinya memakai enkripsi custom dengan socket (bukan HTTP), dan tanpa reverse engineering tidak akan bisa ditamper dengan tool seperti burpsuite. Sebagai catatan: dalam hal ini yang salah bukan sisi app-nya, tapi sisi servernya.

Tools

Bagi saya tools-tools ini sudah cukup untuk membongkar dan menyusun 95% APK yang saya temui:

  • apktool
  • jadx
  • compiler Java dan atau IDE (Intellij/Netbeans/Android Studio)

Tools yang komersial juga ada: JEB tapi harganya relatif mahal.

Beberapa tool lain yang juga saya pakai:

Network

Jika niatnya tidak ingin tahu aplikasi secara dalam, tapi hanya sekedar melihat trafficnya saja, saya memakai tool berikut:

Tools-tools tersebut tidak jalan jika ada certificate pinning. Untuk mengatasinya ada banyak metode yang bisa dipakai, tergantung metode pinning yang dipakai oleh program. Dalam kasus sederhana memakai JustTrustMe (Xposed module) atau Frida sudah cukup, tapi di aplikasi tertentu kita perlu patch kode smali untuk bypass SSL Pinning. Artikel berikut ini membahas metode umum untuk bypass SSL Pinning.

Untuk native code saya menggunakan tools lain: IDA Pro dan  Radare. Saya tidak akan membahas native code reverse engineering di sini.

Memulai

Jadi bagaimana untuk memulai? apa yang perlu dipelajari?. Menurut saya urutan ini cukup baik:

  • Belajar membuat aplikasi Android sederhana (minimal hello world), belajar membuat beberapa user interface sederhana (misalnya halaman login), ini terutama jika ingin mengubah/menambah user interface dari APK yang sudah ada. Sudah ada materi gratis dari Google yang bisa didownload di Internet, berbahasa Indonesia.
  • Ekstrak aplikasi tersebut dengan apktool dan jadx
  • Belajar menggunakan proguard, lalu buat atau download aplikasi dari github, kemudian coba compile, bongkar. Setelah itu coba compile dan obfuscate dengan proguard, lalu bongkar.
  • Download aplikasi dari Google Play yang diinginkan, coba ekstrak aplikasinya. Coba bongkar beberapa aplikasi. Langkah ini bisa diganti dengan mendownload soal CTF Android

Penutup

Berbagai jawaban di atas seharusnya sudah cukup menjawab pertanyaan awal. Banyak pertanyaan lanjutan akan bisa dicari jawabannya di Internet, dan beberapa pertanyaan akan sangat spesifik aplikasi dan bahkan spesifik pada versi aplikasi itu.

Contohnya: banyak aplikasi yang versi awalnya tidak diobfuscate sama sekali (misalnya Gojek, BBM) tapi kemudian diobfuscate. Kebanyakan aplikasi juga akan berubah nama kelasnya, dan bahkan library yang dipakai di versi yang baru bisa berbeda. Di sisi server berbagai hal juga bisa berubah, dari mulai URL, format yang dipakai, metode signature yang dipakai, dsb.

Jadi kalau ada orang yang nanya sesuatu di Gojek terbaru, saya gak akan bisa langsung jawab. Ini seperti nanya isi buku terbaru, saya harus baca dulu apa saja yang berubah dari versi lama, harus tracing lagi nama-nama fungsi, nama library dsb. Dan ini butuh waktu, tidak sebentar apalagi jika pertanyaannya sangat spesifik.

Tergantung kompleksitas aplikasi dan tujuan reversing, mengerjakan satu APK bisa butuh waktu beberapa menit, beberapa jam, dan bahkan berhari-hari. Di kasus ekstrem game Pokemon Go yang proteksinya sangat baik, bahkan dulu dibutuhkan waktu ribuan man-hour (banyak orang bekerja berhari-hari) sebelum mereka berhasil membongkarnya (dan setelah itu sudah diganti lagi algoritmanya, sementara orang-orang sudah menyerah).

Waktu adalah sesuatu yang berharga. Buat apa saya membongkar sebuah APK spesifik secara gratis, sedangkan saya membongkar APK lain (untuk pentest) dibayar? Tapi saya juga tidak pelit, jika memang kebetulan saya pernah atau sedang membongkar APK iseng, saya akan memberikan petunjuk/jawaban (ingat, hanya APK iseng, bukan  APK di mana saya menandatangani NDA untuk pentesting).

Khusus untuk yang masih banyak nanya mengenai APK Gojek: saya tidak lagi tertarik pada Gojek sejak beberapa tahun yang lalu. Saya bahkan belum pernah memakai jasa Gojek (saya tinggal di Thailand). Saya tidak kenal dengan orang-orang di Gojek.

Semoga rangkuman di atas ini cukup buat menjawab berbagai pertanyaan seputar reverse engineering APK.

Perang Cyber dan Hacker Indonesia

Beberapa hari yang lalu China melarang security researchernya untuk mengikuti kompetisi pwn2own dan sejenisnya di luar negaranya.  Ini bisa jadi suatu awal yang gawat untuk dunia keamanan cyber baik secara umum, dan juga untuk Indonesia.

Saya mau mundur sedikit: apa sih pwn2own itu? Ini adalah kompetisi hacking di mana hacker diminta menjebol device dengan software terbaru dengan bug yang belum pernah diketahui orang lain sebelumnya (zero-day). Pemenangnya mendapatkan devicenya dan hadiah puluhan sampai ratusan ribu USD (ratusan juta hingga milyaran rupiah).

Bug

Secara singkat: beberapa bug ini memungkinkan orang mengambil alih ponsel, tablet, dan bahkan mobil (mobil pintar) dari jauh tanpa interaksi dari user.  Ini bukan bug kacangan seperti XSS atau SQL injection di website.

Supaya lebih jelas lagi akan saya jelaskan dengan salah satu contoh pemenang  di tahun 2017 lalu dari kategori Mobile. Salah satu team dari China bisa membuat exploit, sehingga jika  iPhone dengan iOS terbaru (waktu itu versi 11.1) yang melakukan koneksi ke access point tertentu (yang mereka kuasai) maka iPhone tersebut bisa diambil alih, artinya mereka bisa menginstall sebuah aplikasi di iOS tanpa ketahuan dan aplikasinya bisa melakukan apa saja termasuk juga menyadap komunikasi, mencuri data dsb (tanpa ketahuan), dan aplikasinya tetap berjalan setelah ponselnya direstart.

Perhatikan: pemilik ponsel bahkan tidak perlu masuk ke website tertentu, cukup konek ke sebuah access point WIFI.  Dalam banyak kasus, pemilik ponsel bahkan tidak perlu melakukan apapun karena ponsel biasanya auto connect ke jaringan WIFI yang sudah dikenal (artinya attacker cukup membuat nama WIFI yang sama dengan yang sudah pernah dikunjungi korban, misalnya WIFI di Starbucks)

Jika eksploit ini ada di tangan orang jahat, hanya dengan koneksi ke WIFI sebuah cafe, mereka bisa menginstall software yang selalu berjalan di latar belakang. Seorang mata-mata akan dengan mudah mengambil rahasia negara jika orang tersebut memakai iPhone.  Ini bukan kisah fiksi, tool seperti ini sudah dipakai oleh agensi pemerintah.

Takut memakai WIFI? Team lain bahkan bisa menemukan bug di baseband processor dan melakukan baseband attack (dalam kompetisi tersebut yang berhasil dijebol adalah baseband pada Samsung S8). Di dalam sebuah ponsel ada baseband prosessor yang melakukan komunikasi dengan jaringan operator. Jika serangan dilakukan dengan cara ini, maka bahkan jika WIFI mati, asalkan ponsel melakukan koneksi ke BTS maka tetap bisa diambil alih. Secara otomatis ini koneksi akan dilakukan, meskipun pada BTS tidak dikenal karena dibutuhkan untuk fitur emergency call pada ponsel.

Untuk menemukan dan mengeksploitasi bug seperti ini dibutuhkan pemahaman sangat mendalam dari mulai paket data WIFI, sistem operasi (dalam kasus ini iOS sampai level model security yang dipakai, bukan memakai iOS-nya), assembly (dalam kasus ini Arm 64 bit),sampai pembuatan aplikasi iOS (bagian payload-nya).

Untuk memberi gambaran betapa sulitnya mencari dan mengeksploitasi bug level WIFI, silakan baca posting dari team Google Project Zero, mereka menuliskan tiga bagian artikel ekpsloitasi WIFI di device iOS (silakan baca bagian pertama, kedua, dan ketiga). Bagi yang sudah sering ikutan CTF dalam level eksploitasi, pasti akan sedikit paham isi tulisan itu, tapi kebanyakan yang mengaku “hacker” hanya akan bisa bengong.

China

Saat ini team dari China  memiliki kemampuan hacking yang sangat bagus. Tahun lalu semua top 5 di kompetisi pwn2on adalah dari China. Bukan cuma di kompetisi pwn2own, tapi team dari China juga terkenal dalam berbagai kompetisi lain. Lanjutkan membaca “Perang Cyber dan Hacker Indonesia”

Hacking aplikasi web dengan Zaproxy

Saat ini kebanyakan tulisan di blog ini sifatnya cerita yang tidak sampai ke teknis detail. Tulisan kali ini sangat praktis, mengenai memakai Zaproxy untuk hacking (mencari bug atau mengeksplotasi bug) aplikasi web. Atau lebih tepatnya lagi aplikasi yang memakai komunikasi HTTP, baik itu aplikasi berbasis mobile, desktop, maupun browser. Sekaligus ini untuk menjawab berbagai pertanyaan mengenai hacking web yang sering diajukan ke saya.

Zaproxy pada dasarnya adalah sebuah intercepting proxy dengan berbagai fitur tambahan (scanner, spider, dsb). Sebuah intercepting proxy bisa mencegat komunikasi dari client ke server (request) dan balasan dari server (response). Defaultnya, komunikasi yang dicegat akan diteruskan saja dan dicatat (di-log), tapi kita juga bisa mengubah baik request maupun response.

Sebagai catatan, Zaproxy bukan satu-satunya tools yang ada, tapi tools ini gratis,  open source, cross platform (Windows, OS X, Linux) dan fiturnya lengkap. Alternatif populer adalah Burp suite, ini ada versi gratisnya, tapi fitur pentingnya berbayar (salah satu fitur paling penting yang berbayar adalah menyimpan sesi). Tools lainnya yang gratis dan bagus untuk Windows adalah Fiddler (saat ini Fiddler versi OS X dan Linux masih beta), sayangnya Fiddler tidak open source. Jika sudah menguasai salah satu tools ini, berpindah yang lain tidak terlalu sulit. Lanjutkan membaca “Hacking aplikasi web dengan Zaproxy”

Hacking dan Reverse engineering hardware

Saat ini di jaman IOT, makin banyak orang yang tertarik untuk hacking dan reverse engineering (RE) hardware. Karena sudah cukup banyak orang menanyakan topik ini, maka di artikel ini akan saya bahas dasar-dasarnya, plus tools apa saja yang dibutuhkan jika ingin memulai.

Dalam artikel ini RE hanya bertujuan memahami software dan hardware dalam sebuah sistem. Hacking hardware bermakna lebih luas misalnya menambah atau mengubah sesuatu di hardware, misalnya menjalankan Doom di printer, membuat hardware baru, atau oprekan apapun yang berhubungan dengan hardware.

Supaya bisa mengubah sebuah hardware yang tidak terdokumentasi, kita perlu melakukan dulu reverse engineering untuk memahami cara kerjanya, baru setelah itu kita bisa melakukan perubahan. Untuk hardware open source atau yang dokumentasinya sangat baik, proses RE ini tidak perlu.

Tujuan melakukan Hacking Hardware

Ada banyak tujuan RE dan hacking hardware, misalnya:

  • Mencari key enkripsi untuk mengakses konten gratis atau untuk membuat konten baru (misalnya game homebrew), atau bahkan membajak, contohnya dalam kasus Game Console
  • Memperbaiki, menambah atau menghilangkan fungsionalitas , misalnya menambah SD Card di router
  • Mengekstraksi firmware dengan berbagai tujuan: mencari bug di firmwarenya, mengclone firmwarenya (membuat produk tiruan), mencari key dalam firmwarenya

Perlu dicatat bahwa dalam 99% kasus, ujung dari reversing hardware adalah melakukan reversing software yang berjalan di hardware tersebut. Lanjutkan membaca “Hacking dan Reverse engineering hardware”

Jadi peserta CTF yang bener dong, jangan malu-maluin

Tahun lalu saya mengkritik panitia Cyber Jawara karena soal CTF-nya ngawur. Sekarang gantian saya mengkritik peserta yang ngawur di penyisihan online. Banyak peserta yang sharing jawaban, seperti mencontek soal ujian.

Tahun ini, panitia Cyber Jawara dan pembuat soal sudah bekerja sangat baik. Soal yang dibuat berkualitas, dan mereka juga mengecek jawaban peserta dengan teliti sehingga kelakuan curang seperti itu bisa diketahui dan didiskualifikasi.

Kutipan komentar dari panitia (Fariskhi Vidyan):

jadi gini ceritanya ya. Ada beberapa tim yang melaporkan ada tim-tim yang minta flag dan juga menawarkan flag dengan bukti screenshot. Jadi ada tim yang kerjaannya minta-minta flag dan mendistribusikan itu ke tim lain dengan syarat minta pap/foto tim. Ada juga yang pakai cara-cara lain. Gara-gara komunikasi pakai telegram jadinya mudah untuk ngelakuin ini.

Selain itu writeupnya juga pada gak bener. Ada yang persis copy paste. Bahkan user terminalnya pun sama persis -,- dan kata-katanya pure copy tanpa ada perubahan satu karakter pun. Banyak juga yang isinya asal-asalan dan bahkan penjelasan yang salah pun diikutin.

Dan katanya ini emang udah terjadi dari tahun2 lalu. Tapi kalau tahun2 lalu nilai akhir itu nilai di web scoring + nilai write up. Makanya yang curang-curang pada datang rombongan. Mana bisa begitu. Untuk tahun ini, ditegasin dengan kasih penalti besar-besaran ke write up yang gak valid, untuk nilai soal yang write upnya gak bener/ngasal dijadikan 0. Ada yang tadinya full score sampai jadi di bawah 500. Yang write up soalnya sama persis juga dikasih penalti dua-duanya.

Saya kesal dengan mentalitas pencontek seperti ini. Dulu waktu saya masih sering ikutan CTF di akhir pekan, banyak juga yang menanyakan apa flag (jawaban) sebuah soal. Sebenarnya kalo ada yang tanya petunjuk (hint) untuk mengerjakan soalnya, biasanya akan saya jawab. Misalnya akan saya jawab dengan: coba SQL injection, atau: coba baca artikel ini.

Untungnya masih ada beberapa yang bertanya seperti itu, dan sampai sekarang pun masih ada yang rajin menanyakan hint dan meminta petunjuk buku atau artikel mana yang perlu dibaca untuk menyelesaikan soal tertentu atau memahami konsep tertentu. Orang-orang seperti ini yang akan sangat dirugikan oleh cheater.

CTF perlu anti contek juga?

Banyak orang mengkritik kalau pejabat pemerintah bobrok, banyak koruptor, dsb. Padahal kelakuan seperti itu dimulai dari kelakuan kecil seperti mencontek ini.  Jangan pikir bahwa mencontek ini tidak merugikan siapa-siapa: di lomba semacam ini, kelakuan curang akan sangat merugikan orang yang jujur dan memiliki keahlian.

Sebenarnya apa sih tujuan main CTF kalau mainnya curang? CTF itu untuk belajar, dan nanti bisa terpakai di dunia nyata di dunia security. CTF juga buat bersenang-senang seperti menyelesaikan puzzle. Kelakuan cheater seperti ini cuma merusak kesenangan orang yang beneran menikmati main CTF.

Andaikan team curang ini lolos ke final, mereka akan bengong melihat soal-soal yang ada. Andaikan panitia tidak teliti, dan semua team cheater yang masuk final, maka ketika ke tahap berikutnya di level ASEAN, mereka akan bengong dan memalukan Indonesia.

Mencegah kecurangan

Sebenarnya ada cara untuk mempersulit kecurangan semacam ini, tapi panitia harus bekerja ekstra. Tiap flag bisa dibuat unik per peserta, jadi flag tidak bisa dishare begitu saja. Tentunya tidak mudah membuat variasi ini untuk semua jenis soal, tapi mungkin bisa dilakukan untuk sebagian soal saja. Ini tidak mencegah peserta untuk sharing cara mereka menyelesaikan soal.

Untuk membuat orang segan berbagi metode, di beberapa CTF, skor untuk satu soal dikaitkan dengan dua faktor: siapa yang menyelesaikan duluan dan berapa banyak yang menyelesaikan soal tersebut.

Peserta yang duluan menyelesaikan soal mendapat skor lebih tinggi dari peserta berikutnya (misalnya 100%, 99%, dst). Jika sebuah soal banyak diselesaikan oleh orang, maka bobot soal dikurangi, artinya soal yang hanya bisa dipecahkan oleh 10 orang bobotnya lebih tinggi dari yang bisa diselesaikan 100 orang.

Dalam metode scoring ini skornya jadi dinamis. Misalnya soal 1 nilai bobot awalnya 1000. Team A menyelesaikan soal 1, dan mendapat skor 1000. Tiba-tiba ada 9 peserta lain yang berhasil menyelesaikan, bobot skor dikurangi jadi 900, sekarang tiba-tiba team A memiliki skor 900 meskipun tidak melakukan apa-apa.

Team yang jagoan, yang bisa menemukan beberapa flag akan malas sharing dengan team lain: buat apa sharing, nanti skor saya akan menurun kalo banyak yang menyelesaikan soalnya.

Penutup

Bagi saya sendiri, CTF untuk bersenang-senang, kenalan dengan banyak orang, dan kadang-kadang juga mendatangkan rejeki dari tawaran pekerjaan. Beberapa CTF (Seperti Flare On) juga menawari peserta untuk mengirimkan resume (jika berhasil menyelesaikan semua challengenya).

CTF yang baik dan fun butuh panitia yang baik, dan juga butuh peserta yang baik. Jadilah peserta CTF yang jujur dan mau belajar. Panitia jadi akan punya lebih banyak waktu untuk membuat soal yang baik daripada susah payah mencegah cheater.