Posso salvare questi documenti su una macchina morente dall'oblio?

Innanzitutto, una confessione: no, non ho fatto i backup che avrei dovuto.

In secondo luogo, la situazione:

Ho un Dell XPS 9550 con un disco a stato solido con Fedora 25 .

Stavo lavorando su un file e ho provato a salvarlo quando mi è stato detto che stavo cercando di salvare in un file system di sola lettura . Si scopre che il mio filesystem è di sola lettura ora e ci sono errori di I / O dappertutto.

Sono stato in grado di salvare alcuni file inviandoli tramite e-mail tramite un browser Web aperto, ma si è bloccato e non sono in grado di riavviarlo. Ma ho ancora file di interesse aperti in un editor. Non riesco a salvare i file da nessuna parte, ma posso copiarne il contenuto. Se solo potessi trovare un modo per esfiltrare il contenuto del file, potrei risparmiarmi mesi di lavoro.

Ma ci sono alcune orribili limitazioni. Ho tentato di inserire un'unità USB, ma nessun dispositivo sembra rappresentarla e il mountcomando muore con un segfault. Posso provare a ssh su un altro computer, ma ricevo "errore bus" e muore. ping, dmesg, ifconfig, Nessuno di questi lavori. Ma io ce l'ho vime lessed lse in grado di generare nuove bashistanze.

No lynx, no firefox, no google-chrome. Non c'è un lettore DVD.

Fondamentalmente sembra che il mio SSD sia morto. O forse l'intera scheda madre. Ho documenti di grande valore ancora in memoria, ho un indirizzo IP e una connessione di rete, posso eseguire alcuni comandi casuali e avere altri 3500 sul percorso che potrei provare.

cate gccsembra funzionare. Posso scrivere su file in / tmp. Ho ipythonun'istanza corrente che sembra funzionare ancora.

Quindi ... quello che ho provato finora è fallito. Ma sento che ci sono ancora mille possibilità. Cosa non sto considerando? Come potrei eventualmente ottenere questi file dal mio computer morente?

Ci deve essere un modo.

AGGIORNAMENTO : Novità:

• Ho perso la connessione di rete a causa della mia stupidità.
• Ho scritto uno script Python per sostituire cpecp -r
• A meno che non trovo un modo per creare una /devvoce per la scheda SD o per le unità USB, le mie migliori scommesse per ottenere i dati sembrano essere lo schermo e possibilmente gli altoparlanti / il cavo audio.
• Sto scrivendo uno script per provare a leggere i file e produrre quelli che sono leggibili.

Suggerimenti ancora molto graditi!

AGGIORNAMENTO 2 : Elementi più recenti:

• Sul computer morente ho scritto uno script Python che leggerà un file bit per bit e proverò a trasmettere quei bit facendo lampeggiare lo schermo di un colore o di un altro. In questo momento sta cercando di creare un codice a due bit in cui rosso, verde, blu e bianco rappresentano tutti una coppia a due bit. Tuttavia, non funziona così bene, quindi potrei semplicemente passare a due colori e fare un po 'alla volta.
• Sull'altro mio laptop (il vecchio fidato Thinkpad a cui ho rinunciato per questo nuovo XPS) ho scritto uno script che legge dalla webcam usando la libreria OpenCV Python. L'idea è di far decodificare i codici inviati dall'altro computer. Il problema è che il framerate dalla fotocamera è qualcosa come 15 frame al secondo, il che significa che se avessi un trasferimento perfetto e senza errori la mia velocità massima di dati sarebbe di 30 bit al secondo, cioè 225 byte al secondo. Sono 324k al giorno.
• Sull'XPS morente posso usare tarper comprimere i file desiderati in un singolo archivio, che è 1,7 MB. Purtroppo, gzip, bzip2, xz, lzope qualunque compressione utility non sono disponibili. MA usando il zlibmodulo di Python posso comprimere questo file fino a 820 KB. Date queste dimensioni, potrei probabilmente spedire questa cosa in un paio di giorni.
• Poiché questo metodo di trasferimento sarà probabilmente molto soggetto a errori, implementerò i codici Hamming sull'XPS per aggiungere una correzione dell'errore mentre trasmetto i dati.
• Probabilmente ci saranno complicazioni perché è quello che succede, ma almeno sembra in qualche modo fattibile divulgare questi dati!
• Dato che questo è ancora un modo abbastanza schifoso di inviare dati, ho cercato di più sui driver seriali USB. I moduli che ho cercato di carico ( usb-serial-simple, usb-debug, safe-serial) forniscono i / o errori. Non penso sia integrato nel kernel, perché non sono presenti dispositivi / dev / ttyUSB *.

