Latar belakang

Magang adalah proses mendapatkan pengetahuan dan pengalaman. Tim Keamanan Raccoon kami percaya bahwa meningkatkan keamanan informasi perangkat dan perangkat lunak di sekitar kita tidak mungkin tanpa meneruskan pengetahuan dan pengalaman ini kepada generasi spesialis di masa mendatang. Itulah sebabnya kami telah menyelenggarakan magang individu untuk siswa dan lulusan berbakat selama bertahun-tahun.

Penelitian keamanan adalah keterampilan yang tidak diajarkan di universitas. Anda dapat mempelajarinya dari contoh nyata dan di bawah bimbingan mentor yang berpengalaman. Setiap tahun, karyawan magang kami memecahkan masalah teknis yang kompleks, mencapai tujuan mereka dan melanjutkan, memperluas cakrawala profesional mereka dan membuat dunia sedikit lebih aman. Masing-masing dari mereka memiliki kisah tersendiri tentang menjadi seorang spesialis, dan di bawah potongan - awal dari salah satunya.

Pendahuluan

Pada Oktober tahun lalu, saya datang untuk magang teknis di perusahaan NTC Vulkan. Ketertarikan saya diarahkan pada bidang rekayasa terbalik. Saya tahu apa itu, saya sudah mencoba untuk secara mandiri meneliti crackme di bawah x86, tetapi saya mengerti bahwa hal yang paling menarik terletak tepat di persimpangan perangkat lunak dan perangkat keras. Saya tidak memiliki pengalaman di bidang ini, tetapi saya memiliki keinginan untuk mencoba tangan saya.

Saya tidak memiliki harapan khusus dari acara ini - teman dan kenalan sering berbicara tentang magang teknis di berbagai perusahaan terkenal. Dan ketika saya ditawari untuk mencoba meneliti adaptor USB-SATA, saya senang dengan peluang baru untuk mempelajari sesuatu. Pengalaman yang diperoleh dan hasil yang saya capai memungkinkan untuk memverifikasi kebenaran pilihan tempat magang dan profesi masa depan.

Dan penelitian dimulai dengan mendapatkan adaptor USB-SATA biasa. Inilah yang saya lakukan selanjutnya.

Analisis rangkaian visual

Pertama, Anda perlu memeriksa papan adaptor dan menentukan elemen dasar perangkat. Pada gambar di bawah ini, blok utama komponen yang penting untuk pengoperasian perangkat ditandai. Foto yang diambil setelah penelitian:

Adaptor USB ke SATA. Tampilan atas

Adaptor USB ke SATA. Tampak bawah

Setelah menghabiskan beberapa waktu di Google, saya menemukan bahwa ada dua konverter tegangan di papan: satu di 3,3 V, yang lain di 1,2 V. Ini juga sangat mudah untuk menentukan memori flash yang dipasang di papan. ROM bekerja pada antarmuka SPI, dan kapasitas memori 512 Kbps.

Tampaknya tahap pengintaian sirkuit hampir selesai, tetapi pencarian cepat di Internet tidak menghasilkan hasil apa pun untuk kueri "ASM1051". Tidak ada dokumen yang ditemukan untuk chip yang dipasang di papan tulis. Benar, masih berhasil menemukan perangkat lunak yang memungkinkan Anda memperbaruinya. Selain itu, ada datasheet kecil untuk model ASM1053 yang lebih lama.

USB

Saat terhubung ke komputer, adaptor muncul sebagai perangkat penyimpanan USB. Saya memutuskan bahwa pengetahuan yang lebih dalam tentang USB mungkin akan berguna untuk penelitian saya, jadi beberapa jam berikutnya saya habiskan mempelajari antarmuka.
Secara umum, perangkat USB dapat dari kelas yang berbeda, tergantung pada fungsinya. Misalnya, flash drive adalah Mass Storage Device, dan keyboard dan mouse adalah Human Interface Device (HID) . Dan karena adaptor saya terlihat di manajer perangkat sebagai perangkat penyimpanan, itu berarti itu didefinisikan sebagai Mass Storage dan harus bekerja dengan perintah SCSI.

