Skip to content

BAB 6: DETEKSI ANOMALI & ANTI-CHEAT ENGINE (BROWSER SANDBOX SECURITY)

BAB 6: DETEKSI ANOMALI & ANTI-CHEAT ENGINE (BROWSER SANDBOX SECURITY)

Section titled “BAB 6: DETEKSI ANOMALI & ANTI-CHEAT ENGINE (BROWSER SANDBOX SECURITY)”

Layer Browser Sandbox Security pada Gandiwa Stack merupakan arsitektur inspeksi aktivitas di sisi klien (client-side activity inspection) yang dirancang khusus untuk mengunci, memantau, dan menegakkan integritas lingkungan peramban (browser environment) agar bertindak sebagai wadah pengerjaan tugas atau ujian formal yang kebal dari manipulasi. Pada platform berbasis web konvensional, pembatasan gerak-gerik pengguna biasanya membutuhkan instalasi aplikasi native pihak ketiga yang menimbulkan kompleksitas distribusi dan dependensi perangkat yang tinggi dan birokrasi perangkat. Subsistem ini menyelesaikan tantangan keamanan tersebut secara murni di level aplikasi melalui pemanfaatan state window event interceptors dan protokol penalti otomatis transaksional.

6.1 State Window Event Interceptors (Real-time Focus Tracking)

Section titled “6.1 State Window Event Interceptors (Real-time Focus Tracking)”

Untuk memaksa peramban bertindak sebagai lingkungan kerja terisolasi (sandboxed room) tanpa bantuan hak akses tingkat sistem operasi (root/administrator access), Gandiwa Stack mengimplementasikan modul interseptor aktivitas pada file room/page.tsx. Sistem mendeteksi anomali perilaku manipulasi layar memanfaatkan arsitektur event listener asinkronus bawaan standar web.

  • Window Blur State Listener: Sistem memasang pencegat (interceptor) yang memantau fokus kursor dan jendela peramban. Ketika pengguna memindahkan fokus keluar dari area kanvas utama aplikasi, seperti membuka aplikasi komunikasi, mengakses mesin pencari di jendela terpisah, atau memicu fungsi shortcut sistem operasi, peramban langsung menangkap sinyal blur secara real-time.

  • Visibility Change State Listener: Selain memantau fokus, sistem secara aktif memitigasi aksi perpindahan tab (tab switching) atau pengecilan jendela peramban (window minimization) melalui pemanggilan API VisibilityChange. Begitu kondisi document.visibilityState berubah menjadi hidden, peramban secara otomatis menghentikan proses pengerjaan dan membekukan sementara akses antarmuka.

  • Zero-Framework Overhead Execution: Seluruh interseptor ini ditulis menggunakan vanilla JavaScript yang berjalan langsung di atas utas utama (main thread) peramban, memastikan deteksi berjalan instan dalam hitungan milidetik tanpa memicu beban memori tambahan yang dapat memperlambat rendering visual.

6.2 Protokol Penalti Otomatis Transaksional (Dynamic Penalty Engine)

Section titled “6.2 Protokol Penalti Otomatis Transaksional (Dynamic Penalty Engine)”

Ketika interseptor menangkap sinyal pelanggaran (blur atau hidden), sistem tidak sekadar menampilkan peringatan statis, melainkan langsung mengeksekusi runtunan tindakan penalti dinamis secara transaksional.

  • Blokade Antarmuka Fullscreen Interaktif: Begitu anomali terdeteksi, sistem langsung memicu modal interseptor berwarna merah dengan status penolakan penuh (fullscreen overlay blackout). Sistem menegakkan kedisiplinan ruang kerja melalui Stateful Penalty State Machine. Setiap kali sensor mendeteksi hilangnya fokus antarmuka, aplikasi memicu pembatasan interaksi radikal menggunakan penghitung waktu mundur terisolasi. Pelanggaran yang terekam akan memicu fungsi kalkulasi deduksi nilai yang memodifikasi skema data secara linier. Jika akumulasi pelanggaran menembus interseptor kritis, atau fase mediasi waktu habis, sistem mengeksekusi fungsi pemutusan hubungan sepihak, membekukan seluruh modifikasi status dari sisi klien, dan melakukan finalisasi data instan.

  • Mutasi Log Pelanggaran Dinamis via Drizzle ORM: Setiap kali anomali terekam, sistem meningkatkan penghitung variabel penaltyCount. Secara paralel, mutasi data langsung dikirimkan menuju server Edge untuk dicatat ke dalam tabel basis data exam_violation_logs lengkap dengan stempel waktu kejadian (timestamp) dan rekaman waktu kembali pengguna (returnedAt). Setiap satu baris log pelanggaran yang tercipta secara otomatis memotong skor akhir pengguna secara dinamis sebesar 5 poin.

  • Protokol Penguncian Paksa Maksimal (Forced Submission): Gandiwa Stack menetapkan ambang batas toleransi manipulasi yang sangat kaku. Jika penghitung penaltyCount menembus batas maksimal sebanyak 3 kali, atau jika hitung mundur modal 10 detik habis sebelum konfirmasi ditekan, sistem secara otomatis akan mengaktifkan parameter isForced = true. Ruang kerja akan langsung dikunci total, sesi dihentikan sepihak, dan seluruh sisa jawaban dikirim paksa ke database Supabase dengan perolehan nilai absolut 0.

