Puis-je sauvegarder ces documents sur une machine en train de mourir de l'oubli?
Tout d'abord, une confession: non, je n'ai pas fait les sauvegardes que je devrais avoir.
Deuxièmement, la situation:
J'ai un 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 sur un système de fichiers en lecture seule. Il se trouve que mon système de fichiers est en lecture seule à présent et qu'il y a i/o errors partout.
J'ai pu sauvegarder certains fichiers en m'envoyant un courrier électronique via un navigateur Web ouvert, mais cela s'est bloqué et je suis incapable de le relancer. Mais j'ai encore des dossiers d'intérêt ouverts dans un éditeur. Je n'arrive pas à enregistrer les fichiers où que ce soit, mais je peux en copier le contenu. Si seulement je pouvais trouver un moyen d’exfiltrer le contenu du fichier, je pourrais me sauver des mois de travail.
Mais il y a des limites horribles. J'ai tenté d'insérer un lecteur USB, mais aucun périphérique ne semble le représenter et la commande mount s'éteint avec une erreur de segmentation. Je peux essayer de ssh sur un autre ordinateur, mais j'obtiens une "erreur de bus" et ça meurt. ping, dmesg, ifconfig, aucune de ces méthodes ne fonctionne. Mais j'ai vim et less et ls et peux engendrer de nouvelles instances bash.
Non lynx, no firefox, no google-chrome. Il n'y a pas de lecteur de DVD.
Fondamentalement, il semble que mon disque SSD soit mort. Ou peut-être toute la carte mère. J'ai des documents de grande valeur encore en mémoire, j'ai une adresse IP et une connexion réseau, je peux exécuter quelques commandes aléatoires et 3500 autres sur le chemin que je pourrais essayer.
cat et gcc semblent fonctionner. Je peux écrire dans des fichiers dans/tmp. J'ai une instance ipython en cours d'exécution qui semble toujours fonctionner.
Alors ... 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'envisage pas? Comment pourrais-je obtenir ces fichiers de mon ordinateur en train de mourir?
Il doit y avoir un moyen.
UPDATE: Nouveautés:
- J'ai perdu ma connexion réseau à cause de ma propre stupidité.
- J'ai écrit un script Python pour remplacer
cpetcp -r - À moins que je ne trouve le moyen de créer une entrée
/devpour la carte SD ou pour les clés USB, mes meilleurs atouts pour extraire des données semblent être l'écran et éventuellement le câble haut-parleur/audio. - J'écris un script pour essayer de lire des fichiers et de sortir ceux qui sont lisibles.
Les suggestions sont toujours les bienvenues!
UPDATE 2: Nouveaux éléments:
- Sur l'ordinateur mourant, j'ai écrit un script Python qui lit un fichier à la fois et essaie de transmettre ces bits en faisant clignoter l'écran d'une couleur ou d'une autre. À l'heure actuelle, on essaie de créer un code à deux bits où rouge, vert, bleu et blanc représentent tous une paire de deux bits. Cela ne fonctionne pas très bien, cependant, je pourrais simplement passer à deux couleurs et faire un peu à la fois.
- Sur mon autre ordinateur portable (le vieux Thinkpad, que j'ai abandonné pour ce nouveau XPS), j'ai écrit un script qui lit à partir de la webcam à l'aide de la bibliothèque OpenCV Python. L'idée est de le décoder les codes envoyés par l'autre ordinateur. Le problème, c'est que le framerate de l'appareil photo est d'environ 15 images par seconde, ce qui signifie que si j'avais un transfert parfait et sans erreur, mon débit maximum serait de 30 bits par seconde, soit 225 octets par seconde. C'est 324k par jour.
- Sur le XPS mourant, je peux utiliser
tarpour regrouper les fichiers souhaités dans une archive unique, qui est de 1,7 Mo. Malheureusement,gzip,bzip2,xz,lzopet les autres utilitaires de compression ne sont pas disponibles. MAIS en utilisant le modulezlibde Python, je peux compresser ce fichier jusqu’à 820 Ko. Compte tenu de cette taille, je pourrais probablement recevoir cette chose dans quelques jours. - Comme cette méthode de transfert sera probablement très sujette aux erreurs, je vais implémenter des codes de Hamming sur le système XPS afin d'ajouter une correction d'erreur lors de la transmission des données.
- Il y aura probablement des complications parce que c'est ce qui se produit, mais au moins, il semble en quelque sorte faisable d'obtenir ces données!
- Comme cela reste un moyen assez fastidieux d’envoyer des données, je me suis plus intéressé aux pilotes série USB. Les modules que j'ai essayé de charger (
usb-serial-simple,usb-debug,safe-serial) donnent des erreurs d'E/S. Je ne pense pas non plus qu'il soit intégré au noyau, car il n'y a aucun périphérique/dev/ttyUSB * présent.
Merci pour les suggestions de chacun jusqu'à présent - je sais que ce n'est même pas une question bien définie car vous ne savez pas à l'avance quels programmes/fichiers peuvent être lus ou non. Toujours ouvert à de meilleures suggestions que cette approche vidéo!
UPDATE 3: Nouveautés les plus récentes
- J'ai une webcam PS3 Eye et, après avoir désactivé son gain et son exposition automatiques, je lis avec succès les données du XPS, bien qu'un taux erroné de 1 octet par seconde. C’est un grand succès: les premières données ont été exfiltrées! Mais le taux est trop lent pour obtenir mes 820 Ko dans un délai raisonnable, et le taux d'erreur est trop élevé.
- Le problème est que l'écriture sur le terminal est trop lente. Les mises à jour d'écran ne sont pas instantanées, merci (je pense) à la lenteur de l'émulateur de terminal
urxvtauquel j'ai accès. - J'ai découvert que j'ai accès à un compilateur Rust sur XPS. J'ai réécrit le script de transmission en utilisant Rust pour voir si cela améliorerait la vitesse d'actualisation du terminal, mais cela n'a pas aidé.
- Comme il est peu probable que je puisse augmenter le nombre d'images par seconde, je dois 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, clignotant pour marquer l'arrivée de nouvelles images. Mais la 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 de la place rouge clignote sur et en dehors pour indiquer un peu. Les carrés rouges doivent laisser l’ordinateur récepteur se calibrer à l’emplacement des cellules. Je n'ai pas encore de données, mais c'est ce sur quoi je travaille.
- Quelqu'un a suggéré que je cherche à écrire des codes QR au lieu de ces motifs de couleur ad hoc. Je vais aussi examiner cela, et peut-être mettre en place cette approche au lieu de cette approche par grille. La correction d'erreur constituerait une belle victoire, tout en permettant d'utiliser des bibliothèques standard pour le décodage.
- J'ai appris que j'ai accès à libasound (la bibliothèque de sons ALSA), mais pas aux fichiers d'en-tête qui lui sont associés (
alsa/asoundlib.hou autre). Si quelqu'un sait comment utiliser une bibliothèque partagée sans les en-têtes, ou peut me aider à écrire juste l'en-tête droit de me laisser produire une sortie audio, alors je pourrais avoir un moyen audio-basé d'obtenir les fichiers sur. - Sinon, si quelqu'un pouvait m'aider à manipuler les périphériques USB sans accès à libusb, je pourrais peut-être faire quelque chose avec ça?
Avancer!
UPDATE 4: sortie audio produite!
L’utilisateur Francesco Noferi a réalisé un travail remarquable 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 le FFI pour appeler directement dans libasound. J'ai maintenant joué un tas de mes données sur audio et ça sonne comme de la musique à mes oreilles! Encore faut-il établir un véritable canal de communication, mais je me sens très optimiste. À ce stade, mon travail consiste essentiellement à mettre en place un modem. Si quelqu'un a des conseils sur la bonne façon de le faire, je suis tout ouïe. Idéalement, une modulation facile à mettre en œuvre manuellement et une démodulation pour laquelle il existe une bibliothèque que je peux utiliser. Puisque cela peut aller directement au-dessus d'un câble audio et non par le réseau téléphonique, théoriquement nous pouvons faire beaucoup mieux que 56kbps ou quelle que soit la norme était de retour dans la journée, mais en pratique, qui sait ce que nous allons obtenir .
Merci à tous ceux qui nous ont suivis ici et qui ont apporté tant d’excellentes suggestions: at/r/techsupportmacgyver et at/r/Rust . Je vais bientôt faire installer ce "modem", puis je terminerai avec un épilogue. Je pense que je pourrais mettre mon code quelque part pour d'autres gens désespérés d'utiliser à l'avenir --- peut-être même un dépôt d'outils de exfiltration étranges qui sont faciles à taper dans une machine en train de mourir à la main? Nous allons voir ce qui se passe.
UPDATE 5 _ : Il m'a fallu beaucoup de temps pour lutter contre ALSA et mon périphérique de capture audio USB StarTech bon marché (aucune ligne intégrée sur l'ordinateur portable destinataire), et beaucoup de faux commencent à essayer de rouler mon propre protocole de transmission, mais finalement, sous les conseils de certains de mes amis passionnés de radio Ham, j’ai mis en œuvre le protocole de ligne RTTY fonctionnant à 150 bauds, ce qui me donne en pratique environ 10 octets par seconde. Ce n'est pas super rapide mais c'est assez fiable. Et je suis presque fait transférer mon fichier 820KB, vérifié à l'aide CRC32 checksums (en utilisant la fonctionnalité de crc32 à partir du module zlib Python, que j'ai accès). Donc, je déclare la victoire et tiens à remercier encore une fois! Je vais passer un peu plus de temps à trouver d'autres fichiers lisibles et que je peux transférer, mais les bases sont en place. C'est amusant de travailler avec vous tous!
FINAL UPDATE:
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
:-)
voici un exemple de programme libasound avec juste assez de définitions pour obtenir une sortie wav 44.1k de base à 2 canaux sans les en-têtes.
EDIT: En fait, je ne suis pas sûr que le dumping direct des données en tant que wav fonctionnerait, car le bruit lors de l’enregistrement pourrait facilement l’endommager, mais vous pouvez probablement faire quelque chose comme une onde sinusoïdale de bits à haute fréquence qui est plus fiable
EDIT2: si aplay est présent et fonctionne, vous pouvez également l'utiliser et simplement écrire un programme qui produit un son brut et le rediriger vers un jeu ou tout autre élément pouvant lire de l'audio.
EDIT3: modifié pour ne plus utiliser aucun en-tête
si -lasound ne compile pas, ajoutez -L/chemin/où/libasound/est/est situé
/*
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;
}
Votre HDMI ou tout autre port de sortie d'affichage fonctionne-t-il? Si tel est le cas, vous pouvez utiliser un périphérique de capture d'écran pour l'enregistrer en tant que vidéo et le traiter ultérieurement. Donc, ne pas être limité par le framerate de votre webcam.
Que diriez-vous de coder vos données au format hexadécimal et de les envoyer page par page au terminal?
Vous pouvez ajouter un préfixe avec le décalage dans le binaire afin de pouvoir facilement régénérer une page (pour une correction manuelle?)
Puis, sur un autre ordinateur, utilisez un logiciel OCR pour numériser les pages.
Un terminal 80x25 donnerait 1000 octets par page (moins d’espace pour le préfixe). Donc, en environ 1000 pages, vous pouvez sortir vos données. Même à une page par seconde, c'est moins de 20 minutes.
Le codage hexadécimal est facile à écrire et fournit également une forme brute de correction d'erreur (il n'y a que 16 symboles valides).
pouvez-vous configurer une connexion réseau? ssh est peut-être un peu trop mais si vous pouvez utiliser netcat sur deux machines, vous pourrez peut-être transférer des données. un en mode d'envoi, un en mode d'écoute. Si tout ce que vous avez à faire est de transférer du texte, alors ceci pourrait être une solution.
edit: tant pis, il suffit de lire que vous avez également perdu votre connexion réseau ..
Un long plan, mais certaines distributions ont des protocoles intégrés de radioamateur. Un commun est fldigi. Essayez quel fldigi.
Si vous avez ceci ou un autre, ils convertissent le texte en audio, en utilisant généralement une variante de la manipulation par décalage de phase. La sortie est transmise à vos haut-parleurs/casque et est reçue par un ordinateur stable dans la même pièce, répertoriée dans son microphone. (Ceci élimine les radioamateurs qui transmettent et reçoivent le son sur les ondes).
L'approche des codes QR pourrait être bonne. Vous pouvez en afficher autant que possible à l'écran et les actualiser dès que votre terminal vous le permet. Enregistrez ensuite l'écran du XPS avec une caméra (au lieu d'utiliser une webcam) et travaillez simplement à déchiffrer la vidéo que vous avez sauvegardée. Il pourrait être utile d’utiliser la capture au ralenti même.
Grand spectacle :) J'ai une suggestion: vous pouvez également lire les données à l'écran à l'aide d'une photodiode connectée à la carte son de l'autre ordinateur.
Vous pouvez être en mesure de vous envoyer un courriel à partir de la ligne de commande, y compris l'envoi de fichiers.
Quelque chose comme:
$ mail -s "Hello World" [email protected] < /tmp/urgentFileToSave.txt
devrait marcher.
Quelques exemples supplémentaires: http://www.binarytides.com/linux-mail-command-examples/
Vous pouvez supprimer le disque SSD de votre machine et la variable dd/photorec/etc sur une autre machine en fonctionnement.
Voici le manuel de réparation Dell pour le 9550 - voir la section "Retrait du lecteur SSD". Une fois le lecteur retiré, vous pouvez obtenir un boîtier externe M.2 USB et attacher le disque à un autre ordinateur pour récupérer vos données.