Cara Melakukan Reverse Engineering pada Aplikasi dengan Claude Code

Reverse engineering berarti mempelajari software jadi untuk memahami cara kerjanya, biasanya tanpa memiliki kode sumber asli atau dokumen desain apa pun yang menjadi dasarnya. Anda melihat apa yang dilakukannya, bagaimana ia disusun, dan dengan apa ia berkomunikasi, lalu bekerja mundur dari itu menuju model perilakunya.

Orang melakukan ini karena alasan yang sebagian besar tidak glamor dan sebagian besar legitimate. Peneliti keamanan melakukan reverse engineering pada program untuk menemukan vulnerability sebelum orang dengan niat lebih buruk menemukannya. Developer melakukan reverse engineering pada format file dan protokol jaringan agar program baru bisa berinteroperasi dengan program lama yang tidak akan didokumentasikan oleh siapa pun untuk mereka. Arsiparis dan hobbyist melakukan reverse engineering pada software lama untuk menjaganya tetap berjalan setelah hardware asli dan perusahaan di baliknya sudah tidak ada lagi. Dan terkadang alasannya sesederhana: sebuah program yang Anda andalkan melakukan sesuatu yang tidak terdokumentasi, dan Anda perlu mengetahui apa itu sebelum bisa mempercayainya atau mengakalinya.

Tidak ada yang baru dari semua ini. Peneliti keamanan dan arsiparis software sudah melakukannya selama berdekade-dekade dengan disassembler dan debugger, jauh sebelum ada agen AI. Yang berubah adalah kecepatan: agen bisa membaca listing disassembly atau method yang sudah di-decompile dan meringkasnya dalam hitungan detik, pekerjaan yang dulu memakan waktu berjam-jam bagi orang yang terampil. Itu adalah peningkatan kapabilitas yang nyata, dan itulah alasan mengapa batas hukum dan etika di bagian lain panduan ini menjadi lebih penting sekarang, bukan kurang, karena bottleneck yang dulu memperlambat orang antara rasa ingin tahu dan penyalinan sudah sebagian besar hilang.

Sisa panduan ini bersifat spesifik: membahas satu tool, bernama REA, yang menghubungkan agen seperti Claude Code ke jenis analisis ini, dan kebiasaan-kebiasaan yang layak dimiliki sebelum Anda mengarahkannya ke apa pun.

Perbedaan yang paling penting di sini adalah antara mempelajari cara kerja sesuatu dan menyalin ekspresi yang dilindunginya. Reverse engineering untuk mempelajari antarmuka, format file, atau sepotong perilaku, secara hukum, adalah tindakan yang berbeda dari mengambil kode atau aset milik orang lain ke dalam produk Anda sendiri.

Praktik yang dibangun di sekitar perbedaan itu disebut clean-room design. Satu orang atau satu sesi mempelajari yang asli dan menulis spesifikasi dalam bahasa sederhana tentang apa yang dilakukannya: antarmukanya, format datanya, perilakunya, dengan kata-kata mereka sendiri, tanpa kode asli yang disalin ke dalam dokumen. Orang atau sesi terpisah, yang tidak pernah melihat yang asli, kemudian membangun implementasi baru hanya dari spesifikasi itu. Intinya adalah hasil akhir bisa ditunjukkan berasal dari deskripsi tertulis, bukan dari karya aslinya sendiri.

Dua putusan pengadilan AS yang lebih lama sering dikutip terkait hal ini, dan layak diketahui, meskipun tidak ada yang merupakan izin umum untuk melakukan reverse engineering apa pun. Sega Enterprises Ltd. v. Accolade, Inc., diputuskan oleh Ninth Circuit pada 1992, melibatkan perusahaan yang melakukan reverse engineering pada sistem lockout sebuah game console agar game mereka sendiri bisa berjalan di console itu. Pengadilan menyatakan bahwa penyalinan perantara yang terjadi dalam reverse engineering tersebut, dilakukan untuk mencapai elemen fungsional tak terlindungi yang diperlukan agar game-nya bisa berjalan di hardware itu, merupakan fair use berdasarkan fakta spesifik kasus tersebut. Sony Computer Entertainment, Inc. v. Connectix Corp., diputuskan oleh pengadilan yang sama pada 2000, mencapai kesimpulan serupa ketika sebuah perusahaan melakukan reverse engineering pada software startup sebuah console untuk membangun emulator bagi jenis komputer lain, lagi-lagi memperlakukan penyalinan sepanjang proses itu sebagai fair use dalam melayani produk yang ditulis secara independen dan bisa berinteroperasi.

