8cc.bf
https://github.com/shinh/bflisp/blob/master/8cc.bf
Brainfuckで動くCコンパイラができました。このコンパイラ自身で同じコンパイラをコンパイルすることも可能です(ただし5時間以上かかる)。前回との差分はレジスタの幅とデータメモリ空間を24bitに広げたことと、いくつかバグをつぶしたことです。
これまでわざわざ手書きで書いていたBrainfuckのプログラムを、Cのコードから生成することでお手軽に作れるようになりました…とさ。 sizeof(int)==1 で 1byte==24bits だったりする変なアーキテクチャな上に、ビット演算とかがないですけど。
就職して9年が過ぎる
転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。
きっかけ
わりと重要でない
Borgチーム (の周辺)
いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。
さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない？みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。いくつかうまくやったチームがあって、実際すっげー減ったんじゃないかな。最初の3ヶ月は練習期間的な感じで、そういうのの一つでチマチマPython書いたりしてた。
で、日本に帰ってきて僕の入ったチームでは、色々なクラスタの変更の結果が予想しやすくなる、みたいなのを作っていた。Borg自体のコード使ったりもしてたこともあり、ちょっとパッチ投げたりもしたけど、まあ総じて重要度はそれほど高くないプロジェクトだったのかなぁと、今となっては思う。でも新卒で入った僕にわかるわけもなく、そしてエンジニアリング的にはすごく勉強になった。指導してくれた人達がすごかった。
glog (憧れの20%プロジェクトは80%より楽しくなかったでござるの巻)
当時僕はGoogleさっさと辞めると思っていた。しかしGoogleにあるものは色々便利なので、なんか色々opensourceになってると良いなあとか思っていた。Google入って最初の頃に特に感銘を受けた文化に、とりあえずログ残して、用途は後で考える、てのがあった。ログつーとアクセスログみたいなやつと、プログラムがこんなことあったぜ、て端末に吐き続けるログがある。前者は当然すさまじく重要なんだけど、後者も有意義。
まークラウドみたいな環境だと、たまーに起きた問題にgdbで対処する、なんてのはあまり現実的でないことが多く、ログとコード見比べて、ああここNULLになりうるな、みたいな感じのデバッグシーンが多い。まあそんな感じで、使いやすいロギングライブラリがあるってのは重要なのである。
で、このくらいの規模感のものなら僕個人でもopensource化とかできないかな？とか思ってやってみた。当時社員番号3番(つまり最初の従業員)の偉い人が色んなものをopensource化しており(gflagsやperftoolsが一例)、この人に相談するといいかな、って思ってメールしたりした。その偉い人は即日色良い返事をくれていたのだけど、パソコン音痴の僕はgmailにおかしなフィルタを設定してしまっており、彼の返事はなんだか目に入らないところにいっていた。1ヶ月ほどしてから、あれ、そういえばあれ返事もらえてないな？とメールボックスを検索したら返事くれてるのに気付いて、さすがに青冷めた。クソ偉い人にいきなりメールして、即日反応してくれたのに1ヶ月放置するクソ新卒である。その後、クソ新卒のコードレビューをずっとやってくれてたんだから3番良い人すぎた。
そのエピソードと、社内のコードがどう育ってきたかというのを読みつつopensourceとして出せるものにしていく考古学的作業は楽しかったが、リリースしてしまうと、*BSDで動かないとかなんとか、うん、めんどくさいね、てなった。
GSLB (のクライアント)
GSLBてのがあって、これクラスタ内じゃなくて、どのクラスタに行くべき？みたいなレベルのロードバランスしてるんですが、それのクライアントライブラリみたいなのを作っていた。
思うになんかこれは、「なんでこんな当然あるべきもんが無いの？」系のプロジェクトだったと思う。よって、テクニカルにはその前のプロジェクトの方が面白いことをやっていたように思うけど、こっちは作れば確実に成功するていう。僕が言い出したとかでは全然なく、指導してた偉い人がUSに行って面白いネタ無いって聞いてきて、こいうのあるらしいからお前やったら、て言われて気付いたらテックリードという象徴天皇みたいなのになってた。
GSLB上流てのはクソ忙しいチームであり彼らとのコミュニケーションが必須ということもあり、たいしたコード量じゃないのにすごい時間がかかる…みたいなプロジェクトだったけど、まあなんか評価はされるみたいな不思議な感じだった。テックリード的な役割て俺向いてないなぁ…とも感じた。でもびっくりするくらいコード書いてない割には評価は悪くないんだよね不思議。
なるほど、企業というのはコーディング力じゃなくて会社に対するインパクトで評価するのだな、という当たり前のことを実感したように思う。
Chrome (で落穂ひろい)
小さいチームはコミュニケーションコスト的に損、ということでインフラぽいプロジェクトが解体される。今思えば、目をひくほどの成果があるわけでも無い、という要因も重要だったと理解している。評価は悪くはないというだけであり、まあ誰にでもできることをやってたという感じで。
僕はなんとなく something new …てことで Chrome に魅かれていた。周りの人はそうでもない人が多くて、2,3人で Chrome やるぜって盛り上がってたと思うんだけど、 Chrome の当時の偉い人が日本に来て、 html5 やるぜーて騒いで、なんか周りの人も乗り気になった。そして東京に Chrome の結構大きい部隊ができた。
まわりもほとんど全員 Chrome 初心者、みたいな感じなので、みんなパッチ修行と称して、細かいバグ潰しては周りの人と情報交換して…みたいな感じでコードベースに慣れていった。割と適当なバグを重要性無視してプチプチ潰す、みたいなのは好きなので、まあプチプチしてた。当時 Chrome てコードが割と雑然としてて、僕綺麗な環境で働くより雑然としたとこの方が得意だってのもあって、まあまあ効率は悪くなかった気がする。やってた作業が重要なものだったかは謎だが。まあEUC-JPのURLコピペして動くようにとかは普通に役に立ったんでないかな。
WebKit (Appleとの謎の関係)
ある程度 Chrome に慣れたら、 html5 の機能を実装していこう、みたいになって、手つけられてない CSS3 とかやったら、みたいなことで WebKit に親しんでいった。そこで CSS の細かいバグプチプチなんかもやったのだけど、それよりも WebKit の開発サポートツールみたいなスクリプト群の出来の悪さや、コーディングスタイルはあるが強制されてないのでみんな破ってる、みたいな状況がうへえ、て思って、後半は C++ より開発サポートツールのために Python 書いてることが多い、みたいな感じになった。
そんなこんなで難しい C++ のコードとか書かずに Python パッチ量産した結果、パッチ数だけは溜まってる上に、やってる作業的に Apple の人に悪印象持たれてないということもあってか、割とさっくり WebKit reviewer というのになった。あとその後は印刷系の CSS3 のなんかとか少しやったと思う。
WebKit は総じて Chrome よりさらに雑然としてたのもあり、やるべきことが無数にあって、まあなんか思いついたとこいじるみたいな感じだった。何をやるべきかって考える時間が無いてのは僕にとっては良いことで、総じてそれなりの効率だったように思う。やってた作業が重要なものだったかは依然として謎だが。次のプロジェクトに移った後で起きた Blink フォークにはびっくりしたな…
goma (名前に意味はない)
東京オフィスでなんか面白いことやろうぜ、ということでオフィス内アイデアコンペみたいなのが行なわれる。アイデアの段階で半分死に、1週間でまた半分、1ヶ月でもう半分、みたいな感じのやつ。
当時 Chrome の開発には割と満足してたけど、グーグルの社内コードベースに比べて格段にビルドが遅いのがむかついていた。で、社内にあるスゴdistccみたいなやつを、そのままパクったらいいんじゃね、的に goma てのを始めた。社内のやつは社内コードベースに特化してるのだけど、まあそうじゃないとこから簡単にセットアップできます、みたいなコンセプトで。
なんかビルド2,3倍くらいは速くなったなー、ユーザ増やすために宣伝しないとかな？とか思ってるうちに、USのちょっと人気者みたいな人が、「goma 試したけど、これあればdistccとかもういらねーよOMGOMG」的なことを言ってくれたので、苦手な宣伝作業というのをしないでも勝手に流行った。なんか気がついたらChromeチームは全員goma使ってた。口コミの強さよ。
みんなが使うと色々問題が起きたり、新しいコンパイラが欲しいとか言ってきたり、などなど…ということでぼんやり平和に過ごしていた。この時 Mac サポートのために半分ネタで作った maloader が本当に使いものになったのは愉快なできごとであった。
ARC (低レイヤおいしいです)
当時僕は Google Native Client というやつの大ファンだった。今でもグーグルが作った一番クールなものの一つくらいに思っている。それの上で Android アプリを動かそうとしてるプロジェクトがある、という噂を聞いていた。入れてもらえないかなとか思ってたら、なんか長期出張から一時帰国してた同僚が誘ってくれて、やることになった。
これはもう本当に想像よりもクレイジーなプロジェクトに、すごい優秀な人達が全力で挑んでる、みたいな感じですごい楽しかった。僕はだいたい、3ヶ月くらい楽しーて仕事したと思ったら、ぼんやり気味な期間が後で来ることが多いんだけど、この時は1年近く楽しさが持続してたと思う。
POSIXをPOSIXじゃないものでエミュレートしたり、BionicていうlibcをNaClにポートしたり、seccomp-bpfをNaClの強いsandboxのかわりに使うモードをNaClに足したり、みたいなことやってた。つまり何やってんだかよくわからないことやってた。
僕、社内で Chrome と Android の存在を知った時は、「なんてアホなプロジェクトだ、こんなの成功するわけない！」て思ってたんだけど、数年後にはその両方とからむプロジェクトをしてたってのは、僕の先見性の無さがよくわかる話だと思う。
NaCl Development Environment (趣味20%)
NaCl ファンとして 趣味で TinyCC を NaCl にポートした上に NaCl にリターゲッティングしたりしてたんだけど、 GCC もポートしたりしてたので、 NaCl ターゲットの nacl-gcc を NaCl 上で動かす遊びとかをしてた。
ついでに基本的な Unix ツールを Bash on NaCl の上で動くようにしたりと。つまり Chrome だけあればネットワーク無しでも開発できる、てのが夢というわけ。
したら NaCl チームの人が気にいって、なんかよくわからないクロームエクステンションを作ってくれてた。
https://chrome.google.com/webstore/detail/nacl-development-environm/aljpgkjeipgnmdpikaajmnepbcfkglfa
kati (負けない)
Chrome から Android に移った人が、ビルド遅くて不愉快、 ninja+goma 良かった、みたいなことを言っている、という噂を聞く。 goma 時代にちょっと見た時はとりあえず make がアカンすぎるという感想で、 ARC 時代に Android.mk をだいぶ見慣れてたこともあって、「あーありゃGNU make作りなおすんが手っ取り早いね」「んじゃやってみろ」てな感じでやってみた。
なんか色々トントン拍子でいって、これも宣伝工作とかを特にすることもなく、 Android 原住民が超協力的な感じで、あっというまに Android にチェックインされ、 kati+ninja がデフォルトになり、 make でビルドする手段が消された。
最近は Android.mk の方も少しいじったりしてる。
総じて
自慢じゃないけどキャリアパスとか微塵も考えてなくて、偉くなるには人を指導しなければ、みたいなアドバイスは左の耳から出ていっているので、特にそういう点では、なんの参考にもならないと思う。思うに僕は運が良いと思う。そういう意味でも参考にならないと思う。まああと環境的にも他の企業とだいぶ違うと思う。
でもなんか、特に最近意識的にやってて、結構他の人/環境でも適用できるんでないかなと思ってることとして、小さい投資をたくさんする、てのがある。例えば kati 始めた時とかは、 GNU make のクローン作るとかいかにもできなさそうなんで、「とりあえず一ヶ月ください無理そうならさっさとやめます」みたいな感じではじめた。僕は普段、もう少し細かい単位でも、例えば「来週やってみてダメそうならやめる」みたいな感じで時間を無駄にすることをかなり頻繁にやっている。そういう試みの半分以上は失敗に終わるけど、たいして時間を投資してないのでたいした問題にならない。
これについて、個人的に重要だと思ってることがいくつかあって。まずあまりマジメに相談せず勝手にやるってこと。相談すると、5割くらいの確率で「俺がやってるプロジェクトでその問題は解決するよー」とかいう返事が帰ってくる気がする。やる気が損なわれる。「それうまくいかないと思うよ」て言われてやっぱり失敗したら恥ずかしいよね。明らかな結論が出ない場合、どっちのアプローチが優れてるかとか机上で考えるのも時間のムダ。1週間から1ヶ月しか投資しないなら、作ってみて比べりゃいいんで。あと少人数でやること。人数増えると引っ込みがつきにくくなっちゃって、失敗させるのが難しくなると思う。要はサンクコストでかくしないてことか。当たり前の話だなあ。
あと投資対象、なんとなくだけど、ぱっと思いついただけの、いかにもダメそうなアイデアが割とうまくいく気がしている。「次なにするべきか…」とか熟考した上で出てきたそれっぽいアイデアとか、なんでか知らんけどだいたいうまくいかん気がする。ちょっと理由を考えてみると、ぱっと思いつくようなアイデアは本当に必要性があるからぱっと思いつく、みたいな話かな。
小さい投資たくさんするってのは、割とグーグルから学んだことのように思う。僕がグーグルのいいところだと思ってることに、プロジェクトをガンガン潰す、てことがある。それも失敗してるプロジェクトだから潰す、とかいうレベルじゃなくて、成功してないプロジェクトはふっと潰れるし、小さいプロジェクトは成功してても潰れる。これ、潰されるプロジェクトの人としては、もちろんガッカリ事件になる(特にこれといった失敗をしてない時)。僕も Chrome に移る前に少しガッカリしたと思う。
でも、細かいのガンガン潰さないと、リソースに限りある中で新しいことできないんだよなーと気付いて、なんか新しいことできたから、むしろ潰してくれてありがとーと思うようになり、これ日頃の仕事的にも良い考え方だなーと思うようになった。
bflisp.bf
https://github.com/shinh/bflisp
Lisp インタプリタを作りました。 Brainfuck で。
だいたい sedlisp や beflisp や makelisp と似たようなことができます。ちょっとバグあるみたいですが。
Malbolge は実装不能だと思うので、これ以上なくキツいターゲットじゃないかと思っています、ので Lisp シリーズはこれで最後でないかと。というか現世的な速度で動くとは思ってなかった。月なみですが、今のパソコン速いですねー。
実現は簡単な 16bit ハーバードアーキの CPU を定義して、魔改造した 8cc で lisp.c をその CPU のアセンブリにコンパイル、そのアセンブリなどから Brainfuck を生成、という感じになってます。実行は最適化機能つきの 8bit Brainfuck インプリタでやってます。ある程度最適化しないとまともな速度で動かないと思います。
メモリとかなかなか大変で。 Brainfuck で 16bit アドレス空間の load/store を現実的な速度かつコードサイズで実現する方法がなかなか思いつかなかったのですが、今回思いついたから作業始めた、という感じでした。
仮想 16bit CPU を挟んだのは、 @rui314 さんが sedlisp くらいの時から、直接やるんじゃなくて間に中間的な複雑さのなにかを挟んだ方が簡単じゃないの？って言ってて、それを採用した感じです。 sed/befunge/make の時は挟まない方が簡単だと今でも思ってますが、 Brainfuck 直行はまあムリゲー感しか無いです。
Befunge の時は LLVM bit code からだったのですが、 8cc にしたのは Brainfuck 上で C コンパイラ自体を動かすという夢があるからです。これ実現するにはまだまだやること多いはず…です。 8cc 大変いじりやすくてありがたかったです。
TRICK 2015
口頭でも言いましたが、今回は落選したものでも良いできだなーというのが多かったです。前回が価値が無いというほどでは全然ないんですけど、しかしちょっと差があったのは事実かなと。
僕が高得点をつけたものについて
コラッツ
https://github.com/tric/trick2015/blob/master/ksk_1/entry.rb
すごい。これ見れば見るほどスルメみたいに味が増えていくというか、しかもその味やばいっていうか、この短さのコードで、いやここまで考えさせられるとは、っていう。圧巻でした。
がまあ普通に考えてこれの評価がそろわないのは予想できます。2位でも十分評価されていたと思われます。
ドラゴン曲線
https://github.com/tric/trick2015/blob/master/monae/entry.rb
これは初見の印象はかなり悪かった。単なる Quine てのは、もう相当なことをしない限りは僕の中ではマイナスだと言って良い。
ただコード読んでみると、なるほどなー的な感じでコードがふくらんでいっていたと思う。いやでも忘れつつある。
数独
https://github.com/tric/trick2015/blob/master/eregon/entry.rb
これも最初のイメージはイマイチ。しかしよく読むとよくできてる…ていうかデータの埋め込み方かっこいいよね。こうやると決めればテクニックが必要な領域ではないけど、しかしこの埋め込み方決めたのは感心する。
Fiber は正直解く部分ちゃんと読めてないからよくわかってないけど、それでなくても最高に近い点数あげるから文句言うな、的な感覚で読むの放棄した。。
文字数にエンコードされてるプログラム
https://github.com/tric/trick2015/blob/master/usak/entry.rb
いや本当にこういう一発ネタ好きで。コメントした通り中盤はこうグダグダ感あるな、って気付いたのと、あれこれそんな難しいわけでもないよね、てあたりで点数を落としてしまった。最初はあまり迷いなく10点つけてた…がさすがにおかしい気がして少し落とさせてもらった感じで。
いやーでもこれ好きだな。ここまでのやつと比較してみると、コラッツは発想も実装も僕の枠を越えてて、ドラゴン曲線と数独は、発想はわかるなって感じで、実装はがんばったなーて感じ。このコードは発想がすごくわかりやすいが僕の発想の範囲にないのが好きで。
http://www.garbagecollect.jp/~usa/d/201512b.html#id20151211_P1_6
に書かれてますが、 ; の行は僕も味わいがあって良いなとか思ってました。その前後がちょっと残念かなあとは。
円周率覚え歌
https://github.com/tric/trick2015/blob/master/kinaba/entry.rb
これなー。これが優勝なのは文句ない。ただ前回と違って満場一致ではなかった。それだけ今回レベル上がったって話もあると思う。
これ見てて、なんかぱっと見ムダに長くね、とかいうのが第一感で。しかしそういうなら自分でやれ感もあり。まぁいなばさん円周率計算のゴルフ最短から結構長いんだよな。
もちろん TRICK はゴルフコンテストではないので、このコードの素晴らしさにケチをつけているのは長いというのが直接の苦情ではなく。例えば普通 foo = foo ていう文があったら、えっこれムダじゃない？て思うのと同様の感覚で、なーんかムダな式多くない？ていう感覚がある気がする、て感覚があって。
ただこれ自分で同じコード書こうと少しやってみて、あっこれ大変だって気付いた感じでした。でまあ総じてかなり高い点数に。 srand かっこいいしな。
markdown
https://github.com/tric/trick2015/blob/master/yoshi-taka/entry.rb
いやーこれいいでしょ。あの手この手でパース通してる感が、僕の一発ネタをきちんと昇華してる感じがしてて良かった。特に好きなのは TRICK!!! の !!! で、これビックリマーク1つだとパースエラーなんですよねえ。
でも僕これ強くは押してないんですが、理由としてストーリーがよくわからないというのがあって。。 if not for path in ENV って実はうまいこと言ったりしてるんだろうか、僕には単に ruby の式にしか見えなくて。。。
SAT
https://github.com/tric/trick2015/blob/master/ksk_2/entry.rb
あっ、なるほど、すごいですね。というやつ。これは本当にすさまじいので、ぐぐって SAT て regexp で解けるんだと理解するまでは、感動的でした。ぐぐって出てくる URL は正直に remarks に書いてあって、まあ好印象…がまぁ既存研究かーという感あって。
それでこのへんに。
エスケープ
https://github.com/tric/trick2015/blob/master/ko1_2/entry.rb
これ、すごい好きなんだけど技術的に別にたいしたもんでもないんで、このエントリに書いてる他のやつより1点少なくつけたんだけど、でも個人的には好き。
おまけ
気にいったコードはだいたい上記のやつで、全て入賞したのは良かったなーとか思ってました。おまけで自分のコード
https://github.com/tric/trick2015/blob/master/shinh/entry.rb
バラバラのパーツで任意コード書くってやつ。これ、前回の TRICK から考えてたネタでした。前回の時は %I{} がまだ Ruby に無かったか、気付いてなかったか、それか気付いてたけど3文字連続は避けたいと思ってたか、いずれかの理由で TRICK 2013 には出しませんでした。
eval を %I{ #{ ?e + ?v + ?a + ?l } } で作ってるわけですが、これは遠藤本に載っているテクニックだったということで…全く気付いてなかったのは何故かっていうと、あまりマジメに読んでなかった章の、基礎的なことが並んでるところにしれっと書いてあったから、じゃないかなあと。
あとまあ remarks に書きましたが、整形手法も結構気にいってます。短いので。
a=File.read("remarks.markdown").split puts a.pack("A15"*a.size).unpack("A61"*19)
もうひとつおまけ
落選した作品に言及するのはどうかと思うんですが、まあいいだろってことで。落選したやつに Yusuke Endoh て書いてある物があって、しかもやることもコードも比較的まあ、どうでもいいかな…的な。はたしてこれは本人なのか、 mame 騙りなのか考えましたが、どちらのケースでも Yusuke Endoh を名乗って有利になることはちょっと考えずらい。本人が捨てエントリに自分の名前を冠することで、他に Yusuke Endoh がいないとアピールしている…などなど困惑しました。
まあなんにせよこんなもん最低点でいいやろ、と容赦なく死んでもらいました。そしたら本人だったびっくり。
まとめ
投稿してくれた方々、ありがとうございました。前回以上に読むの大変でしたが、大変楽しかった。前回に引き続き、技巧的なものも一発ネタ的なのもほどよく混じった感じだったのが良かったかなーと思います。
printf 用のマクロの話
C言語 Advent Calendar 2015 - Qiita 向け
15年ほどC++書いてるんですが、どんどん自分の書くコードがbetter Cになっていっているような気がしています。どんどん先進性みたいなのが劣化している気がするので、特に高度なことは書かない…というか書けないです。
で、なんか C++ でも printf を使ってしまう傾向にあります。
- cerr だと endl 書かないといけないのがめんどくさいけど自動で改行足すようなやつ作るのは少しめんどくさい
- フォーマット指定子が思い出せない
という2点が主な理由かなあと思います。あとなんか % で書いてある方が出力が予想しやすいことが多いような気がするんですよね。特に括弧とかがたくさん登場する場合。
LOG("setenv(%s, %s)", name, value); LOG << "setenv(" << name << ", " << value << ")";
のどっちが良いかというような話。
iostream 使えば operator<< のオーバーロードで自分の型でも表示できる、てのが嬉しいということがあるかと思うんですが、このへんはマクロ使うと少しラクになったりとか。例えば kati ではファイル名と行番号を保持する
typedef struct { const char* filename; int lineno; } Loc;
みたいな型があったんですが、これを出力するために
#define LOCF(loc) loc.filename, loc.lineno
みたいなマクロを定義して
Loc loc; fprintf(stderr, "%s:%d: something something\n", LOCF(loc));
みたいな感じで使っていました。このマクロだと LOCF に渡したものに副作用があると二度評価されてしまいますが、まあ普通問題にはならないでしょう。。
次の例はヌル終端してない、 Pascal 文字列のようなやつ。
class StringPiece {
public:
const char* data() const { return ptr_; }
size_type size() const { return length_; }
};これも
#define SPF(s) static_cast<int>((s).size()), (s).data()
みたいなマクロを定義してやると、
StringPiece str; fprintf(stderr, "str=%.*s\n", SPF(str));
というようにすると出力できたりします。 %.*s で文字数を変数で指定できる、ていうちょっとマイナー気味な機能を使っています。
他のマクロネタも書こうかと思ってたんですけど、なんか nothingcosmos さんのやつとかぶってるような、かぶってないようなという感じだったので、書き気も起きなくなったので省略。
HITCON CTF 2015
今回は fuzzi3 というなんか卑怯な人の多さのチームに混ぜてもらいました。用事もあったのでゆるく参加するつもりが割と頑張ったけ。けどゆるく参加しても貢献度変わらなかったんじゃね？という感じの成果でした。
チームがものすごいので4位。他人の成果に乗っかってなんかするのができるのはラクだなーというのと、ちゃんと自分の成果を後に引きつげるように考えるべきだなーとか思った。
https://ctf2015.hitcon.org/scoreboard
hard to say
なんか shell 呼べる Ruby で記号しばり 10B で cat flag しろ、という問題。4つにわかれてる問題で、1つ目とかは結構サイズ制限ゆるい。とりあえず任意コードの記号化プログラム的なものが手元にあるのでそれで1問目終了。全チーム最初の1以上の得点だったと思う。
2,3とうーんどっちかというとshell芸だなーと思いつつ m4 flag とかしてこなす感じで。4つ目は全然わからなくて、1つ目で環境見て遊んでる最中に書き込める領域見つけたのでそこに cat flag て内容のファイル書いて実行して終わり。
https://gist.github.com/shinh/4999b3d154aafc774b91
本当は $0 が /bin/sh だからそれ使えば良かったらしい。
おでかけに行く。
babyfirst
出先で docs を見ると、空白と改行と \w+ だけで shell のコード適当に動かせるよ、 wget
まー redirect っしょーと色々やるも、どうもファイル名が index.html になる。 ftp どうよ、と ftp://.../robots.txt にリダイレクトすると robots.txt という名前で落ちてくる。ああこれいけるなーと思ったけど anonymous write できる ftp わからんかったし ftp サーバ出先で上げるのは困難な気がしたので(よく考えると VPS 使えばできたが)、チャットで言ったら他の人が終わらせてくれた。
risky
酒飲んで帰って、適当に見てると risky というのが x86 でない謎アーキテクチャで僕好み。見る。適当に PLT とか見て命令推測…とか少しやってたけどよく docs 見ると RISC-V であることはわかってたぽいので、ツールチェインインストール…とかやってたけどよく見ると他の人が objdump の結果はってた。
適当にアセンブリを方程式にするコード書いて、でこれどうやって解くかな、と思いつつ結果を docs に貼ってたら、他の人が z3 にかけて終わらせてくれた。なるほどこういう時に使うのかーと。これは解析的にも解けたと思うけど、まああきらかに便利そうだから使いかた覚えよう。。
moonglow
心を砕いた問題。フラグのファイル名を知らないプロセスから、同じUIDで動いてる、フラグを知ってるプロセスにフラグの内容を送って、あってるか間違ってるかをチェックしてもらう、って問題。
chroot の中にいるので /proc/*/cmdline とか見てコマンドラインに渡されてるフラグの名前を調べたりできないし、フラグの置かれてるディレクトリは x しか立ってないので中を見ることはできない。 ptrace は yama に殺されている。
なんかマイナーなシステムコールを使うか、チェックにかかった時間を計測するしかないかなーとあれこれする。 prlimit がなにかに使えそうだなーとコアを吐くように変更してみたりするもダメ。 Ubuntu だと apport かなんかに投げるのと、あとそもそも core て chroot されてると出ないらしい。知らなかった。
あと試したのは inotify syslog などなど。時間はかる方も、なんかの間違いで wait4 できねーかなーとやってみたり少し待ってから kill 送って死んだか死んでないかで分離できないか一応チェックしたり。まあ無理に決まっていた。
答えは perf_event_open だったらしい。なるほど perf かー。思いついても良いレベルだった気がするなあ…と悔しい。
