Geekly articles weekly

Analisis BIOS / UEFI Statis atau Cara Mendapatkan Grafik Ketergantungan

"Aku selesai menempa kemarin,
Saya menipu dua rencana ... "
... VS Vysotsky song ...

Hampir 3 tahun yang lalu (pada awal 2016), keinginan pengguna muncul pada masalah proyek UEFITool di GitHub: untuk membangun "Grafik Ketergantungan" untuk modul yang dapat dieksekusi yang termasuk dalam BIOS / UEFI.

Bahkan sebuah diskusi kecil pun terjadi, sebagai akibatnya akhirnya menjadi jelas bahwa tugas ini sama sekali tidak sepele, fungsi yang tersedia untuk solusinya tidak cukup, prospek pada saat itu berkabut ...

Dan pertanyaan ini tetap limbo, dengan prospek realisasi di masa depan yang tidak terbatas (tetapi keinginan mungkin tetap, dan harapan, seperti yang Anda tahu, mati terakhir!).

Ada saran: akhirnya, temukan solusi untuk masalah ini!

Tentukan persyaratannya


Lebih lanjut diasumsikan bahwa kita sedang berhadapan dengan Arsitektur Intel 64 dan IA-32.

Untuk menentukan dengan jelas apa yang kami putuskan untuk dibangun, kami harus membahas lebih detail dengan berfungsinya masing-masing fase operasi BIOS / UEFI.

Jika Anda hati-hati melihat jenis file yang disajikan dalam volume firmware FFS , ternyata sebagian besar file yang tersedia menyertakan bagian dengan modul yang dapat dieksekusi.

Sekalipun kami mempertimbangkan firmware ASUS atau ASRock yang baru dilipat, di mana Anda dapat dengan mudah menemukan hingga satu setengah ratus file jenis EFI_FV_FILETYPE_FREEFORM yang berisi gambar-gambar dengan format berbeda, namun, bahkan dalam firmware ini ada file yang lebih dapat dieksekusi daripada file jenis lainnya.

+--------------------------------------------------------------------------+ | File Types Information | +--------------------------------------------------------------------------+ | EFI_FV_FILETYPE_RAW = 6 | | EFI_FV_FILETYPE_FREEFORM = 83 | | EFI_FV_FILETYPE_SECURITY_CORE = 1 | | EFI_FV_FILETYPE_PEI_CORE = 1 | | EFI_FV_FILETYPE_DXE_CORE = 1 | | EFI_FV_FILETYPE_PEIM = 57 | | EFI_FV_FILETYPE_DRIVER = 196 | | EFI_FV_FILETYPE_APPLICATION = 1 | | EFI_FV_FILETYPE_SMM = 60 | | EFI_FV_FILETYPE_SMM_CORE = 1 | | EFI_FV_FILETYPE_PAD = 4 | +--------------------------------------------------------------------------+ | Total Files : = 411 | +--------------------------------------------------------------------------+
Contoh komposisi beberapa firmware biasa (biasa).

Meskipun file yang berisi modul yang dapat dieksekusi tidak ditandai dalam tabel ini, namun, mereka akan (menurut definisi) semua ada dalam daftar ini, kecuali untuk file dengan sufiks RAW, FREEFORM dan PAD.

File dengan akhiran "CORE" (SECURITY_CORE, PEI_CORE dan DXE_CORE) adalah "kernel" yang sesuai (modul kepala dari fase yang sesuai) yang menerima kontrol dari fase lain (atau setelah mulai), SMM_CORE adalah sub-fase dari fase DXE dan dipanggil saat itu pemenuhan. APLIKASI hanya dapat dilakukan atas permintaan pengguna, itu tidak memiliki ikatan khusus pada fase.

Jenis file yang paling umum tidak terdaftar: PEIM (modul fase PEI), DRIVER (modul fase DXE) dan SMM (modul sub-fase DXE). Modul CORE dari fase PEI dan DXE termasuk operator, yang mengontrol urutan memuat / memulai modul dari fase yang sesuai.

Dalam contoh di atas, tidak ada opsi gabungan, kami tidak akan mengingatnya: meskipun mereka ditemukan dalam firmware asli, itu sangat jarang. Mereka yang ingin menerima informasi yang lebih terperinci dan terperinci diundang untuk merujuk ke artikel CodeRush 1 , 2 , 3 . Dan juga mengutip sarannya: "Untuk penggemar dokumentasi asli, spesifikasi UEFI PI selalu tersedia, semuanya dijelaskan secara lebih rinci."