6.3 Sinkronisasi Status Luring & Validasi Kriptografi Lapis Akhir

Section titled “6.3 Sinkronisasi Status Luring & Validasi Kriptografi Lapis Akhir”

Mengingat Gandiwa Stack mengizinkan pengerjaan berjalan dalam mode 90% luring (luring total), protokol penalti ini dikonfigurasi untuk tetap beroperasi secara mandiri di dalam IndexedDB browser.

  • Enkripsi Log Pelanggaran Lokal: Setiap penambahan baris data pelanggaran di dalam IndexedDB browser dibungkus langsung menggunakan lapisan CryptoGuard AES-GCM. Hal ini menutup celah bagi pengguna untuk menghapus atau mereset nilai penaltyCount secara ilegal melalui modifikasi database lokal di peramban.

  • Inspeksi Server Edge Pasca-Online: Saat jaringan internet pulih dan proses penggabungan data (upsert pipeline) terjadi, server Cloudflare Workers akan membedah berkas log dari exam_violation_logs. Server melakukan validasi matematika terhadap rentang waktu antar-pelanggaran guna mendeteksi anomali rekayasa manipulasi jam sistem perangkat (system clock manipulation) sebelum data dinyatakan sah masuk ke pangkalan data PostgreSQL.

FAQ BAB 6: DETEKSI ANOMALI & ANTI-CHEAT ENGINE

Section titled “FAQ BAB 6: DETEKSI ANOMALI & ANTI-CHEAT ENGINE”

Q: Bagaimana sistem ujian Gandiwa Stack mendeteksi kecurangan tanpa memerlukan instalasi aplikasi native atau hak akses administrator? A: Sistem memanfaatkan dua Web Standard API bawaan peramban yang tidak memerlukan izin tambahan: Window Blur Event yang mendeteksi hilangnya fokus dari tab ujian, dan Page Visibility API (document.visibilityState) yang mendeteksi perpindahan tab atau pengecilan jendela browser. Seluruh interseptor ditulis menggunakan vanilla JavaScript yang dieksekusi langsung di main thread tanpa framework tambahan, menghasilkan deteksi anomali dalam hitungan milidetik sejak kejadian terjadi.

Q: Berapa batas maksimal pelanggaran yang ditoleransi sebelum ujian dihentikan secara paksa, dan apa konsekuensinya? A: Gandiwa Stack menetapkan ambang batas toleransi sebesar 3 pelanggaran. Setiap pelanggaran memotong skor akhir sebesar 5 poin dan dicatat dengan stempel waktu di tabel exam_violation_logs. Jika penghitung penaltyCount menembus batas ke-3, atau jika hitung mundur modal 10 detik habis sebelum pengguna mengonfirmasi kembali, parameter isForced = true diaktifkan , sesi dikunci total, seluruh sisa jawaban dikirim paksa ke database Supabase, dan skor akhir ditetapkan menjadi 0 secara absolut.

Q: Bagaimana log pelanggaran ujian diamankan dari manipulasi dalam mode luring? A: Setiap baris data pelanggaran yang ditulis ke IndexedDB browser dibungkus menggunakan lapisan enkripsi CryptoGuard AES-GCM , mekanisme enkripsi yang sama yang melindungi seluruh data master luring. Hal ini mencegah pengguna menghapus atau mereset nilai penaltyCount secara ilegal melalui modifikasi langsung di tab Application DevTools. Saat sinkronisasi terjadi, server Edge melakukan validasi matematika terhadap rentang waktu antar-pelanggaran untuk mendeteksi manipulasi jam sistem perangkat sebelum data diterima ke PostgreSQL.

Q: Apakah mekanisme anti-cheat tetap berfungsi ketika pengguna mengerjakan ujian dalam kondisi tanpa internet? A: Ya. Seluruh logika deteksi anomali , Window Blur Listener, Visibility Change Listener, penghitung penalti, dan enkripsi log pelanggaran , dieksekusi sepenuhnya di sisi klien tanpa ketergantungan koneksi internet. Data log pelanggaran diakumulasikan di IndexedDB browser selama fase luring. Saat koneksi internet pulih, seluruh log dikirim ke server melalui mekanisme sinkronisasi Background Sync untuk divalidasi dan dicatat secara permanen di PostgreSQL.