Happy 12th Wedding Anniversary

Hari ini sudah 12 tahun kami menikah. Tiap tahun bingung menulis topik apa yang ingin diposting di hari pernikahan. Beberapa hari yang lalu saya teringat lagi posting saya di tahun 2011 (Terima kasih Tuhan untuk semuanya), dan teringat bahwa ada banyak hal yang perlu disyukuri yang belum dituliskan. Jadi di posting ini saya ingin mengupdate beberapa hal setelah posting tersebut (jadi di tulisan ini yang dimaksud “posting sebelumnya”, adalah posting yang saya sebutkan tersebut).

Honeymoon tahun 2007, kami masih kurus

Seperti saya tuliskan di posting sebelumnya: Agak takut menceritakan hal-hal yang membahagiakan kalau tiba-tiba keadaan berubah dari segala yang indah yang diceritakan di posting ini. Tapi kalau dipikir-pikir, justru itu kenapa posting ini harus ditulis. Kalau tiba-tiba keadaan berubah, saya sudah pernah mengungkapkan syukur untuk apa yang sudah diberikan Tuhan pada saat ini.

Saya bersyukur untuk usia pernikahan kami yang sudah 12 tahun, dan sampai saat ini perasaan saya terhap Risna masih seperti lirik lagu ini:

You're still the one I run to
The one that I belong to
You're still the one I want for life
You're still the one I love
The only one I dream of
You're still the one I kiss good night
2019, sekarang kami tambah gemuk. Katanya Scientists Found That Couples Who Really Love Each Other Tend to Gain Weight

Dibandingkan posting yang sebelumnya, hal-hal masih terus membaik. Setelah menunggu beberapa tahun, kami mendapatkan Joshua. Sekarang keduanya tumbuh menjadi anak-anak yang sehat, pintar, lucu, dan menggemaskan. Dan yang membuat saya bersyukur adalah keduanya sangat rukun.

Waktu tahun 2011 kami tinggal di apartemen, dan sekarang sudah beberapa kali pindah sewa rumah, sampai akhirnya dapat menyewa di tempat yang sangat dekat dengan kantor. Saya sangat bersyukur karena dengan dekat kantor, maka waktu luang saya makin banyak, dan makin mudah untuk pulang ke rumah untuk makan siang bersama keluarga.

Saat ini kami menghomeschool Jonathan, dan Jonathan merasa senang bisa belajar di rumah dan bisa sering jalan-jalan dan bermain game dengan saya. Saya bersyukur memiliki istri yang pintar sehingga bisa mengajari Jonathan berbagai hal sehingga Jonathan bisa mendapatkan pendidikan terbaik. Joshua pun saat ini mulai ingin belajar bersama kakaknya di rumah.

Di dalam bidang pekerjaan, saya masih terus kerasan bekerja di tempat saat ini. Istri saya juga terus mendukung saya di banyak hal yang saya lakukan, termasuk juga di bidang security yang saya lakukan beberapa tahun terakhir ini. Saya bersyukur punya istri yang bisa mengerti excitement saya ketika saya menemukan bug-bug security.

Kami juga bersyukur untuk keluarga besar kami. Saat ini keluarga saya sudah bertambah. Dulu baru satu adik saya yang menikah, sekarang masing-masing sudah menikah dan memiliki dua orang anak. Saya bersyukur kedua orang tua saya masih diberi umur panjang, dan mertua saya bahkan masih bisa mengunjungi kami dan berjalan-jalan ke berbagai tempat di Thailand yang butuh banyak jalan dan bahkan banyak jalan menanjak.

Apakah semua di hidup kami 100% selalu membahagiakan? kadang di satu waktu terasa sesuatu sangat mengecewakan karena kami kehilangan sesuatu yang sepertinya sudah sangat baik, tapi ternyata tidak lama kemudian digantikan dengan hal yang jauh lebih baik lagi. Jadi kalau ada sesuatu yang sepertinya kurang baik, kami tetap berusaha bersyukur karena yakin ini bagian dari rencana Nya. Waktu kecil sampai usia beberapa tahun, Jonathan setiap kali mau tidur, tiap kali jatuh atau nangis minta dinyanyikan lagu Bapa Surgawi, yang potongan liriknya seperti ini:

Semua yang terjadi di dalam hidupku
Ajarku menyadari Kau selalu sertaku
Beri hatiku selalu bersyukur pada-Mu
Karena rencana-Mu indah bagiku

Bapa Surgawi

Setelah kami berdua menyanyikan lirik itu ratusan (atau mungkin ribuan kali), lama-lama meresap juga maknanya. Kami berharap keluarga kami tetap bisa langgeng sampai selamanya, dan membawa berkat bagi banyak orang.

Biasanya kami hanya sekedar makan keluar di hari anniversary, tapi kali spesial karena Opungnya Jonathan sedang di Chiang Mai. Kami jalan-jalan ke Queen Sirikit Botanical Garden. Dari Opung, kami juga mendapatkan hadiah istimewa leontin kalung salib yang bisa dipakai Risna dan bisa juga disematkan ke Jas.

Risna memakai kalung salib hadiah. Biasanya nggak pake perhiasan apapun (bahkan nggak pake cincin ataupun anting)

Penjelasan DNS Flag Day

Tanggal 1 Februari nanti akan ada perubahan bersangkutan dengan DNS (Domain Name System). Secara singkat: berbagai domain yang terdaftar di berbagai DNS server yang tidak compliant dengan standar EDNS akan bermasalah sejak tanggal itu. Sebagai user: kemungkinan beberapa domain menjadi tidak bisa diakses sejak tanggal tersebut (atau beberapa hari/minggu setelahnya).

Sayangnya penjelasan singkat tersebuttidak cukup dan bikin penasaran banyak orang: sebenarnya apa sih yang akan terjadi? Saya coba cari sekilas belum ada penjelasan dalam bahasa Indonesia yang mudah dimengerti, jadi saya akan mencoba menjelaskannya di sini. Sebelum masuk ke penjelasan flag day ini, saya akan mulai dulu dengan penjelasan singkat tentang DNS dan sedikit sejarahnya karena ini ada hubungannya dengan masalah saat ini.

Apa itu DNS?

Pada Internet Protocol (IP) ketika sebuah program melakukan koneksi ke sebuah server berdasarkan nama, maka diperlukan proses translasi dari nama menjadi alamat IP. Proses translasi ini dulunya hanya memakai file teks (hosts.txt) ketika internet belum besar. Sampai sekarang pun ini masih didukung berbagai sistem operasi dengan file hosts.

Ketika jumlah domain makin banyak, maka diperlukan sistem baru. Mulai tahun 1983 sudah dibuat standar DNS (RFC 882 dan RFC 883), dan pada tahun 1984 software berdasarkan standar tersebut sudah mulai dibuat (namanya BIND). Kemudian pada tahun 1987 dibuat standar baru (RFC 1034 dan RFC 1035) menggantikan standar pertama.

Sebenarnya cara kerja DNS cukup sederhana: daripada semua nama dikelola satu pihak, biarlah dikelola masing-masing pihak dengan hierarki tertentu. Kenapa bentuknya hierarki seperti ini? Setiap level dari hierarki ini bisa diatur oleh sebuah otoritas untuk nama tersebut. Saya ambil contoh sebuah universitas ITB yang memiliki banyak jurusan.

  • Tiap jurusan bisa punya subdomain sendiri (misalnya if.itb.ac.id untuk informatika)
  • Tiap jurusan bisa memiliki DNS server sendiri, supaya bisa menambah/mengubah subdomainnya sendiri (tidak perlu repot lapor ke universitas)
  • Di level itb.ac.id perlu diset, bahwa NS record untuk if.itb.ac.id ditangani oleh server tertentu di jurusan informatika

