newbieからバイナリアンへ

newbieからバイナリアンへ

コンピュータ初心者からバイナリアンを目指す大学生日記

【pwn 14.0】 pwnの小粒供養 + 12月だから1年間のpwn勉強を振り返る

 

 

【自動投稿 from 2019.11.29 to 2019.12.08.00:00】

 

1: イントロ

本記事はTSG AdventCalender 2019のエントリとして書かれたものです

昨日は うら さんによる 「TSG LIVE! 4 ライブコードゴルフ大会 writeup + 解き直し ( Perl, sed, Haskell ) - 何か書く」でした

adventar.org

 

 +++++++++++++++++++++++++++++++++

 

2日後にも自分がアドベントカレンダーを書く予定があり

そっちではIPAGCC:GlobalCecurityCamp応募課題のwriteupを既に書き終わっている

 

それでは今回は何を書くかというと

予定のところに以下のように書いてしまった

 

f:id:smallkirby:20191130001540p:plain

 

 

 

だがいい感じに題材となりいい感じに解けるpwnの問題を探せなかったため

HITCON2016 SecretHolderでの小さな気づきをメモして

TSG LIVE!4 で出題したが誰にもふれられなかったKillKirby4Freeの供養をしたあと

もう12月ということで、pwnを始めたりTSGに入ったりと色々あった1年間を軽く振り返る

 

わざわざあどべんとかれんだぁを使って書く内容ではない

2日後の記事はちゃんと書いてあるので許して下さい

 

 

 

 

 

 

 2: sbrk or mmap - SecretHolder - HITCON2016

概要

まず最初の小粒ネタ

bataリストのmedium mediumレベルのpwn問題

HITCON CTF 2016 の Secret Holder を解いていた際のこと

 

この問題では3種類(small/big/huge)の大きさのcalloc()ができ

sizeはそれぞれ0x28/0xfa0/0x61a80となっている

なおcalloc()で確保しているためtcacheからは取られない

 

UAFができる設定なのだが

hugeのsizeが0x61a80と非常に大きいサイズになっているため

heapと別ページにメモリが確保されてしまい攻撃に利用することができない

 

pwndbg> x/3gx 0x6020a0
0x6020a0:	0x0000000000000000	0x00007f9e657c6010 <--hugeのアドレス
0x6020b0:	0x0000000000000000
pwndbg> heap
0x1066000 PREV_INUSE {
  mchunk_prev_size = 0, 
  mchunk_size = 593, 
  fd = 0x0, 
  bk = 0x0, 
  fd_nextsize = 0x0, 
  bk_nextsize = 0x0
}
0x1066250 PREV_INUSE { <--top
  mchunk_prev_size = 0, 
  mchunk_size = 134577, 
  fd = 0x0, 
  bk = 0x0, 
  fd_nextsize = 0x0, 
  bk_nextsize = 0x0
}
pwndbg> vmmap
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
          0x400000           0x402000 r-xp     2000 0      /home/wataru/Documents/CTF/secret_holder/SecretHolder
          0x601000           0x602000 r--p     1000 1000   /home/wataru/Documents/CTF/secret_holder/SecretHolder
          0x602000           0x603000 rw-p     1000 2000   /home/wataru/Documents/CTF/secret_holder/SecretHolder
         0x1066000          0x1087000 rw-p    21000 0      [heap]
    0x7f9e65232000     0x7f9e65419000 r-xp   1e7000 0      /lib/x86_64-linux-gnu/libc-2.27.so
    0x7f9e65419000     0x7f9e65619000 ---p   200000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
    0x7f9e65619000     0x7f9e6561d000 r--p     4000 1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
    0x7f9e6561d000     0x7f9e6561f000 rw-p     2000 1eb000 /lib/x86_64-linux-gnu/libc-2.27.so
    0x7f9e6561f000     0x7f9e65623000 rw-p     4000 0      
    0x7f9e65623000     0x7f9e6564a000 r-xp    27000 0      /lib/x86_64-linux-gnu/ld-2.27.so
    ↓ vmmapで確保された領域
    0x7f9e657c6000     0x7f9e6582a000 rw-p    64000 0      
    0x7f9e6584a000     0x7f9e6584b000 r--p     1000 27000  /lib/x86_64-linux-gnu/ld-2.27.so
    0x7f9e6584b000     0x7f9e6584c000 rw-p     1000 28000  /lib/x86_64-linux-gnu/ld-2.27.so
    0x7f9e6584c000     0x7f9e6584d000 rw-p     1000 0      
    0x7ffe8b2e5000     0x7ffe8b307000 rw-p    22000 0      [stack]
    0x7ffe8b333000     0x7ffe8b336000 r--p     3000 0      [vvar]
    0x7ffe8b336000     0x7ffe8b338000 r-xp     2000 0      [vdso]