Baca memori dari ROM

Karena tidak ada yang diketahui tentang ASM1051 yang dipasang di papan, memori dari ROM dianggap sebagai tindakan yang paling jelas. Saya pindah ke laboratorium. Memisahkan chip memori flash dengan pengering rambut solder, menghubungkannya ke programmer USB ChipProg-48. Tidak ada masalah membaca, dan saya memiliki file biner di tangan saya. Saat itu, saya tidak bisa mengatakan apa yang ada di flash drive, dan mulai menganalisis data.

Analisis file biner

Pertama-tama, saya membuka dump memori dari ROM menggunakan WinHex, tetapi Anda dapat menggunakan editor HEX. Mulai melihat byte:

Mulai dari dump memori yang dibaca dari ROM

Tangkapan layar di atas adalah tangkapan layar dari editor. Baris ASMT1051 , yang dimulai dengan alamat 0x44, segera terbukti. Anda juga dapat melihat garis asmedia dari alamat 0x18. Untuk analisis data awal, saya menggunakan alat analisis frekuensi, yang tersedia di WinHex.

Histogram analisis frekuensi memori ROM

Histogram menunjukkan byte yang paling banyak dalam file. Selain tumpukan 0x00 dan 0xFF (kolom ekstrim pada histogram), byte berikut ini sering ditemukan dalam memori:

• 0x02;
• 0x74;
• 0x90;
• 0xA3;
• 0xE0;
• 0xF0.

Mungkin saja untuk mengkonfirmasi asumsi saya bahwa ada firmware dalam ROM. Cara mudah untuk melakukan ini adalah mencoba membandingkan opcodes dari berbagai arsitektur yang cocok untuk mikrokontroler (selanjutnya - MC) dengan byte yang sering ditemukan dalam memori.

Jika diperkirakan secara kasar, maka sangat sering dalam kode apa pun di assembler harus memenuhi perintah seperti:

• mov;
• jmp;
• menelepon;
• ret.

Tentu saja, dalam arsitektur yang berbeda perintah ini mungkin memiliki variasi yang berbeda, tetapi ada satu akal sehat.

Saya harus melalui beberapa set instruksi untuk kernel yang berbeda sebelum saya menemukan yang tepat. Perbandingan dengan arsitektur Intel 8051 memberikan hasil yang sangat masuk akal. Opcode dari beberapa perintah bertepatan dengan byte populer dari file, misalnya:

• 0x02 - LJMP addr16;
• 0x74 - MOV A, #immed;
• 0x90 - MOV DPTR, #immed;
• 0xA3 - INC DPTR;
• 0xE0 - MOVX A, @DPTR;
• 0xF0 - MOVX @DPTR, A.

Sepertinya ada firmware untuk MK di ROM. Seseorang dapat langsung memuat biner ke disassembler IDA Pro , tetapi saat makan siang salah satu rekan bertanya:

"Apakah kamu yakin kode dalam memori dimulai tepat dari alamat nol?"

Dan sungguh, Anda perlu mempertimbangkan bahwa beberapa "sampah" atau data dari alamat 0x00 dapat di memori.

Secara umum, saya menghadapi tugas menentukan alamat awal kode. Untuk mencapai tujuan ini, yang terbaik adalah menggunakan emulator EM100 SPI. Emulator menggantikan chip memori di papan, dengan itu tidak perlu menyolder ROM setiap kali dengan firmware, selain itu, EM100 dapat merekam log akses memori. Mengingat firmware dari ROM telah dibaca, sekarang Anda dapat mengunduhnya ke emulator SPI. Selanjutnya, Anda perlu menyolder emulator ke papan adaptor dan merekam log saat menghubungkan adaptor melalui USB ke PC.

Emulator SPI disolder ke papan adaptor USB-SATA

Saya menyolder kabel dari emulator ke bantalan dari memori flash dan mem-flash emulator dengan beberapa firmware. Sekarang tinggal melihat apakah MK mengalamatkan memori, dan jika demikian, di alamat apa.

ROM akses ke memori ROM (diperoleh dengan menggunakan perangkat lunak emulator SPI)

