問題タブ [aslr]

AMD64 準拠のアーキテクチャでは、アドレスは逆参照される前に正規の形式である必要があります。

Intel マニュアルのセクション 3.3.7.1から:

64 ビット モードでは、アドレス ビット 63 からマイクロアーキテクチャによって実装された最上位ビットまでがすべて 1 またはすべて 0 に設定されている場合、アドレスは標準形式であると見なされます。

現在、現在のオペレーティング システムとアーキテクチャで実装されている最も重要なビットは 47 番目のビットです。これにより、48 ビットのアドレス空間が残ります。

特にASLRが有効になっている場合、ユーザー プログラムは 47 番目のビットが設定されたアドレスを受信することを期待できます。

ポインターのタグ付けなどの最適化が使用され、上位ビットが情報を格納するために使用される場合、プログラムは、アドレスを逆参照する前に、47 番目のビットが何であれ、48 番目から 63 番目のビットが設定されていることを確認する必要があります。

ただし、次のコードを検討してください。

ここで、次のように考えてintArrayください。

0000 0000 0000 0000 0 111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1100

に設定itして一度intArray増やし、 を考慮すると、次のようになります。itsizeof(int) == 4

0000 0000 0000 0000 1 000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

47 番目のビットは太字です。ここで何が起こるかというと、ポインター演算によって取得された 2 番目のポインターは、正規の形式ではないため無効です。正しいアドレスは次のとおりです。

1111 1111 1111 1111 1 000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

プログラムはこれにどのように対処しますか? アドレス範囲が 47 ビット目まで変化しないメモリが割り当てられないという OS の保証はありますか?

Windows の実行可能ファイルには.reloc、イメージをリベースするための情報を格納するセクションがあります。しかし、lazarus によってビルドされた EXE にはそれがありません。ASLR が本当に必要な場合、lazarus プロジェクトで動的ベースを有効にするにはどうすればよいですか?

ずっと前にスタックに配置されたバッファー オーバーフローについて読みましたが、仮想マシンをセットアップして実際にそれらを実際に見ることにしました。

次のコードは、脆弱なプログラムでした。

-zexecstackGCC のおよびオプションを使用してコンパイルさ-fno-stack-protectorれ、スタック内のコードを実行可能にし、プログラムに組み込まれたスタック オーバーフロー保護 (「カナリア」値) を無効にします。

gcc vuln.c -o vuln -zexecstack -fno-stack-protector -g

次に、GDB を使用しnameてスタック上のメモリ位置を調べたところ、次のアドレスが見つかりました。0x7fffffffdc10

私の VM には最近の Linux バージョンがあるため、次を実行して ASLR (Address Space Layout Randomization) を無効にする必要がありました: sudo sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"またはsudo sysctl -w kernel.randomize_va_space=0.

シェルコードは、私がオンラインで見つけた Stack Smashing に関する記事から引用したもので、Perl スクリプトを介してプログラムに供給されました。

シェルコードの最初の 45 バイト (画面に "Hax!" と書かれているはずです)、正しい位置にポインターを取得するための余分な 27 "A" バイト、そして最後にリトル エンディアンでのペイロードの開始アドレスです。

問題は：

GDB でプログラムを実行するときは、次の方法で行います。

シェルコードを実行すると、「Hax!」というメッセージが表示されます。出力。

のようにGDBの外でプログラムを実行しようとすると

「 Hax Illegal instruction (core dumped)!」の代わりにエラーが表示されます。出力。

この異なる動作の原因は何かを突き止めようと、頭を悩ませてきました。GDB はデフォルトで ASLR を無効にしているようsysctlですが、カーネルでも無効にしました。カーネルがkernel.randomize_va_space変数を無視している可能性はありますか? それとも、静的であっても、GDB と実際のプロセスでメモリ アドレスが異なるのでしょうか。または、実際のプロセスが実際にシェルコードを実行しているのに、GDB が無視/バイパスしている実際のプロセスで何か問題が発生している可能性がありますか?

何が原因である可能性がありますか？

簡単な python スクリプト (メッセージ ボックスのみ) を作成し、pyInstaller を使用して実行可能にしました。Powershell スクリプトInvoke-ReflectivePEInjection.ps1を使用してその exe ファイルをリフレクティブにロードしたいのですが、powershell がエラーをスローしています (PE ファイルは ASLR をサポートしていません)。

Python スクリプトから ASLR 互換の exe ファイルを作成する方法はありますか。

私はリバースエンジニアリングを研究している学生です。Windows で ASLR を学習した後、確認するつもりでした。次のキャプチャ:

メモ帳の画像ベースは1回目と2回目で同じです。ollydbg でメモ帳を再起動するたびに、イメージベースは同じです。Windows 10でもPEViewとレジストリ値を介してファイルのASLR属性を確認しました。彼らは正常です。メモ帳のイメージベースを変更しない理由はありますか?

スタックのランダム化を有効または無効にするオプションがありますが、ASLR アルゴリズムにシードを指定して決定論的にする方法はありますか?

編集:コンテキストは次のとおりです。私が持っているメモリのバグは、ASLR で 10 回の実行のうち 1 回発生し、ASLR を無効にすると再現できません。ASLR アルゴリズムにランダム シードを提供すると、デバッグ プロセスが大幅に改善されます。