0xffffffffff600000 0xffffffffff601000 r-xp     1000 0      [vsyscall]

 




と思っていたら

一度この領域をfree()してもう一度確保してみると

今度はheapが隣接するページに拡張され攻撃に利用できるようになった

 

pwndbg> x/3gx 0x6020a0
0x6020a0:	0x0000000000000000	0x00000000006be260 <--hugeのアドレス
0x6020b0:	0x0000000000000000
pwndbg> heap
0x6be000 PREV_INUSE {
  mchunk_prev_size = 0, 
  mchunk_size = 593, 
  fd = 0x0, 
  bk = 0x0, 
  fd_nextsize = 0x0, 
  bk_nextsize = 0x0
}
0x6be250 PREV_INUSE { <--今度はheapの中から確保されている
  mchunk_prev_size = 0, 
  mchunk_size = 400017, 
  fd = 0x4141414141414141, 
  bk = 0x0, 
  fd_nextsize = 0x0, 
  bk_nextsize = 0x0
}
0x71fce0 PREV_INUSE {
  mchunk_prev_size = 0, 
  mchunk_size = 131873, 
  fd = 0x0, 
  bk = 0x0, 
  fd_nextsize = 0x0, 
  bk_nextsize = 0x0
}

 

ということでコードを読んで原因を探していく

(といってもすぐ終わるのだが)

 

 

sysmalloc()での分岐 - mmap_threshold

hugeは馬鹿でかいサイズのため

_int_malloc()において最後の最後にまで流れ着きsysmalloc()を呼ぶことになる

 

sysmalloc()の冒頭にこのような分岐処理がある

  if (av == NULL
      || ((unsigned long) (nb) >= (unsigned long) (mp_.mmap_threshold)
          && (mp_.n_mmaps < mp_.n_mmaps_max)))
    {
      char *mm;           /* return value from mmap call*/
    try_mmap:
      if (MALLOC_ALIGNMENT == 2 * SIZE_SZ)
        size = ALIGN_UP (nb + SIZE_SZ, pagesize);
      else
        size = ALIGN_UP (nb + SIZE_SZ + MALLOC_ALIGN_MASK, pagesize);
      tried_mmap = true;
      /* Don't try if size wraps around 0 */
      if ((unsigned long) (size) > (unsigned long) (nb))
        {
          mm = (char *) (MMAP (0, size, PROT_READ | PROT_WRITE, 0)); ・・・★
          if (mm != MAP_FAILED)
            {
              if (MALLOC_ALIGNMENT == 2 * SIZE_SZ)
                {
                  assert (((INTERNAL_SIZE_T) chunk2mem (mm) & MALLOC_ALIGN_MASK) == 0);
                  front_misalign = 0;
                }
              else
                front_misalign = (INTERNAL_SIZE_T) chunk2mem (mm) & MALLOC_ALIGN_MASK;
              if (front_misalign > 0)
                {
                  correction = MALLOC_ALIGNMENT - front_misalign;
                  p = (mchunkptr) (mm + correction);
                  set_prev_size (p, correction);
                  set_head (p, (size - correction) | IS_MMAPPED);
                }
              else
                {
                  p = (mchunkptr) mm;
                  set_prev_size (p, 0);
                  set_head (p, size | IS_MMAPPED);
                }
              /* update statistics */
              int new = atomic_exchange_and_add (&mp_.n_mmaps, 1) + 1;
              atomic_max (&mp_.max_n_mmaps, new);
              unsigned long sum;
              sum = atomic_exchange_and_add (&mp_.mmapped_mem, size) + size;
              atomic_max (&mp_.max_mmapped_mem, sum);
              check_chunk (av, p);
              return chunk2mem (p);
            }
        }
    }

 

 冒頭のif分岐では

nb>=mp_.mmap_threshold && mp_.n_mmaps < mp_.n_mmaps_max

かどうかを判定している

すなわち

