問題タブ [shellcode]

プログラマーがこの文字列に 16 進エンコードを使用したのはなぜですか? たとえば、なぜ\x31最初の文字に ? ではなく使用するの1ですか?

Aleph One の記事Smashing the Stack for Fun and Profit で説明されているように、私はバッファ オーバーフロー攻撃に取り組んでいます。

この記事で提案されているように、悪意のあるコード (シェルコード) を環境変数 ($EGG) に植え付けるプログラム (shellcode.c) を作成しました。その後、攻撃したいプログラム (vulnerable.c) に $EGG が引数として渡され、そのプログラムのバッファがオーバーフローし、シェルコードが実行されます。

これはバッファがどのように見えるかです -

[NNNNNNNNNN...NNNNNNSSSSSSSS...SSSSSSSRRRRR...RRRRRR]

ここで、N は NOP 命令 ( NOP sledを参照)、S はシェルコード、R はアドレス (命令ポインターがコード セグメントから上記のスタック バッファーにジャンプして命令の実行を開始するバッファーにアドレスを返す) です。

通常のユーザーとして shellcode.c と脆弱な.c の実行可能ファイルを実行すると、次の問題に直面します。命令ポインターがバッファーにリダイレクトされ、命令に遭遇すると、セグメンテーション違反が発生します。ただし、プログラムを sudo として実行すると、バッファ内の命令は問題なく実行され、バッファ内の後続のシェルコードが正常に実行され、ルート ターミナルが起動され、エクスプロイトが完了します。なぜこれが起こっているのか、誰かが光を当てることができますか?

次の保護を無効にしました - Stack Smashing Protection、ASLRおよびLinux の NX (eXecute Disable Bit)。

gcc 4.4.3 (ターゲット: i486-linux-gnu) を使用してコンパイルし、カーネル 2.6.32 を実行する Ubuntu 10.04 (Lucid Lynx) で実行しています。

以下は私の2つのプログラムです：

脆弱な.c

shellcode.c

私は、文字を変更するなどの簡単なことを行って文字列を変更し、それを印刷できるようにするシェルコードの単純なチャンクを作成しようとしています。

「ハローワールド」をプリントアウトすることになっています。movこのようなコマンドでメモリのバイトを変更しようとすると、問題が発生します（セグメンテーション違反） 。

mov byte [esi+1], 41

GDBでプログラムを実行しましたが、pop esiコマンドは正しく機能しesi、文字列のアドレスが読み込まれ、すべてが有効です。しかし、なぜ有効なアドレスのバイト値を変更できないのか理解できません。NASMとldによって生成された実行可能ファイルを実行するだけで、この「シェルコード」をテストしています。Cプログラムなどにはまだ入れていないため、アセンブリにバグが存在します。

追加情報

次のビルドコマンドでx64Linuxを使用しています。

ここに完全なコードを貼り付けました。

ASM の 1 行をシェルコードに変換できるようにしたいと考えています。いいえ:

これを行うにはどうすればよいですか。また、このシェルコードを適切に変換して、Delphi アプリケーションの変数に格納できるようにするにはどうすればよいですか。いいえ:

このシェルコードに問題があります。アセンブラ コードを実行すると文字が出力されますが、c から関数として呼び出すと出力されません。実行されたすべての命令をテストするために gdb を使用しましたが、すべての命令を実行しているようです。私は asm と c の両方のバージョンをデバッグしましたが、どちらも同じように動作しますが、int 0x80 では C コードに対して何も出力しないため、非常に奇妙です。これはCコードです：

これはnasmコードです：

編集：私は問題を解決しました。この Web ページ: http://www.exploit-db.com/papers/13065/ 64 ビットでは、int 0x80 の代わりに syscall を使用してシステムコールを呼び出す必要があり、引数のレジスタが異なることがわかりました。次に、この別の Web ページを見つけました: http://cs.lmu.edu/~ray/notes/linuxsyscalls/。これらのシステムコールの実行に関するいくつかの例があり、良い Web ページだと思います。

しかし、問題は、なぜ Nasm コードで機能したのかということです。互換性に関するものですか？アセンブラーが int 0x80 命令を検出したため、アセンブラー コードが互換モードで実行されていた可能性があります。また、C では、シェルコードを解釈できないためコンパイラーが検出できませんでしたか?

ここに作業用の C コードを残します。

私はexecveシェルコードを研究しようとしていますが、

OS：Linux bt 2.6.39.4

root@bt:~/exploit# cat gshell.s

root@bt:~/exploit# as -gstabs -o gshell.o gshell.s

root@bt:~/exploit# ld -o gshell gshell.o

