Clever Geek Handbook

Meretas ESP32 dengan Memotong Boot Aman dan Enkripsi Flash (CVE-2020-13629)

Kami telah melakukan studi terhadap mikrokontroler Espressif ESP32 untuk ketahanan terhadap serangan yang dilakukan dengan metode memperkenalkan kegagalan dalam pengoperasian chip (Fault Injection). Kami berangsur-angsur bergerak untuk menemukan kerentanan yang memungkinkan kami melewati mekanisme Secure Boot dan Enkripsi Flash hanya dengan satu kegagalan yang disebabkan oleh medan elektromagnetik. Selain itu, setelah berhasil melakukan serangan, kami tidak hanya dapat mengeksekusi kode arbitrer, tetapi juga menerima data memori flash yang telah didekripsi. Espressif telah melaporkan kerentanan ini di database CVE dengan kode CVE-2020-13629







... Saat Anda membaca serangan yang dijelaskan dalam artikel ini, perlu diingat bahwa ini berlaku untuk chip ESP32 revisi 0 dan 1. ESP32 V3 yang lebih baru mendukung fungsi menonaktifkan bootloader UART yang digunakan dalam serangan ini.



UART bootloader



Di ESP32, bootloader UART diimplementasikan dalam kode ROM. Hal ini memungkinkan, antara lain, untuk menulis program ke memori flash eksternal. Menerapkan bootloader UART sebagai kode yang disimpan dalam ROM adalah solusi umum. Ini cukup dapat diandalkan karena fakta bahwa kode tersebut tidak mudah rusak. Jika fungsi ini didasarkan pada kode yang disimpan dalam memori flash eksternal, maka kerusakan apa pun pada memori tersebut akan menyebabkan mikrokontroler tidak dapat beroperasi sepenuhnya.



Biasanya, akses ke fungsionalitas tersebut diatur ketika chip dimuat dalam mode khusus, dalam mode boot. Pilihan mode ini dilakukan dengan menggunakan jumper kontak (atau jumper), diatur sebelum perangkat di-boot ulang. ESP32 menggunakan pin untuk ini G0.



Bootloader UART mendukung banyak hal menarikinstruksi yang dapat digunakan untuk membaca / menulis memori dan register dan bahkan menjalankan program dari SRAM.



▍ Eksekusi kode arbitrer



UART loader mendukung pemuatan dan eksekusi kode arbitrer menggunakan perintah load_ram. ESP32 SDK menyertakan semua alat yang diperlukan untuk mengkompilasi kode yang dapat dijalankan dari SRAM. Misalnya, cuplikan kode berikut mengeluarkan string SRAM CODE\nke antarmuka serial. 



void __attribute__((noreturn)) call_start_cpu0()
{
    ets_printf("SRAM CODE\n");
    while (1);
}


Alat esptool.pyyang merupakan bagian dari ESP32 SDK dapat digunakan untuk memuat biner yang dikompilasi ke dalam SRAM. Kemudian file-file ini dapat dijalankan. 



esptool.py --chip esp32 --no-stub --port COM3 load_ram code.bin


Menariknya, bootloader UART tidak bisa dinonaktifkan. Oleh karena itu, selalu ada akses ke sana, bahkan jika boot aman dan enkripsi flash diaktifkan.



▍ Langkah-langkah keamanan tambahan



Jelas, kecuali tindakan keamanan tambahan dilakukan, ketersediaan bootloader UART yang konstan akan membuat mekanisme boot aman dan enkripsi memori flash menjadi tidak berguna. Oleh karena itu, Espressif telah menerapkan mekanisme keamanan tambahan yang berbasis teknologi eFuse.



Ini adalah bit yang digunakan untuk mengkonfigurasi parameter keamanan, yang disimpan dalam memori khusus yang sering disebut sebagai memori OTP (One-Time-Programmable Memory). Bit dalam memori seperti itu hanya dapat berubah dari 0 ke 1, tetapi tidak ke arah yang berlawanan. Ini memastikan bahwa jika sedikit mengaktifkan fitur telah diatur, itu tidak akan pernah dihapus lagi. Saat ESP32 beroperasi dalam mode bootloader UART, bit berikut dari memori OTP digunakan untuk menonaktifkan kemampuan tertentu:



  • DISABLE_DL_ENCRYPT: -.
  • DISABLE_DL_DECRYPT: -.
  • DISABLE_DL_CACHE: MMU- -.


