É possível recuperar o conteúdo de um script bash em execução da RAM

Por acidente, sobrescrevi um script bash muito complexo, onde tentei implementar o escopo e o encadeamento de maneira organizada.

Agora, o mesmo script ainda está em execução, mas o arquivo não existe mais, a pergunta é: É possível percorrer o RAM e encontrar a representação gráfica do próprio arquivo?

Outro problema é: não consigo encontrar o arquivo / dev / mem ou / dev / kmem, já tentei cumprimentá-lo pelo conteúdo.

Para o ambiente: É um host da máquina debian / sid (vps) em vpsfx.com

root @ heisenberg: ~ # ls -a / dev
. kmsg ptyp2 ptyp9 aleatório tty1 tty5 ttyp2 ttyp9 urandom
.. log ptyp3 ptypa shm tty10 tty6 ttyp3 ttypa xconsole
.udev null ptyp4 ptypb stderr tty11 tty7 ttyp4 ttypb zero
char ptmx ptyp5 ptypc stdin tty12 tty8 ttyp5 ttypc
pts do console ptyp6 ptypd stdout tty2 tty9 ttyp6 ttypd
fd ptyp0 ptyp7 ptype tty3 ttyp0 ttyp7 ttype
ptyp1 completo ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf

linux bash memory

— Thomas Nordquist
fonte

Respostas:

Dê uma olhada em / proc / $ PID / fd. Lá, você deve ter todos os descritores de arquivo abertos pelo processo, incluindo o próprio script. Apenas cat $FD > /tmp/yourscript.shdeve ser suficiente para recuperá-lo.

— Diego Woitasen
fonte

Votei positivamente nessa resposta, apesar de ela não responder de fato à pergunta que o OP fez. O OP perguntou como recuperar o script da RAM , não do sistema de arquivos. Essa resposta usa o sistema de arquivos, contando com o fato de que o arquivo de script não é finalmente desvinculado até que a contagem final de referência chegue a zero.

— Jonathan Ben-Avraham

O sistema de arquivos proc reside apenas na RAM e todo mundo já o montou.

— Diego Woitasen

O /procFS não reside na RAM. De fato, ele não reside em lugar algum . Consulte unix.stackexchange.com/questions/74713/… . Embora você possa obter o fd de /proc, cato fd lê o arquivo do fs, não da RAM. É verdade que você excluiu o arquivo, reduzindo a contagem de referências do inode, e ninguém mais pode vê-lo agora, mas ele não é realmente excluído do fs até que o processo que executa o script o feche. Consulte stackoverflow.com/questions/2028874/… .

— Jonathan Ben-Avraham

Sim você está certo. O arquivo em si é lido no sistema de arquivos do disco. / proc existe na RAM, não é como um ramdisk, mas as informações estão na RAM. Com exceção de / proc / $ PID / fd e pode ser outro. De qualquer forma, o @Thomas Nordquist quer recuperar o arquivo, e esta é a maneira mais fácil.

— Diego Woitasen

Trabalhou para mim, depois de alguns trys eu encontrei o descritor de arquivo correto, finalmente, eu posso fechar o processo e continuar

— Thomas Nordquist

Supondo que o OP realmente significasse a partir da RAM e de nenhuma maneira possível , e assumindo que o processo em que o script foi executado tenha um limite de zero de arquivo principal (que geralmente é a configuração padrão cat /proc/PID/limits), você precisará se conectar ao processo e defina o limite do núcleo como um valor grande o suficiente para incluir a imagem do processo e use o sinal ABRT para gerar o arquivo principal ou use uma ferramenta gdbque possa ser conectada a um processo e gerar uma imagem principal do processo a partir da RAM.

Instalar gdb

Em alguns shell com a mesma propriedade do script em execução ou da propriedade raiz:

Fazer ps axpara encontrar o ID do processo (PID)
gdb -p PID

Observe que isso impedirá a execução do processo de continuar, mas não a removerá da tabela de processos.

No gdb, emita o comando generate-core-file

O gdb deve responder com algo como Saved corefile core.15113, assumindo que o PID seja 15113.

No gdb, emita o comando detach

Seu script continuará (continuando) em execução.

No gdb, emita o comando quit
Com casca, execute strings core.15113 > my_script.sh

Abra o my_script.shem algum editor. O texto do seu script deve estar no final do arquivo antes da seção do ambiente. Use o editor para raspar as seções antes e depois do script.

Teste esta solução em outro script antes de usá-la em seu script de prêmio. YMMV.

A sequência é assim:

yba@tavas:~$ gdb -p 15113
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 15113
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libtinfo.so.5
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007feaf4b4c7be in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) generate-core-file
Saved corefile core.15113
(gdb) detach
Detaching from program: /bin/bash, process 15113
(gdb) quit
yba@tavas:~$

— Jonathan Ben-Avraham
fonte

Esta solução também funciona, mas aqui estão algumas escavações, obrigado por sua ajuda

— Thomas Nordquist

Esta é a solução que funcionou para mim! Eu havia substituído o arquivo original e esperava que ainda estivesse na memória. O arquivo aberto (outra resposta) apontou para o arquivo atualizado. Isso me salvou!

— saveman71

dd a partição do disco rígido em partes sobrepostas e o binário grep para partes do script. se você tiver sorte, escreva esses pedaços no diretório temporário do ram, para que nele possam salvar os ciclos de gravação do disco rígido ou do ssd. não, não é uma solução 'de ram'. esteja ciente do fato de que ao ler os scripts de byte a disco por byte pode estar no formato utf-8 (ou similar), então os parâmetros grep também precisam ser adaptados.

— Michael Grieswald
fonte