はじめに

この度セキュリティキャンプ2018のトラックAの脆弱性・マルウェア解析トラックに応募し選考を通過することができたので、その際の応募用紙を掲載したいと思います。

なんかのバグでセキュキャン通りました
名前忘れたけどトラックAです
クソ嬉しいです#seccamp #seccamp2018
— 過密 (@kam1tsur3) 2018年6月14日

自分は今まで特にこれといった開発経験がなく30日OS本とN予備校のオンラインテキスト等々を見てプログラミングの基礎を学んだくらいで、とても受かるとも思っていませんでした。おそらく参加者の中では底辺レベルだと思います（これはプロ特有の煽りではなく、ガチのやつ）。言い換えると自分の応募用紙はセキュリティキャンプのボーダーラインと言えると思うので、僕と同じような状況の人のために来年度以降の選考通過をお祈りして、応募用紙を掲載しようと思います。

注）原文を載せているのでかなり見づらいです。どうかご容赦ください。

注）Q6,Q7は答えが違う可能性があります。また他の部分についても間違いがありましたら見つけ次第指摘してもらえると嬉しいです。

応募用紙

Q1:

自分が今まで作ってきたものを自慢する課題です。上にも書いた通り、30日OS本とN予備校のテキストで作ったwebアプリのことを書きました。おそらくここは参考にならないと思うので省略させていただきます。

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

自分は半年前ほどからCTFのPwnを始めて、少しではありますが問題を解いてきました。どれも初心者向けの問題ではありますが、greeting (Tokyo Westerns/MMA CTF 2nd 2016),babyecho(DEF CON CTF Qualifier 2015), pwn200(EBCTF 2013),VillagerA(ksnctf)などです。解析する際のおおまかな流れは、まず静的解析でどの実行環境で動くバイナリか、checksec.shを実行してセキュリティ機構を確認しどの脆弱性の可能性があるかを確認した後、実際に実行して挙動をみたり、デバッガを使ってアセンブラレベルで動作を追って脆弱性を探します。そして脆弱性が見つかったらその脆弱性に対して攻撃を仕掛けて行くというのが流れです。もし解析してる途中に自力でもどうしようもなくなった場合はネットでwriteupを探しそこから少しヒントをもらい、また問題に取り組むようにしています。 CTFでバイナリを解析していると、脆弱性などのセキュリティ面の知識以外にも発見があります。例えば、脆弱性を見つけることができて、バイナリの挙動が分かっても攻撃の標的がわからないことが多々あります。先ほど挙げた中で言いますと、greetingという問題ではGOT Overwrite攻撃ができる脆弱性があるのですが、僕はその攻撃を使ってどこを攻撃してよいかわかりませんでした。そこで詰んでしまいwriteupを見るとプログラムはmain関数が始まる前と終わった後でコンストラクタ、デストラクタという領域にジャンプしているということを知りました。当時の僕は恥ずかしながらコンストラクタ、デストラクタの存在すら知らなかったので非常に新鮮な気持ちになったのを覚えています。このようにPwnをしているとセキュリティの知識だけでなくプログラマとして役立つ周辺知識も身につくのでとても楽しいです。僕の通っている大学の同じ学科の周りの人にもとても技術力の高い人はいますが、低レイヤーに興味のある人がなかなかいません。僕のセキュリティキャンプへの参加を志望する理由の一つもそこにあり、低レイヤ―に興味がある仲間を作ってCTFプレイヤーとして、エンジニアとして切磋琢磨できる仲間が欲しいと考えています。

Q3:

自分のSNSアカウントを載せます。

Q4:あなたが今年のセキュリティ・キャンプで受講したいと思っている講義は何ですか？（複数可）

またそれらを受講したい理由を教えてください。