Ini berlaku untuk semua domain, bukan hanya domain organisasi seperti itu. Ketika kita mencari apakah IP untuk sebuah domain blog.compactbyte.com, maka pertama yang dilakukan adalah:

  • Mencari tahu server mana yang menangani .com. Untuk pertanyaan paling atas ini bisa ditanyakan ke root name server (ada beberapa di dunia ini). Kita akan mendapatkan daftar server-server (bisa lebih dari satu) yang menangani domain .com
  • Kita bisa bertanya ke salah satu server tersebut: mana server yang menangani compactbyte.com?
  • Kita bisa bertanya ke server yang menangani compactbyte.com: apa alamat untuk blog.compactbyte.com

Proses di atas dinamakan resolving, dan proses selangkah demi selangkah dari titik atas itu disebut recursive resolving. Tentunya kalau saya membuat program, saya tidak akan menulis sendiri kode untuk melakukan resolving. Sudah ada library resolver yang akan melakukan semua proses di atas.

Server-server di atas memiliki daftar seluruh domain .com di dunia

Sebenarnya dalam dunia nyata, proses seperti itu tidak benar-benar dilakukan karena lambat, tiap kali ingin pergi ke facebook, harus mencari dulu di root server mana yang menangani .com, lalu mana yang menangani facebook.com dst. Dalam praktiknya: kalau sudah tahu nama domainnya, hasilnya akan dicache. Jadi setiap kali proses tidak perlu lagi bertanya ke root server untuk .com karena jawaban sudah dicache.

Supaya lebih efektif biasanya kita memakai sebuah server DNS publik. Ini biasanya dari ISP tapi bisa juga memakai milik Google (8.8.8.8), Cloudflare (1.1.1.1), dan masih banyak lagi. Ketika kita bertanya ke DNS milik ISP kita, maka biasanya jawaban bisa instan karena banyak orang mengakses situs yang sama dan jawabannya masih diingat (dicache). DNS server semacam ini disebut sebagai “caching server“.

Artikel di Wikipedia memberikan gambar yang lebih real mengenai proses ini. Ketika kita bertanya ke DNS milik ISP, maka server tersebut bisa bertanya ke server DNS lain, atau melakukan sendiri proses rekursif yang saya jelaskan di atas untuk mencari IP sebuah domain.


Di dalam server DNS, catatan pemetaan nama ke IP disimpan sebagai sebuah record. Tepatnya lagi ini disebut sebagai address record (singkatnya satu huruf: A). DNS juga memiliki berbagai record lain. Contoh record lain adalah mail exchanger (singkatnya MX) untuk mengetahui server mana yang digunakan untuk menangani email. Kenapa harus ada banyak record? karena kegunaannya berbeda-beda. Contohnya dengan adanya record MX yang terpisah dari record address (A) maka kita bisa punya email yang dihosting di server lain (misalnya Google) dan tidak harus di server kita sendiri.

Saya juga akan menjelaskan sedikit apa yang terjadi waktu kita membeli domain. Domain kita akan didaftarkan di server TLD. Lalu biasanya tempat kita membeli domain akan mengeset otomatis name server ke server milik registar tempat kita membeli. Ini bisa kita ubah agar memakai server lain, misalnya server sendiri atau Cloudflare

Blog ini memakai cloudflare

Beberapa hal yang perlu diketahui adalah:

  • Di dalam mesin (PC/Mobile) ada software resolver
  • Dalam server DNS juga ada resolver untuk bertanya pada server DNS lain
  • Software di berbagai server ini bisa berbeda (tidak hanya ada satu software server DNS, ada banyak, dan masing-masing ada banyak versi)
  • Satu server DNS bisa menangani banyak domain

Extension Mechanism for DNS (EDNS)

Spesifikasi awal DNS kurang fleksibel sedangkan diperlukan banyak fitur baru untuk DNS baik itu untuk meningkatkan performance maupun security. Contoh masalah performance: pada sistem DNS lama ukuran paket yang bisa ditransfer maksimum hanya 512 byte via UDP. Dalam hal security: sebuah DNS server bisa dibajak dengan relatif mudah karena tidak ada signature atau tanda tangan digital yang menyatakan bahwa record yang terdaftar adalah benar adanya.

Pada tahun 1999 diperkenalkanlah Extension Mechanism for DNS. Kemudian standar ini diperbaiki lagi tahun 2013. Jadi EDNS ini sudah dicetuskan 20 tahun yang lalu. Mekanisme EDNS ini backward compatible dengan DNS. Di atas EDNS ini dibangunlah berbagai teknologi baru seperti DNSSEC (Domain Name System Security Extensions).

Untuk mengetahui apakah sebuah server DNS kompatibel dengan EDNS, maka ini yang dilakukan:

  • Resolver akan menanyakan record OPT yang tidak dikenali oleh DNS server lama
  • Server lama (tidak mendukung EDNS) akan mengabaikan OPT, dan menjawab record yang bisa dijawab
  • Server yang baru (mendukung EDNS) akan menjawab bahwa OPT didukung

Sejak diciptakannya, DNS sudah menjadi sistem yang sangat kompleks, dengan 185 RFC yang total halamannya lebih dari 2000 halaman jika dicetak. Ini membuat detail DNS sulit dipahami, dan banyak orang tidak mau pusing memakai software baru yang mendukung berbagai fitur DNS, selama semuanya masih berjalan normal. Ini salah satu alasan kenapa orang tidak mengupdate semua ke server versi terbaru.

Masalah EDNS

Sekarang masalahnya adalah: ada server yang tidak menjawab jika ditanya dengan record OPT, atau jawabannya tidak benar (silakan lihat presentasi ini untuk berbagai jawaban yang salah). Sebenarnya yang diharapkan cuma ini:

  • Kalo kamu mendukung EDNS, jawab yang tegas dengan benar
  • Kalo kamu tidak mendukung EDNS, jawablah bahwa tidak mendukung EDNS

Banyak server yang jawabannya tidak jelas, atau bahkan tidak menjawab. Untuk mengatasi ini, resolver DNS harus bekerja ekstra (istilahnya untuk akal-akalan ini adalah workaround): Jika server ditanya dengan protokol EDNS dan menjawab dengan sempurna, maka diasumsikan server tersebut memang mendukung EDNS. Tapi jika ternyata tidak mendukung, maka ditunggu dulu sampai timeout, terus dicoba lagi ditanya pakai protokol DNS lama (dan kadang tidak menjawab juga, tunggu lagi sampai timeout).

Proses ini tentunya membuat lambat proses resolving. Karena sudah lama sekali standar ini diperkenalkan, maka diputuskan begini:

  • Mari kita stop workaroundnya: kalau jawaban server nggak standar, ya sudah ignore aja servernya (anggap sudah mati)
  • Mari kita buat internet lebih aman dengan mengadopsi standar baru

Kapan ini harus dilakukan? setelah dilihat bahwa sebagian besar (>90% server) sudah mendukung EDNS, maka diputuskan bahwa tanggal 1 Februari 2019 merupakan saat yang tepat. Berbagai DNS publik dunia akan menghentikan workaround yang dilakukan dan berbagai software yang tadinya mendukung workaround juga akan diupdate.

Flag Day

Kenapa namanya flag day? nama ini sifatnya historis. Dulu ada perubahan definisi ASCII di sistem operasi Multics yang dilakukan di Flag Day (hari bendera amerika). Sejak itu istilah ini digunakan untuk perubahan besar pada sistem komputer.

Seperti dijelaskan di atas: software resolver ini ada di device (PC/mobile) kita, dan juga ada di DNS publik seperti ISP dan Google). Biasanya resolver di mesin (komputer/ponsel) kita hanya akan bertanya ke caching server lain di ISP atau DNS publik lain.

Pada flag day, resolver publik yang besar (seperti Google, Quad9, CloudFlare) akan mematikan support untuk workaround. Server DNS untuk domain tertentu yang tidak menjawab dengan benar akan dianggap mati. Sebenarnya yang diharapkan bukan semua server harus support EDNS, tapi harus menjawab dengan jujur dan benar support atau tidak support. Jika kita memakai salah satu server DNS publik tersebut (baik langsung maupun tidak langsung), maka kita akan gagal mengakses domain-domain tertentu.