Gambar di atas menunjukkan bahwa ketika daya terhubung ke adaptor, pengontrol ASM1051 yang terpasang di papan mengirimkan beberapa perintah 0x03 (Baca Data).

Pertama, ASM1051 membaca 0x80 byte, mulai dari 0x0000. Berikut ini adalah dua byte, mulai dari alamat 0x0080, lalu dua byte lagi dari alamat 0x8082. Kemudian ia membaca sebagian besar memori dari ROM, mulai dari alamat 0x0082.

Kita dapat mengasumsikan bahwa sejumlah besar byte yang dibaca dari ROM terakhir, dimulai dengan alamat 0x0082, mungkin merupakan kode. Apa dan mengapa diminta sebelum ini belum jelas. Hanya diketahui bahwa sebagai respons terhadap permintaan pertama, ASM1051 akan menerima baris dari memori flash yang ditandai pada gambar di atas. Mereka hanya terletak di 0x80 byte pertama.

Sudah waktunya untuk memeriksa dugaan bahwa memori eksternal di papan berisi firmware untuk MK dengan kernel 8051, dan kode itu sendiri terletak dari alamat 0x0082. Buka dump memori di IDA Pro, tentukan jenis Prosesor Intel 8051 dan offset untuk kode 0x0082.

File biner dibuka di IDA Pro dengan offset 0x82

Tidak ada masalah membuka biner di disassembler.

Kesimpulan:

1. MK ASM1051 memiliki arsitektur 8.051.
2. Di ROM ada kode yang dimulai dengan alamat 0x82. Ada hal lain selain kode.
3. 0x80 byte pertama menarik perhatian.

Analisis kode

Sekarang saya telah memastikan bahwa kode dalam IDA dimuat dengan benar, Anda dapat mulai menganalisis dan mengomentarinya secara paralel.

Selama mempelajari kode, fungsi sederhana ditemukan, seperti mengurangi angka 32-bit, berbagai penangan ditemukan, mirip dengan switch () di S. Melkali, dan fungsi yang sangat sederhana, seperti menyimpan nilai dari register R7 ke dalam memori di beberapa alamat. Temuan paling signifikan yang akan saya jelaskan di bawah.

Temukan No. 1

Menariknya, sebagai tanggapan atas permintaan INQUIRY ( perintah SCSI ) saya, saya menerima respons yang berisi dua baris yang kami lihat di awal memori ROM. Tentu saja, saya segera mengubah baris ini dalam memori emulator, menunggu permintaan INQUIRY untuk melihat apa yang saya tulis. Mimpi naif seperti itu dengan cepat runtuh. Sekarang, sebagai tanggapan terhadap perintah, saya melihat baris lain, ASM1051 tidak meminta sebagian besar memori dari ROM. MK hanya membaca 0x80 byte pertama dan semua. Dalam arsitektur 8051, mask (perangkat keras) firmware dapat digunakan, tampaknya, ASM1051 mulai mem-boot darinya.

Jadi menjadi jelas bahwa 0x80 byte pertama sangat penting, dan mengubahnya tidak akan berfungsi. Saya memutuskan untuk mempelajari secara lebih rinci permintaan yang dibuat MK pada SPI sebelum mengunduh kode.

Permintaan data SPI dalam ROM

Dua permintaan dua byte tampak menarik. Pencarian di IDA 0x00, 0x80 dan 0xEB menghasilkan sejumlah besar hasil yang saya tidak menganalisis, tetapi byte 0x5A jarang ditemui.

Perbandingan dengan byte 0x5A. Menghitung checksum-8

Secara harfiah klik keenam membawa saya ke bagian kode yang ditunjukkan pada gambar di atas. Dapat dilihat bahwa nilai dari register dengan alamat 0x80 7E dibandingkan dengan 0x5A. Kemudian checksum-8 dibaca untuk nilai yang terletak dari alamat 0x80 04 hingga 0x80 7E . Selanjutnya, nilai pada 0x80 7F dibandingkan dengan jumlah yang diterima sebelumnya.

Awal memori dalam ROM

