2017-07-15

ICPC 国内予選 2017

今年もICPC国内予選に参加していました．
ブログには2014年の以外一切書いてませんでしたが一応ずっとnocowで出ていて，2013と合わせるとnocowのメンバーは全員5回目ということで最後の参加になります．

詳しいことはosrehunが書いてくれたのですが， osrehun.hatenadiary.jp 一応最後なので参加記を残しておきます．

メンバーは3年前から同じ

hec (@osrehun)
nokoTaro (@xthexworldx)
icchy (@icchyr)

で，上2人がコーダー，僕は環境構築担当です．

~15:00

練習セッションの存在を完全に忘れていて，僕だけリモート参加

f:id:icchyr:20170715094635p:plain

L問題が残っていたので先にそっちだけやった

M問題は例年通りだと，1回目は何回か試せば通って2回目でほぼ確実に落ちるようになっていたと記憶しているが，今年は1回目が100ケースくらいあって，そもそも手動だとキツイみたいな感じだった．
あと順位表をみると数十回WAしてACしたチームとかがちらほらいたので，Data1が通せればそのままData2も通せるんじゃないかと思った．適当に100通り全探索するスクリプトを書こうと思ったけど，これはCTFではないしサーバーに負荷をかけるのが躊躇われたのでやめた．

15:00~16:00

会場入りして，諸々の準備をした．
チームで使う環境を一新したのでプリンタの設定に手こずった．プリンタの型番と同じドライバが存在しなかったが，適当に似た番号にしたら行けるということをhecが覚えていたのでプリンタ設定AC．

16:00~16:30

僕が急に「やっぱり印刷投げるのいい感じに自動化したい」と言い出す（は？）

lprコマンドでhtmlを印刷 → キレイなhtmlソースが出てくる（それはそう）
Javascriptのwindow.printで印刷ダイアログを自動で出していく（別チームのメンバーが考案） → クリックが面倒なのでダメ

結局htmlを印刷するにはWebブラウザによるレンダリングが必要なので，ブラウザ無しではできない
→ Headless Chrome使えばいいんじゃね？

Chromeにはバージョン59からヘッドレスモードというのが加わっ~~て，これがPhatomJSにトドメを刺し~~た．
ざっくり言うとGUIのウィンドウを作らずにブラウザを立ち上げる機能で，パフォーマンス良くブラウジングを自動化できる．最近ではGoogle CTFのXSS問題とかで使われたりした．

コマンドで書くと

~$ google-chrome --headless --disable-gpu [OPTIONS] [URL]

が基本で，簡単な操作についてはそもそもオプションで使えたりする．

developers.google.com

今回は--print-to-pdfを使ってPDFを生成し，それを印刷する感じにした．

ちなみにICPCの国内予選は提出したり順位表を見るのにはログインが必要だが，問題を見ること自体は認証無しで可能（これは練習セッションで確認済み）だった．このおかげでログイン処理を書く必要が無く，URLをそのまま直に叩けば問題ページが降ってきた．

~$ for d in {A..H}
> do
> google-chrome --headless --disable-gpu --print-to-pdf http://********/${d}_ja.html
> lpr output.pdf
> done

という感じにするとA~H問題までの問題が印刷される．今回はうちの大学から3チーム出ていたので，lpr output.pdfだけfor文で回した．

↑のコマンドを書いてメモったのが開始5分前で，提案しつつ「事故っても責任は持てないよ」と逃げ道を作っておく．🚩

16:30~17:00

競技開始．
まず問題文を印刷するコマンドを打つ．

プリンタの側で待機している問題文配布担当から出されるNG🙅．

Not Found

The requested URL /********/_ja.html was not found on this server.

Apache/2.4.7 (Ubuntu) Server at icpc.yamagula.ic.i.u-tokyo.ac.jp Port 80

こうして僕たちの最後のICPCは幕を閉じた．
（完）

