【エラー対応】しばらくぶりにWiresharkを触ったら「インターフェースが見つかりません」になった話

VulnHuvで落としてきたマシンへの攻撃ログをキャプチャするためにNpcapと死闘を繰り広げている

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) October 5, 2019

 VulnHubで落としてきたマシンへの攻撃ログを見たくなったので久々にWiresharkを開いたわけだが、「インターフェースが見つかりません」と表示されてしまい、キャプチャできなかった。ちなみにWindows。とりあえずWiresharkをダウンロードしなおすことに。しかし...

npcapのダウンロード終わらん

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) October 5, 2019

 数時間放置しておいたがなかなかNpcap0.9983のダウンロードが終了しない。インストーラの諸々をよく読んでみると、Npcap0.994ないし0.995がダウンロードされている状態だとアップデートがクラッシュするらしい。0.995の方をマニュアルでアンインストールする必要があったのでその時に使ったコマンド等々を以下に羅列しておこうと思う。なお、コマンドプロンプトは管理者権限。

> sc.exe   config   npcap   start=disabled

> sc.exe   config   npf   start=disabled

この後に再起動し、コントロールパネルの「プログラムと機能」から当該バージョンのNpcapをアンインストールし、デバイスマネージャからNpcap Lookup Adapterを削除。この後でWiresharkを入れなおしたらインターフェースが表示されるようになった。

【Rev・バイナリ解析関係】バイナリアン的Photoshop.JPG【バイナリ解析】

このブログのタイトルはある程度人生経験を積んだ人にしか響かないかもしれない...

ちなみに当方は電波少年シリーズを見たことがない。

ちょっと精神的に病んでいた時に「バイナリを眺めて心を落ち着かせよう」と思ったのが事の発端。JPGファイルのExifをいじってみたので記事に残しておこうと思う。今回使用した画像（当方が所属してる山岳部の写真データから適当に引っ張ってきたのを使ってます。ゴメンナサイ...）にはジオタグが保存さてなかったので、書き換えたのは撮影日時と撮影機器のメーカーのみ。そのうちジオタグの改ざんもやりたい。（悪用禁止）

準備

バイナリエディタを使う。

forest.watch.impress.co.jp

ビットマップも見れる＆ファイルの比較ができるので重宝している。vimを使いたい方はどうぞご自由に。ここではBzの詳しい使い方は省略する。

書き換える

※バイナリを眺めながらなんとなく書き換えたのでもっとスマートなやり方、他に書き換えるべきところなどあるかもしれません。教えていただける方などいらっしゃいましたら当方のtwitterまでお願いします。

今回使う画像はこれ

まぁ、ブログの名前がyamanobori_programingの日記となっているので、申し訳程度の登山要素ということで...

この画像をBzで開くとExifっぽいものが色々見つかる。

つまるところここを書き換えてしまえば画像情報を改ざんできるはず。

書き換えた画像がこれになる。

「撮影日時くらいだったらわざわざバイナリの書き換えを行わなくてもwindowsでいじれるじゃないか（困惑）」と考える人もいるかもしれない。実際、windowsのフォトで開いてからファイル情報のところで撮影日時を変更できる。ぱっと見では撮影日時だけ変更されたように見えるが、変更前後のファイルを比較してみると、比較後のファイルはサイズが小さくなっている。Bzで比較してみると分かるが、本来Exifが保存されているべきオフセットからExifが消えている（あるいは、余計なバイト列が挿入されて、他のバイト列が削除されたのかもしれない。）。いずれにせよ、改ざんしたことがすぐに発覚してしまうことに変わりはない。一応、ファイル情報から撮影日時を変更した画像も載せておく。

今度気が向いたら（というか公務員講座につかれたら）ジオタグの改ざんとPNGのExif（Exifじゃないけど）の書き換えをやりたい。PNGについても少し見てみたが、ぱっと見では撮影日時などの情報っぽいものは見つからなかった。何かしらでエンコードされているのかもしれない。

EOF

【勉強会等参加記録】セキュリティキャンプ全国大会2019に参加してきたお話【セキュリティキャンプ】

この前（いつ？）の記事でセキュリティキャンプの選考を通ったお話をした。事前課題晒しについては、過去記事参照。

yamanobori-programing.hatenablog.com

さて、どこから話そうか...

きっと事前準備の段階から話していくのがセオリーだと思うのでそこら辺から話そう。

事前準備

上の記事でもお話した通り、マルウェア解析トラックの選考を通過したので、キャンプ当日までにいろいろと準備をしなければいけなかった。準備したものは

• 名刺
• 事前課題
• モチベーション

こんなもんだろうか...

一つづつ思い出しながら備忘録的に書いていこうと思う。

名刺はとにかく個性的なものにした方がいいというアドバイスがあったのでこんなものを作った。

 ｼﾞﾂﾊﾁｮｯﾄｷﾆｲｯﾃﾀﾘｽﾙ...

作成の構想自体は割と早い段階からできてはいたけど実際に作ったのはキャンプの前々々日くらいだったりする。

事前課題については正直不完全燃焼だった。事前課題に完全に目を通し終わったのは、講義当日の午前2時だったりする。事前課題の進捗はともかく、この事前課題を一通りやっただけでは（少なくとも僕は）当日の演習でなかなかマルウェアの解析が進まなかったりするので、来年時間がある人はn周してみればいいと思います（）

あと、事前課題に全く手を付けていないと本当に当日何もできないようです。

モチベーション。多分一番大事。どんなに当日を楽しみにしていたとしても、私生活で色々あったりすると何も手につかなくなったりするので...。僕は前日にランニングと筋トレをしまくることで精神的なつらさを肉体的なつらさで上書きすることでモチベーションを保ちました（？）

あと、自分がなぜキャンプに応募したのかとか、なぜセキュリティやってるのかとか考えてみるのもよいと思う。

おまけ。キャンプ直前大喜利大会。

当方セキュリティキャンプ初参加なのでよく分からないのですが、何か持っていったほうが良いものってありますか？ pic.twitter.com/9IPxnZq4cp

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) August 12, 2019

キャンプ期間

DAY1

 例のアレ

シベリア送り5ルーブル pic.twitter.com/Ir9yU2YprA

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) August 13, 2019

 昼食をとって、そこでちょっと名刺交換をした。その後の講義では技術技術した講義はあまりなかった。法律の講義は想像してた異常に面白かった。名刺交換タイムではいろんな人と名刺を交換したが、インターネットの住人だと思ってた人が普通に存在することを観測出来てよかった（？）あと、地元県民も割と観測できたので良かった。一通り日程を終了した後は部屋にこもってひたすら事前課題意を追いかけて、就寝したのは2時くらいだった気がする。

DAY2

7時くらいに起床。

初日の朝食。バイキング形式だったので無限に税金を摂取できるとかキャンプ前は考えていたがそんなことはなかった。（以降ご飯の写真が存在しないので他の人の記事を見て💛）

講義は時間にして12時間、4時間区切りの3セットでひたすら（途中座学的なものもあったが）マルウェアを解析した。CTF形式でマルウェアについての情報を多く集めた人ほど得点が多くもらえるようになっていた。あまりにも自分の出来が悪すぎて「みんな⊃∋⊃∋だぁ（脳死）」になってた。キャンプ終わったらもう一度事前課題見直そう。あと、積読と化した「アナライジング・マルウェア」を早くPOPしてあげなければ（使命感）。教室解放の時に軽く自己紹介の時間があったため予備自衛官補やってる話をしたのでその後はなんとなくその関係の話になった。まぁそこら辺の話をして広報活動を行うのも予備自衛官補たるの責務のうちだと思っているので責務を果たせてよかった（技術的な話あまりできてない...）

