Security dari level bit (Bagian 2: Encoding Teks)

Saat ini masih banyak user dan juga programmer yang masih bingung dengan masalah “encoding” teks (misalnya ASCII, ISO8859-1, UTF-8, UTF-16, UTF32, dsb). Ini merupakan hal dasar yang penting, baik untuk keperluan sehari-hari, maupun dalam bidang security. Ada beberapa attack yang berhubungan dengan encoding teks ini.

Encoding teks dan security

Sekilas topik encoding sepertinya hal yang membosankan dari sudut pandang security, tapi ada ada banyak masalah security yang berhubungan dengan encoding teks. Beberapa contohnya:

  • phishing memanfaatkan Unicode characther yang mirip (character ambiguity)
  • phishing menggunakan karakter khusus untuk marker RTL (right to left) dan LTR (left to right)
  • Encoding alternatif untuk bypass filter
  • Overlong UTF-8 encoding attack
  • Membuat shell code yang bisa lolos encoding tertentu
  • Buffer overflow karena kesalahan penanganan encoding

Berbagai hal di atas sulit dijelaskan jika tidak memiliki pemahaman yang baik mengenai encoding, jadi di tulisan kali ini saya akan membahas mengenai text encoding.

Hadiah ke Hong Kong yang saya menangkan tahun lalu pada dasarnya adalah masalah encoding shellcode supaya lolos dari filter UTF-8. Lengkapnya bisa dibaca di blog saya yang lain.

Sekilas mengenai berbagai encoding

Di bagian ini saya hanya akan bercerita dulu mengenai sejarah encoding. Setalah itu di bagian berikutnya saya akan menuliskan lebih detail mengenai berbagai encoding yang disinggung di bagian ini. Memahami sejarah akan menjawab pertanyaan penting: kenapa sih kok ribet banget harus ada banyak encoding? kalau dari dulu cuma ada satu kan nggak ribet.

Dulu teknologi komputer berkembang pesat dimulai dari Amerika, dan ini memberi pengaruh besar terhadap encoding teks. Ketika membaca berbagai buku atau artikel komputer biasanya dijelaskan bahwa ada tabel ASCII yang memetakan huruf ke angka (atau sebaliknya). ASCII ini merupakan singkatan dari American Standard Code for Information Interchange, dan sesuai namanya, ini asalnya dari Amerika.

Sejarah ASCII ini cukup panjang, tapi singkatnya ini adalah standard yang memetakan angka ke simbol (huruf, angka, spasi, tanda baca) serta beberapa karakter kontrol (seperti tanda end of file, new line, dsb). Standard ini hanya memetakan 128 simbol (hanya butuh 7 bit, atau disebut juga sebagai 7-bit character set), karena banyak komputer awal yang memakai 8 bit, maka masih ada 128 simbol yang bisa ditambahkan (istilahnya 8-bit character set).

Berbagai negara menggunakan 128 karakter pertama dari ASCII dan sisanya dipetakan ke karakter masing-masing negara/wilayah. Jadi biasanya kode 65 berarti huruf A di negara manapun, tapi kode 150 bisa menjadi karakter yang berbeda di negara lain. Jadi tiap negara memilki “code page”, atau “character set” yang berbeda. Ada standar ISO-8859 (ISO-8859-1 sampai ISO-8859-16) yang menyatakan “character set” untuk tiap wilayah/negara.

Dengan cara ini kita masih bisa dengan cukup mudah mencampurkan teks dua bahasa antara bahasa Inggris dengan satu bahasa lain (misalnya Thai), tapi jika harus mencampurkan lebih dari itu makan akan jadi sangat sulit. Untuk mengatasi ini maka dibuatlah standard Unicode.

Dalam Standard Unicode, hanya ada satu tabel besar untuk semua huruf di dunia ini, setiap simbol dipetakan ke sebuah nomor code point. Tentunya tabel ini sangat besar, jadi 1 karakter tidak bisa lagi dipetakan ke 8 bit (1 byte). Salah satu cara menyimpan karakter unicode adalah dalam bentuk integer 32 bit (4 byte). Cara ini boros memori (1 huruf butuh 4 byte) tapi mudah diproses.