Grazie per i suggerimenti di tutti fino ad ora --- So che questa non è nemmeno una domanda ben definita poiché non sapete in anticipo quali programmi / file possono essere letti o meno. Ancora aperto a suggerimenti migliori di questo approccio video!

AGGIORNAMENTO 3 : Novità

• Ho una webcam PS3 Eye e, dopo aver disabilitato il guadagno e l'esposizione automatici, sto leggendo con successo i dati dall'XPS, anche se con un errore di 1 byte al secondo. Questo è un grande successo --- i primi dati sono stati filtrati! Ma il tasso è troppo lento per far uscire il mio 820 KB in qualsiasi tempo ragionevole e il tasso di errore è troppo alto.

• Il problema è che la scrittura sul terminale è troppo lenta. Gli aggiornamenti dello schermo non sono nulla di simile all'istante, grazie (penso) alla lentezza urxvtdell'emulatore di terminale a cui ho accesso.
• Ho scoperto di avere accesso a un compilatore Rust sull'XPS. Ho riscritto lo script di trasmissione usando Rust per vedere se ciò avrebbe migliorato la velocità di aggiornamento del terminale, ma non ha aiutato.
• Poiché è improbabile che riesca ad aumentare il framerate, dovrò provare ad aumentare la quantità di dati che ottengo per frame. Il mio approccio attuale assomiglia a questo:

La metà destra è ancora un segnale di orologio, che si accende e si spegne per contrassegnare l'arrivo di nuovi fotogrammi. Ma la sinistra ora è una griglia in cui ogni cella è contrassegnata da un quadrato rosso nell'angolo, quindi la cella verde a destra e in basso dal quadrato rosso viene accesa e spenta per indicare un po '. I quadrati rossi dovrebbero consentire al computer ricevente di calibrare la posizione delle celle. Non ho ancora alcun dato in questo modo, ma è quello su cui sto lavorando.

• Qualcuno mi ha suggerito di cercare di scrivere codici QR anziché questi schemi di colori ad hoc. Analizzerò anche questo, e forse implementerò questo invece di questo approccio alla griglia. La correzione degli errori sarebbe una bella vittoria, oltre a poter utilizzare le librerie standard per la decodifica.
• Ho imparato che ho accesso a libasound (la libreria di suoni ALSA), ma non ai file di intestazione ad esso associati ( alsa/asoundlib.ho altro). Se qualcuno sa come utilizzare una libreria condivisa senza le intestazioni o può aiutarmi a scrivere solo l'intestazione giusta per farmi produrre output audio, allora potrei avere un modo basato su audio per ottenere i file.
• In alternativa, se qualcuno potesse aiutarmi a manipolare i dispositivi USB senza accesso a libusb, allora forse potrei fare qualcosa con quello?

Andando avanti!

AGGIORNAMENTO 4 : uscita audio prodotta!

L'utente Francesco Noferi ha svolto un ottimo lavoro aiutandomi a utilizzare la libreria ALSA menzionata nel precedente aggiornamento. Il compilatore C ha avuto un problema, ma usando il compilatore Rust sono stato in grado di usare l'FFI per chiamare direttamente libasound. Ora ho riprodotto un sacco di miei dati sull'audio e mi sembra musica per le orecchie! Devo ancora stabilire un vero canale di comunicazione, ma mi sento molto fiducioso. A questo punto il mio compito è fondamentalmente quello di implementare un modem, quindi se qualcuno ha qualche guida su buoni modi per farlo, sono tutto orecchi. Idealmente modulazione facile da implementare a mano e demodulazione per la quale esiste una libreria esistente che posso usare. Dal momento che questo può passare direttamente attraverso un cavo audio e non attraverso la rete telefonica, teoricamente possiamo fare molto meglio di 56kbps o qualunque sia lo standard nel passato, ma in pratica chissà cosa otterremo.

Grazie a tutti quelli che seguono qui e a / r / techsupportmacgyver e a / r / rust che hanno contribuito con così tanti suggerimenti eccellenti. Presto per implementare questo "modem" e poi finirò con un epilogo. Penso che potrei mettere il mio codice da qualche parte per altre persone disperate da utilizzare in futuro --- forse anche un repository di strani strumenti di esfiltrazione che sono facili da scrivere in una macchina morente a mano? Vedremo cosa succede.