この時に聞いた話で面白かったのは（明日の講義でも話には出るが）シンボリック実行の話で、これ出来たらRev無敵状態なのでは？とおもった。あと、令和CTFのシェルコード問題の作者の人がいてビビった（？）2日目は結局午前3時位まで次の日の講義で使うVMと格闘してから寝た。

DAY3

前日に引き続いて何とか絶起を回避した。何とか明日も回避できそう（フラグ）

午前の講義は「Reverse Engineering Malware - Know Your Enemies」。主にIDAを使ってマルウェアを静的解析したのだが、IDAは過去のCTFでもあまり使ったことがなかったので少し心配だったが、講義を受ける中で使い方も把握できたし、今まで知らなかった機能とかもしれたので良かった。講義を受けて一番印象に残ったのは、講師の先生がアセンブリコードをほとんど飛ばして読んでいたこと。（応募課題の問6隅から隅まで読んできたのに...）あと、自分がWindowsについてあまりにも知らなさすぎるので、というか、技術的に深く語れそうなものがあまりないので良くないと思った（語彙力)。

???「これから毎日IDAを使ってマルウェアをマルハダカにしようぜ？」

↑うまいことを言ったつもりなので来年のAトラックの講義名に採用して下さい。

午後の講義は「難読化されたマルウェアの解析」。（そういえばブログの下書きのところに難読化に関する記事があるのでこれを機にネットの海に放流してあげよう）もともと難読化に興味があったのでこの講義は割と楽しみにしていた講義の一つ。釣書では難読化の解除や回避に焦点が当てられているように書かれていたが、実際には難読化手法について細かいところも教えてもらい、非常に濃くて参考になる講義だった。ホームルームの時にもこの講義についての質問がいくつか出てたしやはり皆興味がある分野なんだなぁと思った。僕もこの時に難読化について質問させていただき、コンパイラと難読化ソフトウェアの関連を再認識する事が出来た。あと、質問の後に昨年の資料を頂いたのでゴリゴリ読んでいきたい。あと、講義中で講師の方が「応募課題の問6完答できた人はリバエン力高いと思う」って言ってたの聞いてちょっとうれしかった…//実際、あの問題完答できた人は少なかったとは言ってたけどどうなんですかね？

今日は、明日の講義の事前課題がなんとなく終わっているので12時位には眠る事が出来たと思う。なお、キャンプに来てこの時初めてベッドで寝た（今まで椅子で寝てた）

DAY4

なんか夢を見てた気がするけど、看護婦さんに起こされました。（昨日のフラグを見事に回収した）キャンプで寝坊すると、看護婦さんが事前通告なしに起こしに来てくれます。医療従事者がスタンバイしているあたり、多分そういうことです。起きてすぐ講義に向かったので、寝ぼけていたためか降りる階を間違えて看護婦さんに嘲笑されてしまった...

あと、朝食で税金を摂取し損ねたのちょっと悲しかった（朝食のメニューは割と気に入っていた）

4日目の午前の講義は「つくって学ぶ、インターネットのアーキテクチャと運用」。今まで自分がやってきた分野とは全く違う分野のお話だったので、やはりちょっと理解が追い付いてない部分がある。もう一度スライド見直そう...（あと、絶起すると高確率で講義中に眠くなるので来年受ける人は・・・夜更かし・・・やめようね）

最終講義は「実践トラフィック解析」という名の「ハニーポッター養成講座」。はい。会場で流れてるパケットと、非常に治安の悪いパケットを見せていただいたのですが、後者はヨハネスブルグとロアナプラが片一方が消滅するまでやりあうレベルの治安の悪さでしたねぇ...どんなパケットが流れてたかはNDAがあるので言えませんが、実際に流れてる悪性のパケットを発見してしまうと、「もっと極悪なパケットを見つけてみたい」と思ってしまいますねぇ。来年参加しようとしてる方には是非受講して欲しい講義の一つです。そしてキャンプが終わったらハニーポットを運用しよう。

講義が一通り終わったら、最後の晩餐をすました後に「ラストナイトイベント」なるものがある。

「ラストナイトイベント」を実施しました！参加者のみなさんに向けて、講師のみなさんから受講者のみなさんへのプレゼントです！もらった本に筆者のサインをもらっている人もいました！ #seccamp pic.twitter.com/oZUTmHMFkP

— セキュリティ・キャンプ (@security_camp) August 16, 2019

 これです。無料で講義を受けさせてくれた上にプレゼントまでくれるなんて・・・！

牛（ヌー）

ありがたいですねぇ。

戴いた書籍

上の4冊を頂きました。ありがとうございます。

就寝時間は覚えていないが、少なくとも人権がある時間に寝た覚えはない。そして、今朝のことがあったので例に漏れず椅子で寝た。

DAY5

実績:
First blood pic.twitter.com/h1rdg0ZCuO

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) August 16, 2019

 起床処理安全確保支援士合格しました（早く起きすぎて朝食まだだった...）

朝の府中刑務所の匂いは格別だ

朝食後に最後のグループワークを行った。やりたいこと全然違うのに同グループになってくれた方、ありがとうございました_(._.)_今後の更なる活躍をお祈りします。

グループワーク後は開発コースとかネクストキャンプとかジュニアコースの「本当に⊃∋⊃∋の人たち」による成果発表があった。強い、強すぎる...

弊は難読化に興味があるため、難読化ソフトウェアを作ってみたいと思い、友人とコンパイラの実装を行っているが、成果報告を聞いてモチベーションを得る事が出来た。知らない天井を観測するレベルまで頑張ってみよう。

終了

仮釈放された
（来年はわからん…） pic.twitter.com/oW12akEIMc

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) August 17, 2019

 色々やりたいこととかやらなきゃいけないこととかあるけど、またいつかここに帰ってきたいという意味を込めて仮釈放。

帰路

キャンプ後最速飲酒 pic.twitter.com/qZpDSiDxr2

— Кодаира（コダイラ）🐧.🐴💀 (@kodaira9723) August 17, 2019

 (‘ω’)ｱｻﾋｨ↓ｽｩﾊﾟｧ↑ﾄﾞｩﾙｧｧｧｧｲ↓

感想・今後の予定など

以下感想を取り留めもなく羅列していく。

やりたいことが増えてしまって困った。（ハニポ、マルウェア解析、自作パッカー、Pythonをもう一度まともに勉強する）あと、来る前はチューターとか全く考えなかったけど、⊃∋⊃∋になってチューターとして参加してみたいという気持ちになった。そして、なによりもっと力が欲しいと思った。キャンプに応募した時点では、アセンブリコードをちょっと読解できるレベルの力しかなく、話題のレパートリーが少ないというのを今回痛感させられた。ただ、（言い訳っぽく聞こえるかもしれないが、）アセンブリ言語がちょっと読解できるだけの能力を持ち合わせていたことで、良かったと思えることもキャンプ中にあった。「難読化されたマルウェアの解析」中で使用したツールは、難読化を解除した状態のアセンブリコードを出力してくれる機能を持ち合わせているのだが、その機能のバグを発見して、講師に報告できた時は（ほかの受講生も気づいていたかもしれないが）自分の力に少しだけ自信を持つ事が出来たので良かった。あと、キャンプ後にマルウェアの人たちのSlackに誘ってもらえたので、自分もどんどん有益な情報を集めて放出していきたいと思った。他にもいろいろ思ったことがあったと思うが、思い出したら付け加えていこうと思う。

さて、「アウトプットしないのは知的な便秘」という非常にありがたい言葉がある。今自分が出来るアウトプットって何だろうか？とりあえず、やってみたいこと、やらなきゃいけないことを列挙 して、今後何をやっていくか決めていきたいと思う。

