iijlab

IIJlabセミナー: 進化するロギング: デバッグのための古くて新しい技術

IMG_20190122_173812

ロギングはバグを特定するための古典的な手法である.ログとして記録してお
くイベントの品質が,そのままデバッグの効率に直結する.それにもかかわら
ず,従来のロギングでは開発者の経験と勘に基づいて
1) ログを出力するコード上の場所(where to log) と
2) 記録しておくべき情報 (what to log)
をアドホックに決定している.そのため,デバッグ時に必要十分な情報が得ら
れるとは限らず,デバッグを困難なものとする一因となっている.
本発表では,ログの品質を改善する「ロギングコード自動挿入」に関する最近
の研究成果を紹介する.ログの自動挿入はここ数年にわたって活発に研究され
ており,システムソフトウェア研究のトピックのひとつとなっている.既存研
究を概観したのち,発表者等が研究・開発を進めているロギング・ツールK9
について紹介する.K9 はマルチスレッド環境におけるエラー伝播を対象とし
ており,共有データを介したスレッド間でのエラー伝播の追跡を可能とする.
共有データを介したエラー伝播が発生すると,障害を起こしたスレッドのコン
トロールフローを遡っても,障害の原因となったバグにたどり着けるとは限ら
ない.K9 ではそのようなエラー伝播の追跡を支援する.実際に,K9 をLinux
カーネルに適用し,既知のカーネル・バグ 3 種の追跡が可能であることを確
認した.さらに,Linux のファイルシステム保守中に遭遇した未知の障害にも
適用し,バグの特定に有益であることを確認した.

IMG_20190122_174848IMG_20190122_175121

