プロセスがハッキング/クラックされたかどうかを分析する手順

Question

このプロセスがクラック/ハッキングされているかどうかを確認するには、どのような手順に従う必要がありますか?

現在実行中のシステムで単一のプロセスが何を行っているかを確認する唯一の方法は、そのプロセスをデバッグするか、システム全体 (カーネル) をデバッグすることです。前者はかなり簡単で、いくつかのツールを使用すると、疑わしいプロセスでライブで実行できます。どのstraceシステムコールが実行されるか、ltraceどの共有ライブラリ関数が呼び出されるかを確認したり、gdb全体として現在実行されている命令を確認したりできます。後者の場合、そのプロセスをフリーズする (デフォルトモード) だけでなく、ソースコードを適切kwinな場所に配置して、gdb がそれをロードし、停止した行を表示できるようにする必要があります。そうしないと、特別なコマンドを含むマシン命令のみが表示されます。

カーネルをデバッグするには、特別なセットアップが必要ですが、すでに実行中のシステムではおそらく不可能です (ブート時にそのようなセットアップが準備されていない場合)。これにより、ローカル (kgdb の kdb) またはリモート (kgdb と gdb) でシステム全体を停止し、メモリ、レジスタを検査し、コードを逆アセンブルするだけでなく、いくつかの有用な情報をダンプできます。ただし、これを効果的に解釈するには、少なくとも x86 asm の基本を知っておく必要があります。

カーネルは少なくとも擬似ファイル/proc/pid/memを提供するが、これは通常モードでは読み取れないが、https://github.com/siblynx/lynxware/blob/master/dumpmem.cは、/proc/pid/maps で提供されるマッピングに基づいてこのスパースファイルを読み取るラッパーです。その後、逆アセンブラを使用してダンプされたファイルを検査できます。プロセスの状態を気にしない場合は、を使用してコアダンプを強制できますkill -SEGV pidが、起動時にコアファイルのダンプが許可されていない場合 ( ulimit -c size)、コアダンプは実行されずに終了し、取得したい情報の一部が失われます。

同じタスクを目的としたより特殊なフォレンジックツールもありますが、通常は経験豊富なユーザーを対象としています。

この仮定は意味をなしていますか?

そうは思いません。私の fvwm がそのような動作を始めたら、あるいは twm (慣れていれば) がそのような動作を始めたらと少し心配していましたが、kwin (および一般的な KDE) に関しては、今日の KDE は巨大であり、そのような動作は KDE にとって「普通」なので、そのような動作を予想していました。

たとえば、fvwm でこのような動作をした場合、まずプロセスの /proc/pid/exe が正しいバイナリを指しているかどうかを確認し、次にでそのバイナリの作成時間をチェックしstat -c %z /path/to/binary、それが正当であれば strace を実行し、そうでない場合は常に準備されている kdb に急いで送信してシステムをフリーズさせます。「無駄な」アクティビティのほとんどは、プログラムのバグまたはソフトウェアの肥大化です。

注: ほとんど/proc/xxxフォルダーをコピーしたので、かなりの情報があります。

mem/proc ファイルは完全に仮想的なものであり、それらの重要なファイル (疑似ファイルなど) は通常の方法で要求された場合には読み取ることができないため、これは意味がありません。

Answer 1

このプロセスがクラック/ハッキングされているかどうかを確認するには、どのような手順に従う必要がありますか?