AGGIORNAMENTO 5 : Mi ci è voluto molto tempo a lottare con ALSA e il mio economico dispositivo di acquisizione audio USB StarTech (nessuna linea incorporata sul laptop ricevente), e molti falsi inizi a provare a implementare il mio protocollo di trasmissione, ma alla fine sotto il consiglio di alcuni I miei amici appassionati di radioamatori hanno implementato il protocollo di linea RTTY a 150 baud, che in pratica mi dà circa 10 byte al secondo. Non è super veloce ma è abbastanza affidabile. E ho quasi finito di trasferire il mio file da 820 KB, verificato usando i checksum CRC32 (usando la funzionalità crc32 di Pythonzlibmodulo, a cui ho accesso). Quindi sto dichiarando la vittoria e voglio ringraziare ancora una volta! Trascorrerò un po 'più tempo a cercare altri file leggibili e che posso trasferire, ma le basi sono a posto. È stato divertente lavorare con tutti voi!

AGGIORNAMENTO FINALE :

Sulla macchina morente:

$ tar cf ./files
$ ./checksum.py ./files.tar 9999999
Part 1 checksum: -1459633665
$ ./zlib_compress.py ./files.tar
$ ./checksum.py ./files.tar.z 9999999
Part 1 checksum: -378365928
$ ./transmit_rust/target/debug/transmit ./files.tar.z
Transmitting files.tar.gz over audio using RTTY
Period size: 2048
Sample rate: 44100
Samples per bit: 294
Sending start signal.
Transmitting data.
nread: 2048
nread: 2048
...
nread: 2048
nread: 208
Transmission complete. Sending hold signal.

Sulla macchina di soccorso:

$ minimodem --rx -8 --rx-one -R 44100 -S 915 -M 1085 --startbits 3
            --stopbits 2 --alsa=1 150 -q > ./files.tar.z
$ ./checksum.py ./files.tar.z
Part 1 checksum: -378365928
$ ./zlib_decompress.py ./files.tar.z
$ ./checksum.py ./files.tar
Part 1 checksum: -1459633665

:-)

ecco un esempio di programma libasound con le definizioni appena sufficienti per ottenere un output wav 44.1k di base a 2 canali senza le intestazioni.

EDIT: In realtà non sono sicuro se scaricare direttamente i dati come wav funzionerebbe, poiché il rumore durante la registrazione potrebbe facilmente danneggiarlo, ma probabilmente puoi fare qualcosa come un'onda sinusoidale di bit ad alta frequenza che è più affidabile

EDIT2: se l'aplay è presente e funziona puoi anche usarlo e basta scrivere un programma che emette audio non elaborato e reindirizzarlo in aplay o qualsiasi cosa in grado di riprodurre audio

EDIT3: modificato per non utilizzare alcuna intestazione

se -lasound non viene compilato, aggiungi -L / path / where / libasound / is / located

/*
    gcc alsa_noheader.c -lasound
    cat stuff.wav | ./a.out
*/

typedef unsigned int uint;
typedef unsigned long ulon;

int printf(char*, ...);
void* malloc(long);
long read(int fd, void* buf, ulon count);

int snd_pcm_open(void**, char*, int, int);
ulon snd_pcm_hw_params_sizeof();
int snd_pcm_hw_params_any(void*, void*);
int snd_pcm_hw_params_set_access(void*, void*, int);
int snd_pcm_hw_params_set_format(void*, void*, int);
int snd_pcm_hw_params_set_channels(void*, void*, uint);
int snd_pcm_hw_params_set_rate_near(void*, void*, uint*, int*);
int snd_pcm_hw_params(void*, void*);
int snd_pcm_hw_params_get_period_size(void*, ulon*, int*);
long snd_pcm_writei(void*, void*, uint);
int snd_pcm_prepare(void*);
int snd_pcm_drain(void*);
int snd_pcm_close(void*);