• キャンプの講義まとめ
• Pythoの勉強
• JavaScriptの勉強
• コンパイラ実装
• パッカー自作
• ハニーポット運用
• マルウェア解析
• 公務員講座（<<<?）

この中から、絶対にやらなきゃいけないことを優先的に採択すると

• 公務員講座
• キャンプの講義まとめ
• コンパイラ実装

になる。キャンプのまとめは早々にやってしまおう。

公務員講座については、今までブログで触れてこなかったが、いい機会だと思うので少しだけ時間をもらって語らせてもらおう。

/******************************************/

/*以下指定あるまで興味がなければ  */

/*読み飛ばし推奨　　　　　　　　  */

/******************************************/

当方、セキュリティに興味を持ちだす前（高校生ぐらいの時？）はまぁまぁのミリオタさんだった。他校の人とサバゲーチーム結成して遊んでたりしたが、受験勉強を機にミリオタ趣味とはちょっと離れる。ちょうど受験生だったころに18歳選挙権が施行され、当方も受験勉強の合間を縫って新聞とか読んでいた。元ミリオタさんだったので安全保障には多少敏感だったかもしれない。安全保障とサイバーセキュリティに関する記事を読んでからセキュリティに興味を持ちだしたと思う。そこまで理学部の数学科志望だったのを心機一転工学部の情報工学科志望に変更し、今の大学に落ち着いた。

ここまでがセキュリティに興味を持った経緯。では、なぜ公務員講座を受ける羽目になったのか？

米国のUSCYBERCOM、イスラエルの8200部隊、中国のPLA Unit 61398のような部隊が日本にも存在する。そういった国家機関で働くためには、たとえその実態がエンジニアであろうとも、日本では所定の試験をパスする必要がある。キャンプでも何人かの方には話したと思うが、当方はナショナルセキュリティの方面に興味があるので、技術を磨きつつそっちの試験もパスしなければいけない。そういうわけで現在公務員講座を受講しているわけである。

/******************************************/

/*読み飛ばし推奨区間終了                */

/******************************************/

セキュリティキャンプには是非行っていただきたいですねぇ、はい。セキュリティ畑の人じゃなくても、JKの人とかコンピュータに興味がある人とかは是非行ってほしいです。絶対に新しい発見があると思うし、今後の活動に大いにプラスになると思います。成長したいって人には最高の5日間だと思いました。しかし、選考を通過するのは簡単ではないと思います。⊃∋⊃∋の人たちが全力を投入して課題に取り掛かります。でも、キャンプの課題の評価基準はその人の技術力にはないようです。もし、来年キャンプに参加してみたいという人がいたら、その熱意を保ったまま、来年の応募課題が出るまでいろいろ活動してみるとキャンプの選考如何にかかわらず、自身にとって良い結果をもたらすと思います。

当方文才がイマイチなので、セキュリティキャンプの魅力を伝えるためのうまい言葉が見つからないのですが、ちょっとでも興味があったら、自分が興味のある分野の勉強を自分がやりたいようにやってみて、応募課題に取り組んでみるとよいと思います。

終了

【write-up】令和CTFのRev問題（和暦の流れ）

暫く忙しかったが、先週微妙に時間が出来たので久しぶりにCTFの問題に触った。遥か昔に開催された令和CTFのRev問題を復習したので記事にしようと思う。

.ELFのファイルが渡されて、実行すると文字列の入力を求められる。

例のごとくradareで実行を解析してみる。最初、変数の初期化と思われる条件ループがあり、その後、入力に対する条件ループが2つある。

変数の初期化と思われるループ

入力受付後の条件ループ1

入力受付後の条件ループ2

je命令の後の命令は移っていないが、それぞれsomething_is_wrong関数（入力を間違えたときに出てくる）が呼び出されるか、esp+0x18の値がインクリメントされている。最初の条件ループでは、入力された文字列はesp+0x36から格納されていて、ループ内のアセンブリ言語をゴリゴリと読み進めていくと、

[esp+0x36] xor [esp+0x1c] = [esp+0x22]

となるような入力の時に条件クリアとなるようである。

なので、本来のesp+0x36の値は52 41 59 57 41(=RAYWA)となり、入力としてこれを与えるべきであるということがわかる。2回目のループも同様に考えることで入力すべき文字列を求める事が出来る。

今回も同様にアセンブリ言語をゴリゴリ読み進めていくと

[esp+0x4e] xor [esp+0x28] = [esp+0x2f]

となる時に条件クリアとなり、入力として48 45 59 53 41 59(=HEYSAY)を与えると条件クリアとなる。

【雑記（分類不可）】弊学の教授とSecHack365修了生の方とお話しした話

弊学にはセキュリティを専門とされている教授とSecHack365の一期生の方がいる。

今回、そのお二方とお話しする機会があったので、メモ的に話の内容を記しておきたいと思う。（実は、今回お話を聞きに行った教授は1を聞いたら10を返してくれる方だったのだが、そのことを知らずに質問に行っていろいろな事を教えてもらった。あまりにも情報が多すぎて思い出し思い出し記事を書いている。次からメモを持っていくようにしよう）

あまり技術技術してはいけない（戒め）

見出しだけ見たら過激なブログだと思われてしまいそうだ。要は、技術を学ぶのもいいが、その技術をどの局面で使うか知っていなければ有効に使う事が出来ないし、その面でマネジメントは大事だというお話。（実はこの話は当方が学部1年の時にも聞かされており、そのころはセキュリティから離れたことをやっていたのであまり気にも留めていなかったが、今思えば学部1年の時間があるときにセキュリティマネジメントの勉強でもしてみればよかったのだろうかと思っている。）

既に過去のものとなってしまった概念も復活することがあるので見ておくといいかも？

セキュリティの世界は話題やスタンダードがころころ変わる。ということは、過去に既に話題になったが、大した対策がなされず次の話題に変わられてしまったものや、アイディアは存在したが、予算などの面で実装には至らなかった技術など、あるいは過去に流行った概念は今後復活することが十分にあり得るという話。その一例というか、こんなものを知っておくといいよというお話があったので紹介しようと思う。

ja.wikipedia.org

技術的なお話というよりかはマネジメントよりのお話かな？

日本の「スタンダード」と世界一般の「スタンダードの意味合いの違い

殊日本においては、スタンダードはそのまま「一般的な」とか「とりあえずそれにしておけば大丈夫」的な意味合いで用いられる。一方。ワールド「スタンダード」な意味合いはむしろ「流行」的な意味合いが強い。その意味で、セキュリティにおいて日本的な「スタンダード」は存在しない。（という話だった気がする...。次からメモ持っていこう。）

不当な扱いを受けるバイナリアン達

インターンの募集などを見ていると、ネットワークやTCP/IPについてある程度理解していることが条件にされていることが多いが、「目グレップできます」とか「機械語で会話できます」とかいう人材はあまり求められていないようである。これは、低レイヤーよりな技術がある種の職人技的な側面がある点、そして、低レイヤーなセキュリティよりもネットワークとかweb系のセキュリティを強化する方が効果的であるという側面があるかららしい。ネットワークとかweb系にもてを出してみようと思った（粉ミカン）

セキュリティにかかわる人のセキュリティ

ホワイトハッカーの話になり、セキュリティにかかわる人はメンタルがしっかりしてる人の方が向いているのではないか？というお話。例えば、企業とか公官庁お抱えのハッカーとして働いてる人は、素性が明らかになれば敵対する組織から狙われる可能性というのも十分あるわけで、その面でメンタルが強くないとやっていけないのではないのだろうか？加えて、自分が狙われる分にはまだいいかもしれないが、家族が狙われたときにはメンタル云々の話を通り越してしまうので、もしそういう仕事に就くのなら、雇用主がそういうことも配慮してくれるかを考えて仕事を選ばなければいけないのではないか？（しかし、この話を聞くと、件のセキュリティキャンプも、そういう観点から動向を注視している人もいるんだろうなぁ、と思った。）

