🏇🏽 🍍 😿 Melindungi dan Meretas Xbox 360 (Bagian 3) 🤜🏼 🍬 👶🏽

Pada tahun 2011, 6 tahun setelah rilis konsol game Xbox 360, para peneliti menemukan fakta yang menarik - jika sinyal "0" dikirim ke output RESET dari prosesor pusat untuk waktu yang sangat singkat, prosesor tidak akan mengatur ulang statusnya (sebagaimana mestinya), tetapi sebaliknya ubah perilaku Anda! Berdasarkan "fitur" ini, Reset Glitch Hack (RGH) dikembangkan , dengan bantuan yang memungkinkan untuk sepenuhnya mengkompromikan perlindungan Xbox 360, menjalankan kode yang tidak ditandatangani, dengan demikian membuka cara untuk meretas sistem itu sendiri dan mengalahkan drive DG-16D5S yang “tidak dapat dipecahkan” .

Mari kita lihat lebih dekat bagaimana RGH bekerja, bagaimana para pengembang mencoba untuk menambal lubang, dan bagaimana tambalan ini dapat berkeliling!

Apa itu serangan kesalahan?

Prosesornya sangat bodoh, tidak peduli apa yang dikatakan pemasar. Semua kode tingkat tinggi yang ditulis oleh programmer dikurangi menjadi eksekusi perintah sederhana - aritmatika dengan angka, data bergerak, lompatan bersyarat dan tanpa syarat. Diasumsikan bahwa prosesor selalu menjalankan perintah ini tanpa kesalahan, dan hasilnya sesuai dengan dokumentasi.

Memang, kompilasi kodenya

i = i + 2;

Anda mengandalkan fakta bahwa nilai variabel saya akan meningkat tepat 2, bahkan tanpa menyadari bagaimana bisa sebaliknya.

Serangan Glitch melanggar kepercayaan diri ini - tujuan mereka adalah untuk memastikan bahwa prosesor "bermasalah" dan berperilaku salah. Ada beberapa cara untuk "menyalahkan" prosesor, misalnya:

Tarik tegangan CPU
Untuk memberikan dorongan ekstra ke frekuensi referensi CPU
"Bersinar" pada persen radiasi

Ada perangkat khusus untuk melakukan serangan seperti itu - misalnya, ChipWhisperer menawarkan berbagai serangan dalam frekuensi dan daya:

Dalam kasus Xbox 360, "kesalahan" terjadi sebagai akibat dari paparan ke garis RESET. Prosesor memulai prosedur reset, tetapi karena durasi sinyal yang sangat singkat, prosesor tidak punya waktu untuk menyelesaikannya dan terus bekerja seolah-olah tidak ada yang terjadi. Tetapi hanya untuk momen singkat ini, ketika sinyal RESET aktif, perilakunya berubah!

Prosesor kesalahan

Perlindungan Xbox 360 bertumpu pada bootloader yang saling mengecek dalam satu rantai. Pada akhirnya, verifikasi pada setiap tahap datang ke memanggil fungsi membandingkan jumlah hash dengan "pola". Saat itulah mereka menerapkan serangan kesalahan, memaksa prosesor untuk mengabaikan ketidakcocokan. Impuls ke saluran RESET segera setelah memanggil prosedur memcmp memaksa prosesor untuk "pergi" ke cabang lain dan terus memuat, bahkan jika jumlah hash salah:

Tempat terbaik untuk menyerang ditemukan di bootloader tahap kedua, "CB". Tahap-tahap selanjutnya lebih sulit untuk diserang (dan mudah diperbaiki), tetapi pada tahap pertama pemuatan (“1BL”, ROM) serangan gagal karena konstruksi yang sedikit berbeda dari kode program.

Kedengarannya sederhana, tetapi pada kenyataannya, ketika mencoba melakukan serangan, banyak nuansa yang ditemukan.