フラグ🚩回収に成功したとこで気を取り直して再度コマンドを打つ．今度は大丈夫そう．

僕がやらかしてる間にhecがターミナルの後ろにあるブラウザの画面からA問題を読み取っていて，とりあえずテンプレート等を打ってすぐ交代する．

ちょっとデバッグに手こずって開始10分後くらいでAC．大学内で一番遅かったらしい．
nokoTaroがBを詰め終わっていたのでコーディング交代．hecがCを読み終わって解法を詰めているところなので僕はDを読む．
一瞬で読み終わったのでEをちら見する．これも一瞬で読み終わる．
hecにDの概要を伝えたらO(1)で解法が降ってきた．Bのサンプルが合わなくて紙デバッグに移る．同時にhecがCの実装を開始．

Bのデバッグがすぐ終わったのでCをコーディングしてる途中で交代して修正してAC．
そのあとhecがCを通してそのままDの実装に移る．この時点で30分くらいだったと思う．

17:00~17:30

Eが読み終わってるので僕はFを読む．これも一瞬で読み終わるが，頭が弱いので折りたたみの様子を完全にイメージできず，メモ用の紙を使って小道具を作った．

Fのインフラ pic.twitter.com/o40dVdXoqm
— ヘクト_クリアカラー🐬(D69/74) (@osrehun) 2017年7月14日

これが後に大きく活躍したらしい．

nokoTaroがGの方針が思い浮かばないとのことなので，一旦Fを一緒に考えてもらう．
途中でDのデバッグ作業に呼ばれてsegvの箇所を特定するなどした．間もなくしてDが通る．

17:30~18:00

Eの概要をhecに伝えたがちょっと方針に確信が持てないのでFを手伝ってもらう．
3人でウンウン唸った後hecがよくわからない方法で通してた．

18:00~19:00

hecと適当に相談して，制約を見るとどうやらevaluatorを作ってぶん回せば行けそう（雑）ということがわかったのでそのままコーディングしてもらう．
nokoTaroがやはりGの方針が浮かばないとのことなので問題を見る．探索する近傍に優先順位をつけて反時計周りに辿れば良さそうということに気づくが，G問題ということもあり流石にそれはないでしょｗみたいなやり取りを数回繰り返す．
途中でHを見て，幾何だけどなんとなく行けそうな匂いがしてしまう．しかし過去の経験上，幾何に手を付けて時間を溶かしてオワリみたいな展開が幾度となくあったのでGに戻る．
やはり先ほどの解法で反例が見つからないので強く主張する．悩んだ結果とりあえずコーディングだけしてみよう，ということに．
Eのバグ取りに手こずっていたようなので，一旦交代してnokoTaroにコーディングしてもらう．適当にバグを取ってサンプルも通ったのでsubmitする．WA．
Eの実装に戻ってもらいつつ，Gのテストケースを軽く印刷してもらう．18:30くらいに反例が見つかった．ここで右手法を使えば良いということに気づいて，nokoTaroに解法を伝える．

Eのバグが取れてサンプルも通ったとのことなので，Data1を処理している間にGのコーディングをしてもらう．いくつかバグを踏みつつ，EのData1の処理が終わったので提出．Correctで盛り上がる．
そのままGのコーディングを続けてもらい，バグが取れたところでEのData2の処理が終わる．提出してAC．6完で勝ちを確信する．

19:00~19:30

まあ解法雑だし最悪通らなくてもいいや…という気持ちでGを投げてもらう．AC．7完でかなり盛り上がる．

順位表を確認すると東大に挟まれていて笑う．その時点では4位だったのでshuriken通してくれ〜みたいな謎の祈りをしながら一応Hを見る．
完全に解法は詰めきれていなかったが，とりあえず幾何ライブラリを写経していた．
Hを考える気力が残っていなかったのであとは適当に順位表を眺めていたら，shurikenがGを通して4位になったので√29を確信する．