公官庁のセキュリティ要員のお話

弊学の教授はたまに公官庁の人と仕事をすることがある。そのことについて聞いてみた。殊警察組織については警察庁がサイバー要員の育成を行い、各県警に人材を派遣しているらしい。ん？兵庫県警と神奈川ｋ・・・おや、誰か来たようだ。

Hardening

当方は普段CTFなどをやっているが、CTFは概ね攻撃を主とする競技であるのに対し、Hardeningという守り一辺倒の競技があるらしい。ちょっとだけ説明すると、運営から（仮想的に）業務を行っているサーバーが与えられ、そのサーバーを攻撃から守りつつ業務を遂行し最終的な売り上げが多いチームの勝利とする競技。

wasforum.jp

キャンパー（に）は気をつけろ

SecHack365にもセキュリティキャンプの修了生はいるらしい。しかし、セキュリティキャンプに出たことで満足してしまっている人もいるらしい。キャンプに出ることもすごいことだと思うし、キャンプ中も今まで知らなかったことに出会ったり、挫折することもあると思うが、それを受けて自分がどうするのかの方が大事だし、むしろそっちの方が成長するというのは分かってはいることではあるが、実際に動けるかは自分次第であり、そういうのも含めて、セキュリティについて語り合える仲間を作ろうね、っていう話なんだろうなぁ、と思った。なかなかうまく話がまとまったてよかった。

【勉強会等参加記録】セキュリティキャンプ2019で提出した課題を晒す【セキュリティキャンプ】

ようやく大学の試験期間が終わったのでセキュリティキャンプの課題晒しをする。こんな回答でもセキュリティキャンプの選考通るけどもっと素晴らしいもの（熱意が伝わるようなもの）を書き上げてね💛

そもそもセキュリティキャンプとは？

www.security-camp.or.jp

まぁここに書いてある通りである。残念ながら年齢制限があるようなので行けるうちに行っておこう。2019年度から新しくセキュリティネクストキャンプなるものが新設されたようで、キャンプ修了生でも25歳以下なら参加できる。修了生じゃなくても修了生と同等の技術があれば参加できるようである。

セキュリティキャンプは主に選択コースと集中開発コースに分かれていて、私は選択コースの脆弱性・マルウェア解析トラックに参加することになった。詳しいことはおいおい書いていくとして、とりあえず私の回答を後悔（？）していきたいと思う。

問1

 
## 問1
あなたが今まで作ってきたソフトウェアにはどのようなものがありますか？また、それらはどんな言語やライブラリを使って作ったのか、どこにこだわって作ったのか、たくさん自慢してください。 

回答

褒められるような出来のものを作成したことはないが、強いて言うなら、学部一年の時に作成した、ロボットの状態を3Dモデルで表示するプログラムとセンサから取得した二酸化炭素濃度をロボットの操縦者に表示するプログラムについて記述したい。ロボットの状態を3Dモデルで表示するプログラムはロボットのモーターの回転数をエンコーダーで読み取り、その値を受け、ubuntu上で動作するROS(Open Roboticsによって開発されたオープンソースソフトウェア。ロボットの開発に融通を利かせるために、開発時にあえてセキュリティの機能を外している)の可視化ソフトであるRviz上に出力するプログラムである。このソフトウェア動かすには、移動をシミュレートするC++のプログラム、ロボットの状態を記述するxmlのコード(URDF:Unified Robot Description Format)と実際にプログラムを起動するためのlaunchファイル(xml)を         作成しなくてはならなかった。当時はやっとC言語の学習を終えたばかりであり、セキュリティ系の知識はおろか、その他情報系の知識が皆無な状況だったので、毎日、その日の講義が終わったら、すぐに工房に向かいQiitaなどに公開されている、過去に同じようなことを行った人の記事を参考にしながら、先に挙げた三つのソフトウェアを作成していった。毎日帰宅が0時を過ぎるような状態だったため、自分の力不足を痛感させられた。また、公開されている技術情報を参考にしたとは言え、そもそも情報がそこまで多くなかったので、ひな型となるソースコードを作成したら、変数に思い当たる値やファイル名を代入して、実際に3Dモデルがrviz上に表示されるのか表示されないのか、表示されたらなぜ表示されたのかなど、完全に手探りの状態で開発を進めていった。また、launchファイルを実行してもrvizが立ち上がらないという問題も発生していたため、対処すべき課題は少ないとは言えなかった。結局、launch後にrvizが立ち上がらない問題はrvizの使い方がよく分かっていなかっために、rvizでの設定が間違っていた。3Dモデルが表示されない問題はURDFで指定したstlファイル(Standard Triangulated Languageの略で、三次元形状のデータを保存する。)が正しいディレクトリに格納されていなかったためだった。とりあえずrviz上に3Dモデルを表示させることは出来たので、次は、その3Dモデルがロボットの動きに連動して、ロボットの姿勢を反映してくれるかどうかを実験した。案の定うまく動いてくれなかった。うまく動かなかった現象としては、rviz上のサブクローラーが実機の運動に連動していない、連動していても実機の運動以上の動きをする、回転軸がずれている、描写時のフレームレートが高すぎて、rviz上に描写すると点滅が発生するなどの現象が発生した。（参考として、ロボットは六つのクローラーで移動し、車体の側面にメインクローラー二つ、メインクローラーの前後両端にサブクローラーが一つづつついている）これらの問題の多くは、シミュレートを行うc++プログラムに問題があると思われたため、プログラムの修正を行っていった。こちらも、rvizにモデルを表示させる時と同様に手探り的な開発になってしまい、c++プログラム内の値をちょうどよくなるように調整していった。結局、大体の挙動の問題は解決したが、サブクローラーの回転軸がずれている問題だけはどうしても解決できず、操縦者がうまく解釈して機体の状態を把握してもらうということになってしまった。二酸化炭素濃度を表示するプログラムは、当初センサーで収集した情報をサーバーを通して取得し、ロボットやその周辺の環境を統合的に表示する環境に表示する予定だったが、その環境の開発が思うように進まず、ターミナル上に表示することになった。Pythonを用いて作成したが、先ほど同様、Pythonについても全く触れたことがなかったので、既に作成済みであったサーバーとの簡単なやり取りをするプログラムを改造して使用することになった。こっちの方は実装はそんなにつまずくことはなかったが、実際にセンサーに息を吹きかけて二酸化炭素ノードが上昇するか実験してみたところ、著しい上昇は確認できなかった。そもそも、開発時点でどのくらい濃度の上昇があったら正しく動作しているか？センサーは本当に正常しているのか？（使用したセンサーが非常に安かったことと、アマゾンのレビューがあまり芳しくなかったため）などの認識が共有されていない中での開発であったので、開発がうまくいったとは言えなかった。何かしらの開発を行うときは、技術的な事柄以外にも、チームメンバーでよく協議することが大切であるということを体験した。これらのソフトウェアは2018年の5/3~5の間に岐阜県大垣市で開催されたロボカップジャパンオープンのレスキュー実機リーグに向けたものであったが、上記の理由で実装はされなかった。これらのことを通して、技術情報を常日頃から収集する必要性を感じた。また、このプロジェクトに参加するにあたって、こういった技術的な事柄を含むプロジェクトは、その内容が本当に好きじゃないと続かないということを実感し、以前から興味を持っていた情報セキュリティに関して、本格的にセキュリティに関する技術を勉強するきっかけになり、新潟大学の独自カリキュラムである、創造プロジェクトにおいて、新たに情報セキュリティに関する技術を習得するためのプロジェクトを設立する契機にもなった。

 はい。出だしから自慢の逆を行っている気がするので、自慢せよといわれたら自慢しよう！私は学部一年の時にはレスキューロボットを開発するプロジェクトに所属していた。他大学のことはよく分からないが、私の大学には講義の一環として、学生が自ら課題を設定し、それに対して取り組むことで技術力の向上を図っていくという講義がある。そのなかでいくつかプロジェクトがあって、その中のレスキューロボットを作るプロジェクトに所属していた。（過去形ということは現在は違うのであって、その話もそのうち出来たらいいと思っている）その時に開発したプログラムについて書いた。ここは個人がどんな経験をしてきたのかで書く内容が変わってくるのでどうしたらいいとかは言いにくいところではあると思うが、興味のある分野の勉強とかを進めてみれば、そのうち何か作ってみたいものが見えてくるのではないかと思う。