Pertama, agar berhasil melakukan serangan kesalahan, perlu untuk menentukan titik waktu ketika pulsa RESET harus diterapkan dengan sangat akurat. Jika Anda membuat kesalahan setidaknya untuk mikrodetik, mengirim impuls terlalu pendek atau panjang, serangan itu tidak berfungsi.

Untungnya, di Xbox 360, setiap langkah boot disertai dengan perubahan nilai pada bus debug POST_OUT. Selain itu, output debug sering diatur sehingga nilai POST baru diatur segera sebelum membandingkan jumlah hash:

Jadi tutup lokasi hasil debug dari situs serangan adalah pemicu yang sangat nyaman. POST_OUT adalah bus paralel dan merupakan output ke 8 situs uji pada papan sirkuit tercetak, yang masing-masing bertanggung jawab atas salah satu bit nilai. Bahkan dimungkinkan untuk menyederhanakan skema koneksi hanya menggunakan satu bit dan menghitung jumlah perubahan dalam statusnya sejak sistem di-boot:

Ternyata juga karena frekuensi prosesor yang tinggi, hampir tidak mungkin untuk mendapatkan momen yang tepat dalam hal akurasi dan durasi. Waktu pemaparan harus sangat singkat, berdasarkan urutan waktu pelaksanaan satu instruksi oleh prosesor. Tetapi semakin lambat prosesor berjalan, semakin lama interval waktunya cocok untuk kita. Karena itu, kami mengambil dan memperlambat prosesor!

Pada PC biasa, frekuensi CPU didefinisikan sebagai produk dari eksternal, frekuensi dan pengali "referensi":

Jadi di Xbox 360, jalur eksternal dari frekuensi referensi cocok untuk prosesor, dan di dalam frekuensi ini dikalikan dengan PLL . Dan pada revisi lama, "tebal" dari set-top box, mekanisme PLL dapat dimatikan, memperlambat prosesor sebanyak 128 kali:

Pada versi "Slim", trik PLL tidak dapat dilakukan (garis tidak dipisahkan di papan), dan karena kita tidak dapat mempengaruhi faktor "Slim", kami akan mengurangi frekuensi "referensi"!

Ini dihasilkan oleh chip HANA, dan dapat dikonfigurasi melalui bus I2C:

Sayangnya, tidak mungkin mengurangi banyak, "pada kecepatan rendah" frekuensi prosesor akhir mulai "berenang" dengan kuat, yang mengurangi peluang keberhasilan. Opsi yang paling stabil adalah penurunan 3,17 kali. Tidak 128 kali, tapi setidaknya sesuatu.

Semua? Tidak semuanya. Jauh dari fakta bahwa serangan itu akan bekerja pertama kali (terutama pada Slim). Dan jika mulai gagal, awalan reboot dan mencoba untuk memulai lagi. Hanya 5 upaya yang diberikan untuk memulai, setelah awalan berhenti dan mulai berkedip "cincin merah kematian". Oleh karena itu, kami juga menambal firmware jembatan selatan (SMC) sehingga tidak menderita sampah dan mem-boot ulang awalan hingga menjadi biru:

Jadi, kami mendapatkan algoritma:

menambal SMC
memperlambat persen (via PLL atau I2C)
menunggu pemicu POST
menunggu N mikrodetik
kirim impuls ke RESET
mempercepat persen kembali

Untuk akurasi perhitungan yang lebih besar, kami mengambil frekuensi dari HANA yang sama (48 MHz):

Dan kami mendapatkan desain seperti itu berdasarkan CPLD Xilinx XC2C64A yang murah:

Jangan lupa perdukakan dengan panjang dan lokasi kabel pada RESET (perhatikan "koil" di bagian bawah foto) dan maju, berharap bahwa peluncuran akan bekerja dalam satu menit.

Tapi ini hanya di sisi perangkat keras. Bagaimana kita menambal bootloader dan memasukkan kode kita?

Patch loader