Offset seperti ini menyerupai awal dump memori dari ROM. Gambar di atas menunjukkan bahwa alamat 0x7E berisi byte 0x5A. Dan jika Anda menghitung checksum-8 untuk byte dari posisi 0x04 hingga 0x7E, maka kami mendapatkan 0xA7, dan nilai ini hanya terletak di alamat 0x7F.

Dengan cara yang sama, kami berhasil menemukan perhitungan jumlah cek untuk byte dari alamat 0x0082 hingga 0x807F (tampaknya ini adalah seluruh kode), yang diperiksa dengan byte di alamat 0x8083. Dan pada 0x8082 lagi terletak nilai 0x5A.

Ya, ini sedikit lebih rumit daripada hanya mengubah garis dalam memori. Saya juga mengubah mereka, tetapi saya juga menghitung dan menuliskan cek-jumlah untuk file baru di tempat yang tepat. Setelah itu, sebagai tanggapan atas perintah SCSI INQUIRY, saya melihat dialog saya.

Kesimpulan:

1. Selama boot, ASM1051 berupaya mengunduh kode dari ROM.
2. Pertama, ASM1051 membandingkan byte checksum-8 dari alamat 0x04 ke 0x7E dengan nilai 0x7F.
3. Jika perbandingan jumlah cek untuk pembukaan telah berhasil, maka kita dapat mempertimbangkannya untuk "kode" (alamat dari 0x0082 hingga 0x807F). ASM1051 membandingkan jumlah ini dengan nilai pada alamat 0x8083 dan memverifikasi bahwa byte 0x5A terletak di alamat 0x8082.
4. Jika semua pemeriksaan sudah benar, maka ASM1051 diambil dari ROM, jika tidak menggunakan firmware mask.

Temukan nomor 2

Saat meninjau dan mengomentari fungsi, saya menemukan bahwa seringkali fungsi PRINTF digunakan dalam kode (saya menyebutnya demikian). Hal yang menarik tentang itu adalah bahwa sebelum dipanggil, karakter yang dicetak ditulis ke register R7.

Fungsi PRINTF di IDA Pro

Fungsi itu sendiri disajikan pada gambar di atas. Mari kita hadapi dia. Pertama-tama, Anda perlu memindahkan nilai dari register dengan alamat 0x7F6 ke baterai. Jika ada nol, maka keluarlah dari fungsinya. Hal yang paling menarik terjadi jika tidak ada nol. Kemudian nilai register R7 dipindahkan ke register dengan alamat 0xC001, dan, seperti yang kita ingat, sebelum memanggil fungsi ini, karakter yang dicetak ditulis ke R7. Selanjutnya, periksa apakah nilai dalam R7 sama dengan kode karakter "." Atau "-", jika tidak, maka keluar dari fungsinya. Tetapi jika perbandingan ternyata berhasil, maka fungsi mengambil nilai dari register dengan alamat 0x16A dan memindahkannya ke 0xC001, tetapi apakah itu rumit. Misalnya, alih-alih byte 0x41 (karakter "A" di ASCII), fungsinya akan pindah ke 0xC001 byte 0x34 (karakter "4" di ASCII), lalu 0x31 (karakter "1" di ASCII). Keluar dari fungsi lagi.

Saya menemukan bahwa pemeriksaan di awal fungsi tidak dapat dilewati, karena register dengan alamat 0x7F6 diinisialisasi ke nol, maka tidak berubah dalam kode. Artinya, fungsi ini dinonaktifkan oleh programmer, meskipun tetap dikompilasi. Fakta bahwa byte hanya ditulis ke register 0xC001 (dan terkadang dua berturut-turut), menunjukkan bahwa ini kemungkinan besar merupakan register perangkat keras.

Semua ini menyerupai UART. Untuk mengetahui apakah ini benar, Anda harus melakukan yang berikut:

1. Identifikasi kaki-kaki pada ASM1051 di mana UART adalah output.
2. Tentukan parameter UART (kecepatan, paritas, jumlah bit stop).
3. Alangkah baiknya untuk mengaktifkan UART dalam kode (rupanya, dimatikan).