int main(int argc, char* argv[])
{
    void* pcm;
    void* params;

    int rate;
    int nchannels;
    ulon frames;
    void* buf;
    int bufsize;
    long nread;

    snd_pcm_open(&pcm, "default", 0, 0);
    params = malloc(snd_pcm_hw_params_sizeof());
    snd_pcm_hw_params_any(pcm, params);

    /* 3 = rw_interleaved */
    snd_pcm_hw_params_set_access(pcm, params, 3);

    /* 2 = 16-bit signed little endian */
    snd_pcm_hw_params_set_format(pcm, params, 2);

    /* 2 channels */
    nchannels = 2;
    snd_pcm_hw_params_set_channels(pcm, params, nchannels);

    /* sample rate */
    rate = 44100;
    snd_pcm_hw_params_set_rate_near(pcm, params, &rate, 0);

    snd_pcm_hw_params(pcm, params);
    snd_pcm_hw_params_get_period_size(params, &frames, 0);

    bufsize = frames * nchannels * 2;
    buf = malloc(bufsize);

    /* read file from stdin */
    while (nread = read(0, buf, bufsize) > 0)
    {
        if (snd_pcm_writei(pcm, buf, frames) == -29)
        {
            printf("W: underrun\n");
            snd_pcm_prepare(pcm);
        }
    }

    snd_pcm_drain(pcm);
    snd_pcm_close(pcm);

    return 0;
}

Il tuo HDMI o qualsiasi altra porta di uscita dello schermo funziona? In tal caso, puoi utilizzare un dispositivo di acquisizione dello schermo per registrarlo come video ed elaborarlo in seguito. Quindi non essere limitato dal framerate della tua webcam.

Che ne dici di codificare i tuoi dati in modo esadecimale e di inviarli pagina per pagina al terminale?

È possibile aggiungere un prefisso con l'offset nel file binario in modo da poter rigenerare facilmente una pagina (per la correzione manuale?)

Quindi su un altro computer utilizzare alcuni software OCR per scansionare le pagine.

Il terminale 80x25 produrrebbe 1000 byte per pagina (meno uno spazio per il prefisso). Quindi in circa 1000 pagine potresti ottenere i tuoi dati. Anche a una pagina al secondo, sono meno di 20 minuti.

La codifica esadecimale è facile da scrivere e fornisce anche una forma grezza di correzione degli errori (ci sono solo 16 simboli validi).

puoi impostare una connessione di rete? ssh potrebbe essere un po 'troppo ma se puoi usare netcat su 2 macchine potresti essere in grado di trasferire dati. uno in modalità invio, uno in modalità ascolto. Se tutto ciò che devi fare è trasferire il testo, questa 'potrebbe' essere una soluzione.

modifica: non importa, leggi solo che hai perso anche la connessione di rete.

Si può essere in grado di e-mail se stessi da linea di comando, tra cui l'invio dei file.

Qualcosa di simile a:

$ mail -s "Hello World" user@yourmaildomain.com < /tmp/urgentFileToSave.txt

dovrebbe funzionare.

Alcuni altri esempi: http://www.binarytides.com/linux-mail-command-examples/

Python può accedere alla porta di uscita audio? Puoi provare a trasferire i dati usando quello - vedi questo o quello .

È possibile rimuovere l'SSD dalla propria macchina e dd/ photorec/ ecc. Su un'altra macchina funzionante.

Ecco il manuale di servizio Dell per il 9550 - consultare la sezione "Rimozione dell'unità a stato solido". Dopo aver rimosso l'unità, è possibile ottenere un contenitore USB M.2 esterno e collegare il disco a un altro computer per recuperare i dati.

Colpo lungo, ma alcune distro hanno protocolli radioamatoriali integrati. Uno comune è fldigi. Prova quale fldigi.

Se si dispone di questo o di un altro, convertono il testo in audio, in genere utilizzando alcune variazioni della digitazione a sfasamento. L'uscita viene trasmessa agli altoparlanti / alle cuffie e viene ricevuta da un computer stabile nella stessa stanza, elencato sul suo microfono. (Ciò elimina le radio del prosciutto che trasmettono e hanno ricevuto l'audio tramite le onde radio).

L'approccio dei codici QR potrebbe essere buono. Potresti inserirne il maggior numero possibile sullo schermo e aggiornarli non appena il tuo terminale lo consente. Quindi registra lo schermo dell'XPS con una videocamera (anziché utilizzare una webcam) e lavora semplicemente sulla decifrazione del video che hai salvato. Potrebbe essere utile utilizzare anche l'acquisizione al rallentatore.

Grande spettacolo :) Ho 1 suggerimento: puoi anche leggere i dati dallo schermo usando un diodo fotografico collegato alla scheda audio dell'altro computer