Key Takeaways: Exploit development yang reliable dimulai dari binary analysis yang tepat. Tiga kesalahan fatal yang sering terabaikan: mengabaikan ASLR/PIE, menggunakan offset hardcoded tanpa verifikasi, dan melindungi NX stack tanpa antisipasi. Ikuti walkthrough ini untuk mengubah crash analysis menjadi proof-of-concept yang stabil.
Pernah nggak sih kamu habisin waktu berjam-jam nulis shellcode, tapi pas dijalankan exploitnya cuma crash tanpa alasan jelas? Atau malah shellnya mati sebelum sempat hidup? Masalahnya bukan di shellcode-nya, tapi di binary analysis yang kamu lewati.
Banyak security researcher, bahkan yang udah senior, masih suka skip tahap analisis biner secara mendalam. Mereka langsung lompat ke ROP chain atau shellcode tanpa paham proteksi apa aja yang aktif di binary target. Hasilnya? Exploit yang unreliable, sering gagal di environment berbeda, dan bikin frustrasi.
Binary Analysis: Fondasi yang Sering Di-skip
Sebelum kita bahas kesalahan fatalnya, pahami dulu kenapa binary analysis itu krusial. Setiap program punya proteksi berbeda, mulai dari stack canary, NX (No-Execute), ASLR (Address Space Layout Randomization), sampai PIE (Position Independent Executable). Tanpa analisis mendalam, kamu nggak akan tahu proteksi mana yang aktif dan bagaimana cara bypass-nya.
Binary analysis bukan sekadar cari offset. Ini tentang memahami bagaimana program berinteraksi dengan memori, bagaimana compiler mengoptimasi kode, dan bagaimana sistem operasi memberikan proteksi tambahan. Tanpa pemahaman ini, exploit kamu cuma jadi trial and error yang buang waktu.
3 Kesalahan Fatal dalam Binary Analysis
1. Mengabaikan ASLR dan PIE
ASLR dan PIE itu dua proteksi yang bikin alamat memori berubah setiap kali program dijalankan. Banyak researcher yang nulis exploit dengan alamat hardcoded, padahal alamat itu berubah-ubah. Hasilnya? Exploit cuma jalan di environment testing, tapi gagal di production.
Cara fix: Gunakan teknik info leak untuk mendapatkan alamat runtime, atau manfaatkan gadget yang tersedia di dalam program itu sendiri (return-to-libc atau ROP). Jangan pernah hardcode alamat tanpa strategi bypass ASLR.
2. Menggunakan Offset Hardcoded Tanpa Verifikasi
Sering kali kamu nemu offset dari write-up orang lain, langsung copas tanpa verifikasi. Padahal offset bisa berbeda karena compiler version, flags kompilasi, atau even versi library yang berbeda.
Cara fix: Selalu verifikasi offset dengan crash analysis sendiri. Gunakan debugger seperti GDB atau LLDB untuk memastikan offset yang kamu dapat benar-benar work di environment kamu. Jangan percaya offset 100% tanpa tes.
3. Melindungi NX Stack Tanpa Antisipasi
NX (No-Execute) stack itu proteksi yang mencegah eksekusi kode di stack. Banyak researcher yang pakai shellcode di stack tanpa memikirkan bagaimana bypass NX. Hasilnya? Segfault tanpa penjelasan.
Cara fix: Gunakan ROP chain atau ret2libc untuk bypass NX. Pelajari gadget-gadget yang tersedia di binary atau library seperti libc. Jangan pakai shellcode di stack kalau NX aktif.
Step-by-Step: Dari Crash ke Reliable PoC
Phase 1: Crash Reproduction
Mulai dengan crash yang bisa diulang dan dikontrol. Siapkan environment testing yang isolasi. Gunakan GDB untuk memahami crash state.
Phase 2: Offset Calculation
Hitung offset dengan pattern unik atau cyclic pattern. Pastikan offset konsisten di beberapa run untuk memastikan reliability.
Phase 3: Bypassing Protections
Identifikasi proteksi aktif (checksec atau readelf). Rancang strategi bypass untuk ASLR, NX, stack canary, dan PIE.
Phase 4: Shellcode Integration
Integrasikan shellcode atau ROP chain. Test di environment dengan proteksi aktif untuk memastikan reliability.
Tools Cheat Sheet
- GDB/LLDB: Debugger untuk crash analysis
- pwntools: Python library untuk exploit development
- ROPgadget: Mencari gadget untuk ROP chain
- checksec: Memeriksa proteksi binary
- radare2/Ghidra: Reverse engineering binary
FAQ
Bagaimana cara mengetahui apakah binary menggunakan ASLR?
Gunakan perintah checksec --file=/path/to/binary atau readelf -l binary | grep GNU_STACK. Jika terlihat flag RWE atau NX disabled, berarti ada peluang untuk eksekusi kode di stack.
Apakah offset dari write-up orang lain bisa langsung dipakai?
Jangan langsung dipakai. Offset bisa berbeda karena compiler version, flags kompilasi, atau library yang berbeda. Selalu verifikasi dengan crash analysis di environment kamu sendiri.
Bagaimana cara bypass NX tanpa ROP?
Alternatif lain adalah ret2libc, di mana kamu memanggil fungsi system() dari libc untuk menjalankan shell. Atau gunakan JIT spray jika binary mendukung.