Semuanya terlihat cukup sederhana: Anda dapat bergiliran menyentuh kaki dengan penganalisa logis dan mencari yang di mana saat mengirim UART akan terlihat. Di hadapan sinyal, kecepatan dapat ditentukan oleh waktu pulsa. Dengan sisa parameter, semuanya juga jelas, lihat saja saat mengirim byte pada alat analisa.

Untuk "mengaktifkan" fungsi ini, Anda dapat menulis nol alih-alih tiga baris pertama, di mana nilainya diperiksa dalam register dengan alamat 0x7F6. Untuk melakukan ini, saya kembali membuka firmware di WinHex.

Enam byte yang akan direset dialokasikan.

Di editor, saya mengubah enam byte yang diinginkan menjadi nol. Sekarang firmware siap dan dapat diunduh ke emulator ROM. Jika kita mengasumsikan bahwa fungsi untuk menghasilkan byte di UART dinyalakan, dan panggilannya terletak sangat sering di seluruh kode, maka kita dapat berharap bahwa byte harus "terbang" dari UART ketika adaptor berjalan. Saya berharap untuk melihat pelacak yang memberi sinyal dalam byte di UART berapa banyak kode yang dieksekusi.

Seperti yang saya tulis di atas, untuk menemukan kaki Rx dan Tx yang diperlukan, Anda dapat melihat penganalisa logika satu per satu. Namun, saya berasumsi bahwa Rx dan Tx pada ASM1051 berada di tempat yang sama dengan ASM1053 - kaki 40 dan 41, masing-masing. Saya meletakkan probe analyzer ke pin 41 (diasumsikan Tx) dan saya melihat sesuatu yang mirip dengan sinyal yang diinginkan:

Diagram waktu dengan kaki 41 - Tx

Untuk menghubungkan konverter USB-UART dan mengamati karakter cetak yang masuk di terminal, saya harus menyolder dua kabel tipis langsung ke papan adaptor dan memperbaikinya dengan lem panas.

Dua kabel disolder ke RX dan TX

Saya mempelajari diagram dari gambar "Timing diagram from leg 41 - Tx" sedikit: waktu satu pulsa, ternyata, adalah 1 μs, dan untuk enam bit - 6,3 μs. Setelah menghitung ulang nilai dalam baud, saya menerima sekitar 950.000 baud, kecepatan UART standar terdekat adalah 921600 baud. Saya pikir perbedaan ini diperoleh karena kesalahan pengukuran oleh penganalisis logis, saya mengambil bukan perangkat yang paling layak, tetapi “bayi” Tiongkok. Setelah mengatur parameter di jendela program Terminal 1.9b, saya dapat mengamati byte yang masuk dari ASM1051 MK selama operasinya.

Jendela program Terminal 1.9b selama operasi adaptor

Kesimpulan:

ASM1051 MK memiliki modul perangkat keras UART. Register untuk mengirim data memiliki alamat 0xC001. Kecepatan data adalah 921600 baud. Ada one stop bit. Leg 41 adalah Tx dan Leg 40 adalah Rx (meskipun ini tidak akurat).

Temukan nomor 3

Menggulir kode di disassembler, menambahkan komentar, Anda dapat menemukan konstruksi lebih sulit daripada menulis nomor dalam register. Jadi saya menemukan penangan yang menarik, yang sebagian di C, tampak seperti switch () .

Penangan perintah dari register dengan alamat 0x800F

Memahami bahwa di suatu tempat perintah SCSI harus diproses, saya mulai mencari di antara mereka untuk byte yang isi register dengan alamat 0x800F dibandingkan pada gambar di atas. Ternyata empat cabang pertama memeriksa perintah Baca (10), Tulis (10), Baca (16), Tulis (16). Tidak ada keraguan bahwa ini adalah penangan perintah SCSI. Selanjutnya, saya melihat fungsi yang dipanggil jika perintah yang masuk tidak Baca / Tulis (u_Switch). Itu, tergantung pada byte dalam register dengan alamat 0x16A (nilainya diambil dari 0x800F), membaca alamat yang akan kita dapatkan ketika mereka keluar dari fungsi ini. Ini mirip dengan switch () .

