Category Archives: 日記

SECCON CTF 2014 Online 予選 Write Up #2

前回 #1 に引き続き、SECCON CTF 2014 Online 予選 (2回目) のWrite Upを。

次に解いたのが、Network 300 の”Get from curious “FTP” server”です。

nw300FTPサーバを教えられるので、ftpコマンドで繋いでみると、LISTができません。

そこで、telnetで直接繋いでみて、STATコマンドを実行してみると、”key_is_in_this_file_afjoirefjort94dv7u.txt”っていうファイルが見つかるのでダウンロードしたらOKです。

ftp

 

ちなみに、MacのCyberduckで接続すると、なんの問題もなく一覧の表示とダウンロードができてしました…

 

SECCON CTF 2014 Online 予選 Write Up #1

昨日の9時から今日の17時ににかけてSECCON CTF 2014のオンライン予選(2回目)が開催されてました。

すでに、前回の予選で出場権を得ているため、今回は練習ということで出場していました。

今回のメンバーは

  • @__math
  • @aki33524
  • @misodengaku
  • @chibiegg

の4人でした。チーム名はMt. Takedashiです。今回は、みんな、映画に行ったり、バイトに行ったり、出かけたり、10時間ぐらい寝たりと、稼働率30%もないんじゃないかという状況で点数は残念な結果でしたが、出場権を気にせずに問題が楽しめて良かった感じです。

で、僕が解いた問題、そうでない問題を含めてちょっとまとめてみようかなということを(モチベーションが続けば)やってみようと思います。

途中のスクリーンショットなので全部載ってるかちょっと怪しいですが、問題一覧はこんな感じです。

SECCON CTP 2014 オンライン予選 問題一覧

まず、僕が解いた順でいきたいと思います。朝起きたじてんで結構他の人が解いてたので、まだ手がつけられていなかった”SECCON Wars: The Flag Awakens”をときました。

qr300

Youtubeの動画がわたされるので再生してみましたが、どこがQRコードに関係するのかさっぱり…

seccon_tube1

なんどか見返してると、SECCONのロゴの下にQRコードが流れているではないですか!

seccon_tube2

さっそくPhotoshopでフレームをレイヤーにして取り込み、境界線でわかりやすいようにして、少しずつ復元していきました。

qrps

で、復元したQRコードをZXingにかけて、デコードすればおしましです。

qr300

とびだせ!QRコード

とびだせ!QRコード

お久しぶりです,関西電力計画停電配信システムの紹介から5ヶ月,全く何も更新してませんでした.すいません.

で,今回は新しく開発したサービス「とびだせ!QRコード」を紹介します.

11月に任天堂から発売された3DS用ゲームソフト「とびだせ どうぶつの森」がかなりヒットしているみたいですね.で,ゲームの詳細は省略しますが,このゲーム,以前の作品からですが,看板や,衣装など,自分でデザインする機能「マイデザイン」がついています.

この機能を使うと,例えばこんなかんじで,好きなデザインの服をつくることができます.

マイデザイン

マイデザイン

前作まではここまでなのですが,今作から作った「マイデザイン」をQRコードにして他の人にプレゼントすることができます.

今回の新サービス「とびだせ!QRコード」はこのQRコードを投稿し,みなさんが「マイデザイン」を共有できるサービスです.アクセスはこちらから!

とびだせ!QRコード   トップページ

とびだせ!QRコード トップページ

これまでも,画像を投稿して,画像掲示板のように共有できるサイトはありましたが,タイトルで検索したり,マイデザインを編集できるようなサイトはありませんでした.

そこで,マイデザインのQRコードを解析し,QRコードからタイトルや作った人の名前などを抽出できるようにしただけではなく,タグ付けもできるようにし,できるだけ「マイデザインの共有」に特化した使いやすいサービスにしてみました.

また,投稿だけでなく,画像ファイルからマイデザインを作成する機能もつけてありますので,是非つかってみてください.

編集については,まだタイトルの編集しかできませんが今後デザイン自体の編集も可能にできるようにする予定です.

まだまだできたてのサービスですが,みなさんどんどん投稿して使ってください!

P.S. 3DSに搭載されている「インターネットブラウザ」からも,投稿できます!是非気軽に投稿してみてください.