①E4　Linux故障解析入門 Q1でも述べたのですが、自分は自作OSを作ったことがあります。しかしそれは本当にOSの基礎部分であり、実際に世に出ているOSとは比べ物にならないと思います。僕はこれから、組み込みOSなどの違うアーキテクチャのOSや、何かの動きに特化したOSなども開発していきたいと思っているので、実用的なOSはどのようなメモリ管理、システムコールなどなどを実装しているのかはとても興味があるのでLinuxシステムの動きの理解を深められそうなこの講義はとても惹かれるものがあります。

②E5 Linux カーネル脆弱性入門　大方①のE4と同じ理由です。講義名がもう面白いです。個人的にはyoutubeに上がっている講師の小崎さんのmallocの解説動画がとてもわかりやすくおもしろかったので、小崎さんの話を直接聞きたいなぁという願望もあります。

③A7　本当にわかる SpectreとMeltdown 　自分はQ5の課題のSpectreを選んで調べました。しかし英語のテキストを読んだりしたので、恥ずかしながら理解ができてない部分も多くあると思います。例えば攻撃の例がいろいろ挙げられているのですが、実際のクラウドサービスなどで攻撃ができるとしたら、そのサービスにはどういう条件が必要なのかなどの理解が追い付いていないです。実際の攻撃例は動画で見たことがあるのですが、自分の手元で再現はしたことがなく（再現のプロセスがわからない）、この講義では自分の手を動かしながら動作を追うことができるということで、よりこの脆弱性に対する理解、カーネルの動きに対する理解が深まると思い興味を持ちました。

Q5：

　僕の調べた脆弱性は最近話題になっていたMeltdownとSpectreのうち、Spectreです。　SpectreはCPUのキャッシュを用いたサイドチャネル攻撃と、投機的実行による脆弱性です。キャッシュを用いたサイドチャネル攻撃とはCPUがデータにアクセスする際にキャッシュに乗っているデータとRAMに乗っているデータではキャッシュに乗っているデータのほうが速くアクセスできることを用いた攻撃です。一方で投機的実行は、CPUの命令は命令によって実行時間が違うので、実行時間が遅い命令を待たないで先に次の命令を実行してCPUの動作を高速化する技術です。これがどういう脆弱性を生むのか、この課題の解答の最後にのせた参考資料①の資料からサンプルコードを引用します。

struct array {

unsigned long length;

unsigned char data[];

};

struct array arr1 = ...; / small array */

struct array arr2 = ...; / array of size 0x400 */

/ >0x400 (OUT OF BOUNDS!) /

unsigned long untrusted_offset_from_caller = ...;

