Dalam tulisan ini saya akan membahas UEFI (Unified Extensible Firmware Interface) dari mulai dasarnya, securitynya, dan sekilas cara reverse engineeringnya, dan hal-hal apa yang perlu diperhatikan ketika berurusan dengan UEFI (misalnya ketika melakuan cloning komputer).
Meskipun tulisan ini cukup panjang, tapi ini hanya perkenalan saja. Ada banyak topik yang tidak saya bahas. Ada beberapa topik yang penjelasannya saya sederhanakan sehingga mungkin kurang akurat. Silakan baca berbagai website yang saya link dari artikel ini jika ingin mendapatkan penjelasan lebih dalam. Jika ingin belajar langsung dari sumbernya, spesifikasi UEFI dan source code dari Intel bisa dibaca.
Secara awam UEFI adalah pengganti BIOS (Basic Input Output System). BIOS sendiri adalah software yang sudah tertanam di komputer yang menyediakan akses dasar ke hardware. Sebagai informasi: BIOS hanya ada di arsitektur x86, sedangkan di arsitektur lain, fungsi BIOS ini digantikan oleh software lain. Software low level yang menempel ke hardware ini disebut juga sebagai firmware.
Ketika sebuah komputer dinyalakan, perlu ada firmware yang bisa meload sistem operasi dari suatu media, entah itu dari disk (macam-macam, bisa flash disk, micro sd, harddisk, SSD, NVME, dsb) dari network, atau mungkin dari sumber lain. Di dunia PC, firmware ini dulunya adalah BIOS, tapi sudah belasan tahun ini digantikan oleh UEFI.
Contents
Sedikit Sejarah
BIOS untuk x86 usianya sudah sangat tua (dari jaman PC XT), dan memiliki banyak keterbatasan (misalnya hanya bisa berjalan di mode 16 bit). Jadi untuk sistem operasi 32 atau 64 bit, boot loader atau sistem operasi perlu beralih mode dari 16 ke 32/64 bit setelah diload oleh BIOS.
Saya dulu pernah membuat sendiri OS sederhana dari nol, dan proses bootnya cukup panjang: mengimplementasikan kode MBR (yang otomatis diload oleh BIOS, ukurannya maksimal 512 byte), yang akan meload boot loader (memanggil fungsi/interrupt BIOS untuk mengakses disk), lalu boot loadernya meload kernel, switch ke mode 32 bit, lalu baru melakukan jump ke mode 32 bit. Detail proses booting klasik bisa dibaca di sini.
Ketika Intel membuat prosessor Itanium, mereka menyadari berbagai keterbatasan BIOS ini dan mulai membuat spesifikasi baru yang bernama UEFI. UEFI sendiri sebenarnya hanyalah sebuah spesifikasi, jadi terserah masing-masing pembuat firmware UEFI bagaimana mengimplementasikannya. Saat ini UEFI tidak terbatas untuk arsitektur x86 saja, tapi bisa untuk berbagai arsitektur (ARM, RISCV, dan arsitektur Loongson dari China).
Agar tidak semua orang berusaha membuat implementasi UEFI dari nol, Intel membuat implementasi UEFI dan dirilis open source. Implementasi ini bernama Tiano, lalu digantikan dengan EDK, lalu EDK2. Berdasarkan pada source code EDK2, Microsoft membuat implementasi yang dipakai di hardware Microsoft Surface (termasuk versi ARM), dengan nama Mu.
Secara praktis, berbagai pembuat firmware UEFI ini dulunya adalah pembuat firmware BIOS, jadi nama-nama seperti AMI atau Phoenix masih akan sering kita lihat). Seperti yang dilakukan Microsoft, kode dasar semua firmware ini berdasarkan pada kode dari Intel.
Hampir semua firmware UEFI saat ini juga masih memberikan mode kompatibilitas BIOS, jadi kode BIOS lama juga masih ada di firmware. Berbagai pembuat motherboard juga masih menyebut update firmware UEFI ini sebagai “Update BIOS” atau “file BIOS”. Supaya tidak membingungkan, di tulisan ini ketika saya menyebut BIOS, artinya itu sistem yang lama, dan UEFI adalah penggantinya yang modern.
Firmware UEFI dan Aplikasi UEFI
Firmware UEFI terdiri dari banyak komponen, mirip sebuah sistem operasi, ada banyak driver, dan juga aplikasi ekstra (misalnya aplikasi diagnostik motherboard atau laptop). Driver dan aplikasi ini dijadikan satu menjadi firmware UEFI. Di bagian reverse engineering UEFI, akan saya bahas sedikit bagaima membongkar firmware ini menjadi komponen-komponennya.
Sekarang jika kita ingin membuat OS sederhana 32/64 bit, caranya lebih mudah, kita cukup membuat aplikasi UEFI, lalu ditaruh di direktori tertentu, dan akan diload oleh firmware UEFI. Di laptop/desktop modern (sekitar 5-10 tahun terakhir) sudah memakai UEFI versi 64 bit, sehinga langsung masuk ke mode 64 bit. Aplikasi UEFI bisa memanggil fungsi-fungsi yang disediakan firmware (dulunya hal semacam ini dilakukan memakai Interrupt 13h). Jadi Aplikasi UEFI ini bisa berjalan tanpa sistem operasi.
Selain aplikasi, kita juga bisa membuat driver UEFI yang bisa diload oleh firmware UEFI. Driver ini bisa berupa driver untuk mengakses hardware tertentu, atau bisa juga untuk menambah fungsionalitas. Misalnya ada driver filesystem agar EFI bisa mengakses HFS, EXT2 dan filesystem lain.
Aplikasi dan driver UEFI ini bentuknya adalah sebuah file executable, dengan ektensi EFI, dan memakai format PE (Portable Executable, seperti file EXE Windows). Di header file PE bisa dicantumkan untuk subsytem apa file tersebut, jadi EXE Windows tidak jalan di EFI dan sebaliknya, meskipun sama-sama format PE. Untuk aplikasi UEFI, jenis subsystemnya adalah EFI_Application.
Beberapa aplikasi UEFI disertakan di source code EDK2 (misalnya UEFI shell). UEFI shell ini adalah sebuah aplikasi command line yang bisa dipakai untuk memeriksa hardware komputer, melihat file, dan meload aplikasi UEFI lain.
Aplikasi EFI yang banyak dikenal orang adalah bootloader UEFI, misalnya Grub yang dipakai di berbagai distro Linux, bootloader milik Microsoft yang dipakai di Windows, serta Clover dan Chameleon yang dipakai oleh komunitas Hackintosh.
Tapi Aplikasi UEFI tidak hanya bootloader saja atau shell saja, banyak yang sudah membuat game dalam UEFI, misalnya Flappy Bird, Tetris, Pong, dsb. Selain game, ada juga yang mengimplementasikan interpreter Basic dan Lua untuk UEFI.
Ketika komputer Intel 64 bit melakukan booting, file yang dicari oleh firmware adalah bootx64.efi pada direktori EFI\boot\pada partisi yang ditentukan oleh firmware (informasi ini diambil dari variabel UEFI). Untuk arsitektur lain, filenya bisa dilihat pada tabel di spesifikasi UEFI.
Jadi nanti ketika membuat profram UEFI, kita bisa membuat file dengan nama yang sesuai tabel di atas, di lokasi yang sesuai di media penyimpanan (bisa di USB, sd card, dsb). Anda bisa juga membuat disk image dan memakai VM untuk bereksperimen dengan UEFI.
Variable UEFI
Dulu setting BIOS masih sangat sedikit, dan bisa masuk ke RAM berbasis CMOS, yang kapasitasnya kecil dan butuh batere. Sekarang ini firmware UEFI biasanya menyimpan setting di NVRAM yang tidak butuh lagi batere CMOS, walau di banyak motherboard, batere ini tetap diperlukan dan jika dicabut akan mereset isi NVRAM.
Variabel di RAM CMOS dulu biasanya hanya dipakai oleh BIOS saja, dan spesifik ke vendor tertentu. Sekarang firmware UEFI menyediakan akses ke penyimpanan variabel dan tiap variabel diberi nama. Sebagian variabel ini terdokumentasi dengan jelas, dan sebagian tetap spesifik.
Beberapa variabel hanya bisa diubah di mode SMM (ini akan dibahas di bagian lain artikel ini), dan sebagian bebas diubah. Contoh variabel yang bisa diubah adalah “Boot Order” alias urutan booting ketika komputer dinyalakan, apakah akan boot ke USB disk dulu atau langsung ke harddisk, atau bahkan mungkin ke jaringan.
Di Windows kita bisa menggunakan PowerShell dengan modul UEFI2 untuk melihat dan mengubah isi variabel UEFI. Untuk menginstall modulnya, di PowerShell (sebagai admin), ketik Install-Module UEFIv2. Untuk mendapatkan daftar variabel gunakan Get-UEFIVariable -All
Perhatikan bahwa ada namespace pada variable, jadi bisa saja ada variabel bernama Setup di dua namespace yang berbeda. Namespace standard adalah 8be4df61-93ca-11d2-aa0d-00e098032b8c, yaitu UEFI_GLOBAL_VARIABLE.
Beberapa variabel isinya adalah byte array, dan perlu diparse khusus. Contohnya BootOrder isinya adalah byte array seperti ini:
Modul UEFI sudah punya fungsi khusus untuk melakukan parsing informasi tersebut dengan melihat variabel lain. Isi modul ini bisa dipelajari dari source codenya.
Bagaimana dengan Linux? semua di Linux direpresentasikan sebagai file. Dalam kasus EFI, ini ada di /sys/firmware/efi/efivars. Daftar variabelnya bisa dilihat dengan ls dan isinya bisa dilihat dengan cat (atau sering kali hexdump lebih berguna). Jika Anda tidak menemukan direktori ini, kemungkinan Linux diboot dengan mode legacy BIOS dan bukan UEFI.
Hal yang perlu diperhatikan adalah bahwa 4 byte pertama isi “file” variabel adalah attribut UEFI.
Attribut ini ada di spesifikasi UEFI, misalnya ada variabel yang hanya bisa diakses sebelum masuk ke OS (sebelum ExitBootServices() dipanggil), ada variabel yang read only, dsb. Penjelasan mengenai ini bisa dibaca di dokumentasi EDK2.
Program UEFI Hello World
Ada banyak cara untuk membuat program UEFI, misalnya dengan menggunakan EDK2, menggunakan Rust, menggunakan .NET (menggunakan Aheaf Of Time Compilation/AOT) dan masih banyak lagi. Dengan memahami program Hello World, maka kita akan lebih mudah melakukan reverse engineering dan eksploitasi UEFI. Tentunya akan lebih baik jika setelah memprogram Hello World, kita juga mencoba berbagai API lain.
Saya sendiri suka menggunakan GNU EFI yang lebih lightweight dari EDK2, karena hanya berupa header saja. Untuk compilernya, saya memilih clang, yang bisa membuat file PE dengan subsystem efi_application.
Program sederhana seperti ini:
#include <efi.h>
#include <efilib.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {
gSystemTable = SystemTable;
SystemTable->ConOut->OutputString(SystemTable->ConOut, L"Hello, world!\n");
//while (1); //untuk Qemu, jika ingin output tetap terlihat
return 0;
}
Jika kita punya banyak file, masing-masing file bisa dicompile seperti ini:
clang -Iinc -Ignu-efi/inc/ -target x86_64-unknown-windows -ffreestanding -fshort-wchar -mno-red-zone -c namafile.c
Dan untuk melink hasil akhirnya:
clang -target x86_64-unknown-windows -nostdlib -Wl,-entry:efi_main -Wl,-subsystem:efi_application -fuse-ld=lld-link file1.o file2.o -o main.efi
Ketika sebuah program EFI dimulai, kita diberi pointer ke sebuah struktur bernama EFI_SYSTEM_TABLE, dalam struktur ini ada banyak field, misalnya RuntimeServices dan BootServices yang berisi pointer ke berbagai fungsi yang bisa kita panggil. Selain itu ada juga ConIn dan ConOut untuk melakukan input/output.
Jika kita memakai Qemu, ketika program exit, maka akan kembali ke menu UEFI lagi, jadi jika ingin output tetap ada di layar, bisa ditambahkan infinite loop.
Secure Boot
Sebelum mulai menjalankan Hello World, kita perlu paham dulu apa itu secure boot, dan kenapa ini perlu dimatikan untuk bisa menjalankan aplikasi Hello World. Selain itu akan saya jelaskan konsekuensinya jika secure boot diaktifkan atau dinon aktifkan.
Sebelum ada spesifikasi Secure Boot, mudah sekali bagi attacker untuk mengganti file efi (misalnya bootloader) dengan file baru atau file hasil modifikasi dari yang sudah ada. Karena aplikasi EFI ini akan dieksekusi sebelum OS dijalankan, maka bisa melakukan apa saja sebelum OS-nya dimulai, misalnya membuat file baru, memodifikasi file lama, mendisable antivirus (dengan mengubah file konfigurasi), dsb.
Dengan secure boot, setiap langkah boot akan divalidasi dengan digital signature. Secara default, hampir semua firmware UEFI memiliki root certificate dari Microsoft dan dari Vendor pembuat motherboard/laptop. Agar sebuah bootloader atau aplikasi UEFI bisa dijalankan dalam mode secure, filenya harus ditandatangani secara digital.
Dalam mode secure, kita tidak bisa menaruh sembarang file EFI untuk dieksekusi, karena tidak ditandatangani oleh Microsoft. Microsoft tentunya tidak akan menandatangani sembarang file, hanya yang dianggap aman saja, dan biayanya juga tidak murah.
Jika semua ditandatangani secara digital, artinya proses booting sudah (dianggap) aman. Proses lebih detailnya bisa dibaca di dokumen Microsoft. Di sini letak kelemahan Secure Boot UEFI: berbagai aplikasi UEFI yang ditandangani Microsoft atau Vendor bisa ada bugnya. Jika bug ini ditemukan, maka filenya akan diblacklist (masuk dalam revocation list).
Revocation List dan Firmware Update
Blacklist dilakukan dengan variabel bernama dbx dalam namespace {d719b2cb-3d3a-4596-a3bc-dad00e67656f} (namespace untuk security UEFI). Variabel ini mulai Windows 10 akan diupdate otomatis oleh Windows. Untuk Linux, kita perlu menjalankan fwupd untuk mengupdate boot revocation.
Dengan script dari sini, kita bisa melakukan dump hash yang saat ini diblacklist.
Daftar blacklist/revocation list terbaru bisa diunduh dari sini. Dengan membandingkan file terbaru dengan yang tercantum di variable dbx kita bisa mengetahui aplikasi/bootloader UEFI mana yang masih bisa dimanfaatkan untuk menembus sistem.
Perhatikan bahwa Secure Boot merupakan salah satu syarat agar enkripsi bitlocker dilakukan otomatis (untuk OEM/pembuat hardware). Dengan mematikan secure boot, maka proses enkripsi otomatis ini tidak dilakukan. Drive yang dienkrip dengan Bitlocker juga perlu penanganan khusus jika dipakai di komputer baru.
Bagaimana dengan Linux? Redhat membuat loader kecil (shim) yang ditandatangani secara digital oleh Microsoft. Loader ini defaultnya hanya akan meload file yang ditandatangani Redhat. Tapi diberikan juga kebebasan bagi user untuk menambah key baru (key enrollment), tapi harus dilakukan secara manual, kita harus menekan beberapa tombol untuk konfirmasi di boot loader. Jadi attacker remote tidak bisa dengan mudah menambahkan key secara otomatis.
Tapi kelemahan kadang bukan hanya di aplikasi/bootloader yang diload oleh firmware UEFI, kadang kelemahannya ada di firmware itu sendiri. Contohnya kelemahan parsing variabel UEFI. Untuk mempermudah update firmware UEFI, sudah ada standard UEFI Capsules. Windows 10 sudah mendukung capsule ini, jadi update firmware UEFI sudah bisa dilakukan bersama dengan update Windows. Di Linux, hal yang sama bisa dilakukan dengan fwupd.
Menjalankan Hello World
Untuk development, kita bisa menggunakan software virtual machine untuk menjalankan file efinya. Dengan ini kita tidak perlu mempedulikan masalah secure boot.
Untuk menjalankan di QEMU, install qemu, dan download firmware, misalnya OVMF.fd dari sini. Letakkan file efi di dalam direktori test/efi/boot/boox64.efi, lalu jalankan Qemu:
qemu-system-x86_64 -bios ./OVMF.fd -net none -hda fat:rw:test
Dan jika kita ingin menjalankan di hardaware beneran, cara termudah adalah dengan menyalin file EFI ini ke USB, lalu boot langsung komputer. Set agar startup disk menunjuk ke USB disk. Jangan lupa: jika secure boot aktif, maka perlu dinon-aktifkan. Alternatif lain adalah perlu menggunakan bootloader dari Redhat dan melakukan key enrolment (prosesnya agak rumit).
Membongkar Firmware dan Program UEFI
Program EFI bisa dibongkar dengan berbagai disassember/decompiler standard. UEFI ini banyak memakai pointer, jadi sebaiknya gunakan modul tambahan untuk mempermudah reverse engineering, IDA versi Pro sudah memiliki database struktur EFI, Ada ghidra-firmware-utils untuk Ghidra, dan ada radare2-uefi untuk radare2.
Perhatikan, tanpa mengetahui tipe data yang dipakai di UEFI, tidak jelas call rax itu memanggil apa. Dengan database yang lengkap, bisa didapatkan bahwa RAX berisi pointer ke OutputString pada struct CounOut di SystemTable.
Untuk file EFI hasil kompilasi sendiri, file bisa langsung dibongkar, tapi untuk firmware UEFI, kita butuh langkah ekstra. Firmware UEFI disusun dari banyak module UEFI, masing-masing bentuknya adalah file PE. Jadi jika kita bisa mengekstrak modulnya, maka kita bisa membongkarnya seperti program UEFI biasa.
Program yang bisa dipakai adalah UEFITool. Program ini ada mode GUI-nya dan ada juga mode teksnya.
Hal yang bisa membantu RE adalah source code, baik itu source code terbaru, maupun source code lama (asalkan kodenya masih serupa). Saat ini banyak implementasi UEFI didasarkan pada EDK2, jadi kita bisa membandingkan kode yang kita reverse dengan kode di EDK2. Banyak nama modul yang ditemukan akan sama dengan yang di EDK2.
Beberapa vendor source codenya sudah bocor di Internet (walau bukan yang terbaru), ini juga bisa membantu kita melakukan reverse engineering versi terbaru. Contohnya: Acer saya memakai firmware UEFI dari Insyde, dan sudah ada source code versi sebelumnya yang bocor di Github.
EFI Shell dan Code Execution
Jika kita bisa mendapatkan akses ke EFI Shell, apa yang bisa kita lakukan untuk eksploitasinya?. Biasanya setelah mendapatkan EFI Shell, kita tetap tidak bisa meload sembarang EFI karena signaturenya akan dicek. Beberapa yang bisa dilakukan: Mengganti isi variabel UEFI, menjalankan shell code, patching agar EFI loading bisa dilakukan (mengabaikan bagian pemeriksaan signature), atau patching ACPI table.
Biasanya langkah pertama dalam eksploitasi UEFI adalah mencari bootloader yang memiliki akses shell dan belum diblacklist di komputer tersebut. Jika tidak ketemu yang bentuknya shell, terpaksa harus melakukan mencari bug di aplikasi yang mungkin perlu melibatkan eksploitasi binary.
Contoh BootLoader yang belum diblacklist di Acer Aspire 3 yang saya miliki adalah utility SeaChest dari Seagate. Utility ini bisa dijalankan dari USB/CDROM untuk mendiagnosa disk Seagate dan mengupdate firmware. Ada banyak utility sejenis dari vendor lain. Defaultnya aplikasi ini akan meload aplikasi EFI Seagate saja, tapi ketika refind.conf diedit, kita bisa memulai EFI shell yang disertakan oleh Seagate dan ditandatangi digital.
Untuk memahami perintah UEFI shell, kita bisa menggunakan help untuk melihat daftar command, dan menggunakan help namacommand untuk melihat detail setiap command. Tombol Page up dan Page Down dapat digunakan untuk scrolling layar. Jika masih kurang jelas, source code shell juga bisa dibaca (biasanya semuanya berdasarkan shell di EDK atau EDK2.
Variabel EFI bisa dimanipulasi dengan command dmpstore. Kita bisa melihat, menyimpan variabel ke file dan meload dari file. Isi memori secara umum bisa dibaca dan dipatch dengan perintah mm.
Saat ini kebanyakan firmware UEFI tidak mengimplementasikan ASLR (Address Space Layout Randomization), dan kebanyakan tabel berada di lokasi yang sifatnya fixed, jadi eksplotasi bisa dilakukan dengan menulis ke memori tersebut. Untuk melihat di mana lokasi berbagai tabel (seperti Runtime Services, Boot Services, dsb), kita bisa menggunakan command mem.
Dari tabel di atas, kita bisa men-dump tabel, misalnya tabel Runtime Services bisa didump dengan mem dd272e18. Alamat tentunya ini akan beda di UEFI yang berbeda, tapi karena tanpa ASLR akan tetap sama meskipun sudah kita restart.
Perintah mm bisa kita gunakan untuk menulis ke area memori mana saja (asalkan protection-nya memang bisa ditulisi). Jika kita menuliskan kode di suatu lokasi memori, lalu mem-patch tabel Runtime Services pada fungsi GetVariable, maka ketika kita melakukan dmpstore, fungsi kita yang akan dipanggil. Berbagai perintah patching memory ini bisa dimasukkan ke script startup.nsh.
Patching Windows Platform Binary Table (WPBT) pada ACPI juga bisa dilakukan sebagai salah satu bentuk eksploit. WPBT berisi pointer ke executable di memori yang akan otomatis dieksekusi Windows 8 ke atas ketika booting. Executable yang ada harus sudah ditandatangi secara digital, jadi tidak bisa sembarangan file kita letakkan. Penjelasan lebih lanjut mengenai WPBT dan eksploitasi tabel lain bisa dilihat di presentasi ini.
Hacking System Management Mode
System Management Mode (SMM) merupakan mode eksekusi khusus (ring -2), dalam mode ini semua eksekusi sistem operasi dihentikan, dan kode dalam range memori khusus akan dieksekusi. Biasanya kode yang dieksekusi ini diload dari firmware.
SMM ini dipakai untuk banyak hal: power management, akses ke TPM (Trusted Platform Module), dsb. Karena sistem operasi tidak bisa mematikan atau mengoverride SMM, ini bisa dipakai untuk menyembunyikan rootkit. Kita juga dapat mengubah berbagai macam variabel UEFI yang tidak dapat diubah di mode biasa.
Eksploitasi untuk mendapatkan akses SMM ini tidak semudah eksploitasi di OS biasa. Di berbagai OS ada banyak tool dan pendekatan dasar yang bisa kita pakai untuk menaikkan privilege, sedangkan untuk UEFI harus coding sendiri sesuai versi target firmware UEFI.
Untuk topik SMM, saya tidak akan membahas di sini, karena topiknya sangat panjang, dan sudah ada seri tulisan yang sangat bagus di sini. Selain itu saya sendiri juga masih memiliki pengalaman SMM yang terbatas.
Kenapa ngoprek UEFI?
Banyak topik saya oprek karena asalnya dari iseng, atau karena satu topik yang melebar ke mana-mana. Alasan saya ngoprek UEFI dimulai dari sebuah hal kecil: masalah setting default laptop.
Laptop Acer Aspire 3 yang digunakan dalam lomba IOI (International Olympiad in Informatics) memiliki default yang aneh: tombol Fn harus ditekan untuk menekan tombol F1-F12. Jika tidak menekan FN, maka defaultnya adalah menjadi “media key”.
Masalahnya lagi, tombol F1 adalah sleep, jadi jika ingin menekan ESC di Vim, tapi tangan kita meleset, maka komputer bisa sleep. Khusus untuk masalah sleep, ini bisa didisable di level OS, tapi tombol yang lain juga cukup mengganggu. Debugging di hampir semua IDE memakai tombol F8/F10/F11/F12, akan sangat tidak nyaman jika harus menahan Fn tiap kali menekan tombol tersebut.
Setting tombol Fn ini bisa diganti di Firmware UEFI secara manual, tapi bagaimana jika ingin melakukan ini di 300 laptop untuk kompetisi IOI? Andaikan kami tahu bahwa default setting ini defaultnya adalah Media Key, maka bisa diminta agar diset dari awal seperti itu sebelum laptop dikirimkan, tapi baru diketahui setelah laptopnya datang.
Setting ini tidak bisa dilakukan di level sistem operasi. Saya sudah mencoba mengedit variabel EFI, tapi ternyata gagal. Di versi yang lama, Insyde H2O (nama firmwarenya) mudah sekali dioprek, kita cukup mengganti setting dengan mengedit variabel EFI. Banyak orang mengaktifkan fitur-fitur tersembunyi, sehinggadi versi yang baru, ini sudah diproteksi sangat baik (dengan SMM).
Pada akhirnya saya gagal mengeksploitasi SMM untuk mengganti setting ini, tapi sudah terlanjur mengoprek cukup dalam, jadi pengalamannya saya tuliskan di sini. Jadi bagaimana solusi untuk masalah saya? akhirnya saya memakai solusi yang lebih sederhana dengan Pico yang berfungsi jadi USB “Rubber Ducky”. Ini akan saya bahas di tulisan lain.
Kebanyakan programmer mungkin tidak akan pernah menyentuh UEFI dan memang tidak akan perlu. Tapi pemahaman ini bisa berguna untuk troubleshooting PC. Untuk yang ingin mendalami dunia security, ini juga merupakan topik yang menarik.