Kami sangat tertarik dengan bit memori OTP DISABLE_DL_DECRYPT, karena bit memori ini menonaktifkan dekripsi transparan dari data yang disimpan dalam memori flash.



Jika bit ini tidak disetel, maka, saat memuat mikrokontroler menggunakan bootloader UART, Anda dapat mengatur akses sederhana ke data yang disimpan dalam memori flash, bekerja dengannya seperti pada teks biasa.



Jika bit ini disetel, maka dalam mode boot menggunakan bootloader UART, hanya data terenkripsi yang dapat dibaca dari memori. Fungsionalitas enkripsi flash, diimplementasikan sepenuhnya di perangkat keras dan transparan ke prosesor, hanya diaktifkan saat ESP32 melakukan booting dalam mode Normal.



Saat melakukan serangan yang kita bicarakan di sini, semua bit ini disetel ke 1.



Data SRAM tetap ada setelah perangkat melakukan boot ulang panas



SRAM yang digunakan oleh mikrokontroler ESP32 cukup umum. Hal yang sama digunakan oleh banyak chip. Biasanya digunakan bersama dengan ROM dan bertanggung jawab untuk memulai bootloader pertama dari memori flash. Memori semacam itu nyaman digunakan pada tahap awal pemuatan, karena tidak ada yang perlu dikonfigurasi sebelum menggunakannya.



Pengalaman dari penelitian sebelumnya memberi tahu kita bahwa data yang disimpan di SRAM tidak berubah sampai ditimpa, atau sampai tidak ada lagi listrik yang disuplai ke sel memori. Setelah reset dingin (yaitu, siklus hidup / mati) chip, konten SRAM akan diatur ulang ke status defaultnya. Setiap chip dari memori semacam itu dibedakan oleh status unik (bisa dikatakan, semi-acak) dari bit yang disetel ke nilai 0 dan 1.



Tetapi setelah hot reboot, ketika chip di-boot ulang tanpa mematikan daya, dapat terjadi data yang disimpan di SRAM tetap sama seperti sebelumnya. Ini ditunjukkan pada gambar berikut.





Dampak



booting ulang dingin (di atas) dan panas (di bawah) pada konten SRAM Kami memutuskan untuk mencari tahu apakah hal di atas benar untuk ESP32. Kami menemukan bahwa Anda dapat menggunakan timer pengawas perangkat keras untuk melakukan boot panas lembut. Anda dapat memaksa timer ini untuk menyala bahkan saat chip dalam mode boot menggunakan bootloader UART. Hasilnya, Anda dapat menggunakan mekanisme ini untuk mengalihkan ESP32 ke mode boot normal.



Menggunakan kode tes, yang dimuat ke SRAM dan dieksekusi menggunakan bootloader UART, kami menentukan bahwa data di SRAM, memang, tetap ada setelah hot reset yang diprakarsai oleh pengatur waktu pengawas. Dan ini berarti kami, setelah merekam apa yang kami butuhkan di SRAM, dapat mem-boot ESP32 seperti biasa.



Kemudian pertanyaan muncul di hadapan kita tentang bagaimana kita dapat menggunakan ini.



Jalan menuju kegagalan



Kami berasumsi bahwa kami mungkin dapat memanfaatkan fakta bahwa data disimpan di SRAM setelah hot reboot untuk sebuah serangan. Serangan pertama kami adalah kami menulis beberapa kode ke SRAM menggunakan bootloader UART, dan kemudian, menggunakan pengatur waktu pengawas, kami melakukan boot ulang perangkat secara panas. Kami kemudian membuat crash dengan menjalankannya karena kode ROM menimpa kode itu dengan kode bootloader flash selama boot normal.



Kami mendapatkan ide ini setelah kami mengubah proses transfer data menjadi proses eksekusi kode dalam eksperimen sebelumnya . Kemudian kami melihat bahwa chip mulai menjalankan kode dari alamat awal sebelum bootloader selesai menyalin.



Terkadang, untuk mencapai sesuatu, Anda hanya perlu mencobanya ...



▍Kode dimuat ke SRAM dan digunakan untuk melakukan serangan



Berikut adalah kode yang kami tulis ke SRAM menggunakan bootloader UART. 



#define a "addi a6, a6, 1;"
#define t a a a a a a a a a a
#define h t t t t t t t t t t
#define d h h h h h h h h h h