競技終了．7完5位という過去最高の結果だった．hecは神．僕はカス．

その後は会場の撤収作業を済ませ，適当に酒を飲むなどした．

おわりに

今回はそこそこ役に立てたので良かった．

Headless Chromeを使うと問題文印刷がかなり楽になるので来年度以降是非活用して下さい．typoをすると404 Not Foundなページが30枚近く出てくることになるので気をつけましょう．

2017-03-10

UnicornでWindowsAPIトレーサーみたいなものを作った

とは言っても技術的に何か特殊なことをしているとかいうわけではなくて，単純にPEローダーを頑張って実装したみたいな話．

作ったもの github.com

Unicorn

QEMUのラッパみたいなもので，CPUエミュレータをフレームワークとして手軽に扱えるUnicornというライブラリがある．
つい先月v1.0がリリースされて，Go, Python, .NET, Javaの他にMSVC, VB6, Ruby, Haskellのバインディングが追加された．

www.unicorn-engine.org

他に特筆すべき点としては，GDTR, IDTR, LDTRあたりのサポートが追加されて適切にセグメントレジスタを設定できるようになった(!)ことや，コンテキスト周りのサポートが入ったことが挙げられる．前者の方が結構重要で，WindowsではFSレジスタがTIBのアドレスを指しているのでマルウェアだとよく使われたりする．

PyAnaとDutas

UnicornでPEエミュレータってあるんじゃね？と思って探したら，案の定あった．

github.com

どちらもメインの機能としてWindowsAPIのトレーサーがついていて，サンプルコードを実行すると胡散臭い命令がジャンジャン呼ばれている様子を観測できる．

しかしこれらはUnicorn v0.9での動作を前提に作られていて，セグメント周りのサポートが入っていなかったためFSレジスタにメモリのアドレスを直接書き込むという荒業を使っている．

        mu.reg_write(UC_X86_REG_FS, TIB)

これをv1.0で動かすと当然クラッシュする．

また，どちらもLDR周りの整備を無理矢理やっていて，例えば別のdllを追加するのに結構労力を割かれたりする．解析する検体側でLoadLibraryが呼ばれてたりするとメモリにマッピングしてくれるのだけれど，PEが事前に別のdllを必要としていると全く動かない．

WindowsAPIフック

このように制約条件はありながらも，WindowsAPIフック機能はかなり良い感じに動作する．どうやってAPIフックを実現しているかというと，

DLLに含まれる関数の先頭を\xc3 (ret) に書き換える
当該関数の先頭アドレスをフック対象に追加
関数が呼ばれるとUnicorn上で代わりにその処理を行い，スタックや戻り値などの辻褄を合わせる

という非常にシンプルなものである．
フック対象を管理しているリスト (実際はdict) では関数の先頭アドレスとWindowsAPIの名前をペアとして持っておく．代理で呼ぶ関数には予めhook_というprefixをつけておき，globals()から取得してeip, esp, uc (Unicornのインスタンス)を渡して呼び出す．例えばエミュレータ上でGetProcAddressが呼ばれるとhook_GetProcAddress(eip, esp, uc)が実行される，という具合．
hook_*という関数が大量に実装されているが，もちろんされてないもののほうが多い．最初はPyAnaないしDutasにちまちまとフック関数を実装して頑張っていたのだが，結構な数になってくると見通しが悪い．あとlstrcatみたいな絶対に動作が変わらないものの処理が検体毎に複製されていくのがなんだか気持ち悪いので，ライブラリ化しておきたいという気持ちになった．

pefile

PyAnaもDutasもDLLがエクスポートした関数を列挙するのにpefileというライブラリを使っている．

github.com

これはPythonでPEを扱うなら鉄板ライブラリといえるほど動作が安定していて，実績も多い．例えばangrはPEを解析するときに内部でpefileを使っている．