Dalam kehidupan sehari-hari, jarang sekali kita memakai semua huruf di dunia ini dalam satu dokumen, jadi ada cara untuk menghemat memori: kita hanya memakai 16 bit saja. Karena 16 bit hanya bisa dipetakan ke 65536 karakter maka hanya sebagian unicode saja yang dipakai. Unicode dibagi menjadi banyak “plane” (ini sekedar range code point saja), yang pertama adalah Basic Multilingual Plane (BMP) yang berisi hampir semua karakter di bahasa modern saat iin. Dengan 16 bit, kita bisa memakai BMP saja, dan ada cara khusus untuk memasukkan karakter dari plane lain dengan menggunakan surrogate.

Tapi 16 bit pun kadang masih terlalu boros memori. Berbagai sistem komputer masih sangat berpusat pada American/English, ini meliputi: berbagai perintah command line, berbagai bahasa pemrograman, dan berbagai standar lain. Jadi seringnya kita hanya perlu menyimpan karakter ASCII, dan kadang baru butuh karakter lain. Dengan pemikiran ini maka ada yang namanya encoding UTF-8 (Unicode Transformation Format-8 bit). Dengan encoding ini, karakter yang ada di tabel ASCII hanya perlu 1 byte, karakter lain bisa memakai 2, 3, atau 4 byte. Ini istilahnya adalah variable length encoding. Sebagai catatan ada encoding lain (UTF-1 yang tidak lagi dipakai dan UTF-7 yang juga bukan standar).

Byte order marker

Dalam hampir semua komputer modern, data dibagi dalam byte dan ketika kita berurusan dengan bilangan yang lebih dari 1 byte, kita punya pilihan urutan: little endian dan big endian. Contohnya angka 299 desimal adalah 0x12b dalam heksadesimal. Di memori, ini bisa dituliskan 0x12 0x0b (little endian), atau 0x0b 0x12 (big endian).

Untuk encoding UTF16 dan UTF32, ada pilihan big endian (BE) atau little endian (LE) ketika menyimpan file. Jika data big endian dibaca menjadi little endian, maka hasilnya akan salah, misalnya angka 299 desimal tadi bisa terbaca jadi 2834 desimal. Pada teks Unicode, kita bisa menambahkan BOM (byte order marker) di awal sebuah file untuk menunjukkan file ini disimpan dalam big endian atau little endian.

UTF-32


Seperti telah disinggung di atas:

  • Ini merupakan encoding paling sederhana, hanya array of 32 bit integer
  • ini merupakan encoding paling boros memori
  • untuk mengakses karakter ke n, kita tinggal mengakses elemen integer ke n
UTF32-LE dengan Byte order marker

Kita bisa mencoba membuat file dengan BabelPad (teks editor gratis yang mendukung Unicode dengan baik) dan menyimpannya dalam UTF-32 lalu membukanya dengan editor teks. Ada beberapa variasi yang bisa dicoba:

  • little endian atau big endian
  • dengan atau tanpa byte order marker. Untuk Little endian akan ada FF FE 00 00 di awal dokumen dan untuk big endian 00 00 FE FF
UTF32-LE dengan BOM

Perhatikan urutan byte-byte untuk big endian dan little endian. Untuk teks latin, terlihat sekali boros memori karena banyak byte 00 (dalam huruf latin tiap 1 huruf hanya memakai 1 byte). Sekarang saya contohkan isi teks yang berisi bahasa lain (Thai). Terlihat bahwa karakter Thai memerlukan 2 byte, dan karakter emoji senyum bahagia memakai 3 byte.

UTF-16

Encoding UTF-16 atau UCS-2 (Universal Character Set, 2 Byte) menggunakan 2 byte (16 bit) sebagai unit penyimpanannya. Karena sebagian besar huruf di dunia ini masuk ke basic multilingual plane (BMP), maka sering kali 16 bit sudah cukup (contoh tulisan/bahasa yang masuk ke BMP: Inggris, Arab, Thai, Kanji, Bali, Sunda, Batak). Hanya di kasus tertentu kita perlu menyimpan dengan cara khusus (misalnya emoji yang baru). Di dalam Unicode surrogates.

UTF-16-LE dengan BOM

Kita bisa menyimpan teks sebelumnya dengan encoding UTF-16 dan melihat harsilnya. Terlihat bahwa untuk karakter latin dan Thai, hanya dibutuhkan 2 byte untuk satu karakter, sedangkan untuk karakter emoji dibutuhkan 4 karakter. Empat karakter ini terdiri dari high surrogate (H) dan low surrogate (L) yang perlu dipasangkan untuk merepresentasikan karakter di luar BMP. Formulanya:

0x10000 + (H – 0xD800) x 0x400 + (L – 0xDC00)

Contoh: karakter emoji di contoh tersebut adalah Face with Tears of Joy. Emoji ini memiliki Code Point 128514 atau 0x1F602 dan dengan surrogate dapat direpresentasikan sebagai: 0xD83D 0xDE02. Ini bisa dicek dengan memasukkan angka pertama dan kedua ke formula di atas:

0x10000 + (0xD83D – 0xD800) *0x400 + ( 0xDE02 – 0xDC00)

Sebaliknya kita bisa mendapatkan nilai H dan L untuk sebuah code point C dengan:

L = 0xDC00 + ((C – 0x10000) mod 0x400) H = 0xD800

UTF-16-BE dengan BOM

Di sini mulai ada masalah security: apa jadinya jika ada high surrogate yang tidak memiliki pairing low surrogate? Beberapa sistem mungkin akan mengabaikan bagian itu saja lalu meneruskan memproses datanya, sedangkan sistem lain mungkin akan menolak data yang masuk atau di kasus lain justu meneruskan data apa adanya.

Dalam encoding 16 bit, di bahasa low level seperti C biasanya untuk mengakses karakter ke N kita bisa langsung menggunakan X[n], tapi jika ada karakter surrogate ini tidak benar. Program yang berusaha mengakses dengan cara ini bisa memiliki bug. Cara yang benar biasanya dengan menggunakan iterator, menggunakan accessor khusus (charAt) atau membuat representasi 32 bit di memori agar lebih mudah diakses.

UTF-8

Saat ini UTF-8 merupakan encoding yang palign banyak digunakan, karena sangat hemat penyimpanan (untuk berbagai protokol Internet) dan kompatibel dengan ASCII (untuk 128 huruf pertama). Encoding ini sedikit lebih rumit dari yang lain: untuk code point 0 sampai 0x7f dibutuhkan hanya 1 byte, 0x80 sampai 0x7ff butuh 2 byte, 0x800 sampai 0xffff butuh 3 byte, dan sisanya butuh 4 byte.

Sebagai catatan: UTF-8 tidak memiliki endiannes, tapi kadang file teks di beri byte order mark untuk sekedar menandai bahwa file tersebut menggunakan encoding UTF-8. Adanya BOM kadang membingungkan aplikasi tertentu, jadi kadang ini perlu dihilangkan.

UTF-8 dengan BOM
Tabel diambil dari Wikipedia

Kali ini saya tidak akan membahas detail mengenai UTF-8 karena artikel ini sudah terlalu panjang, dan topik UTF-8 sendiri bisa cukup panjang. Ada beberapa artikel security yang berhubungan dengan UTF-8 ini, misalnya mengenai overly long encoding dan mengenai shellcode yang merupakan teks UTF-8 valid.

ISO 8859 dan encoding lain

Seperti telah dijelaskan sebelumnya bahwa 8 bit tidak cukup untuk mengencode semuanya, maka beberapa konversi bisa dilakukan dan beberapa tidak bisa dilakukan.

  • Teks dalam encoding ISO-8859-X apapun bisa dijadikan Unicode (dengan encoding apa saja)
  • Teks dalam encoding ISO-8859-X hanya bisa dipetakan ke ISO-8859-Y jika semua karakter di teks itu kebetulan ada di target
  • Teks Unicode yang hanya mengandung satu bahasa (atau Inggris dan satu bahasa lain) biasanya bisa diencode ke salah satu ISO-8859-X

Sekarang ini UTF-8 sudah sangat populer dan biasanya encoding lama ini hanya digunakan untuk berinteraksi dengan hardware ataupun software lama.

Penutup

Semoga tulisan ini bisa memberi penjelasan yang bisa dipahami mengenai masalah encoding teks. Saya merasa ilmu encoding teks ini sangat berguna dalam masalah security dan non security, semoga hal tersebut juga berlaku untuk Anda.

Security dari level bit (Bagian 1: Encoding Base N)

Di masa awal kuliah ilmu komputer, mahasiswa diajari berbagai macam hal dasar mengenai komputer. Hal dasar pertama adalah bahwa data bisa dikonversi menjadi bilangan (data di sini berupa teks, foto, video, suara, dsb). Lalu setiap bilangan bisa dikonversi dalam representasi biner supaya bisa diproses oleh komputer digital. Beberapa pelajaran awal arsitektur komputer akan membahas mengenai gerbang logika, lalu bagaimana gerbang logika ini bisa dipakai untuk menjumlahkan. Setelah kita bisa menjumlahkan maka kita juga bisa mengurangi (di sini akan diajarkan mengenai komplemen 2). Setelah bisa menjumlahkan, kita akan bisa mengalikan.