Ganti Perintah SCSI

Karena saya sudah menentukan byte yang saya bandingkan dengan perintah SCSI yang datang ke adaptor, saya dengan cepat mengatur korespondensi alamat dengan perintah. Jadi, misalnya, pada gambar di atas dapat dilihat bahwa jika byte 0x1A berada dalam register dengan alamat 0x16A, maka setelah keluar dari fungsi u_Switch kita akan pergi ke alamat 0x1B85. Menariknya, tidak semua byte yang dibandingkan dengan u_Switch didefinisikan dalam standar SCSI. Artinya, adaptor dapat memproses byte 0xE6 atau 0xDF, tetapi tidak diperbaiki oleh standar.

Seperti yang Anda lihat, adaptor dapat menjalankan perintah khusus dan ada fungsi handler untuknya.

Halaman 13 dari Kelas Penyimpanan Massal Universal Serial Bus

Perhatikan offset 0x0F relatif terhadap alamat 0x8000. Sebelum prosesor, dari register dengan alamat 0x800F perintah SCSI dibaca. Jika Anda hati-hati membaca tabel pada gambar di atas, Anda dapat melihat bahwa di Command Block Wrapper (CBW), bidang CBWCB juga memiliki offset 0x0F . Ternyata alamat memori ASM1051 RAM, dimulai dengan 0x8000, dapat berupa buffer USB, seperti yang ditunjukkan pada tabel di bawah ini.

Gambar di bawah ini menunjukkan bagian kode di mana perbandingan dengan string USBC terjadi (harus berupa tanda tangan dCBWSignature) dan tanda tangan yang diusulkan terletak dari alamat 0x8000. Saya pikir ini cukup untuk memastikan bahwa buffer USB terletak di memori RAM mulai dari 0x8000.

Periksa bidang dCBWSignature untuk kecocokan dengan string USBC

Kesimpulan:

1. MK ASM1051 tidak hanya dapat menangani perintah SCSI, yang dijelaskan dalam standar.
2. Alamat awal buffer USB adalah 0x8000. Perintah SCSI terletak di register dengan alamat 0x800F, yang berarti bahwa akan ada data / argumen lebih lanjut dari perintah.

Temukan nomor 4

Mengetahui bahwa MK dapat memproses tim yang tidak standar, saya ingin tahu apa yang mereka lakukan. Kebanyakan dari mereka dengan cepat menaati saya. Saya tidak akan mengutip studi kode dari perintah-perintah ini, karena ini bisa memakan waktu lama dan mungkin menjadi bahan untuk artikel terpisah yang berjudul "Assembler itu sederhana," Saya akan menjelaskan hasil dalam tabel di bawah ini.

Saya akui bahwa saya tidak mengetahui semua perintah dengan membaca fungsi di IDA. Setelah menabrak dinding selama penelitian, saya ingat bahwa saya melihat perangkat lunak dan banyak firmware untuk ASM1051 ketika saya sedang mencari dokumentasi di dalamnya. Dengan menggunakan perangkat lunak yang ditemukan, Anda dapat memperbarui firmware dan menyalakan ulang perangkat. Oleh karena itu, saya memutuskan bahwa sudah waktunya untuk menggunakan Device Monitoring Studio dan melihat apa yang mengirim PC ke adaptor selama pembaruan.

Dengan demikian, dimungkinkan untuk memahami bagaimana proses pembaruan firmware terjadi: pertama pembukaan dibuka (dengan perintah 0xE1), kemudian kode ditulis dengan perintah 0xE3, kemudian semua ini dipoles dengan me-reboot (perintah 0xE8). Untuk pembaruan yang cepat dan mudah, saya menulis skrip Python yang menyisipkan baris yang diperlukan ke dalam pembukaan, kemudian membaca jumlah cek dan memperbarui perangkat. Sekarang saya tidak lagi membutuhkan emulator, saya mendapat kesempatan untuk mengunggah firmware ke ASM1051 melalui USB, Anda dapat mengembalikan ROM asli ke papan.

Kesimpulan

