CTFっぽい話(john)
ksnctf という CTF があります。
そもそもctfとは…。
CTF(Capture The Flag)とは、コンピュータセキュリティ技術の競技である。CTFは通常、参加者に対しコンピュータを守る経験に加え、現実の世界で発見されたサイバー攻撃への対処を学ぶ教育手法として企画されている。「ハッカーコンテスト」「ハッキング大会」「ハッキング技術コンテスト」「ハッカー大会」などとも訳される。
※(Wikipedia より)
ksnctfは、そんなctfのオンラインバージョンなわけです。ググれば出てきます。
今回はその中の14問目、「john」を解いた際の解説をします。
※以降ネタバレ要素を含みます(というか思いっきりネタバレ)なので、自分で解きたい方はブラウザの戻るボタンを押してください。
問題
まずこれが問題の画面です。
こういう画面が出てくるわけです。
これは知っているかどうかの問題だと思いますが、僕はちょうど学校のカリキュラムでLPICを学んでいたので、この文字列の集合が「なんとなく shadow ファイルっぽい」という手がかりを最初に掴みました。
手始めにこの文字列をコピペして、「 testpassword 」という名前のファイルで保存します。
(shadow ファイルとは、ホストに居るユーザのパスワードを暗号化して格納するファイルです。/etc 以下にあり、基本的にスーパユーザしか読めません。)
つまり、shadow ファイルの中身は暗号化されているので、復号してあげればいいわけです。
復号①
とりあえず中身を cat してみます。
問題の画面で気づいた方も居るかもしれませんが、user99 の行にURLが書いてありました。
因みに、このURLにアクセスすると、末尾の拡張子からもわかるように、テキストファイルが現れます。とりあえず、「 dictionary.txt 」という名前で落としました。
ここで dictionary = 辞書 という名前のファイル名にしたのは、 shadow ファイルの解析によく用いられるパスワード解析ファイル「 john the ripper 」で使用する為です。
ただの無作為な文字列の並びだったこともあり、恐らくこれを辞書攻撃用のファイルとして使用してあげれば良いのでは、と思ったわけです。
復号②
さっそく yum install john します。
無事に落とせたので、ヘルプをみて使い方を確認します。
解析のモードはいくつかあるようですが、ここでは「 --wordlist 」オプションを使いました(先ほど落とした dictionary.txt を使うので)。
オプションを指定して実行するコマンドが以下のようになります。
# john --wordlist=dictionary testpassword
このコマンドを実行します。
すると、user~~ のそれぞれのパスワードが少しずつ解析されていきます。
解析後のファイルを見るには、 --show オプション付きの john コマンドを呼んであげればよいです。
# john --show testpassword
すると、解析されたパスワードの一覧が表示されます。↓
user04 のパスワードがおかしい、と思い小一時間悩みましたが、ヒントはそこではなく各ユーザのパスワードの先頭文字でした。
画像にある通り、「 FLAG_a... 」となっているのが解ります。
そこで、今度は python の出番でした。
復号③
解析後、 --show オプションで閲覧できるファイルを、.txt 形式のファイルに保存します。
# john --show testpassword > foo.txt
生で叩いても良さそうですが、今回の解説用に上記のコマンドを実行しました。
先ほどの画像からもわかるように、どうやらパスワードの先頭文字は８文字目からのようなので、 index にすると７に当たる部分の文字を取得して、連結していってあげるとよいことが解ります。
ソースコードはこちらです。
テキストファイルとして保存した foo.txt を一行ずつ取り出して、連結していきます。
実行結果がこちらです。
これを最初の問題の画面にあるテキストフォームにコピペしてあげると、正解となります。
まとめ
今回はVM上の CentOS5.8 を使って解きました。
問題文を解くきっかけとしては、最初の画像を見て shadow ファイルを推測できるかどうかが鍵かと思います。
ちなみに、解析前のパスワードの先頭についていた「$6」という文字列は、SHA-512で暗号化されている、という印らしいです。
rails のエラーと解決（カラム名と予約語）
rails アプリ開発中の出来事です。
作成しようとしていたのは学生を扱う users controller と user model。
(student で良い気もしますが…)
そこで躓いたのが model の作成でした。
controller や model の作成はすんなりと通るのですが、それをいざ見てみよう、と
ブラウザで view を表示した途端にエラー。
NoMethodError - undefined method `[]' for nil:NilClass:
みたいなやつが…
user model に紐づいた form_for の記述内容を変えてみたりしましたが、一向に改善しない……。
console では、
ActionView::Template::Error (undefined method `model_name' for {}:Hash):
1: <h1>Create User</h1>
2: <p>please additional your information.</p>
3: <%= form_for @user do |f| %>
4: <%= f.label :name, 'Name' %>
5: <%= f.text_field :name %>
6: <%= f.label :username, 'Name' %>
app/views/users/new.html.erb:3:in `_app_views_users_new_html_erb__1488396736_9
3375700'
と表示されます。
タイトルにエラーの原因と解決理由をサラッと書いてしまっていますが、エラーの原因は model のカラム名に予約語を使っていたことでした。
生徒個人を区別する情報として、在籍クラスを持たせることを考えていたのですが、何も考えずにカラム名を "class" にしていました。
このエラーを解決するために数日を無駄にしたのは内緒です。笑
まとめ：
まとめるほどでもないですが…
rails は scaffold など、細かく便利に設定してくれる頼りになる存在な感じがしますが、エラーの括り方はだいぶ雑だなーという印象を受けました…
もう少し細かくエラーの内容を知れるといいですね！(エラー出さないのが先決)
Rails での link_to , button_to に対する css の適用について
rails アプリケーションを作成中なのですが、妙な所で躓いたのでメモ。
link_to と button_to への css の適用についてです。
まずは正解(？)というか、適用できた時(最終的にこうなっただけ)のソースから。
このように、:controller と :action を {} で括っています。
:class オプションで指定している"btn btn-***"
という要素については、
Bootstrap · The world's most popular mobile-first and responsive front-end framework.
を参照してください。
ちなみにこの場合、 css は適用されますので、実行画面上ではこういう風になります。
僕自身、rails 初心者という事もあって、この場合の {} の有無がそれほど重要だとは思っていなかったので、作成当初は以下のように記述しました。
するとどうでしょう。bootstrap が適用されるはずのリンクに、 css が適用されませんでした。
さっぱりわけが解らなかったので、google先生に働いてもらったり、API等をチラッと読みに行ったりしたのですが、スッキリするような答えは得られず。
しかしその時点での僕の考えとしては、 {} の有無によって rails 側での解釈のされ方が変わるからなのだろう、と思っていました…(確信はない)。
ようやくそれらしき資料を発見し調べたところによると、
第２引数の中にある予約パラメータ以外のものは、クエリとして渡される
らしいです。
つまり、{} をつけない場合、予約語である controller と action がURLとして、予約語ではないオプションの class はURLに付随するクエリとして、渡されることになる、ということらしいです。
例：/users/new?class=btn%20btn-***
になるわけです。(%20はパーセントエンコーディングされた半角スぺ―スです)
更にそこで、
第２引数をハッシュにすればURL情報であることを明示でき、また第３引数が確実にhtml属性になる
という情報を得ました。
ここでおさらい。
ハッシュとは
ハッシュとは、簡単に言うと「連想配列」の事です。通常の配列と同じように複数のオブジェクトへの参照をまとめて管理することが出来ますが、配列と大きく異なる点として、配列がインデックスを使って要素を区別していたのに対し、ハッシュでは「キー」と呼ばれるものを使用する、という特徴があります。
キーに対応した値を一般に「バリュー」と言います。
例：{ key1 => value1, key2 => value2 ...}
本題に戻ります。
先ほど得た「第２引数をハッシュにすればURL情報であることを明示でき、また第３引数が確実にhtml属性になる」という情報を基に、第二引数をハッシュにすると、最初に載せたコードに辿り着きますね。
:controller と :action を {} で囲みハッシュとして扱うことで、まとめて第２引数にしているわけです。
それにより、第３引数となった :class => 'btn btn-***' が無事に html 属性として解決されたわけです。
button_to の場合でも、上記の方法で css を適用させることができました。
因みに button_to だと、bootstrap を使うと改行されてしまうようですが、該当部分のcssを { display: inline-block; }とすると、改行は弾けるはずです。
参考記事：
Rails - link_to の引数と展開の違いまとめ - Qiita
javascript でのタイマー処理について (setInterval,setTimeout)
同じく前回の記事で書いたゲーム作成中の事です。
ゲーム内部の処理で、一定時間毎に問題の切り替え、正誤判定等を行いたいと考えていたところ、候補として二つの関数を発見しました。
setInterval と setTimeout です。
使ったり調べたりしている内に細かい挙動の違いが気になったのでメモとして。
両者とも基本的にループ処理に用いられる事が多い点などでは同じです。
簡単な相違点を見てみましょう。
setInterval の場合
大きな特徴としては、スタックやランタイムを考慮せずに指定時間毎に処理を行うという点です。
つまり、以下の画像内のコメントのような状態が起こり得る事になります。
この処理、実はsetTimeoutで書き換える事によって、ブラウザのクラッシュという問題を防ぐことが出来ます。
見てみましょう。
setTimeout の場合
setInterval と比較した場合の大きな特徴として、setTimeoutではスタックやランタイムを考慮するという特徴があります。
上記ソースコードのような「ある処理を三秒ごとに繰り返し」たい場合、こうなります。
最後の関数呼び出しでファンクションに入り、再帰的な処理が実行されるイメージです。
setInterval との違いは、一言で言うと前処理の終了を待つかどうかです。
このような記述により、予想しない結果が返されるのを防ぐことができます。
ループの停止
二つのコードを見て気づくと思いますが、上の処理は両方とも永久ループです。止まりません。
ということで、続いて二つの処理を止める方法を考えます。
まずはsetIntervalを用いたループの場合。
通常、カウンタぽいものを用いて止める形になります。
先述のコードを書き換えたものがこちらです。
カウンタ(1行目)をループ内でインクリメントさせ、3回目でループから抜け出しています。
コンソールも無事に。
ちなみに、カウンタの宣言をファンクション内に書いてしまうと、当然永久ループになります(呼び出しの度に生成されるので)。
次に、setTimeoutの場合。
停止処理追加後はこのようになります。
setIntervalでも同じような記述でしたが、setTimeoutそのものを変数に入れ、clearTimeout側の引数にしています。
コンソール。
こちらも無事に3回目の出力後に処理は停止しています。
注意点としては、finished の時間が約6秒となっている事です。
setTimeoutの場合、ソースコード末尾でファンクションを呼び出していますが、この最初の呼び出しでは3000ミリ秒の待機を行いません。
そのため、2回目と3回目の待機(3秒*2回)のみが存在するかたちになります。
まとめ的な。
以上の話をまとめると、こうなります(※筆者推測)。
・setInterval()
前後の処理に関わらず、独立して指定時間ごとに実行。
つまり、起動間隔の指定。
ユーザ操作などが必要ない機械的なループに適する。
内部の処理が重過ぎると、スタックオーバーフローの危険性がある。
・setTimeout()
基本的には、引数に与えた関数を、指定ミリ秒後に実行する形(シンタックス参照)。
つまり、待機時間の指定。
前後の処理を考慮するので、スタックオーバーフローの危険性は極めて低い。
調べ始めた時に中々理解できず、納得するまで続けていたらゲームの進捗が遅れたのは内緒です。
今回はここまで。
2014
2014年も終わろうとしています。
ちゃんとした投稿は年明けから始めようと思っているのですが、
少しだけ2014年を振り返りたいと思います。
実は今年の4月に国家試験を受験していました。
応用情報処理技術者試験、通称APです。
結果は、合格ラインギリギリでの合格でした。
二度目の受験だったので、1年分の蓄えが功を奏した形になるのだろうと思います。
ここでもしかすると、
「AP持ってる人のtips…」みたいなバイアスがかかり、「そこそこデキそう」な人だと思った人も居るかもしれませんが、ことプログラミングに関しては、まったくの初心者といっても過言ではありません。
最低でも1tips/月くらいのペースで何か書ければいいなーと思っている程度のブログなので、お手柔らかにお願いします。
ちなみに、Mac Book Air を先日購入したばかりなので、だいぶ浮かれています。