Untuk sementara waktu, ketika ISP belum mengupdate softwarenya, mungkin situs tersebut masih bisa diakses, tapi setelah beberapa waktu, berbagai ISP di dunia akan mengupdate server/resolver mereka dengan versi terbaru dan akhirnya domain-domain tersebut akan tidak bisa diakses sama sekali jika software DNS pada server yang tercantum di nama domain tidak diupdate.

Sebagai catatan: bukan pemilik domain yang harus mengupdate software, tapi pemilik server DNS yang dipakai di domain tersebut. Jadi misalnya Anda membeli domain dari sebuah registrar dan memakai nameserver registrar, maka registrar tersebut yang harus mengupdate software DNS-nya. Alternatif lain adalah: pemilik domain bisa memakai server DNS lain yang sudah memakai software DNS terbaru.

Selain perubahan di DNS publik, ada juga perubahan kode pada berbagai library resolver dan server DNS, misalnya BIND supaya mendrop workaround. Contoh realnya perubahan kode yang dilakukan di BIND bisa dilihat di URL ini:

https://gitlab.isc.org/isc-projects/bind9/commit/615ebc39e39abd06e97131339cb508a8651ac65c

Apakah domain saya akan baik-baik saja?

Domain yang Anda miliki bisa dicek di situs https://dnsflagday.net. Jika hasilnya OK, maka sudah aman. Jika hasilnya STOP, maka ini sangat berbahaya, dan jika hasilnya SLOW maka sebaiknya setting server diperbaiki atau versinya diupdate. Sebelum panik, cobalah testnya sekali lagi, karena jika server sedang sibuk, kadang hasilnya bisa salah. Jika mengerti penggunaan dig, maka sebaiknya cek juga secara manual dari jaringan yang dekat dengan server (misalnya jika server di Indonesia, cek dari ISP Indonesia).

Ketika hasilnya SLOW atau STOP akan muncul link yang menjelaskan masalah detail eksaknya untuk domain tersebut. Jika situs Anda cuma diakses puluhan atau ratusan orang, response “SLOW” mungkin tidak apa-apa, tapi jika situs Anda sangat ramai, ya sebaiknya diperbaiki.

Seperti yang sudah saya sebutkan sebelumnya, sebagai pemilik domain, yang bisa dilakukan adalah:

  • Pindah name server ke yang sudah mendukung software terbaru
  • Menghubungi pemilik server DNS untuk mengupdate softwarenya

Jika Anda sekedar pemakai sebuah situs, Anda bisa juga memeriksa situs tersebut dan memberi tahu adminnya, supaya dia bisa melakukan perubahan yang perlu. Ini terutama untuk situs yang kecil/kurang populer karena situs besar biasanya sudah menangani ini.

Penutup

Kadang masalah tertentu sulit dijelaskan tanpa mengetahui detail teknis, dan DNS Flag Day ini merupakan salah satu contohnya. Semoga artikel ini cukup bisa menjelaskan. Secara umum: tidak perlu panik. Para admin mungkin harus bekerja ekstra keras, tapi persiapan DNS Flag Day ini sudah cukup lama, jadi harapannya semua akan berjalan lancar pada tanggal yang ditentukan nanti.

Root check dan jailbreak check pada aplikasi mobile

Artikel ini akan membas mengenai metode untuk mengecek root (pada Android) atau jailbreak (pada iOS) dan mengapa pemeriksaan ini diperlukan. Berikut saya akan membahas bagaimana melakukan bypass pengecekan ini supaya seorang pentester bisa melakukan testing pada aplikasi mobile.

Apa itu rooting/jailbreak?

Baik rooting maupun jailbreak gunanya adalah untuk mendapatkan hak akses setara administrator pada mobile device yang kita miliki. Di Android kita bebas menginstall aplikasi apa saja, di iOS sebuah aplikasi hanya bisa diinstall dalam mode development, dengan jailbreak maka aplikasi tambahan bisa diinstall.

Jika device sudah dijailbreak/root maka sebuah aplikasi kemudian bisa diberi hak untuk melakukan apa saja, termasuk juga membaca data privat aplikasi lain. “Melakukan apa saja” bisa berarti positif, misalnya kita bisa mengganti berbagai aplikasi sistem dengan versi yang lebih baik, menghapus aplikasi bawaan sistem yang tidak terpakai, dsb.

Biasanya seseorang dengan sengaja melakukan rooting/jailbreaking pada devicenya sendiri supaya bisa melakukan hal-hal yang sebelumnya tidak bisa diijinkan oleh sistem. Contohnya: kita bisa mengganti isi file hosts untuk memblokir iklan di berbagai aplikasi, atau meningkatkan privasi dengan menggunakan aplikasi tertentu yang mencegat berbagai kebocoran informasi (misalnya dengan XPrivacyLua), atau bahkan sekedar untuk mencurangi game tertentu.

Tapi proses rooting/jailbreak ini juga bisa dilakukan oleh pihak lain, misalnya penjahat atau agen pemerintahan agar bisa menginstall aplikasi untuk mengendalikan ponsel kita, memata-matai menggunakan kamera/mikrofon, mencuri data bank, dsb. Proses jailbreak/rooting ini kadang bisa dilakukan secara remote (diinstall menggunakan eksploit tertentu tanpa sepengetahuan user), dan bisa juga melalui aplikasi yang diinstall dengan menipu user (contohnya di Android bisa berpura-pura jadi aplikasi cheat untuk game populer).

Memeriksa Jailbreak/rooting

Sebuah aplikasi yang penting (misalnya aplikasi bank) tidak ingin uang nasabahnya dicuri oleh program lain. Jadi logikanya begini:

  • Jika device dijailbreak/root, maka ada program lain yang bisa mencuri/mengubah data di aplikasi banking
  • Ada kemungkinan user tidak tahu bahwa devicenya dijailbreak/root, jadi aplikasi perlu mendeteksi dan memberitahu user

Setelah bisa mendeteksi device dijailbreak atau tidak, maka aplikasi bisa melakukan ini:

  • Meneruskan program, tapi memberi peringatan dulu ke user bahwa device dijailbreak
  • Tidak mau meneruskan, karena ada risiko bahwa user tidak mengerti apa itu root/jailbreak serta risikonya dan jika diberi pilihan dalam bentuk pertanyaan apapun maka user akan menjawab apapun asalkan programnya jalan terus

Proses pemeriksaan jailbreak/rooting

Proses pemeriksaan bisa banyak, ini bisa dilakukan dengan coding manual, atau menggunakan library yang sudah ada untuk mengecek ini (misalnya rootbeer). Apapun yang digunakan, biasanya pemeriksaannya seperti ini:

  • Cek apakah file tertentu ada atau tidak, ada file-file standar yang diciptakan oleh program root/jailbreak
  • Cek apakah ada aplikasi tertentu yang biasanya diinstall bersama dengan root/jailbreak
  • Cek apakah direktori tertentu bisa dibaca/ditulis

Untuk Android, ada juga pemeriksaan level sistem yang bisa dilakukan dengan menggunakan Safety Net.

Rooting/Jailbreak untuk pentesting

Sebagai pentester, memiliki HP dengan akses root/jailbreak sangat membantu untuk banyak hal:

  • Di iOS jailbreak dibutuhkan untuk mendekrip agar aplikasi dari app store bisa dianalisis dengan menggunakan disassembler/decompiler
  • Di Android rooting bisa dipakai untuk menginstall berbagai aplikasi seperti wireshark atau nmap (atau bahkan sebuah distribusi seperti Kali Linux) yang memungkinkan kita menggunakan Android sebagai device pentesting

Anti Rooting/Jailbreak detection

Nah sekarang kita memiliki masalah:

  • Memiliki HP yang diroot/jailbreak membantu proses pentesting
  • Aplikasi tertentu tidak mau jalan karena sudah kita root, dan aplikasi tersebut melalukan root/jailbreak detection

Ada beberapa pendekatan agar aplikasi menyangka bahwa device saat ini tidak diroot/jailbreak

  1. Memakai aplikasi penyembunyi, misalnya di Android ada RootCloak, Magisk dsb, di iOS ada Flex 2, Liberty Lite dsb. Tool-tool ini saling berlomba dengan pembuat detektor jailbreak, jadi di masa depan mungkin akan muncul tool-tool lain
  2. Modifikasi aplikasi agar aplikasi tersebut terus jalan walaupun device sudah diroot/jailbreak. Modifikasi bisa dilakukan temporer (dengan skrip Frida) atau permanen (dengan mengedit file smali-nya).