[2019-01-22 18:00]

  • 障害が発生したら(教科書的には): 再現→調査→対策
  • しかし:
    • そもそも再現がむつかしい。
    • 同じ実行環境が手にはいらない。
    • プライバシの観点からデータが手に入らない。
  • かわりのログを送ってもらいログを調査する。
  • しかし:
    • ログが膨大すぎて解析できない。
    • 肝心の手掛かりとなる情報がログにない。
  • 経験と勘に基づいたロギングが原因。
    • システムコールのエラー。
    • 例外的な処理。
    • 気分で入れてるだけ。
    • windows SOSP 2009
    • printf, log4j, syslog event tracing for windows (ETW)
  • 適切なログイングは難しい。
  • 専門用語:
    • logging too little: ログが少なすぎる
    • logging too much (redundant&trivial): 冗長だったり、あたりまえの内容だったり。オーバヘッド・ストレージ使用量が問題になる。
  • ロギングが研究テーマになったのは数年前から
    • 手動から自動へ
    • where to log?: どこに入れるか?
    • what to log?: どんな値を記録すればよいか?
    • what happend?: ログから障害発生の様子を自動抽出して障害の実行パスを類推する。
  • Errlog [Yuan+ OSDI'12]
    • どこでログを入れるか、入れわすれたところに自動でログを入れる。
    • 例外処理:
      • 実際にはログを取り忘れるケースが多い。250件の障害事例を調査。
    • error()を呼んでたらエラー処理というような判定をする。error()を呼ぶ条件式を集めて、ログを入れ忘れているところに追加する。プログラマは無能ではない前提。
  • SherLog [ASPLOS'10]
    • what happend? ログから実行パスを類推する。Sharはシャーロックホームズから。
  • LogEnhancer[ASPLOS'11]
    • 実行パスが類推できるように変数の値をロギングする。
  • K9ではLinuxをターゲットにした。
    • Linux as Infrastructure
    • Linuxは実用的・巨大・複雑なので、Linuxでつかえれば他のソフトでも使える。
  • 用語:
    • fault: =bug 誤りのこと バグがあっても踏まないと発症しない
    • error: バグをふんでおかしくなった状態
    • error propagation: おかしな状態は伝搬する
    • failure: 障害発生(クラッシュ・ハングアップ)
  • Palix:
    • Null: nullチェックもれ
    • Inull(Inconsistent null check): ポインタ参照(deref)したあとにnullチェック(意味がない)
    • Block: ブロックしてはいけないコンテキストでブロックする関数をよぶ
  • linuxにはだいたいいつでも700個くらいバグが残っている。
    • バグをつぶしても同じくらいバグが入ってくる。
    • 1行あたりのバグは減っている。
  • 簡単なバグだけではない
    • 関数にまたいだ問題
    • 割り込み(非同期)
  • Inter-thread error propagation
      • Btrfsでworker threadが例外時にdirtyフラグを落すのを忘れて
      • sync threadがBUG()を踏む
    • direct propagation: スレッド1が共有データを更新して、スレッド2が読む。
    • indirect propagation: スレッド1が共有データを更新して、スレッド2が読んで別の共有データを更新して、スレッド3が読む。
  • K9ではエラー伝搬を解析できるようにログを入れるが、linux規模のソフトでは正攻法は無理。
    • オーバヘッドを押える
    • 静的解析はしない
    • ポインタ解析はしない (やっても正確には分からないことが証明されている)
    • coding traditionを仮定して共有データをさがす。
      • 共有データはヒープに置かれる。
      • 共有データは構造体になっている。
        • そのなかのポインタ配列やリスト構造をみる。
        • リンクリストなどのデータ構造用のライブラリにも対応(対応しないとデータ構造を操作するだけの関数がログに出て呼び出し元が分からない)
    • indirect propagationはデータフローは追い掛けずに型レベルで推測する。
  • ファイルシステムにはバグが多いという論文がある and Btrfsは新しいファイルシステムなのでバグが多く残っているのでは? and 研究室の学生がBtrfsのメンテナ
  • Btrfsで未知のバグをK9で追い掛けた原因をつきとめられた (実証)
  • K9のオーバヘッドは、スループットで1.83%(平均)、CPU利用率で0.32%(平均)。
  • たまにスループットのオーバヘッドが少ないという論文があってもCPU使用率が高いケースがある。その場合はCPUに余裕がないとスループットが悪くなる。

[2019-01-22 19:16]

QA

  • Q: ログを入れたのはファイルシステムだけ?
  • A: yes。だがファイルシステムのコードから呼ばれている関数にもログが入っている。スケジューラとかメモリ管理とか。これら(sched,mem)にはバグが少ないという研究報告がある。クリティカルセクション内でログを吐かないようにすることで、よりオーバヘッドを減らせる余地がある。
  • Q: ロックには注目しないのか?
  • A: ロックの範囲を調べるのが簡単ではないのと、ロックが保護している変数を見つけるのも難しい。ロックもれがあった場合に困る。やってみたが良くなかった。
  • Q: K9の論文は公開されているか?
  • A: 投稿中。
  • Q: オープンソースにするのか? それとも企業に買収されるのを期待しているのか?
  • A: 日立との共同研究なので日立が買う可能性はあるが、オープンソースにする予定になっている。
  • Q: C以外の言語でもつかえるか?
  • A: LLVMの中間言語で解析しているので、言語に特化したものでなければいけるはず。

[2019-01-22 19:24]

IMG_20190122_194128

関連資料?

IIJLabセミナー: 不揮発性メモリ時代のネットワークスタックおよび ACM HotNets 2016 参加報告

image

[2016-12-26 17:59]

講師 本多倫夫氏 登場

[2016-12-26 18:03]P1120351x

PASTE: Network Stacks Must Integrate with NMVM Abstructions

  • NVMMs: non-volatile main memories
  • persistent
  • byte-addressable
  • low latency: 10s-1000s o ns (お値段による)
  • ファイル名が永続化するためのしくみ、とも考えられる。
  • direct mmap()-ed files
  • data structureが変ったらネットワークスタックはどう変るか?
  • case study: WAL(write ahead logging)
    • B-tree(メタデータ)のアップデートは時間がかかるので一旦logに書いてclientにackを返す。
    • データの流れ: client -> server: nic->dram->networkstack->(read)->app->(write/fsync,memcpy/msync)->storagestack->storage->..
    • 実験:
      • NVMe: 2000us。ネットワークはやれることはない。ストレージで律速。
      • NVMM: 42usくらいでおわる。ネットワークでやれることがある。
    • 実際には並列アクセスされるのでNVMMをつかっても(ネットワークだけストレージなしの時よりも)スループット/レイテンシは落ちる。
    • NVMMつかっても、まだまだ永続化するコストがある → メモリコピーによるキャッシュミス
      • rx_buf→app_bufのコピーはapp_bufが固定なので(キャッシュヒットして)コストは安い。
      • app_buf→log_file(NVMM)は毎回違う場所になるのでキャッシュミスしてコスト高い。
      • DDIOがあるのでNIC受信はLLC(last level cache)にいきなりヒットするのでキャッシュミスがすくない。
      • kernel内のmemcpyはユーザ空間のmemcpyに比べて最適化されてない?のでキャッシュミスが多くなる。
    • 受信バッファ(in kernel)をNVMMに置けば解決。/mnt/nvmm/pktbufs とか。ログは /mnt/nvmm/appmd (アプリメタデータ) に。
  • FAST Logging with PASTEP1120352x
    • NICがrecvした段階ではLLCに乗っているだけでflush(clflush)してはじめて永続化する。
    • clflushはキャッシュライン単位でフラッシュする。msyncはページ単位。
    • データはNVMMのポインタをコピーすることでmemcpy回避(コピーするのはメタデータだけにする)。
    • netmapを改造して実装。 pkg-gen -i eth1@/mnt/pmem/bufs -f rx
    • tcp/ipはstackmapをつかっている(先行研究)。
    • ざっくり thruput 10%up, latency 40%up した。
  • 関連研究:
    • NVMM関係ないネットワークスタック(高速ネットワーク)
    • NVMMつかったファイルシステム(高速ファイルシステム)
    • NVMMだけどRDMAつかってネットワークスタック関係ない(HPC系)
  • まとめ:
    • RDMAはどこでもつかえるわけじゃない!
    • 単体で改善するだけでは十分じゃない!

[2016-12-26 18:31]

  • Q: clflushをlazyにできるときもあるとおもうが
  • A: writeのlatencyが長いNVMM(3dxpointとか)もあるので、アプリがLLCをflushするかどうか決めるようにしている。トランザクションの永続化要求はアプリによってちがう。multi-coreのときにスケールしないかもしれないのはfuture work.
  • Q: いま売られているものと今後でてくるものはちがってくるとおもうが、どうなる?
  • A: いま売られているのはbattery-backupedで速いやつなので、3dxpointみたいな遅めのやつでは.. 研究者はfpgaでemulatorかdramで実験している。
  • Q: フラグメントしない?
  • A: ほんとうに保存(リングバッファから別の領域に?)しおわってはじめて回収できるようになる。netmapでdouble bufferingがあるので穴あきもんだいはok。

[2016-12-26 18:39]

Report on ACM HotNets 2016 P1120353x

  • 90人くらいなので学内ワークショップなフレンドリーな雰囲気。
  • frontier network: 辺境の地でのネットワーク
  • MPTCPでマルチホームのときに他のISPにトラフィックをおしつけたり
  • RDMAが流行り
  • datacenterでマルチリンクのときにトポロジをどうするとか
  • RDMAでpriority-basedだとデッドロックしちゃうのでどうしようとか

[2016-12-26 18:48]

  • Q: もりあがってた話題は?
  • A: 発表時間がかぎられているので、どの話題もそれほどもりあがらない。
  • Q: 気になったのは?
  • A: internet blockchain(BGP,DNSをやめようというやつ)がおもしろかった。
  • Q: MPTCP ホットポテト問題? (ホットポテトってこれか?)
  • A: ISP間の公平性の問題提起。appleがECNでREDやってるけどISPでもやるの?とか。

[2016-12-26 18:52]

  • Q: ネットワークスタックをどうかえたい? pullupじゃなくて、とか。
  • A: netmapはlinuxには絶対入らないし、freebsdにはNVMMがないし、アプリ専用のスタックをつくるのは懐疑的(カーネル内のプロトコルスタックは複雑なので触りたくない)。
    • FreeBSD: RAMとして見えるけどpageをどうみせるとかグルーの部分がぜんぜんない。そもそも人がいない...
  • Q: RDMAきらい?
  • A: LLCにRDMAする話はきかないし、あまり議論するつもりがない。(ちなみに会議にはHPC屋はいなかった)
  • Q: DDIOは3種類: 1:ringbufだけ、2:メタデータも、3:ペイロードも。
  • A: ペイロードありで実験している。

[2016-12-26 18:59]

飯田橋駅工事中で、西口に活気がない感じがした。

P1120355x

IIJlabセミナー: Linux Kernel Library: 再利用可能なモノリシックカーネル

image

  • 動機
    • ネットワークシミュレータの研究をしていて、シミュレーションと実機とで二重にコードを持ちたくなかった。
    • Linuxのネットワークコードは618KLoCもある。
    • だからといってシミュレーションするときにLinuxをVMで動かすと遅い。
    • 新しいソフトを使うときにVMで検証してる?
      • マイクロソフトでさえ頻繁に検証するわけではない実態。
    • (一般的にいって)性能と利便性のトレードオフがある。
    • 問題はindirectで解決できるという名言。
  • AnyKernel (NetBSDというOSのrump kernelみたいなもの)
    • clock,memory,scheduler,deviceIO(NIC,blockdev)だけがarchitecture dependで
    • その上にarch independentな層、さらにその上に(改造なしの)カーネルをもってくる。
    • カーネルの上にAPIを被せてアプリケーションはAPI経由でカーネルを利用する。
  • やりかた
    • Arch independentな層を入れたり
    • 抽象的なCPU archを導入したり
  • アプローチ
    • フルスクラッチ: mirage, includeos, seaster, mtcp
      • 性能的に有利
    • 移植: OSv, libuinet, sandstorm
      • 最新版への追従性に難
    • anykernel(移植ではなくそのままもってくる): NetBSD rump, UML, DrawBridge(マイクロソフト製,論文からするとおそらく)
      • カーネル資産をつかえる、最新版への追従性も良好
  • LKL: Linux Kernel Library
    • https://github.com/lkl/linux
    • カーネルのライブラリ化
    • 2007年にルーマニアでスタート(rumpと同時期)
    • IOはいまどきのvertio
    • win32,linux,freebsdなどの上で動作
  • DCE/LibOS
    • 2008年スタート
  • LKL vs LibOS
    • LKLはpthreadでIRQ,kthread,timerを実装
    • LibOSは高位APIをpthreadで実装
  • デバイスイタンフェース: TAP, DPDK, VDE
  • wrapperの規模は2400LoC、CPU非依存
  • ホストOSにはNT,POSIX,MacOS,Linuxがつかえる。
  • LKL APIの種類:
    • (1) LKL syscall: ふつうのsyscallに相当: lkl_sys_hogehoge()
    • (2) Hijack Lib: LD_PRELOADでsocket()をlkl_sys_socket()に曲げたり. linux以外ではsyscall emulatorが必要になる
    • (3) extended(alternative)libc: musl(マスル)。 libcを拡張してアプリに機能を提供。
  • アプリケーションの例
    • ns-3(ネットワークシミュレータ)
      • ns-3の中でLKLを読み込んでネットワークスタックを利用する。dlmopen
      • 実機とちがってタイミングが毎度同じなので再現率100% (仮想クロック使用時)
      • valgrindでデバッグできる。
    • 簡易カーネルバイパス
      • LD_PRELOAD=hogehoge-tcp.so firefox などとして、ホストカーネルとは異なるネットワークスタックをつかってみたり。
    • ext4読み書き
      • windows上でext4のディスクにアクセスする。
    • unikernel
      • 単一アプリにカーネルをリンクする、小さなゲストOS。rumpに似ている。
      • たとえばping6コマンドにLinuxを埋め込むなど。
      • たとえばarm-qemu上でゲストOSを起動しないでpingを実行するとか。(pingにOSがリンクされている)
      • 今日の発表もこれをつかっているらしい。
  • 性能について (UDP 1000B)
    • native kernelがRTT/thruputともにベスト
    • DPDKはRTTがとんでもなく遅い。thruputも低い。
    • netmapとtapはthruputが低い
  • Q:コストは?
  • A: 初期化はふつうのカーネルよりも速い。デバイスの応答を待つ必要がないのと、不要なデバイス初期化をなくせるのとで。メモリフットプリントはとても大きい。おそらく実装の問題。らくらくGB越え。qemuでメモリサイズをGBにしないと動かない。
  • Q: 改造量は?
  • A: IRQ,threadなどだけをposixで実装して、他の下廻りはカーネルのコードをそのままつかっている。
  • Q: 昔のSunのマシンがやっていたメモリリフレッシュとかはどうなるだろう?
  • A: たぶんそのまま動く???
  • Q: ns-3での再現性100%はほんとうか?
  • A: パケットのキャプチャと再生はできるという意味ではyes。実行時のトレースはとっていないので、スレッドのインターリーブによる部分は再現できないだろう。
  • Q: ext4の例はどのレイヤでやっている?
  • A: ディスクイメージをLKLが解釈している。VFSはつかっていない(ホストOSのVFSのことか?)。
  • Q: LKLのデバッグは?
  • A: gdbでカーネルデバッグできる。
  • archLinuxベースらしい。

image

IIJlab: 自動車とインターネットの融合:IoTは自動車から~日本・シンガポールの先端ITS事例

image

image

18:01

  • 大学時代からずっと自動車とインターネットの研究をしている。
  • DSRC:シンガポール ETCみたいなもの
  • 10月にもどってきて日本で聞くキーワード: IoT,bitdata,AI → まさに自動車自動運転。周期でいえば日本は真夏の次期にきている!
  • ITS: 行動道路交通システム。車両・道路・人をITでつなぐ。
  • 車には300以上のセンサーがある
  • アメリカでは車はweareable computingととらえる人もいる。
  • プローブ情報システム: 渋滞(GPSと速度)とか、ABSでヒヤリハット、ワイパーで天候情報とか。 (~2000年くらいまで)
  • VICSの補完のためにあるのかという質問をよく受けた。
  • 車をインターネットにノードとしてつなぐというコンセプトがわかってもらえなった。
  • ABS動作情報: 温度もあわせて凍結路面とか。 複数メーカーでも動くように国際標準をめさして。
  • ABSの情報は自動車メーカーは出したくない。でもABSのwarningランプ情報は出してくれることになった。
  • スバルはOBD2につなぐ車載機をつくってくれた。
  • 実証実験は秋田大学と北海道大学で(雪がふるところで)
  • 3.11で通れた道マップ。
  • 携帯電話にたよっていたが大規模災害で動かない(停電等)ところもあった→車車間通信も必要。
  • 保険でもつかわれている。運転距離ではなくマイルドな運転をしているかどうかで保険料を決められるメリット。
  • 運転手からしても見られているとおもうとていねいな運転になる。
  • カーテレマティクス系: 自動車メーカー主導。
  • ETC2.0: 一定間隔でプローブ情報をなげている。渋滞で迂回路とおっても事故で一般道におりても料金同じになる。
  • 海外では自動車メーカーはやっておらずプラットフォーム系がほとんど。ノキアのHereとTomTom HD traffic。
  • KEIO-NUS CUTE Center
  • シンガポールは世界一車が高い1000万円くらい。(日本だと200-300万円)
  • 慢性的な渋滞が社会問題になっていた→一般道のロードプライシング(ALS,ERP)
  • ERPの特徴: フリーフロー(ゲートがない)、 mandatory(必須)。
  • 駐車場料金にもつかわれている。
  • 三菱重工が一社独占、メンテナンスでけっこうウハウハなのでは?
  • ERP2: 車を増やしたい。GPSでエリアにはいると携帯網経由で決済。ガントリー不要。メンテ不要。時間で課金とか。
  • 政府としては自動車ビッグデータのプラットホームにしたい狙い。車100%に塔載はインパクトがある。
  • デジタルサイネージで実証実験した。
  • 匿名化して民間に提供するのも考えている。
  • safety(安全), productivity(移動中も自由にできる), efficiency(渋滞をなくす), accessibility(身体障害など)
    • automated driviing(自動運転): V2X 路車(ろしゃ)協調ITS, 日本ではただ1箇所 御台場に設置されている。
    • autonomous driving(自立運転): ドライバーレス。 ITSよりはロボット技術。 これには大きな飛躍が必要。
  • "認知→判断→操作" の判断の部分が自動運転で重要になってくる。
  • ジュネーブ条約/ウィーン協定: article 8ですべての自動車はドライバーをもつこと、ドライバーは操作できなければいないことが定められている。
  • autonomous vehicleでもハンドルとブレーキがついてないとだめとの判決がある。
  • AIに人格権をもたせる方向で話しが進むかも(AIがドライバーとの判断. NHTSA)。 (今日のトップニュース!)
  • 今後の問題:自動運転する車が流れに入ってくることで事故を誘発してしまわないか?
  • 標準化活動: ITS2404? プライバシーが重要。 どこをは走っていたとか知られたくない。
  • 自動車メーカーの中でもAPIを切ってオープンにしていくトレンド。
  • ISOだけでなくW3C(業界団体)でも標準化
  • オープンプラットホーム化がトレンド。秩序あるオープンプラットホーム化。
  • パーソナルデータの扱いが課題。

19:51

  • Q: シンガポールで(ロードプライシングは)いくらかかる?
  • A: $1,$2くらい($1=80円) 。エリアに入るたびに徴収されるのでタクシーには不評。エリアに出入りしなければ金はかからない。
  • Q: 完全自動運転の技術的な障害はなにか?
  • A: 限定されたエリアならなんとかできている。地続きで他の国に入れるようなヨーロッパではまだ難しい。(判断(AI)の部分)
    • これについてはグーグルが先行。リスクヘッジしているメーカは遅れがち。
    • センサーの死角を補うために路側からのデータが必要。今は車載センサーだけ。
  • Q: 使うのはインターネットなのか閉域網なのか?
  • A: いまは併用。ITS用の基盤がある(専用の無線帯域とか)。
    • ITSconnectは760MHzだが、海外ではケータイ用の帯域。
    • 5Gでは車車間通信もターゲットにしているので、どうなるか
    • 国の方針とITUの割り当てと。
  • Q:
  • A: ERPはゲートで。ERP2はゲート不要でGPSで位置情報3Gで。
    • DSRC: 車載機が(不正改造などで)動いていなかったら写真とられて罰金、という世界になる。
    • ERP2で路車間通信だけでなく車車間通信できるようになる。
  • Q: LTEだとか公衆網だと信頼性・安全性はどうか?
  • A: そこはDSRCで。(EPR2でケータイ会社は100万契約純増するウハウハ)

19:05

iijlabセミナー: 静的解析と動的解析を組み合わせたバイナリーコードの制御フロー解析手法

_1000085

_1000087_1000088

  • 3月までは産総研
  • バイナリのマルウェアを研究対象にしていた
    • セキュリティではない
    • サンドボックスで実行してトレースをとるのが一般的。
    • でも特定の条件じゃないと動かないものはパスをすべて調べられない。
  • 最低限、CPU/OS/エントリポイントがわかっている状況で調べる。
  • CFG: 制御フローグラフ。ノードは中はジャンプ命令なしのグラフ。
  • CFGがわかる→抽象実行・モデル検査できる。機械学習もできる。
  • でもCFGをつくるのがむつかしい。
  • 難しさ1
    • 間接ジャンプ(RET命令も含む)には値解析が必要だが、値解析にはCFGが必要。ジレンマ。
    • 一般的には静的決定不能。
  • 難しさ2
    • CALL/RETが信用できない。
    • CALLはRETで戻ってくるとはかぎらない。スタックをいじられてしまうと。
    • 部分構造に切り出して問題を小さくして解くのが基本だが、それができない(どこが関数なのかわからない)。
    • →スタックといった抽象化をしないで単なるメモリアクセスとして解釈する。
  • 展開形制御フロー解析
    • 静的解析(直接ジャンプと宛先のわかる間接ジャンプのみを追う)と動的解析(CFGを実行する。CFG静的解析できてないところかコード書き換えがあるまで)を交互に実施。
    • 静的解析必要ないのでは?→動的解析で通らなかったコードについてもある程度わかるので必要。
    • まず静的解析で広い範囲を調べてわからないところを動的解析する戦略。
    • 動的解析にはBochsとXen(Ether)の両方をつかっている。
  • Win32/Rustok.Bの解析例:
    • ドロッパー: マルウェアをインストールするプログラム。
    • ノード: 253、エッジ: 284を20分で解析
  • 静的解析
    • 直接ジャンプをたどってCFGをつくる
    • 各命令を代入文に変換
    • SSAに変換
    • 要求駆動型定数伝搬
      • Φ関数をつかう(複数のところからJMPでとびこんでくるときレジスタの値が一意に決まらないのを解決するのに)
      • 定数になるまでCFGをさかのぼって展開してゆく
      • 引き算が肝らしい
  • Win32 APIの中身は解析しないでAPIブロックを作成。(マルウェアの解析が目的なので)
  • 文字列解析
    • GetProcAddress(module,procname)みたいなやつを静的解析できる
  • ループは静的解析できない。
  • 動的実行
    • Bochs-python + Ether(Xen)
    • シングルステップ実行
    • ブレークポイント
    • 書き込み検知
    • ステルス性(マルウェアに検出されないように)
  • Bochs-python
    • bochsデバッガインタフェースをフックしてpythonからコントロール
  • Ether
    • Xen3.1ベースにイントロスペクションツール
    • SYSENTERでシステムコールをトレースし
    • ページフォールトでブレークポイント
    • シングルステップ実行にはTFを使用
  • Drakvuf/Libvmi
    • Etherは古いので
    • エージェントがなくてもよい

[2015-07-21 18:29]

Q: 動的解析・静的解析が無限に続いて終らない可能性は?

A: 動的解析にはタイムアウトが必要。

Q: C++のような間接ジャンプのあらしだとおもうが?

A: いちおうできている。

Q: マルウェア以外の用途は?

A: コンパイラの素性がわかっていればヒューリステックがつかえる。組込系でハンドアセンブルしたものとかBIOSとかのバッファオーバーフローの解析とか。

Q: 例外ハンドラで書き換えとか

A: 今は動的解析で対応している

Q: コードインジェクションは?

A: スレッドインジェクション(IE)は実験している。

Q: 開発言語は?

A: Pythonで。インタフェースはCで。メモリは喰うが測ってはない。マルウェアはペイロードが小さい前提がある。同じ計算を何度もしないようにキャッシュしているのでメモリが増えてゆく。

Q: 静的解析でいくつか候補を上げておいて動的解析で絞る方法にしないのは?

A: できるだけ抽象度を上げないで発散しないようにしている。

[2015-07-21 18:40]

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • 今日の練習 2019-03-18
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    • FINA/CNSG Diving World Series 2019 Sagamihara,JPN
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