Modder memulihkan ROM game dari suara crash GBA

• TheZZAZZGlitch menunjukkan bahwa dengan merekam suara crash Game Boy Advance, data game di dalam kartrid bisa diidentifikasi dan pada akhirnya ROM yang sama dapat dipulihkan
• Intinya adalah menafsirkan audio yang keluar setelah crash sebagai data ROM, tetapi diperlukan banyak penyesuaian untuk tiap format sumber sehingga sulit digunakan sebagai alat dump serbaguna
• Dari rekaman lebih dari 4 jam, gelombang khas muncul di sekitar titik 1 jam 50 menit, lalu suara instrumen dan sampel audio dari game terdengar secara berurutan
• Dengan skrip Python dan koreksi penyelarasan, akurasi mencapai 99,76%, tetapi gagal melakukan boot; saat 3 rekaman digabungkan dengan algoritme voting mayoritas, hasilnya meningkat menjadi 99,979%
• Setelah menggabungkan 7 rekaman dan memfilter ruang kosong, hasilnya mencapai kecocokan 100%, mengonfirmasi kemungkinan eksperimental untuk memulihkan ROM GBA hanya dari suara crash

---

Eksperimen membaca data ROM dari suara crash

• TheZZAZZGlitch mendemonstrasikan bahwa suara yang dihasilkan GBA setelah software crash dapat memuat data game
• GBA yang crash dapat terus menghasilkan suara berdasarkan data internal kartrid, dan dengan hardware khusus serta kode tertentu, audio ini bisa dianalisis untuk mengidentifikasi game apa yang sedang dijalankan
• Namun, metode ini bukan cara mudah untuk melakukan dump data kartrid, dan juga bukan solusi yang siap langsung dipakai
  • Diperlukan banyak tuning yang disesuaikan dengan format sumber yang berbeda-beda

Gelombang yang muncul dari rekaman panjang

• Setelah membuat GBA crash lalu merekamnya selama lebih dari 4 jam, gelombang khas muncul sekitar titik 1 jam 50 menit
• Pada bagian setelah itu, suara instrumen dan sampel audio nyata yang ada di dalam game terdengar secara berurutan
• Sisa datanya terdengar sebagai data 8-bit pada 13.100Hz, dan beberapa bagiannya terdengar sangat aneh

Skrip Python dan upaya pemulihan pertama

• TheZZAZZGlitch menyiapkan skrip Python untuk membaca rekaman dump crash GBA yang bersih setelah “memperbaiki bug selama 2 hari”
• Data ROM memiliki bagian berisi byte 0 dalam jumlah besar, dan bagian ini muncul seperti keheningan sehingga sulit di-parse dari audio
• Setelah menjalankan skrip terpisah untuk menyusun ulang bagian-bagian berdasarkan posisinya di ROM asli, ROM hasil pemulihan mencapai akurasi 99,76%
• ROM ini masih gagal boot, dan karena metode tersebut menggunakan data ROM yang sudah diketahui untuk mengungkap data yang belum diketahui, secara teknis ini termasuk “cheating”
  • Bahkan jika dilakukan sepenuhnya secara blind, masih ada asumsi dan perkiraan yang bisa diterapkan

Menggabungkan beberapa rekaman untuk meningkatkan akurasi

• Pada tahap berikutnya, fokusnya adalah meningkatkan kualitas rekaman
• Saat hasil dari 3 kali rekaman digabungkan dengan algoritme “voting mayoritas”, akurasinya naik hingga 99,979%
• ROM keluaran ini berhasil boot, tetapi teksnya rusak dan terjadi crash di layar judul
• Setelah itu, 7 rekaman digabungkan dan ruang kosong difilter, sehingga tercapai kecocokan 100%

Hardware fisik dan eksperimen tambahan

• Di bagian akhir video, juga diperlihatkan bagaimana metode ini bekerja pada hardware fisik
• Eksperimen juga dilakukan pada game lain, sambil menelusuri misteri yang terkait dengan kode ARM di dalam kartrid kloning
• Berbagai cara untuk mendapatkan rekaman yang lebih baik juga dicoba
  • Salah satunya adalah penggunaan “cursed adapter” yang melakukan mixdown kasar ke satu kanal

[GN⁺]

Komentar Hacker News