Biasanya mahasiswa masih mengerti konsep-konsep tersebut ketika diajarkan, walau mungkin belum bisa menyambungkan ilmunya dengan komputer yang ditemui sehari-hari. Di masa-masa akhir kuliah, berbagai topik praktis diajarkan. Di sini mahasiswa akan bisa membuat web atau aplikasi praktis. Tapi biasanya ada gap pengetahuan dari hal yang dasar di tahun pertama dengan hal praktis di tahun terakhir.

Hex editor bukan benda ajaib

Contoh yang sederhana adalah masalah manipulasi bit atau pemahaman bahwa berbagai manipulasi data bisa dipahami dari level biner. Kebanyakan orang akan bingung berhadapan dengan hex editor untuk melihat data sebuah file, dan bahkan menganggap kalau hex editor (saja) cukup untuk menghack apa saja.

Supaya praktis, di posting ini saya hanya akan membahas manipulasi bit untuk encoding base N. Di posting lain saya akan membahas encoding teks di level biner (terutama teks Unicode).

Banyak orang yang akan bingung jika diminta mengimplementasikan base64 tanpa memakai library, meskipun sering kali melihat data dalam bentuk base64 dan mengerti pemakaiannya di berbagai tempat (misalnya di aplikasi web). Dalam kebanyakan bahasa pemrograman, programmer memang tinggal pake dan tidak penting untuk tahu detailnya.

Lalu kenapa perlu tahu implementasi base64 (atau base N secara umum) di bidang security? Jika bidangnya adalah analisis malware, banyak malware memakai tabel base64 yang custom. Untuk satu topik khusus ini (base64) sudah ada banyak pembahasan, tool, dan triknya sehingga gampang dicari. Tapi jika tidak paham prinsipnya, jika ada kasus yang sedikit berbeda maka Anda akan kebingungan.

Base64 saya ambil sebagai contoh untuk satu hal yang berhubungan dengan representasi/manipulasi bit tapi masih cukup sederhana. Banyak hal security yang berhubungan dengan representasi bit, contoh praktis sederhana adalah format private key di sebuah SSL certificate. Contoh yang lebih kompleks adalah row hammer attack untuk melakukan bit-flipping pada RAM atau SPA (simple power analysis) untuk mendapatkan key RSA jika implementasinya tidak aman.

Masih kembali ke contoh praktis pemakaian base N:

  • base85: dipakai dalam format PDF
  • base64: untuk berbagai data di web (misalnya data URI di web)
  • base58: dipakai untuk bitcoin address
  • base36: untuk safe url encoding
  • base32: dipakai untuk geohash dan di beberapa game Nintendo lama
  • base16: representasi heksadesimal (hex), dipakai di mana-mana
  • base8: representasi oktal dipakai di mode/permission file di OS UNIX based

Sebenarnya semua di atas hanyalah masalah “basis bilangan”. Dalam biner kita memakai dua simbol saja: 0 dan 1. Dalam oktal kita memakai simbol dari 0 sampai 7. Dalam desimal kita memakai sepuluh simbol dari 0 sampai 9. Dalam heksadesimal, kita menyetujui untuk memakai 0 sampai 9, ditambah dengan a sampai f. Tapi untuk basis bilangan selain itu, ada banyak varian huruf yang bisa kita gunakan.

Untuk contoh berikutnya, saya akan menggunakan data ini yang akan di encode: “Hello”. Untuk memudahkan, saya akan menggunakan encoding ASCII. Di tulisan berikutnya saya akan bahas mengenai berbagai encoding teks yang lain.

Angka di bawah masing-masing huruf adalah nomor huruf tersebut dalam tabel ASCII. Di bawahnya saya tampilkan juga representasi biner dari angka tersebut. Konversi basis 2 ke basis lain yang bisa direpresentasikan dalam 2 pangkat n (8, 16, 32, 64) bisa dilakukan sangat mudah. Representasi oktal jarang digunakan untuk mengencode data, jadi saya akan langsung ke heksadesimal dan base 2 pangkat n berikutnya (base32, base64).

Heksadesimal (base 16)

Dalam heksadesimal (2 pangkat 4), tiap 4 bit kita translasikan menjadi 1 simbol.