問2

 ## 問2
今までに解析したことのあるソフトウェアやハードウェアにはどのようなものがありますか？また、その解析目的や解析方法、工夫した点があればそれらも教えてください。

回答

スマートフォンを充電するついでにMTPを使ってスマートフォン内のファイルを見てみた。ほとんどのフォルダは空フォルダだったので何も得ることは出来なかったが、”.”から始まっているファイルなどからlinuxの名残を感じたり、base64でファイル名がエンコードされているようなファイルを見つけたりなど新しい発見もあり、forensicにも手を出してみたいと思った。ダウンロードフォルダには様々ファイルがあったので見て回っていた。その中にhtmlのファイル（A.htmlと呼称する）があった。見覚えのないファイルだったが、思い当たる節はあったので、あまり乗り気ではなかったがA.htmlを開いてみることにした。しかし、webページは表示されず、表示されたのは文字化けした文字とELFの3文字、そしてwww.php.netへのリンクだった。ダウンロードの途中で何らかの原因により終了したのかもしれないが、A.htmlのリンクを踏んでも明示的に何かダウンロードしている様子はなかった。（A.htmlで検索してみたら一件だけヒットした。）このことから、詳細な解析が必要なのではないかと思い、解析を行うことにした。本当にhtmlのファイルならテキストエディタで開いた時にhtmlの構文が現れるはずだが、vimで開いてもhtmlの構文は得られなかった。fileコマンドを使ってファイルの情報を得ようとしてみたが、エラーが生じたため、readelfコマンドを利用して、より詳細な情報を得ようとした。やはり実行可能ファイルであった。ABIがFreeBSDのものだったので、仮想環境を構築しようと思ったが、FreeBSDのisoファイルが見つからず、環境の構築はできなかった。結局、現在はA.htmlが何者だったのか分からず、今までバイナリ解析を主にやってきたが、forensicsについても興味を持つきっかけになった。

追記

課題7に取り組むにあたり、BZ(バイナリエディタ)を導入したため、BZを用いてビットマップを確認して解析のヒントを得ようとした。他の.htmlファイルや実行ファイルと比較した結果、やはり実行ファイルであるようだった。しかし、ビットマップをまじめに眺めたのがセキュリティキャンプの課題からであるために、ビットマップやフォレンジック調査に関するノウハウの欠如により、それ以上の情報は得られなかった。

 CTFでReversingの問題を解くことはあっても、実際に身の回りのものを解析したことはないなぁ（というか解析していいのか？ちなみに、お山に登るときに持っていくGPSの取扱説明書では明示的にリバースエンジニアリングが禁止されていた）と思いながら、PCで充電していたスマホに手を伸ばしてファイル転送を行ってみたのが事の発端である。実際に解析しなくとも、普段の生活の中で目に入ったものをどんな風に解析しようかと想像してみるのは割といいことかもしれないと思った。

問3

## 問3
ブログやGitHubなど技術情報を公開しているURLがあれば教えてください。またその内容についてアピールすべきポイントがあれば記載してください。

回答

ブログ→https://yamanobori-programing.hatenablog.com/

github→https://github.com/I-love-bin

twitter→https://twitter.com/bot04220350

当初は2018年10月のセキュリティ・ミニキャンプ in 山梨で講師の坂井さんに「ブログとかやってるとアピールポイントが増えていい」と助言されてから始めたものだが、ブログを更新していくうちに毎回読んでくれる読者もでき、セキュリティキャンプの選考を通過するためのブログよりも、技術情報を共有するためのブログという側面も見えてきたので良かった。現在、ブログの内容は主に参加したCTFのwrite-upを掲載している。2019年になってから精力的にCTFに参加しているが、現在CTFには月一回程度のペースで参加しており、参加したCTFで、自分が解いた問題は必ず記事にするようにし、CTFを通じて得られた技術情報をなるべく発信するようにしている。また、CTFに出て、解けなかった問題もあるが、それについての考察も記載しており、write-upを読んでくれた人が新しい知見を得てくれればいいと考えている。また、技術情報を公開するブログとしてはいるものの、趣味で登山を行っているので、そのことについてもたまに記事にしたいと考えている。技術情報のみを記事にすると、そのブログを訪れる人は限られてくるが、技術情報以外の記事を追加することで、普段セキュリティにあまり興味のない人も訪問することになり、セキュリティの話題に触れる機会を提供する事が出来ると思う。今は主にCTFのwrite-upを載せているが、今後はCTF以外の技術的な話題（例えばJVNの脆弱性レポートなどを題材とした話題など）も増やしていきたい。githubは主に作成したプログラムを公開するために使用している。バイナリファイルに加えてソースコードも原則公開しているため、自分では気に留めないようなことを指摘してもらえるかもしれないと考えている。また、オープンソース化することで、訪問した人に新たな知見を提供できるとも考えている。twitterは主に情報収集、情報発信用として活用している。ブログを開設しただけでは多くの人に記事を共有することは難しいが、ブログの更新を、twitterを利用して告知することで、技術情報の共有について効果を発揮していると考える。

 お山の記事も書いていきたいですねぇ。

坂井講師からのアドバイスで始めたこのブログも、もうすぐ200アクセスに届きそうである。某botのフォロワーも増えたので、CTF以外の技術的なトピックも扱っていきたいナリねぇ

問4

 ## 問4
あなたが今年のセキュリティ・キャンプで受講したいと思っている講義は何ですか？（複数可）またそれらを受講したい理由を教えてください。

回答

様々興味のある講義は、脆弱性・マルウェア解析トラック以外にもあるが、今回のセキュリティキャンプで特に受講してみたいと思っている講義は三日目に開催される「Reverse Engineering Malware – Know Your Enemies」、「難読化されたマルウェアの解析」の二つである。というのも、自分は普段CTFに参加しており、特にReversingについて主に担当しているため、現在の自分の力で、どこまで講義についていけるのか？また、自分が今までCTFを通して養ってきたReversingの力は、実際の現場でどのように役に立っているのか？といったことが気になるからである。加えて、元々低いレイヤーのセキュリティに関する技術に興味があり、難読化についても様々調べているのだが、その動作原理というのはよく分からない面もあった。そのため、今回の講義に参加して、少しでも難読化の動作原理や実装についてのヒントを得られれば良いと考えたため。また、三日目、四日目は他トラックの講義にも参加できるようなので、三日目は受講したい講義が選択トラックで設定されているため他のトラックの講義には参加できないが、四日目は他のトラックの講義に参加して知見を深めたいと考えている。具体的には、開発と運用トラックと特別トラックで開講される「つくって学ぶ、インターネットのアーキテクチャと運用」と「実践トラフィック解析」である。というのも、自分は普段ネットワーク系の技術やセキュリティの話題にかかわることが少ないと考えているため、これを契機として、ネットワーク系の話題や技術についても理解、習得ていきたいと考えたためである。また、「実践トラフィック解析」では、ダークネットのトラフィックを観測する。近年話題になっているダークネットはマルウェアの拡散のための利用などの不正な活動に利用されており、ネットワーク技術の習得のほかにも、マルウェアのより広い理解やいままでなんとなくしか知らなかったダークネットの具体テクな理解につなげられると考えたため、参加してみたいと考えた。

 ここは熱意の見せどころなのかな？講義の内容と絡めながら自分が興味を持っている技術について熱く語ってみてみるのも良いのだろうかと思った。

