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

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

我意外地覆盖了一个非常复杂的 bash 脚本,并试图以一种整洁的方式实现作用域和线程。

现在相同的脚本仍在运行,但文件不再存在,问题是:是否可以扫描 RAM 并找到文件本身的字符串表示?

另一个问题是:我找不到 /dev/mem 或 /dev/kmem 文件,已经尝试通过 grep 查找其内容。

环境:这是 vpsfx.com 上的 debian/sid 机器 (vps) hostet

root@heisenberg:~# ls -a /dev
. kmsg ptyp2 ptyp9 随机 tty1 tty5 ttyp2 ttyp9 urandom
.. 登录 ptyp3 ptypa shm tty10 tty6 ttyp3 ttypa xconsole
.udev 空 ptyp4 ptypb stderr tty11 tty7 ttyp4 ttypb 零
char ptmx ptyp5 ptypc stdin 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

答案1

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

答案2

假设原帖作者的真正意思是来自 RAM并不是任何可能的方式,并假设执行脚本的进程具有零核心文件限制(通常是默认设置cat /proc/PID/limits),那么您需要附加到该进程并将核心限制设置为足够大的值以包含进程映像并使用 ABRT 信号生成核心文件,或者使用gdb可以附加到进程并从 RAM 生成进程核心映像的工具。

  1. 安装gdb

在某些与正在运行的脚本具有相同所有权或 root 所有权的 shell 中:

  1. 查找ps ax进程 ID (PID)
  2. gdb -p PID

请注意,这将停止进程继续执行,但不会将其从进程表中删除。

  1. 在 gdb 中发出命令generate-core-file

Saved corefile core.15113假设 PID 是 15113,gdb 应该会做出类似的回应。

  1. 在 gdb 中发出命令detach

您的脚本将继续(恢复)运行。

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

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

在将此解决方案用于奖励脚本之前,请先在其他脚本上测试该解决方案。YMMV。

该序列如下所示:

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:~$ 

答案3

在重叠块中对硬盘分区进行 dd,并对脚本的各个部分执行 grep 二进制文件。如果幸运的话,将这些块写入 RAM 中的临时目录,以便在其中执行 greeping 以保存硬盘或 SSD 的写入周期。不,这不是一个“来自 RAM”的解决方案。请注意,当逐字节读取磁盘时,脚本可能采用 utf-8(或类似)字符集格式,因此 grep 参数可能也必须进行调整。

相关内容