しかしこのライブラリ，非常に遅い．kernel32.dll (約1.1MB) を読み込むのに6秒くらいかかる．DLL一つだけならまだ良いが，3個以上のDLLを予め読み込んだり，LoadLibraryが途中で呼ばれて追加のDLLが読み込まれたりすると，正直待ってられない．DLLが足りなくて途中で落ちたらまた20秒くらい待たされることになる．と思っていたのだが，単純にpipで入るバージョンがクソ古いだけだった．githubから最新版を落としてくるともうちょっと早く動く．それでも2秒くらいはかかる．

PythonでPEパーサーといえばもう一つ，pype32というライブラリがある．readpe.pyが有名．前は普通にサクサク使えてた印象があったのだけど，いつの間にか遅くなっていた．~~というかパースが終わらない．バグか？~~これも勘違い．正しくは exeのパースは早いがdllはクソ遅い だった．kernel32.dllで試したのだけれど，~~2分48秒かかった．~~ 測り直したら1分5秒でした．論外.

PEパーサー

pefileもpype32もまともに使えない(pefileはまあ使える)ことがわかったので，自分で実装することにした．参考にしたサイトを貼っておく．

PE(Portable Executable)ファイルフォーマットの概要

Portable Executable カテゴリーの記事一覧 - 鷲ノ巣

DOSヘッダからセクションヘッダまでなら前者，IMAGE_DATA_DIRECTORY以降の話なら後者がわかりやすい．
これらを参考にしつつ，MSDNのサイトPeering Inside the PE: A Tour of the Win32 Portable Executable File Formatを見ながらctypesでごりごりとパーサーを書いた．

今回必要な機能は

EXEがインポートしているDLL, 関数名/RVA列挙
DLLがエクスポートしている関数名/RVA列挙
PEがメモリ上へ展開された後のイメージ
PEの各種情報 (ImageBase, EntryPointなど)

で，IMAGE_DIRECTORYのうちサポートするインポートはIMAGE_DIRECTORY_ENTRY_IMPORTのみ．
この位まで機能を絞ると案外実装しやすくて，速度も出た．

github.com

A Tour of the Win32 Portable Executable File Formatとあるように，32bitまでしか対応してないので現状64bitは未対応．気が向いたらやる．

TIB周り

WindowsのプロセスにはTIB (Thread Information Block) というのがあって，プロセス・スレッド自身の情報を保持している．プロセス起動時にFSレジスタがこの構造体の先頭アドレスを指すようになっており，これを辿ることで各情報にアクセスできる．
特に対解析機能として難読化をかけてるコードやパッキングしているようなコードは，元のバイナリが使用しているWindowsAPIのアドレスを動的に解決する必要があるため，PEBのLDRからモジュールのリストを辿ってLoadLibrary,GetProcAddress (kernel32.dll) のアドレスを取得し，そこから必要な関数をもってくる，といったことをよくする．

そのためTIB周りをちゃんとセットアップしてやらないと動かない検体が結構あって，実装することにした．PyAnaもDutasも見かけ上はLDRまでやってるけど，オフセットも決め打ちで，用意するLDRのリンクも真面目に繋いでないので，ちょっと別経路を辿ると動かなかったりする．具体的に言うと，ロードされたモジュールはLoadOrder, MemOrder, InitOrderの3種類の順番で辿ることができるが，LoadOrderの部分しか繋いでないとMemOrderを辿る検体が動かない，という具合．LDR_MODULEについては Understanding the PEB_LDR_DATA Structure がわかりやすい．
ちなみにTIB周りの構造体は Welcome to WinAppDbg 1.5! — WinAppDbg 1.5 documentation を拝借して流用している．素のままだとUnix環境で動かないので適当に手を加えた．

セグメントレジスタ周り

