プロセスのハッキング/クラックかどうかを分析するプロセス

• プロセスが損傷/ハッキングされたことを確認するには、どのような手順に従う必要がありますか？

現在実行中のシステムで単一のプロセスが実行する操作を確認する唯一の方法は、そのプロセスをデバッグするか、システム全体（カーネル）をデバッグすることです。最初の方法は非常に簡単で、疑わしいプロセスに対してリアルタイムでこれを行うことができるいくつかのツールがあります。straceどのシステムコールを実行しているかを確認でき、どの共有ltraceライブラリ機能を呼び出すか、さらにgdb現在全体的に実行されているコマンドも確認できます。後者の場合、プロセスを停止するのではなく（デフォルトモードで）、kwingdbがプロセスをロードして停止した行を表示できるように、正しい場所にソースコードが必要です。それ以外の場合は、特殊命令を含む機械命令のみが表示されます。

カーネルをデバッグするには特別な設定が必要です。これは、すでに実行されているシステムの場合は不可能です（設定が起動時に準備されていない場合）。これにより、システム全体をローカル（kgdbの場合はkdb）またはリモートで（kgdbとgdb）停止し、メモリを調べ、登録し、いくつかの有用な情報をダンプし、コードを分解することができます。ただし、効果的に説明するには、少なくともx86 asmの基本を理解する必要があります。

カーネルは少なくとも通常モードでは読めない擬似ファイル /proc/pid/mem を提供しますが、https://github.com/siblenx/lynxware/blob/master/dumpmem.c/proc/pid/mapsに提供されているマッピングに基づいてこのスパースファイルを読み取るラッパーです。その後、逆アセンブラを使用してダンプされたファイルを確認できます。プロセスの状態に興味がない場合。kill -SEGV pidulimit -c size

同じ作業に特化したフォレンジックツールがありますが、一般的には経験豊富な人材を対象としています。

• この仮定は意味がありますか？

私はそうは思わない。私のfvwmがそのように動作し始めるか、またはtwm（慣れている場合）も少し心配です。しかし、kwin（そして一般的にKDE）に関しては、今日KDE以来このように動作したいと思います。かなり大きな活動です。それは「正常な」活動です。

たとえば、fvwmがこのように動作する場合は、まずプロセスの/proc/pid/exeが正しいバイナリを指していることを確認し、次にstat -c %z /path/to/binarykdbを使用してそのバイナリの作成時間を確認します。それ以外の場合、システムは停止します。ほとんどの「無駄な」活動はプログラミングのバグまたはソフトウェアの拡張です。

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

/ procファイルは純粋に仮想ファイルであり、いくつかの重要なファイル（mem疑似ファイルなど）はランダムに要求されたときに読み取れないため、これは意味がありません。