void __attribute__((noreturn)) call_start_cpu0() {
    uint8_t cmd;

    ets_printf("SRAM CODE\n");

    while (1) {

        cmd = 0;
        uart_rx_one_char(&cmd);

        if(cmd == 'A') {                                    // 1
            *(unsigned int *)(0x3ff4808c) = 0x4001f880;
            *(unsigned int *)(0x3ff48090) = 0x00003a98;
            *(unsigned int *)(0x3ff4808c) = 0xc001f880;
        }
    }

    asm volatile ( d );                                     // 2

    "movi a6, 0x40; slli a6, a6, 24;"                       // 3
    "movi a7, 0x00; slli a7, a7, 16;"
    "xor a6, a6, a7;"
    "movi a7, 0x7c; slli a7, a7, 8;"
    "xor a6, a6, a7;"
    "movi a7, 0xf8;"
    "xor a6, a6, a7;"

    "movi a10, 0x52; callx8  a6;" // R
    "movi a10, 0x61; callx8  a6;" // a            
    "movi a10, 0x65; callx8  a6;" // e               
    "movi a10, 0x6C; callx8  a6;" // l               
    "movi a10, 0x69; callx8  a6;" // i               
    "movi a10, 0x7A; callx8  a6;" // z               
    "movi a10, 0x65; callx8  a6;" // e               
    "movi a10, 0x21; callx8  a6;" // !               
    "movi a10, 0x0a; callx8  a6;" // \n               

    while(1);
}


Kode ini mengimplementasikan yang berikut (nomor item daftar sesuai dengan nomor yang ditentukan dalam komentar):



  1. Penangan perintah tunggal yang menyetel ulang pengatur waktu pengawas.
  2. Sebuah analog NOPberdasarkan instruksi addi.
  3. Kode perakitan yang mengeluarkan string ke antarmuka serial Raelize!.


▍Memilih waktu serangan



Kami memiliki jendela serangan yang relatif kecil yang kami miliki, dimulai dengan Fseperti yang ditunjukkan pada gambar berikut. Kami tahu dari percobaan sebelumnya bahwa kode bootloader sedang disalin dari memori flash pada saat ini.





Jendela serangan diwakili oleh F



Kegagalan harus terjadi sebelum konten SRAM sepenuhnya ditimpa oleh kode bootloader yang benar dari memori flash.



▍ Siklus Serangan



Dalam setiap eksperimen kami, kami mengambil langkah-langkah berikut untuk memverifikasi bahwa ide serangan berhasil. Organisasi kegagalan yang berhasil seharusnya menghasilkan output ke antarmuka saluran serial Raelize!.



  • Menetapkan pin G0rendah dan menjalankan cold boot untuk masuk ke mode bootloader UART.
  • Menggunakan perintah load_ramuntuk mengeksekusi kode serangan dari SRAM.
  • Mengirim program Ake hot reboot dan kembali ke mode boot normal.
  • Organisasi kegagalan dalam proses menyalin bootloader dari memori flash menggunakan kode dari ROM.


▍Hasil



Setelah kami melakukan eksperimen ini selama lebih dari satu hari, telah melakukannya lebih dari satu juta kali, kami tetap tidak berhasil.



▍Hasil yang tidak terduga



Tetapi, terlepas dari kenyataan bahwa kami tidak berhasil mencapai apa yang kami inginkan, kami, menganalisis hasil eksperimen, menemukan sesuatu yang tidak terduga.



Dalam satu percobaan, antarmuka serial melaporkan data yang menunjukkan bahwa kegagalan mengakibatkan pengecualian IllegalInstruction(instruksi tidak valid). Beginilah tampilannya: 



ets Jun  8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:4
load:0x3fff000c,len:3220
load:0x40078000,len:4816
load:0x40080400,len:18640
entry 0x40080740
Fatal exception (0): IllegalInstruction
epc1=0x661b661b, epc2=0x00000000, epc3=0x00000000, 
excvaddr=0x00000000, depc=0x00000000


Saat mencoba menyebabkan kegagalan chip, pengecualian ini cukup sering terjadi. Hal yang sama berlaku untuk ESP32. Untuk sebagian besar pengecualian ini, register PCdisetel ke nilai yang diharapkan (yaitu, alamat yang benar terletak di sana). Jarang terjadi PCmakna yang begitu menarik muncul.



