問題タブ [shellcode]

gccでは、これは正常に機能します。コードは次のようになります。

しかし、これをVisual C ++に入れると、次のエラーメッセージが表示されます。

なぜそうなのか誰もが知っていますか？

シェルコードではヌルバイトは許可されていないと思いました。いくつかのシェルコードを理解しているときに、nullを含み、完全に機能するコードに出くわしたようですが、これはなぜですか？

http://pastie.org/private/feg8du0e9kfagng4rrg

私は最近、エクスプロイトとシェルコードを書くことを自分自身に教えてきました。ガイド/本の多くは、スタックがどこから始まるかを推測できると主張しているため、少しの作業で、シェルコードがスタックのどのアドレスから始まるかを推測できます。

• スタックの開始アドレスが予測可能であるのはなぜですか？スタックはメモリ内のランダムなアドレスから開始するべきではありませんか？
• スタックのアドレス開始が仮想アドレス空間の固定オフセットである場合、それがマシンごとに異なるのはなぜですか？
• 異なるプラットフォーム間の許容誤差とスタックの開始アドレスはどれくらいですか？

関連：「スタックはすべてのプログラムで同じアドレスで始まります」、ハッキングによるアドレスの問題：悪用の芸術、なぜスタックアドレスはメモリアドレスの減少に向かって成長するのですか？

編集私のテストでは、アドレス空間配置のランダム化（ASLR）がオフになっています。

このコードがどのように機能するかはよくわかりません。

わかりました、私は知っています：

int のポインターを設定します。と：

ret と 2 バイトのアドレスを設定します (と思います)。

しかし、これが何を意味するのかわかりません：

意味はわかるけど&ret意味がわからない(int *)&ret。shellcodeまた、 toの値を代入してシェルコードを実行するにはどうすればよいretですか?

更新:次の違いは何ですか:

と：

しばらく前に、Windows XPSP3（ http://www.exploit-db.com/exploits/9177/ ）でEasy RM to MP3 Converter 2.7.3.700のエクスプロイトに取り組んでいるときに、理解していない概念に出くわしました。このようになります：

悪意のあるファイルを生成するためのperlスクリプト：

悪意のあるファイルを生成した後、コンバーターにフィードすると、[esp + 18]（espに関連するアドレス指定）でスタックの内容が分析されます...なぜこれらのAがここにあるのですか??

つまり ：

Aは[ESP-88E8]から[ESP-43C]
までBは[ESP-438]から[ESP-C]まで
Cは[ESP-8]で開始

では、なぜこれらのAは[ESP+18]から[ESP+418]にあるのでしょうか？なぜこれらのAは[ESP-88E8]から[ESP-43C]にすでに配置されているのに、[ESP+18]から[ESP+418]で繰り返されているのですか..??

ありがとうございました 。

Linux64ビットマシンで16進バイトコードを実行できる単純なCメソッドが必要です。これが私が持っているCプログラムです：

私が実行しようとしているコード（"\x48\x31\xc0"）この単純なアセンブリプログラムを作成して取得したコード（実際には何も実行されないはずです）

次に、それをコンパイルしてobjdumpして、バイトコードを取得します。

ただし、Cプログラムを実行すると、セグメンテーション違反が発生します。何か案は？

更新されたすべてのオペレーティングシステムは、ASLR、カナリアチェック、およびその他のそのような方法を介してスタックおよびヒープタイプのオーバーフローを防ぐので、メモリ破損のエクスプロイトはまだ蔓延していますか？システムの管理者は有能であり、ブルートフォース攻撃やlibc攻撃からシステムを保護していることを考えると、正直なところ、他の多くの方法を見ることができません。誰かがシステムを攻撃することを私が想像できるのは、スタック上の関数ポインターを上書きすることだけですが、それだけです。誰かが乱数を予測する巧妙な方法を見つけた場合、ランダムな結果に依存するスキームが無効になる可能性がありますが、それはありそうにないようです。今日与えられている他の誰かのシステムを悪用する唯一の方法は、rootまたは管理者をだましてソフトウェアをインストールさせることだと思われます。コードインジェクションの昔は終わりましたか？私'

私は以下に小さなシェルコードを書きました：

シェルコードが機能すると、6が返されます。実際には、上記のコードは適切に機能し、メイン関数は実際に6を返します。

次に、コードをCプログラムに埋め込みます。

通常の状況では、コードは6を返すはずですが、常に0を返します。

私のコードは間違っているとは思いません。それをお見せします。

まず、gdbからvalretのアドレスを取得します。

そして、私はメインの次の呼び出し命令のアドレスを取得します：

明らかに、それは0x08048cd9です。

次に、上記のアドレスをスタックに格納するアドレスを取得します。

明らかに、アドレスは0xbffff2f8 + 0x04=0xbffff2fcです。そして、valretのアドレスは0xbffff2f4です。

したがって、ret=(int *)&ret+0x08正しいアドレスを取得する必要があります。そして*ret=(int *)shellcode、シェルコードのアドレスをスタックに挿入する必要があります。そして、プログラムはシェルコードにぶつかり、プログラムが戻ったときに最後に6を取得します。

私が間違っている？

私は間違った場所を見つけたようです：

指示add $0x20,%eaxがおかしい。これはどのように起こりますか？

最終的に英語の段落の形になるシェルコードを書き込もうとしています。これは、英数字または句読点に評価されるオペコードを持つ命令にほとんど制限されていることを意味します。これによりjo、実際jnoには、、、、、、、、、、、、、、および（文字に対応する）を含む多くの異なるジャンプ命令が残ります。これらの各ジャンプは、ジャンプするかどうかを決定する前にテストを実行します。ほとんどの場合、ジャンプとその逆を組み合わせて、シェルコードでジャンプが確実に行われるようにすることができます（たとえば、then 、またはthenを使用）が、の場合はこれを行うことができません。のテストjbjaejejnejbejajsjnsjpp-zjojnojejnejbjbですCF=1。

私の質問は、機能的にNOPであるが、それを保証する一連の英数字命令はありますCF=1か？ CFはキャリーフラグであるため、キャリーフラグを設定することが保証されている操作で十分です。

また、を確実にするためにjae、とにかく確実にするためにCF=0？