RAMから実行中のbashスクリプトのコンテンツを取得することは可能ですか？

私は偶然に非常に複雑なbashスクリプトを上書きしました。そこでは、スコーピングとスレッド化をきちんと実装しようとしました。

今、同じスクリプトはまだ実行されていますが、ファイルはもうありません、質問は次のとおりです。ラムをスキャンして、ファイル自体のスティング表現を見つけることは可能ですか？

もう1つの問題は、/ dev / memまたは/ dev / kmemファイルが見つからないことです。すでに内容をgrepしようとしました。

環境へ：vpsfx.comのdebian / sidマシン（vps）ホスト

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
コンソール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

/ proc / $ PID / fdをご覧ください。ここで、スクリプト自体を含め、プロセスによってすべてのファイル記述子を開く必要があります。ただ、cat $FD > /tmp/yourscript.shそれを回復するために十分でなければなりません。

OPが実際にはRAMからのものであり、可能な方法ではないことを想定し、スクリプトが実行されたプロセスのコアファイル制限がゼロであると仮定すると（通常はデフォルト設定ですcat /proc/PID/limits）、プロセスに添付する必要がありますプロセスイメージを含めるのに十分な値にコア制限を設定し、ABRT信号を使用してコアファイルを生成するかgdb、プロセスにアタッチしてRAMからプロセスのコアイメージを生成できるツールを使用します。

1. インストール gdb

実行中のスクリプトと同じ所有権またはルート所有権を持ついくつかのシェルで：

2. やるps axプロセスID（PID）を見つけるために
3. gdb -p PID

これにより、プロセスの実行が継続されなくなりますが、プロセステーブルからは削除されません。

4. gdbで、コマンドを発行します generate-core-file

PDBが15113であるSaved corefile core.15113と仮定すると、gdbはのようなもので応答するはずです。

5. gdbで、コマンドを発行します detach

スクリプトの実行が続行（再開）されます。

6. gdbで、コマンドを発行します quit
7. シェルで、実行 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:~$ 

dd重複するチャンクのハードディスクパーティションと、スクリプトの一部のgrepバイナリ。運が良ければ、それらのチャンクをRAMの一時ディレクトリに書き出して、ハードディスクまたはssdの書き込みサイクルを保存します。いいえ、「ramから」のソリューションではありません。ディスクをバイト単位で読み込む場合、スクリプトはutf-8（または同様の）文字セット形式である可能性があるため、grepパラメーターも適合させる必要がある場合があることに注意してください。