UnicornはあくまでもCPUエミュレータなので，アーキテクチャの設計に対して忠実に処理を書かなければならない．最初ここを理解してなくて，FSレジスタを設定するだけでsegv起こしたり，mapしたはずのスタック領域がunmapped扱いになったりした．
ざっくり説明すると，セグメントレジスタを設定するときはGDT (Global Discriptor Table) をあらかじめ設定しておく必要があって，その中のインデックス番号，メモリ上の範囲，各種フラグを含んだ値 (selectorという) をセグメントレジスタに書き込む．selectorを書き込む段階でGDTのセットアップが終わってないとsegvする．
GDTについては Global Descriptor Table - OSDev Wiki とプロテクトモードのセグメント機構を参照した．

他にハマりどころとして，Windows (x86環境) ではGS, ES, DS, SSが全て同じ値 0x002B (index:5, range:0x00000000-0xffffffff, flags: gr=1, sz=1, pr=1, privl=3, ex=0, dc=0, rw=1, ac=1, rpl=3) に設定されているのだけれど，Unicornではこの値だとスタックがうまく扱えなくて，正しくはSSに設定するフラグを gr=1, sz=1, pr=1, privl=0, ex=0, dc=1, rw=1, ac=1, rpl=0 にしてあげる必要がある．違いはgdt entryの特権レベルとselectorの要求特権レベルが0 (kernel) になっているのと，dc (Direction bit/Conforming bit) が1 (segment grows down) になっている点．dc bitは全然気づかなかった．
セグメント周りの設定はこのへんでやってる．indexが露骨に調整してあるのはWindowsをマネしたため．

フック

フックの仕組みはPyAnaやDutasと同じく，関数の先頭をretに書き換えてUnicorn側で代わりの処理を呼ぶ．トレーサーとフック処理の接点をUnitracerインスタンスだけに抑えるため，hookを呼ぶ時にselfを渡すというちょっと変なことをやっている．WindowsAPIが行う処理はアーキテクチャに依らず同じ結果を返してほしいので，フック処理ではなるべくUnicornの都合を意識しなくて済むような設計にしたかったのだが，現状はできてない．多分呼び出し規約をWindowsクラス側で一意に扱えるようにしないと実現できない気がする．
実際にUnitracerを使うときは絶対に挙動が変わらない処理はlib/windows/hooks以下に書いておいて，挙動を変えたい時に[Unitracerインスタンス].hooksに直接関数を追加して動かすみたいな使い方を想定している．これでとりあえず当初の目的であったフック処理のライブラリ化に関しては達成できたとは思う．

現状

ここまで長々と書いてしまったけど，とりあえずAPIトレーサとしては十分動くと思う．
まだTIB周りが弱くて，~~サンプル (samples/Wincalc.sc) が動かない！ｗ~~ [17/03/11]PEパーサーのバグだった．現在は修正済み．あとフックを全然実装してないのでちょくちょく追加していく予定．

2016-12-18

Advent Calendarに遅刻しないために

icchyr って人MMA Advent Calendar書いてなさそう https://t.co/zawvQyJoWk
— みきお.pm (@benevolent0505) 2016年12月18日

この記事はMMA Advent Calendar 2016の18日目の記事です．(遅刻回避)

僕はMMAでは無いのですが，

@icchyr MMA部室によくいるし頼んだ https://t.co/xUq8n04INl
— ひろ (@hyr3k) 2016年10月27日

というわけで書きます．

皆さん，Advent Calendarって登録してても忘れますよね？

忘れない方法として，通知を行うというソリューションがありますが，どのようにしたら良いでしょうか．

結論

iCal形式でダウンロードできるので，カレンダーにインポートしましょう

これで忘れていてもカレンダーから通知が飛んできますね

今後活用していきたいと思います

f:id:icchyr:20161218235156p:plain

僕からは以上です

2016-12-04

HITCON CTF 2016 Finals参加記

この記事はCTF Advent Calendarの4日目です．

~~まだ欠けているところがあるのでとりあえず速報版ということで…~~
12/07: 残りの写真などを貼りました．

