Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/themalwareguardian/uefi-security-research-howyar-sysreturn-netcopy
Sicurezza Sistemi EmbeddedAnalisi delle VulnerabilitàExploitReverse EngineeringAnalisi MalwareSicurezza HardwareAnalisi di BinariPaper e RicercaAnalisi del Firmware
GitHubthemalwareguardian/uefi-security-research-howyar-sysreturn-netcopy

UEFI-Security-Research-Howyar-SysReturn-NetCopy

Analisi post CVE-2024-7344 di Howyar SysReturn NetCopy - note di reverse engineering, binari vulnerabili, corrispondenza con il fornitore e tooling proof-of-concept per CVE-2026-79298 (bypass di Secure Boot IA-32 tramite il loader PE personalizzato RxPE in BOOTia32.efi).

Vedi Repository
23320 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

🌊 Ricerca sulla Sicurezza UEFI - Howyar SysReturn NetCopy

Sotto il mantello del Secure Boot, alcune architetture affondano più in profondità delle vulnerabilità che le hanno esposte. Alcuni binari vengono revocati. Alcune patch vengono distribuite. Ma in profondità sotto la superficie, le vecchie abitudini lasciano tracce. Questo è ciò che rimane quando una vulnerabilità viene divulgata, corretta e dimenticata.




🐞 CVE-2026-79298 - Assegnata

Le scoperte documentate in questo repository sono state assegnate a CVE-2026-79298.

Durante il processo di divulgazione coordinata, il fornitore ha confermato che la correzione associata a CVE-2024-7344 riguardava solo il percorso di avvio x64. Il percorso di avvio IA-32 - incluso BOOTia32.efi distribuito come parte della funzionalità SysReturn NetCopy - non è mai stato incluso nella correzione originale. Di conseguenza, il componente IA-32 vulnerabile ha continuato a essere distribuito commercialmente fino alla versione 11.3.034 (luglio 2026).

Il repository dedicato alla CVE rimanda qui per la completa profondità tecnica: reverse engineering, analisi binaria, corrispondenza con il fornitore, artefatti di riproduzione e strumenti proof-of-concept.

➡️ Ricerca: CVE-2026-79298




📑 Indice

  • Come è iniziata questa ricerca
  • Il problema che ha portato SysReturn alla mia attenzione
  • Il software di ripristino come risposta operativa
  • CVE-2024-7344

  • Ottenere il software
  • Cosa ho trovato

  • Struttura del repository
  • Da dove iniziare



🎯 Come è iniziata questa ricerca

Nel corso del 2026 mi sono dedicato a fondo alla sicurezza UEFI - sviluppo di bootkit, bypass del Secure Boot, sfruttamento del firmware, analisi di CVE, sviluppo di strumenti offensivi, pubblicazione di ricerche. È l'area in cui ho scelto di specializzarmi e ogni settimana porta qualcosa di nuovo. Parte di questo lavoro consiste nello sfruttare CVE note nei componenti UEFI. Parte consiste nel ricercare software che distribuisce bootloader UEFI ma ha ricevuto scarsa attenzione pubblica. E parte - la parte che questo repository documenta - consiste nel porsi una domanda che ritengo venga troppo spesso trascurata:

Come appare un prodotto dopo una CVE?

Non durante la corsa alle patch. Non nella settimana in cui viene pubblicato l'avviso. Diciotto mesi dopo, quando la pressione è svanita, quando i ricercatori sono passati oltre, quando nessuno sta più guardando.

Questo repository è il mio tentativo di rispondere a quella domanda per uno specifico prodotto: Howyar SysReturn NetCopy.

E credo che ciò che ho trovato sorprenderà le persone.




🏫 Il problema che ha portato SysReturn alla mia attenzione

