Recuperare un database di Signal danneggiato

Il database di Signal Desktop si trova in ~/Library/Application Support/Signal/sql/db.sqlite su macOS, in %AppData%\Signal\sql\db.sqlite su Windows e in ~/.config/Signal/sql/db.sqlite su Linux. Poiché SQLCipher cifra l'intero file, eseguire file db.sqlite mostra byte casuali invece della consueta firma SQLite format 3\0. Qualsiasi strumento SQLite normale — l'interprete sqlite3, DB Browser o il motore di recupero di questa pagina — vede testo cifrato, non pagine, e non può né vuole indovinare la chiave.

La chiave SQLCipher di 64 caratteri esadecimali si trova in config.json, accanto al database. Nelle versioni più vecchie è memorizzata in chiaro sotto un campo key; dal 2024 Signal la avvolge sotto encryptedKey usando l'API safeStorage di Electron, sostenuta dall'elemento del Portachiavi di macOS chiamato "Signal Safe Storage", da DPAPI su Windows e da gnome-libsecret / kwallet su Linux. Poiché l'involucro è legato al tuo account del sistema operativo, la chiave si scarta sulla stessa macchina e con lo stesso utente che l'hanno creata.

Con la chiave grezza a disposizione, apri il database in un qualsiasi strumento compatibile con SQLCipher (la CLI sqlcipher, oppure una build di DB Browser for SQLite compilata con SQLCipher) ed esegui PRAGMA key = "x'<chiave-64-hex>'"; seguito da PRAGMA cipher_compatibility = 4; — Signal include SQLCipher 4. Poi esporta una copia in chiaro con .recover o con VACUUM INTO 'plain.sqlite'. Quel file in chiaro è quello che trascini qui. Lavora sempre su una copia byte per byte, mai sul tuo unico originale.

Una volta decifrato, un database di Signal è un normale file SQLite: un array piatto di pagine di dimensione fissa (4096 byte ciascuna). La pagina 1 contiene l'intestazione e lo schema; ogni tabella e indice è un b-tree di pagine interne che puntano verso il basso, alle pagine foglia che contengono le righe. I dati di Signal risiedono in tabelle come messages (ogni riga identificata da id, con conversationId, sent_at, received_at, type, una colonna body e una colonna json che porta il record completo del messaggio), conversations, reactions, sessions, items e un indice full-text messages_fts (FTS5) usato per le ricerche.

La corruzione è quasi sempre localizzata. Un'interruzione di corrente a metà di una scrittura, una sincronizzazione interrotta, una pagina lacerata su uno storage che ha mentito sul flush: un solo puntatore di un b-tree smette di concordare con i dati e SQLite solleva SQLITE_CORRUPT: Error: database disk image is malformed (11). Rifiuta l'intero file nell'istante in cui non può più fidarsi della struttura, anche se le altre tabelle sono lì intatte nelle loro pagine foglia. Il file sembra molto peggio di quanto sia davvero.

L'errore correlato file is not a database (SQLITE_NOTADB, codice 26) ha qui due significati: o la firma di 16 byte dell'intestazione è stata danneggiata (le pagine che ci sono dietro sono spesso intatte), oppure — molto più comune con Signal — hai puntato uno strumento normale al file ancora cifrato. Se lo vedi prima di decifrare, è la cifratura che parla, non un danno.

Il recupero delle pagine non ripara il file rotto sul posto; fa ciò che fa il .recover di SQLite stesso. Percorre il file decifrato pagina per pagina e, per ogni pagina che sembra una foglia di tabella, legge direttamente ogni cella — rowid, tipi seriali, valori — e reinserisce ogni riga decodificabile in un database nuovo e vuoto. Le pagine danneggiate vengono saltate; le pagine leggibili cedono le loro righe, che il b-tree che le indicizzava sia sopravvissuto o no. Le righe che la catena di puntatori non raggiunge più vengono trovate con una scansione grezza, e le righe la cui tabella di origine non può essere identificata finiscono in una tabella lost_and_found indicizzata per pagina e cella, invece di essere scartate. In pratica, le tue righe di messages tornano con il loro body e il loro json intatti anche se a rompersi è stato l'indice FTS o l'albero di una singola conversazione.

Se il crash ha lasciato un file gemello -wal (la modalità WAL prepara le transazioni confermate più recenti prima di riversarle — checkpoint — in db.sqlite), lì ci sono i tuoi messaggi più recenti, ma anch'esso è cifrato con SQLCipher, quindi decifralo insieme al file principale. Dato un database in chiaro e il suo WAL in chiaro, il motore sovrappone i frame confermati prima della scansione, così il recupero riflette l'ultima transazione confermata.

I limiti onesti sono reali. Gli allegati non sono nel database: Signal salva foto, video e file come blob separati e cifrati individualmente sotto attachments.noindex/, quindi una riga di messages recuperata conserva il puntatore e i metadati, ma recuperare il DB non decifra il file multimediale in sé. Tutto ciò che è stato fisicamente sovrascritto o troncato dalla fine del file è perso: un file SQLite non ha ridondanza con cui ricostruirlo. E l'output recuperato è sempre sospetto: poiché la scansione legge celle grezze, incluse le pagine della freelist, possono riaffiorare messaggi cancellati e un valore può tornare con la classe di archiviazione sbagliata, quindi verificalo rispetto a una fonte nota e affidabile prima di farci affidamento.

Il database di un messenger è il singolo file che meno vorresti su un server che non controlli: è ogni conversazione, ogni contatto e ogni gruppo che hai conservato. I servizi di "riparazione" basati sul caricamento copiano quel file su un'infrastruttura che non puoi ispezionare, secondo condizioni di conservazione che non hai scritto tu; e con un database di Signal, questo smonta in silenzio tutto il senso di usare Signal.

Qui il recupero viene eseguito interamente nella scheda del tuo browser: il file in chiaro viene letto dal disco, ricostruito localmente e scaricato, e puoi aprire la scheda Rete (Network) e vedere uscire 0 byte. Altrettanto importante: anche il passaggio di decifratura resta locale — la tua chiave SQLCipher proviene dal tuo Portachiavi (o da config.json) ed è usata da uno strumento sulla tua macchina, mai trasmessa. Recuperare un database di Signal in questo modo significa non affidare a nessuna terza parte né i dati né la chiave.