12/2-12/3の2日間，台湾にてHITCON CTF 2016の決勝戦が開催され，TokyoWesternsとして参加してきました．
今回の遠征において起こったことを時系列順に書いていきます．

飛行機の遅延

我々は当初11:45に成田を出る飛行機に乗る予定だったのですが，前日の夜22時頃に突然メールが来て，

Flight Delay Notification

11:45発予定が19:00に変更?????
このままだと台湾につくのは22時過ぎ(現地時刻)になり，移動が極めて面倒なことになりそう，という結論に．
とりあえず問い合わせて，払い戻しが可能かどうかを聞くことにしました．（時間帯的に窓口が英語しか対応してなくて，非常にしんどかった）

どうやら払い戻しは可能っぽいので，実際に手続きをするのは翌朝に日本語の窓口が対応しているときにしよう，ということで急遽別の飛行機を予約するという話になりました (この時点で夜中の1時を過ぎており，寝落ちした→他の人より航空券が少し高くついた)．

まあなんやかんやで無事に飛行機に乗れたので良しということで．

台湾着

台湾に着いて適当にSIMカードを購入したりして，ホテルまでのルートを調べました．
今回運営が用意してくれたホテルは結構良い所らしく，なんと空港からバス一本でたどり着くことができて感動しました．
ちなみにバスの券を販売しているところのPCにXPが写っていたり，発券された乗車券の時刻がクソ適当だったりといろいろ怪しい点は多かったものの，特にトラブルもなくホテルまで着き，先に来ていたhhc0nullと合流してすき家で食事を取りました．

f:id:icchyr:20161207230733j:plain:w200 f:id:icchyr:20161207230634j:plain:w300

あとLTEがクソ早くて感動した

f:id:icchyr:20161207230510p:plain

会場

今年のFinalsはHITCON Pacificと同時開催らしくて，Taipei New Horizonという所の最上階でした． f:id:icchyr:20161207230916j:plain

f:id:icchyr:20161207231020j:plain

f:id:icchyr:20161207231047j:plain

設営もめちゃくちゃ手が込んでいて，各チームのテーブルには看板が設置してありました．

f:id:icchyr:20161207231235j:plain:w300

…? 何か足りないですね…

ところでこれは某CTFの名札です

f:id:icchyr:20161207231815j:plain:w300

今年はチーム名を間違えられる呪いにでもかけられたんでしょうか．

Finals

去年に続き素晴らしい大会で，今年のA&DはPwnable3問，Web3問でした．競技はday1 10:00 ~ 18:00, day2 8:30 ~ 15:30で，day2の12:30までは1ラウンド5min, それ以降は1ラウンド2minという設定でした． Pwnable問題は公開されてからは最後まで動いていて，Web問題は各問題が別々の時間に公開されて2つ以上の問題が同時に動くことはありませんでした．そのかわりWeb問題にはfirst bloodがあり，1500, 1000, 500, 300, 100という具合に解いた順にボーナスポイントが与えられました．

問題	時間	ジャンル	概要
digimon	day1 10:00 ~	pwnable	デジモンをモチーフにしたゲーム．ショップの番号に制限が無くて任意メモリの書き換えが可能(らしい)
rabbit	day1 10:00 ~ 14:00	web	zabbixが動いている．/jsrpc.phpにSQL injectionの脆弱性があり，Adminのセッションを奪うことができる．Adminはzabbixの機能でスクリプト実行が可能なのでflagを読む．
criticalheap_revenge	day1 14:00(?) ~	pwnable	よく読んでないけどFSBがあったらしい
webrop	day1 14:00 ~ day2 12:30	web	SugarCRMとphpMyAdminが置いてあるだけ．詳しくは後述します．
fx-1337	day2 9:30 ~	pwnable	電卓を模したアプリケーション．BackSpaceの回数に制限が無くて任意のアドレスにジャンプすることのできる脆弱性があった(らしい)
myide	day2 12:30 ~	web	flask製のテキスト共有システム．詳しくは後述．

