Bug yang Tidak Terdokumentasi Ditemukan dalam Kode Komputer Pemandu Apollo 11

 (juxt.pro)
2 poin oleh GN⁺ 2026-04-08 | 1 komentar | Bagikan ke WhatsApp
  • Bug pelepasan kunci sumber daya yang terlewat ditemukan dalam kode Apollo Guidance Computer(AGC) yang selama 57 tahun dianggap nyaris sempurna
  • Tim JUXT menganalisis 130 ribu baris assembly menggunakan bahasa spesifikasi AI Allium dan Claude, lalu mengidentifikasi cacat yang tidak terlihat lewat metode verifikasi sebelumnya
  • Pada jalur terminasi abnormal (BADEND) di rutinitas kontrol gyro, kunci LGYRO tidak dilepas, sehingga seluruh fungsi terkait gyro setelahnya bisa berhenti
  • Jika sakelar Cage sempat tertekan secara keliru saat misi nyata di orbit bulan, pekerjaan penyelarasan Program 52 bisa terhenti dan Collins mungkin mengiranya sebagai kerusakan perangkat keras
  • Kasus ini menunjukkan bahwa analisis berbasis spesifikasi perilaku adalah metode yang ampuh untuk menemukan cacat baru bahkan pada kode lama

Cacat Potensial yang Ditemukan di Komputer Pemandu Apollo 11

  • Apollo Guidance Computer(AGC) adalah salah satu codebase yang paling teliti ditinjau dalam sejarah, dan telah dianalisis oleh banyak pengembang serta peneliti
    • Namun, bug kunci sumber daya yang tidak dilepas yang tak terdeteksi selama 57 tahun kini ditemukan di kode kontrol gyro
    • Masalahnya adalah pada jalur error, kunci tidak dilepas sehingga fungsi penyelarasan ulang platform pemandu menjadi nonaktif
  • Tim JUXT menggunakan bahasa spesifikasi berbasis AI Allium dan Claude untuk mengubah 130 ribu baris assembly AGC menjadi 12.500 baris spesifikasi perilaku
    • Mereka mengekstrak spesifikasi langsung dari kode untuk memodelkan semua jalur akuisisi dan pelepasan sumber daya
    • Dalam proses ini, muncullah cacat yang tidak terlihat lewat pembacaan kode atau emulasi biasa

Struktur Kode dan Pendekatan Analisis

  • Kode sumber AGC dipublikasikan pada 2003 setelah Ron Burkey dan para relawan menyalin secara manual versi cetak dari MIT Instrumentation Laboratory
    • Pada 2016, repositori GitHub milik Chris Garry dipublikasikan sehingga para pengembang di seluruh dunia dapat menelaah kode assembly dengan RAM 2KB dan CPU 1MHz
  • Program disimpan dalam core rope memory berukuran 74KB, yang merepresentasikan 1 dan 0 dengan menenun kawat tembaga secara manual ke inti magnetik
    • Para teknisi perempuan yang melakukan pekerjaan ini dijuluki “Little Old Ladies”, dan memorinya dinamai LOL memory
  • Hingga kini, tidak ada catatan bahwa verifikasi formal, model checking, atau analisis statis pernah dilakukan terhadap AGC
    • Sebagian besar verifikasi berfokus pada pembacaan kode, emulasi, dan pengecekan akurasi transkripsi
    Iklan
  • JUXT menulis spesifikasi perilaku subsistem IMU(Inertial Measurement Unit) dalam Allium
    • Dengan memodelkan waktu akuisisi dan pelepasan tiap sumber daya bersama, mereka berhasil mengidentifikasi cacat

Kunci yang Tidak Dilepas di Rutinitas Kontrol Gyro

  • AGC mengelola IMU dengan kunci bersama bernama LGYRO
    • Saat memberi torsi pada gyroscope, sistem mengambil kunci tersebut dan melepaskannya setelah ketiga sumbu selesai
    • Ini melindungi agar dua rutinitas tidak memanipulasi perangkat keras secara bersamaan
  • Namun, pada jalur terminasi abnormal, kunci itu tidak dilepas
    • Dalam terminasi normal, rutinitas STRTGYR2 melepaskan LGYRO, tetapi ketika terjadi ‘Caging’ (kunci fisik untuk melindungi gyro), alur berpindah ke rutinitas BADEND
    • Di BADEND, dua instruksi CAF ZERO dan TS LGYRO (total 4 byte) tidak ada, sehingga kunci tetap tertahan
  • Jika LGYRO tidak dilepas, semua rutinitas torsi gyro berikutnya akan berhenti sambil menunggu kunci
    • Penyelarasan halus, koreksi drift, torsi manual, dan seluruh fungsi terkait gyro akan terhenti