• Masalah ketika 0x00 berlanjut panjang berkaitan dengan clock recovery
  Beberapa aliran data digital, terutama data mentah dari head magnetik disk drive atau komunikasi serial berkecepatan tinggi seperti Ethernet, ditransmisikan tanpa sinyal clock terpisah
  Penerima membuat clock dari acuan frekuensi perkiraan, lalu menyelaraskan fase clock ke transisi pada aliran data dengan phase-locked loop (PLL)
  Agar cara ini bekerja, transisi data harus muncul cukup sering untuk mengoreksi drift osilator PLL, dan spesifikasi tentang berapa lama sistem dapat bertahan tanpa transisi disebut CID (maximum consecutive identical digits)
  https://en.wikipedia.org/wiki/Clock_recovery

  • Dulu saya menyukai bagaimana kemungkinan clock recovery dijamin dengan pendekatan codebook yang cerdas, seperti 8b/10b, yang menangani rentang bit pendek dengan sangat hati-hati sekaligus menghindari masalah kapasitansi jalur
    Setelah itu, pendekatannya bergeser ke metode seperti 64/66b, yang menjamin transisi clock dengan menambahkan header pendek ke blok bit besar, lalu melewatkan keseluruhannya melalui scrambler pseudorandom
  • Kekhawatiran lain adalah jika ada bagian pada bentuk gelombang yang AC-coupled sehingga komponen DC tidak bisa lewat
    Bahkan jika clock tersinkron sempurna, pada rentang yang panjang sinyal yang hampir semuanya 1 dan sinyal yang hampir semuanya 0 pada akhirnya menjadi tidak bisa dibedakan
  • Dalam kasus ini sepertinya tidak terlalu relevan
    Audio bersifat analog, dan untuk mendekodenya menjadi bitstream diperlukan DAC, serta sinyal dikirim pada frekuensi tetap seperti 44.1kHz atau 48kHz tanpa sinkronisasi khusus
  • Saya menemukan artikel yang sangat menarik tentang Wireless Set Number 10 di halaman ini
    https://en.wikipedia.org/wiki/Wireless_Set_Number_10

• Ini mengingatkan saya pada hack iPodLinux asli yang men-dump firmware iPod generasi ke-4 dengan speaker piezo hampir 20 tahun lalu
  https://web.archive.org/web/20140810083116/http://www.newscientist.com/article/dn7085
  Secara kebetulan, berkat itu kita juga bisa menjalankan game GBA di iPod, tetapi bermain Doom dengan click wheel dan menonton video hitam-putih saja sudah cukup memuaskan

  • Kenangan yang indah
    Saya masih punya iPod Classic, dan setelah upgrade baterai saya memasukkan empat kartu MicroSD 256GB
    Baru-baru ini saya juga melihat mod yang menambahkan Bluetooth, tetapi karena harus mengganti casing belakang, sepertinya saya tidak akan sampai sejauh itu
    Ada kesan yang tidak pudar dimakan waktu, baik pada desainnya maupun pada fakta bahwa kita benar-benar memiliki salinan file musik kita sendiri

• Senang melihat ini mendapat lebih banyak perhatian di sini
  Beberapa hari lalu ini juga sempat diposting, tetapi tenggelam: https://news.ycombinator.com/item?id=39037104
  Video aslinya memuat jauh lebih banyak hal daripada tulisan singkat ini, termasuk adaptor khusus yang dibuat si hacker dengan memotong dan menyambung sendiri demi mendapatkan kualitas audio yang memadai dari DS

  • Tautan video asli:
    https://www.youtube.com/watch?v=0-7PSmYYHF0

• Zzazz mengadakan kompetisi/acara April Mop setiap tahun, dan biasanya ada unsur retro hacking atau reverse engineering sampai tingkat tertentu
  Saya merekomendasikan untuk ikut
  Kompetisi-kompetisi sebelumnya ada di GitHub