Pengecualian diberikan IllegalInstructionkarena 0x661b661btidak ada instruksi yang benar pada alamat tersebut . Kami memutuskan bahwa nilai ini PCharus datang dari suatu tempat di register , dan dengan sendirinya tidak dapat muncul di sana.



Untuk mencari penjelasan, kami menganalisis kode yang kami muat ke SRAM. Melihat kode biner, yang cuplikannya ditampilkan di bawah ini, memungkinkan kami untuk dengan cepat menemukan jawaban atas pertanyaan kami. Artinya, di sini mudah untuk menemukan artinya0x661b661b... Ini diwakili oleh dua instruksi addi a6, a6, 1, dengan bantuan yang analognya diimplementasikan dalam kode NOP. 



00000000  e9 02 02 10 28 04 08 40  ee 00 00 00 00 00 00 00  |....(..@........|
00000010  00 00 00 00 00 00 00 01  00 00 ff 3f 0c 00 00 00  |...........?....|
00000020  53 52 41 4d 20 43 4f 44  45 0a 00 00 00 04 08 40  |SRAM CODE......@|
00000030  50 09 00 00 00 00 ff 3f  04 04 fe 3f 4d 04 08 40  |P......?...?M..@|
00000040  00 04 fe 3f 8c 80 f4 3f  90 80 f4 3f 98 3a 00 00  |...?...?...?.:..|
00000050  80 f8 01 c0 54 7d 00 40  d0 92 00 40 36 61 00 a1  |....T}.@...@6a..|
00000060  f5 ff 81 fc ff e0 08 00  0c 08 82 41 00 ad 01 81  |...........A....|
00000070  fa ff e0 08 00 82 01 00  4c 19 97 98 1f 81 ef ff  |........L.......|
00000080  91 ee ff 89 09 91 ee ff  89 09 91 f0 ff 81 ee ff  |................|
00000090  99 08 91 ef ff 81 eb ff  99 08 86 f2 ff 5c a9 97  |.............\..|
000000a0  98 c5 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 3e 0c  |...f.f.f.f.f.f>.|
000000b0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
000000c0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
000000d0  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
...
00000330  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
00000340  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|
00000350  1b 66 1b 66 1b 66 1b 66  1b 66 1b 66 1b 66 1b 66  |.f.f.f.f.f.f.f.f|


Kami menyiapkan "ruang gerak" dengan instruksi ini, menggunakannya dengan cara yang mirip dengan bagaimana urutan perintah NOPsering digunakan dalam eksploitasi untuk menunda eksekusi kode hingga diperlukan. Kami tidak berharap instruksi ini berakhir di register PC.



Tapi kami, tentu saja, tidak menentang penggunaan ini. Kami memutuskan bahwa kami dapat memuat data dari SRAM ke register PCselama crash yang disebabkan ketika data dari memori flash disalin dengan menggunakan kode ROM.



Kami segera menyadari bahwa kami sekarang memiliki semua bahan untuk mempersiapkan serangan yang akan melewati boot aman dan sistem enkripsi flash dalam satu kesalahan. Di sini kami menggunakan pengalaman yang diperoleh selama eksekusi serangan yang dijelaskan sebelumnyaketika kami berhasil mendapatkan kendali register PC.



Cara menuju sukses



Dalam serangan ini, kami menggunakan sebagian besar kode yang sebelumnya dimuat ke SRAM menggunakan bootloader UART. Hanya perintah untuk mengeluarkan karakter ke antarmuka serial yang telah dihapus dari kode ini, karena sekarang tujuan kami adalah mengatur register PCke nilai yang kami butuhkan, yaitu untuk mendapatkan kemampuan untuk mengontrol sistem. 



#define a "addi a6, a6, 1;"
#define t a a a a a a a a a a
#define h t t t t t t t t t t
#define d h h h h h h h h h h

void __attribute__((noreturn)) call_start_cpu0() {
    uint8_t cmd;
   
    ets_printf("SRAM CODE\n");

    while (1) {

        cmd = 0;
        uart_rx_one_char(&cmd);

        if(cmd == 'A') {
            *(unsigned int *)(0x3ff4808c) = 0x4001f880;
            *(unsigned int *)(0x3ff48090) = 0x00003a98;
            *(unsigned int *)(0x3ff4808c) = 0xc001f880;
        }
    }

    asm volatile ( d );

    while(1);
}