Setiap modul firmware yang dapat dieksekusi adalah modul format PE + (Portable Executable) atau turunannya (Terse Executable: format TE). Modul executable format PE + adalah sekumpulan data terstruktur "sedikit" yang berisi informasi yang dibutuhkan oleh loader untuk memetakan modul ini ke memori.

Format (struktur) PE + itu sendiri tidak memiliki mekanisme interaksi antara modul PE + individu. Setiap modul yang dapat dieksekusi setelah memuat dan memulai eksekusi adalah proses independen yang otonom, (well, seharusnya begitu!) , I.e. modul tidak boleh "mengasumsikan" apa pun tentang apa yang sedang dilakukan di luarnya.

Organisasi interaksi antara modul yang dapat dieksekusi terpisah dari satu fase UEFI diatur melalui modul CORE pada fase yang sesuai. Masing-masing modul yang dapat dieksekusi dapat mendefinisikan (Menginstal) protokol, meminta (Temukan) dan menggunakan protokol yang dideklarasikan oleh modul lain, mengatur / mendeklarasikan peristiwa, dan mendeklarasikan (memberitahukan) pengendali acara.

Dengan demikian, untuk setiap modul firmware yang dapat dieksekusi, kami tertarik dengan keberadaan artefak berikut:

  1. Daftar protokol yang didefinisikan oleh modul ini. (Setiap protokol diidentifikasi oleh penunjuk nomor unik).
  2. Daftar protokol yang menggunakan modul ini (mencoba menggunakan).
  3. Daftar acara yang diumumkan modul ini. (Acara ini memiliki nomor - panduan unik).
  4. Daftar penangan acara hadir (diimplementasikan dan dapat diinstal / diinisialisasi) dalam modul ini.
Grafik Ketergantungan Statis untuk fase BIOS / UEFI tertentu dianggap ditentukan jika, untuk setiap modul fase yang dapat dieksekusi, kita tahu semua artefak yang tercantum di atas pada bagian 1-4. (Dengan kata lain, jika kita telah mendefinisikan semua informasi yang menggambarkan saling ketergantungan antar modul).
Kami hanya akan mempertimbangkan opsi analisis statis, ini berarti bahwa beberapa elemen dari kode yang mengimplementasikan item 1-4 tidak dapat dicapai (merupakan fragmen dari kode "mati") atau hanya dapat dicapai dengan opsi tertentu untuk input data / parameter.

Semua yang kami pertimbangkan sejauh ini hanya berdasarkan pada spesifikasi BIOS / UEFI . Dan untuk memahami "hubungan" dari modul-modul firmware yang dapat dieksekusi yang ada yang bersangkutan, kita harus mempelajari lebih dalam strukturnya, yang berarti bahwa kita setidaknya harus membalik sebagiannya (mengembalikan algoritma asli).

Seperti telah disebutkan di atas, modul executable format PE + hanyalah seperangkat struktur untuk loader, membangun dalam memori objek yang akan ditransfer kontrol, dan objek ini pada dasarnya terdiri dari instruksi prosesor, serta data untuk instruksi ini.
Kami akan mengatakan bahwa pembongkaran lengkap modul yang dapat dieksekusi dibuat jika mungkin untuk memecahkan masalah pemisahan perintah dan data yang disajikan dalam modul ini.
Pada saat yang sama, kami tidak akan memaksakan persyaratan apa pun pada struktur dan tipe data, cukup jika untuk setiap byte milik gambar modul yang dapat dieksekusi yang diterima oleh loader, kami dapat dengan jelas mengatakan yang mana dari dua kategori yang dimilikinya: byte perintah atau byte data.

Tugas untuk benar - benar membongkar modul yang dapat dieksekusi itu sendiri umumnya tidak sepele, apalagi, dalam kasus umum, secara algoritmik tidak dapat dipecahkan. Kami tidak akan masuk ke detail masalah ini, mematahkan tombak juga, kami menganggap pernyataan ini sebagai aksioma.

Misalkan:

  1. Kami telah memecahkan masalah pembongkaran lengkap untuk modul eksekusi BIOS / UEFI tertentu, mis. kami berhasil memisahkan perintah dan data.
  2. Ada kode sumber untuk modul dalam bahasa "C" (dalam firmware BIOS / UEFI saat ini, modul sebagian besar dikembangkan hanya dalam bahasa "C").