• Arsitektur audio Nintendo selalu menarik
  NES asli memiliki sample generator yang bisa membuat bentuk gelombang arbitrer dan dapat dijalankan dengan dua cara
  Salah satunya adalah dengan memberikan alamat memori agar ia membaca bit dan mengolahnya menjadi bentuk gelombang yang sangat sederhana; 1 berarti “menaikkan nilai satu tingkat”, 0 berarti “menurunkan nilai satu tingkat”, jadi untuk membuat gelombang datar harus mengulang pola seperti 10101010
  Cara lainnya adalah mode di mana CPU terus langsung memasukkan “nilai awal” untuk menggerakkan chip secara langsung, yang dalam praktiknya ternyata lebih cepat daripada driver audio membaca bit dari RAM
  Masalahnya, cara ini memakan semua siklus CPU sehingga hanya bisa dipakai ketika tidak ada hal lain yang dikerjakan
  Game seperti Battletoads memanfaatkan ini untuk memutar hentakan drum dengan kualitas lebih tinggi saat aksi berhenti, dan menggunakannya pada layar judul, efek “renyah” saat semua aksi berhenti sejenak ketika memberi pukulan terakhir ke musuh, serta musik pause yang mudah diingat
  Ada demo di sini yang memperlihatkan bagaimana game beralih antara mode direct drive dan mode saat chip membaca sampel; Retro Game Audio mengunggah video yang dimodifikasi dengan emulator untuk menunjukkan momen tepat ketika masuk ke subrutin direct drive: https://www.youtube.com/watch?v=JGT0FM3yh-w

• Awalnya penasaran kenapa hal ini bisa terjadi
  Apakah game seperti ini memang sering membuang status lewat audio? Apakah ini alat debugging yang sengaja dibuat untuk pengembang game?

  • Video sebelumnya dari penulis[1] menjelaskan detail teknis dari perilaku ini
    Pada dasarnya, suara GBA melakukan streaming audio dari buffer di RAM, dan interupsi harus memberi tahu perangkat keras untuk mulai membaca lagi dari awal buffer
    Namun jika game crash sehingga interupsi tidak terjadi, aliran audio akan melewati batas buffer dan mulai membaca area memori lain
    [1] https://www.youtube.com/watch?v=wSWNkpqjtQY&t=361s
  • Ini cukup jarang terjadi, dan juga bukan alat debugging yang disengaja
    Secara teori, GBA bisa saja dibuat untuk “membekukan” arsitekturnya saat game crash, atau memasang watchdog yang mengikat pembaruan status yang harus berjalan berkala ke interupsi yang tidak bisa dimask, lalu me-reboot jika pembaruan itu berhenti
    Namun fitur seperti itu menambah biaya, jadi GBA tidak memilikinya
    Nintendo pada dasarnya memilih pendekatan tradisional para pembuat kartrid game lama: “kalau game kami tidak punya bug, kami tidak perlu khawatir tentang perilaku status perangkat keras yang tidak terdefinisi”
    Jadi saat game GBA masuk ke status crash seperti loop tak berujung dengan interupsi dinonaktifkan, chip audio tidak tahu bahwa sistem sudah crash dan hanya terus melakukan tugas sederhananya, yaitu membaca bit-bit berurutan dari RAM lalu mengubahnya menjadi suara
    Dalam operasi normal, rutinitas housekeeping yang mengelola pembacaan itu akan tetap ada, tetapi ketika rutinitas itu hilang, pembacaan terus berlanjut sampai akhirnya mencapai bit-bit yang merepresentasikan nilai ROM kartrid

• Benar-benar sangat mengesankan sampai tidak masuk akal
  Teknik seperti algoritma voting mayoritas yang dipakai di sini rasanya masih belum dimanfaatkan cukup luas di berbagai industri

  • Kalau tertarik, teknik canggih untuk pemulihan sinyal bising sudah berkembang hampir 100 tahun
    Media penyimpanan magnetik pada dasarnya bekerja dengan prinsip yang sama seperti hack ini
    https://en.wikipedia.org/wiki/Partial-response_maximum-likelihood
    Ide yang sama juga bisa diterapkan di sini, karena isi ROM GBA kemungkinan punya bias yang kuat
    Voting mayoritas membuang banyak informasi
  • Penerapan menarik dari memilih nilai mayoritas, atau lebih umum lagi memilih median, adalah cara menghilangkan noise atau orang dari beberapa foto yang diambil pada waktu yang sama
    Tinggal tumpuk semua foto lalu sisakan median untuk tiap piksel[1]
    [1]: https://patdavid.net/2013/05/noise-removal-in-photos-with-median_6/
  • Dalam pemulihan data, ini cukup umum
    Caranya dengan terus membaca image disk dan menjalankan penilaian kuorum sampai muncul hasil yang lolos checksum, lalu dilihat apakah benar bekerja
    Jika ada checksum tingkat lebih tinggi seperti signature file, itu lebih baik lagi untuk verifikasi tambahan
    Ini juga dipakai di beberapa aplikasi kedirgantaraan
  • Saya sempat berpikir ini mungkin bisa dipakai untuk pemindaian film, terutama proyek penggemar seperti 4K77
    Karena yang ditangani adalah cetakan tayang bioskop yang mungkin rusak, bukan master yang pristine, memakai beberapa salinan untuk menghilangkan goresan dan semacamnya bisa sangat mengurangi waktu perbaikan manual di tahap pascaproduksi