Dampak Potensial di Sisi Gelap Bulan

  • Pada 21 Juli 1969, Michael Collins secara berkala menjalankan Program 52 (program penyelarasan pengamatan bintang) saat berada di orbit bulan
    • Jika platform mengalami drift, ada risiko arah mesin pulang menjadi salah
    Iklan
  • Jika sakelar Cage tanpa sengaja tertekan saat proses torsi berlangsung dan alur masuk ke BADEND, LGYRO mungkin tidak akan dilepas sehingga semua P52 berikutnya bisa macet
    • DSKY (display-keyboard) tetap menerima input tetapi tidak memberi respons
    • Karena fungsi lain tetap berjalan normal, Collins bisa saja mengiranya sebagai kerusakan perangkat keras
  • Jika restart (hard reset) dilakukan, masalah ini kemungkinan akan teratasi, tetapi pengalaman alarm 1202 saat pendaratan bulan mungkin membuat keputusan untuk segera melakukan reset tidak mudah

Desain Defensif Sistem Lama dan Keterbatasannya

  • Tim MIT yang dipimpin Margaret Hamilton memperkenalkan konsep dasar rekayasa perangkat lunak modern seperti penjadwalan prioritas, multitasking asinkron, dan perlindungan restart
    • Berkat desain ini, pendaratan tetap bisa dilakukan meski muncul alarm 1202
  • Sebagian besar cacat besar merupakan kesalahan spesifikasi, dan seperti kasus yang didokumentasikan Don Eyles, pernah ada peningkatan beban CPU akibat sinkronisasi fase antaperangkat keras yang terlewat
  • Cacat kali ini memiliki struktur serupa
    • BADEND adalah rutinitas terminasi umum untuk perpindahan mode IMU; ia melepaskan sumber daya umum seperti MODECADR, tetapi tidak menangani LGYRO
    • Karena logika restart menginisialisasi ulang LGYRO, masalah ini pulih tanpa gejala saat pengujian sehingga cacatnya tetap tersembunyi
  • Namun, dalam situasi nyata tanpa restart, gyro bisa tetap berada dalam keadaan terkunci secara permanen

Proses Penemuan Cacat dengan Allium

  • Spesifikasi Allium memodelkan siklus hidup (lifecycle) tiap sumber daya
    • Field gyros_busy merepresentasikan LGYRO, aturan GyroTorque mendefinisikan pengambilan kunci, dan aturan GyroTorqueBusy mendefinisikan keadaan menunggu saat kunci sudah diambil
    Iklan
  • Spesifikasi tersebut menyatakan kewajiban bahwa “jika kunci menjadi true, maka ia harus kembali menjadi false”
    • Setelah Claude melacak semua jalur, ditemukan bahwa pada jalur normal (STRTGYR2) kunci dilepas, tetapi pada jalur error (BADEND) hal itu terlewat
  • Pendekatan berbasis spesifikasi memverifikasi bukan apa yang dilakukan kode, melainkan apa yang seharusnya dilakukan
    • Pengujian memeriksa perilaku kode saat ini, sedangkan spesifikasi memverifikasi perilaku yang dimaksudkan
  • Spesifikasi Allium dan kode reproduksi bug dipublikasikan di GitHub

Implikasi dan Pelajaran Modern

  • Pada masa itu, programmer harus melepaskan kunci secara manual dengan instruksi CAF ZERO dan TS LGYRO
    • Mereka harus mengingat semua jalur dan menyisipkan kode pelepasan secara manual
  • Bahasa modern mencegah masalah sumber daya yang terlewat seperti ini secara lebih struktural
    • defer di Go, try-with-resources di Java, with di Python, dan sistem ownership di Rust menjamin pelepasan otomatis
  • Meski begitu, cacat tipe CWE-772 (Missing Release of Resource) masih tetap ada
    • Koneksi database, kunci terdistribusi, file handle, dan urutan penghentian infrastruktur masih sering menjadi tanggung jawab programmer
  • Semua misi Apollo berhasil kembali dengan selamat, tetapi cacat ini tetap ikut terbawa tanpa diperbaiki ke perangkat lunak COMANCHE(command module) dan LUMINARY(lunar module)
  • Cacat yang tersembunyi selama 57 tahun ini menunjukkan pentingnya analisis berbasis spesifikasi perilaku

Bacaan terkait

