REA: Reverse Engineering Berbasis Bukti untuk Red Teaming

Source code menjelaskan implementasi yang bisa kita baca. Threat model menjelaskan aset dan aturan yang ingin dijaga. Namun, pengguna menjalankan aplikasi yang telah dibangun dan dikemas. Ada bundle, preload, native module, konfigurasi, dan layanan yang belum tentu identik dengan asumsi saat review.

Reverse engineering membantu memeriksa bagian tersebut dari artefak dan perilaku yang dapat diamati. REA dalam tulisan ini merujuk pada Reverse Engineer Anything, proyek morluto/rea, yang menyediakan CLI dan MCP server untuk membantu investigasi itu.

Ini bagian penutup dari seri:

Tree-sitter: membaca struktur kode.
STRIDE: memetakan ancaman.
REA: memeriksa artefak dan merancang pengujian red team.

Contohnya tetap aplikasi fiktif Laporan. Kita ingin memahami jalur ekspor dari renderer ke layanan, kemudian menguji apakah akun biasa dapat mengakses laporan tenant lain. Skenario dan format catatan di bawah adalah ilustrasi, bukan hasil menjalankan REA terhadap aplikasi nyata.

Reverse engineering menjawab pertanyaan yang berbeda

Saat source lengkap dan sesuai dengan build tersedia, membacanya langsung sering menjadi langkah paling efisien. Reverse engineering berguna ketika pertanyaan bergantung pada apa yang benar-benar dikemas atau dijalankan:

Apakah preload pada paket distribusi mengekspos API yang sama dengan source?
Apakah bundle masih memuat jalur ekspor lama?
Native module mana yang mengerjakan operasi sensitif?
Apakah perubahan antarrilis menyentuh jalur yang terkait kontrol akses?
Request apa yang benar-benar muncul pada skenario runtime tertentu?

Ada tiga jenis pekerjaan yang perlu dibedakan. Analisis statis membaca artefak tanpa menjalankan kode target. Analisis dinamis mengamati target ketika berjalan dalam skenario tertentu. Rekonstruksi membuat model atau implementasi berdasarkan bukti yang diperoleh. Keberhasilan salah satunya tidak otomatis menjamin kelengkapan dua lainnya.

Apa yang disediakan REA?

REA menghubungkan agent dengan alat analisis melalui Model Context Protocol, atau MCP, dan menyediakan akses lewat terminal. Pada target native, ia dapat memakai provider analisis seperti Ghidra, Hopper, atau IDA. Analisis JavaScript statis memiliki jalur tersendiri yang tidak memerlukan native decompiler. Kebutuhan host dan provider mengikuti target; lihat dokumentasi resmi REA.

Hubungan komponennya dapat dibaca seperti ini:

Pertanyaan analis
      |
Agent atau CLI
      |
REA memilih workflow yang sesuai
      |
Pembaca artefak / analisis JavaScript / provider native
      |
Pengamatan + lokasi bukti + hubungan + keterbatasan
      |
Analis menilai hipotesis dan menentukan pemeriksaan berikutnya

MCP adalah antarmuka pemanggilan tool. Ia tidak memberi jaminan bahwa interpretasi agent benar. Nilai hasil analisis tetap bergantung pada identitas artefak, kemampuan provider, cakupan pemeriksaan, dan kualitas penalaran atas buktinya.

Pilih workflow dari jenis target

Target	Titik awal yang relevan
Direktori JavaScript/Electron atau ASAR	`analyze_javascript_application`
Binary native	`open_binary`, lalu pencarian fungsi, referensi, dan analisis terarah
Assembly .NET	Inspeksi metadata dan managed code yang didukung
APK Android	Inspeksi paket dan kode dengan kebutuhan engine yang sesuai
Aplikasi atau halaman yang sedang berjalan	Workflow observasi runtime yang dipilih secara eksplisit

Tabel ini membantu memilih arah, bukan daftar kompatibilitas lengkap. Periksa tool yang tersedia pada versi terpasang. Dokumentasi branch main dapat mendeskripsikan kemampuan yang belum masuk ke rilis yang dipakai.

Persiapan: ikat investigasi pada artefak tertentu

Untuk contoh Laporan, pilih paket distribusi yang memang masuk scope pengujian, misalnya app.asar dari build staging yang ditentukan. Catat versi aplikasi, platform, asal paket, waktu pengambilan, ukuran, dan hash SHA-256. Simpan salinan asli agar hasil dapat diulang pada byte yang sama.

Hash membantu membedakan artefak, tetapi tidak membuktikan penerbit atau keamanan paket. Informasi asal distribusi dan tanda tangan, bila tersedia, memiliki peran tersendiri. Jangan menganggap paket versi sama pasti memiliki isi identik di semua platform.

