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

Question

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

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

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

另一个问题是：我找不到 /dev/mem 或 /dev/kmem 文件，已经尝试对其内容进行 grep。

环境：它是 vpsfx.com 上的 debian/sid machine (vps) hostet

root@heisenberg:~# ls -a /dev
. kmsg ptyp2 ptyp9 随机 tty1 tty5 ttyp2 ttyp9 urandom
.. 记录 ptyp3 ptypa shm tty10 tty6 ttyp3 ttypa xconsole
.udev null ptyp4 ptypb stderr tty11 tty7 ttyp4 ttypb 零
字符 ptmx ptyp5 ptypc 标准输入 tty12 tty8 ttyp5 ttypc
控制台 pts ptyp6 ptypd 标准输出 tty2 tty9 ttyp6 ttypd
fd ptyp0 ptyp7 ptype tty tty3 ttyp0 ttyp7 ttype
完整的 ptyp1 ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf

Answer 1

小智 18

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

`/proc` fs 不驻留在 RAM 中。事实上，它并不驻留在*任何地方*。请参阅 http://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux/74724#74724。虽然你可以从`/proc` 获取fd，但是`cat` ing fd 是从fs 读取文件，而不是RAM。确实，您删除了文件，减少了 inode 引用计数，现在没有其他人可以看到它，但它实际上并没有从 fs 中删除，直到运行脚本的进程关闭它。请参阅 http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de。 (2认同)

Answer 2

Jon*_*ham 17

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

安装 gdb

在某些与运行脚本或 root 所有权具有相同所有权的 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:~$

Run Code Online (Sandbox Code Playgroud)

归档时间：	12 年，1 月前
查看次数：	4407 次
最近记录：	7 年，2 月前