Comprendere le Fondazioni di Reverse Engineering Network Storage

Invertire l'ingegneria di un sistema di archiviazione di rete proprietario richiede un approccio metodologico che abbraccia gli strati di hardware, firmware e comunicazione di rete. Se state costruendo un'utilità di backup per un elettrodomestici non supportato, eseguire un audit di sicurezza, o sviluppare un controller di sostituzione, le competenze richieste sono sia tecniche che legalmente nuanced. Questa guida cammina attraverso l'intero processo, dalle considerazioni legali per testare i risultati, con esempi pratici tratti da architetture di storage reali.

Prima di immergersi in strumenti e tecniche, vale la pena chiedere perché chiunque invertisse un sistema di archiviazione a tutti. Le motivazioni comuni includono: raggiungere l'interoperabilità con le apparecchiature legacy, verificare le pretese di sicurezza, recuperare i dati da un fornitore fallito, o creare driver open source per l'hardware delle merci.

Mazzi giuridici ed etici

Il Digital Millennium Copyright Act (DMCA) negli Stati Uniti, ad esempio, vieta le misure di protezione tecnologica, anche se esistono esenzioni per la ricerca di sicurezza e l'interoperabilità. Il testo DMCA[ fornisce il quadro legale familiare nell'Unione Europea, la direttiva del proprietario del software consente l'inversione di ingegneria per l'interoperabilità in determinate condizioni.

Se scopri una vulnerabilità di sicurezza, segui le pratiche di divulgazione responsabile. Non rilasciare il codice di exploit pubblicamente senza dare al venditore una finestra ragionevole per patchare il problema. L'obiettivo di reverse engineering un sistema di archiviazione dovrebbe essere quello di migliorare la sicurezza e l'interoperabilità, non per aggirare le licenze o rubare la proprietà intellettuale.

Inoltre, molti sistemi di archiviazione proprietari incorporano firme crittografiche e guarnizioni antimanomissione. Rompere queste possono annullare le garanzie o causare il dispositivo di smettere di funzionare.

Assemblaggio del tuo strumento di ingegneria inversa

L'ingegneria inversa di successo della rete di archiviazione richiede una serie di strumenti specializzati. L'elenco esatto dipende dal fatto che si sta concentrando su protocolli hardware, firmware o di rete, ma la maggior parte dei progetti richiedono una combinazione dei seguenti.

Strumenti di analisi hardware

Strumenti software e firmware

  • IDA Pro[] – disassemblatore e debugger standard del settore. Il suo decompiler è particolarmente utile per la comprensione del firmware ARM e MIPS.
  • Ghidra[] – struttura di reverse engineering free e open source sviluppata dalla NSA, supporta molte architetture e include un decompiler.
  • Binwalk[] – analizza le immagini del firmware per i filesystem, i kernel e i bootloader incorporati.
  • strings e hexdump[[] – semplice ma efficace per il rapido riconoscimento dei modelli in blobs binari.
  • GDB] – per analisi dinamica se è possibile collegare un debugger al sistema di esecuzione.