1 komentar

 
GN⁺ 2026-04-08
Komentar Hacker News

  • Saya Mike Stewart, memimpin proyek restorasi AGC di channel CuriousMarc dan salah satu admin VirtualAGC
    Bug yang disebut kali ini memang benar merupakan cacat pada perangkat lunak AGC yang pernah ada. Namun, bug itu tidak dibiarkan selama seluruh masa program. Bug ini ditemukan saat pengujian tahap 3 SATANCHE, dicatat sebagai L-1D-02, dan diperbaiki antara Apollo 14 dan 15
    Laporan terkait bisa dilihat di dokumen ibiblio 1 dan dokumen 2
    Perbaikannya bukan sekadar menambahkan dua baris untuk menjadikan LGYRO bernilai 0, tetapi juga mencakup penataan ulang struktur kode dan logika untuk membangunkan tugas yang tertunda. Jika membandingkan kode Apollo 14 dan 15 (kode Apollo 14, kode Apollo 15), perbedaannya bisa dilihat
    Ini bukan bug yang muncul diam-diam seperti dijelaskan di artikel. LGYRO juga diinisialisasi di STARTSB2, yang dijalankan setiap kali program berpindah sehingga masalah ini otomatis teratasi. Jadi dalam praktiknya, bug ini hanya jarang terjadi saat melakukan operasi torsi selama BADEND
    Jika bug tetap bertahan, beberapa tugas akan menumpuk dan pada akhirnya memicu error 31202 (versi lanjutan dari 1202). Masalah ini ditemukan sebelum penerbangan Apollo 14 dan prosedur pemulihannya ditambahkan ke Apollo 14 Program Notes
    Selain itu, meskipun disebut bahwa Ken Shirriff melakukan analisis pada level gerbang, sebenarnya sayalah yang melakukan sebagian besarnya
    Virtual AGC baru menyelesaikan verifikasi kecocokan byte demi byte dengan dump core rope asli untuk sebagian program saja, dan untuk keseluruhan program itu masih belum memungkinkan. Sebagian besar source dipulihkan berdasarkan versi cetak atau checksum
    Margaret Hamilton adalah ‘rope mother’ untuk Comanche (perangkat lunak command module), sedangkan Luminary (modul pendaratan bulan) ditangani oleh Jim Kernan. Ini bisa dikonfirmasi di bagan organisasi 1969
    Saat alarm 1202 terjadi, AGC tidak dirancang untuk membuang tugas berprioritas rendah. Justru panduan pendaratan adalah tugas dengan prioritas paling rendah, sementara kontrol antena dan pembaruan display punya prioritas lebih tinggi. Dokumen ini merangkum prioritas tiap tugas
    Terakhir, penyebab alarm 1202 bukanlah perbedaan fase melainkan perbedaan tegangan (28V vs 15V), dan hal ini telah dikonfirmasi lewat pengujian pada perangkat keras asli. Video eksperimen terkait bisa dilihat di tautan YouTube

    • Saya sudah menunggu komentar Anda. Terima kasih telah membagikan detail sejarah yang benar-benar luar biasa
    • Halaman utama sudah pindah ke topik lain, tetapi ini benar-benar informasi berharga. Terima kasih sudah meluangkan waktu

  • Jika Anda tertarik dengan Apollo AGC, saya sangat merekomendasikan channel YouTube CuriousMarc. Tim yang sangat mumpuni secara teknis mendokumentasikan proses restorasi dan analisis berbagai komponen AGC
    Bagian yang особенно menarik adalah penafsiran ulang alarm 1202 yang terkenal itu. Biasanya ini dikenal sebagai kesalahan sensor yang bisa diabaikan, tetapi sebenarnya dalam kondisi tertentu hal itu bisa sangat fatal

    • Jadi bisa dibilang saat ini mencoba pendaratan yang sama lagi akan lebih sulit atau lebih mudah. Kita mengetahui jauh lebih banyak mode kegagalan dibanding saat itu
    • “Yang dijelaskan ke publik” dan “yang benar-benar dipahami” itu berbeda. Ada banyak penjelasan yang disederhanakan, tetapi di kalangan ahli fenomena ini sudah dipahami dengan baik
    • Diskusi tim CuriousMarc tentang restorasi AGC juga berlanjut di thread ini

  • Potongan kode favorit saya adalah ini

    TC  BANKCALL  # TEMPORARY, I HOPE HOPE HOPE