Bahkan dalam kasus ini, hanya membandingkan hasil yang diperoleh (teks assembler hanyalah representasi tekstual dari instruksi prosesor) dengan kode sumber dalam bahasa "C" akan hampir selalu membutuhkan pengalaman / kualifikasi yang baik, dengan pengecualian kasus yang benar-benar merosot.

Studi lengkap tentang contoh yang menunjukkan kesulitan dalam mengidentifikasi atau membandingkan hasil pembongkaran dengan kode sumber bukan bagian dari rencana kami saat ini.
Mari kita perhatikan hanya sebuah contoh ketika dalam daftar assembler kita menemukan perintah "Panggilan Tidak Langsung" - panggilan prosedur implisit.

Ini adalah contoh panggilan prosedur yang dirujuk dalam tabel. Tabel yang berisi tautan ke berbagai prosedur adalah kasus tipikal untuk mengimplementasikan presentasi antarmuka protokol arbitrer.

Tabel seperti itu tidak harus hanya terdiri dari referensi untuk prosedur, tidak ada yang melarang menyimpan data sewenang-wenang dalam struktur ini (dan ini adalah contoh dari struktur "C" yang khas).

Inilah salah satu bentuk panggilan semacam itu (alih-alih dari register ecx, hampir semua varian register prosesor 32-bit dimungkinkan):
FF 51 18 hubungi dword ptr [ecx + 18h]
Setelah mendapatkan, berdasarkan analisis, perintah serupa, dimungkinkan untuk mencari tahu seperti apa prosedur yang dipanggil, daftar parameternya, jenis dan nilai hasil yang dikembalikan, hanya mungkin jika kita mengetahui jenis objek (protokol) yang antarmuka-nya disebut oleh perintah ini.

Jika kita tahu bahwa dalam contoh sebelumnya, register "ecx" berisi sebuah pointer (alamat awal tabel EFI_PEI_SERVICES), kami dapat menerima (hadir) perintah ini dalam bentuk berikut yang lebih dimengerti dan "menyenangkan":
Panggilan FF 51 18 [exx + EFI_PEI_SERVICES.InstallPpi]
Memperoleh informasi tentang isi register yang berpartisipasi dalam perintah "Panggilan Tidak Langsung" paling sering melampaui kemampuan disassembler "tipikal", yang tugasnya hanya menganalisis dan mengubah kode biner prosesor menjadi bentuk yang dapat dibaca manusia - sebuah representasi tekstual dari perintah prosesor yang sesuai.

Untuk mengatasi masalah ini, sering diperlukan untuk menggunakan informasi tambahan (Meta) yang tidak tersedia dalam modul biner yang dapat dieksekusi (hilang karena kompilasi dan penautan - ini digunakan dalam transformasi dari satu representasi algoritma ke yang lain, tetapi prosesor tidak perlu lagi menjalankan perintah yang diterima).

Jika Metadata ini masih tersedia bagi kita dari sumber tambahan, kemudian menggunakannya dan melakukan analisis tambahan, kita mendapatkan representasi yang lebih dapat dimengerti (dan lebih akurat) dari perintah "Panggilan Tidak Langsung" .

Bahkan, analisis lanjutan ini sudah lebih mengingatkan pada proses "dekompilasi", meskipun hasilnya tidak terlihat seperti kode sumber modul dalam bahasa "C", namun, di masa depan kita akan menyebut proses ini sebagai dekompilasi perintah yang disebut "Panggilan Tidak Langsung" atau " dekompilasi sebagian " .

Jadi, kami siap untuk menentukan kondisi yang cukup untuk membangun grafik interdependensi dari modul firmware yang dapat dieksekusi untuk fase BIOS / UEFI yang diberikan:
Untuk mendapatkan Grafik Ketergantungan Statis (salah satu fase - PEI atau DXE), cukup untuk membongkar sepenuhnya semua modul yang dapat dieksekusi pada fase yang sesuai (setidaknya memisahkan semua perintah), dan mendekompilasi perintah "Panggilan Tidak Langsung" yang ada dalam modul yang dibongkar.
Segera ada banyak pertanyaan tentang bagaimana pengetahuan kita tentang tim "Panggilan Tidak Langsung" terhubung dengan interaksi antar-modul.
Seperti disebutkan di atas, seluruh layanan manajemen interaksi disediakan oleh modul "INTI" pada fase yang sesuai, dan layanan dalam fase dirancang sebagai tabel layanan "dasar".

