Puis-je sauver ces documents de l'oubli sur une machine mourante ?

Tout d'abord, un aveu : non, je n'ai pas fait les sauvegardes que j'aurais dû faire.

Deuxièmement, la situation :

J'ai un ordinateur Dell XPS 9550 avec un disque à l'état solide en cours d'exécution Fedora 25 .

Je travaillais sur un fichier et j'ai essayé de l'enregistrer quand on m'a dit que j'essayais de l'enregistrer dans un fichier de type système de fichiers en lecture seule . Il s'avère que mon système de fichiers est maintenant en lecture seule et qu'il y a des erreurs d'entrée/sortie partout.

J'ai pu sauvegarder certains des fichiers en me les envoyant par courrier électronique via un navigateur web ouvert, mais celui-ci s'est bloqué et je ne parviens pas à le relancer. Mais j'ai toujours des fichiers intéressants ouverts dans un éditeur. Je ne peux enregistrer les fichiers nulle part, mais je peux copier leur contenu. Si seulement je pouvais trouver un moyen d'exfiltrer le contenu des fichiers, je pourrais m'épargner des mois de travail.

Mais il y a d'horribles limitations. J'ai tenté d'insérer une clé USB, mais aucun périphérique ne semble la représenter, et l'écran d'accueil de l'ordinateur s'affiche. mount se termine par une erreur de segmentation. Je peux essayer de me connecter en ssh à un autre ordinateur, mais j'obtiens "bus error" et la commande s'arrête. ping , dmesg , ifconfig Aucune de ces méthodes ne fonctionne. Mais j'ai vim y less y ls et peut engendrer de nouveaux bash instances.

Non lynx , non firefox , non google-chrome . Il n'y a pas de lecteur de DVD.

Il semblerait que mon disque dur SSD soit mort. Ou peut-être la carte mère entière. J'ai des documents de grande valeur encore en mémoire, j'ai une adresse IP et une connexion réseau, je peux lancer quelques commandes au hasard et j'en ai 3500 autres sur le chemin que je pourrais essayer.

cat y gcc semblent fonctionner. Je peux écrire dans les fichiers de /tmp. J'ai un ipython qui semble toujours fonctionner.

Donc... ce que j'ai essayé jusqu'à présent a échoué. Mais j'ai l'impression qu'il y a encore mille possibilités. Qu'est-ce que je n'ai pas envisagé ? Comment pourrais-je récupérer ces fichiers sur mon ordinateur mourant ?

Il doit y avoir un moyen.

アップデイト : Nouveautés :

• J'ai perdu ma connexion réseau à cause de ma propre stupidité.
• J'ai écrit un script en Python pour remplacer cp y cp -r
• À moins que je ne trouve un moyen de créer un /dev pour la carte SD, ou pour les clés USB, mes meilleures chances d'obtenir des données semblent être l'écran et éventuellement les haut-parleurs/le câble audio.
• J'écris un script pour essayer de lire des fichiers et indiquer ceux qui sont lisibles.

Les suggestions sont toujours les bienvenues !

MISE À JOUR 2 : Des choses plus récentes :

