Primeiro, uma confissão: não, não fiz os backups que deveria ter.
Segundo, a situação:
Eu tenho um Dell XPS 9550 com um disco de estado sólido executando o Fedora 25 .
Eu estava trabalhando em um arquivo e tentei salvá-lo quando me disseram que estava tentando salvar em um sistema de arquivos somente leitura . Acontece que meu sistema de arquivos é somente leitura agora e há erros de E / S em todo o lugar.
Consegui salvar alguns arquivos enviando-os por e-mail para mim mesmo por meio de um navegador da Web aberto, mas isso travou e não consigo relançá-lo. Mas ainda tenho arquivos de interesse abertos em um editor. Não consigo salvar os arquivos em nenhum lugar, mas posso copiar o conteúdo deles. Se eu conseguisse encontrar uma maneira de filtrar o conteúdo do arquivo, poderia me salvar meses de trabalho.
Mas existem algumas limitações horríveis. Tentei inserir uma unidade USB, mas nenhum dispositivo parece representá-la e o mount
comando morre com um segfault. Posso tentar ssh para outro computador, mas recebo "erro de barramento" e ele morre. ping
, dmesg
, ifconfig
, Nenhum desses trabalhos. Mas eu tenho vim
e less
e ls
e pode gerar novas bash
instâncias.
Não lynx
, não firefox
, não google-chrome
. Não há unidade de DVD.
Basicamente, parece que meu SSD morreu. Ou talvez toda a placa-mãe. Ainda tenho documentos de grande valor na memória, tenho um endereço IP e uma conexão de rede, posso executar alguns comandos aleatórios e ter mais 3500 no caminho que poderia tentar.
cat
e gcc
parece funcionar. Eu posso gravar em arquivos em / tmp. Eu tenho uma ipython
instância em execução que ainda parece funcionar.
Então ... o que eu tentei até agora falhou. Mas sinto que ainda existem mil possibilidades. O que não estou considerando? Como eu poderia obter esses arquivos do meu computador que estava morrendo?
Deve haver um caminho.
UPDATE : Novos itens:
- Perdi minha conexão de rede devido à minha própria estupidez.
- Eu escrevi um script Python para substituir
cp
ecp -r
- A menos que eu encontre alguma maneira de criar uma
/dev
entrada para o cartão SD ou para unidades USB, minhas melhores apostas para obter dados parecem ser a tela e, possivelmente, os alto-falantes / cabo de áudio. - Estou escrevendo um script para tentar ler arquivos e produzir quais são legíveis.
Sugestões ainda muito bem-vindas!
ATUALIZAÇÃO 2 : coisas mais recentes:
- No computador que estava morrendo, escrevi um script Python que lê um arquivo pouco a pouco e tenta transmitir esses bits piscando a tela de uma cor ou de outra. No momento, ele está tentando criar um código de dois bits, onde vermelho, verde, azul e branco representam um par de dois bits. Porém, isso não está funcionando tão bem, então eu posso mudar para duas cores e fazer um pouco de cada vez.
- No meu outro laptop (o velho e confiável Thinkpad que desisti desse novo XPS quente), escrevi um script que lê da webcam usando a biblioteca OpenCV Python. A idéia é decodificar os códigos enviados pelo outro computador. O problema é que a taxa de quadros da câmera é algo como 15 quadros por segundo, o que significa que, se eu tivesse uma transferência perfeita e sem erros, minha taxa máxima de dados seria de 30 bits por segundo, ou seja, 225 bytes por segundo. Isso é 324k por dia.
- No XPS moribundo, posso usar
tar
para compactar os arquivos desejados em um único arquivo morto , que é de 1,7 MB. Infelizmente,gzip
,bzip2
,xz
,lzop
e qualquer que seja a compressão utilitários estão indisponíveis. MAS, usando ozlib
módulo do Python, posso compactar esse arquivo para 820 KB. Dado esse tamanho, eu provavelmente poderia enviar essa coisa em alguns dias. - Como esse método de transferência provavelmente será muito suscetível a erros, implementarei os códigos Hamming no XPS para adicionar alguma correção de erro ao transmitir os dados.
- É provável que ocorram complicações porque é isso que acontece, mas pelo menos parece viável obter esses dados!
- Como essa ainda é uma maneira bem complicada de enviar dados, observei mais os drivers seriais USB. Os módulos I já tentou carregar (
usb-serial-simple
,usb-debug
,safe-serial
) dar i / o erros. Também não acho que ele esteja embutido no kernel, porque não há dispositivos / dev / ttyUSB * presentes.
Obrigado pelas sugestões de todos até agora - eu sei que essa nem é uma pergunta bem definida, pois vocês não sabem de antemão quais programas / arquivos podem ser lidos ou não. Ainda aberto a sugestões melhores do que esta abordagem em vídeo!
ATUALIZAÇÃO 3 : Novidades
- Eu tenho uma webcam PS3 Eye e, depois de desativar o ganho e a exposição automáticos, estou lendo com sucesso os dados do XPS, embora com 1 byte por segundo errôneo. Este é um grande sucesso - os primeiros dados exfiltrados! Mas a taxa é muito lenta para liberar meus 820 KB em qualquer tempo razoável e a taxa de erro é muito alta.
- O problema é que a gravação no terminal é muito lenta. As atualizações de tela não são instantâneas, graças (acho) à lentidão do
urxvt
emulador de terminal ao qual tenho acesso. - Descobri que tenho acesso a um compilador Rust no XPS. Reescrevi o script de transmissão usando o Rust para ver se isso melhoraria a velocidade de atualização do terminal, mas não ajudou.
- Como é improvável que eu possa aumentar a taxa de quadros, terei que tentar aumentar a quantidade de dados que recebo por quadro. Minha abordagem atual é mais ou menos assim:
A metade direita ainda é um sinal de relógio, piscando para desligar e marcar a chegada de novos quadros. Mas a esquerda agora é uma grade em que cada célula é marcada por um quadrado vermelho no canto e, em seguida, a célula verde à direita e para baixo do quadrado vermelho fica intermitente para indicar um pouco. Os quadrados vermelhos devem deixar o computador receptor calibrar onde as células estão localizadas. Ainda não tenho dados desse tipo, mas é nisso que estou trabalhando.
- Alguém sugeriu que eu escrevesse códigos QR em vez desses padrões de cores ad hoc. Também vou analisar isso e talvez implementar isso em vez dessa abordagem de grade. A correção de erros seria uma boa vitória, além de poder usar bibliotecas padrão para decodificar.
- Aprendi que tenho acesso ao libasound (a biblioteca de sons ALSA), mas não aos arquivos de cabeçalho associados a ele (
alsa/asoundlib.h
ou o que seja). Se alguém souber como fazer uso de uma biblioteca compartilhada sem os cabeçalhos ou puder me ajudar a escrever o cabeçalho certo para produzir saída de áudio, eu poderia ter uma maneira baseada em áudio de obter os arquivos. - Como alternativa, se alguém pudesse me ajudar a manipular os dispositivos USB sem acesso ao libusb, talvez eu pudesse fazer algo com isso?
Avançando!
ATUALIZAÇÃO 4 : saída de áudio produzida!
O usuário Francesco Noferi fez um ótimo trabalho me ajudando a utilizar a biblioteca ALSA mencionada na atualização anterior. O compilador C teve um problema, mas usando o compilador Rust, pude usar o FFI para chamar diretamente libasound
. Agora, toquei vários dados em áudio e isso soa como música para os meus ouvidos! Ainda preciso estabelecer um canal de comunicação real, mas estou com muita esperança. Neste ponto, meu trabalho é basicamente implementar um modem; portanto, se alguém tiver alguma orientação sobre boas maneiras de fazer isso, sou todo ouvidos. Idealmente, modulação fácil de implementar manualmente e desmodulação para a qual existe uma biblioteca existente que eu possa usar. Como isso pode passar diretamente por um cabo de áudio e não pela rede telefônica, teoricamente podemos fazer muito melhor do que 56kbps ou qualquer que seja o padrão anterior, mas na prática quem sabe o que obteremos.
Obrigado a todos que estão acompanhando aqui e em / r / techsupportmacgyver e em / r / rust contribuindo com tantas sugestões excelentes. Em breve, esse "modem" será implementado e depois terminarei com um epílogo. Acho que posso colocar meu código em algum lugar para outras pessoas desesperadas usarem no futuro - talvez até mesmo um repositório de ferramentas estranhas de exfiltração que sejam fáceis de digitar manualmente em uma máquina que está morrendo? Veremos o que acontece.
ATUALIZAÇÃO 5 : Levei muito tempo lutando com a ALSA e meu barato dispositivo de captura de áudio USB StarTech (nenhuma linha embutida no laptop receptor), e muitas falsas tentativas tentando executar meu próprio protocolo de transmissão, mas finalmente sob o conselho de alguns Meus amigos entusiastas do rádio amador Eu implementei o protocolo de linha RTTY rodando a 150 baud, o que na prática me dá cerca de 10 bytes por segundo. Não é super rápido, mas é bastante confiável. E estou quase terminando de transferir meu arquivo de 820 KB, verificado usando as somas de verificação CRC32 (usando a funcionalidade crc32 do Python'szlib
módulo, ao qual tenho acesso). Estou declarando vitória e quero agradecer mais uma vez! Vou dedicar mais tempo a encontrar outros arquivos legíveis e que possam ser transferidos, mas a base está em vigor. Foi divertido trabalhar com todos vocês!
ATUALIZAÇÃO FINAL :
Na máquina moribunda:
$ 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.
Na máquina de resgate:
$ 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
:-)
python -m SimpleHTTPServer
. Agora você está compartilhando os arquivos através de um servidor http na porta 8000 . Abra um navegador em outro dispositivo na mesma rede e digite o seguinte: http://<IP address>:8000
e comece a baixar tudo o que puder.