• Perubahan 0xFF menjadi 0x00 mungkin disebabkan oleh kapasitor pemblokir DC atau penyaringan high-pass
  Rangkaian audio memang kurang cocok untuk konten yang tidak bisa didengar
  Kalau beruntung, akurasi penangkapan mungkin bisa lebih baik dengan langsung menghubungkan osiloskop digital ke keluaran audio chip, tetapi tetap saja cukup mengesankan bahwa mereka berhasil mendapatkan image yang bisa di-boot

  • Dari yang saya ingat pernah dibaca di komentar video YouTube, tujuannya adalah melakukan ini dengan peralatan dasar semaksimal mungkin
    Jadi alih-alih memakai osiloskop pencatat data yang layak, mereka menghabiskan waktu berjam-jam menangkap berulang kali untuk merata-ratakan kesalahan
  • Betul, perlu dibuat sinyal tanpa bias DC
    Bahkan pendekatan sederhana seperti pengodean Manchester pun akan sangat membantu
    Kalau itu belum cukup, NRZ atau bahkan convolutional coding juga bisa dipakai
    Selain itu, bisa juga mengirim gelombang sinus, atau kalau tidak memungkinkan setidaknya menaikkan frekuensi gelombang kotak cukup tinggi agar tidak teredam oleh kapasitor kopling AC

• Bagian yang paling mengesankan dari semua ini, menurut saya pribadi, adalah cara para pembajak memodifikasi kode agar game berjalan dari flash yang bisa ditulis alih-alih ROM+memori penyimpanan volatil

  • Ini teknik yang sangat umum dipakai pada game Game Boy dan Game Boy Advance bajakan untuk menghemat beberapa sen biaya baterai
    Sebenarnya membuat patch seperti ini juga tidak terlalu sulit
    Para pembajak sedikit melakukan reverse engineering pada lokasi tempat kode game menyimpan data, lalu menulis patch per game untuk mem-flush data simpanan ke flash yang bisa ditulis
    Namun game GBA resmi selalu memakai fungsi dari Nintendo SDK untuk menyimpan, jadi dengan melakukan hooking pada fungsi-fungsi itu, menjadi cukup mudah membuat patch generik yang memungkinkan game GBA apa pun menyimpan di kartrid salinan tanpa baterai
    Saya menulis patcher untuk melakukan ini, dan bisa dilihat di sini
    https://github.com/metroid-maniac/gba-auto-batteryless-patcher

• Apakah ada yang tahu apa yang sebenarnya terjadi di dalam emulator TheZZAZZGlitch ketika ia melaporkan bahwa game mencoba lompat ke alamat yang salah?
  Saya tidak akrab dengan prosesor ARM7 yang dipakai di GameBoy Advance, tetapi saya sulit membayangkan bagaimana bisa membentuk pemanggilan lompat ke nilai yang keliru
  Saya juga penasaran apa yang akan terjadi jika salah satu ROM yang dipulihkan secara keliru oleh TheZZAZZGlitch dijalankan di GameBoy sungguhan

  • Dengan instruksi bx, Anda bisa melompat ke alamat arbitrer yang disimpan di register
    Dan jika ROM yang salah dipulihkan itu dijalankan di GameBoy sungguhan, game itu akan crash dan pada akhirnya mulai memutar ROM lewat speaker
    Itulah inti dari videonya :)
  • Kemungkinan besar emulator hanya mengemulasikan akses ke area valid dalam peta memori GBA, dan jika area tidak valid diakses, ia melempar error itu
    Di perangkat keras asli akan seperti apa… siapa yang tahu :)