Seperti yang saya sebutkan, bootloader tingkat kedua, "CB," sedang diserang. Bootloader ini dienkripsi dengan kunci tetap, sama untuk semua konsol, tetapi hanya "CB" tidak dapat dimodifikasi, kami hanya menyerang itu. Tetapi yang berikutnya sudah dienkripsi dengan kunci CPU, unik untuk setiap set-top box. Dan untuk memodifikasinya, Anda perlu tahu kunci ini ...
Atau tidak?

Dalam revisi "tebal" lama dari Xbox 360, apa yang disebut mode "Zero-Pairing", yang digunakan pada tahap produksi konsol, didukung di CB loader. Setiap header bootloader pada offset 0x10 berisi kumpulan data Pairing acak yang digunakan sebagai bagian dari kunci untuk dekripsi. Dan jika kumpulan data ini seluruhnya terdiri dari nol ("Zero-Pairing"), maka kunci prosesor diabaikan dan diperbaiki, kunci nol digunakan sebagai gantinya!

Dengan trik ini adalah mungkin untuk mengumpulkan gambar dengan "CB" asli, mengenkripsi bootloader berikutnya, "CD" (dengan kode sendiri) dengan kunci nol dan menjalankannya menggunakan RGH!

Dalam konsol "Slim" membungkus trik ini, menghapus mode "Zero-Pairing" dan membagi "CB" menjadi dua bagian. Di sini, "CB" dibagi menjadi "CB_A" yang sangat sederhana dan kecil dan dienkripsi dengan kunci prosesor "CB_B":

Tetapi enkripsi dengan algoritma RC4 (yaitu, CB_B dienkripsi dengan algoritma ini) memiliki satu kekhasan. Dalam proses enkripsi berdasarkan kunci, aliran data pseudo-acak dihasilkan, yang merupakan biner "dijumlahkan" (operasi 'eksklusif atau', 'xor') dengan sumber data. Ketika mendekripsi, hal yang sama terjadi, menambahkan dengan aliran pseudo-acak yang sama mengembalikan data ke nilai aslinya:

Tetapi operasi penambahan biner bersifat komutatif dan asosiatif, yang berarti bahwa kita dapat memodifikasi data terenkripsi tanpa mengetahui kuncinya, hanya untuk xor 'dan kode terenkripsi dengan tambalan yang kita butuhkan!

Sebagai hasilnya, kita dapat mengenkripsi "CB_A", menambal "CB_B" yang dienkripsi (sehingga tidak melakukan dekripsi sama sekali) dan memasukkan "CD" teks biasa dengan kodenya!

Singkatnya, jika Anda menyatukannya, maka peluncurannya akan terlihat seperti ini:
(XeLL adalah bootloader dari homebrew, Linux, dan juga menunjukkan kunci-kunci CPU)

Microsoft menyerang balik

Tentu saja, Microsoft mencoba untuk memperbaiki semuanya.

Dalam pembaruan sistem baru, semua konsol lama dipindahkan ke boot "terpisah" dari "CB_A" dan "CB_B", sehingga akhirnya menutup mode "Zero-Paired". Pada Slim, bootloader juga telah diperbarui. Bootloader baru telah dimodifikasi secara serius untuk melindungi terhadap RGH, dengan penekanan terbesar ditempatkan pada perlindungan CB_A:

Benar-benar menghapus hasil debug di POST
Verifikasi hash telah diulang dan diduplikasi untuk keandalan
Sepanjang kode, sleep () diset untuk waktu acak (tergantung pada kunci CPU !!)
Menambahkan cek fusi CBLDV untuk mencabut CB_A

Daftar inovasi tidak memberikan peluang bagi RGH. Tapi mari kita perhatikan item terakhir dalam daftar - sebelum itu, tidak ada pemeriksaan fusi di CB_A! Kelemahan fatal. Selain itu, seperti yang kita ingat, kunci prosesor tidak terlibat dalam decoding "CB_A". Ini berarti bahwa loader CB_A yang rentan terhadap RGH dapat diluncurkan pada konsol apa pun, dan ini tidak dapat dilarang.