問5

 ## 問5
自分が最も技術的に興味を持った脆弱性をひとつ挙げ、技術的詳細（脆弱性の原因、攻略方法、対策方法など）について分かったことや思ったこと、調査の過程で工夫したこと等を報告してください。その際、書籍やウェブサイトを調べて分かったことはその情報源を明記し、自分が独自に気付いたことや思ったことはそれと分かる形で報告してください。また脆弱性の攻略方法を試す際は、他者に迷惑を掛けないように万全の措置をとってください。

 回答

ヒープオーバーフローの脆弱性について調べ、分からない単語等があれば、その単語が出てきた事項について概観しつつ、その単語についても調べることで、知識を広げつつ、なるべく多くのことについて理解できるように心がけた。この脆弱性について興味を持った背景について、脆弱性といわれてすぐに思いつくのはスタックベースのバッファオーバーフローだが、Security Intelligence Report vol.16によると、近年は攻撃に利用された脆弱性のうちの一割を切っており、代わりにuse-after-freeを用いた攻撃が増加傾向にある。そのために、use-after-freeに興味を持つと同時に、同じくヒープ領域に端を発する脆弱性であるヒープオーバーフローに興味を持った次第である。ヒープオーバーフローは、ヒープ領域に確保された変数に対して過剰な入力を与えることによって、同じくヒープ領域に確保された他の変数が上書ききされてしまうことに起因する脆弱性である。スタックオーバーフローでは過剰に入力を与えた結果、EIPを書き換えることで制御を奪う事が出来るが、ヒープオーバーフローではアドレスの書き換えのみ行うため、GOToverwriteなど他の攻撃テクニックと併用することで制御を奪う。CWE識別番号は122。この脆弱性を利用したwindowsOSにおける攻撃の一例として、Lookaside listを用いた攻撃がある。

[前提] windowsでのヒープの作成と管理等について

C/C++ではmallocやnewを用いてヒープ領域の確保を行うが、windowsのAPIではHeapCreateでヒープ領域の作成、HeapAllocでヒープ領域から特定サイズのメモリ領域の取得、HeapFreeで取得したメモリ領域の解放を行う。また、windowsのヒープ管理は主としてFrontendとBackendからなり、Frontendがアプリケーションと直接やり取りを行い、メモリ割り当ての最適化のために配置されている。WindowsはFrontendにおける機構として、windows XP以前ではLookaside listを、Windows Vista以降はLow Fragmentation Heapをサポートしている。また、Backendは実際にメモリ割り当てを行う。Windowsのヒープ構造について、ヒープの先頭には_HEAP構造体が配置されており、ヒープの管理情報が格納されている。その下には未使用領域や、chunk headerとデータ領域のセットが存在する。ある領域がHeapFreeで解放され、隣の領域が未使用領域であるときにはそれらの連結が行われ、既存の未使用領域は新規の未使用領域に連結される形になるために、未使用領域のリストから削除される。windows XP SP1まではこの時の双方向リストのunlink動作の特徴を利用して攻撃が行われていた。

windows XP SP1までの攻撃手法は、既存の未使用領域のFlinkとBlinkを任意の値に書き換え、その領域が新規の未使用領域に連結されるときのFlinkとBlinkの値の参照をを利用し、関数ポインタの値を書き換えることで任意コードの実行を行う。これに対しwindows XP SP2では対策が講じられ、Chunk HeaderのCookieの導入、Safe unlinking、PEB Randomizationが実装された。Chunk Headerのcookieの導入は、Chunk Headerに8bitの値（Chunkのアドレスから計算される）をあらかじめ書き込んでおき、その値が書き換えられたかどうか確認する。スタックにおけるカナリア領域のようなものであると思われる。文献は見当たらなかったが、スタックオーバーフローを利用した攻撃のように入力をうまく調整して、そこの8bit分だけ値を変えないようにすれば回避が可能なようである。Safe Unlinkingは双方向リストから要素を削除する前に前後の要素のポインタが自分を指しているかを確認し、矛盾がないことを確認する方法である。PEB(Process Environment Block：システム上で動作する各プロセスに一つずつ割り当てられるデータ構造で、当該プロセスが利用しているヒープ情報やファイルの情報、ロードしているモジュールの情報など、攻撃に利用されやすい情報を保持している) Randomizationは、元々PEBが実行中のプロセスのfs:30hのアドレスに常に配置されるようにwindows側で決定されていたものをランダムな配置に変更することで攻撃の成功確率を低下させるという対抗策である。これらの対策について、Lookaside listを用いた攻撃によって無効化できる。Lookaside listは解放済みのメモリ領域を指し示す単方向リストであり、HeapFreeによってメモリが解放される時は、最初にLookaside listによって管理される。HeapAllocでメモリ確保の要求があった際には、最初にLookaside listに未使用領域が存在するか調べ、存在するときはここから返される。Lookaside listについては、単方向リストであるために、Safe Unlinkingが適応されない。加えてChunk HeaderのCookieのチェックがないために、XP SP2以降に実装された対抗策が無効化されてしまっている。そのため、未使用領域のヘッダ領域がオーバーフローによって書き換えられたのちに、二回のHeapAllocが呼び出されると書き換えられたポインタを参照することで任意の領域のアドレスを返す事が出来る。あるいは、未使用領域のFlinkについて、関数ポインタを含むアドレスを指すように上書きし、二回目のHeapAllocでうまい入力を与える事が出来れば、関数ポインタを任意の値に上書きする事が出来る。これを受けて、windows Vistaでは、Low Fragmentation Heapの導入、Block Metadataのランダマイズ、Enhanced entry header cookie、Heap base randomization、Heap function pointer encodingが実装された。これまで利用されていたLookaside listに代わりメモリの断片化を提言するLFHが導入されたため先の攻撃は無効化された。Blpck MetadataのランダマイズによるCokkieを予想したChunk Headerの上書きの回避やEnhancedentry header cookieの導入によるChunk Headerの書き換え検知機能の強化によってwindows XPまでにメジャーであったヒープオーバーフローを利用した攻撃は鳴りを潜めたようである。しかし、当然、これらの対策にもLFHのオーバーフローを利用した_HEAP構造体の書き換えなどといった回避策が打ち出されており、鼬ごっこの様相を呈している。

調査中に気づいたこと

(1)複数のコマンドライン引数について、echoコマンドを用いて実行ファイルに渡す際は、xargsコマンドを用いて

$ echo hoge hoge hoge | xargs ./huga

として実行するとよい。

(2)脆弱性の指標として存在するCVE,CVSS,CWEについて、CVE(Common Vulnerabilities and Exposyres：共通脆弱性識別子)は個々の脆弱性に対して一元的に付与される識別子であり、例えば二つの脆弱性がそれぞれヒープオーバーフローに起因するものであっても、個別の事例ならば個々に特有の識別子が与えられる。CVSS(Common Vulnerability Scoring System：共通脆弱性評価システム)は脆弱性の深刻度に応じたスコアを付与するシステムであり、数字が10に近いほど深刻な脆弱性である。CWE(Common Weakness Enumeration：共通脆弱性タイプ一覧)は、個々の脆弱性がどういった領域の脆弱性なのかについて分類する。すべてのCVEについてCWE IDが付与されているわけではない。

参考にしたページは以下の通り

http://inaz2.hatenablog.com/entry/2014/05/14/011448