Karena model interaksi antara modul dalam fase PEI dan DXE, meskipun secara ideologis (secara struktural) serupa, secara teknis masih berbeda, diusulkan untuk beralih dari beberapa pertimbangan formal untuk mempertimbangkan konstruksi langsung tertentu dari Grafik Ketergantungan Statis untuk fase PEI.

Kami bahkan akan dapat menentukan dan merumuskan kondisi yang diperlukan dan cukup untuk kemungkinan membangun Grafik Ketergantungan Statis untuk fase PEI.

Membangun Grafik Ketergantungan Statis untuk Fase PEI


Deskripsi solusi untuk masalah pembongkaran lengkap modul yang dapat dieksekusi pada fase PEI dan dekompilasi perintah Panggilan Tidak Langsung yang ada dalam modul ini berada di luar ruang lingkup narasi kami dan tidak akan diberikan di dalamnya - penyajian materi ini dalam volume dapat melebihi ukuran karya ini.

Ada kemungkinan bahwa seiring waktu ini akan terjadi sebagai bahan yang terpisah, tetapi untuk sekarang - tahu caranya.

Kami hanya mencatat bahwa penggunaan Metadata, ditambah keberadaan struktur tertentu untuk membangun kode biner, memungkinkan dalam praktiknya untuk sepenuhnya membongkar modul BIOS / UEFI yang dapat dieksekusi. Bukti formal dari fakta ini tidak seharusnya sekarang atau di masa depan. Setidaknya dalam analisis / pemrosesan lebih dari seratus (100) BIOS / UEFI dari berbagai produsen, tidak ada contoh di mana pembongkaran total tidak dimungkinkan.

Lebih lanjut, hanya hasil spesifik (dengan penjelasan: apa, bagaimana dan berapa banyak ...).

Struktur EFI_PEI_SERVICES adalah struktur dasar fase PEI, yang dilewatkan sebagai parameter ke titik masuk setiap modul PEI dan berisi tautan ke layanan dasar yang diperlukan agar modul PEI berfungsi.

Kami hanya akan tertarik pada bidang yang terletak di bagian paling awal struktur:



Sebuah fragmen dari struktur nyata dari tipe EFI_PEI_SERVICES dalam disassembler IDA Pro.