Cara pertama merupakan cara termudah, tinggal install aplikasi tertentu dan harapannya aplikasi akan mau terus berjalan. Sayangnya ini tidak selalu berhasil. Beberapa aplikasi memiliki proses deteksi yang sering tetap bisa mendeteksi anti jailbreak ini. Sebagai catatan: untuk saat ini Magisk bisa tersembunyi dari hampir semua aplikasi. Kelemahan Magisk adalah: kita tidak bisa menginstallnya bersamaan dengan XPosed Framework, jika diinstall bersamaan, maka akan terdeteksi dengan metode Safety Net.

Cara patching selalu berhasil, tapi masalahnya adalah ini tidak mudah. Diperlukan skill reverse engineering untuk mencari tahu di mana proses deteksi dilakukan, dan bagaimana modifikasinya agar aplikasi tetap jalan terus.

Jika aplikasi sifatnya tidak diobfuskasi (not obfuscated), maka pemeriksaan ini biasanya mudah dicari, apalagi jika namanya sangat jelas. Contohnya jika aplikasi memakai library RootBeer, pemeriksaannya sangat jelas karena nama methodnya “isRooted” mudah dilihat.

Pemeriksaan root dengan RootBeer

Tapi jika sebuah aplikasi sudah diobfuskasi (obfuscated), maka semua nama menjadi kurang jelas. Jika kode diatas sudah obfuscated, maka bisa muncul kira-kira seperti ini:

Kode yang sama, obfuscated, tentunya komentar tidak akan muncul ketika kode didekompilasi

Biasanya kode seperti ini bisa dicari dengan melihat berbagai string yang ada. Contohnya, jika root ketemu, maka aplikasi menampilkan dialog dengan string “Ponsel Anda diroot”. Untuk ini kita hanya perlu mencari string “Ponsel Anda diroot” dan bisa ditebak kondisi “if” mana yang perlu diubah.

Tentunya programmer bisa membuat pengecekan ini ini jadi semakin sulit. String bisa dienkripsi, jadi jika dicari tidak akan ketemu (kecuali kita dekrip dulu). Proses pemeriksaan root dan pengecekan juga bisa dipisah. Misalnya di kelas utama hanya mengeset variabel “z” menjadi true jika diroot. Di View yang lain baru kita cek isi variabel z. Proses pemeriksaan bisa dipanggil beberapa kali (jadi perlu dicek dibypass di banyak tempat, misalnya di waktu login, awal transaksi dan di akhir transaksi). Dan masih banyak lagi cara mempersulit agar pemeriksaan root tidak gampang dibypass.

Meski tidak gampang, tapi cara patching ini selalu berhasil jika penyerang cukup bisa memahami aplikasnya. Agar lebih sulit lagi, sebuah aplikasi kadang melakukan pemeriksaan terhadap signature packagenya, agar yakin bahwa aplikasi tersebut tidak diubah (ketika di-sign ulang, signature akan berubah). Dalam kasus ini pemeriksaan signature ini harus dipatch juga oleh pentester.

Protektor

Saat ini ada beberapa software protektor komersial yang memiliki proteksi yang cukup sulit. Contoh bentuk proteksinya:

  • File DEX dienkrip dan diload ketika aplikasi berjalan (runtime)
  • Pemeriksaan dilakukan di native library (harus memahami assembly)
  • Digunakan berbagai teknik antidebug dan anti tamper untuk mempersulit modifikasi

Semua proteksi ini bisa dibypass, tapi akan butuh waktu. Kadang ada orang yang menuliskan dengan detail teknik bypass protektor tertentu, tapi menurut saya ini agak sia-sia: setiap kali ada tulisan seperti itu, pembuat protektor akan mengubah sesuatu (kadang kecil sekali) sehingga langkah detail yang diberikan tidak lagi bisa dipakai.

Menurut saya yang lebih perlu adalah mengajarkan langkah umum bagaimana melakukan reversing. Dengan ini jika ada perubahan maka ilmunya akan tetap terpakai. Saya pernah menuliskan ini di blog saya yang lain.

Penutup

Banyak pentester pemula yang masih bingung dengan teknik pengecekan rooting seperti ini, jadi semoga artikel ini bisa membantu. Saat ini jika Anda tidak memakai XPosed Framework, maka Magisk bisa menyelesaikan 99% masalah deteksi rooting.

Di kesempatan lain saya berencana akan menulis lebih banyak mengenai SSL Pinning dan bagaimana melakukan unpinning. Topik SSL pinning ini merupakan topik sejenis yang sering dianggap sulit oleh pentester pemula. Tidak seperti rooting yang bisa diselesaikan dengan Magisk, berbagai aplikasi memakai teknik SSL pinning yang tidak standar sehingga butuh lebih banyak teknik manual.

Cerita pengalaman pentesting

Sudah beberapa tahun terakhir saya melakukan pentesting eksternal, menjadi freelancer melalui salah satu perusahaan security di Jakarta. Kali ini saya ingin menuliskan cerita pengalaman, dari mulai kenapa pentesting itu fun, dan beberapa pelajaran yang bisa dipetik (lesson learned) dari pekerjaan pentesting ini. Mengenai pembahasan apa itu pentesting dan serba-serbinya (terutama untuk orang yang ingin produknya ditest), bisa baca tulisan saya sebelumnya serba serbi pentest.

Berbagi ilmu bukan berarti saya sudah jagoan. Saya tidak merasa diri saya sangat jago, dan tidak merasa bahwa apa yang saya pentest pasti sudah aman. Tapi saya merasa ada beberapa hal yang saya tahu yang bisa saya bagikan. Sebagian pentester sangat pelit dengan ilmunya supaya kelihatan jagoan (padahal ilmu pentesting ya itu-itu aja).

Karena pekerjaan saya lakukan secara remote, scopenya biasanya terbatas: web dan aplikasi mobile. Tapi kadang ada juga pekerjaan yang melibatkan hardware misalnya kartu NFC (bendanya dikirim ke sini dan dikirimkan balik setelah selesai), atau masuk ke jaringan internal via VPN (yang ini jarang).

Sejauh ini saya tidak pernah berhadapan langsung dengan client, kecuali membalas beberapa hal teknis via email. Jadi lesson learned di sini tidak akan mencakup interaksi dengan client. Saya juga tidak membuat laporan resmi atau melakukan presentasi untuk client, ini dilakukan orang lain, jadi itu juga tidak masuk ke scope.

Saya memulai pekerjaan pentest dengan dasar ilmu yang mungkin berbeda dengan orang lain:

  • Dulu saya pernah bandel waktu di semester pertama kuliah, belasan tahun yang lalu. Saya dan temen saya pernah melakukan beberapa keisengan digital di kampus, seperti mengeksploitasi sistem, memasang keylogger, dsb
  • Setelah hampir DO gara-gara kasus tersebut (bukan gara-gara nilai kuliah), saya menjadi administrator sistem, jadi setelah itu punya dasar sistem operasi dan juga jaringan yang baik untuk OS Linux dan Windows. Sejak saat itu saya hanya hacking for fun, misalnya crack software untuk dipakai sendiri atau mengakali website yang saya pakai
  • Saya punya hobi reverse engineering, tapi tidak benar-benar saya dalami. Contohnya tahun 2006 saya pernah menulis reverse engineering virus Brontok. Saya kerja dengan C++ dan sering kali dalam debugging perlu sampai ke level assembly, jadi masih dengan berbagai hal low level.
  • Saya punya hobi programming dan sudah membuat berbagai macam aplikasi dari mulai web app, mobile app, dan bahkan porting kernel FreeBSD

Ketika mulai pentesting:

  • Saya tidak punya sertifikasi apa-apa
  • Saya cuma kenal sedikit orang security
  • Saya tidak kenal banyak tool yang populer, bahkan waktu itu belum pernah memakai zaproxy ataupun burp suite

