Simfoni Hooking Asinkron: Memanfaatkan Event Loop Frida untuk Analisis Perilaku Multithreading pada Runtime Aplikasi

Dunia dynamic instrumentation sering kali dipandang sebagai proses linier: temukan fungsi, pasang hook, ubah argumen atau nilai kembali, dan selesai. Namun, ketika berhadapan dengan aplikasi modern skala besar—baik itu aplikasi mobile bertingkat tinggi atau perangkat lunak desktop enterprise—logika bisnis jarang berjalan di atas satu jalur linier. Aplikasi modern adalah sebuah orkestra kompleks yang digerakkan oleh arsitektur multithreading, asynchronous event loops, dan komunikasi antar-proses (IPC).

Melakukan hooking pada aplikasi yang sangat bergantung pada multithreading memunculkan tantangan unik. Jika kita menggunakan pendekatan sinkronis konvensional, kita berisiko menyebabkan deadlock, memperlambat thread kritis (sehingga memicu mekanisme watchdog anti-tamper), atau kehilangan visibilitas atas data yang berpindah dengan cepat di antara thread yang berbeda.

Artikel ini akan membahas secara mendalam bagaimana menguasai Frida Scripting dengan pendekatan asinkron, memanfaatkan event loop internal Frida (Interceptor.attach yang dikombinasikan dengan manipulasi memori non-blocking), serta strategi melacak state aplikasi lintas thread secara presisi.

---

Anatomi Masalah: Mengapa Pendekatan Sinkron Gagal pada Multithreading?

Secara default, saat Anda menggunakan Interceptor.attach() di Frida, skrip JavaScript Anda dieksekusi di dalam konteks thread yang sedang memanggil fungsi target. Perhatikan skenario berikut:

1. Thread A (UI/Main Thread) memicu fungsi otentikasi.
2. Frida mengintersepsi fungsi tersebut, menghentikan sementara ekskusi Thread A, dan menjalankan kode JavaScript Anda di fungsi onEnter.
3. Di dalam onEnter, Anda melakukan operasi I/O yang berat atau menunggu respons dari skrip host menggunakan send() dan recv().wait().

Pada aplikasi yang sensitif terhadap waktu, menahan Thread A terlalu lama akan memicu Application Not Responding (ANR) pada Android atau Watchdog crash pada iOS. Terlebih lagi, jika fungsi yang Anda hook dipanggil oleh ratusan thread pekerja (worker threads) secara bersamaan, eksekusi sinkron akan menciptakan antrean raksasa yang mengubah perilaku asli aplikasi, sehingga menyembunyikan bug atau celah keamanan (race condition) yang sebenarnya ingin Anda selidiki.

---

Arsitektur Event Loop Frida dan Komunikasi Non-Blocking

Untuk menjinakkan kompleksitas ini, kita harus memperlakukan skrip Frida bukan sebagai interseptor linier, melainkan sebagai aplikasi berbasis peristiwa (event-driven). Frida berjalan di atas mesin JavaScript V8 (atau QuickJS pada sistem hemat memori), yang berarti kita memiliki akses ke event loop dan mekanisme asinkron.

Alih-alih memblokir thread target dengan recv().wait(), kita harus mengadopsi pola Fire-and-Forget dengan State Tracking. Kuncinya adalah meminimalkan waktu yang dihabiskan di dalam callback onEnter dan onLeave.

Strategi 1: Thread-Local Storage (TLS) Buatan di Frida

Saat memetakan perilaku multithreading, kita perlu melacak data apa yang dibawa oleh thread mana, tanpa mencampurnya dengan data dari thread lain yang memanggil fungsi yang sama. Frida menyediakan objek this di dalam onEnter dan onLeave yang unik untuk setiap pemanggilan fungsi pada thread yang bersangkutan.

Mari kita lihat contoh implementasi pelacakan alur data lintas fungsi pada thread yang sama:

Interceptor.attach(Module.findExportByName(null, "perform_crypto_operation"), {
    onEnter: function (args) {
        // Menyimpan ID Thread saat ini ke dalam context objek 'this'
        this.threadId = Process.getCurrentThreadId();
        this.payloadPtr = args[1]; // Misal argumen kedua adalah pointer ke data
        
        console.log(`[+] Thread ${this.threadId} memasuki operasi kriptografi.`);
        
        // Alokasikan memori secara asinkron jika ingin menduplikat data tanpa memblokir
        this.clonedData = Memory.alloc(1024);
        Memory.copy(this.clonedData, this.payloadPtr, 1024);
    },
    onLeave: function (retval) {
        // Memastikan kita masih berada di thread yang sama atau memproses data yang benar
        console.log(`[+] Thread ${this.threadId} menyelesaikan operasi. Hasil: ${retval}`);
        
        // Kirim data ke host secara asinkron tanpa menunggu balasan (Non-blocking)
        send({
            event: "crypto_done",
            threadId: this.threadId,
            snapshot: Memory.readByteArray(this.clonedData, 64)
        });
    }
});

---

Melacak Kondisi Balapan (Race Condition) Lintas Thread

Salah satu kasus penggunaan tingkat lanjut dari Frida Scripting adalah menganalisis Race Condition—situasi di mana dua thread mengakses memori yang sama secara simultan dan menyebabkan ketidakstabilan sistem. Untuk mendeteksi ini, kita bisa menggabungkan hooking fungsi dengan pemantauan alamat memori (Memory Watchpoints) secara dinamis.

Misalkan kita ingin mengetahui kapan Thread B memodifikasi struktur data konfigurasi saat Thread A sedang membacanya.

const targetModule = Process.getModuleByName("libnative-lib.so");
const configStructAddr = targetModule.base.add(0x42A0); // Alamat struktur data sensitif

// Monitor akses baca/tulis ke area memori tersebut
Memory.protect(configStructAddr, 4096, 'rw-');

Interceptor.attach(Module.findExportByName(null, "pthread_mutex_lock"), {
    onEnter: function (args) {
        this.mutexAddr = args[0];
        this.currentThread = Process.getCurrentThreadId();
        
        // Catat thread mana yang berhasil mengunci mutex tertentu
        send({
            event: "mutex_lock_attempt",
            threadId: this.currentThread,
            mutex: this.mutexAddr.toString()
        });
    }
});

Dengan skrip di atas, kita memetakan peta sinkronisasi aplikasi. Jika kita melihat ada mutasi pada configStructAddr tanpa dibarengi oleh log mutex_lock_attempt dari thread yang mengeksekusinya, kita telah menemukan anomali dalam manajemen multithreading aplikasi tersebut.

---

Mengamankan State Menggunakan Eksekusi Terjadwal (Script.nextTick)

Ketika Anda perlu berinteraksi kembali dengan runtime aplikasi dari luar (misalnya, menerima instruksi dari skrip Python di komputer host Anda), jangan langsung memanipulasi memori aplikasi di dalam fungsi penanganan pesan recv(). Melakukan hal tersebut di luar konteks thread yang aman dapat menyebabkan korupsi memori.

Gunakan Script.nextTick atau setTimeout bawaan Frida untuk menjadwalkan eksekusi manipulasi Anda pada putaran event loop berikutnya yang aman:

rpc.exports = {
    injectPayloadAsync: function (targetAddressHex, dataArray) {
        const targetAddr = ptr(targetAddressHex);
        
        // Jadwalkan eksekusi agar tidak mengganggu thread utama yang sedang berjalan
        Script.nextTick(function () {
            console.log(`[ * ] Menulis data ke ${targetAddr} secara aman via Event Loop.`);
            Memory.writeByteArray(targetAddr, dataArray);
        });
    }
};

Pendekatan ini menjamin bahwa operasi penulisan memori yang diinisiasi oleh host tidak bertabrakan dengan operasi penulisan internal yang dilakukan oleh engine instrumentasi Frida itu sendiri.

---

Kesimpulan

Beralih dari pemikiran sinkron ke asinkron adalah lompatan besar dalam penguasaan Frida Scripting. Dengan memahami bahwa setiap interupsi fungsi berdampak pada eksekusi thread aplikasi target, kita dapat merancang skrip instrumentasi yang tidak hanya kuat, tetapi juga "gaib" dan minim jejak (low footprint).

Melalui pemanfaatan objek konteks this untuk Thread-Local Storage, pengiriman data non-blocking via send(), dan penjadwalan aman dengan Script.nextTick, Anda kini siap membongkar, menganalisis, dan memanipulasi aplikasi multithread paling kompleks sekalipun tanpa takut akan risiko crash atau deadlock.