Atau singkatnya, kata hello bisa diencode dalam heksadesimal menjadi “48656c6c6f”. Secara praktis ini bisa dilakukan dengan berbagai cara. Misalnya dengan shell command ini:

echo -n Hello| xxd -p

Dan untuk mengembalikannya

echo -n 48656c6c6f|xxd -r -p

Konversi dari biner ke heksadesimal bisa dilakukan dengan tabel semacam ini. Tapi supaya singkat saya bisa mengatakan bahwa simbol untuk base16 adalah: “0123456789abcdef”. Menggunakan string seperti ini akan lebih mudah ketika kita memakai encoding base N yang lebih besar.

Base32

Berikutnya ke base32: untuk ini kita bisa memakai simbol “ABCDEFGHIJKLMNOPQRSTUVWXYZ234567”. Kenapa dipilih karakter-karakter itu, kenapa bukan “ABCDEFGHIJKLMNOPQRSTUVWXYZ012345” (atau angka dulu dan sisanya huruf). Ini dipilih karena beberapa alasan:

  • Supaya tidak tertukar antara 0/O, 1/I
  • Dalam kasus tertentu jika 0..9 ada di depan, nanti disangka heksadesimal

Tentunya jika kita membuat aplikasi sendiri yang tidak perlu interoperasi dengan aplikasi lain, kita bisa membuat tabel sendiri. Tabel yang standar ini diambil dari http://www.rfc-editor.org/rfc/rfc4648.txt

Karena 32 merupakan 2 pangkat 5, kita bisa membagi per 5 bit. Gambar di bawah ini adalah serangkaian bit di gambar pertama, tapi dikelompokkan jadi 5 bit per group. Jadi di kotak pertama tercantum ‘01001’ atau 9 dalam desimal. Karakter ke 9 (dihitung dari 0) dari string “ABCDEFGHIJKLMNOPQRSTUVWXYZ234567” adalah huruf J. Demikian seterusnya.

Kita bisa mengecek hal di atas dengan menggunakan modul base64 (meski namanya base64, modul ini mendukung base 16, 32, 64, dan 85).

import base64 print 
base64.b32encode("Hello") #hasilnya: JBSWY3DP print base64.b32decode("JBSWY3DP") #hasilnya: Hello

Base64

Contoh base64 juga sangat serupa karena 64 bit juga merupakan 2 pangkat n, dengan n = 6. Di contoh base32 kebetulan jumlah bitnya kelipatan 5, nah bagaimana jika jumlah bit tidak kelipatan n? kita biarkan bagian terakhir kurang dari n bit. Berikut ini contohnya dalam base64:

Sebenarnya string di atas sudah cukup sebagai representasi base64, tapi dalam konvensi biasanya ditambahkan padding karakter ‘' jika input bukan kelipatan 3. Contohnya karakter 'A' jika diencode akan jadi 'QQ=‘, dan ‘AA’ jadi ‘QUE=’, tapi AAA karena kelipatan 3 jadi ‘QUFB’.

Kita bisa memakai program base64 untuk mengencode dan decode base64:

echo -n Hello| base64

Dan untuk mendecodenya (gunakan kapital -D jika Anda memakai OS X atau BSD):

echo -n SGVsbG8= | base64 -d

Atau dalam Python:

import base64 
print base64.b64encode("Hello") #hasilnya: SGVsbG8=
print base64.b64decode("JBSWY3DP") #hasilnya: Hello