Dari hasil ngobrol dengan beberapa orang, kebanyakan pentester mulai dari otodidak. Ada yang mulai dari iseng positif (CTF), ada juga yang masuk dunia security karena hal negatif (tertangkap hacking sesuatu). Beberapa orang berkembang dengan belajar lebih banyak, ada yang kuliah IT, ada yang mengambil sertifikasi, dsb. Sebagian lagi ilmunya tidak berkembang

Kelebihan saya menurut saya adalah: kemampuan membaca kode (baik biner maupun tekstual) dan pengetahuan kriptografi yang cukup baik sehingga bisa menemukan bug kriptografi sejenis hashing bug Mastercard. Bug sejenis ini sudah saya temukan di beberapa payment gateway di Indonesia (sayangnya karena NDA, tidak bisa diceritakan, jadi untuk bug semacam ini saya hanya bilang: bug sejenis Mastercard, tanpa menyebut detail varian masalahnya).

Bug seperti Bug Gojek bisa dengan mudah ditemukan banyak pentester, tapi jika saya membuat aplikasi dengan bug sejenis bug MasterCard atau E-Money Mandiri, saya cukup yakin hanya sedikit pentester yang mampu menemukannya.

Kenapa pentesting?

Kenapa tidak melakukan software development saja? kenapa tertarik pentesting?

  1. Saya memang suka ngoprek apa aja, jadi bagus untuk penyaluran hobi
  2. Memaksa saya belajar banyak teknologi baru. Misalnya ketika ada Angular XSS injection, mau tidak mau saya perlu mengenal angular untuk belajar eksploitasi itu
  3. Pekerjaan pentest sifatnya singkat. Software development biasanya lama. Setelah selesai pun perlu disupport
  4. Seru dan bangga jika bisa menemukan bug fatal. Ini terutama jika dilakukan pada sistem yang sudah live bertahun-tahun, dan baru ditemukan bugnya sekarang.

Apakah selalu menyenangkan?

Tidak ada hal yang semuanya fun, meskipun sebagian besar pekerjaan pentesting sifatnya fun tapi banyak juga yang membosankan. Contohnya jika kita perlu memeriksa sistem informasi yang punya form 10 halaman dan hanya jalan di tablet (jadi tidak bisa memakai skrip auto fill form, atau harus menulis sendiri skrip baru).

Terkadang developer juga membuat gemes karena tidak mengerti bug fatal yang sudah dijelaskan, sehingga kadang sampai perlu membuat video untuk menjelaskan bugnya. Lebih mengesalkan lagi jika mereka dikejar deadline, dan jadinya pentester ikutan dikejar deadline.

Di kasus lain, kadang aplikasinya belum selesai di tanggal yang dijadwalkan, jadi pentester malah jadi tester fungsionalitas aplikasi. Salah satu kasus terparah waktu diberi website dengan halaman HTML statik tanpa https, jadi hal yang bisa dicek sangat minim sekali.

Hal yang membuat sedih adalah Non Disclosure Agreement: kadang saya tidak bisa sharing bug-bug menarik ke orang lain jika itu menyangkut sistem mereka. Bug menarik di sini maksudnya bukan sekedar SQL Injection, XXE atau XSS. Jika bugnya di luar sistem mereka maka saya bisa sharing (contoh: bug alternatif firewall Palo Alto ini juga bisa dianggap bug di luar sistem mereka).

Lesson Learned

Ini adalah beberapa catatan random mengenai berbagai pelajaran yang saya petik

Belajarlah dari orang lain

Belajarlah dari orang lain karena ini cara yang baik untuk memulai. Pelajaran ini bisa didapat dari berbagai cerita orang ataupun dari berbagai tulisan/writeup di web. Setelah mendapatkan gambaran topiknya kita bisa mendalami topik dengan membaca berbagai macam buku atau mencoba berbagai tool.

Karena saya jarang melakukan testing internal (on site), saya juga masih terus belajar dengan melihat report dari orang lain yang mengerjakan testing internal. Tentunya jika kita belajar dari orang lain, kita sebaiknya juga mengajari orang lain, baik dengan memberikan ilmu via obrolan ataupun tulisan.

Saya belum pernah ketemu pentester atau hacker yang punya teknik luar biasa yang tidak diketahui siapapun. Semua ilmu mereka dipelajari dari berbagai writeup dan sharing yang dilakukan orang lain.

Satu orang biasanya tidak cukup

Banyak aplikasi bisa dipentest oleh satu orang, tapi untuk aplikasi super penting, misalnya yang melibatkan uang, sebaiknya pentest dilakukan oleh lebih dari satu orang.

Satu orang pentester bisa membuat kesalahan, dan sumbernya bisa banyak:

  • Skill orang tersebut memang kurang
  • Orang tersebut memiliki skill, tapi pada saat testing mungkin sedang mengantuk, kurang konsentrasi, dsb
  • Jumlah target ada banyak atau fungsionalitas aplikasi terlalu banyak
  • Ada masalah jaringan yang diakses dari jaringan orang tersebut sehingga tool yang dipakai tidak bekerja benar (contoh: bisa saja ISP tertentu menyisipkan iklan jadi eksploitasi gagal), tapi pentester dari jaringan lain ternyata berhasil mengeksploitasi
  • Masalah juga bisa ada di komputer pentester atau tool yang dipakai pentester. Contoh nyata yang pernah saya alami adalah: semua tool berbasis Java (burp suite dan zaproxy) selalu gagal melakukan koneksi ke server tertentu, tapi pentester lain yang memakai Fiddler ternyata bisa melakukan koneksi dengan normal.

Beberapa perusahaan menyewa beberapa group pentester, baik secara bersamaan, ataupun bergantian supaya yakin hasilnya aman. Pekerjaan pentest biasanya dibatasi waktu yang singkat, jadi jumlah bug yang ditemukan terbatas. Harapannya bug-bug besar ditemukan oleh pentester, tapi bukan jaminan bahwa nanti ada hacker atau bug hunter yang berusaha berminggu-minggu bisa tembus ke sebuah aplikasi.

Dari mengerjakan berbagai pekerjaan bareng orang lain, saya jadi belajar memperhatikan bug-bug tertentu yang kadang terlewat oleh saya dan juga tahu tools-tools yang populer dipakai.

Belajar terus informasi terbaru

Di awal kita bisa bertanya secara langsung pada seseorang untuk belajar berbagai hal dasar, tapi setelah itu saatnya kita perlu belajar sendiri “langsung dari sumbernya”. Biasanya sumber awal berbagai teknik baru adalah dari presentasi di security conference. Berbagai security conference akan mengupload file dan video presentasinya sehingga bisa kita baca, jadi tidak perlu ikutan untuk mendapatkan ilmunya.

Berbagai varian dari teknik yang sudah ada juga bisa dibaca dari writeup orang-orang yang melakukan bug bounty. Terkadang isinya membosankan, bug yang sudah sangat sering ditemukan (misalnya XSS), tapi sesekali ada teknik eksploitasi yang menarik yang bisa diambil ilmunya.

Sumber saya mendapatkan berbagai info security terbaru adalah dari reddit /r/netsec dan /r/reversengineering. Biasanya ini sudah cukup untuk merangkum berbagai informasi terbaru. Untuk info tambahan, saya subcribe ke security updates Debian (ada berbagai bug, kadang yang kurang signifikan saya ketahui dari adanya security update package tertentu)

Belajar mencari dan mendalami tool

Seperti saya ceritakan di awal: saya dulu kurang tahu banyak tool. Di awal saya banyak mengimplementasikan tool custom saya sendiri. Setelah memperhatikan pentester lain, jadi tahu berbagai tool yang sudah siap pakai dan lebih matang dari tool buatan saya.

Untuk satu tujuan, biasanya ada banyak sekali pilihan tool. Biasanya saya akan mencoba beberapa tool sejenis lalu memutuskan yang mana yang akan saya pakai, dan kadang saya pakai beberapa sekaligus. Contoh: untuk vulnerability scanner (yang sekedar mencari bug-bug sederhana) saya memakai Nexpose, OpenVAS, dan Arachni.