Pasang dan hubungkan REA melalui petunjuk instalasi resminya. Memasang skill memberi panduan workflow; pendaftaran MCP server dan ketersediaan engine adalah hal yang berbeda. Catat versi paket serta provider yang benar-benar digunakan agar investigasi dapat direproduksi.

Untuk materi ini, mulai dari analisis statis. Observasi runtime dilakukan sebagai langkah tersendiri setelah tujuan, akun, data uji, dan efek operasinya ditentukan.

Langkah 1: baca struktur aplikasi yang dikemas

Dengan CLI REA yang sudah tersedia, pola perintah untuk direktori aplikasi atau ASAR adalah:

rea analyze-javascript-application /lab/laporan/app.asar --json > laporan-evidence.json

Ganti path dengan lokasi absolut artefak yang dipilih. Jalankan di direktori investigasi dan gunakan nama output baru agar catatan sebelumnya tidak tertimpa oleh redirection shell. Perintah ini membaca target JavaScript secara statis; ia bukan perintah untuk membuka atau menjalankan aplikasi.

Untuk MCP, panggil tool analyze_javascript_application dengan input seperti berikut, sesuai schema versi yang tersedia:

{
  "input_path": "/lab/laporan/app.asar",
  "format": "asar",
  "detail": "summary"
}

Pada workflow yang didokumentasikan, ringkasan dapat menyertakan parent_evidence_id untuk membaca bagian Evidence yang disimpan dalam sesi. detail: "summary" mengurangi isi yang dikirim ke agent; pembatasan file sumber adalah pengaturan cakupan yang berbeda. Jangan menyamakan output ringkas dengan analisis atas sebagian file. Rinciannya ada di panduan rekonstruksi artefak JavaScript.

Mulai dengan pertanyaan sempit: di mana entry main process, preload, dan renderer? Modul mana yang mendaftarkan reports:export? Apakah terdapat native add-on atau import dinamis yang hubungannya belum terselesaikan?

Langkah 2: ikuti satu fitur, bukan seluruh aplikasi sekaligus

Dari inventaris tadi, pilih jalur ekspor. Untuk ilustrasi, bentuk hubungan yang ingin kita periksa adalah:

renderer: window.reports.export(reportId)
       |
preload: API bridge yang terbatas
       |
IPC: reports:export
       |
main: exportReport(request)
       |
API SaaS: buat job dan ambil hasil

Ini peta pertanyaan, bukan jaminan bahwa semua panah pasti ada. Periksa lokasi kode yang mendukung tiap hubungan. Bila salah satu panah hanya disimpulkan dari string channel yang sama, tandai sebagai inferensi sampai ada bukti yang lebih kuat.

REA menyediakan workflow graph dan tracing untuk JavaScript, termasuk trace_application_feature dan trace_javascript_semantics pada versi yang mendukungnya. Hasil tersebut perlu dibaca bersama provenance dan keterbatasan hubungan. Jalur statis yang ditemukan tidak otomatis berarti jalur itu dapat dicapai oleh akun tertentu saat runtime. Lihat panduan workflow JavaScript.

Kaitannya dengan Tree-sitter di sini bersifat metodologis. Query pada post pertama membantu membuat inventaris dari source; REA menambah workflow untuk artefak dan hubungan yang perlu ditelusuri. Seri ini tidak mengasumsikan bahwa REA memakai query Tree-sitter kita atau bahwa keduanya otomatis tersambung menjadi satu pipeline.

Apa yang perlu diperiksa pada Electron?

Untuk TB1 dari post STRIDE, periksa API yang diekspos preload, validasi pengirim IPC, bentuk payload, dan operasi yang dapat diminta renderer. Nilai juga konfigurasi contextIsolation, sandbox, dan penggunaan Node.js pada konten yang tidak dipercaya. Panduan keamanan Electron menjelaskan kontrol-kontrol ini.

Pola yang ingin dicari adalah API bridge yang cukup sempit untuk kebutuhan fitur, dengan validasi pada komponen yang memiliki kewenangan. Mengaktifkan isolasi tidak otomatis memperbaiki handler yang menerima operasi terlalu luas. Demikian juga, kontrol main process tidak menggantikan otorisasi laporan pada API SaaS.

Langkah 3: bedakan pengamatan, inferensi, dan hal yang belum diketahui

Disiplin terpenting bukan jumlah tool call, melainkan ketepatan kalimat yang kita tulis setelah membacanya.

Jenis pernyataan	Contoh pada Laporan
Pengamatan	Bundle yang diperiksa memuat pendaftaran channel `reports:export` pada lokasi tertentu.
Inferensi	Channel itu kemungkinan menghubungkan bridge renderer dengan fungsi ekspor.
Belum diketahui	Apakah role viewer boleh mencapai jalur itu dan apakah server memeriksa tenant.
Hasil uji terbatas	Pada build dan akun uji tertentu, permintaan lintas tenant ditolak.