Strumenti di monitoraggio della rete

  • Wireshark[] – cattura e decodifica i pacchetti di rete. I dissettori personalizzati possono essere scritti in Lua per i protocolli proprietari.
  • tcpdump[[] – alternativa di linea di comando leggera per sistemi senza testa.
  • Ettercap[[]] o Bettercap[] – per attacchi di mezzo uomo sul traffico di rete se è necessario intercettare sessioni crittografate.
  • Scapy[] – libreria Python per la realizzazione e l'analisi di pacchetti di rete programmaticamente.

Riconnascimento Hardware iniziale

Iniziate ispezionando visivamente il sistema di archiviazione. Rimuovete l'armadio (con opportune precauzioni ESD) e documentate ogni componente principale. Cercate il sistema principale-on-chip (SoC) o CPU, chip DRAM, flash NAND o flash NOR per il firmware, e qualsiasi ASIC dedicato a RAID o crittografia.

Identificare le porte della console seriale. I dispositivi di archiviazione incorporati espongono un intestazione UART per il debugging, spesso etichettato come TX[], ] RX[], ]GND]], e talvolta [[FLT file di configurazione di configurazione di configurazione di configurazione di configurazione di configurazione di file di configurazione di configurazione di configurazione di file di configurazione di configurazione di configurazione di file di configurazione di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di file di configurazione VCC[

Cercare segnali di reset e oscillatori di clock. Queste informazioni sono preziose se si prevede di analizzare i controlli di sicurezza di boot-time o la necessità di bypassare la crittografia basata su hardware.

Se il dispositivo ha un chip flash SPI rimovibile, è possibile scaricare il suo contenuto utilizzando un programmatore flash. Desoldering il chip è invasivo, ma per analisi non distruttive spesso è possibile clip sul chip con una clip Pomona SOIC. L'immagine scaricata conterrà il bootloader (U-Boot, Redboot, ecc), kernel, e forse un rootf.

Estrazione e analisi del firmware

Con un'immagine del firmware in mano, il passo successivo è quello di identificare la sua struttura. Utilizzare []binwalk[]] per la scansione per firme note. Ad esempio, il comando estrae ricorsivamente filesystems come SquashFS, JFFS2, o UBIFS che sono comuni nei dispositivi di archiviazione di rete. Se il firmware viene compresso o crittografato, è necessario trovare il tasto.

Trovare le chiavi di crittografia

I fornitori a volte codificano i tasti AES nel bootloader o in un blocco di configurazione separato. Le stringhe come o nell'output binario da possono rivelarli. In molti casi, la chiave è semplicemente un modello di ripetizione o derivato da un numero di serie del dispositivo. Se il dispositivo utilizza il modulo di avvio Trusted (TPM) per la memorizzazione chiave, è necessario estrarre i tasti JPMTA

Smontaggio di componenti di firmware critici

Caricare il kernel o bootloader in IDA Pro o Ghidra. Concentrati su routine che gestiscono l'autenticazione, i servizi di rete e le operazioni di filesystem. Per un dispositivo NAS, cerca il server [RPC[] (rimozione chiamata procedura) spesso implementato tramite XML-RPC o un protocollo binario personalizzato.

Molti sistemi di archiviazione proprietari hanno vulnerabilità negli script CGI o nelle interfacce web che possono essere sfruttate senza hardware costoso. Un semplice overflow buffer in un parametro di stringa di query potrebbe dare accesso root.

Gli emulatori come QEMU[] possono eseguire il firmware estratto in un ambiente di movimento utente o di sistema, consentendo analisi dinamiche senza il dispositivo fisico.

Invertire Ingegneria il Protocollo di rete

I dispositivi di archiviazione di rete utilizzano in genere più protocolli contemporaneamente. I comuni includono SMB/CIFS per la condivisione di file di Windows, NFS per Unix e HTTP/HTTPS per le interfacce di gestione del web.

Catturare il traffico

Posizionare il dispositivo su un VLAN isolato e utilizzare un interruttore con mirroring della porta o un hub per catturare tutto il traffico. Eseguire Wireshark con un filtro come []] per concentrarsi sul dispositivo di archiviazione. Eseguire operazioni tipiche – la lettura di un file, la creazione di un'istantanea, la modifica delle impostazioni – e salvare le cattura dei pacchetti.

Identificare la struttura del protocollo

Molti fornitori utilizzano semplici protocolli binari con un intestazione a dimensione fissa contenente lunghezza, ID di comando, numero di sequenza e checksum. Ad esempio, se si vedono byte ] ricorrenti all'inizio di ogni pacchetto, che potrebbe essere un campo di numero e lunghezza magici.

Utilizza Scapy[] per creare pacchetti con campi modificati e osservare la risposta. Il processo e l'errore possono mappare rapidamente gli ID dei comandi alle azioni. Ad esempio, se si invia un pacchetto con ID di comando [] attiva un volume di montaggio, si ha identificato un'operazione.

Se il traffico appare crittografato ma inizia sempre con gli stessi pochi byte, può essere un semplice cifratore XOR su un intestazione conosciuta. Prova XORing i primi 16 byte con il byte chiave indovinato. Molti dispositivi NAS di consumo utilizzano ancora chiavi statiche XOR per “crittografia” che è più offuscamento che sicurezza.

Scrivere un Dissector Wireshark personalizzato

Una volta compreso il formato dei pacchetti, scrivi un dissettore Lua per Wireshark. Questo ti aiuterà a decodificare automaticamente le catture. Un modello di dissetore di base potrebbe assomigliare:

local p_storage = Proto("storage", "Proprietary Storage Protocol")
local f_length = ProtoField.uint16("storage.length", "Length")
local f_cmd = ProtoField.uint16("storage.cmd", "Command ID")
p_storage.fields = { f_length, f_cmd }
function p_storage.dissector(buf, pkt, tree)
 local subtree = tree:add(p_storage, buf(0, 4))
 subtree:add(f_length, buf(0, 2))
 subtree:add(f_cmd, buf(2, 2))
end
-- then register for your protocol

Caricare il dissetore in Wireshark e ri-analisi delle tue catture. La capacità di vedere i campi decodifica accelera la comprensione del comportamento del sistema.

Porte e interfacce Debug

Molti sistemi di archiviazione espongono le interfacce di debug sul PCB. L'UART che abbiamo catturato i log di avvio da prima potrebbe anche accettare l'ingresso durante il processo di avvio. Interruzione del bootloader (U-Boot) premendo una chiave (spesso ]]]Space] o ]]Enter] file di memoria di boot