Tetapi untuk memulai sesuatu dengan bantuan "CB_A" yang rentan ini, Anda perlu mengelak sedikit. Jika kita tidak tahu kunci CPU, yang tersisa bagi kita adalah menambal "CB_B" yang ada. Tetapi bagaimana jika, alih-alih memodifikasi setiap bagian, kami sepenuhnya menimpa seluruh bootloader? Dan karena ini, "tulis" bootloader lama, yang sudah kita tahu cara menambal, untuk mengganti yang baru? Jadi mereka melakukannya:

Kami mengenkripsi CB_A yang rentan dengan cara yang sama seperti pada gambar asli
XOR CB_B kami dengan yang baru, dapatkan "perbedaan"
Kami menaruhnya di "CB_B" terenkripsi!

Semuanya, sekali lagi, tanpa mengetahui kuncinya, kami berhasil mengganti konten yang dienkripsi, dan juga menempatkan bootloader yang rentan. Konsol diretas, Microsoft terkejut.

Pengembang bekerja keras, dan dalam pembaruan sistem berikutnya ... sedikit mengubah metode enkripsi "CB_B", sekarang kunci enkripsi juga menjadi tergantung pada versi "CB_A":

Sekarang, ketika mencoba untuk xor 'dan mendorong data ke "CB_A" versi lama, bootloader mendekripsi sampah karena perbedaan kunci. Dan bootloader baru tidak dapat diretas, dilindungi dengan baik dari serangan glich. Sejauh ini, kemenangan untuk Microsoft!

Corona melempar masalah

Sementara itu, revisi baru Xbox 360, Corona, memasuki pasar, dan itu membawa masalah modders:

Tidak cukup chip di papan tulis, dapatkah Anda menemukannya? Itu benar, chip HANA "tersembunyi" di jembatan selatan. Tidak ada tempat lain untuk mengambil frekuensi 48 MHz untuk chip mod, perintah perlambatan I2C sebelumnya tidak berfungsi. Tapi apa itu, flash NAND 16 MB, yang telah berfungsi sebagai penyimpanan sistem Xbox 360 selama bertahun-tahun, diganti dengan chip 4 GB dengan antarmuka eMMC! (Benar, hanya di versi konsol yang lebih murah, tapi tetap saja):

Tapi tidak ada, semuanya ditangani. Kami menemukan cara membaca / menulis memori flash melalui pembaca kartu:

Ditemukan perintah perlambatan I2C baru, osilator kristal 48 MHz eksternal menggantikan HANA:

Script build yang lengkap, menambahkan dukungan untuk NAND 4 GB ...

Namun Microsoft terus memasukkan tongkat ke roda. Misalnya, pada papan baru, beberapa resistor menghilang, tanpa itu chip mod berhenti bekerja:

Benar, ini diperbaiki dengan memasang jumper dengan besi solder:

Hal-hal menjadi lebih serius ketika trek POST_OUT menghilang dari papan:

Tapi di sini Microsoft tidak beruntung, "bola" CPU yang dibutuhkan untuk RGH berada di baris paling ekstrim:

Dan, tentu saja, mereka dapat terhubung dengan mereka. Pertama, yang paling lengan, sedikit mengebor tepi prosesor dan menyolder langsung ke bola dengan kabel:

Dan kemudian orang Cina merilis kerangka kerja dengan jarum pegas, persis bertumpu pada bola, dan masalahnya diselesaikan untuk semua orang:

Perbatasan Terakhir

Setelah kami mengalahkan "mahkota", ada satu masalah - versi baru dari sistem tidak menyerah pada peretasan. Untuk memulai RGH, Anda perlu mengetahui kunci CPU, dan untuk mengetahui kunci CPU, Anda harus menjalankan RGH setidaknya sekali. Masalah ayam dan telur pada umumnya.

Dan kemudian muncul pemikiran - dan mari kita tidak hanya memeriksa dengan otentikasi "kesalahan", tetapi kami juga akan melewatkan dekripsi! Jika berhasil, maka kita tidak perlu tahu kuncinya, letakkan "CB_B" di tempat yang jelas, itu saja. Gagasan ini menjadi dasar Double Glitch Hack (DGX):

