-1

これを行う32ビットLinuxのカーネルモードのシェルコードを書きたい：

commit_creds (prepare_kernel_cred(0));

だから私は次のファイルを作成します：

xor eax, eax
call 0x1234567
call 0x1234568
ret

ここで、0x1234567はprepare_kernel_credのアドレスであり、0x1234568はcommit_credsのアドレスであり、どちらも/ proc/kallsymsから見つかります。

nasm -f elfとobjdump-dを使用してアセンブルし、マシンコードを取得します。

私は次のようなものを手に入れます：

31 c0               which is xor eax, eax
e8 7c 67 06 c1      which is call prepare_kernel_cred
e8 7c 65 06 c1      which is call commit_creds
c3                  which is ret

これは機能しません。ただし、2番目のe8 79代わりにe8 7cおよびの代わりにを使用すると、機能します。この2番目のマシンコードをどこから入手したか（別のファイルにありました）は覚えていませんが、なぜこれが機能するのか、単純にそのように組み立てるのではないのか、非常に興味があります。e8 74e8 7c

これはどんなタイプCALLですか？上に示したように、コードを単純にアセンブルしないのはなぜですか？e8 79とをCALLに使用すると、おもちゃのエクスプロイトは人工カーネルのバグに対して正常にe8 74機能しますが、nasm/objdumpからアセンブルされたマシンコードを使用すると失敗します。

4

2 に答える 2

1

E8hで始まるCALLバリアントは、現在の命令に相対的な変位によって指定されたアドレスへのニアコールです。これは、命令ごとに値を変える必要がある理由を説明しています。しかし、私はあなたがどのようにしてnasmにそのコードを発行させたかについて途方に暮れています。これは宿題ではありませんか？

于 2013-02-19T05:17:01.580 に答える
0

以前に次のコマンドを使用してこれをコンパイルしたことがわかりました。

gcc -m32 -Ttext=0 -nostdlib

これにより、以前と同じ結果が得られます。また、デフォルトで 0x0 から始まるという警告も表示されます。

しかし、なぜnasmはこれを再現しないのですか? objdump で確認したところ、開始アドレスは両方のファイルで 0x0 のようです。

于 2013-02-19T16:35:51.627 に答える