僕がメインで取り組んでいたのはWebの3問で，前半2問(rabbit, webrop)はいずれも実際に使われているソフトウェアを用いており，オイオイ0dayゲーか〜???と思いましたが，3問目はお手製のflaskアプリでした．実際にはrabbit, webropはCVEの付いている脆弱性を抱えており，それを用いて攻撃が可能，というものでした．

webrop

phpMyAdminとSugarCRMが置かれているが，phpMyAdminの指しているホストが126.0.0.1と128.0.0.1のみ選べるため，全く意味ない．ように見える．SugarCRMは普通の設定で，適当なユーザーでのログインはできる状態．この問題は1日目は全く動きが見られず，2日目に持ち越されたため結局first bloodは無効になりました．我々のチームではytokuさんが一日目の夜に0dayの脆弱性を発見し，それを用いてexploitを作成していったところうまく刺さりました(もちろん数チームには途中から対策されました)．他にも0dayを見つけたチームがいて，CTFerの恐ろしさを見せつけられました．ちなみに競技終了後に運営に想定解を聞いたのですが，phpMyAdminの脆弱性によってセッションの上書きが可能であり，それを用いてSugarCRMで権限昇格を行う，というものだったそうです．PPPはこの方法で攻撃したそうです．途中までは全部のチームからflagを取れていたのですが，PPPはログインをできなくしたせいで攻撃が刺さらなくなったにも関わらずSLAはALIVEになっていて，なるほど．去年はSLAがクソ厳しかった上に，事前のルール説明に「脆弱性部分以外のパッチで防ぐのはやめろ」みたいなことが書いてあったため，どのチームも割とパッチに苦労してたと思うのですが… 結果的には結構な点を取れたと思います．

myide

flask製のアプリケーションで，一番最初に用いられた脆弱性はpath traversalでした．普通に任意ファイルを読むことができる感じ．テンプレートエンジンにjinja2を使っていたので案の定template injectionがあり，任意コードの実行が可能でした．ただしこの問題のみ，ソースコードに対するパッチが当てられなかった(当てても再起動する手段が無かった)ため，終わりの方はDOSの打ち合いという地獄絵図が広がっていました．

結果

最終結果はCykor, LC/BC, PPP, Shellphishに続いて5位でした！！！

決勝のA&Dでは今までの中で一番良い結果を残せたと思います．

余談

終了後の会場に良い話が転がっていました．

f:id:icchyr:20161207232458j:plain

終わりに

クソ適当な記事ですみませんでした．CTF Advent Calendarにはまだまだ空きがあるので是非書きましょう．
明日はyamaguchiさんのTSGCTFwriteupです．

2016-05-16

El Capitanでtsocksを使う

コマンドを実行するとき，必ずSOCKSプロキシを通るようにするためのツール tsocksというものがあって，Linuxではもちろん，OSX Mavericksでも動くのでよく使っていました．

ところが，先日El Capitanにアップデートした途端動かなくなり，いろいろ調べてるうちに解決したのでそのメモ．

OSXでのインストール方法

標準のhomebrewには含まれておらず，homebrew用のスクリプトを用意してやる必要があります．

norisu0313.hatenablog.com

ここを参考に，

github.com

に含まれているスクリプトを/usr/local/Library/Formula/に配置します．

~$ cat -> /usr/local/Library/Formula/tsocks.rb
require 'formula'