Dan beginilah tampilannya dalam kode sumber dalam bahasa "C" (ingat, ini hanya sebagian dari struktur):

 struct EFI_PEI_SERVICES { EFI_TABLE_HEADER Hdr; EFI_PEI_INSTALL_PPI InstallPpi; EFI_PEI_REINSTALL_PPI ReInstallPpi; EFI_PEI_LOCATE_PPI LocatePpi; EFI_PEI_NOTIFY_PPI NotifyPpi; //...      ... };

Di awal struktur EFI_PEI_SERVICES, seperti dalam semua tabel Layanan "dasar", ada struktur EFI_TABLE_HEADER. Nilai-nilai yang disajikan dalam struktur tajuk ini memungkinkan kami untuk menyatakan dengan tegas bahwa jika struktur EFI_PEI_SERVICES sendiri benar-benar hadir pada fragmen dari disassembler (lihat bidang "Hdr.Signature"), maka setidaknya templat struktur ini!

 struct EFI_TABLE_HEADER { UINT64 Signature; UINT32 Revision; UINT32 HeaderSize; UINT32 CRC32; UINT32 Reserved; };

Sepanjang jalan, kita dapat menetapkan bahwa firmware sedang dikembangkan pada saat versi spesifikasi UEFI PI adalah 1.2, periode relevansinya adalah dari 2009 hingga 2013, tetapi pada saat ini (awal 2019), versi spesifikasi saat ini telah tumbuh (secara harfiah tumbuh beberapa hari yang lalu) ke versi 1.7.

Dari bidang "Hdr.HeaderSize" dapat ditentukan bahwa total panjang struktur adalah 78 jam (dan ini bukan panjang header, seperti namanya, tetapi panjang seluruh struktur EFI_PEI_SERVICES).

Antarmuka EFI_PEI_SERVICES dibagi menjadi 7 kategori / kelas. Kami hanya daftar mereka:

  1. Layanan PPI.
  2. Layanan Mode Booting.
  3. Layanan HOB.
  4. Layanan Volume Firmware.
  5. Layanan Memori PEI.
  6. Layanan Kode Status.
  7. Setel Ulang Layanan.

Semua narasi lebih lanjut akan terkait langsung dengan prosedur yang termasuk dalam kategori / kelas Layanan PPI, yang dimaksudkan untuk organisasi interaksi antar modul dari modul yang dapat dieksekusi fase PEI.

Dan hanya ada empat untuk fase PEI.

Secara umum, tidak perlu menebak tujuan dari masing-masing antarmuka: fungsionalitas sepenuhnya ditentukan oleh nama antarmuka, semua detail ada dalam spesifikasi .

Berikut ini adalah prototipe dari prosedur ini:

 typedef EFI_STATUS (__cdecl *EFI_PEI_INSTALL_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_PPI_DESCRIPTOR *PpiList); typedef EFI_STATUS (__cdecl *EFI_PEI_REINSTALL_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_PPI_DESCRIPTOR *OldPpi, const EFI_PEI_PPI_DESCRIPTOR *NewPpi); typedef EFI_STATUS (__cdecl *EFI_PEI_LOCATE_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_GUID *Guid, UINTN Instance, EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, void **Ppi); typedef EFI_STATUS (__cdecl *EFI_PEI_NOTIFY_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_NOTIFY_DESCRIPTOR *NotifyList);

Kami hanya mencatat bahwa selain perintah "Panggilan Tidak Langsung" yang memanggil prosedur / antarmuka kelas "Layanan PPI", panggilan eksplisit (langsung - bukan tabular) ke prosedur ini dimungkinkan, yang kadang-kadang terjadi dalam modul eksekutif, di mana struktur EFI_PEI_SERVICES didefinisikan / dibuat.

Saya akan memberi tahu Anda satu rahasia kecil: cukup aneh, meskipun ini adalah tabel "dasar" layanan untuk fase PEI, namun, seperti yang ditunjukkan oleh praktik, ini dapat didefinisikan tidak hanya dalam modul PEI_CORE.

Sebenarnya, ada perangkat tegar di mana struktur EFI_PEI_SERVICES didefinisikan / dibentuk dan digunakan dalam beberapa modul, dan ini sama sekali bukan salinan modul PEI_CORE.

Dengan demikian, opsi kode berikut dimungkinkan:

 seg000:00785F0D B8 8C A6 78+ mov eax, offset ppiList_78A68C seg000:00785F12 50 push eax ; PpiList seg000:00785F13 57 push edi ; PeiServices seg000:00785F14 89 86 40 0E+ mov [esi+0E40h], eax seg000:00785F1A E8 70 FC FF+ call InstallPpi

Contoh panggilan eksplisit ke prosedur "InstallPpi".

 seg000:00787CBB 8B 4D FC mov ecx, [ebp+PeiServices] seg000:00787CBE 50 push eax ; PpiList seg000:00787CBF C7 00 10 00+ mov dword ptr [eax], 80000010h seg000:00787CC5 C7 43 3C A8+ mov dword ptr [ebx+3Ch], offset guid_78A9A8 seg000:00787CCC 8B 11 mov edx, [ecx] seg000:00787CCE 51 push ecx ; PeiServices seg000:00787CCF FF 52 18 call [edx+EFI_PEI_SERVICES.InstallPpi]

Contoh panggilan implisit ke antarmuka InstallPpi.

 FF 51 18 call dword ptr [ecx+18h] FF 51 18 call [ex+EFI_PEI_SERVICES.InstallPpi] FF 51 1 call dword ptr [ecx+1Ch] FF 51 1C call [ex+EFI_PEI_SERVICES.ReInstallPpi] FF 51 20 call dword ptr [ecx+20h] FF 51 20 call [ex+EFI_PEI_SERVICES.LocatePpi] FF 51 24 call dword ptr [ecx+24h] FF 51 24 call [ex+EFI_PEI_SERVICES.NotifyPpi]
Contoh panggilan antarmuka implisit sebelum dan sesudah otentikasi.

Kami mencatat satu fitur karakteristik: dalam hal fase PEI untuk arsitektur IA-32, antarmuka kelas Layanan PPI memiliki offset 18 jam, 1 jam, 20 jam, dan 24 jam.

Dan sekarang kita nyatakan pernyataan berikut:
Untuk membangun Grafik Ketergantungan Statis dari fase PEI, perlu dan cukup untuk membongkar sepenuhnya semua modul yang dapat dieksekusi dari fase (setidaknya memisahkan semua perintah), dan mendekompilasi perintah “Panggilan Tidak Langsung” dengan offset 18h, 1Ch, 20h, 24h dalam modul yang dibongkar.
Faktanya, kami telah sepenuhnya merumuskan algoritma untuk menyelesaikan masalah, dan segera setelah kami berhasil mengisolasi semua panggilan ke antarmuka / prosedur kelas Layanan PPI, tetap hanya untuk menentukan parameter mana yang diteruskan ke panggilan ini. Tugasnya mungkin bukan yang paling sepele, tetapi, seperti yang telah ditunjukkan oleh praktik, itu sepenuhnya bisa dipecahkan, kami memiliki semua data untuk ini.

Dan sekarang contoh nyata dari data nyata untuk modul fase PEI nyata. Kami tidak secara sengaja menunjukkan hasil BIOS / UEFI perusahaan mana yang diperoleh, cukup berikan contoh penampilannya.

Dua contoh deskripsi modul PEIM dengan informasi lengkap tentang penggunaan antarmuka Layanan PPI dalam modul-modul ini


  -- File 04-047/0x02F/: "TcgPlatformSetupPeiPolicy" : [007CCAF0 - 007CD144] DEPENDENCY_START EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI DEPENDENCY_END Install Protocols: [1] TCG_PLATFORM_SETUP_PEI_POLICY Locate Protocols: [2] EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI 
 -- File 04-048/0x030/: "TcgPei" : [007CD160 - 007CF5DE] DEPENDENCY_START EFI_PEI_MASTER_BOOT_MODE_PEIM_PPI EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI AND DEPENDENCY_END Install Protocols: [1] AMI_TCG_PLATFORM_PPI [2] EFI_PEI_TCG_PPI [2] PEI_TPM_PPI Locate Protocols: [1] EFI_PEI_TCG_PPI [1] EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI [1] TCG_PLATFORM_SETUP_PEI_POLICY [5] PEI_TPM_PPI Notify Events: [1] AMI_TCM_CALLBACK ReInstall Protocols: [1] PEI_TPM_PPI

Daftar protokol berdasarkan jenis antarmuka di mana mereka digunakan


Di bawah di bawah spoiler adalah contoh singkat daftar protokol PPIM untuk masing-masing antarmuka kelas Layanan PPI.

Format daftar adalah sebagai berikut:
 |  nomor seri |  name_PPI |  guid_PPI |  executable_name: username |

***** Instal 99 Ppi di "Firmware"


***** Temukan 194 Ppi di "Firmware"


***** Pasang kembali 5 Ppi di "Firmware"


***** Beri tahu 29 Ppi dalam "Firmware"


Daftar akhir semua panduan protokol yang direferensikan dalam BIOS / UEFI tertentu dengan legenda yang menunjukkan di mana "Layanan PPI" protokol ini ditemukan


Di bawah ini adalah daftar spoiler dari 97 PPi-guids yang ditemukan dan secara eksplisit digunakan dalam firmware tertentu, data yang diberikan sebelumnya.

Setiap item dari daftar didahului oleh legenda, yang mencerminkan semua jenis penggunaan protokol tertentu.

 "D" - in DEPENDENCY section used "I" - in "InstallPpi" functions used "L" - in "LocatePpi" functions used "R" - in "ReInstallPpi" functions used "N" - in "NotifyPpi" functions used

***** Daftar Ppi di "Firmware"




Interval daftar protokol berikut ini patut diperhatikan dalam BIOS / UEFI ini:

  1. No. 38-50.
    Menentukan protokol / acara (InstallPpi) yang tidak digunakan oleh modul apa pun.
  2. No. 87-95.
    Coba minta protokol yang tidak diinstal oleh modul apa pun dari firmware ini.
  3. No. 96-97.
    Dua acara "Beritahu", yang masing-masing modul tidak repot-repot mendeklarasikan antarmuka yang sesuai, meskipun prosedur ini dinyatakan dalam modul yang dapat dieksekusi, mereka tidak akan pernah berfungsi.

Kesimpulan


  • Hasil yang mirip dengan yang di atas diperoleh untuk BIOS / UEFI dari berbagai produsen, itulah sebabnya semua contoh anonim.
  • Bahkan, tugas yang lebih umum untuk membalikkan algoritma modul BIOS / UEFI yang dapat dieksekusi diselesaikan, dan grafik yang dihasilkan adalah hasil sampingan, semacam bonus tambahan.
  • Solusi yang benar dari tugas "Memperoleh Grafik Ketergantungan Statis" untuk modul BIOS / UEFI yang dapat dieksekusi memerlukan analisis statis kode biner, yang mencakup pembongkaran lengkap dari modul yang dapat dieksekusi dan dekompilasi sebagian dari perintah Panggilan Tidak Langsung dari modul-modul ini.

Source: https://habr.com/ru/post/id440052/

More articles:


All Articles