root@bt:~/exploit# ./gshell セグメンテーション違反 (コアダンプ) root@bt:~/exploit#

GDB:

(gdb) break *_start Breakpoint 1 at 0x8048054: ファイル gshell.s、6 行目。

(gdb) r プログラムの起動: /root/exploit/gshell

プログラム受信信号 SIGSEGV、セグメンテーション違反。shell () at gshell.s:14 14 movb %al,9(%esi)

(gdb) print /x $esi $1 = 0x804807a (gdb) x/16cb $esi 0x804807a : 47 '/' 98 'b' 105 'i' 110 'n' 47 '/' 98 'b' 97 'a' 115 's' 0x8048082 : 104 'h' 65 'A' 68 'D' 68 'D' 68 'D' 68 'D' 67 'C' 67 'C' (gdb)

上記の出力から、/bin/sh アドレスを ESI レジスタに正常に pope したようですが、0 を 9(%esi) に移動しようとすると、セグメンテーション違反が発生します。このプログラムを変更しようとさえしました: movl $0 から $esi. 0x804807a アドレスへの書き込みに制限されているかどうか知りたいですか? この障害の原因は何ですか？このシェルコードを正常に実行する方法

ありがとう、リトルジャック

私はCでコンパイラスイッチを備えた単純なプログラムを持っています：/ GS-

これは、EIPをマシンコード文字列の場所に変更するという概念実証にすぎません。

EIP = 0x012f5000に設定すると、EIPは次の配列のアドレスに配置されます。

char code[] = "\x00\x00\x8B\x00\x00";

これらの命令が何をするのか正確にはわかりませんが、x00の命令はおっとのようです。EIPをプログラム内の他の場所に切り替えると問題が発生するようですが、EIPをこのアレイのアドレスにポイントすると、EIPのその場所で「アクセス違反」例外が発生します。

なぜこのエラーが発生するのですか？これは、ある種のWindows保護メカニズムによるものですか？それとも、Windowsがこの文字列形式で命令を実行できないということですか？プログラムにこれらの命令を実行させるにはどうすればよいですか？

シェル コードを作成するために、今日アセンブリを開始しました。ASM は問題なく、しばらくすると次のように作成されました。

うまくいった：

そこで、「objdump -d test」を使用して、次の結果を得ました。

しかし、それをシェルコードに変えたとき:

うまくいきませんでした。何が間違っていますか?

私は、offensive-security.com から Backtrack クラスを使用した侵入テストを受講しており、Ability Server のバッファー オーバーフロー エクスプロイトに取り組んでいます。EIP を正常に上書きして、シェルコードにジャンプできます。ただし、デバッガーでシェルコードを調べ始めると、シェルコードから壊れます。悪い文字を排除したことはほぼ 100% 確信しています。送信前のシェルコードと、送信後のデバッガーのシェルコードを比較したところ、それらは同一でした。

imgurアルバムから写真を投稿しなければならないことをお詫びします。私はstackoverflow.comに慣れていないので、ストリートの信用を得るまで写真を投稿することはできません.

写真はバッファオーバーフローアルバムにあります。(唯一のアルバム) http://edwardmcfellon.imgur.com/

{写真 1}ここでは、EIP に設定されたブレーク ポイントがあります。これまでのところ、すべて順調です。

{写真 2}プログラムを続行すると、シェル コードにジャンプします。すべてはまだ良いです。

{写真 3}プログラムが POP EBX を実行すると、シェルコードが壊れてしまい、これが私の問題です。

{写真4}これが壊れた後の行き先です。

どんな助けでも大歓迎です。参考までに、私はバッファオーバーフローを書くのが初めてで、なぜこれが起こっているのか、そして将来それを防ぐ方法を理解しようとしています. 前もって感謝します。

次のようなコードは、シェルコードを「テスト」、つまり実行できるはずです。

ただし、これらの例を使用しようとすると、シェルコードの最初の命令でセグメンテーション違反を受け取るため、コードが実行可能ではないメモリで実行されているように見えることがわかります。

代わりにシェルコード宣言を a に変更すると#define、シェルコードを実行できます。ただし、シェルコードは、独自のメモリに書き込もうとすると停止します (このシェルコードは、スタック上で実行されることを前提としています)。

だから私の質問は、実行可能（明らかに）および書き込み可能なメモリを想定しているシェルコードをテストする最も簡単で信頼できる方法は何ですか？コードをスタックまたはヒープに割り当ててそこにジャンプしようとすると、NX ビット保護に遭遇し、再び失敗します。明らかにNXビットを無効にすることができましたが、このテストを行うためのより良い方法はありませんか?