Sekedar catatan: Jika ada pentester yang hanya menyerahkan hasil scanner, tanpa melakukan testing manual, bisa dipastikan pentester tersebut tidak bekerja. Dalam kasus ini kemungkinan besar ada bug tidak ditemukan, dan Anda akan pusing membaca hasil scan yang masih butuh validasi lagi.

Untuk intercepting proxy, saya akhirnya memilih zaproxy dengan pertimbangan:

  • Gratis (burp professional tidak gratis, sementara versi free tidak bisa menyimpan session)
  • Open source. Fiddler dan burp suite (versi free) gratis tapi tidak open source
  • Cross platform (Fiddler tidak cross platform, belum lama ini baru ada versi beta untuk non Windows)

Setelah saya putuskan, saya kemudian berusaha mendalami jika tool tersebut cukup kompleks. Contohnya dalam kasus zaproxy di atas, setelah paham pemakaiannya, saya mencari tips dan trik di Internet dan ketemu bahwa kita bisa memakai berbagai list dari SecLists untuk input zaproxy dan kita bisa menambah berbagai skrip dan list kita sendiri.

Contoh skrip yang bisa kita buat misalnya:

  • skrip payload generator custom (mencoba-coba berbagai payload yang paling sering berhasil)
  • skrip untuk meng-exclude berbagai situs tidak penting (seperti facebook/google/dsb) dari log

Log IP saat ini

Saya melakukan testing dari rumah dengan IP dinamik, artinya IP eksternal bisa berubah setiap waktu. Kadang pihak yang ditest ingin mengecek apakah benar sebuah request berasal dari penyerang sesungguhnya atau dari kerjaan pentesting.

Dulu saya tidak mencatat ini, tapi untungnya saya masih bisa mengecek beberapa IP terakhir melalui log activity di Gmail. Sekarang supaya aman, saya membuat skrip yang mencatat setiap ada perubahan alamat IP.

Log semua sesi pentesting

Alasan saya tidak memakai burp versi gratis adalah karena tidak bisa menyimpan session. Kadang ada client yang menanyakan laporan beberapa bulan yang lalu, padahal website yang ditest sudah berubah. Dengan menyimpan semua sesi pentesting, bisa dilihat semua request yang pernah diberikan, dan juga bisa dijelaskan jika memang ada bagian website yang sudah berubah.

Lakukan otomasi

Banyak pekerjaan pentest sifatnya membosankan dan bisa diotomasi. Otomasi ini bisa dilakukan dengan menginstall berbagai software atau browser extension untuk tujuan khusus atau dengan membuat skrip sendiri. Contoh sederhana: beberapa aplikasi bank memiliki form yang terdiri atas beberapa halaman (misalnya form aplikasi kartu kredit). Dengan browser extension untuk mengisi form secara otomatis (atau menyimpan isian saat ini), maka kita bisa menghemat waktu ketika testing hal semacam itu.

Saya sendiri sekarang ini punya berbagai kategori skrip:

  • berbagai skrip python custom untuk target tertentu
  • berbagai skrip zaproxy
  • browser extension custom
  • skrip Frida untuk pentest Android dan iOS

Ilmu programming sangat terpakai

Secara umum ilmu programming sangat terpakai dalam pentesting. Selain untuk otomasi seperti yang disebutkan sebelumnya, juga terpakai untuk hal-hal berikut:

  • Source code review: keahlian membaca dan memahami program sangat diperlukan
  • API test. Beberapa perusahaan pernah meminta testing apakah API mereka bisa bocor (sejenis bug yang saya temui di kasus Mastercard), jadi mau tidak mau harus membuat program
  • memperbaiki eksploit (contoh: pernah saya temui eksploit Java yang hanya berjalan di Java versi baru karena memakai kelas yang hanya ada di Java terbaru, sedangkan client masih memakai Java versi sebelumnya)
  • Untuk modifikasi kode. Dalam pentest mobile app, kadang kode perlu dipatch untuk memudahkan testing

Dengan dasar programming yang baik, jumlah bug yang ditemukan dan dieksploitasi bisa lebih banyak.

Kreativitas CTF kadang diperlukan

Mungkin sekitar 90% eksploit dari Internet bisa langsung dijalankan, dan biasanya orang-orang akan menyerah jika eksploitnya tidak jalan hanya karena perbedaan versi software. Biasanya hal seperti ini justru jadi tantangan buat saya.

Hal-hal seperti ini bisa dipelajari dengan mengikuti CTF. Banyak soal CTF luar negeri adalah varian dari bug yang nyata. Dalam kasus ini kita perlu paham eksploitnya dan menerapkannya sesuai dengan situasi

Skill administrasi sistem sangat terpakai

Tidak selamanya kita bisa langsung testing ke target yang live. Kadang pentest dibatasi waktunya, kadang koneksi terlalu lambat dari Thailand ke Indonesia. Di saat seperti itu kadang saya perlu menginstall secara lokal berbagai software supaya bisa ditest eksplotasi secara lokal.

Selain contoh kasus di atas, kadang saya menemui mesin dengan sistem operasi yang sangat tua. Saya biasanya menginstall dulu versi yang sama di sistem lokal untuk mengetes eksploit supaya yakin apakah tidak akan membuat sistem crash.

Pengalaman dan ilmu administrasi sistem yang saya miliki ternyata sangat berguna untuk setup semacam ini. Saran saya jika Anda ingin jadi pentester, minimal bisa mensetup sistem operasi dan berbagai software secara lokal untuk ditest sendiri.

Penutup

Salah satu alasan saya dulu meninggalkan dunia security adalah: saya pikir software akan menjadi semakin aman. Ketika saya belajar mengenai SQL injection belasan tahun lalu, saya punya pikiran seperti ini: bug ini mudah sekali dihindari, dalam beberapa tahun ke depan pasti bug seperti ini sudah nggak akan ditemui lagi.

Bug sql injection ini baru saya temukan Januari 2019, di sebuah subdomain situs sebuah bank yang bisa diakses dari publik

Setelah melakukan pentesting beberapa tahun, ternyata saya salah besar, sampai saat ini bug SQL injection masih cukup sering saya temui. Bug buffer overflow dan sejenisnya juga masih ditemui. Sekarang ini banyak jenis bug baru yang sepertinya akan tetap ada sampai belasan tahun ke depan.

Jadi sepertinya sampai cukup jauh ke depan, pentester masih sangat dibutuhkan. Berbagai tools akan membuat beberapa pekerjaan pentesting jadi sederhana, tapi masih banyak yang lain yang tetap harus manual. Tentunya ilmu pentesting ini harus diupdate terus supaya mengikuti perkembangan teknologi. Tiap teknologi bisa membawa banyak masalah baru misalnya yang trend sekarang:

  • Cloud: sering ada misconfiguration
  • IOT: banyak masalah dasar seperti 20 tahun yang lalu (buffer overflow dsb) dan juga ada berbagai serangan menarik seperti glitch attack para microcontroller
  • BlockChain: masalah pada implementasi, pada enkripsi, pada smart contract
  • machine learning (adversarial machine learning)

Dilihat dari contoh di atas, di masa depan ilmu programming dan devops makin diperlukan untuk memahami masalah security yang lebih kompleks.

Catatan Oprekan Liburan

Pulang ke Indonesia kali ini cukup lama dari tanggal 12 Desember 2018 dan baru masuk kerja besok, tanggal 7 Januari. Sebenarnya nggak banyak yang dioprek selama liburan ini, tapi ini sekedar jadi catatan, plus ada beberapa barang yang baru sampai ketika kami sedang di Depok yang siap dioprek bulan ini.

Liburan kali ini saya berusaha meminimasi bawaan, tapi tetap ingin bisa ngoprek hardware. Kali ini saya coba membawa Pi Zero W yang sudah diberi case USB, sehingga bisa langsung dicolok ke komputer untuk powernya. Saya juga sudah setup agar Pi Zero W-nya mengemulasikan USB Ethernet, jadi bisa langsung diakses dari komputer/laptop.