CADR STOPRATE  # TEMPORARY, I HOPE HOPE HOPE
TC  DOWNFLAG  # PERMIT X-AXIS OVERRIDE

    Tautan GitHub

    • Kode ini juga disebut di The Codeless Code
    • CADR di sini tidak ada hubungannya dengan fungsi cadr di Lisp
    • Adakah yang bisa menjelaskan kenapa kode ini lucu?
    • Saya ingat pernah melihat puisi tentang kode ini di XKCD, tapi mungkin saya salah ingat

  • Saya penasaran apakah pernah ada verifikasi bahwa bug ini benar-benar ada. AI memang kuat untuk analisis eksploratif seperti ini, tetapi tingkat false positive-nya masih tinggi
    Bergantung konteksnya, ini bisa penting atau tidak. Ada juga banyak bug yang tidak ditemukan AI
    Saya tidak punya keahlian untuk memverifikasinya sendiri, tetapi ini sangat menarik

    • Sebenarnya juga tidak jelas apakah AI yang menemukan bug itu. Yang tertulis hanya “dimodelkan dalam bahasa native AI”
      Namun penjelasan tentang pengambilan lock dan skenario kegagalan memang cukup meyakinkan

  • Menarik bahwa mereka benar-benar menemukan bug nyata. Tetapi dramatisasi dalam tulisannya nyaris seperti fiksi
    Misalnya menyenggol sakelar dengan siku, atau membesar-besarkan masalah yang sebenarnya bisa diatasi dengan reset. Hal-hal seperti ini memang membuat tulisannya lebih sensasional, tetapi mengurangi kredibilitasnya. Ditambah lagi gaya tulisannya terasa seperti ditulis AI, jadi makin mengganggu

    • Tentu saja sakelarnya adalah sakelar dengan penutup pelindung.
      Tetapi untuk menjelaskan bug yang subtil kepada pembaca umum, memang perlu sedikit storytelling. Kalau terlalu teknis orang jadi kehilangan minat, kalau terlalu dramatis para ahli akan mengkritik. Menurut saya, sulit mencari titik seimbangnya

  • Saya sempat menjalankan sendiri kode reproduksi (repro) yang disertakan di artikel
    Tautan GitHub
    Memang bisa dijalankan, tetapi Phase 5 (demo deadlock) sepenuhnya output palsu. Itu hanya mencetak hasil yang diharapkan tanpa benar-benar menjalankan emulator
    Karena itu saya membuat PR sendiri untuk memperbaikinya agar benar-benar berjalan di emulator, dan juga memverifikasi bahwa patch dua baris tersebut memang memperbaiki bug

    • Saya sering melihat “kode AI” seperti ini. Kelihatannya meniru test-driven development, tetapi sebenarnya hanya menghasilkan kode palsu yang sekadar meloloskan test
      Kode hasil AI cenderung berhenti di titik “sekarang sudah sempurna!”, lalu orang-orang mempercayainya dan langsung merilisnya. Itulah masalah yang sebenarnya

  • Tulisan itu sendiri menarik, tetapi terasa sangat artifisial seperti ditulis LLM

    • Bagi saya sama sekali tidak terasa seperti LLM. Mungkin karena gaya tulisannya seperti makalah ilmiah
    • Juxt sudah lama menulis artikel yang bagus dan punya keahlian yang cukup. Jadi saya rasa kecil kemungkinan tulisan ini ditulis AI
    • Sebagai referensi, menurut analisis Pangram, tulisan ini dinilai ditulis manusia
    • Tetapi salah satu tulisan Juxt yang lain memang secara eksplisit dinyatakan ditulis oleh Claude. Hal itu disebutkan di paragraf terakhir artikel tersebut
    • Selain itu, bagian tentang Rust dan lock juga tidak sesuai fakta. Ini ditunjukkan di komentar ini

  • Fakta bahwa bahkan perangkat lunak yang membawa manusia ke bulan dengan hanya 4KB memori masih punya bug yang belum ditemukan menunjukkan bahwa kompleksitas bisa tersembunyi bahkan dalam kode kecil

    • Semakin kecil memorinya, semakin lemah korelasi antara panjang kode dan tingkat bug. Justru upaya memadatkan kompleksitas malah menambah bug
    • Ucapan seperti itu terdengar cuma seperti klise kosong

  • Ungkapan “menurunkan spesifikasi dari kode” itu keliru. Mungkin perlu melihat lagi arti specification

    • Sebenarnya itu hanya berarti reverse engineering

  • Baik artikelnya maupun repositorinya adalah hasil yang ceroboh (sloppy)
    Kalau melihat tautan repositori, mereka menyebutnya “reproduksi”, padahal tidak menjalankan bug yang sebenarnya dan hanya menampilkan baris-baris output yang berkata “ini yang akan terjadi”