是否可以从RAM中检索正在运行的bash脚本的内容

我偶然覆盖了一个非常复杂的bash脚本，我试图以一种整洁的方式实现范围和线程。

现在相同的脚本仍在运行，但文件已不复存在，问题是：是否可以扫描ram并找到文件本身的sting表示？

另一个问题是：我找不到/ dev / mem或/ dev / kmem文件，已经尝试过grep它的内容。

对于环境：它是vpsfx.com上的debian / sid机器（vps）hostet

root @heisenberg：〜＃ls -a / dev
。kmsg ptyp2 ptyp9随机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
完整ptyp1 ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf

linux bash memory

— 托马斯诺德奎斯特
source

Answers:

看看/ proc / $ PID / fd。在那里你应该有进程打开的所有文件描述符，包括脚本本身。只是cat $FD > /tmp/yourscript.sh应该足以恢复。

— Diego Woitasen
source

尽管事实上它没有回答OP提出的问题，但我还是赞成了这个答案。OP询问如何从RAM中恢复脚本，而不是从文件系统中恢复脚本。这个答案使用文件系统，依赖于脚本文件最终未被链接的事实，直到最终引用计数达到零。

— Jonathan Ben-Avraham 2013年

proc文件系统只驻留在RAM中，并且每个人都安装了它。

— Diego Woitasen

该/procFS不驻留在RAM中。事实上，它并不存在于任何地方。见unix.stackexchange.com/questions/74713/...。虽然你可以从fd中获取fd /proc，cat但fd从fs读取文件，而不是RAM。是的，您删除了文件，减少了inode引用计数，现在没有其他人可以看到它，但实际上并没有从fs中删除它，直到运行脚本的进程关闭它。见stackoverflow.com/questions/2028874/...。

— Jonathan Ben-Avraham 2013年

是的，你是对的。文件本身是从磁盘文件系统中读取的。/ proc存在于RAM中，它不像ramdisk，但信息在RAM中。/ proc / $ PID / fd除外，可能是其他的。无论如何，@ Tommas Nordquist希望恢复文件，这就是简单的方法。

— Diego Woitasen 2013年

为我工作，经过几次尝试后我找到了正确的文件描述符，我终于可以关闭这个过程并继续

— Thomas Nordquist

假设OP确实意味着从RAM而不是任何可能的方式，并假设执行脚本的进程没有核心文件限制（通常是默认设置cat /proc/PID/limits），那么你需要附加到进程并且将核心限制设置为足够大的值以包括过程映像并使用ABRT信号生成核心文件，或使用诸如gdb可附加到进程的工具并从RAM生成进程的核心映像。

安装 gdb

在某些与运行脚本或根所有权具有相同所有权的shell中：

不要ps ax找进程ID（PID）
gdb -p PID

请注意，这将阻止流程执行继续，但不会将其从流程表中删除。

在gdb中，发出命令 generate-core-file

Saved corefile core.15113假设PID为15113，gdb应该响应类似的东西。

在gdb中，发出命令 detach

您的脚本将继续（恢复）运行。

在gdb中，发出命令 quit
在shell中，运行 strings core.15113 > my_script.sh

my_script.sh在某些编辑器中打开。您的脚本文本应该位于环境部分之前的文件末尾。使用编辑器清除脚本之前和之后的部分。

在您的奖品脚本上使用之前，请在另一个脚本上测试此解决方案。因人而异。

序列如下所示：

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
source

这个解决方案也有效，但这里有一些挖掘，谢谢你的帮助

— Thomas Nordquist

dd重叠块中的硬盘分区和脚本部分的grep binary。如果运气好的话，请将这些块写到ram中的临时目录中，以便保存硬盘或ssd的写周期。不，这不是'来自ram'的解决方案。请注意，当逐字节脚本读取磁盘时，可能采用utf-8（或类似）charset格式，因此也可能需要调整grep参数。

— 迈克尔格里斯瓦尔德
source