Setelah mengkompilasi kode ini, kami, tepat dalam versi binernya, mengganti instruksi addidengan alamat 0x4005a980. Di alamat ini adalah fungsi di ROM yang mengeluarkan data ke antarmuka serial. Panggilan yang berhasil ke fungsi ini akan memberi tahu kami tentang serangan yang berhasil.



Kami mempersiapkan diri untuk menangani kegagalan yang konsisten dengan penyebab pengecualian pada percobaan sebelumnya IllegalInstruction. Setelah beberapa saat, kami menemukan keberhasilan menyelesaikan beberapa eksperimen untuk memuat PCalamat yang diberikan ke register . Kontrol kasus PCsangat mungkin berarti bahwa kita dapat mengeksekusi kode arbitrer.



▍Mengapa ini mungkin?



Judul bagian ini berisi pertanyaan bagus yang tidak mudah dijawab.



Sayangnya, kami tidak memiliki jawaban yang jelas. Kami tentu tidak mengharapkan manipulasi data untuk memungkinkan kontrol register PC. Kami memiliki beberapa penjelasan untuk ini, tetapi kami tidak dapat mengklaim dengan pasti bahwa semua itu benar.



Satu penjelasan adalah bahwa selama kegagalan, kedua operan instruksi ldrdigunakan untuk memuat nilai ke dalamnya a0. Ini mirip dengan apa yang kami lihat dalam serangan ini , di mana kami memperoleh kendali tidak langsung atas register PCdengan memodifikasi data.



Selain itu, ada kemungkinan bahwa kode yang disimpan dalam ROM mengimplementasikan fungsionalitas yang berkontribusi pada keberhasilan serangan ini. Dengan kata lain, karena kegagalan, kita dapat mengeksekusi kode yang benar dari ROM, yang mengarah pada fakta bahwa data dari SRAM dimuat ke register PC.



Lebih banyak penelitian perlu dilakukan untuk menemukan apa sebenarnya yang memungkinkan kami melakukan serangan ini. Tetapi jika Anda melihat masalah ini dari sudut pandang seseorang yang memutuskan untuk meretas chip, kami memiliki cukup pengetahuan untuk membuat eksploitasi berdasarkan kemungkinan memengaruhi register PC.



Ekstrak konten memori flash sebagai teks biasa



Kita dapat menulis ke register PCapa yang kita inginkan, tetapi kita belum dapat mengambil konten memori flash sebagai teks biasa. Oleh karena itu, diputuskan untuk memanfaatkan kemampuan bootloader UART.



Yakni, kami memutuskan untuk langsung ke bootloader UART saat chip dalam mode boot normal. Untuk melakukan serangan ini, kami menulis ulang instruksi addidalam kode yang dimuat ke RAM, sebagai gantinya menggunakan alamat awal kode bootloader UART ( 0x40007a19).



UART bootloader mengeluarkan baris yang ditunjukkan di bawah ini ke antarmuka serial. Kita bisa menggunakan fakta ini untuk menentukan keberhasilan sebuah serangan. 



waiting for download\n"


Setelah percobaan seperti itu berhasil, kita cukup menggunakan esptool.pyuntuk menjalankan perintah read_memdan mengakses data flash dalam teks biasa. Misalnya, perintah berikut membaca 4 byte dari ruang alamat flash eksternal ( 0x3f400000). 



esptool.py --no-stub --before no_reset --after no_reset read_mem 0x3f400000


Sayangnya, perintah seperti itu tidak berhasil. Untuk beberapa alasan, respons prosesor tampak seperti 0xbad00bad, menunjukkan bahwa kami mencoba membaca data dari memori yang tidak terisi. 



esptool.py v2.8
Serial port COM8
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Crystal is 40MHz
MAC: 24:6f:28:24:75:08
Enabling default SPI flash mode...
0x3f400000 = 0xbad00bad
Staying in bootloader.


Kami memperhatikan bahwa cukup banyak pengaturan dibuat di awal bootloader UART. Kami berasumsi bahwa pengaturan ini mungkin mempengaruhi MMU juga.



Hanya untuk mencoba sesuatu yang lain, kami memutuskan untuk langsung ke pengendali perintah dari bootloader UART ( 0x40007a4e) itu sendiri . Setelah kita menemukan diri kita di handler, kita dapat mengirim perintah read_memsecara mandiri langsung ke antarmuka serial: 



target.write(b'\xc0\x00\x0a\x04\x00\x00\x00\x00\x00\x00\x00\x40\x3f\xc0')


