Q&A
一応、私が言った事のなかで誤解されてそうなものを修正しとくと
> ヘッダーファイルの場所を記録するIATも
> 同じ端末で実行させるなら考慮しなくていいはずなので
は言った覚えがないです。
同一環境ならばアドレスが同一(な事が多い)ですが、IATの仕組み上呼び方に工夫が必要です。
それと私の立場としては、「アセンブラでやらないとどうしようもない部分が存在する」です。
アセンブリ言語で直接CPUへ命令（システムコール）
をすることによって、"Hello World"を出力させるプログラムを作りました。
１、winAPIを使ったパターン
（winAPI関数を２回使用・・・）
s
1LFB10: 2 3 sub $20,%esp 4 pushl $-11 5 call _GetStdHandle@4 6 pushl $0 7 leal 4(%esp), %ebx 8 pushl $0 9 pushl %ebx 10 pushl $14 11 pushl $LC0 12 pushl %eax 13 call _WriteFile@20 14 add $20,%esp 15 16 LC0: 17 .ascii "Hello, world!\n" 18
２、printf関数を読んだパターン
s
1.text 2 msg: .ascii "%s\0"; 3 msg4: .ascii "Hello World!\0" 4 .globl _main 5 6_main: 7LFB10: 8 9sub $20,%esp 10movl $msg4,4(%esp) 11movl $msg,(%esp) 12call _printf 13add $20,%esp
スライディングコード
実行される位置がランダムになってしまうため
無駄な処理をシェルコード先頭に配置してい置き
本命のコードが実行されることを期待する・・・
ための工夫（多分）
設定でランダムは消せると思うのでたぶんいらない。
バッファオーバーフロー
でシェルコードを実行させたいときは工夫が必要いわれていますが
私は自分のパソコンで作成したシェルコードを
自分のパソコンで実行させようとしています。
それなら、アドレスのランダム化も無効化してしまえばどうにかなるし
ヘッダーファイルの場所を記録するIATも
同じ端末で実行させるなら考慮しなくていいはずなので
ほぼコードを変える必要性が無いと思うのですが
IDA Proも導入したはいいものも・・・
（実行ファイルの中身を16進数で表したもの）
膨大な数のこのコード（？）
バッファオーバーフローでシェルコードとして使いたい場合
どのようなところをアレンジする必要があるのでしょうか？
]
（見た感じ全部必要ですよね？）
分からないのでお願いします。
回答3件
0
ベストアンサー
先の質問に対する回答の中でも触れましたが、シェルコードとして実行させるというのは実行中の別の (脆弱性がある) プログラムの中に差し込んで実行させます。 それによって既に走っているプログラムの権限を乗っ取るのが基本的な形です。 ですから、シェルコード自体にはセクションも何もないです。
しいて言えば .text 相当のみがある状態と言えます。
失礼な言葉になってしまうかもしれませんが、質問者はシェルコードがどういうものなのか理解するのに充分な前提知識がありません。 先に触れたことを理解していな状態で似たような次の質問をどんどん連投するのはあまりよくないですね。 まずは普通のアプリケーションプログラムを満足に書ける程度にはなってから次の段階へ移るべきだと思いますが、どうしてもシェルコードというものに興味があるのだということであれば「Hacking: 美しき策謀 ―脆弱性攻撃の理論と実際」という本が手頃だと思います。 安価ですし。
投稿2019/10/27 03:29
総合スコア5444
0
インポートライブラリを使うことは無理なので(詳しくはデバッガや逆アセンブラで、生成されている機械語を見てください)
まず、アドレスを特定する
c
1#include <windows.h> 2#include <stdio.h> 3 4int main(){ 5 HINSTANCE KernelDll = GetModuleHandle("Kernel32.dll"); 6 void* WriteFile = GetProcAddress(KernelDll, "WriteFile"); 7 void* GetStdHandle = GetProcAddress(KernelDll, "GetStdHandle"); 8 void* ExitProcess = GetProcAddress(KernelDll, "ExitProcess"); 9 10 printf("KernelDll = %p\n%%define WriteFile 0x%p\n%%define GetStdHandle 0x%p\n", KernelDll, WriteFile, GetStdHandle); 11 printf("%%define ExitProcess 0x%p", ExitProcess); 12}
それを用いて
nasm
1; 注: gasではなくnasmアセンブラを用いること 2bits 32 3; 以下に上のプログラムで特定したアドレスを入れる 4%define WriteFile 0xFFFFFFFF 5%define GetStdHandle 0xFFFFFFFF 6%define ExitProcess 0xFFFFFFFF 7; global _main 8; section .text 9; _main: 10xor ebx, ebx 11push -11 12mov eax, GetStdHandle ; GetStdHandle(-11) 13call eax 14 15push ebx ; "\0" 16push 0x0A0D444C ; "LD\r\n" 17push 0x524F574F ; "OWOR" 18push 0x4C4C4548 ; "HELL" 19mov edx, esp ; edx = "HELLOWORLD\r\n\0" 20 21push ebx; NULL 22push esp; &written 23push 13 ; len 24push edx; buf 25push eax; stdout 26mov eax, WriteFile ; WriteFile(stdout, buf, len, &written, NULL) 27call eax 28 29push ebx 30mov eax, ExitProcess 31call eax
にてそれっぽいものができました。
投稿2019/10/28 13:02
編集2019/10/28 14:41総合スコア15147
ありがとうございます。
今見て思ったのですが
関数がある場所のアドレスはスタックセグメントに積まれるんですね。
IATが使えないためコード内にて決め打ちしていますが、なにか不思議でしょうか？
あ、いえ
関数のアドレスはスタックではない
また別のセグメントに置かれるものだと
思っていたからです。
別のセグメントに置かれるから、コードしかない(上に真っ当な方法で読み込まれない)シェルコードでは使うことができないんです
さっき、私が言った関数のアドレスとは
関数を使うため（printfとか）
関数自体が定義されている場所を知らせなければいけない。
だから、スタックに積んで場所を指定するのではないか？
という意味のほうです。
asmさんが言っているのは
＞別のセグメントに置かれるから
関数定義されているファイル自体の場所・メモリのセグメント
のことですよね？
> 関数定義されているファイル自体の場所・メモリのセグメントのことですよね？
OS(のイメージローダーLdr)によるIAT(主に.idata)の解析・書き換えが行われない事を指しています。
ところで、シェルコード内部に定数としては埋め込みましたが、スタックに積んだ覚えはありません。
シェルコード自体をスタックに読み込むのだから「スタックに積んでいる」も間違いではありませんが
別にヒープに読み込んでも動くつもりで、その場合はスタックには積まない筈ですが
＞ところで、シェルコード内部に定数としては埋め込みましたが
すみません。言葉のミスです。
0
アレンジ可能かどうか具体的なアドバイスは可能だと思う、と書いた手前、回答してみる。
- 攻撃対象のプログラムは scanf() 等で、スタック上の文字配列（ローカル変数）にシェルコードを読み込み、バッファオーバーランを起こす
- 攻撃対象プログラムの文字配列の先頭アドレスがわかる
- 攻撃対象プログラムの_printf のアドレスがわかる
- 上記の printf() を呼ぶパターン
という前提で考えてみた。SaitoAtsushiさん曰く
しいて言えば .text 相当のみがある状態
であって、〜〜ヘッダ領域などは一切不要。
さらに切り詰めれば、おおよそ次のようなコードがあれば良いのではないか。
gas
1shcode: 2 movl $shcode-8, %esp # スタックポインタを調整 3 movl $msg,(%esp) 4 call _printf # printf("Hello World!\n") ; 5 ret # 表示後、どうすれば良い？ 6 7msg: 8 .ascii "Hello World!\n\0" 9 .rept 20 # バッファオーバーランするバイト数 10 .byte 0x90 11 .endr 12 .long shcode # 実際は配列の先頭アドレス
ただし、このコードは動作確認も何もしていない、アイディアだけ。次のような箇所を質問者自身で判断し、値を決定しなくてはならない。
- このコードは攻撃対象の文字配列のあるスタック領域に読み込まれて動作するのだから、下手をすると printf()等が、このコード自身を上書きしてしまうかもしれない、なので先頭でスタックポインタを調整すると良いかも、それにはスタックポインタ %esp がコード先頭付近をポイントすれば、このコードを壊されずにすむだろう、というアイディア。ただし、文字配列に十分な大きさがあって、そこをスタックとして printf() 等が動作できるなら、こんなことをする必要はない。
- movl $msg,(%esp) と call _printf の２行が表示の本体。ただし、call命令は E8 xx xx xx xx ではなく、_printf の絶対番地を呼び出す ff 25 xx xx xx xx に変更したほうがよさそう（さらに syscall で表示するなら、_printfのアドレスを知らなくてもよい）。
- 最後の** ret 命令は全く適当でない**。ここで何をすべきかアイディアが無い。
- .rept 〜 .endr は0x90（NOP命令）を必要な個数だけ並べて配列を溢れさせるもの（「20」はテキトーに書いた値）。
- .long shcode はリターンアドレスを上書きする値。これでコード先頭（shcode）へ制御を移動させることになる。値は攻撃対象の文字配列の先頭アドレスになるはず。.long は 32bit の値の場合であって、64bit にするなら代りに .quad という擬似命令がある。
これら全てで数十〜100バイト程度の機械語（攻撃対象関数のスタックフレームに応じた大きさ）、即ちシェルコードになると思う。
ただし、これをアセンブルしただけでは、目的のシェルコードは得られない。アセンブルさせてみた上で、バイナリエディタなどでファイル化するのが、愚直だが確実な方法だと思う。アセンブラ・リンカなど、正規の使い方で作れるものではないのだから工夫が要る。
"Hello World!"を出力するプログラムを作ったとして
コンパイルした機械語をアレンジする必要があるのですか？
「〜を出力するプログラム」は、自分自身の、通常のメモリ配置で動作するが、
シェルコードは他人（攻撃対象）が動作するメモリアドレスで動作しなければならない。プログラムコード領域（コードセグメント?）で動作する想定でコンパイルされるコードが、攻撃対象のスタック領域（スタックセグメント?）で動作することになる（のだよね?）。
つまり動作環境（メモリアドレス）がガラっと変わる事を忘れてはいけない。コードの配置場所が違ってしまうので、関数呼出し等ができなくなったり、文字列のようなデータの在り処（メモリアドレス）が変わってしまうという事。だからアレンジが必要になる。
結論的に言えそうな事は、シェルコード中の命令で、オペランドにメモリアドレスが現れる命令が要注意だと思う。私が示したコードでは、次の4行。
- movl $shcode-8, %esp
- movl $msg,(%esp)
- call _printf
- .long shcode
一方、シェルコード書いてみたのアセンブリコード connect.s には要注意な命令は無い。connect.s をアセンブルして得られた機械語はそのまま利用可能と思われる。その違いをまとめると次のようになる。
- スタックポインタを変更していない（"movl $shcode-8,%esp" 相当の操作無し）
- 文字列 "/bin//sh" をそのままpushしている（"movl $msg,(%esp)" に相当）
- syscall 命令を使う（"call _printf" ではなく）
- リターンアドレスを上書きする値を含んでいない（".long shcode" が無い）
文字列をpushする部分はこう。
gas
1 xor rcx, rcx /* rcx := 0 */ 2 push rcx /* push した 0 が '\0' の代り */ 3 mov rax, 0x68732f2f6e69622f /* == "/bin//sh" */ 4 push rax /* スタックに 8 文字を push */ 5 mov rdi, rsp /* その時の rsp が文字列先頭アドレス */
スタックに文字列の先頭アドレスを push するのではなく、8文字の文字列（8文字==64bit）そのものを直接 push するのがミソで、push 直後のスタックポインタ rsp の値が文字列先頭アドレスになる。このようなコードはスタック領域が何番地でも問題無く動くからアレンジは不要。
printf() を使わず、syscall を使うことは大きい。
まず、printf() 関数のアドレスを調べる必要が無い。そして、syscall で出力するなら、スタックポインタの変更（movl $shcode-8,%esp）をしなくても良い可能性が高い。
printf() は関数だから、その実行にはそれなりのスタック領域が必要だが、何バイト必要なのか簡単にはわからない。そこで私のコードは安全策をとって、スタックポインタを変更した。
一方、syscall 命令は、その時点でＯＳ内部のコードへ処理が遷移すると同時に、スタックポインタがＯＳ用のスタック領域に切り替わる。そのため、こちらのコードに必要なスタックサイズは少量で済み、かつ見積りが可能になる（＝push するバイト数を数えれば良い）。
文字列をpushする事とsyscall命令を使う事は、メモリアドレスが現れる命令をなるべく使わないための、標準的な工夫と言えるだろう。
いずれにしても、（攻撃対象プロセスの）スタック領域を、どう使おうとしているか、目に見えていないことには、何が問題かも理解できないと思う。一命令ごとに動作をトレースできないようでは（略）。
ところで、リンクのページでは 167 バイトのシェルコードを得ている。しかし、リターンアドレスを上書きする値も、バッファを溢れさせる nop 命令列も無いので、そのままでは攻撃できない事に気づいているだろうか。結局、その２つを付け足すアレンジは最低限要るはずだ。
投稿2019/10/27 09:47
編集2019/11/08 15:06
総合スコア1380
scanf() などは 0x00 を読み込めない・・・ああ、そうか。
上記コード中に 0x00 が出てくるなら、そこを対策しないといけない。つまり、同じ動作を 0x00 を含まない命令やデータに置き換えなくてはならない。
・・・すると "hello world\n\0" のターミネータもダメってことになる。工夫のしがいありで楽しいね笑
そもそもデータセグメント使わずに"hello world\n\0" をpushするのもCでは一苦労ですね
> 最後の ret 命令は全く適当でない。
exitを呼ぶのが適切です。
printf() のアドレスがわかるなら exit()のアドレスもわかるでしょう。カズヤ君自身でアセンブリコード化できると思います。
_printfはCのランタイムライブラリに属するので、シェルコードとして潜り込む先の宿主のEXEがCランタイムをDLLとしてリンクしているか、スタティックリンクしているかでまた事情が変わりそうに思いますが、ほとんどのケースではmsvcrt.dllとのダイナミックリンクであろうことを前提にして、宿主のIATから探しに行くかたちになるでしょうか。更に、_printfと_exitのエントリが存在することに期待して。
ありがとうございます。
Linuxで"Hello World!"を出力する
アセンブリプログラムを作成したとして
（0x00や、"Hello World!"の場所の問題は解決したとして）
そのソースコード自体（？）を環境変数に登録し、
脆弱性のあるプログラムのリターンアドレスを
そのソースコードが置かれている環境変数のアドレスに
変更するとうまくできると、参考書に書かれていたのですが
アセンブリ言語をexeにして、さらに16進数表現にして
それらすべてをscanfに流すパターンと何が違うのでしょうか？
また、exeのすべての機械語コードが必要ではない
というのはexeをファイルからクリックするならば
例外処理とか、文字列の場所とか必要だけど
すでに動いているプログラムに割り込むのだから
最低限のコード、すなわちtextだけでいいんじゃないか？
という話（？）ですよね？
追記
＞テキストセグメント関係のようですね。
なんでもないです。
メモリのどこのセグメントにデータが
置かれるかだけの問題みたいですね。。
> exeのすべての機械語コードが必要ではない（中略）
> すでに動いているプログラムに割り込むのだから最低限のコードだけでいいんじゃないか？
まあ、そうなんですけど、私が上で示したシェルコードは、割り込むのではありません。＜潜り込む＞とでも言うべきです。コンピュータには別の意味の「割込み」という言葉がありますから。
ちなみに「動いている exe プログラム」をプロセスと呼びます。
シェルコードを攻撃対象プロセスの配列に潜り込ませて、そこに制御を移す、のがこの攻撃手段ですね。
さて、hello world を表示する exe ファイルをクリックすれば、攻撃対象プロセスとは別の、新たなプロセスが誕生します。新たなプロセスの誕生には（実行形式として必要な）ヘッダ情報や各種セクション情報などが一通り必要です。
しかし別のプロセスが表示しても、それは「攻撃」にはなりません。
やりたいことはプロセスを新たに誕生させる事では無いので、ヘッダ情報等は一切不要です。
よく考えてみてください。
- シェルコードを書き込むスタック領域
- 書き変えたリターンアドレスにRETしていくCPU
- シェルコードが呼び出す printf() 関数
これらは攻撃対象のプロセスが持っている「資源」です。。
攻撃対象プロセスの資源を利用して、その意に反する動作（hello worldを表示）させてしまう、それは宿主の細胞が持つＤＮＡ複製の仕組みを利用するウィルスによく似ています。シェルコードもサイズは小さく、細胞のような（exeファイルのような）大きな構造を持ちません。
> そのソースコード自体（？）を環境変数に登録し、脆弱性のあるプログラムのリターンアドレスをそのソースコードが置かれている環境変数のアドレスに変更するとうまくできる
これは何のこと？私は全く知りません。
ありがとうございます。
だからこそ、文字列の格納場所とかが問題になるのですね。
（自分の環境ならまだしも他の環境だとさらに厳しい・・・）
なんだかんだで
VirtualboxでCentOS
環境構築をすることができました。
GASコンパイラとGDBを導入したのでさっそく始めていきたいのですが
・・・
Linux環境下で"Hello World!"を出力するプログラムを作ったとして
（文字列のアドレス、0問題はアセンブリコード内で解決したものとして）
コンパイルした機械語をアレンジする必要があるのですか？
それても、アセンブリ言語で問題を解決しているならば
生成した機械語列をアレンジする必要はないのでしょうか？
https://qiita.com/slowsingle/items/59c139b747edec9157cc
取り出す必要があるみたいですが・・・
https://ameblo.jp/n0xi-lab/entry-12132843161.html
でも、こちらのサイトだとそのようなことは書かれていませんね。
> では、これをマシン語に変換しシェルコードを作ります。
> :~$ nasm shell.s
nasmだから、gasとは(デフォルトでは)出力するファイルの形式が違います。
NASMなら、そのまま使えるんですね。
ファイル形式に違いはあっても、「取り出した」結果としてのシェルコードは同じもののはずだが？
「シェルコード書いてみた」ページでは connect.s をコンパイルして得た a.out からシェルコードを「取り出し」ている。その結果167バイトのシェルコードである。もとの a.out の、どの部分を取り出したのか、どの部分を取り出せばよいのか、自分の手で確かめたのかな？
シェルコードはヘッダ情報などを取り去った、肝心要の機械語コードだから。
一方、実行形式のファイルやリロケータブルオブジェクトファイル形式には、機械語だけでなく、ヘッダ情報やセクション情報などがくっついていて、それがgas（実際はリンカldか？）の出力形式とNASMの出力ファイル形式の違いだと思われるが、その違いはシェルコードには不要な部分。
了解です。ありがとうございます。
GASだと、実行可能ファイルが生成される
（ヘッダーとかついている）
NASMだと、そういうのは一切ないんですか？
私はNASMを使ったことがないし、gas もちゃんと理解してるとは言いがたいので。。。NASMとgasの違い、確かなところは他の方に聞いてくれ（笑）。
一般的に、アセンブルすればリロケータブル・オブジェクト・ファイル（ＲＯＦ）が作られる。ほぼ機械語だけど、未解決シンボルがあるので、実行できない。当然のように何らかのヘッダ情報やセクション情報などが含まれている。
実行可能形式ファイルとは、リンカ（ldかな?）がROFやライブラリをリンクして、未解決シンボルを解決したもの。セクションもまとめられる。Windowsならexeファイル。当然、実行可能形式にもヘッダなどの情報は含まれている。
CentOSなら
% as -a connect.s
でアセンブルリストが表示されるはず。作られたファイルがＲＯＦか実行可能形式かは file コマンドで確認できるし、objdump -d コマンドで逆アセンブルできる。
繰り返すが、ＲＯＦでも実行可能形式でも、シェルコードとして必要なのは、その中の一部分だけ。ちなみに、リンク先の connect.s には未解決シンボルが無いので、アセンブルしただけで必要なシェルコード（機械語）が得られる。
ありがとうございます。
ひとつ、よろしいでしょうか？
アセンブルしてROFファイルを生成。
そのROFにもシェルコードに必要ないヘッダー類がついて
くるなら、そのままでは使えないのでは
と思ったのですが・・・
（未解決シンボルになるようなものが無ければヘッダーも生成されない？）
ＲＯＦにも実行可能ファイルにもヘッダ情報が含まれている。だから原則的に「取り出す」作業は要るのだ。さっさと覚悟しなさい。君が試そうとしているのは、まともなソフトウェア開発ではないのだ。どの部分が必要で、どこが不要なのか、それがわからないならハッキングなど身の程知らずと言うもの。
「シェルコード書いてみた」ページでは「シェルコードの抽出」のところに
$ objdump -M intel -d a.out | grep '^ ' | cut -f2 | perl -pe 's/(\w{2})\s+/\x\1/g'
という操作が記されている。ここで「取り出し」ているではないか。この４段のパイプラインが何なのか、何のためにやってるのか、それぞれのオプションはどんな意味があるのか、他にやり方は無いのか・・・まだまだ先は長そうだな笑。
＞アセンブルしただけで必要なシェルコード（機械語）が得られる。
カスタマイズせずに使用可能なシェルコードが手に入る
という意味だったんですね。
生成されたコード自体すべてシェルコードとして使えるのだと
思ってしまっていました。（笑）
結局は抽出作業が必要不可欠。
ん、となると
実行可能ファイルからではなく
ROFファイルから取り出すメリットとはなんでしょうか？
さあ？君にとって取り出し作業がいくらかでも楽かどうか、かな？
わかりました。とりあえずやってみます。
nasmについて知りたいのなら(nasmに言及してない)人に頼るのではなくまずはマニュアルを見ることです
https://www.nasm.us/xdoc/2.14.02/html/nasmdoc2.html#section-2.1.2
https://www.nasm.us/xdoc/2.14.02/html/nasmdoc7.html
ありがとうございます。
マニュアルがあったんですね。。。
あなたの回答
tips
プレビュー