• Sur l'ordinateur mourant, j'ai écrit un script Python script qui lira un fichier bit par bit et tentera de transmettre ces bits en faisant clignoter l'écran d'une couleur ou d'une autre. Pour l'instant, il essaie de faire un code à deux bits où le rouge, le vert, le bleu et le blanc représentent tous une paire de deux bits. Cela ne fonctionne pas très bien, alors je vais peut-être passer à deux couleurs et faire clignoter un bit à la fois.
• Sur mon autre ordinateur portable (le bon vieux Thinkpad que j'ai abandonné pour ce nouveau XPS tout chaud), j'ai écrit un script qui lit les données de la webcam en utilisant la bibliothèque OpenCV Python. L'idée est de décoder les codes envoyés par l'autre ordinateur. Le problème est que le taux de rafraîchissement de la caméra est d'environ 15 images par seconde, ce qui signifie que si j'avais un transfert parfait, sans erreur, mon taux de données maximum serait de 30 bits par seconde, c'est-à-dire 225 octets par seconde. Cela représente 324 000 par jour.
• Sur le XPS mourant, je peux utiliser tar pour regrouper les fichiers souhaités dans une seule archive de 1,7 Mo. Malheureusement, ce n'est pas le cas, gzip , bzip2 , xz , lzop et tout autre utilitaire de compression non disponible. MAIS en utilisant la fonction zlib module Je peux compresser ce fichier à 820KB. Compte tenu de cette taille, je pourrais probablement l'envoyer en quelques jours.
• Comme cette méthode de transfert sera probablement très sujette aux erreurs, je vais mettre en œuvre des codes de Hamming sur le XPS pour ajouter une correction d'erreur lors de la transmission des données.
• Il est probable qu'il y aura des complications, car c'est ce qui se passe, mais au moins, il semble possible de diffuser ces données !
• Comme il s'agit encore d'une méthode assez peu efficace pour envoyer des données, je me suis penché sur les pilotes série USB. Les modules que j'ai essayé de charger ( usb-serial-simple , usb-debug , safe-serial ) provoquent des erreurs d'entrée/sortie. Je ne pense pas non plus que ce soit intégré au noyau, car il n'y a pas de périphériques /dev/ttyUSB* présents.

Merci pour les suggestions de chacun jusqu'à présent - je sais que ce n'est même pas une question bien définie puisque vous ne savez pas à l'avance quels programmes/fichiers peuvent être lus ou non. Je reste ouvert à de meilleures suggestions que cette approche vidéo !

MISE À JOUR 3 : Nouveautés

• J'ai acheté une webcam PS3 Eye et, après avoir désactivé son gain et son exposition automatiques, je parviens à lire les données du XPS, bien qu'à une vitesse erronée de 1 octet par seconde. C'est un grand succès - les premières données exfiltrées ! Mais le débit est trop lent pour que mes 820KB soient lus dans un délai raisonnable, et le taux d'erreur est trop élevé.

• Le problème est que l'écriture dans le terminal est trop lente. Les mises à jour de l'écran sont loin d'être instantanées, grâce (je pense) à la lenteur de la fonction urxvt émulateur de terminal auquel j'ai accès.
• J'ai découvert que j'avais accès à un compilateur Rust sur le XPS. J'ai réécrit le script de transmission script en utilisant Rust pour voir si cela améliorerait la vitesse de rafraîchissement du terminal, mais cela n'a pas aidé.
• Comme il est peu probable que je puisse augmenter le taux de rafraîchissement, je vais devoir essayer d'augmenter la quantité de données que j'obtiens par image. Mon approche actuelle ressemble à ceci :

La moitié droite est toujours un signal d'horloge, qui clignote pour marquer l'arrivée de nouvelles images. Mais la partie gauche est maintenant une grille où chaque cellule est marquée par un carré rouge dans le coin, puis la cellule verte à droite et en bas du carré rouge est allumée et éteinte pour indiquer un bit. Les carrés rouges devraient permettre à l'ordinateur récepteur de calibrer l'emplacement des cellules. Je n'ai pas encore obtenu de données de cette manière, mais c'est ce à quoi je travaille.

• Quelqu'un m'a suggéré d'écrire des codes QR au lieu de ces motifs de couleur ad hoc. Je vais également me pencher sur cette question et peut-être la mettre en œuvre au lieu de cette approche par grille. La correction des erreurs serait une bonne chose, de même que la possibilité d'utiliser des bibliothèques standard pour décoder.
• J'ai appris que j'avais accès à libasound (la bibliothèque de sons ALSA), mais pas aux fichiers d'en-tête qui lui sont associés ( alsa/asoundlib.h ou autre). Si quelqu'un sait comment utiliser une bibliothèque partagée sans les en-têtes, ou peut m'aider à écrire le bon en-tête pour me permettre de produire une sortie audio, alors je pourrais avoir un moyen audio de sortir les fichiers.
• Sinon, si quelqu'un pouvait m'aider à manipuler les périphériques USB sans avoir accès à libusb, je pourrais peut-être faire quelque chose avec ça ?

Aller de l'avant !

MISE À JOUR 4 Sortie audio : sortie audio produite !

L'utilisateur Francesco Noferi a fait un excellent travail en m'aidant à utiliser la bibliothèque ALSA mentionnée dans la mise à jour précédente. Le compilateur C avait un problème, mais en utilisant le compilateur Rust, j'ai pu utiliser la FFI pour appeler directement dans libasound . J'ai maintenant joué un grand nombre de mes données en audio et cela sonne comme de la musique à mes oreilles ! Il reste à établir un véritable canal de communication, mais j'ai bon espoir. A ce stade, mon travail consiste essentiellement à mettre en place un modem, donc si quelqu'un a des conseils sur les bonnes façons de le faire, je suis tout ouïe. Idéalement une modulation facile à implémenter à la main et une démodulation pour laquelle il existe une bibliothèque que je peux utiliser. Je n'ai pas besoin d'un modem, car il peut passer directement par un câble audio et non par le réseau téléphonique, théoriquement nous pouvons faire beaucoup mieux que 56kbps ou que la norme de l'époque, mais dans la pratique, qui sait ce que nous obtiendrons.

Merci à tous ceux qui nous suivent ici et at /r/techsupportmacgyver y at /r/rust qui apporte tant d'excellentes suggestions. Je vais bientôt mettre en place ce "modem" et je terminerai par un épilogue. Je pense que je pourrais mettre mon code quelque part pour que d'autres personnes désespérées puissent l'utiliser à l'avenir - peut-être même un dépôt d'outils d'exfiltration bizarres qui sont faciles à taper à la main dans une machine mourante ? Nous verrons ce qui se passera.

MISE À JOUR 5 : Il m'a fallu beaucoup de temps pour me débattre avec ALSA et mon périphérique de capture audio USB StarTech bon marché (pas d'entrée de ligne intégrée sur l'ordinateur portable récepteur), et de nombreux faux départs en essayant de mettre au point mon propre protocole de transmission, mais finalement, sur les conseils de quelques amis enthousiastes de la radio amateur, j'ai mis en œuvre le protocole d'échange de données. Protocole de ligne RTTY à 150 bauds, ce qui, en pratique, me donne environ 10 octets par seconde. Ce n'est pas très rapide, mais c'est assez fiable. Et j'ai presque fini de transférer mon fichier de 820 Ko, vérifié à l'aide de sommes de contrôle CRC32 (en utilisant la fonctionnalité crc32 de la bibliothèque Python zlib auquel j'ai accès). Je crie donc victoire et je tiens à vous remercier encore une fois ! Je vais passer un peu plus de temps à trouver d'autres fichiers qui sont lisibles et que je peux transférer, mais la base est en place. J'ai eu beaucoup de plaisir à travailler avec vous tous !

MISE À JOUR FINALE :

Sur la machine à mourir :

$ 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.

Sur la machine de secours :

$ 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

:-)