È possibile recuperare il contenuto di uno script bash in esecuzione dalla RAM

Ho accidentalmente sovrascritto uno script bash molto complesso, in cui ho cercato di implementare in modo ordinato scoping e threading.

Ora lo stesso script è ancora in esecuzione ma il file non esiste più, la domanda è: è possibile scansionare il ram e trovare la rappresentazione pungente del file stesso?

Un altro problema è: non riesco a trovare il file / dev / mem o / dev / kmem, ho già provato a cercarlo per contenuti.

Per l'ambiente: è un hostet debian / sid machine (vps) su vpsfx.com

root @ heisenberg: ~ # ls -a / dev
. kmsg ptyp2 ptyp9 random 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
console pts ptyp6 ptypd stdout tty2 tty9 ttyp6 ttypd
fd ptyp0 ptyp7 ptype tty tty3 ttyp0 ttyp7 ttype
full ptyp1 ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf

linux bash memory

— Thomas Nordquist
fonte

Risposte:

Dai un'occhiata a / proc / $ PID / fd. Lì dovresti avere tutti i descrittori di file aperti dal processo, incluso lo script stesso. Basta cat $FD > /tmp/yourscript.shdovrebbe essere sufficiente per recuperarlo.

— Diego Woitasen
fonte

Ho votato a favore di questa risposta nonostante non risponda effettivamente alla domanda posta dal PO. L'OP ha chiesto come recuperare lo script dalla RAM , non dal filesystem. Questa risposta utilizza il file system, basandosi sul fatto che il file di script non viene infine scollegato fino a quando il conteggio dei riferimenti finali non raggiunge lo zero.

— Jonathan Ben-Avraham il

Il filesystem proc risiede solo nella RAM e quasi tutti lo hanno montato.

— Diego Woitasen,

La /procfs non risiede nella RAM. In realtà, non risiede da nessuna parte . Vedi unix.stackexchange.com/questions/74713/… . Sebbene sia possibile ottenere il file fd /proc, cating fd legge il file da fs, non da RAM. È vero, hai eliminato il file, riducendo il conteggio degli inode e nessun altro può vederlo ora, ma non viene effettivamente eliminato da fs fino a quando il processo che esegue lo script non lo chiude. Vedi stackoverflow.com/questions/2028874/… .

— Jonathan Ben-Avraham,

Si hai ragione. Il file stesso viene letto dal filesystem del disco. / proc esiste nella RAM, non è come un ramdisk, ma le informazioni sono nella RAM. Con l'eccezione di / proc / $ PID / fd e potrebbe essere diverso. Comunque, @Thomas Nordquist vuole recuperare il file, e questo è il modo più semplice.

— Diego Woitasen,

Ha funzionato per me, dopo alcuni trys ho trovato il descrittore di file corretto finalmente posso chiudere il processo e continuare

— Thomas Nordquist

Supponendo che l'OP significhi davvero dalla RAM e non in alcun modo possibile , e supponendo che il processo in cui lo script è stato eseguito abbia un limite di file core zero (che di solito è l'impostazione predefinita cat /proc/PID/limits), quindi è necessario collegarsi al processo e impostare il limite principale su un valore sufficientemente grande da includere l'immagine del processo e utilizzare il segnale ABRT per generare il file principale, oppure utilizzare uno strumento come quello gdbche può collegarsi a un processo e generare un'immagine principale del processo dalla RAM.

Installare gdb

In alcune shell con la stessa proprietà dello script in esecuzione o della proprietà root:

Fare ps axper trovare l'ID del processo (PID)
gdb -p PID

Si noti che ciò interromperà l'esecuzione del processo ma non la rimuoverà dalla tabella del processo.

In gdb, immettere il comando generate-core-file

gdb dovrebbe rispondere con qualcosa del genere Saved corefile core.15113, supponendo che PID sia 15113.

In gdb, immettere il comando detach

Lo script continuerà (riprenderà) in esecuzione.

In gdb, immettere il comando quit
Nella shell, corri strings core.15113 > my_script.sh

Apri my_script.shin qualche editor. Il testo dello script dovrebbe essere verso la fine del file prima della sezione ambiente. Utilizzare l'editor per eliminare le sezioni prima e dopo lo script.

Prova questa soluzione su un altro script prima di utilizzarla sul tuo script premio. YMMV.

La sequenza è simile alla seguente:

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

Anche questa soluzione funziona, ma qui sono coinvolti alcuni scavi, grazie per l'aiuto

— Thomas Nordquist

Questa è la soluzione che ha funzionato per me! Avevo sovrascritto il file originale e speravo che fosse ancora in memoria. La fd aperta (altra risposta) puntava al file aggiornato. Questo mi ha salvato!

— saveman71

dd la partizione del disco rigido in blocchi sovrapposti e binario grep per parti dello script. se sei fortunato, scrivi quei pezzi nella directory temporanea in ram per greeping in esso per salvare i tuoi cicli di scrittura del disco rigido o ssd. no, non è una soluzione "from ram". essere consapevoli del fatto che durante la lettura di byte su disco gli script byte potrebbero essere in formato charset utf-8 (o simile), quindi potrebbe essere necessario adattare anche i parametri grep.

— Michael Grieswald
fonte