Heap-Overflowを用いたGOT-Overwrite攻撃

https://www.atmarkit.co.jp/ait/articles/1408/28/news010.html

Heap-Overflowの概説

https://www.atmarkit.co.jp/ait/articles/1111/18/news146_2.html

PEBに関する説明

https://www.keicode.com/windows/heap-internals1.php

Lookaside listについて

https://www.ffri.jp/assets/files/monthly_research/MR201312_History%20and%20Current%20State%20of%20Heap%20Exploit_JPN.pdf

lookaside listを用いた攻撃について

 ヒープオーバーフローについての脆弱性を調べて報告した。実際に環境を構築して実験できればよかったのだが...

脆弱性についても随時ブログで記事にしていきたいと思う。

問6

## 問6
以下にDebian 9.8（amd64）上で動作するプログラムflatteningのmain関数の逆アセンブル結果(*1)とmain関数で使われているデータ領域のダンプ結果(*2)があります。このプログラムは、コマンドライン引数としてある特定の文字列を指定されたときのみ実行結果が0となり、それ以外の場合は実行結果が1となります。この実行結果が0となる特定の文字列を探し、その文字列を得るまでに考えたことや試したこと、使ったツール、抱いた感想等について詳細に報告してください。

回答

最初に自分が取り組んだことは、実行遷移の解明である。このプログラムの特徴として、実行遷移先がアドレスで明示的に示されていないという点が挙げられる。raxレジスタに格納された値をアドレスとみなして遷移している。raxレジスタを適切な値にするためにはrdxレジスタが用いられる。rdxレジスタには、あらかじめ0x8b4が格納されていて、[rsp-0xc]に格納された任意の値をeaxレジスタに格納、その後rdx+rax*4番地（これは.rodataのアドレスとなる）の値を取得しraxに格納、rdxと足し合わせることで遷移先のアドレスが取得できる仕組みになっている。アドレスの取得方法が分かったので、次は渡された逆アセンブル結果を加工し、IDAやradare2のように、処理の流れを追いやすいように加工した。加工の結果、このプログラムは、主に5つの機能から成り立っていることが分かった。以降、一つずつ詳しく見ていく。最初の部分で、特筆すべき点として、ediが0x2以外の時は、eaxに1を代入して終了している。手元の環境（kali linux 2019.1）でコマンドライン引数を受け付ける環境を作成し、gdb-pedaでediレジスタの変化を観察してみる。渡すコマンドライン引数の長さや数を変えてみた結果、どうやらediレジスタには入力されたコマンドライン引数の個数が格納されているようだということが確認された。よって、この部分では、入力されたコマンドライン引数が（プログラム自身を除いて）一つだけかを確認していると推察される。次の部分ではループ構造になっていて、[rsi+0x8]に格納された値をr11レジスタに格納した後、1バイトずつ走査していき、r11レジスタに格納されている値が0x0の場合、またはループの回数が8回を超えた場合にループを抜け出すようになっている。処理を追ってみると、おそらくrsi+0x8は入力された文字列の先頭番地を表していると思われ、文字列を一文字ずつ格納していき、ヌル文字が現れた時点で格納を終了しているものと思われる。また、試行回数が8回を超えた時点でループを抜け出していることを鑑みると、9文字目以上の文字に特に意味はなく、求めるべき文字列の長さは8なのではないかということが推察される。このことは次の部分で明らかになっていて、次の部分ではループの回数が8以外の場合にはeaxレジスタに1を格納して終了している。次の部分では、特筆すべき点として、xor命令がある。文字列に対する処理として非常に重要な意味を持ちそうである。そして、xor命令の結果は0x593の命令より次のxor命令のために利用されている。この部分では文字列に対する数学的操作を行ってる。この数学的操作の結果を受け、その操作の結果がr10レジスタの内容と等しければeaxに0を格納（具体的にはxor演算を行っている）して終了する。以上のことから、個々の部分は、それぞれ「コマンドライン引数が正しく入力されたかを確かめる部分」、「入力された文字列がヌル文字かを確認する部分」、「入力された文字列が本来の長さかを確認する部分」、「入力された文字列に任意の操作を行う部分」、「操作を行った結果があらかじめ設定されている結果と等しくなっているかを確認する部分」である。以下、「入力された文字列に任意の操作を行う部分」について、さらに詳しく見ていく。具体的には0x6e1から0x5a0、0x588、0x568、0x559から始まる命令である。0x6e1の命令に入る前にr8dレジスタには-0xffffffccが格納されていて、r10レジスタに格納されている値は数学的操作後の値であると考えられ、その値は0xedd5a792ef95fa9eである。rcxレジスタには当初0が格納されている。この値は繰り返しごとにインクリメントされていく。最初、r11dレジスタにr8+rcx*1の値が格納される。その値の下位8bitをもって、入力された文字とのxorをとる。演算結果は[rsp+rax*1-0x8]のに格納され、raxの値はrcxの値に等しい。この時に格納された値はその後、r8dレジスタにゼロ拡張されてから格納される。この操作を繰り返すことで、最終的に0xedd5a792ef95fa9eが生成されればeaxレジスタに0が格納される。ここで、入力される文字列長は8であること、バイトオーダーとして、リトルエンディアンが採用されていることから、入力された文字列の数学的操作の結果は先頭文字から0x9e,0xfa,0x95,0xef,0x92,0xa7,0xd5,0xedに対応していることに気を付けなくてはいけない。以下、実際に入力された文字列を求めていく。当初、r11dには0xffffffccが格納されていて、その下位8bitは0xccである。そのために、入力された文字をXnで表現すると、X0 xor 0xcc = 0x9eであり、X0 = 0xcc xor 0x9e =0x52であり、これはasciiコードでRに該当する。この後、数学的処理の結果(=0x9e)は1を加算された後、次の文字とのxor演算に利用される。同様の計算を行うと以下のようになる。

X1 xor 0x9f = 0xfa

X2 xor 0xfc = 0x95

X3 xor 0x98 = 0xef

X4 xor 0xf3 = 0x92

X5 xor 0x97 = 0xa7

X6 xor 0xad = 0xd5

X7 xor 0xdc = 0xed

これらからXnを求めると、(X0,X1…X7)=(R,e,I,w,a,0,x,1)となり、特定の文字列はReiwa0x1となる。

 あきらめずに最後までアセンブリ言語と格闘しよう。ちなみに、文中に出てくる処理の流れを追いやすいように加工したものがこれである。

github.com

問7

## 問7
### 導入
本課題はSIFT Workstationでfuse-apfsを利用して実施することを想定しています。次のリンクからOVA形式の仮想マシンイメージをダウンロードして調査環境を構築してください。
- https://digital-forensics.sans.org/community/downloads

### 課題
ファイルsample.rawおよびchallenge.rawは暗号化されていないAPFSパーティションをDDでダンプしたイメージデータです。それぞれ1つのAPFSボリュームを含んでおり、3種類の異なるPDFファイルが双方のボリュームに一つずつ保存されています。ただし、challenge.raw は一部のデータが改ざんされており、このままではイメージに含まれるボリュームをマウントしたり、全てのファイルを正しく取り出したりすることができません。
資料apfs101.pdfを参考に、以下の問いに答えてください。なお、回答は全体で最大6,144文字とします。極力簡潔に記述してください。