class Tsocks < Formula
  # The original is http://tsocks.sourceforge.net/
  # This GitHub repo is a maintained fork with OSX support
  homepage 'http://github.com/pc/tsocks'
  head 'https://github.com/pc/tsocks.git'

  depends_on 'autoconf' => :build if MacOS.xcode_version.to_f >= 4.3

  def install
    system "autoconf", "-v"
    system "./configure", "--prefix=#{prefix}", "--disable-debug", "--disable-dependency-tracking", "--with-conf=#{config_file}"

    inreplace("tsocks") { |bin| bin.change_make_var! "LIBDIR", lib }

    system "make"
    system "make install"

    etc.install "tsocks.conf.simple.example" => "tsocks.conf" unless config_file.exist?
  end

  def test
    puts 'Your current public ip is:'
    ohai `curl -sS ifconfig.me 2>&1`.chomp
    puts "If your correctly configured #{config_file}, this should show the ip you have trough the proxy"
    puts 'Your ip through the proxy is:'
    ohai `tsocks curl -sS ifconfig.me 2>&1`.chomp
  end

  def config_file
    etc / 'tsocks.conf'
  end
end
[EOF]
~$

tsocksのしくみ

tsocksのソースコードを読むとわかるのですが，ライブラリ関数のフックを用いてこの機能を実現しています．LinuxならLD_PRELOAD, OSXならDYLD_INSERT_LIBRARIESおよびDYLD_FORCE_FLAT_NAMESPACEといった具合です．tsocks本体のスクリプトは環境変数に共有ライブラリを追加するためのラッパーで，実際には生成されたlibtsocksというライブラリが仕事をしています．

El Capitanでの問題

どうやらSystem Integrity Protection (SIP) が悪さ (セキュリティ的には良い挙動ですが) をしているらしく，DYLD_INSERT_LIBRARIESによるフックが無効化されていました．
SIPの無効化はリカバリーモードでcsrutil disableとか打つと良いのですが，影響を及ぼさないシステム保護まで解除してしまうため，必要なものだけを無効化します．

~$ csrutil disable
~$ csrutil enable --without debug

これによってApple InternalとDebugging Restrictionsのみが無効化され，fsなどの保護は生きたままになります．

~$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
    Apple Internal: disabled
    Kext Signing: enabled
    Filesystem Protections: enabled
    Debugging Restrictions: disabled
    DTrace Restrictions: enabled
    NVRAM Protections: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

これでtsocksが使えるようになります．

~$ ssh -fND 1080 home
~$ tsocks curl 192.168.1.X

2015-12-02

Linuxでunzipすると文字化けする

今年度が始まるちょっと前くらいに新しくバイトを始め，楽しくやっています．どこでバイトしているかは言えないので察していただきたいのですが，毎日楽しく業務をこなしています．
業務中に得られた小さな知見を公開できる範囲で共有したいと思います．

タイトル通り，Windowsで作成したzipファイルをそのままunzipすると悲惨なことになります．現在のディレクトリに展開された場合は削除するのも面倒です．
このような悲劇を生まないために，unzip -O cp932 hoge.zipしましょう．

2015-09-03

rncc夏期講習に参加してきました

id:kkrntと相談しながら日取りを決め，FMSのNCCさんと東京農工大のMCCとで夏期講習を開催しました．
本当はMCCから4人くらい話す予定だったのですが，なんと僕のみの参加となってしまいました
ちなみにrnccというのは"r"と"n"が並ぶと"m"っぽく見えるのが由来です．

話したこと

皆にシェルの楽しさを知ってもらいたく，「シェル芸初心者によるシェル芸入門」というタイトルで発表をしました．
僕は趣味でシェル遊びをしているので，シェル芸人ではありません．

シェル芸初心者によるシェル芸入門 (修正版) from icchy

www.slideshare.net

他の人が話した内容

詳しいことはNCCの記事を見て下さい．

<a href="http://ncc.hateblo.jp/entry/2015/09/03/163239">rncc夏期講習を東京農工大学のMCCさんと開催しました - Nakano Computer Club 活動記録</a>ncc.hateblo.jp

個人的にはES2015(ES6)に触れたのが面白かったです．npm便利．
あとchainerちょっと遊んでみたいと思いました．とりあえずpip install chainerしたので適当にやってみます