Pernyataan terakhir memerlukan uji yang benar-benar dijalankan. Jangan memindahkan hipotesis ke kolom “tervalidasi” hanya karena agent membuat penjelasan yang terdengar meyakinkan.

Kontrak MCP REA membedakan identitas Evidence, hasil yang dinormalisasi, cakupan, dan keterbatasan. Saat meninjau hasil, simpan record lengkap yang relevan dan rujuk lokasi sumber atau alamat fungsi. Kumpulan hasil yang kosong perlu dibaca bersama status cakupannya; ia bisa berarti tidak ditemukan dalam lingkup yang diperiksa, bukan tidak ada di seluruh aplikasi.

Pseudocode bukan source asli

Untuk target native, decompiler dapat menghasilkan representasi yang membantu membaca alur. Nama variabel, tipe, dan bentuk kontrolnya dapat merupakan hasil rekonstruksi. Optimisasi, inlining, indirect calls, dan simbol yang hilang membatasi interpretasi.

Jika suatu kesimpulan bergantung pada argumen fungsi atau cabang tertentu, periksa referensi, instruksi, dan konteks pemanggil yang tersedia. Jangan menilai kelemahan hanya dari nama fungsi yang dihasilkan decompiler. Panduan native REA menjelaskan pemeriksaan fungsi dan batas kemampuan provider.

Langkah 4: susun hipotesis red team dari TM-01

Threat model kita menyatakan bahwa akses lintas tenant harus ditolak. Analisis artefak membantu mencari entry point yang cocok. Berikutnya, tulis hipotesis yang menyambungkan keduanya:

Jika akun viewer tenant A dapat meminta ekspor melalui jalur client yang tersedia, dan layanan tidak memeriksa akses terhadap laporan tenant B, maka akun itu dapat memperoleh laporan di luar kewenangannya.

Ada beberapa syarat yang harus terbukti: jalur dapat dicapai, request sampai ke layanan, kontrol akses tidak menahan operasi, dan hasil yang dikembalikan benar-benar milik tenant lain. Menemukan salah satu syarat tidak membuktikan keseluruhan jalur.

Ini juga memperjelas kemampuan awal adversary: pengguna terautentikasi yang dapat memodifikasi request dari client miliknya. Kita tidak perlu mengasumsikan akses admin, kompromi server, atau kemampuan lain yang belum diberikan oleh skenario.

Langkah 5: jalankan pengujian dengan ukuran keberhasilan yang jelas

Rules of engagement menentukan build dan lingkungan, akun yang digunakan, rentang waktu, data yang boleh disentuh, batas pekerjaan, serta kondisi penghentian. Untuk latihan ini, gunakan dua tenant uji dan laporan sintetis dengan marker berbeda. Kita cukup membuktikan apakah satu objek yang ditentukan dapat diakses sesuai izin.

Urutan pemeriksaannya:

Uji kontrol positif. Pastikan akun A dapat mengekspor laporan A yang memang diizinkan. Jika gagal, hasil uji negatif sulit ditafsirkan.
Uji isolasi objek. Minta laporan uji B dari akun A melalui jalur yang disepakati, dengan satu perubahan yang dapat dijelaskan.
Periksa seluruh hasil. Tinjau keputusan API, status job, pengambilan hasil, dan marker isi. Jangan berhenti pada status HTTP awal.
Korelasikan telemetry. Cocokkan request ID, job ID, actor, tenant, objek, dan waktu pada catatan yang tersedia.
Nilai deteksi serta respons. Periksa alert yang diharapkan dan kemampuan tim mengidentifikasi skenario sesuai tujuan engagement.

MITRE memakai emulasi perilaku adversary untuk menguji pertahanan secara relevan. Karena itu, hasil kegiatan red team sebaiknya menjelaskan konsekuensi operasional dari perilaku yang diuji. Pemetaan ATT&CK berguna bila perilaku dan konteksnya cocok; jangan memaksakan nomor teknik pada setiap bug aplikasi.

Baca hasil pencegahan dan deteksi secara terpisah

Hasil kontrol akses	Hasil deteksi yang disepakati	Makna untuk skenario ini
Akses ditolak	Sinyal yang diharapkan muncul	Pencegahan dan observasi bekerja pada kasus uji.
Akses ditolak	Sinyal tidak muncul	Pencegahan bekerja; jalur logging atau deteksi perlu ditinjau.
Akses berhasil	Sinyal muncul	Ada kegagalan kontrol akses meskipun perilaku terlihat.
Akses berhasil	Sinyal tidak muncul	Ada kegagalan kontrol akses dan kesenjangan observasi.