Perlakukan kedua kasus itu sebagai konteks sejarah, bukan nasihat untuk situasi Anda. Keduanya adalah dua putusan pengadilan banding spesifik tentang fakta spesifik, fair use diputuskan kasus per kasus, negara lain menarik batas ini secara berbeda, dan undang-undang yang lebih baru yang menyasar penerobosan perlindungan hak cipta mempersempit hal ini secara signifikan untuk software yang terikat DRM. Siapa pun yang berencana membangun sesuatu berdasarkan jenis pekerjaan ini, terutama apa pun yang dimaksudkan untuk dirilis atau dijual, harus bicara dengan pengacara sungguhan sebelum mengandalkan apa pun dari ini.

REA menarik batasnya sendiri secara independen dari apa yang pada akhirnya mungkin diputuskan pengadilan tentang kasus tertentu. Menurut DISCLAIMER.md proyek ini, REA tidak mendukung dan tidak akan membantu menerobos DRM, pengecekan lisensi, sistem anti-cheat, atau ukuran perlindungan teknis lainnya, atau menyalin software proprietary atau kode dan aset yang dilindunginya, dan proyek ini menyatakan secara jelas bahwa output analisisnya tidak memberikan hak apa pun atas program aslinya. Aturan praktis yang mengikutinya: hanya analisis software yang Anda miliki, Anda tulis sendiri, atau yang Anda diizinkan untuk periksa.

Versi Node.js penting di sini. README REA sendiri menyatakan persyaratannya secara persis sebagai: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), atau 26.12.1+, ditambah npm. Cek itu dengan README yang aktif sebelum Anda menginstal, karena jenis persyaratan ini berubah antar rilis.

Command setup-nya adalah npx rea-agents setup. Menurut README, ini memandu Anda memilih agen mana yang akan didaftarkan dengan REA, menunjukkan perubahan yang diusulkannya sebelum Anda menyetujuinya, dan menyimpan backup konfigurasi Anda yang sudah ada. Restart agen Anda setelahnya agar ia mengambil server MCP yang baru; instruksi REA sendiri menyatakan ini secara jelas.

Untuk instalasi command-line yang persisten daripada menjalankan npx sekali saja, README menjelaskan npm install --global rea-agents, diikuti rea --help untuk melihat apa yang tersedia. Dari instalasi global, rea update memindahkan Anda ke versi baru sesuai jadwal Anda sendiri alih-alih otomatis, dan menjalankan npx rea-agents@latest setup setelahnya memperbarui pendaftaran agen agar sesuai.

Sebelum mengarahkan REA ke apa pun yang tidak sepenuhnya Anda miliki, coba dulu pada aplikasi kecil yang Anda tulis sendiri. Dengan REA sudah diatur, minta Claude Code membuka aplikasi kecil itu dan menjelaskan apa yang dilihatnya, fungsi demi fungsi, dan bandingkan itu dengan apa yang sudah Anda ketahui Anda tulis. Latihan itu saja mengonfirmasi bahwa setup benar-benar berfungsi, dan memberi Anda gambaran bagaimana bukti REA, sebuah file, sebuah fungsi, sebuah panggilan, terlihat dalam praktik sebelum Anda mengandalkannya untuk sesuatu yang penting.

Wujudkan ide clean-room dari sebelumnya ke dalam bentuk konkret menggunakan dua sesi Claude Code yang terpisah. Yang pertama adalah sesi spesifikasi: arahkan REA ke software yang Anda diizinkan untuk pelajari, dan minta agen menulis spesifikasi dalam bahasa sederhana tentang antarmukanya, format datanya, dan perilaku fungsi-fungsi utamanya, seluruhnya dengan kata-katanya sendiri, tanpa kode asli atau pseudocode yang disalin secara verbatim ke dalam dokumen.

Yang kedua adalah sesi pembangunan, dimulai dari awal, tanpa memori dari sesi pertama. Berikan hanya file spesifikasi, tidak ada yang lain: bukan binary aslinya, bukan transkrip sesi pertama, bukan output mentah REA. Minta agen membangun implementasi baru yang independen yang memenuhi spesifikasi tersebut, dan memberi tahu Anda ketika ada sesuatu di spesifikasi itu yang ambigu daripada diam-diam menebak apa yang dilakukan program aslinya.

Menjaga keduanya sebagai sesi yang benar-benar terpisah, bukan dua fase dari satu percakapan panjang, adalah bagian yang penting. Satu sesi tunggal yang mempelajari yang asli lalu menulis penggantinya telah mengaburkan persis batas yang dijaga ketat oleh clean-room design, karena tidak ada cara untuk menunjukkan, setelah fakta, bahwa bagian kedua tidak bersandar pada bagian pertama.

Jujurlah tentang apa yang didapat dari ini. Workflow dua sesi yang disiplin adalah praktik yang mendukung argumen clean-room di kemudian hari jika suatu saat ada yang bertanya bagaimana sesuatu dibangun. Ini bukan jaminan hukum dengan sendirinya, dan tidak menggantikan konsultasi dengan pengacara sungguhan untuk apa pun yang Anda rencanakan untuk dirilis atau dijual.