Untuk memperbarui firmware, tiga perintah SCSI harus dijalankan secara berurutan: 0xE1, 0xE3 dan 0xE8.

Temukan nomor 5

Selain perintah tidak berdokumen, itu menarik untuk melihat penangan perintah standar.

Memindahkan bit ketiga dari register 0xC884 ke bit ketujuh register 0x8002

Ada satu tes menarik dalam penangan perintah MODE SENSE (10) SCSI. Gambar di atas menunjukkan bagian dari kode fungsi. Dapat dilihat bahwa bit ketiga sedang dibaca dari register 0xC884 . Kemudian nilai bit ini diatur dalam register pada 0x8002.

Yang menarik di sini adalah bahwa register 0xC884 tidak diinisialisasi di mana pun dalam kode, yang berarti kemungkinan besar perangkat keras.

Tabel 362 Manual Referensi Perintah SCSI

Selain itu, jika Anda melihat dokumentasi untuk perintah 0x5A SCSI (MODE SENSE), menjadi jelas bahwa adaptor USB-SATA harus menanggapi permintaan MODE SENSE. Byte ketiga dari respons berisi bit ketujuh dari WP (Write Protect - write protection). By the way, saya sudah melihat bit ketujuh di 0x8002, dan offset dari awal buffer USB (0x8000) persis 3 di sini .

Kesimpulan:

Adaptor USB-SATA yang teruji membaca bit ketiga dari register perangkat keras pada 0xC884 dan mengirimkannya ke host USB sebagai bit WP.

Temukan nomor 6

Register perangkat keras yang ditemukan selama penyelidikan MODE SENSE SCSI handler sangat mirip dengan GPIO. Untuk mengkonfirmasi ini, saya memutuskan untuk menyentuh kaki ASM1051 dengan resistor langsung dan membaca nilai register (perintah SCSI 0xE4) dengan alamat 0xC884 . Untuk melakukan ini, saya menulis skrip Python menggunakan perintah SCSI khusus yang memantau nilai dalam register 0xC884 dan menampilkannya di PC.

Setelah melakukan percobaan seperti itu, saya menyusun tabel di mana saya menampilkan bit mana dalam register 0xC884 yang berubah ketika resistor ASM1051 menyentuh kaki. Ternyata register yang diteliti terkait erat dengan GPIO, tetapi upaya untuk menulisnya (dengan perintah SCSI 0xE5) tidak berhasil - nilainya tidak berubah.

Kemudian saya memutuskan bahwa register ini hanya baca-saja, atau di suatu tempat menulisnya dilarang di tingkat perangkat keras. Jika, misalnya, kaki-kaki MK awalnya diatur hanya untuk membaca, maka, mungkin, menulis ke register 0xC884 bisa jadi tidak tersedia.

Secara umum, untuk menemukan register yang terkait dengan GPIO, saya membahas kode inisialisasi MK. Saya mencatat semua register yang alamatnya dekat dengan 0xC884 . Saya mendapat sekitar 10 dari mereka, saya mengingatkan Anda bahwa kaki kesepuluh dari MK terhubung ke LED di papan, itu sesuai dengan bit kedua di register 0xC884 . – 0880 , (, ). , , 0880 (/), 0884 , - .

0880 , 0884 . 0884 . ASM1051.

:

GPIO ASM1051. 0880 / I/O. 0884 I/O.

№ 5.

GPIO- , 45- 0884 . WP , USB. 45- , HDD, , .

HDD, 45-

. GND 45- , HDD. .

45- ASM1051 HDD.

USB-SATA-. ASM1051. , - , . , GPIO. – ASM1051 , HDD. , , (« »), , , USB-SATA- ASM1051.

, footprint ASM1051, datasheet ASM1053. , ASM1051 .

ASM1051

, 3D- , .

3D-

WP . GPIO ASM1051 , UART. , SATA, HDD. USB 3.0 Micro-B Type-C. HDD USB, HDD 3.5" +12 , 12 21 . .

Kesimpulan

, .

-, , . « «», . , .

, (, ) embedded-. , , . , , , , .

, datasheets, , . , !

Raccoon Security – «» , , , .
, , . .