📿 🖊️ 👨🏿‍💼 UID dan Penguntit Otorisasi pada MAG250 🍮 🧑🏾‍🤝‍🧑🏼 📹

Saya telah lama tertarik dengan topik otorisasi konsol media di portal Stalker, tetapi itu tidak terjadi sebelumnya. Suatu hari saya tidak sengaja mendapatkan awalan Infomir MAG250 dan saya memutuskan untuk mengatasi masalah ini.

Latihan

Pertama-tama, saya membongkar awalan, menyolder kabel ke konektor dan menghubungkannya ke komputer. Setelah meluncurkan program terminal, saya senang dengan U-Boot yang familier. Proses booting juga dapat terganggu dengan menekan tombol apa saja (biasanya pabrikan menonaktifkan chip tersebut dan Anda harus menghabiskan banyak waktu untuk membawa U-Boot ke keadaan yang diinginkan). Akses dengan hak akses root juga tersedia melalui ssh.

Konsol ini dilengkapi dengan DRAM 256MB dan dua flash drive, NOR 1 MB dan NAND 256 MB. Dengan NOR, U-Boot dimuat dalam proses, yang memuat kernel dan sistem file dari NAND.

Fungsi Getuid ()

Awalan mengotorisasi dirinya sendiri di portal Stalker, mengirimkan banyak informasi, seperti, misalnya, jenis, versi firmware, versi perangkat keras, nomor seri, dll. Tapi saya secara khusus tertarik pada parameter device_id, yang dikeluarkan oleh fungsi gSTB.GetUID (). Pada pandangan pertama, itu adalah hash seperti SHA256 atau MD5. Mengacu pada dokumentasi resmi soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID , fungsinya dapat memakan waktu hingga dua parameter, tetapi hal pertama yang saya tertarik adalah opsi tanpa parameter. Dengan memuat stbapp di IDA, kami dapat dengan mudah menemukan fungsi ini.

Melangkah lebih jauh, kita melihat momen yang menarik

Di sini, program mengalokasikan memori 0x41 byte, membatalkannya, dan memanggil fungsi driver / dev / stapi / stevt_ioctl, meneruskannya dengan memori ini dan parameter 0xC004C919. Oleh karena itu, driver stevt_ioctl tertentu bertanggung jawab untuk menghasilkan UID. Untuk memeriksanya, saya dengan cepat membuat sketsa kode ini:

Menjalankannya di konsol, saya melihat UID yang sudah dikenal.

stevt_ioctl

Langkah selanjutnya adalah membongkar driver stapi_ioctl_stripped.ko, yang terletak di / root / modules. Kami memuat driver ke dalam IDA dan menemukan handler 0xC004C919 ioctl (saya menyebut fungsi ini calcHash).

Ada tiga poin menarik. Pertama, memori 0x41 byte disalin dari ruang pengguna ke ruang kernel (inilah yang ditransmisikan oleh pengguna dan dalam kasus kami terdiri dari nol), fungsi get_mem_type disebut(sepanjang jalan di kernel itu sendiri) dan hasilnya (lagi 0x41 byte) kemudian disalin ke area alamat pengguna. Untuk menemukan alamat fungsi get_mem_type, saya melihat dua kemungkinan: lihat saja file / proc / kallsysms, berharap akses tidak dibatasi, yah, atau, jika tidak, tuliskan assembler assembler untuk driver itu sendiri yang akan mengembalikan nilai register r0 di tempat yang tepat. Setelah mencari di / proc / kallsysms, saya terkejut dan menemukan alamat fungsi get_mem_type 0x8080E380.

Inti

Untuk analisis lebih lanjut, Anda perlu menganalisis kernel. Kernel itu sendiri dapat ditemukan di firmware pabrikan, atau Anda dapat menghapus dump menggunakan U-Boot

atau me-mount partisi yang diinginkan.

Berdasarkan informasi U-Boot, kernel dimuat pada 0x80800000, dan titik masuknya pada 0x80801000. Kami memuat kernel di IDA dan menemukan fungsi get_mem_type .