Ini saya pakai untuk iseng-iseng membaca data dari beberapa kartu NFC yang saya temui. Saat ini tidak ada temuan baru yang menarik.

Waktu libur saya sempat ngoprek dan nemu bug. Sementara ini saya nggak kasih tau dulu bugnya apa, tapi sayangnya tidak ada bounty dari perusahaan tersebut. Tapi ada teman saya di situ yang mengurusin security dan pinter bikin cake, jadi ditodong aja, hasilnya Cheese Cake ini.

Dari sejak beberapa tahun lalu saya teringat sebuah game lama, tapi lupa judulnya, dan bahkan lupa di platform mana (NES atau Sega Mega Drive, dulu punya 2 console ini). Yang saya ingat cuma satu: tokohnya membawa anjing dalam petualangannya, anjingnya bisa dibuat agar terbang mengelilingi tokohnya, terus terbang menerjang musuhnya. Karena sulit mencari deskripsi ini (dan adik-adik saya juga lupa), jadi saya putuskan untuk mencoba memainkan semua game NES dan kalau tidak ketemu, akan mencoba semua game Sega Mega Drive.

Saya menggunakan 3DS untuk mencoba-coba game-game NES-nya, jadi bisa dilakukan di mana saja. Saya juga membawa 3DS dalam liburan ini dan untungnya sampai huruf C sudah ketemu judul yang saya cari: Conquest of the Crystal Palace. Walau sudah menemukan ini, saya masih akan meneruskan mencoba semua game NES.

Ini adegan yang saya ingat

Sesampainya di Chiang Mai, sudah ada beberapa paket menunggu.

Nggak semua isi paket dibahas di posting kali ini

Yang pertama adalah decoder ring hadiah dari Flare-On. Jonathan sedang suka bermain-main sebagai detektif/spy dan senang memainkan ini.

Ini hadiah dari menyelesaikan flare-on 2018

Paket lainnya adlaah Foldscope, mikroskop origami kertas. Ceritanya mikroskop ini dibuat dengan biaya 1 USD (tentunya dijual dengan harga lebih dari harga pembuatan), tapi untuk bisa mendapatkannya tidak bisa beli satuan. Harga termurah adalah 35 USD (dapat 20 Foldscope) belum termasuk ongkos kirim.

Jonathan memakai Foldscope

Beberapa waktu yang lalu kernel Linux mensupport satu arsitektur CPU baru: C-SKY dari China. Ini mungkin akan menjadi arsitektur baru terakhir yang akan ditambakan ke Linux karena sekarang semua memakai arsitektur populer atau RISC-V yang terbuka. Karena penasaran saya membeli satu development board untuk CPU ini dan baru sampai ketika saya sudah di Depok. Saat inielum sempat dicoba lebih lanjut.

Booting CSKY
Ini boardnya

Demikian catatan oprekan kali ini. Semoga tahun ini akan bisa menulis lebih banyak oprekan lain.

Cara bertanya di dunia maya

Ini saya tuliskan karena sering sekali mendapatkan pertanyaan baik langsung maupun di group yang menurut saya tidak jelas dan kemudian membuang waktu semua orang. Jika seseorang bertanya dengan cara yang baik maka kemungkinan dijawabnya akan lebih besar dan lebih cepat.

Cari dulu di Google

Ada satu hal penting sebelum bertanya: cobalah dulu mencari dengan Google. Sekarang ini Google bisa ditanya dengan bahasa natural: “apa ibukota Indonesia?” dan akan dijawab “Jakarta”. Berbagai pesan error juga bisa dicopy paste ke Google untuk mencari jawabannya. 

Kalau sudah mentok, bisa bertanya ke group atau langsung ke seseorang. Misalnya: “saya berusaha mencari tahu tentang topik X, sudah saya cari di Google dengan kata kunci berikut, tapi tidak ketemu jawabannya. Apakah ada kata kunci lain yang lebih baik?”

Salam sambil bertanya

Hal pertama adalah mengenai salam. Di dunia nyata, biasanya kita memberi salam dulu, menunggu jawaban, lalu bertanya. Di dunia maya tidak perlu seperti itu, beri salam sambil bertanya akan lebih efisien. “Selamat siang”, nunggu saya menjawab beberapa jam kemudian, lalu saya jawab “Selamat sore”, beberapa jam kemudian orang tersebut sudah tidak online, tidak tahu tadinya ingin bertanya apa.  Kadang saya sedang online dan bisa langsung menjawab: “selamat siang”, lalu harus menunggu orang tersebut mengetikkan pertanyaan panjangnya.

Akan lebih efisien jika langsung: “Selamat siang, saya ingin bertanya mengenai <jelaskan masalahnya>”. Untuk sebagian pertanyaan, saya sudah tahu jawabannya dan bisa langsung saya jawab, atau bisa saya berikan linknya. Untuk pertanyaan yang lebih rumit, saya bisa mikir dulu untuk menjawab nanti (atau kadang perlu menunggu sampai rumah untuk mengirimkan suatu dokumen atau artikel di komputer saya). Jika pertanyaan via email, maka subjectnya harus jelas, bukan sekedar: “Halo”, “Salam kenal”, dsb.

Tanya di tempat yang benar

Tujuannya ada banyak group, dengan banyak sub group (misalnya untuk  security ada Forensic, Web Security, Reverse Engineering, dsb) adalah supaya diskusinya terfokus. Jika semua group dipakai untuk tanya apa saja, ya buat apa ada banyak group?

Buat apa ada group Python, Javascript, dsb kan sama-sama programming? kenapa nggak boleh nanya SQL injection di Reverse Engineering, kan sama-sama security? Sekalian aja kenapa gak boleh bertanya tentang memelihara burung di group botani, kan sama-sama mahluk hidup.

Kenali topik Anda apa dan tanyakan di group yang sesuai. Jangan maksa bertanya topik yang di luar group. Jika jawabannya adalah: carilah group lain, maka carilah group lain ada banyak daftar group telegram, Facebook dsb di berbagai website.

Pertanyaan harus jelas

Pertanyaan juga sebaiknya yang jelas. Sering kali di sebuah group yang anggotanya sudah beberapa ratus atau bahkan beberapa ribu (Group Telegram anggotanya bisa ribuan) seseorang datang cuma bilang: “Halo, ada yang tau XX” dengan XX adalah sesuatu yang sangat umum, misalnya “Ada yang tahu Tensorflow?” (di group Machine Learning), “ada yang tahu mysql?” (di group Database), “Ada yang tahu heap? (di group Reverse Engineering). 

Kalau setiap anggota group yang anggotanya 2000 orang harus menghabiskan 2 detik dari menerima notifikasi sampai membaca pesannya, Anda menghabiskan total 4000 detik di bumi ini dari semua orang. Ini seperti orang yang memblokir lift karena sedang ngobrol dengan temannya, atau parkir di pinggir jalan yang sudah sempit sehingga orang sulit lewat: semuanya membuang waktu orang lain.

Pertanyaan seperti itu nggak jelas, dan dari ribuan orang kemungkinan ada yang tahu jawabannya (apalagi bertanya di group yang memang membahas topik itu). Masalahnya adalah: Anda ingin tahu apa? misalnya bertanya “Ada yang tahu mysql?”, lalu dijelaskan “mysql adalah dbms bla bla bla”, lalu ternyata yang ingin ditanyakan adalah: “mysql saya gak jalan”. Biasanya kemudian ada yang mengambil asumsi tertentu (Mysql di Linux dengan systemd), dan kemudian langsung menjawab dengan systemcl, tapi ternyata Mysql-nya di Windows. 

Jadi pertanyaan harus jelas:  bukan dengan mulai “siapa yang tahu topik X”, tapi tanyakan dengan jelas apa yang ingin Anda ketahui. Lalu berikan konteks yang jelas: saya sedang berusaha melakukan X tapi gagal. Berikan informasi tambahan yang perlu misalnya: saya coba di Linux, atau saya coba dengan software versi X, atau apapun yang kira-kira penting. Contoh info yang penting: ini saya download dari situs lain karena situs resminya down (ternyata di situs itu cuma ada versi lama), saya compile sendiri (ternyata salah opsi ketika compile), dsb. 