参考までに、APFSパーティションイメージをapfs-fuseでマウント/アンマウントする場合は、以下のオプションを利用します。
```
# apfs-fuse -s 0 <image file> <mount dir>
# fusermount -u <mount dir>

問7-1

#### 問7-1
challenge.rawをfuse-apfsでマウントできるようにするために修正し、以下の内容を答えてください。
1. 修正箇所のオフセットと修正内容。
2. そのように修正するとマウントできるようになる理由。

回答

書き換えたオフセット

オフセット0x0の4e7a1c850e1fe634をefd8aacfb4dfe089に

オフセット0x20の58を4eに

オフセット0x22の5858を5342に

オフセット0x25の00を10に

オフセット0x28の5a5fを981cに

オフセット0x48のdf3ec0be3c544eeebd31c70a0dc4cfcb0aを658aad5567e246d29b4b49e174dfdeda09に

オフセット0x60の3fを17に

オフセット0x6cのe8を7cに

オフセット0x84の0eを056に

オフセット0x90の0aを52に

オフセット0xa0の3201をec17に

オフセット0x3d8の2003を2701に

オフセット0x524の06を03に

オフセット0x1000のcb4ec5を5392c1に

オフセット0x1004の6c603aをec1b32に

オフセット0x1010の3dを15に

オフセット0x1048の0fを57に

オフセット0x12c8の10を58に

オフセット0x1098の11を59に

オフセット0x10c0の12を5aに

修正理由

pngファイルやelfファイルなどには、それ特有のマジックナンバーと呼ばれるものが存在する。バイナリエディタで開いたときに先頭の数バイトに記されている値は、そのファイル形式特有のものとなっている。今回渡されたrawファイルについても同様のことがいえるものと考え、rawファイルのマジックナンバーについて、情報が見当たらなかったために、apfs-fuseでマウントできるsample.rawとchallenge.rawのバイナリを比較し、差分を修正することでマウントできるようにした。

apfs-fuseを使えるようにするのに手間取った。日本語の解説がなかったのであきらめて英語の文章を読もう。というか英語大事。

問7-2

#### 問7-2
challenge.rawに含まれるボリュームには、sample.rawに含まれるものと同じPDFファ
イルが保存されています。しかし、問1の問題を解決してマウントしても、そのまま
では開くことができないファイルが1つあります。当該ファイルを開けるように
challenge.rawのデータを修正し、以下の内容を答えてください。
1. 修正箇所のオフセットと修正内容。
2. そのように修正するとファイルを開くことができるようになる理由。
3. 回答に至る調査の過程(簡潔に)。

書き換えたオフセット

不明

修正理由

不明

調査過程

まず、マウントしたrawファイルを開き、開けないpdfを特定することから始めた。調査の結果、iir_vol41.pdfのみ開く事が出来ず、エラーの内容はFile type unknown　(application/octet-stream)　is not supportedだった。このことから、pdfファイルのマジックナンバーが改ざんされているのではないかという仮説を立て、バイナリエディタで当該箇所を調査してみたが、マジックナンバーの改ざんは発見されなかった。次に、pdf本体を抽出して比較してみることにした。sample.rawとchallenge.rawからそれぞれiir_vol41.pdfを抽出し、比較してみた結果、challenge.rawから抽出したpdfファイルのバイナリは0x0で満たされていた。なお、sample.rawにおけるiir_vol41.pdfと同様のものと思われるファイルはchallenge.raw内にも存在するため、ファイルアクセス時に参照する情報が改ざんされているものと推定した。しかし、結局どの部分が改ざんされているのか特定することは出来なかった。

正直、この問題が解けなかったので選考とは通過できないと思っていたが、なぜか通過できた。他の人の課題晒しを見ながら復習せねば...

いやぁ、回答がしょぼい...

こんな回答をネットの海に放流して、1000年後の大学入試の試験問題の古典で出されたらどうしよう...

そんなことを思いつつも、どうも課題は技術力を見ているようではないので（技術があるに越したことはないけど）「技術的に難しいから応募は諦めよう...」とか思っちゃってるそこの君！！（誰？）この回答を見て少しでも「自分でも行けそう」と思ってくれればうれしいです。そして完答できなくとも、課題に取り組むことでセキュリティについて今までにないくらいに向き合う事が出来ると思うのでやはり取り組んでみてほしいと思います。そして回答に自信がなくてもとりあえず出してみることでもしかしたら選考通るかもしれないし、通らなかったとしても次のアクションのモチベーションにもなると思うので頑張ってください。

【Rev・バイナリ解析関係】PDFをいじめる【バイナリ解析】

前置き

先日、twitterでこんなことを言った。

とりあえずテスト期間終わったらこの前のセキュリティキャンプの課題のwrite-up的なものを書こうと思ってるナリ

— バイナリ大好きbot (@bot04220350) June 2, 2019

 しかし、まだテスト期間は終わってないので、しばらくは何書こうが私の勝手なのである（試験勉強しろ）

まぁ、試験は今期3つしかないのでどうにかなるだろう。そして、この記事を書いてる時点で2つ終了して、次の試験まで割と時間があるのでこの記事を書いている。内容はタイトルの通りである。講義中にPDFの誤りを見つけた教授が「PDFで修正できないため...（ry」と仰っていたが、同じ席に座っていたバイナリアン二人はこう思った「エディタでいじれば修正できるんじゃないか？」

ということで講義が終わり、さっそくエディタでPDFにあんなことやこんなことをしてしまう訳である。具体的には、数か所値を書き換えてみて、どこを書き換えたらPDFの本分に影響を及ぼすのか調べていこうという物である。ちなみに、元のPDFの一部を抜粋すると以下のようになっている。

最初、問題文が書かれていて、その下に考察（貧弱）、問題解決に用いたソースが記述されている。今回はこのPDFに対し、以下の3か所を書き換えた。

書き換える量は、残念ながら適当である。1か所書き換えたら、その都度PDFを開き、どこが変化したか観察する。1回目と2回目の書き換えの結果、本文の内容に変化はなかった。しかし、PDFを開いている間、evinceはこんなエラーを吐き続けていた。

どうも、書き換えの過程で、PDF内でフォントを定義している部分を（そんなところがあったならば）侵食してしまったようだ。ただし、この時点で最初の書き換えと2回目の書き換えのどちらがフォント定義の領域を侵食したのかは分からない。3回目の書き換えで、ようやく本分の書き換えに成功した。

ソースコードの部分とかがごっそり抜け落ちている。

PDFの構造のお話

PDFは、大雑把に言うと以下の構造になっている。

• ヘッダー
• ボディー
• クロスリファレンステーブル
• トレイラー

大雑把に説明すると、ヘッダーはそのファイルがどんなファイル化を識別するためのデータ部分。 ELFなら、ELFを表すデータが格納されているし、ZIPファイルならZIPファイルを表すデータが格納されている。ボディーは文章の内容を表しているようである。インダイレクトオブジェクトと呼ばれるもので構成されていて、インダイレクトオブジェクトにはどんな文章を、どんな大きさで、どんなフォントで表現するかなどが表されている。クロスリファレンステーブルは、インダイレクトオブジェクトがどのオフセットに格納されているかを表している。トレイラーはPDFの最後の部分に現れ、「trailer」、「startxref」、「%%EOF」の順に出現する。（セキュリティキャンプの課題提出までに、このことを知ってたらもっといいとこまで行けたかもしれないと思うと非常に悔しくなる...）。インダイレクトオブジェクトについて、もう少し詳しく見てみると、自分のPDFで、あるインダイレクトオブジェクトは以下のような記述になっている。

14 0 obj 

<</Filter\FlateDecode/Length 1332>>

stream

hogehogehugahuga

endstream

endobj

実際、今回の書き換えでは3つとも全てインダイレクトオブジェクトのstream~endstream間の値を書き換えていたが、なぜか3つ目の書き換えを行ったときのみ本分に影響が出た。インダイレクトオブジェクトはランダムに配置されているようで、本分とインダイレクトオブジェクトの対応が分かれば、PDFの書き換えが出来そうだが、その話はまたいつか。

参考にさせていただいたページ

www.pdf-tools.trustss.co.jp