とびだせ!QRコード(3DSのブラウザ)

とびだせ!QRコード(3DSのブラウザ)

Can you crack it?

Can you crack it? クリア

イギリスの政府通信本部(GCHQ)が現在採用活動の一環として、「Can you crack it?」と題して暗号解読クイズページを公開しています。

イギリス人であればこれをクリアするとエントリーフォームからエントリーできるみたいです。

Can you crack it?

Can you crack it?

で、先日大学の友達と相談しながらクリアしました。

Can you crack it? クリア

Can you crack it? クリア

実はこれ、表示されてる問題をクリアしたと思ったらstage 2 of 3が出て来ます(笑)。

面白かったので、解答までの流れをブログに書きたいのですが、期日まであと1日ちょっとあるので、その後にします。

stm32f10x_can.c のバグについて

前回の投稿と打って変わって組込系の話題を。

最近STM32でCANとか使っているのですが、時々送信に失敗してしまうという問題がありました。

たまになので問題ないのですが、気になったので調べてみるとSTMicroが用意しているSTM32F10x standard peripheral libraryのバグでした。バージョンは04/16/2010 のV3.3.0と古いやつですが。

具体的に言うと、現在送信しようとしているメッセージの状態を確認する関数

CAN_TransmitStatus にあります。

ここでは CANxのTSRレジスタのTSS_RQCP0、TSR_TXOK0、およびTSR_TME0ビットの値を見て、

CANTXPENDING(送信中)、CANTXFAILED(失敗)、CANTXOK(成功)を返しています。

が、こんな風にレジスタにアクセスするようなコードになってます。

switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((CANx->TSR & TSR_RQCP0) << 2);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK0) >> 0);
      state |= (uint8_t)((CANx->TSR & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((CANx->TSR & TSR_RQCP1) >> 6);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK1) >> 8);
      state |= (uint8_t)((CANx->TSR & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((CANx->TSR & TSR_RQCP2) >> 14);
      state |= (uint8_t)((CANx->TSR & TSR_TXOK2) >> 16);
      state |= (uint8_t)((CANx->TSR & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

これでは、レジスタに3回アクセスしてしまっており、アクセスとアクセスの間でレジスタの値が変わってしまうと変なstatusになってしまいます。その結果 default で CANTXFAILED がセットされてしまうというのが送信失敗の原因です(実際にはこの瞬間に成功しているが、失敗したと判断してしまう)。

最も修正量の少ない解決策は簡単で、CANx->TSRの値を一旦変数に入れてやればいいのです。

uint32_t _tsr =  CANx->TSR;
switch (TransmitMailbox)
  {
    case (0): state |= (uint8_t)((_tsr & TSR_RQCP0) << 2);
      state |= (uint8_t)((_tsr & TSR_TXOK0) >> 0);
      state |= (uint8_t)((_tsr & TSR_TME0) >> 26);
      break;
    case (1): state |= (uint8_t)((_tsr & TSR_RQCP1) >> 6);
      state |= (uint8_t)((_tsr & TSR_TXOK1) >> 8);
      state |= (uint8_t)((_tsr & TSR_TME1) >> 27);
      break;
    case (2): state |= (uint8_t)((_tsr & TSR_RQCP2) >> 14);
      state |= (uint8_t)((_tsr & TSR_TXOK2) >> 16);
      state |= (uint8_t)((_tsr & TSR_TME2) >> 28);
      break;
    default:
      state = CANTXFAILED;
      break;
  }

こんな風に。

で、最新のV3.5.0ではちゃんと修正されてました。

switch (TransmitMailbox)
  {
    case (CAN_TXMAILBOX_0):
      state =   CANx->TSR &  (CAN_TSR_RQCP0 | CAN_TSR_TXOK0 | CAN_TSR_TME0);
      break;
    case (CAN_TXMAILBOX_1):
      state =   CANx->TSR &  (CAN_TSR_RQCP1 | CAN_TSR_TXOK1 | CAN_TSR_TME1);
      break;
    case (CAN_TXMAILBOX_2):
      state =   CANx->TSR &  (CAN_TSR_RQCP2 | CAN_TSR_TXOK2 | CAN_TSR_TME2);
      break;
    default:
      state = CAN_TxStatus_Failed;
      break;
  }

一度でアクセスするようになってます。でも返値変わってて、最新版に置き換えるのは大変そう…

nginxでSSL/TLSを使う

今回はSSL(https)を使えるようにするような設定をnginxにしてみようと思います。

証明書の取得

本来はSECOMやVeriSign等に有料で証明してもらうのですが、今回は以前にも紹介したCACertを載せときます。

ということで、証明書の取得は省略します。とりあえず、サーバーの秘密鍵 server.key と サーバーの証明書 server.cer が手に入った事にします。

nginxに設定

nginxでの設定は簡単で、既存の設定をコピーして、80番ではなく443番に変更し、SSLを有効にしてサーバーの鍵・証明書のファイルを指定してあげるだけです。

ちょっとその部分だけ書いてみます。

server {
	listen   443 default_server ssl;
	server_name	_;
	ssl_certificate /keys/server.cer;
	ssl_certificate_key /keys/server.key;

	location / {
		この辺は適当に
	}
}

リバースプロキシとしてnginxとして使っている場合も同様です。

名前ベースのバーチャルホストを使っている場合

ドメイン名を複数つかってバーチャルホストを使っている場合もあると思います。SSLではアクセスされたサーバー名がわかる前に証明書を渡さなければならないので、名前ベースのバーチャルホストでSSLは利用できませんでした。

が、SNI(Server Name Indication)というプロトコル拡張ができたので、名前ベースのバーチャルホストでも可能になりました。(ブラウザによっては対応してません)

設定は簡単で、httpと同じくserver_nameを設定するだけです。

リバースプロキシとして使っている場合は、証明書を変えるために、バーチャルホストの数だけServerディレクティブを作ってあげてください。

 

 

nginxでプロキシ&キャッシュサーバー

(多分)一般的なWebサーバーであるApacheは複雑な設定も可能で便利なのですが、その分重いのです。

どう重いのかというと、Apacheは一つのプロセスが一つのHTTPリクエストを同期処理で裁いてるのでその間は他の処理をしません。なので、同時アクセス数が増えるとApacheはプロセスをどんどん生成します。(あるいは後からきたリクエストを待たせる)

なので、アクセス数が増えると急激にパフォーマンスが落ちるという問題を抱えてます。(ほかにもプロセスIDが足りなくなってどんなにリソースがあっても最大プロセスIDで制限されてしまう)

で、最近話題のハイパフォーマンスWebサーバーがnginx(えんじんえっくす)です。

nginxは一つのプロセスで複数のリクエストを非同期で同時に処理します。なので、アクセス数が増えてもパフォーマンスが落ちにくいという特性があります。特に静的ファイルの場合は処理のほとんどがI/O待ちなので効果が大きいです。

そこで、PHPとかSVNとか設定がめんどくさいものはApacheに任せておいて、静的なファイルだけをnginxに処理させてみると、Apacheへのリクエスト数は激減するはずです。

例えば、このブログのトップページの場合PHPで生成されるHTMLが一個にたいして、CSSや画像等の静的ファイルが20個近くあります。単純計算で21個のリクエストのうち1個だけがApacheで処理されるのでApacheへのリクエストは約95%削減されます。

では設定してみましょう。OSはUbuntu Server 10.04(64bit)です。Apacheは既にインストール済みで運用されているとします。設定後はnginxがポート80で待ち受けて、Apacheはポート8080で待ち受けるということにします。

(記事の最後でキャッシュファイルをRAMに置くというのもやってみます)

Read more …

WordPressはどうすれば速くなるのか、検証実験

さっきの投稿でWordPressが遅い事を書きました。で、先輩のさくらのVPS(nginx+fastcgi)では速いってことも書きました。

ということで、僕も借りてるさくらのVPSで一からセットアップして実験してみました。OSはデフォルトではなくUbuntu 10.04が入ってます。

今回検証したのは、WebサーバーはApache/2.2.14とnginx/1.0.9、RDBMはMySQL(Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using readline 6.1)とPostgreSQL/8.4.9です。なので、合計4通りですね。

Apacheではmod_phpで、nginxでは後ろでspawn-fcgiが動いてます。

で、試してみた結果です。今回検証したいのは静的ファイルではなくPHPの出力なので、画像とかCSSがブラウザでキャッシュされてたりするのは気にしないでください。

Apache + MySQL + WordPress

Apache + MySQL + WordPress

Apache + PostgreSQL + WordPress

Apache + PostgreSQL + WordPress

nginx + MySQL + WordPress

nginx + MySQL + WordPress

nginx + PostgreSQL + WordPress

nginx + PostgreSQL + WordPress

平均もとってない1回こっきりのアクセスの結果なので互いの比較はそんなに意味がないです。

が、どれもレイテンシが数百ミリ秒あります。これは何回試しても同じでした。

あれ?…

先輩のVPSと同じ環境のはずなのになんでこんなに違うの?

WordPressが遅い…なぜ?

最近サーバーの設定を変えたり、リバースプロキシをしてる、HTTPのフロントをApacheからnginxに変えたり高速化を試みています。

が、どうしてもこのブログ(にかぎらず、稼働しているWordPress全部)が重い、というより遅いのです。
Memcachedでオブジェクトをキャッシュしてみたりしても改善されず…

で、Safariで開発ツールの「ネットワーク」をつかって取得の時間を見てみました。

Apache(mod_php) + WordPress 処理時間

Apache(mod_php) + WordPress ネットワーク時間

ここでPHPのファイルへのアクセスのレイテンシが334msもあることに気づきました。稼働しているどのWordPressもです。

で、WordPressはそうなのかと、さくらのVPSで運用してる先輩のWordPressを見てみると…

 

さくらのVPS nginx + WordPress(fast-cgi)

さくらのVPS nginx + WordPress(fast-cgi)

速い….レイテンシ45msです。静的ファイルはうちのサーバーのほうがレイテンシ含め速いので(どちらも304なので比較していいかな)、ネットワーク等の問題ではないみたい。

(あと、向こうはnginx+fastcgi(swanかな?)+WordPressですが、うちでもnginx+fastcgiにしてみたけど改善せず…)

なんで?

とりあえず、僕も借りてるさくらのVPSでDBをMySQLからPostgreSQLにしてみたり、いろいろ実験してみます。

 

 

東北旅行3日目

東北旅行3日目です。
この日は道の駅「とうわ」にて停泊しました。

道の駅「とうわ」

道の駅「とうわ」

まず最初の目的地はかつてカッパが多く住み、人々を驚かしたという伝説がのこる遠野のカッパ淵でしたが、途中で土木学会推薦のめがね橋を見学。(昭和18年改修)

めがね橋

めがね橋

その後カッパ淵へ、

カッパ淵

カッパ淵

カッパ淵のすぐそばでKIRINのホップ農場を発見。こんなところでつくってたとは。

KIRINのホップ農園

KIRINのホップ農園


ホップ

ホップ

この後遠野の道の駅「風の丘」に寄るとハネの形が変わった風車が建っていた。

道の駅「風の丘」

道の駅「風の丘」

こいつの風車は本体だけでなくハネ?の一本一本も回転する。(帰宅したら動画をアップする予定)

で、次は小岩井農場まきば園へ。ずっと小岩井牧場だと思ってたけれど小岩井農場だったらしい。

小岩井農場まきば園

小岩井農場まきば園


例によって例の如く小岩井農場の牛乳とのむヨーグルト。
小岩井農場の牛乳と飲むヨーグルト

小岩井農場の牛乳と飲むヨーグルト

ここで、おみやげを購入。

で、次に訪れたのは日本で最初の地熱発電所である松川地熱発電所へ。

松川地熱発電所

松川地熱発電所

大きな牛乳のビンみたいな建物は使った蒸気を冷却し水に戻す施設。
温泉が湧き出ているので川は沈殿成分でいっぱい。

で、そこで見たビデオに写っていた八幡平に行きたくなったので八幡平の樹海ラインへ。

八幡平 その1

八幡平 その1


八幡平 その2

八幡平 その2

か細い回線で書くのがしんどいのでほとんどコメントが無いけれど、これにて3日目の日記は終了。