Jika pertanyaan berhubungan dengan kode program, sertakan kode programnya. Jika sangat singkat (1 fungsi kecil) bisa langsung di teks pesan, tapi jika lebih panjang, masukkan ke gist atau pastebin. Jangan mengirimkan image/screenshot source code. Image sulit dibaca, tidak bisa copy paste dengan mudah untuk menunjukkan salahnya, dan kadang tidak lengkap. Jika ada pesan error: tunjukkan dengan lengkap (tapi jika errornya panjang, masukkan ke gist atau pastebin).

Bersiap menerima jawaban

Bagian berikutnya adalah: bersiaplah menerima jawaban. Tanyalah ketika Anda sedang di depan komputer, kadang sudah dijawab dengan sangat cepat, tapi kemudian dijawab lagi dengan “Oh saya lupa versinya, nanti saya cek lagi” atau “OK, nanti saya coba kalo sudah di desktop”. Kenapa nggak nanya pas sedang di depan desktop? Ini terutama jika pertanyaan diajukan ke group dengan ribuan orang di dalamnya, yang biasanya merespon dengan cepat. Yang lebih menyebalkan lagi adalah: sudah dijawab baik dengan jawaban yang sudah jelas, atau direspon dengan pertanyaan klarifikasi, tapi kemudian tidak dibalas sama sekali oleh penanya awal.

Jika jawaban semua orang adalah: pelajari dulu topik X. Maka jangan ngeyel. Jika ada yang bertanya: saya coba bongkar aplikasi X dengan ida pro, kok munculnya “db” semua ya? Setelah dijawab, kembali ke pertanyaan sederhana “ini artinya apa?” dst.  Bisa terlihat bahwa orang tersebut masih buta soal reversing. Semua orang menyarankan coba dulu bongkar aplikasi lain, supaya paham hal-hal dasar, lalu dijawab: tapi saya maunya langsung bongkar aplikasi X. Maunya disuapi belajar langkah demi langkah.

Ada banyak hal yang tidak bisa dijawab dengan singkat (pertanyaanya sangat umum). Coba jika ada yang bertanya: saya bingung konsep diferensial di kalkulus, tolong jelaskan ke saya? Apakah Anda bisa menjelaskannya dengan singkat dan bisa dipahami lewat chatting? (beberapa pertanyaan sejenis ini misalnya: saya bingung konsep managemen memori di C). Jadi jawaban yang bisa diberikan paling-paling: coba baca buku X atau Y, lihat video Youtube, lalu coba-coba sendiri.

Sharing

Terakhir: ucapkan terima kasih. Ini tujuannya selain untuk kesopanan juga untuk menutup topik (bahwa jawaban yang diberikan sudah cukup jelas dan membantu). Kadang masih ada beberapa jawaban ekstra karena dikira topiknya belum selesai.

Bentuk terima kasih yang paling bagus adalah dengan membagikan apa yang Anda tahu. Jika Anda tahu jawaban sesuatu, atau mengerti topik sesuatu, Anda bisa menuliskannya di blog misalnya, supaya orang berikutnya bisa membaca jawaban Anda. Jadi jangan cuma jadi orang yang pasif menerima jawaban  untuk kepentingan sendiri saja.

Jika tidak dijawab

Meskipun sudah bertanya dengan baik dan sopan, belum tentu pertanyaan Anda dijawab, dengan banyak alasan:

  • Memang tidak ada yang tahu jawabannya
  • Orang yang tahu jawabannya sedang tidak ada waktu untuk menjawab, atau mungkin terlewat membaca pertanyaan itu
  • Reputasi Anda jelek, orang sudah malas menjawab
  • Tidak ada kewajiban bagi orang lain untuk menjawab

Coba renungkan juga: berapa kali Anda menjawab seseorang, ketika ada yang bertanya dan Anda tahu jawabannya. Apakah Anda menunggu orang lain yang menjawabnya? atau Anda sendiri orang yang suka membantu orang lain? (bukan hanya mengenai menjawab pertanyaan, tapi secara umum berbuat baik pada orang yang tidak Anda kenal). Menjawab pertanyaan orang lain itu sekedar amal, tidak wajib.

Penutup

Sekalian saya ingin menyampaikan uneg-uneg mengenai berbagai kondisi group teknologi saat ini. Kebanyakan group ini noise nya sangat tinggi (banyak sampahnya) karena banyak anggota yang tidak peduli sopan-santun.

Untuk orang yang suka berjualan, mengirimkan pengumuman seminar dsb, tolong jangan memotong diskusi yang sedang berjalan. Jika ada seseorang sedang di tengah sesi tanya jawab, tiba-tiba ada yang nyelonong memforward message mengenai seminar, itu sangat mengganggu. Kalo saya admin groupnya, sudah saya ban orang yang seperti itu.

Orang-orang tersebut tidak peduli dengan isi group, yang kepikiran cuma begini: oh ternyata group itu aktif (ada message baru), saya forward deh info seminarnya tanpa peduli mengganggu diskusi (sering kali butuh 2-3 detik buat scroll message teks yang panjang sekali). Bahkan sering kali tidak melihat bahwa baru saja beberapa pesan sebelumnya info itu sudah diforward oleh orang lain.

Jangan ngejunk di group yang berfokus pada hal tertentu. Sudah ada group keluarga, group SD/SMP/SMU/jurusan/universitas, group kantor, group temen kompleks dsb yang bisa dipakai untuk ngejunk, kirim-kirim meme, politik, dsb. Kalau semua group hanya dipakai untuk meme politik, buat apa bikin group baru?

Mungkin sebagian akan mikir: ah ribet banget sih, santai aja lah ngejunk. Salah satu alasan banyak orang yang memiliki ilmu jarang mau sharing atau menjawab di group adalah: 90% waktunya dipakai untuk membaca sampah, jadi daripada waktunya dibuang percuma mereka memilih pergi. Ya silakan saja memiliki group penuh sampah, tapi jangan salahkan juga kalau tidak ada orang berkualitas yang mau join. Sebaliknya jangan sakit hati jika dikick dari group yang berkualitas karena sering tidak sopan atau ngejunk.

Hosting email

Meneruskan cerita sebelumnya tentang self hosting, kali ini saya ingin membahas lebih jauh lagi mengenai email. Sekarang ini email (dan nomor HP) menjadi “kunci” bagi banyak layanan. Kebanyakan layanan memerlukan email untuk login dan untuk fitur lupa password. Berbagai notifikasi transaksi keuangan juga masuk ke email. Jika kita kehilangan akses email, akibatnya cukup fatal.

Banyak layanan juga meminta verifikasi via email jika kita login di komputer baru atau IP yang baru. Jadi jika account email kita dihack atau diblokir, kita tidak bisa login. Email ini sangat penting, jika sampai kehilangan akses maka urusannya rumit, seperti jika kita kehilangan dompet. Sekarang setelah tahu betapa pentingnya email ini, kita perlu berusaha mengamankannya.

Contoh verifikasi dari Steam

Email gratisan

Sebagian besar orang menggunakan dua jenis email ini: email kantor dan email gratisan dari berbagai provider (Google/Yahoo/Outlook dsb). Sebenarnya kemungkinan account kita tiba-tiba ditutup oleh Google atau berbagai perusahaan ini cukup kecil, tapi tetap ada. Bisa saja kita sudah taat peraturan, tapi ada kesalahan pada sistem yang membuat account diblokir. Selama lebih dari 14 tahun memakai Google, baru sekali saya mengalami masalah.

Selain Google sebenarnya ada banyak layanan email gratis lain, misalnya protonmail yang terenkripsi, outlook.com dari Microsoft, bahkan Yahoo juga masih memberikan email gratis. Tapi semua email gratisan ini agak mengkhawatirkan karena sebagai pengguna gratis, kita ini “bukan siapa-siapa” dan bisa ditendang kapan saja.

Lanjutkan membaca “Hosting email”