Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hello world(kari)

237 views

Published on

Hello World(kari)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Hello world(kari)

  1. 1. Hello World(kari) @chouett0
  2. 2. attention • 9割妄想 • IT弱者による検証のため間違いを多く含む • 一部検証を省いている部分あり • 30分枠で発表させていただくに値しない内容 • ネタ要素のないスライド • 保険をかけまくらなければ精神を保てない発表者によるLT
  3. 3. …の前に自己紹介
  4. 4. 自己紹介 # Name * Chouett0 (@chouett0) # School * 某横浜の専門学校 # Job * 都内の某所でネットワークエンジニア # Like * Rev * Network ## Interest * Forensic (Under Groundの内容含む) * OS * 機械学習 # HomPage * https://t.co/oMTF3cTyna
  5. 5. # Skil ## Program Language * C/C++ * Python * Scala * Rust * PHP …を少し書ける程度
  6. 6. 要するに
  7. 7. クソザコナメクジ
  8. 8. IT強者に淘汰されることで意味を全うする存在
  9. 9. 以上
  10. 10. 詳しくは先ほどのリンク先を参照してください
  11. 11. Abstract • Cでコーディングしたものは一般的、しかしPythonをexe形式に変換するpy2exeと呼ばれるツール(?)を 使うことで実行ファイルの生成が可能、Rustもコンパイルすることで実行ファイルが生成される • 同じexeファイルで同じ処理をするプログラムであるなら実行ファイルのバイナリも同ような構成にな っているのだろうか? • 仮に異なるバイナリを生成するのならば、どこに差があるのか • バイナリアン(笑)を名乗るのなら其のあたりを解明しようじゃないか
  12. 12. Index • Stirling(と一部stringsコマンド) -> 表層解析以前 • vxPEViewer,stud PE -> PEヘッダー解析 • Ollydbg,IDA -> 静的解析
  13. 13. Index • Stirling(と一部stringsコマンド) -> 表層解析以前 • vxPEViewer,stud PE -> PEヘッダー解析 • Ollydbg,IDA -> 静的解析
  14. 14. C-Python • C-pythonでは、ヘッダーとヘッダー・ボディ間のnullバイト列の空白以外 はほぼ異なるバイナリ • バイナリ列中にIsDebuggerPresentやGetLastError等の一般的な関数が列 挙されている -> Cバイナリにも同じような関数名を列挙した箇所がある • pythonバイナリのヘッダー付近に「python27」等の文字列が現れる -> python側でエラー処理を行っている?(error 等の文字列が多く現れてい るため) -> 相似していないのではなく、python側の処理分ズレている可能性あり( サイズが大幅に肥大化しているのもその影響かも) • 一部タグらしき形式の文字列あり • 最終部辺りで「pyo」等のpython関連と思しき文字列あり
  15. 15. C-Rust • Python同様ヘッダー以外は異なったバイナリ -> 若干python以上に異なる部分が多い • stringsを用いると.idataなどの文字列が多く出力される • GCCなども多くみられる • 前半部はほぼ解読不可なもので、おそらく後半部に重要な処理がある? -> 後半部はrust文らしきものが多くある(implなど) • rust特有の命令(Cではない命令)が含まれている. • error処理が大半 • Python同様、わかる形で「Hello World!」は格納されていない
  16. 16. 表層解析以前までの考察 • どのバイナリもヘッダー以外はほぼ共通の箇所がない • そもそもバイナリサイズが大幅に違う • この時点で最も似通ったバイナリを持ったものを挙げるならば「C-Python」
  17. 17. Index • Stirling(と一部stringsコマンド) -> 表層解析以前 • vxPEViewer,stud PE -> PEヘッダー解析 • Ollydbg,IDA -> 静的解析
  18. 18. • C-Pythonの比較をする前に…
  19. 19. • pyoとかpydって何
  20. 20. • せっかくだからpydも解析してみよう
  21. 21. python関連のファイル解析 • 解析対象 • select.pyd, unicodedata.pyd, bz2.pyd, _hashhub.pyd
  22. 22. .pyd #とは • PythonスクリプトからDLLを生成したもの • 中身は単なるDLLファイル? • DLLならばollyとかで解析できるのでは?
  23. 23. • ollyに投げるとちゃんと読み込む
  24. 24. Select.pyd • vxPEViewを用いると、複数のdllを読み込んでいる模様 -> その一つに「pyhton27.dll」を読み込んでいることから、何らかの関連性がある? -> 「kernel32.dll」はほとんどのバイナリで読み込まれるため省略 -> 「ws2_32.dll」はwinsock2を扱うためのライブラリ -> 「select」という名称から、socket関連のdllかも? -> python27.dllは主に初期化やエラー処理を行う内容? -> socket関連なら初期化・エラーは必要な処理 • その他の要素は普通のdllと差はない
  25. 25. その他のpydファイル • select.pydと同様、python27.dllは読み込まれているが、ws2_32.dllが読み込まれていない点から、上記の仮説は正しいと思われる。 • 同じくpython27.dllが読まれててエラー処理が含まれているが、「format」や「string」 などの文字列操作系の処理と思われる関数が含まれている -> 内部でCやシステムコールラッパ等に変換している? -> PyXX_xxxxxx : XX部が処理の内容(ErrやOS等), xx部がその具体的な処理名 -> snprintfなどのCで用いられる関数も含まれていることから上記の仮説の辻褄があう
  26. 26. pydについての考察 • pythonスクリプトを変換するためのdllであると考えられる • 本来コンパイラによって構文解析を行っているところを、pythonスクリプト からソースコードへ変換した後にコンパイラへ渡す or コンパイラ自身が直接 アセンブリに変換しているのではないか • その為にpython27.dllには何らかの変換処理が含まれているのではないか
  27. 27. • Python27.dllが諸悪の根源なのではないか • ならば解析するのがバイナリアンの宿命 • そうでもしないと内容が薄すぎる
  28. 28. Python27.dll • kernel32.dll, user32.dll, msvcr90.dllなどの一般的によく利用されるdllの他にshell.dllと いうdllが含まれている。 • shell32.dll/shellexecute : 外部アプリケーションを操作する関数 -> 何らかの実行ファイルを実行・終了するために利用する? • pythonスクリプトをexeファイルに変換時にスクリプトで利用される関数を抽出して 新たな小型のdllを生成している? -> pydがそれに該当する? -> もしくは各pydから読み込まれて利用される
  29. 29. Index • Stirling(と一部stringsコマンド) -> 表層解析以前 • vxPEViewer,stud PE -> PEヘッダー解析 • Ollydbg,IDA -> 静的解析
  30. 30. C • 「call 0095154B」を最初に実行しているが、メインルーチンでないため、 おそらく初期化などの処理を行なっている? • 引数として「Hello World」と1(stdout)を渡してcallしている処理があるもの の、実際のメインルーチンではない模様 • ImageBase範囲外で主な処理を行なっている? • メインルーチンと思われる00400000番台のアドレスを経由せず、様々なア ドレスへジャンプしながら最終的にwriteconsoleA関数を呼び出すことで画 面出力を行なっている • アドレス値がImageBaseと異なるのは環境の問題? -> その影響からか、直 接printf関数を呼び出さずにwriteconsoleAを呼び出している? • WriteFile => WriteCosoleという流れから、UNIX系統で用いられるglibの write() => writeシステムコールラッパの構造に似ている? • コンソール上に文字列(Hello World!)を表示させる最終的な関数は WriteConsoleAであり、表面上ではWriteFile関数を呼び出すことで表示させ ている -> WriteFileがWriteConsoleのラッパの役割を果たしている?
  31. 31. import関数 • vxPEViewerでの結果通りkernel32.dllから関数を呼び出している • 一覧内に「WriteConsole」が含まれていることから、おそらくこれが出力する関数
  32. 32. • WriteFile関数を呼び出している • WriteFileは関数名通りファイルへ書き込むための関数 -> UNIXのwrite関数と同じ? -> バッファのサイズと表示文字列のサイズが同一
  33. 33. • WriteConsoleA関数はコンソール上に文字列を表示する関数 • -> これ以上は深く潜れなかったため、おそらくこれが根底の処理であり printf関数の最深部である可能性が高い
  34. 34. C-Python• 開始時点ではCファイルのようにWriteConsole関数もWriteFile関数もない -> 実行していくと WriteConsoleA関数を呼び出す処理がある • _writeという名前で呼び出される -> glibでも存在するwriteシステムコールラッパと同等? • Cファイルとは違い、ImageBase範囲内でコードが実行されている -> Cファイルで最適化無効が 効いてない? • PyEval_EvalcodeEx => PyFrame_New => etc...を経由する処理から、表面上はPython27.dll内で処 理が行われている? -> 内部で様々なpyと付く関数の定義が成されている -> そもそもvxpeViewerで読み込まれていなかったはずが、実際にはアクセスしている点から、 python27.dllはあらゆる関数をpythonスクリプトから変換する役割を持つという仮説の信ぴょう性 が高くなった • printf関数をkernel32.dllからimportしている -> 変換の際に利用されている? • python27.dllで定義されている関数は内部で既存の関数を呼び出している点から標準関数のラッパ である可能性が濃厚 -> ループ処理を繰り返すことで変換を行なっている? -> python27.dllを書き 換えることで任意の処理に改ざんできる? • WriteFileを呼び出して内部でWriteConsoleAを呼び出すルーチンはCと同じ -> PyFile_WriteObjectが一番外側 && ラッパの関数
  35. 35. C-Python • PythonでもC同様にWriteFile関数の呼び出しが行われている
  36. 36. C-Python • 解析を進めていくとpython27.dllを参照している処理がある • この近辺のコードは何度も実行されるようにループになっっているため、 構文解析を行っている可能性が高い
  37. 37. C-Python • python27内でexportされている関数一覧が確認できる • 実際にこれらの関数内に入ってみるとkernel32.dll等の関数が呼ばれている
  38. 38. C-Python • PyFIle_WriteObjectを呼び出している
  39. 39. C-Python • WriteFile (ry
  40. 40. C-Python • こちらも同じようにWriteConsole関数を呼び出している
  41. 41. C-Rust • CともPythonとも異なる初期コードを持っている -> call => jmpという流れは同一 • C,Pythonと違い、エントリーポイントが正常な位置に存在している? -> いくつかアドレス を経由しているが、これまでのファイルよりも本来の処理に近い形をしている • Stirlingでは発見できなかったが、セクション内に「Hello World!」が存在している? • WriteConsoleWを使用している -> 最適化の問題? • Cと異なり、WriteFIleを経由せずに直接(一応Rustではラッパを作成しているかも )WriteConcsole関数を呼び出している -> 自前で関数ラッパを作成している -> vxPEViewerでの仮説が正しい可能性が濃厚 -> ファイルサイズのわりに実行する処理がさほど多くないのも其のため?
  42. 42. C-Rust • わかりづらいものの、「Hello World」を引数として渡していると思われる処理がある • Stirlingでは確認できなかったが、実行後には存在していることから、後から生成された?
  43. 43. C-Rust • WriteFile及びWriteConsole関数を呼び出す処理があることがわかる
  44. 44. まとめ • 各バイナリで関数の呼び出しやラッパの有無等の違いはあるものの、最終的に WriteConsoleを呼び出す点においては同一であると思われる • Python及びRustでは必要な処理以外に変換処理などが行われているせいか、ファイルサイ ズが大きくなってしまうため無駄が多いように感じる • 特にPythonはPython27.dllが必須になってしまうため、実行ファイルの大きさは更に大きく なる他、無駄なファイルアクセスを行なっている可能性がある • Rustでも同じことが言え、無駄な処理が多く存在するためファイルサイズがどうしても大 きくなるが解析時のコード数は比較的小さなものだったため最も実行速度が速い?
  45. 45. http://chouett0note.hatenablog.com/entry/2017/10/01/185600

×