Ada beberapa pertanyaan yang ditujukan ke saya yang jawabannya mudah jika sang penanya bisa membaca source code. Sayangnya skill membaca source code ini sering kali tidak dimiliki, padahal sangat diperlukan oleh programmer dan juga para reverse engineer.
Saat ini mungkin sekitar 90% pertanyaan programming bisa dicari jawabannya dengan Google, dan biasanya jawabannya akan ditemukan di situs stack overflow, di blog seseorang, dan kadang di beberapa situs yang memang membahas topik khusus yang dicari.
Tentunya jawaban-jawaban tersebut bisa ditemukan kalau Anda bisa berbahasa Inggris. Minimal tahu beberapa kata kunci untuk mencari, dan sisanya adalah kemampuan membaca teks berbahasa Inggris. Segala macam pertanyaan sederhana sudah ada yang menanyakan, misalnya “how to split string in <java/c/javascript/..>”. Sering kali jawabannya disertai source code fungsinya, misalnya untuk pertanyaan cara split string di C yang tidak ada di library standar.
Selain berbagai jawaban di stack overflow, dan artikel di berbagai situs, ada juga berbagai buku dan dokumen yang bisa dibaca untuk mencari jawaban. Tapi ada satu sumber yang paling akurat untuk pertanyaan programming: source code. Kadang informasi dari dokumentasi bisa salah atau belum diupdate, tapi informasi dari source code tidak akan salah.
Saat ini sebagian besar software yang dipakai sudah open source. Berbagai sistem operasi sourcenya terbuka (Linux, FreeBSD, OS X, dan masih banyak lagi), compiler dan interpreter (gcc, llvm, go, php, python, dsb), editor text biasa ( emacs, notepad++, vi, dsb) atau bahkan IDE (IntelliJ, Eclipse, Visual Studio Code, dsb). Berbagai game, editor audio, konverter video, dsb semuanya ada versi open sourcenya. Berbagai library sudah ada untuk melakukan hampir apa saja, dari mulai decoding format file sampai mengenali wajah dan suara.
Tidak semua software memiliki dokumentasi yang lengkap. Contohnya: meskipun jutaan orang memakai OS X, dan kernel OS X ini open source, sedikit sekali dokumentasi dan buku mengenai internal kernel OS X. Jika untuk software yang sangat populer saja dokumentasinya tidak banyak, tentunya masih ada ratusan ribu software lain yang dokumentasinya lebih sedikit lagi.
Dokumentasi sebuah fungsi di sebuah bahasa juga sering kali tidak menyebut detail implementasi, yang kadang penting dari sisi security, misalnya dokumentasi mt_rand dan mt_srand di PHP tidak menyebutkan bagaimana proses seeding dilakukan jika tidak dinyatakan secara eksplisit. Tentunya ini bisa ditanyakan ke stack overflow, dan dalam kasus ini ada yang menjawab untuk versi PHP yang spesifik (dan dia mendapatkan jawabannya dari source code).
Dari sisi security, kita bisa menemukan kelemahan dari membaca source code. Dalam kasus mt_rand, sudah pernah ada dua bug ditemukan (tahun 2008 dan 2011). Bug di software yang menggunakan PHP sehubungan dengan penggunaan mt_rand juga masih sering ditemukan (misalnya salah satu yang relatif baru di Oktober 2017).
Membaca source code tanpa alasan yang kuat memang jarang dilakukan orang. Tapi ketika terpaksa, sebaiknya kita mampu membaca kode orang lain. Sering kali kita tidak perlu membaca dalam, biasanya hanya sekedar permukaan saja atau langsung spesifik ke bagian tertentu, tergantung kebutuhan. Membaca source code besar tidak bisa seperti membaca novel dari halaman pertama ke terakhir. Membaca source code besar harus memakai berbagai pendekatan.
Pendekatan pertama adalah skimming, sekedar melihat berbagai file yang ada, lalu membuka file tersebut. Cek apakah ada komentarnya. Hal paling penting adalah mengetahui apakah file tersebut dipakai atau tidak. Sebagian file ternyata tidak dipakai, sebagian ternyata hanya dikompilasi jika fitur tertentu diaktifkan (sedangkan defaultnya fitur tersebut tidak aktif).
Hal penting lain yang bisa didapat dari sekedar skimming adalah: library apa yang dipakai oleh program ini atau program eksternal apa yang dipanggil oleh program ini? Kadang ternyata source code yang kita temukan tidak sesuai harapan karena ternyata hanya membungkus library atau command line lain.
Pendekatan berikutnya adalah menjalankan program tersebut. Ini bisa langsung dilakukan jika program tidak perlu dicompile dan tidak butuh server tertentu (contoh: sebagian program butuh server database). Jika program perlu dicompile, langkah ini juga memberikan banyak informasi. Kita jadi tahu file apa saja yang ternyata dicompile, jadi tahu library apa yang dilink, dsb.
Jika sudah bisa menjalankan program, akan lebih baik lagi jika bisa mendebug program. Beberapa program memang sangat sulit didebug, contohnya kernel Linux di Android butuh setup yang tidak mudah, plus perlu belajar memakai GDB. Tapi jika debugger bisa dipakai, maka ini akan memudahkan pemahaman program. Jika debugger tidak bisa dipakai, maka cara lain adalah menggunakan “print” debugging.
Sebagai catatan: berbagai langkah bisa dilakukan bersamaan. Mengkompilasi source code kadang butuh waktu lama (berjam-jam) atau mendownload requirement (berbagai library yang dibutuhkan) butuh waktu berjam-jam. Sementara kompilasi dilakkan, kode bisa dibaca. Kalau kodenya terlalu besar untuk didownload (contoh: ukuran source code Qt ukurannya ratusan megabyte) bisa source code versi online yang dibaca (misalnya di github).
Sebuah IDE akan sangat membantu untuk membaca program: mencari tahu di mana sebuah fungsi didefinisikan, dari mana saja fungsi dipanggil bisa dialakukan dengan mudah. Untuk memahami program sangat besar (misalnya kernel Linux) biasanya sebuah IDE kurang bisa dipakai (terlalu lambat). Sebagai alternatif, program cross reference (misalnya LXR) bisa dipakai.
Jika program memiliki unit test, maka test ini juga bisa menjadi cara untuk memahami fungsi tertentu. Unit test hanya memanggil satu modul program saja untuk menguji kebenarannya, jadi kita bisa mengerti satu bagian kecil program tersebut.
Perhatikan juga bahwa kadang aplikasi yang populer sudah sangat kompleks karena memiliki banyak optimasi. Contohnya jika hanya ingin memahami membuat web server, maka bisa diawali dengan membaca source code sederhana, lalu kemudian bisa diteruskan dengan membaca yang lebih rumit. Jika Anda belum paham dasar web server, dan langsung membaca source code Apache, maka kemungkinan besar Anda akan bingung.
Beberapa hal butuh dasar teori yang baik, contohnya: memahami source code library kompresi butuh dasar teori mengenai kompresi. Memahami implementasi encoder/decoder MP3 juga akan mustahil jika tidak punya dasar teori mengenai pendengaran manusia (dan banyak konsep matematika).
Hal yang paling penting ketika membaca source code adalah: motivasi. Tanpa motivasi tertentu, membaca source code memang sangat membosankan. Motivasi membaca source code ini bisa banyak, dan tergantung masing-masing orang. Beberapa contoh hal yang pernah memotivasi saya:
- Ada konfigurasi yang tidak jalan, dan saya tidak mengerti kenapa, sedangkan dokumentasinya kurang jelas
- Saya ingin memahami bug tertentu (misalnya ini)
- Saya perlu tahu implementasi algoritma tertentu
- Saya perlu mencari bug untuk tujuan pentesting. Misalnya ada software lama tapi tidak menemukan eksploitnya di web
Semoga semua tips di atas bisa membantu Anda mencoba membaca source code orang lain.