Sebagai catatan: ada banyak varian base64, tergantung dari karakter yang digunakan (lengkapnya bisa dilihat di Wikipedia: https://en.wikipedia.org/wiki/Base64)

Base58

Seperti sudah dibahas sebelumnya: jika basisnya dalam bentuk 2 pangkat n, maka ini mudah dilakukan, cukup dengan memecah per n bit. Dalam implementasinya ini biasanya dilakukan dengan menggunakan operator SHIFT dan AND. Untuk basis lain, kita bisa menggunakan pembagian berulang. Karena pembagian berulang ini kurang efisien, base yang lain biasanya dipakai untuk menyimpan data yang tidak besar (contohnya: bitcoin address memakai base58, integer dalam PDF memakai base85).

Saya akan memberikan contoh encoding base58 untuk data di atas. Pertama kita gabungkan semua digit biner, lalu konversi bilangan biner menjadi desimal. Konversi ke desimal ini agar sekedar mudah dibaca manusia saja. Angka biner 0100100001100101011011000110110001101111 dalam desimal adalah 310939249775. Kita lakukan pembagian berulang dengan 58 dan catat sisanya. Sisanya ini dipakai untuk menjadi indeks bagi tabel: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Hasilnya kita balik dari bawah ke atas yaitu: 9Ajdvzr. Kita bisa mengecek ini dengan modul base58 di python (perlu diinstall terpisah dengan pip install base58).

import base58 
print base58.b58encode("Hello")
print base58.b58decode("9Ajdvzr")

Penutup

Ini merupakan satu bagian saja dari berbagai tulisan dasar mengenai ilmu komputer dan security. Semoga saya bisa terus sabar menuliskan keseluruhan topiknya.

Adakah satu buku yang bisa mengajarkan topik security ini dari level bit? setahu saya tidak ada. Buku Silence on the wire memberikan overview yang bagus mengenai banyak masalah security dari level bit (bahkan membahas singkat dari mulai algabar boolean), tapi topik-topik lain perlu dipelajari di berbagai teks dasar mengenai ilmu komputer.

Ilmu komputer dan security

Seringkali ketika ingin menuliskan topik security, saya bingung mulai dari mana karena banyak sekali topik security yang butuh dasar ilmu komputer yang baik. Tanpa satu dasar yang baik, penjelasan topik security bisa jauh ke mana-mana. Selain itu saya juga sering dapat pertanyaan yang aneh-aneh.

Contoh pertanyaan konyol yang sering saya dapatkan adalah: saya diberi string dalam base64 dan ditanya apa artinya. Atau bagaimana mendecode string heksa yang adalah sebuah hash. Ini sama saja dengan bertanya: 763748 itu angka apa? bisa berupa apa saja, mungkin nomor Induk mahasiswa, mungkin sisa saldo rekening Anda, 6 digit terakhir nomoer telepon gebetan Anda, PIN iPad kakek Anda, dsb.

Kalau bisa melihat isi gembok, lebih gampang membukanya tanpa kunci

Di sisi lain ada pertanyaan yang benar, tapi sulit dijawab dengan singkat, misalnya mengenai SSL pinning. Saya tadinya ingin menuliskan tentang SSL pinning dan bagaimana caranya membypass hal tersebut. Supaya pembahasannya tuntas, saya perlu membahas banyak hal.

Hal pertama adalah cara kerja SSL, yang melibatkan penggunaan public key cryptography. Di sini perlu diketahui mengenai kunci publik, kunci privat. Kemudian perlu dijelaskan mengapa SSL pinning ini diperlukan. Lalu perlu dijelaskan mengenai certificate (yang bisa ada dalam berbagai format). Perlu dijelaskan juga bagaimana mendapatkan sertifikat SSL ini atau bagaimana membuat sendiri (untuk self signed certificate). Dari sertifikat itu, kita perlu mengekstrak informasi hash public key untuk melakukan pinning.

Itu baru sampai topik dasarnya, belum masuk ke bagian: bagaimana SSL pinning diimplementasikan. Untuk Android bisa dengan kode Java (dengan berbagai library), bisa dengan native code (misalnya dengan libcurl + openssl), bisa dengan fitur Android OS 7 ike atas (Network Security Configuration). Untuk iOS pembahasannya juga akan banyak.

Setelah itu baru bisa masuk ke topik bagaimana bypass SSL pinning. Inipun bisa dengan banyak teknik, bisa dengan patching APK/IPA, bisa dengan Frida, bisa dengan berbagai tool yang sudah ada. Biasanya 99% orang yang bertanya ke saya cuma membaca: pakai tool ini atau pakai skrip frida “universal” ini, dan hasilnya nggak jalan, dan mereka bingung harus meneruskan dari mana.

Untuk memudahkan pembahasan berbagai topik security, saya akan mulai menulis berbagai topik kecil yang terpisah. Sebagian topik ini mungkin akan terlalu dasar bagi banyak orang, tapi daripada saya harus menjelaskan ulang puluhan kali, akan lebhi baik jika saya tuliskan saja.

Rencananya topik-topik yang akan saya bahas yang praktis saja, walau kenyataannya dalam hidup ini kita perlu tahu sangat banyak hal untuk dapat mengevaluasi security sebuah sistem. Contohnya baru-baru ini saya membaca mengenai pentingnya ilmu geometri dalam menemukan bug di library grafik.