Setelah menganalisis kode, saya menemukan bagian ini, yang seharusnya mengembalikan UID.

Jadi UID disimpan di 0x80D635EC. Selanjutnya, kami mencari di IDA, di mana nilai ini terbentuk. Ini ada dalam fungsi init_board_extra (saya tidak akan menerjemahkan daftar lengkap)

Jadi ini adalah nilai yang tidak diketahui sama di alamat register r4 dari mana hash bunga dihitung (fill_hash dengan cara diselesaikan oleh SHA256). Saya benar-benar ingin mengetahui apa itu dan saya dengan cepat menulis sebuah insert assembler, yang, melalui fungsi printk, mengembalikan isi memori ke alamat register r2. Setelah memodifikasi kernel dengan cara ini, saya membuat uImage baru dan mengunggahnya ke drive USB. Dan di set U-Boot terminal:

usb start
fatload usb 0:1 80000000 uImage
bootm

Tetapi setelah tim terakhir, kesedihan seperti itu menunggu saya,

U-Boot dengan sopan menolak untuk mengirimkan kernel baru saya.

Mengedit U-Boot

Untuk meyakinkan U-Boot untuk mem-boot kernel saya, saya memutuskan untuk menambalnya di memori dengan perintah mw itu sendiri . Untuk memulai, saya membuat dump penuh NOR flash, yang terletak di 0xA0000000. Setelah mengarahkan dump ke IDA, saya menemukan alamat memori tempat U-Boot menyalin sendiri. Itu 0x8FD00000. Sekali lagi, setelah membuang bagian memori ini dan menjalankan IDA, saya dengan mudah menemukan fungsi yang memeriksa tanda tangan. Jika semuanya benar, dia mengembalikan 0. Selain itu, dia dipanggil di dua tempat yang berbeda.

Apa sebenarnya fungsi ini lakukan tidak menarik bagi saya. Dia hanya perlu mengembalikan 0 seperti ini:

mov #0x0, r0
rts
nop

Kode yang sesuai untuk U-Boot sekarang seperti ini:

usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm

Kemudian U-Boot dengan senang hati memuat kernel saya, yang dikeluarkan

EF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN

Analisis lengkap

Jadi, terdiri dari apa UID itu? Itu adalah sejumlah 8 byte yang tidak diketahui, nomor seri konsol, alamat MAC, jenis konsol dan sepotong sampah. Masih mencari tahu nomor berapa yang tidak dikenal itu dan dari mana sampah itu berasal. Saya kembali ke fungsi init_board_extra lagi .

Nomor tak dikenal diambil dari bagian kode ini:

Di sini, menggunakan fungsi __ioremap, kernel mengakses memori fisik pada 0x00000000 (yang merupakan alamat NOR flash), menulis 0x0F ke 0x00000000, kemudian 0x98 ke 0x000000AA dan membaca 8 byte mulai dari 0x000000C2. Dan apa ini? Ini adalah perintah protokol CFI dimana kernel berkomunikasi dengan NOR. 0x0F membawa NOR ke keadaan semula, dan dengan 0x98 beralih perintah mods CFI. Dalam modul ini, di alamat 0x000000C2 adalah Area Kode Keamanan atau nomor perangkat unik 64-bit. Itu nomor yang tidak dikenal adalah nomor flash NOR yang unik. Berikut ini adalah tumpukan identifikasi CFI.

Anda dapat melakukan dump langsung di U-Boot dengan mengatur

mw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100

Sepotong sampah hanyalah set karakter 32-byte biasa yang dijahit ke dalam kernel itu sendiri.Dan

sampah ini diproses sebelum menggunakan fungsi enkripsi swap_pairs , yang hanya mengubah posisi byte

[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]

Berdasarkan informasi yang diterima, saya berani berasumsi bahwa database pabrikan berisi informasi pada setiap ID NOR flash dan nomor seri serta alamat MAC yang sesuai.
Tentu saja, tidak mungkin untuk memilih semua ini, tetapi Anda dapat menulis perangkat lunak Anda sendiri, yang akan sepenuhnya meniru konsol.