Usare uno strumento come OpenOCD]] per connettersi al contenuto della CPU e discarica della RAM. Per i dispositivi con JTAG bloccato (ad esempio, attraverso fusibili di sicurezza), potrebbe essere necessario attaccare il processo di avvio tramite tecniche di glitching.

Case study: Inversione di un fornitore comune di NAS

Abbiamo applicato questi metodi a un modello più vecchio da un popolare fornitore NAS che rimarrà senza nome. Il dispositivo ha usato un ARMADA SoC Marvell. Collegando all'UART, abbiamo ottenuto una shell radice con uno sforzo minimo - il venditore aveva lasciato la password radice invariata (ben noto dai post del forum). Da lì, abbiamo esaminato i processi in esecuzione e identificato il daemon responsabile per il protocollo di backup proprietario.

Questa scoperta è stata rivelata responsabilmente al fornitore, che ha rilasciato un aggiornamento del firmware che ha sostituito la chiave statica con una chiave di sessione-derivata. I dettagli completi sono documentati in una carta di ricerca[ sulle vulnerabilità del NAS di consumo.

Documentazione delle tue scoperte

Mantenere un quaderno di laboratorio – fisico o digitale – con diagrammi del PCB, cattura dei pacchetti annotati, note smontabili e risultati di test. Strumenti come Obsidian[]] o ]Nozione funziona bene per l'organizzazione delle note di errore collegate.

Scrivere script che automatizzano le attività ripetitive. Ad esempio, uno script Python può inviare una sequenza di pacchetti per enumerate tutti i comandi disponibili e confrontare le risposte.

Se il vostro obiettivo è quello di costruire un driver open source o uno strato di compatibilità, la vostra documentazione diventa le specifiche. Utilizzare per scrivere una libreria in C o Python che altri sviluppatori possono adottare.

Test e convalida

Convalida la tua comprensione eseguendo i passaggi di reverse engineering su una seconda unità identica (se disponibile) per garantire che le tue osservazioni non siano dovute a un guasto hardware.

Per le operazioni di file system, confrontare il comportamento del vostro protocollo in reverse-engineered contro il cliente ufficiale del fornitore. Se producono risultati identici, probabilmente avete decodificato correttamente il protocollo.

I test di sicurezza devono essere condotti in un ambiente di laboratorio isolato. Non puntare mai i tuoi strumenti di reverse engineering in una rete di produzione. Utilizzare un analizzatore di spettro per verificare la perdita di RF se il dispositivo ha capacità wireless – una supervisione comune nelle valutazioni di sicurezza.

Conclusioni

Con un'attenta preparazione, gli strumenti giusti e un approccio metodologico, è possibile scoprire i protocolli e gli interni che i fornitori tentano di mantenere nascosto. Opera sempre all'interno dei confini legali ed etici, e utilizzare i risultati per migliorare la sicurezza e l'interoperabilità. La conoscenza acquisita non solo demystify a black box ma consente anche di estendere la vita di hardware che altrimenti potrebbe diventare a causa di evasione.

Il viaggio dall'ispezione visiva a un driver open source funzionante è lungo, ma ogni passo – dai log di avvio UART all'analisi di cattura dei pacchetti – vi avvicina. Ricordate di documentare tutto, testare rigorosamente e condividere i vostri risultati in modo responsabile. La comunità di ingegneri hardware e software inverso è una risorsa preziosa; considerate di contribuire con i vostri dissensori, script e risultati personalizzati.