¿Es posible recuperar el contenido de un script bash en ejecución desde la RAM

18

Por accidente, he sobrescrito un script de bash muy complejo, donde traté de implementar el alcance y el enhebrado de manera ordenada.

Ahora el mismo script aún se está ejecutando pero el archivo ya no existe, la pregunta es: ¿Es posible escanear a través del ram y encontrar la representación del archivo en sí?

Otro problema es: no puedo encontrar el archivo / dev / mem o / dev / kmem, ya intenté buscar el contenido.

Para el medio ambiente: es un host de máquina debian / sid (vps) en vpsfx.com

root @ heisenberg: ~ # ls -a / dev
. kmsg ptyp2 ptyp9 aleatorio tty1 tty5 ttyp2 ttyp9 urandom
.. log ptyp3 ptypa shm tty10 tty6 ttyp3 ttypa xconsole
.udev nulo ptyp4 ptypb stderr tty11 tty7 ttyp4 ttypb cero
char ptmx ptyp5 ptypc stdin tty12 tty8 ttyp5 ttypc
consola pts ptyp6 ptypd stdout tty2 tty9 ttyp6 ttypd
fd ptyp0 ptyp7 ptype tty tty3 ttyp0 ttyp7 ttype
completo ptyp1 ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf
linux bash memory Thomas Nordquist
fuente

Respuestas:

17

Echa un vistazo a / proc / $ PID / fd. Allí debe tener todos los descriptores de archivo abiertos por el proceso, incluido el script en sí. Solo cat $FD > /tmp/yourscript.shdebería ser suficiente para recuperarlo.

Diego Woitasen
fuente
1
Voté esta respuesta a pesar de que en realidad no responde la pregunta que hizo el OP. El OP preguntó cómo recuperar el script desde la RAM , no desde el sistema de archivos. Esta respuesta utiliza el sistema de archivos, basándose en el hecho de que el archivo de script finalmente no se desvincula hasta que el recuento de referencia final llega a cero.
Jonathan Ben-Avraham
1
El sistema de archivos proc reside solo en RAM y casi todo el mundo lo tiene montado.
Diego Woitasen
2
El /procfs no reside en la RAM. De hecho, no reside en ningún lado . Ver unix.stackexchange.com/questions/74713/… . Aunque puede obtener el fd /proc, cating fd lee el archivo de fs, no RAM. Es cierto, eliminó el archivo, reduciendo el recuento de referencia de inodo, y nadie más puede verlo ahora, pero en realidad no se elimina de la fs hasta que el proceso que ejecuta el script lo cierra. Ver stackoverflow.com/questions/2028874/… .
Jonathan Ben-Avraham
Sí, tiene usted razón. El archivo en sí se lee del sistema de archivos del disco. / proc existe en RAM, no es como un disco RAM, pero la información está en RAM. Con la excepción de / proc / $ PID / fd y puede ser otro. De todos modos, @Thomas Nordquist quiere recuperar el archivo, y esta es la manera más fácil.
Diego Woitasen
Trabajó para mí, después de algunos intentos encontré el descriptor de archivo correcto, finalmente puedo cerrar el proceso y continuar
Thomas Nordquist
16

Suponiendo que el OP realmente significaba RAM y no de ninguna manera posible , y suponiendo que el proceso en el que se ejecutó el script tiene un límite de archivo de núcleo cero (que generalmente es la configuración predeterminada cat /proc/PID/limits), entonces debe adjuntarlo al proceso y establezca el límite central en un valor lo suficientemente grande como para incluir la imagen del proceso y use la señal ABRT para generar el archivo central, o use una herramienta como gdbesa que pueda adjuntarse a un proceso y generar una imagen central del proceso desde la RAM.

  1. Instalar en pc gdb

En algunos shell con la misma propiedad que el script en ejecución o la propiedad de root:

  1. Hacer ps axpara encontrar la identificación del proceso (PID)
  2. gdb -p PID

Tenga en cuenta que esto detendrá la ejecución del proceso, pero no lo eliminará de la tabla de procesos.

  1. En gdb, emita el comando generate-core-file

gdb debería responder con algo como Saved corefile core.15113, suponiendo que PID es 15113.

  1. En gdb, emita el comando detach

Su script continuará (se reanudará) ejecutándose.

  1. En gdb, emita el comando quit
  2. En shell, corre strings core.15113 > my_script.sh

Abra el my_script.shen algún editor. El texto del script debe estar hacia el final del archivo antes de la sección de entorno. Use el editor para eliminar las secciones antes y después del guión.

Pruebe esta solución en otro script antes de usarlo en su script de premio. YMMV.

La secuencia se ve así:

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
fuente
Esta solución también funciona, pero aquí hay algunas excavaciones involucradas, gracias por su ayuda
Thomas Nordquist
¡Esta es la solución que funcionó para mí! Había sobrescrito el archivo original y esperaba que todavía estuviera en la memoria. El fd abierto (otra respuesta) apuntaba al archivo actualizado. Eso me salvó!
saveman71
0

dd la partición del disco duro en trozos superpuestos y grep binary para partes del script. si tiene suerte, escriba esos fragmentos en el directorio temporal en ram para saludarlos y guardar su disco duro o los ciclos de escritura de ssd. no, no es una solución 'de ram'. tenga en cuenta el hecho de que, al leer el disco byte por byte, los scripts pueden estar en formato de caracteres utf-8 (o similar), por lo que los parámetros grep también pueden tener que adaptarse.

Michael Grieswald
fuente