・要求バイト数がmmap_threshold (malloc_par structure's mem)以上である

・過去のmmap回数がn_mmaps_max未満である

ことを満たすならば★においてmmap()をすることになる

 

★ではMMAPマクロを使っているが実体は以下の通り

#define MMAP(addr, size, prot, flags) \
 __mmap((addr), (size), (prot), (flags)|MAP_ANONYMOUS|MAP_PRIVATE, -1, 0)

 

flagsにMAP_ANONYMOUS(確保領域をゼロクリア), MAP_PRIVATEを付加するだけでただ__mmap()を呼んでいる

 

さてmmap()をするかどうかは要求サイズがmp_.mmap_threshold以上かどうかで決まるとわかったわけだが

このmp_.mmap_thresholdは_int_free()内の以下の部分で変更されている

 

f:id:smallkirby:20191203190728p:plain

malloc.c

 mmap()で確保された領域をfree()する際

(それはchunkのszの下2bit目を見ればわかる)

sizeがmmap_thresholdよりも大きければ

そのサイズにmmap_thresholdを更新している

 

なぜこのような処理をしているか考えた結果

2回mmapされるようなサイズのchunkは それ以降も確保される可能性が高いため

いちいちmmap()で確保するよりもheapの拡張をしたほうが効率がいいのであろうと結論づけた

 

 

これにて、解決

 

 

 

sbrkによるheap拡張

ことはついでなので

要求サイズがmmap_threshold未満である場合の処理についても軽く見てみる

 

以下のコードまで落ちていく

(重要な部分のみを抜き出している)

old_top = av->top;
  old_size = chunksize (old_top);
  old_end = (char *) (chunk_at_offset (old_top, old_size));
  brk = snd_brk = (char *) (MORECORE_FAILURE);
 
  if (av != &main_arena)
    {
     (...snipped...)
    }
  else     /* av == main_arena */
    { /* Request enough space for nb + pad + overhead */
      size = nb + mp_.top_pad + MINSIZE;

      if (contiguous (av)) ・・・①
        size -= old_size;

      size = ALIGN_UP (size, pagesize);
      if (size > 0) ・・・②
        {
          brk = (char *) (MORECORE (size));
          LIBC_PROBE (memory_sbrk_more, 2, brk, size);
        }
      if (brk != (char *) (MORECORE_FAILURE))
        {
          /* Call the `morecore' hook if necessary.  */
          void (*hook) (void) = atomic_forced_read (__after_morecore_hook);
          if (__builtin_expect (hook != NULL, 0))
            (*hook)();
        }
      else
        {
          (..snipped.. mmap()でもう一度確保を試みる)
        }
    (..snipped.. まだまだ本当は処理が続く)

 

avがmain_arena以外の場合の処理は一旦考えないこととする

基本は読んで字の如くだが以下の2点に注意

 

①contiguous

contiguous(av)という処理がある

これはマクロでav->flagsのNONCONTIGUOUS_BITが降りていればtrueを返す

この辺のコンフィグに関してはmalloc.cの冒頭で以下のように定義されている

Options for customizing MORECORE:
    MORECORE                   sbrk
    MORECORE_FAILURE           -1
    MORECORE_CONTIGUOUS        1
    MORECORE_CANNOT_TRIM       NOT defined
    MORECORE_CLEARS            1
    MMAP_AS_MORECORE_SIZE      (1024 * 1024)
    
#define NONCONTIGUOUS_BIT     (2U)

 

この設定によって

MORECORE(==sbrk())によって確保される領域は

old_topと隣接するようになる

よって隣接しているold_topのサイズを引いた分を要求サイズとする

 

②MORECORE

最初にsize>0を確認している

これは_int_malloc()内のnbがINTERNAL_SIZE_T型(unsigned)であるのに対し

_sbrk内のsizeがlong(singed)であるために

あまりに大きいサイズを渡して負数と認識されるのを防ぐためである

(なお_sbrkに渡すsizeが負数だとtopはshrinkされる)

 

あとは上で定義していたMORECOREに飛ぶことになる

この辺MORECOREを何で定義しているかは環境に依るだろうが自分の環境では以下のようになった

pwndbg> bt
#0  __GI___sbrk (increment=135168) at sbrk.c:32
#1  0x00007ffff7a7f199 in __GI___default_morecore (increment=<optimized out<) at morecore.c:47
#2  0x00007ffff7a77dac in sysmalloc (nb=nb@entry=592, av=av@entry=0x7ffff7dcfc40 <main_arena>) at malloc.c:2489
#3  0x00007ffff7a78ff0 in _int_malloc (av=av@entry=0x7ffff7dcfc40 <main_arena>, bytes=bytes@entry=576) at malloc.c:4125
#4  0x00007ffff7a7a4b5 in tcache_init () at malloc.c:2987
#5  0x00007ffff7a7abbb in tcache_init () at malloc.c:2983
#6  __GI___libc_malloc (bytes=65536) at malloc.c:3042
#7  malloc_hook_ini (sz=65536, caller=<optimized out>) at hooks.c:32
#8  0x000055555555469c in main ()

 

__default_morecore()が呼ばれていることになる

これは内部で__sbrk()==sbrk()を呼んで

成功ならその返り値を、失敗ならNULLを返すだけの関数である





ということで軽くsbrk/mmapについて眺めてみた

今後巨大chunkを確保する際には気をつけてみたい






 

3: KillKirby4Free供養

続いて

自分の初pwn自作問題として TSG LIVE!4 で出題した問題 KillKirby4Free

後に複数の人から言われたが

明らかに75分(しかも他pwn2問)で解ける問題ではなかった。。。

 

結果として誰に触れられることもなく終わったため

ここでカービィの供養をすることにする

 

なお他の問題と本問のexploitコードについては以下のエントリで見れる

smallkirby.hatenablog.com

 

 

脆弱性

 登場するkirbyには normal/ small/ bigの3種類がいる

異なるのはkirbyに命名するときのnameバッファの大きさであり

それぞれ0x48/ 0x50/ 可変(>0x50)になっている

 

だが実際の命名部分は以下のようになっている

  printf("Name him! > ");
  if(new_kirby->bufsize!=1){
    if(read(0,new_kirby->name,NORMALBUF)<=0){
      printf("BYE\n");
      exit(1);
    }
  }else if(read(0,new_kirby->name,new_kirby->bufsize)<=0){
      printf("BYE\n");
      exit(1);
  }

 

smallもnormalもNORMALBUF==0x50だけ入力するようになっている

すなわちsmallkirbyの命名時に8byte overflowが存在する

 

しかもsmallkirbyのnameバッファは0x48とmod8==0&&mod16!=0であるために

次のchunkのszを書き換えることができる

この脆弱性をとっかかりに攻めていくことになる



方針

上の脆弱性は以下の3条件を満たしている

・chunkのszを任意に書き換えることができる

・任意のサイズのmalloc()ができる(bigkirbyによる)

・heapのアドレスをleakすることができる(smallkirbyに丁度0x48の命名をする)

よってHouse of Force: HoFを利用することができる

(HoFについてわからない場合は以下を参照)

smallkirby.hatenablog.com

 

 

これで基本的にwrite-what-whereになったわけだ

 

何を書き換えるかだが、まずはlibc_baseをleakしたい

そのためには以下の方法を使ってstdoutのFILE構造体がもつポインタをleakしてもいいが

smallkirby.hatenablog.com

 

この場合はfree()をすることでmain_arena+96のアドレスをheapに出現させたい

本問では kirby_is_free 変数によってfree()が禁止されているため

まずはこの変数を書き換えることでfree()ができるようにしたい

(この辺はTWCTF2019のsecure_karteをちょっとだけ意識した)

smallkirby.hatenablog.com

 

 

 

3回のHouse of Force

 ということで1回目のHoFはkirby_is_freeを書き換えるのに使う

但しHoFではメタデータによって周辺の領域が破壊されることに注意

 

とはいってもこの辺は自分でexploitを書くときに調整しており

stderr辺りに飛ぶと上手いこと必要な情報は破壊せずにchunkを配置することができる

 

さてこれによってchunkをfree()できるようになったわけだが

続いてmain_arena+96をleakしなくてはならない

そのためにはsmallkirbyを捕まえる必要があるのだが

こいつは0x10回に1回しか出現しないため、それまでに数回mallocする必要がある

だが現在のav->topは.dataセクションに置いてあり

あまり沢山のchunkを確保してしまうと破壊してはいけない領域を破壊したり

readonlyな領域にアクセスしたりしてしまうことになる

そのため一度もとのheapに戻る必要がある

 

ということでここで2度目のHoFをする

これによってvalidなheapに戻ったら

smallkirbyを確保して最初と同様の方法でmain_arena+96のアドレスをleakする

 

そうしてlibc_baseをリークしたら最後に__malloc_hookを書き換えるために3回目のHoFをする

ここに特に注意点はない

 

ということでHoFを3回使えば簡単に解ける問題であった

 

 

exploit

先程のブログエントリを参照してもらうか

以下のTSGのgithubに問題バイナリやexploitコードが置いてある

t.co

 

 

 

作問のきっかけ

ということで初めてpwn問題を作った

もとはpwnの勉強中に、問題作ってる人ってどんな気分なんだろうなぁと思ったのがきっかけで

なんとなく自分用に作った問題であったが

丁度TSG LIVE!の問題を募集している最中だったため出題させてもらった

 

作問の際には

まず問題のフレームワーク(この場合kirbyを捕まえていく)を決め

そのあとで使用するテクニック・方針等を決めていった

 

ただし最初からガチガチに方針を決めたわけではなく

まず適当にプログラムを作って

それをどうやったらぱうんできるかを考えてexploitを書いた

つまり、結局は作問をする際もpwnを解く側の気持ちでやっていた

いつもと違うのはそれがexploitableかどうかわからないということと

それから上手く行かないところはexploitコードではなくバイナリ自体を書き換えられるということだった

 

 

 

作問をするのも普通に楽しかったが

そもそも自分みたいにpwnが弱い人間が作った問題は概してクソ問になるため

まずは自身のスキルを上げるところから頑張りたい

 

 

ちなみに

昨日割といい感じの問題(の設定)を思いついたので

機会があったらどっかに出したいです

 

 

 

 

以上、kirbyの供養!!

 

 

 

 

 

 

4: pwnを始めた1年を振り返る

もう12月

今年はTSGに入ったり、pwnを始めたりと割と色々とあった1年だった

アドベントカレンダーに登録したはいいけど書くことが見つからなかったため

以下ではこの1年間をpwn的なことを中心にだらだら振り返っていく

日記とか書くのって、楽しいもんね。。。

 

2012年:C言語との出会い

 ・Hacking: 美しき策謀本を読む

アセンブラどころかCも何も知らずただ名前の響きだけで買って読んだ

何言ってるかわからんかった

 

・30日でできる! OS自作入門 をやる

中2で出会った河合さんのOS本に夢中になり、実際に作ってCDに焼いて動かした

これが初めて使ったC言語(+ちょっとだけアセンブラ、ほぼコピペだけど)だった

自分で作ったのが動くってすげえ、と月並みな感想を抱く

 

Windowsでゲームプログラミング

 以下のサイトを真似して東方チックなシューティングゲームを作った

(東方のことは今でも何も知らないから、キャラをカービィにした記憶がある)

後にも先にも初めてのゲームプログラミングだった

dixq.net

 

・すし打にハマる

すし

 

 

2013年: Windows離れ

・ITパスポートを取る

中3で暇だったのかITパスポートとかいう謎資格を取る

なお同時に漢検5級も取る♥

 

 プログラミング言語を作る をやる

前橋さんのこの本で簡単なプログラミング言語を実装した

割と面白かったことは覚えているが、具体的な記憶が何故か殆ど残っていないという不思議

 

Linuxの存在を知る

なんかLinuxというOSがあるらしいということを知る

かっこよさそうだからという理由で自分のノートPCをWindowsUbuntuデュアルブートにする

ここでUbuntuの使い方は覚えた感

 

PHPとかをやったりWebサイトを作ったり

分厚いPHPレシピ本を買って

HTMLを直書きしてFC2にC言語の学習サイトを作った

今でも存在しているが、見ると穴に入りたくなるためこのまま墓まで持っていく

ここでちゃんと体系だてて勉強していれば今のWebに対する抵抗感はなかったかもしれないのになぁ

 

 

2014年-2016年: あんまPCに触らなくなる

・策略本をもう一度やる

 C言語を2年間触ったあとでもう一度策略本をもう一度やった

攻撃方法等は理解できたし面白かった

この時初めてgdbに触った

 

アルゴリズム本とかネットワークの仕組みとか

理論よりのことを本で読むようになる

実機にあまり触らなかったため、あまり知識は定着しなかった

 

時間の有り余っている高校生のときに

何故もっとちゃんとコンピュータの勉強をしなかったのか

後悔と言うよりも不思議が上回る

あんま高校で同じ分野に興味ある人いなかったんだよなぁ

 

 

2017年: PCをへし折る

・PCをへし折る

高校生でも大学生でもないという摩訶不思議な時空の狭間で

何を血迷ったか大好きだったLenovo Thinkpadを真っ二つにへし折った

へし折る際のコツだが

意外と硬いことに加えて破片が刺さる可能性があるため

布状のものをかぶせた上から、全体重を載せてディスプレイを反対方向に回転させるのがポイント

不思議なことにへし折った後は電源がつかないし、画面にも何も映らなかった

 

この1年間はこれ以外PCに触らなかった

 

 

2018年3月: Pythonとの出会い

・中古PCを買う

なぜかPCがへし折った後に使えなくなったため

中古3万円のdynabookを買い、UbuntuとKali Linuxデュアルブートにした

あと大学用にMacbookも買ったが殆ど使っていない

 

Pythonに出会う

Cとアセンブラしか見たことがなかったが大学に入る上で他にも何か使えたほうがいいと思い、退屈なことはPython本を買って読んだ

Cと比較しての便利さにびっくりした

なお、今自分が書くPythonのコードは8割方 from pwn import * から始まる

 

・知識を取り戻す

長いこと触れていなかった本を読み返し知識を取り戻す

 

 

2018年4月-2019年2月: 何もしない

コンピュータのことは何もしない

とにかく本を読み漁っていた

ショーペンハウアーの日本で文庫本で出ているのは多分全部読んで

村上春樹を2/3くらい読んだ

 

 

2019年3月: TSGに入る/ pwnをやり始める

・TSGに入る

B1の同じクラスにTSGの部長がいて、前々から色々と教わっていた

TSGも名前は聞いたことはあったが、ガチ勢の巣窟で自分なんか入っても淘汰されると思っていた

だが部長が猛プッシュしてくれたこともあり入る運びに

今ではすごく感謝している

 

・pwnの下準備をする

まず"大熱血!アセンブラ"を読んでx86/x86_64を中心とするアーキのアセンブラを読めるようにした

次にハリネズミ本を読んでpwnとはどんな問題なのかを把握した

そこで足りない知識を補うために坂井さんのリンカ・ローダ本を読んだ

それからgdbとlibc/systemcallの知識を深めるため同じく坂井さんのハローhelloworldを読んだ

また、いい機会だと思い策略本をもう一度丁寧に読み返した

そこまで終わるといよいよ常設CTFのpwnable.xyzでpwnを解いていった

はじめは本当に何もわからず、部長やくっきーさんに随時質問して1問ずつゆっくり解いていった

この2人のおかげでpwnに入門することができて、なんやかんや1年が楽しくなった気がする

 

 

2019年4月: pwnable.xyzを解き続ける

・ゆっくりpwnをやる

相変わらず2人に質問をしながらxyzを解いていった

電車の中で考えるのが捗った

全完するつもりでやっていたが、ゆっくりやりすぎたのかxyzの問題サーバが9月頃に死んでしまった

結局これ以上flagを獲得することができず2/3くらいを解いて52位で止まってしまっている

f:id:smallkirby:20191203233337p:plain

xyzのleadersboard



 

 

2019年5月: Seccampの課題をやる

・xyzをやり続ける

以下略

 

・SECCON for beginners CTFをやる

初めて常設じゃないCTFでflagを取る

 

セキュリティキャンプの課題をやる

セキュリティキャンプの課題を解いて出した

前年はレポートをほぼ白紙で出したら落ちたため、今年はなんやかんや5万字くらい書いたら通った

smallkirby.hatenablog.com

 

 

2019年6月: heap問を解き始める

・pwn分科会

 TSGのpwn分科会でmalloc/freeのlibcを読んだ

これきっかけでheap問に対する抵抗感がなくなりheap問を解き始めるようになった

xyzからは若干離れていた

 

自然言語処理

pythonのゼロからディープラーニング本を読んで面白いと思い

画像処理とか自然言語処理にハマっていた

この時期はpwnよりもやっていた

 

 

2019年7月: 何もしない

進振りに振り回される

結局失敗する

 

・Cryptに憧れる

cryptできたらかっこいいなぁと思い結城さんの暗号技術入門とか石井さんのガロア理論頂き本とか雪江代数学とか読んだが続かず

 

CPUの創りかたを読む

CPUつくるとかやってみてぇなぁと思い読んで素子も沢山買ってきたが、はんだ付けが途中でめんどくさくなり放置

 

Kindleで技術書を読むことにハマる

Kindleなら分厚い技術書も電車で読めることに気づき色々と読み漁る

 

 

2019年8月: キャンプに行く

 ・MITのOSの授業

MITの授業で誰でも資料を読めるOSの授業があったから途中までやっていたが途中ですっかり忘れ去った

 

セキュリティキャンプに行く

つよつよの人たちを目の当たりにする

TSGの会ったことなかった人にも会った

授業内容というよりもそういう人たちから刺激をもらえたこととキャンプ後も連絡をとれるようになったことが貴重な機会だった

あとこれきっかけでGhidraをヘビーに使うようになった

 

・キャンプに行く

人と2人で山梨県にキャンプに行った

湖のほとりにある場所でほとんど人がいなかった

自分たちで火をおこして飯を作って夜は星を見た

pwnとかどうでもいいと思った

 

・LinuxKernelに興味を持つ

キャンプで会った人の影響でkernel詳しかったら面白いなぁと思い

詳解カーネルと詳解デバドラを買った

どちらも半端で放置している

 

malware解析に興味を持つ

同じくキャンプで会った人の影響でmalware詳しかったら面白いなぁと思い

PracticalMalwareAnalysisを買った

Windowsわからん太郎になった

けどなんやかんやこれからもちょっとずつ独学でやっていく気がする

 

・TokyoWesterns CTFをやる

TSGの人たちとslackでわいわいしながら問題を解いた

なんも力に慣れずpwnがんばらなきゃなと思った

 

 

2019年9月: bataリストを解き始める

・bataリスト

学部が決まったが特に忙しくなるわけではなく、bataさんのpwn良問リストを解き始める

なんかこの月思い返すと何もしてないな

 

 

2019年10月: 色々なCTFにちょっとずつ参加する

・CTF

TSGとしてではなく個人としてちょっとしたCTFに参加したりしていた

やっぱりリアルタイムでやると緊張感が楽しい

この頃からCTF中に眠くなるとピアスを開けて目を覚ますという悪い癖が付く

 

・CodeBlueに行く

面白い話を聞けたしTSGの昔話を聞けた

すごすごの人たちが本当に実在することを確かめられた

 

・最近の問題を解き始める

bataリストを解いていたところ、部長に最近の問題を解けと言われたため最近の問題を解き始める

 

2019年11月: ずっと試験

・ずっと試験

10月下旬から12月上旬までずっと試験

なんならこれ書いてる今もずっと試験

 

・source-reading分科会

TSGのsource-reading分科会に参加

その過程で初めてkernel問(gnote-TW2019)を解いた

smallkirby.hatenablog.com

 

 

・CTFZone CTF

これもTSGでリアルタイムでわいわいした

オンサイトで集まってやりたかったが引越し準備のため行けなかったのが悔やまれる

これもTWのときと同様何も力になれず、頑張らなきゃと思う

 

 





こう書いてみると

随分うっすい1年間だこと

来年は濃い1年になるよう頑張りたいところですねぇ、はい。





 

5: アウトロ

ということでネタがないのがバレバレな散らばった内容でした

明後日にはGCCの課題のwriteupを書きます

 

明日(12/9)のTSGアドベントカレンダー

kuromunori さんというネコ科人間による

「九九判定プログラムのesoの解説を。><>、GolfScript,Aheui,Tetris(ほんまか)」です

お楽しみに











6: 発狂して湖に飛び込みYoutuberデビューする予定

 

うわああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああいいいいいいい。

げろげろげろげろげろげろげろげろげろげろくえっくえっくえっくえっぽんぽんこつこんぽんぽんこつこつけろけろぐえっ

 うわああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああいいいいいいい。

げろげろげろげろげろげろげろげろげろげろくえっくえっくえっくえっぽんぽんこつこんぽんぽんこつこつけろけろぐえっ





ぼしゃっっ

ちゃぷちゃぷちゃぷ

 

しーーーーん。。。。。

 

 

 

 

 

 

ぶんぶんはろーゆーちゅーぶ

 

 

 

 

 

 

 

 

 

続く