if (untrusted_offset_from_caller < arr1->length) {

unsigned char value = arr1->data[untrusted_offset_from_caller];

unsigned long index2 = ((value&1)*0x100)+0x200;

if (index2 < arr2->length) {

unsigned char value2 = arr2->data[index2];

}

サンプルコードにはないのですが１３行目より前にCPUのキャッシュをフラッシュすることが必要になります。投機的実行が問題となるところが９行目のif分です。これは投機的実行のなかでも分岐予測実行とよばれるものが問題となっていて、if文の中身をtrueと予測して１０行目からのコードをif文の結果を待たずに実行することができます。これもSpectreの脆弱性として言われていて、分岐予測は過去のif文の結果に基づいて行われているので、その過去の結果からの予測の仕方も操作できることが分かっています。もしif文の中身のuntrusted_offset_from_callerがarr1->lengthより大きかった場合は１０行目で配列dataの長さを超えて、本来アクセスできないメモリを読みだして変数valueに格納します。１１行目はvalueの最下位ビットが0か1かでそれぞれ0x200か0x300になります。そして１２行目、１３行目が実行されます。ここでif文の結果がfalseだとしても１０行目から１３行目で実行された結果は破棄されますが、１３行目でアクセスしたarr2->data[index]はキャッシュには残ります。そしてこのコードのあとにarr2->data[0x200]にアクセスするようなコードを書き、その実行時間が閾値より短ければarr2->data[0x200]はキャッシュに乗っているのでvalueの最下位ビットは０、遅ければ１という判断ができます（このコードでは前提としてキャッシュのページサイズが0x100以下とします）。ここからは自分が考えたことなのですが、（説明がすでに十分であったから書いてないだけで自明なのかもしれないです）これを同様にして１１行目のvalue&1の1を2,4,8,16,…,128というように順に実行していけば（毎回キャッシュはフラッシュする）valueの値が下から１ビットずつ、最終的には１バイトまるまる分かってしまいます。valueの値は本来アクセスできないメモリのデータであるのでこれは大変な脆弱性となります。ここで一つ疑問に思ったことがあり、valueの値をリークする時なぜ１ビットずつなのかということです。参考資料②のスライドにもあるように配列（上のコードではarr2）の大きさを0xff(キャッシュのページサイズ)にしてしまえば、１度上記のサンプルコードのif文のブロックを実行すれば、arr2->data[x0x100]のxを0から0xffまで繰り返してアクセスの実行時間を計測すれば済みますし、何回もキャッシュをフラッシュする必要もないのではないかと思いました。しかし少し定量的に考えてみると理由が分かってきました。提案した方法だと１バイト読みだすのに最悪の場合で0xff+1回、すなわち256回ループを回すことになります。一方参考資料①のサンプルコードでは１ビットずつ読み出すので、キャッシュフラッシュとif文のブロックを繰り返すことになりますが、１バイト読みだすのに必ず８回のループで済みます。前者の方法ではvalueの値が８以下の時に後者の方法より速くなりますが、0xffまであるうちの8以下なので実行の合計時間が短くなるとは考えにくいです。ただ大きなメモリ空間を攻撃するとなったときには、0x00が続く空間がたくさんある可能性も多くなってくるので、その時にはもしかしたら有効かもしれません。それでも１ビットずつのほうが安定したスピードでリークできますし、実行時間のおおよその計算もしやすいので実用的かと思いました。気になるSpectreの攻撃例と対策ですが、Spectreは現実的な攻撃ではないようです。攻撃ができる条件として、攻撃対象となるマシン上にもともと存在するコードか動的生成したコードをもとに命令ポインタを操作する必要があるので、それは厳しいとされています。もし攻撃が可能であった場合はそのコードが動いているプロセスのアクセス可能なメモリ空間を理論上すべてリークできるようで、カーネル内で実行すればカーネル空間もリークできるので理論上物理メモリすべてリークすることができると言われています。　それではなぜ脆弱性が見つかって早急に対策が急がれたMeltdownではなくSpectreを選んだかというと、これは完全に僕の主観なのですがSpectreのほうが技術的に面白いと思ったからです。キャッシュに乗っているか否かをアクセス時間で判断し、標的のメモリビットを間接的にリークするアイデアにとても感心しました。電磁波解析や電磁波解析など、専門的な知識がないと根本的な理解ができないロマンチックなサイドチャネル攻撃があるなか、このサイドチャネル攻撃はキャッシュの存在を理解していれば理解できるのもとても魅力的でした。

参考資料 ① https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html

② https://speakerdeck.com/sat/tu-jie-dewakaruspectretomeltdown

Q6：

まずmain関数が始まる前にコマンドライン引数の個数（C言語でいうmain関数の引数のint argc）がrdi(edi)レジスタに、コマンドライン引数の文字列が格納されている番地の配列のアドレス(先述のchar **argv)がrsiレジスタに格納されます。命令番地0x4003c0から0x4003e6までの動きとしては、rsp-0x8の中身が指す番地（[rsp-0x8]と表記し、以下も同じように表記します）と[rsp-0x10]に定数を格納することと、ediと0x2を比較し等しくなければmain関数の最後にジャンプするという動きをしています。後者の動きは言い換えればコマンドライン引数の個数が２でなければ１を返り値として(eaxに1を格納して)main関数を終了していることになるので、実行結果を０にするにはコマンドライン引数の個数が２であることが必要条件になります。注意しておくポイントは、amd64のアーキテクチャはリトルエンディアンなので、命令番地0x4003c0,0x4003cdのmovabs命令の結果は[rsp-0x10]には0x0f、[rsp-0xf]には0x0e…というように格納されることです。次に命令番地0x4003e8から0x400402までの動きを見てみます。まず[rsi+0x8]には２個目のコマンドライン引数（以下ではコマンドライン引数と表記し２個目であることを表記しません）の文字列の開始番地が格納されています(argv[1])。これは[rsi]には１個目の開始番地が書かれていて、ポインタの配列の要素のサイズが８バイトであることから分かります。そして[rsi+0x8]をrdx レジスタに格納し、eaxをxor命令を使って０にします。0x4003eeからループする命令で、ecxにeaxの値をコピーし、rax(eax)をインクリメントします。その後[rdx-0x1+rax]の値と0x0を比較し等しくなければまた0x4003eeに戻ります。ループを抜けたらecxと0x8を比較し等しくなければeaxに１を格納してmain関数の最後にジャンプしています。ループを抜けたときraxはコマンドライン引数の文字数より１多くecxはその文字数に等しいです。つまりここでの動作はコマンドライン引数の文字数が８でなければ返り値を１としてmain関数を終了しています。すなわちコマンドライン引数の文字列が８文字であることが必要条件になります。命令番地0x400404では[rdx]をrsiレジスタにコピーします。先ほどrdxには[rsi+0x8]を格納しているので、[rdx]はコマンドライン引数の１文字目であり、[rdx+0x1]は２文字目です。0x400402まででコマンドライン引数の文字数は８文字であり、これは8バイトであるので、0x400404の命令でrsiにぴったりコマンドライン引数の文字が格納されます。注意点としてレジスタrsiの中身の詳細は最下位バイトが1文字目で、最上位バイトが８文字目です。0x400407,0x400409でxor命令を使ってeax(rax)とcl(ecx)レジスタを0に初期化します。ここからループで、0x40040bでrdxにrsiをコピーし、rdxをcl(ecx)ビット右シフトしand命令を使ってedx（rdx）の下位４ビット以外を０にし、[rsp-0x10+rdx]の値（１バイト）をedx(rdx)にゼロ拡張し格納します。その後rdxをcl(ecx)ビット左シフトし、ecxに0x4を足した後raxにraxとrdxの論理和をとります。そしてecxが0x40と等しくなければまた0x40040bにループします。このループで何をしているかというと、コマンドライン引数を最下位ビットから４ビットずつ取り出し、取り出した４ビットの値によって0x4003c0から0x4003dcまでで[rsp-0x10]から[rsp-0x01]までの連続番地に格納した定数8ビットを取り出し（8ビット単位で区切るとすべて上位4ビットが0になっているため実質４ビット）、これをまたraxに最下位ビットから４ビットずつ格納しています。ここで[rsp-0x10]から[rsp-0x01]までの連続番地はテーブルのような役割を果たしています。なぜecxと0x40を比べているのは0x40を0x4で割ると16で、４ビットずつ取り出して、４ビットずつ格納していくのを16回行うと64ビット、すなわちコマンドライン引数の文字列かつレジスタのビット数になるからです。そしてこのループを抜けた先の0x400427では上の命令で4ビットずつ格納していったraxと[rip-0x6e]の排他的論理和をとっています。[rip-0x6e]とはripの値が一つ先の命令番地0x40042eなので[0x4003c0]のことで、これはmain関数の先頭のアドレスから始まる機械語のビット列のことです。リトルエンディアンであることに注意すると[rip-0x6e]の値は0x1000b0d0e0fb848となります。0x40042eから0x40043eではraxと0x600967b3670e0385を比較し等しくなければalに１を、等しければalに0を格納し、alをeaxにゼロ拡張したあと関数を終了しています。つまり実行結果を0にするためには0x400427のxor命令に入る直前にはraxは0x1000b0d0e0fb848と0x600967b3670e0385の排他的論理和、0x61096cbe6901bbcdである必要があります。そのために動作から逆算してうまく0x40040bから0x400422の間のループでraxに格納してあげます。最下位の１バイトは0xcdにする必要があることが分かり、最初に格納したテーブル的役割をもつ[rsp-0x10]から[rsp-0x1]までを見てみると、0xcは[rsp-0x9]に、0xdは[rsp-0xe]に位置します。４ビットを取り出す動作の時にここを参照すればうまくraxに0xcdを格納できそうです。そのために前の命令番地に戻ってみると、0x400414に入る直前にrdxをそれぞれ0xcを参照するには0x7、0xdでは0x2を格納しておけばよいので、0x400404で格納するrsiの最下位１バイトは0x72であることがわかります。これはコマンドライン引数の１文字目であるので、ASCIIコードを直すと１文字目は”r”であることがわかります。残りも同様に計算すると実行結果を０にする文字列は”r3En1gNe”となります。ここまで静的解析しかしてないので実際にコードを書いて動かしてみました。ファイル名の拡張子は.asmで、コンパイルにはnasmとgccを使用しました。またプログラム中に実行結果が出力されることはなくraxのレジスタで判断するしかなかったので、radare2というレジスタの中身まで出力してくれるデバッガツールで動作を追って、main関数の終了の際のraxレジスタの状態を確認しました。問題文と変更した点はintel記法で書いたことと、0x4003c0、0x4003ee、0x40040b、0x400441の命令の前にそれぞれ、main、j1、j2、j3とラベルをつけてjneなどのジャンプ命令のオペランドを命令番地でなくラベルにしたことに加え、コンパイルが通らなかった箇所を何点か変更したので以下に列挙します。

0x4003e6: →jne j3

0x4003f3: →cmp byte[rdx-0x1+rax], 0x0(cmpbだとコンパイルエラーだったため)

0x4003f8: →jne j1

0x400402:　→jne j3

0x400414: →movzx edx, bytersp-0x10+rdx

0x400425: →jne j2

0x400427: →xor rax, main

0x40043e: →movzx eax, al(movzblだとコンパイルエラーだったため)

尚cmpbやmovzblのオペコードの変更はコンパイル後、機械語で同じになっていることを確認しています。　ファイル名をsec.asmとしコマンドラインに

$nasm -f elf64 sec.asm

$gcc -o sec sec.o

$radare2 -d ./sec r3En1gNe

を入力しradare2でステップ実行していくとmain関数の最後のret命令のときのraxレジスタの中身が０になっていることが確認できました。念のためコマンドライン引数を１文字変えてみるとraxレジスタは１になっていたので、”r3En1gNe”が特定の文字列です。　CTFを少しかじっていたこともあり、アセンブラはすんなり解読でき、答えの文字列も早い段階で導きだせました。わからない命令はsetneぐらいだったのでそこは検索して調べました。最初のほうのediとrsiのレジスタの用途を知らなかったのですが、読んだ感じおそらくコマンドライン引数の個数とアドレス番地が入っていると予測でき、検索してみると予想通りでした。一番時間がかかったのがアセンブリプログラミングで、自作OSの際に少しやっていた経験はあったのですが、なかなかコンパイルが通らず、上に書いたように何度か試行錯誤し命令を少し変えたりしてコンパイルを通しました。答えの文字列まで一回でたどり着けたのもとても嬉しかったです。~~答えがreengineをいじったものかなと思ったのですが、iとgが入れ替わっているのでそこを指摘するまでの課題なのでしょうか。~~

(追記）engineerを逆から読んだものでしたね、、、クソイキってしまいました。

実行環境 Ubuntu16.04 ,gcc5.4.0,nasm version2.11.08, radare2 2.4.0

参考にした資料

https://www.simple-teq.net/assembly/assm-14.html

https://qiita.com/MoriokaReimen/items/b316a68d76c1eafa18f8

Q７:

１． USBに使用されるファイルシステムの種類を調べるとFATかNTFSがメジャーであることが分かりました。そこでBzというバイナリエディタで中身をみてみると最初のバイトが0xEB 0x52 0x90の形式をとっていて、これはNTFS ファイルシステムのヘッダであることが分かりました。ちなみにFAT16だと0xEB,0x3C,0x90、FAT32だと0xEB,0x58,0x90であることも分かりました。オフセット1が壊れていた場合FATの可能性もあるのですが以下に続く課題でNTFSであると仮定して進めていくと、マウントできたのでファイルシステムはNTFSであると分かります。

２&3. まずはバイナリエディタでイメージファイルの先頭付近にあるBoot sectorのバイト列を参考資料①と②を見ながら修正をしていきます。まずオフセット3からの４バイトは0x4e,0x54,0x46,0x53に修正しました。このオフセットは3~0xaまでがOEM IDというメンバに位置していて、修正するとASCIIコードで”NTFS “となります。ここはおそらくファイルシステムを判断するのに使用すると思われます。オフセット0xbからの2バイトは0x00,0x02に修正しました。これは1セクタが何バイトかを表すByte/Sectorというメンバで、リトルエンディアンで512を16進数に直した値をいれています。1セクタのバイト数は512が一般的なようなので、この値としました。オフセット0xdは0x08に修正しました。これは1クラスタが何セクタかを表すSector/clustというメンバで、これも一般的と言われている8を入れました。もし何かしらのエラーがでたら、これら二つのとりあえず一般的な値を入れた箇所を見直す必要があるかもしれません。上記の3か所を修正した後FTKImagerというマウントツールを使ってマウントしてみると、目的のpdfファイルiir_vol37.pdfとiir_vol38.pdfの２つが見つかりました。開いてみるとiir_vol37.pdfは開けるのですが、iir_vol38.pdfが壊れているようです。次に$MFTと呼ばれている部分を見ていきます。$MFTとはファイルシステム中のすべてのファイルの情報が書かれている特殊なファイルです。＄MFTが位置するオフセットは先ほど除いたBoot sectorから計算することができて、今回の場合だとBoot sectorのオフセット0x30からの8バイト分の$MFTの開始クラスタ番号であるLogical Cluster of $MFTと呼ばれるメンバ(0x2155)と、上で述べたByte/Sector(0x200)とSector/clust(0x8)をすべて掛け合わせた0x2155000から始まることがわかります。＄MFTの領域0x2155000に飛んでそこから下をずっと見ていくとASCII変換すると“FILE0”から始まるのバイト列のセットが繰り返されているのが分かります。$MFTの最初の4バイトはASCII変換で”FILE”を表す0x46,0x49,0x4c,0x45が固定なようです。つまり0x2155000からはファイルシステムの中のすべてのファイルの$MFTが繰り返されているのだと予想できます。そのまま少し下に眺めていくとオフセット0x2165000に”FILE”ではなく”BAAD”で始まる$MFTがあります。そしてその$MFT内の0x21650daから１バイトおきにiir_vol38.pdfと書かれていているのでこれがiir_vol38.pdfの$MFTだと推測できます。まだ下に行くと0x2165400からは同様の推測方法でiir_vol37.pdfのものと思われる＄MFTがあります。iir_vol37.pdfの$MFTの先頭4バイトは”FILE”だったのでiir_vol37.pdfが取り出せて、iir_vol38.pdfが取り出せなかった理由は先頭の4バイトにありそうです。0x2165000からの4バイトを0x46,0x49,0x4c,0x45に直してマウントしなおすと無事にiir_vol38.pdfを取り出すことができました。

４．上記の過程で取り出した二つのpdfファイルを、実行環境をUbuntuに移し

$sha256sum　　

とコマンドを打つと

iir_vol37.pdfのハッシュ値：

5d62f82532d62645cd67b312546a599d90d15ea09c5ee5dbd61c5d90fc945ad3

iir_vol38.pdfのハッシュ値：

86eb9f1fe34087f709a659b051d4d06930078c72d420683f2bf89455f31eb55f

が得られました。念のためpythonのhashlibライブラリでそれらのファイルのsha256のハッシュ値を計算したところ、結果が一致しました。

実は課題提出期限の8時間くらい前までNTFSではなくFAT16かFAT32のどっちかだと仮定して進めてきていました。それはFATとNTFSのファイルの先頭（オフセット0~2）が同じようなジャンプ命令を表すバイト列であることを考慮せず、FATの資料を見て、これはFATだと決めつけていました。しかしどこのオフセットを見ても0xf8,0xffのようなFATテーブルの先頭のバイト列が見つかず、さらにFAT16か32かの区別さえつかず色々探る日が何日も続きました。なのでNTFSである可能性に気づき、調べてNTFSであることを知ったときは感動した感情が一瞬現れた後、これ提出間に合うのかという焦りが現れ、ヒヤヒヤした時間を過ごすことができました。あっているかはわかりませんが、あきらめずに調べ続けて自分なりの答えが出せて満足しています。

実行環境

Ubuntu16.04, sha256sum 8.25, python 2.7

Windows10, Bz version1.62, FTKImager 4.1.1.1

参考にした資料

①https://qiita.com/kusano_k/items/45b0a86649aabb8040ff

②http://www.writeblocked.org/resources/ntfs_cheat_sheets.pdf

③http://free.pjc.co.jp/fat/index.html

④http://elm-chan.org/docs/fat.html

まとめ

自分は冬休みにとある長期インターンに応募しまして、そこでは当時話題になっていたMeltdownとSpecterの英語の論文を読んで脆弱性を理解するという課題を与えられたのですが、それがQ5に役立ちました。その時は１日オフィスで７時間ぐらい英語の論文を読まされて、「何このクソインターン」「自分何してんだろ」と思い、３日でインターンを辞退したのですが、それが今になって役に立つとは思いませんでした。（ちなみにそれがトラウマでそれ以来インターンには参加してません。またスキルアップのためにインターン参加しようかな。。。） Q6は普段趣味でCTFのPwnを解いているのでアセンブリはすらすら読めました。多分正解していると思います。 Q7は課題締め切り当日まで残っていた課題で、用紙にも書きましたが、１週間くらいFATファイルシステムと思い込んで進めていて、締め切り日に気づいて急いで調べなおしました。あの時の心拍数は尋常じゃなかったです。諦めないって大事ですね。

去年も応募したのですが、その時は全く歯が立たず、文字通り、とりあえず応募したような人間だったのですが、振り返ってみると自分がセキュキャンに通る実感がまだ湧きません。よくこれで通ったなぁという気持ちです。プロの皆さんはセキュキャンがゴールではなくむしろスタートのようなことをよく仰っているのでこれからも精進したいと思います。

最後になりますが、僕にCTFを教えてくれたり、この界隈に引き込んでくれた、同学同学科の界隈のプロの同期（一応名前は伏せておきますが、カンファレンスで登壇するような超プロ）には感謝してもしきれません。本当にありがとうございます。

過密です

タイトルしょうもなさすぎたので変えました

セキュリティキャンプ2018応募課題

はじめに

応募用紙

Q1:

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

Q3:

Q4:あなたが今年のセキュリティ・キャンプで受講したいと思っている講義は何ですか？（複数可）

Q5：

Q6：

Q７:

まとめ

BeginnersCTF writeup

[warmup]condition(pwn)

[Warmup] Simple Auth(Rev)

[Warmup] plain mail(Misc)

[Warmup] Welome(Misc)

てけいさんえくすとりーむず(Misc)

Find the messages(Misc)

BBS (Pwn)