Tidak setiap penolakan normal perlu menjadi alert. Harapan deteksi harus ditentukan dari skenario dan kebijakan tim. Catat pula bila telemetry belum tersedia atau waktu tunggunya belum cukup; “belum dapat dinilai” lebih akurat daripada langsung menyebutnya gagal.

Laporan yang bisa dipakai untuk memperbaiki sistem

Simpan identitas artefak dan lingkungan, kemampuan awal akun, langkah minimal yang dilakukan, hasil yang diharapkan, hasil aktual, bukti yang relevan, dampak, serta keterbatasan. Hubungkan ke ID ancaman seperti TM-01.

Misalnya, jika uji benar-benar membuktikan kebocoran, judul yang berguna adalah “Viewer tenant A dapat mengunduh laporan tenant B melalui ekspor”. Penjelasannya perlu menunjukkan objek uji, identitas yang dipakai, dan bagian jalur yang gagal menegakkan izin. Kalimat “REA menemukan celah” tidak cukup menjelaskan mekanisme maupun tanggung jawab perbaikannya.

Pisahkan temuan kontrol aplikasi dari kekurangan telemetry agar pemilik perbaikannya jelas. Lindungi Evidence asli dan buat salinan tersanitasi untuk dibagikan. Token, data pelanggan, atau path pribadi tidak perlu ikut masuk laporan pembelajaran.

Retest harus memeriksa aturan, bukan hanya satu payload

Setelah perbaikan, ulangi kasus yang membuktikan masalah, kontrol positif, akses tenant lain, dan role yang berbeda. Periksa juga job asinkron serta pengambilan hasil agar penolakan di satu endpoint tidak menyisakan jalur lain. Gunakan artefak build baru dan catat identitasnya.

Perubahan nama fungsi, string, atau pseudocode antara dua build hanya menunjukkan perubahan pada representasi yang diamati. Ia belum membuktikan perbaikan perilaku. Pemeriksaan artefak membantu mengarahkan retest; hasil pengujian menentukan apakah aturan keamanan benar-benar dipenuhi pada cakupan yang diuji.

Jika persoalan awalnya adalah konteks tenant yang hilang saat masuk queue, perbaikan yang baik juga perlu mempertahankan konteks itu di worker dan hasil ekspor. Pelajarannya harus kembali masuk threat model dan pengujian regresi, supaya tidak hilang setelah engagement selesai.

Peran AI dan batas red teaming pada seri ini

Agent dapat membantu merangkum graph, menyusun pertanyaan, dan menghubungkan lokasi bukti. Namun, teks di dalam artefak adalah data yang sedang diperiksa. Komentar atau string yang berisi instruksi kepada agent tidak memiliki otoritas untuk mengubah tujuan investigasi atau menjalankan perintah.

Analisis REA berjalan lokal, tetapi keluaran tool yang diberikan kepada agent dapat masuk ke penyedia model sesuai konfigurasi dan kebijakan layanannya. “Tool lokal” tidak otomatis berarti semua informasi tetap berada di mesin. Pertimbangan ini juga dijelaskan dalam FAQ REA.

Red teaming dalam seri ini berfokus pada keamanan aplikasi dan kemampuan pertahanan organisasi. AI red teaming dapat menambah sasaran lain, seperti prompt injection, penyalahgunaan tool, dan kebocoran konteks model. Penggunaan agent untuk reverse engineering sendiri tidak otomatis berarti kita sedang melakukan AI red teaming; sasaran evaluasinya yang menentukan.

Menyatukan ketiga bagian

Pendekatan	Pertanyaan utama	Keluaran yang berguna
Tree-sitter	Struktur kode apa yang relevan untuk diperiksa?	Inventaris entry point, lokasi kode, dan cakupan query.
STRIDE	Aset dan batas mana yang dapat gagal dijaga?	Hipotesis ancaman, prioritas, pemilik, dan kriteria validasi.
REA	Apa yang dapat dibuktikan dari artefak dan observasi terpilih?	Evidence, hubungan, dan ketidakpastian yang dapat ditelusuri.
Pengujian red team	Apakah perilaku adversary mencapai tujuan dan bagaimana pertahanan merespons?	Bukti dampak, hasil pencegahan dan deteksi, serta bahan perbaikan.

Urutannya dapat berubah mengikuti akses yang tersedia. Investigasi dari binary bisa melahirkan threat model baru; hasil uji bisa mengoreksi asumsi arsitektur. Yang perlu dipertahankan adalah hubungan antara pertanyaan, bukti, keputusan, dan retest. Dari situlah analisis teknis menjadi pengetahuan yang dapat dipakai tim untuk memperbaiki sistem.