Tutto nella ricerca sulla sicurezza si collega a qualcos'altro se si seguono i fili abbastanza a lungo. Questo particolare filo è iniziato al lavoro. Ci è stato affidato il compito di analizzare il rischio reale degli attacchi UEFI e bootkit contro una specifica categoria di ambienti: i centri educativi. Sembra di nicchia. Non lo è.

Ecco la realtà che la maggior parte delle persone al di fuori di questo campo non comprende appieno. In una città di medie dimensioni, possono esserci facilmente 70.000 o più dispositivi condivisi distribuiti nelle scuole - laptop e workstation utilizzati da studenti tra gli otto e i quindici anni, che eseguono distribuzioni Linux perché le licenze Windows su quella scala sono spesso proibitive.

Ora chiedetevi: quante di quelle macchine hanno il Secure Boot correttamente abilitato? La risposta onesta, nella maggior parte dei luoghi, è molto poche. E il motivo non è la negligenza. È la realtà operativa.

Abilitare correttamente il Secure Boot in un ambiente Linux significa firmare ogni kernel. Ogni aggiornamento del kernel - e le vulnerabilità del kernel Linux sono arrivate rapidamente negli ultimi anni - richiede una nuova immagine firmata da distribuire su ogni singola macchina. Ciò significa pipeline di aggiornamento coordinate, infrastruttura di gestione delle chiavi, personale formato e manutenzione continua su migliaia di endpoint distribuiti in dozzine di sedi.

Per le organizzazioni con queste risorse, è gestibile. Per la maggior parte dei distretti scolastici, non lo è. Semplicemente non ci sono abbastanza persone, abbastanza budget e abbastanza strumenti per farlo correttamente su quella scala. Quindi il Secure Boot rimane disabilitato.

Le password del BIOS non vengono impostate - perché ruotarle su 70.000 macchine con personale limitato è impraticabile. E quelle macchine restano lì, completamente esposte a livello di firmware, utilizzate da centinaia di studenti ogni giorno.

Ciò che questo significa realmente, da una prospettiva di sicurezza, è che un attaccante che comprende lo sfruttamento UEFI può compromettere una di quelle macchine a livello di firmware - prima che il sistema operativo si carichi, prima che qualsiasi software di sicurezza si avvii, prima che qualsiasi meccanismo di protezione abbia la possibilità di intervenire. Un bootkit può persistere attraverso i riavvii, attraverso le reinstallazioni del sistema operativo, attraverso tutto. Lo so perché sviluppo io stesso quel tipo di strumenti. Le tecniche esistono. Non sono teoriche.

Questo è un problema noto. È ampiamente riconosciuto. E non scomparirà presto.




🔄 Il software di ripristino come risposta operativa

La risposta operativa a quel problema - ciò che le scuole effettivamente distribuiscono invece di un Secure Boot adeguato - è il software di ripristino.

L'idea è semplice: qualunque cosa faccia uno studente durante una sessione, tutto ritorna a uno stato noto e pulito dopo il riavvio successivo. Malware, modifiche alla configurazione, file di sistema danneggiati, dati eliminati accidentalmente o intenzionalmente - spariti. Questo riduce drasticamente i costi di manutenzione e offre agli amministratori un modo per gestire macchine condivise senza dover avere controlli di sicurezza perfetti a livello di firmware su ogni dispositivo.

Quando abbiamo iniziato a valutare quali prodotti venivano utilizzati in questi ambienti, sono emersi diversi nomi. Uno di questi era Howyar SysReturn - un prodotto taiwanese progettato specificamente per distribuzioni educative, con supporto esplicito per laboratori informatici scolastici, workstation condivise e ambienti gestiti su larga scala.

Nel momento in cui ho visto quel nome, sapevo esattamente cosa volevo fare.




🔍 CVE-2024-7344

Nel gennaio 2025, ESET Research ha pubblicato la divulgazione di CVE-2024-7344 - un bypass del Secure Boot che interessa SysReturn e diversi altri prodotti di ripristino basati sullo stesso codebase.

Scarica lo strumento