Chip ini “buggy” persen dua kali, pulsa pertama melewatkan fase dekripsi bootloader, dan pulsa kedua melewatkan otentikasi. Ini bekerja jauh lebih tidak stabil, karena setidaknya diperlukan satu peluncuran yang sukses - maka kita mendapatkan kunci CPU dan melanjutkan seperti sebelumnya.

DGX tidak relevan untuk waktu yang lama, setelah 3 bulan orang Cina melempar dalam rilis "DGX RIP" dengan gambar yang berjalan pada setiap set-top box, bekerja dengan RGH standar dan, tentu saja, mulai jauh lebih stabil:

Gambar-gambar ini berisi versi khusus dari bootloader CB_A yang digunakan dalam produksi Xbox 360 dan, pada kenyataannya, adalah analog lengkap dari mode "Zero-Pairing" yang baik. Alih-alih kunci prosesor, "CB_A_mfg" ini mendekripsi "CB_B" dengan kunci null tetap:

Dan inilah Microsoft. Dalam versi "layanan" "CB_A" ini juga tidak ada pemeriksaan fusi dan tidak mungkin untuk melarangnya. Sudah cukup untuk merekam gambar sesuai dengan revisi Xbox 360, solder chip - dan semuanya berfungsi.

Winchester!

RGH sepenuhnya diperbaiki hanya dalam revisi baru konsol, nama kode Winchester. Untuk pertama kalinya, prosesor CPU dan GPU digabung dalam satu chip, papan disederhanakan sebanyak mungkin:

POST_OUT trek tidak hanya dihapus. Bahkan jika Anda menyolder ke platform di bawah prosesor:

Dan bahkan jika Anda menyolder prosesor ke versi khusus papan untuk pengembang, XDK, di mana trek ini masih ada:

Pada POST_OUT, hanya satu pulsa yang terlihat saat konsol dimulai. Bus terkunci:

Selain itu, hanya diblokir pada tahap produksi. Jika Anda mengambil prosesor "bersih" dari pabrik tempat Anda belum membakar sekering, POST_OUT bekerja di dalamnya!

Tapi RGH di atasnya tidak lagi berfungsi. Tidak peduli bagaimana Anda mencoba memberikan pulsa RESET, prosesor dengan benar melakukan reset, atau mengabaikan sinyal Anda karena durasinya terlalu pendek. Rupanya, modul logika khusus ditambahkan ke prosesor, memfilter garis RESET dan akhirnya memperbaiki kesalahan perangkat keras.

Posting scriptum

Ternyata revisi terbaru Xbox 360 tidak mungkin diretas?

Iya dan tidak. Saat ini, hanya ada satu cara yang dikenal untuk menjalankan sistem yang dimodifikasi pada revisi Winchester.

Kit pengembangan perangkat lunak (XDK) berisi berbagai kunci pribadi untuk menandatangani kode yang dikompilasi. Dan ternyata di antara mereka kunci "shadowboot" kunci, bootloader tingkat ketiga untuk sistem XDK, berantakan. Dan dengan itu, Anda dapat mengumpulkan gambar yang ditandatangani sah dengan firmware yang dimodifikasi. Hanya bekerja pada konsol "toko" biasa, dia tidak akan melakukannya. Kami membutuhkan prosesor dengan versi XDK konsol, atau "bersih" CPU dengan sekering non-sekering (Anda bisa melihatnya di Aliexpress):

Dan hanya pada saat itulah Anda memiliki kesempatan untuk merenungkan tulisan seperti itu di "informasi sistem" dari shell kustom:

Dan itu saja! Seperti biasa, saya siap menjawab pertanyaan Anda di komentar :)

Perlindungan dan Peretasan
Xbox 360 , Bagian 1 Perlindungan dan Peretasan Xbox 360 , Bagian 2
Perlindungan dan Peretasan Xbox 360, Bagian 3

Melindungi dan Meretas Xbox 360 (Bagian 3)