Sayangnya, jika Anda langsung menuju ke pawang, maka baris yang ditampilkan setelah masuk ke bootloader UART (yaitu - waiting for download\n) tidak akan ditampilkan. Karena itu, kami kehilangan cara sederhana dan nyaman untuk mengidentifikasi eksperimen yang berhasil. Akibatnya, kami memutuskan untuk mengirimkan perintah di atas di semua eksperimen, terlepas dari apakah eksperimen itu berhasil atau tidak. Kami menggunakan waktu tunggu serial yang sangat singkat untuk meminimalkan waktu tunggu tambahan yang terkait dengan batas waktu ini, yang hampir selalu terjadi.



Setelah beberapa saat, kami melihat hasil dari percobaan pertama yang berhasil!



Hasil



Pada artikel ini, kami menjelaskan serangan pada ESP32, di mana kami melewati sistem boot aman dan enkripsi memori flash, mengatur hanya satu kegagalan dalam mikrokontroler. Selain itu, kami menggunakan kerentanan yang dieksploitasi selama serangan untuk mengekstrak konten memori flash terenkripsi dalam teks biasa.



Kita bisa menggunakan FIRM untuk melewati serangan ini .





Kemajuan Serangan



Berikut adalah penjelasan singkat tentang apa yang terjadi dalam langkah-langkah berbeda dari serangan di atas:



  1. Aktifkan (pilihan alat untuk melakukan serangan) - di sini kompleks Riscure Inspector FI digunakan .
  2. Injeksi (serangan) - efek elektromagnetik pada mikrokontroler yang sedang diselidiki.
  3. Glitch ( ) — , (, , ).
  4. Fault ( ) — , , , . , - .
  5. Exploit ( ) — UART , SRAM, . UART PC read_mem.
  6. Goal ( ) — - .


Menariknya, keberhasilan serangan ini bergantung pada dua kelemahan di ESP32. Kelemahan pertama adalah bootloader UART tidak dapat dinonaktifkan. Hasilnya, selalu tersedia. Kelemahan kedua adalah masih adanya data di SRAM setelah hot reset perangkat. Hal ini memungkinkan penggunaan bootloader UART untuk mengisi SRAM dengan data arbitrer.



Dalam laporan informasi , yang mengacu pada serangan tersebut, perusahaan Espressif melaporkan bahwa versi ESP32 yang lebih baru terdapat mekanisme yang membuat serangan seperti itu tidak mungkin dilakukan.



Semua sistem tertanam standar rentan terhadap serangan gangguan perangkat. Oleh karena itu, tidak heran jika mikrokontroler ESP32 juga rentan terhadap serangan side channel. Keripik seperti ini tidak dirancang untuk menahan serangan semacam itu. Namun yang terpenting, ini tidak berarti bahwa serangan semacam itu tidak membawa risiko apa pun.



Penelitian kami telah menunjukkan bahwa mengeksploitasi kelemahan chip memungkinkan terjadinya serangan yang berhasil, menyebabkan kegagalan. Sebagian besar serangan yang dapat dipelajari dari sumber terbuka menggunakan pendekatan tradisional, di mana fokus utamanya adalah melewati pemeriksaan. Kami belum melihat banyak laporan serangan seperti yang telah kami jelaskan.



Kami yakin bahwa potensi penuh dari serangan tersebut masih belum dieksplorasi sepenuhnya. Sampai saat ini, sebagian besar peneliti hanya mempelajari metode untuk mengganggu pengoperasian chip (langkah Aktifkan, Injeksi, Glitch), tetapi kami melangkah lebih jauh, mempertimbangkan kemungkinan bekerja dengan chip yang rentan setelah kegagalan (langkah Fault, Exploit, Goal).





Penelitian hingga 2020 dan setelah tahun 2020



Kami yakin bahwa penggunaan kreatif model kegagalan chip baru akan mengarah pada peningkatan metode serangan yang menggunakan strategi eksploitasi kerentanan yang menarik untuk mencapai berbagai tujuan.



Jika Anda tertarik dengan topik yang diangkat dalam materi ini, maka di sini , di sini dan di sini - materi lain yang dikhususkan untuk studi ESP32.



Pernahkah Anda menjumpai dalam praktik meretas perangkat apa pun menggunakan metode yang mirip dengan yang dibahas dalam artikel ini?









More articles:


All Articles