ヾﾉ*＞ㅅ＜)ﾉｼ帳

ノンジャンルのふりーだむなブログです。

nagoya.bin（名古屋低レイヤー勉強会）の第1回に参加しましたヾﾉ*＞ㅅ＜)ﾉｼ

友利奈緒 シンボリック実行 勉強会登壇

2017年10月29日（日）に開催されたnagoya.binという低レイヤーな勉強会に参加しました。この日のために肉体改造と2 kg減量しました。その程度の減量って意味あるのと思うかもしれませんが、「肉体改造」が肝です。この話は別の機会に書きます。

nagoyabin.connpass.com

正装した友利奈緒として、シンボリック実行エンジンを自作した話をしました。資料はSpeakerDeckに上げてあります。 参加してない方も宿題やっていいですからね。

speakerdeck.com

https://speakerdeck.com/katc/bainarimeng-efalsebi-nu-gasinboritukushi-xing-nilian-zhao-sitemasuga-zhi-yue-nitiao-muyou-qi-nabiao-qing-gazui-gao-desu-1

発表者は分かるが、発表内容はわからない、統一的なテーマも無い、そんな謎の勉強会にも関わらず、初心者を脱した専門技能をもった方々が集まっていました。 これぐらいは分かっててくれへんと10分に収まらんがなってとこはカットしましたが、そこそこ言いたかったことは伝わってた感じがしました。 互いの専門性の共集合は無いけど、それは大学でもやったなーってのが多かったので、個々の発表内容がすんなり入ってきました。

会場はMisocaさんのセミナールームでした。ありがとうございました。 マイク無しで声通るかな？しかもマスクしてるんに、と思いましたけど、奥行きが狭いので声を張らずとも声は届いていたと思います。 勉強会会場としてありっすね。投写も16：9オッケーみたいですし。そろそろ16：9で作るようにしたいね～。

描き下ろしたイラストです：

www.pixiv.net

裏話をすると、このネタを作るためのプログラミング作業が10時間だったのに対して、イラストを描く時間が30時間ほど、スライドを100回以上修正するのに10時間ほどかけました。 このコストの高さは、趣味でやってるからできることっすね。大事にしていきたいです。

こうした規格を外れた創作活動は今後強化していきたいと思います。 皆さんの反応と自分のモチベーション次第では（３）がリリースされるかもしれません。 （２）はプロットができているので時間がとれるかどうかです…。 〈ダイジェスト版〉ってことはDay 3以降を含めた同人誌向けのノーカット版があるのかと思った方は鋭いです。それはノーコメントです。

太ももがまだ太いので筋トレは続けます！

VirtualBoxのWindows 10 VMに外付けHDDをマウントするのが大変だった

VirtualBoxのバージョンは5.1.128です。

Windows 10のVMでNTFSフォーマットされた外付けHDDをマウントするのが大変だったので解決手順を残しておきます。

USBデバイスを有効にするために、VirtualBox Extension Packをインストール
https://www.virtualbox.org/wiki/Downloads

この段階ではWindowsのデバイスマネージャでは身元不明のHDDとして認識されます。

次に、VMを一旦シャットダウンして、[設定] - [USB]の画面で、USB 2.0 (EHCI) コントローラを選択。

f:id:katc:20170927030550p:plain

これでマウントできるようになります。

研究生活に役立つDocker入門

Docker

f:id:katc:20171031062207p:plain

※走り書きです。

Dockerとは？＋注意書き

※Linux限定で書いてしまうが、WindowsやmacOSでも利用可能

超軽量のコンテナ型仮想化を実現するOSSソフトウェア。VMのイメージで扱うと大変危険。 コンテナはシステムの資源を間借できる高機能chroot環境と思うのが吉。

Dockerでは、Linuxのカーネルをホストとコンテナで共有する。これはコンテナがLinuxカーネルの機能で実現されているからである。 コンテナの中から見えるファイルシステムは厳密に独立していないので、/bootとかは触ってはだめ（/etcはOK）。 systemd（pid 1系）は使えないので気をつけて。 先述の注意点がクリティカルな場合は素直にVagrantなりVirtualBoxなり使うのが賢明。

Dockerがなぜ研究生活向けなのか？

研究室で受け継がれるVMイメージはときに邪悪である。 OSのインストールは良いとして、その後に何をどうビルドしてインストールしたのかが全く明らかではない。 別にドキュメントを用意することが必要になってしまう。 また起動と実行のためにCPUとメモリを多く奪われてしまうのは全くイケてない。

Dockerを使って研究を進められる環境を作ると次のようなメリットがある。

  • Dockerfile（後述）がそのまま環境構築手順書になる
  • 起動が速く、ホストとシームレスにつながる（※ホストPCがLinuxの場合に限る）
  • Dockerfileをgitなどでバージョン管理すると、いついつのときのコンテナを起動することができる（※image（後述）をビルドする時に細工が必要）
    • システム変更を記録に残す癖がついて良い
  • コンテナ起動後にした変更が破棄されるので、同じコンテナを使っている限り、システム側が原因で「前まで使えたのになぜか使えなくなった」が起こり得ない
    • 試しにいじって上手く行ったらDockerfileに反映するアプローチも良し

ただし、以下のデメリットもあるので注意が必要。

  • ウインドウマネージャの恩恵を受けられない（が、GUIアプリの画面を出すことは可能）
  • 複数のターミナルを出すのがサーバーと同じくらい少し大変（が、こんなのは慣れの問題）
  • Dockerfileを変更してコンテナを更新するまでに大変時間がかかることがある（変更方法に依存するが、覚悟が必要）
  • Dockerfile作成にあまりネットで言及されないコツが必要（後述）

インストール方法

Ubuntuは以下の記事で良いと思われる。 [Docker] ubuntu 14.04/16.04にDockerをインストール - Qiita

Arch Linuxの場合は、

sudo pacman -S docker
### 自分にdockerグループを追加
sudo usermod -aG docker `whoami`
### dockerを自動起動
sudo systemctl enable docker

ここで完了させておくことは、

  • dockerのインストール
  • ユーザーにdockerグループを追加
  • dockerデーモンの有効化（ないしは sudo docker daemon をLinuxが起動する度に手動実行）

である。

コンテナ起動

コンテナ起動時に実行するプログラムを指定する。通常はbashを起動する。 後述するDockerfileにCMDとして起動するプログラムを明示していないケース／誤ったCMDの指定がされることがあるので気をつけること。 Dockerfileを信頼せず、コマンドラインで明示するのが安全である。

コンテナ起動のコマンドは次の通り：

### ubuntu 14.04の場合
### オプションは "run it" で覚えるのがおすすめ
docker run -it ubuntu:14.04 bash
#### runの前に `docker pull ubuntu:14.04` が必要かも
### プロセス終了時にコンテナを破棄したいとき（--rm）
### オプションは "run, remove it" で覚えるのがおすすめ
docker run --rm -it ubuntu:14.04 bash

動作確認のために上記コマンドを実行してUbuntuのbashシェルが出ることを確認してほしい。 ネットワークからimageがダウンロードされるので初回の起動は時間がかかる。 imageとはコンテナを起動する種になるものである。 これは次節で説明する。

高度なコンテナ起動オプションとDockerあるあるについては後半で述べる。

imageの作成

imageはコンテナ起動の元になる「種」のようなものである。 imageの作成は2通りの方法がある。

Dockerhub   Dockerfile
   |            |
  pull        build
   |            |
 [      image      ]
          |
         run
          |
 [    container    ]

1つ目はDockerhubからpullする方法である。あまり使わないので説明は省略。気になる人は「docker pull dockerhub」でググって。

2つ目はDockerfileからbuildする方法である。 Dockerfileはこの名前で存在するファイルである。 Dockerfileがあるディレクトリまで移動（cd）して、

docker build -t IMAGE_NAME . # IMAGE_NAME must be lowercase
### or
docker build -t IMAGE_NAME -f DOCKERFILE_PATH
### without cache
docker build -t IMAGE_NAME . --no-cache=true

のどれかの形式で実行すると良い。IMAGE_NAMEは制約があるので小文字でいい感じに付けると良い。 buildはキャッシュを使ってされる。apt updateで不都合が起こる時はこのオプションを付けるとよい。

Dockerfileの構成

大抵の場合上の行から、

  • FROM（必ず1番上に書くこと）
  • MAINTANER（省略可）
  • RUN または ADD または ENV または WORKDIR または USER（これが複数行続く）
  • CMD または ENTRYPOINT （省略可；1行のみ）

の順に書かれている。

FROM

FROMはベースとなるimageを指定する。何も考えずに

FROM ubuntu:16.04

か

FROM ubuntu:14.04

と書くといい。

MAINTANER

メンテナーの情報を書く欄。自由に

RUN

ベースのimageで実行するコマンドを書く。複数行に分けたい時は行末に「半角スペース＋バックスラッシュ」

例えば、

RUN sed -i.bak -e "s%http://archive.ubuntu.com/ubuntu/%http://ftp.iij.ad.jp/pub/linux/ubuntu/archive/%g" /etc/apt/sources.list && \
    apt update && \
    apt install -y git automake pkg-config libssl-dev
RUN apt install -y curl wget bash-completion net-tools strace silversearcher-ag mlocate vim

シェルスクリプトの要領でガリガリ書いていく。コマンドはroot権限で実行されるのでsudoは付けなくて良い。 ちなみにRUNごとにキャッシュが生成される。

1つ前のRUNでcdして、次のRUNでそこの場所でコマンドを実行はできない。RUNごとにカレントディレクトリがリセットする。 cdのし忘れには気をつけよう。面倒な時は後述のWORKDIRが便利。

ADD

外部ファイルをimageに追加するコマンド。Dockerfileから見た相対パスで書く。 パッチファイルを取り込みたいときに便利。

ADD ./my-awesome.patch /home/docker
ADD ./my-awesome.patch $PATCH_FILE_DIR

面倒でなければENVで設定した環境変数を使うようにしてください

ENV

docker buildで有効な環境変数を設定するコマンド。$HOMEを変更するときはWORKDIRを使わないとだめ。 以下例。

ENV PATCH_FILE_DIR /home/docker/projects/qemu/patches

WORKDIR

カレントディレクトリを変更するコマンド。 以下例。

WORKDIR /home/docker/projects

これをするとその後のRUNから/home/docker/projectsがカレントディレクトリになる。

USER

コマンドの実行主を変更するコマンド。このときユーザーが自動的に作成されるかは知りません。

USER docker

CMD, ENTRYPOINT

両方は使えなかったはず。複数回もできなかったはず。 コンテナが起動したときに自動実行するコマンドを指定できる。 どっちかが、コマンドラインで指定したコマンドに置き換えられるはず。

Dockerfileのトラブルシューティングのコツ

  • 前もって別の環境で実行して、このコマンドで上手くいくことを確認する
  • apt updateを冒頭で必ずする
  • ファイルがあることを確認するために RUN ls * する
  • buildメッセージに載っているキャッシュされたimageのIDを控える→ docker run --rm -it CACHE_IMAGE_ID してインタラクティブに確認【一番オススメ】
  • RUNの単位を細かくする。&&で頑張って繋げない
  • RUNで複数実行するときは ; でなく && でコマンドをつなげる

日頃気をつけること

  • システムに残したい変更をしたら、そのときに実行したコマンドをDockerfileに残すのを忘れないこと。

高度なdocker run

privillegedオプション

Dockerのコンテナは触れるシステム資源が制限されている。 USBはこれに該当する。USBを使えるようにする前提で説明する。

まず Dockerfile 後半に以下の行を追記する必要がある。

VOLUME /dev/bus/usb:/dev/bus/usb

これは、ホストとコンテナの間でUSBを共有する設定。

privilegedモードでの起動は

docker run --rm -it --privileged IMAGE_NAME[:tag] bash

特権が付いているかどうかは次のように確認できる。

コンテナの外から：

docker inspect --format='{{.HostConfig.Privileged}}' CONTAINER_ID

コンテナの中から:

ip link add dummy0 type dummy

デタッチしたコンテナを復活させる

--rmを付けずにdocker runした場合のみ。

docker run で起動したbashをexitしたとき、コンテナはdocker ps（※起動中のコンテナを確認するコマンド）には表示されなくなる。 次の手順でコンテナIDを取得し、re-attachすることができる。

### check container name or ID
docker ps -a
### wakeup contianer with its id or its name
docker start CONTAINER_ID/CONTAINER_NAME
### you can check your container restarted
docker ps
### now you can re-attach to it
docker attach CONTAINER_ID/CONTAINER_NAME
# hit ENTER

docker attachしたターミナルで、アタッチ後にEnterを押さないとプロンプトが返らないことがある。

ショート版の手順がこちら：

docker ps -a
docker attach `docker start CONTAINER_ID/CONTAINER_NAME`

tmux

シェルが1つしかないのは不便なので、tmuxのようなターミナルマルチプレクサを使うとシェルをいくつも開けて便利。

VirtualBoxみたいにファイル共有（フォルダ共有）したい

起動時に「-v マウント元（ホスト上のパス）：マウント先（コンテナ上のパス）」のオプションを与える。 -v A:B -v C:D の感じで複数並べることも可能

### read-write mode
docker -it -v VOLUME_NAME:/home/guest
docker -it -v `pwd`/HOST_DIR_NAME:/home/guest
### read-only mode
docker -it -v VOLUME_NAME:/home/guest:ro
docker -it -v `pwd`/HOST_DIR_NAME:/home/guest:ro

高度なdocker build

docker build を一々叩くのは面倒なので ./build.sh なり、ビルド用のシェルスクリプトを用意すると便利である。 docker buildに成功したらタグを付けるようにしたほうがいい。タグ名はちゃんと管理できる自信があるならバージョン番号でも良いし、 gitのコミットハッシュでもよい。後者を前提とした build.sh のテンプレートが以下：

count_x_files()
{
    COUNT=$(git status --porcelain | grep -v "/patch/" | grep $1 | wc -l)
    echo $COUNT # return $COUNT
}

IMAGE="my-ubuntu"

docker build -t $IMAGE . || (echo "[!] ERROR: docker build. exit" ; exit)
echo "[*] DONE: docker build"

if [ $(count_x_files "MM") -ne "0" ]; then
    echo "[!] There's not staged changes. git add it now"; exit
fi
if [ $(count_x_files "??") -ne "0" ]; then
    echo "[!] There's untracked patch files. git add it now"; exit
fi
docker tag $IMAGE $IMAGE:$(git rev-parse --short HEAD)
echo "[*] DONE: docker tag"

このテンプレはgit add -u && git commit のし忘れを指摘してくれる。

Dockerあるあると小ネタ

コンテナーのIDを知りたい

docker ps

（docker buildで作成された）特定のコンテナのログを見たい

docker log CONTAINER_ID

ID は docker build のログ Running in dc043f01ca19 から dc043f01ca19 を拾ってくる

imageの一覧を見たい

docker images

イメージを消したい

### remove specific image
docker rmi IMAGE_NAME [IMAGE_NAME ...]
### force remove 
docker rmi -f IMAGE_NAME [IMAGE_NAME ...]

イメージ名を改名したい

### copy
docker tag OLD_IMAGE_NAME OLD_IMAGE_NAME
### and remove
docker rmi OLD_IMAGE_NAME

停止したコンテナだけ一覧で出したい

docker ps --filter "status=exited"

使ってないコンテナ（exitしたコンテナ）を消したい

docker rm `docker ps --filter "status=exited" -q`
### or
docker rm $(docker ps -a -q)

タグがついてないimageを消したい (like <none>:<none>)

docker rmi $(docker images | egrep "^<none>" | awk '{print $3}')

Wi-Fiが突然死んだと思いきやwpa_supplicantのロードエラーが原因だった

Linux

当方の環境はArch Linuxです。カーネルバージョンはこちら：

K_atc% uname -a
Linux K_atc 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux

PCを起動したらWi-Fi（wlp3s0）がunavailableで死んでいました。

K_atc% nmcli d
デバイス         タイプ    状態      接続            
br-7dd2d35de895  bridge    接続済み  br-7dd2d35de895 
docker0          bridge    接続済み  docker0         
enp0s26u1u2      ethernet  接続済み  有線接続 1      
enp0s25          ethernet  利用不可  --              
wlp3s0           wifi      利用不可  --              
lo               loopback  管理無し  --

ググっても同じ現象の人は居ませんでした。一日悩んだら原因が分かりました。 journalctl -u NetworkManagerでNetworkManagerのログをよく見るとwpa_supplicantでエラーが出ていることが分かりました。

K_atc% journalctl -u NetworkManager | tail -20
Sep 03 19:55:53 K_atc NetworkManager[1920]: <info>  [1504436153.0566] manager: NetworkManager state is now CONNECTED_GLOBAL
Sep 03 19:56:16 K_atc NetworkManager[1920]: <warn>  [1504436176.2134] supplicant: failed to acquire wpa_supplicant proxy: Wi-Fi and 802.1x will not be available (fi.w1.wpa_supplicant1 を StartServiceByName で呼び出そうとしてエラー: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'fi.w1.wpa_supplicant1': timed out)
... snipped ...
Sep 03 20:27:38 K_atc NetworkManager[1920]: <info>  [1504438058.5537] manager: rfkill: WiFi now disabled by radio killswitch
Sep 03 20:27:39 K_atc NetworkManager[1920]: <info>  [1504438059.5157] manager: rfkill: WiFi now enabled by radio killswitch

上と同様にwpa_supplicantのログを確認しました。libssl.so.1.0.0が見つからなかったために静かに死んでしまったようです。

K_atc% systemctl status wpa_supplicant
● wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled; vendor 
   Active: failed (Result: exit-code) since Sun 2017-09-03 19:55:51 JST; 42min ago
  Process: 1927 ExecStart=/usr/bin/wpa_supplicant -u (code=exited, status=127)
 Main PID: 1927 (code=exited, status=127)
      CPU: 961us

Sep 03 19:55:51 K_atc systemd[1]: Starting WPA supplicant...
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Main process exited, code=
Sep 03 19:55:51 K_atc wpa_supplicant[1927]: /usr/bin/wpa_supplicant: error while loa
Sep 03 19:55:51 K_atc systemd[1]: Failed to start WPA supplicant.
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Unit entered failed state.
Sep 03 19:55:51 K_atc systemd[1]: wpa_supplicant.service: Failed with result 'exit-c

openssl-1.0パッケージを入れてあげれば解決します。以下手順：

K_atc% sudo pacman -S openssl-1.0
K_atc% ls /usr/lib/libssl*
/usr/lib/libssl.so        /usr/lib/libssl.so.1.1
/usr/lib/libssl.so.1.0.0  /usr/lib/libssl3.so
K_atc% sudo systemctl start wpa_supplicant  
[sudo] katc のパスワード:
K_atc% sudo systemctl restart NetworkManager
K_atc% nmcli d
デバイス         タイプ    状態              接続            
br-7dd2d35de895  bridge    接続済み          br-7dd2d35de895 
docker0          bridge    接続済み          docker0         
enp0s26u1u2      ethernet  接続済み          有線接続 1      
wlp3s0           wifi      接続中（設定中）  Buffalo-G-****
enp0s25          ethernet  利用不可          --              
lo               loopback  管理無し          --

はい勝ち〜

3000～5000円台の最近のイヤホンでオススメなやつ

オーディオ

タイトルの「最近の」は発売日が「最近」ではなく、「最近」の売り場で置かれているを意味します。

僕は高いイヤホンを大学で無くした経験があるので、普段は安いイヤホンを持ち歩いています。 先週耳に入れる部分の蓋が取れるといういつもの壊れ方をしたので、新しいものを探しにビックカメラへ行きました。 （ポイントで払おうと思いきや、カードを持ってくるのを忘れたので買わずに帰って来ました。e-イヤホン行けばよかったですかね…）

3000～5000円台のイヤホンはこのような特徴があります：

  • 大体のイヤホンは高音が刺さる
  • 大体のイヤホンは音がザラザラしている（僕はこれを「イヤホン（デジタル）な鳴り方」と評したい。これの逆は「スピーカー的（アナログ）な鳴り方」）
  • 音場（音の広がり）は左右の耳へ直線的でつながる感じで、広がりはあまりない。音場が広いものはあるっちゃある
  • 低音が高音より鳴る。中音域の再生能力が弱い
  • 高音が歪んでいるか攻撃的（具体的に言うと、例えばシンバルの音がぶっ壊れてる）

そんな中で6000円～9000円クラスの鳴り方をするイヤホンがあって面白い価格帯であります。

リファレンス音源は、

  • 高音テスト用：Hesitation Snow
  • 低音・高音同時テスト用：ユーロビートから適当にチョイス
  • 低音テスト用：Forever Young
  • 全体のバランス確認用：Won(3)Chu KissMe!, ワガママMIRROR HEART

です。EurobeatとJ-EURO系が中心なので、人によってはこれがおすすめ？と感じる可能性があります。 プレイヤー（DAP）はCOWONのPlenue Dです。BEE+ありです。

個人的には、この価格帯で選ぶなら、解像度は重視せずに、高音が刺さらない、スピーカー的な鳴り方をするイヤホンを選ぶのがおすすめです。

final audio / E3000（5000円；おすすめ度★★★★）

final E3000 FI-E3DSS

final E3000 FI-E3DSS

ステンレス筐体。クラシック系・ストリングス系の楽曲がおすすめとポップが出ていたが、Adagio IIの再生能力を包含しているため、ユーロビート・アニソンの再生をそつなくこなしてくれる。 全音域のバランスが良く、音はスピーカー的ないしは金属的な鳴り方。高音の刺さりはなく、聞き心地良い高音を楽しむことができる。 Y23とどっちがいいのかで好みが別れると思います。

同系統の音で、2年以上前の同価格帯のイヤホンにSonyの MDR-EX650があります。それよりは心地よい鳴り方をします。音質はどっこいどっこいですかね。

final audio / Adagio II（4000円；おすすめ度★★★）

final audio design Adagio II ダイナミック型イヤホン(クリーム) FI-AD2DCR

final audio design Adagio II ダイナミック型イヤホン(クリーム) FI-AD2DCR

アルミニウム筐体。J-POP・クラブの楽曲と相性がよいというポップが出ていた。 高音の主張が弱く、どこかイヤホンな鳴り方をしてしまう面があり、もうひと頑張りを期待したくなる。 予算を4000円にするなら購入に踏み切るライン。 ＋1000円でE3000のレベルになるなのでそこは慎重になってもいいかも。

AKG / Y23（4000円；おすすめ度★★★）

AKG Y23BLK（ブラック）【ウルトラスモール・カナルイヤホン】 | イヤホン・ヘッドホン専門店e☆イヤホン

Y20と同傾向。こっちの方が音がよくて、艶があると感じた。

AKG / Y20（3000円；おすすめ度★★）

AKG Y23 イヤホン カナル型 ブラック Y23BLK 【国内正規品】

AKG Y23 イヤホン カナル型 ブラック Y23BLK 【国内正規品】

解像度は高め。少しAKGらしい開放的な音。少し聞き疲れする。Adagio IIの方が開放的でオススメ。

Pioneer / SE-CH5T（4000円；おすすめ度：★★★）

パイオニア SE-CH5T イヤホン カナル型/ハイレゾ対応 レッド SE-CH5T-R 【国内正規品】

パイオニア SE-CH5T イヤホン カナル型/ハイレゾ対応 レッド SE-CH5T-R 【国内正規品】

ねっとりした低音。音場広め。価格帯に見合った解像度。音場広め。マイルドな音。

Philips / SHE9730（4000円；おすすめ度：★）

PHILIPS SHE9730 イヤホン カナル型 ハイレゾ対応 ブラック SHE9730BK 【国内正規品】

PHILIPS SHE9730 イヤホン カナル型 ハイレゾ対応 ブラック SHE9730BK 【国内正規品】

イヤホンな鳴り方。解像度は高い。音場広め。聞き疲れする。高音が刺さり気味。

後日談【2017/9/3追記】

final audioのE3000をビックカメラで買いました。在庫切れだったのでお取り寄せでの対応となりました。それでも2営業日で届くレベルです。5000円台とは思えない音質で最高です〜

後日談【2017/9/9追記】

E3000万歳って感じになってしまっているので欠点を書いていきます。

  • 鼓膜に近い位置で鳴っているためか、音量を上げると耳が痛くなりやすい（PLENUE Dだと45/100ぐらいが限界）
  • 音場が同価格帯のイヤホンに比べて狭い
  • セミオープンなので後方の開口部から音漏れする

Trend Micro CTF 2017 Qual - rev100, osint100, misc100 の Writeup

CTF

日本時間で2017/6/24 13:00 - 6/25 13:00に開催されたTrend Micro CTF（TMCTF）にPing-Micで参加しました。時間は24時間です。 ぼっちだったので時間が全然足りんかったです。

以下の3問のWriteupを書きます。18時間かけて成果がこれですよ、はい。

  • Reversing 100
  • OSINT 100
  • misc 100

結果はチームとして300点（内300点submit）のTODO位です。

Reversing 100

初見でやるだけの自明な問題と分かるタイプの問題でした。バイナリ解析とx64dbgのリハビリとして解きました。良いリハビリになりました。

手順：

  1. fileコマンドでファイル形式を確認して展開→PEと暗号化済みzipが出てきた
  2. 32ビットのPEバイナリは動的解析をうまくしながら静的解析（※後述）
  3. 1つ目のパスワードmacaronがでてきるので暗号化済みのzipを復号
  4. 最終ステージに突入。画像ファイルの末尾にPKの文字があり、後ろにzipがあることが自明。1つ目のキーワードcreamという文字が書かれたtxtファイルが出て来た（※後述）
  5. 2つ目の32ビットPEバイナリを動的解析して2つ目のキーワードchouxを得た（※後述）
  6. biscuit4というファイルにはフラグ生成の指示が書かれている。それをもとにありえるflagを全通り試す（※後述）

1つ目のPEバイナリ（biscuit1）の解析

32ビットときたら久々のIDA Freeの出番です！x64dbgでstackを観察する限り、main関数相当の関数でargv, envを読み取ってから何か情報を得ている様子がないのと、プログラムからcost char[]ではない文字列の出力がないので内部でsecretを生成するタイプのバイナリと判断しました。

f:id:katc:20170625183627p:plain

IDAによる静的解析でスタックに文字列を積んでその後のループでこねくり回しているいかにもな箇所を発見しました。あとはx64dbgでステップ実行しながらスタックを人力で監視してmから始まるスイーツの名前が出て来るのを待ちます。

f:id:katc:20170625183646p:plain

よく見るとmarcaronという文字列が生成されたのがおわかりいただけると思います。

画像ファイル（biscuit3）の解析

最終ステージで出てきた怪しげな画像ファイル。そこに何もflagのヒントがないということは少ないので010 Editorにぶち込みます。 画像ファイルの終わりに怪しげなPKの文字。zipファイルを付加されているのが自明です。

f:id:katc:20170625184108p:plain

2つ目のPEバイナリ（biscuit5）の解析

先と同じノリで静的解析してsecretを生成しているルーチンを探します。5文字という決め打ちの値でループを回しているところが怪しいです。

f:id:katc:20170625184721p:plain

x64dbgでは0401656にソフトウェアブレークポイントを張って、Runさせながらメモリがどう書き換わるのかを観察しました。元々"biscuit"だった5文字が何に変わるのでしょうか。

f:id:katc:20170625184802p:plain “choux"が出てきましたね。

flag生成

biscuit4にはこう書かれていました。

Please create flag.

hint:

Flag = TMCTF{biscuit3_ biscuit5}

この場合、biscuit5でのトラップを考えると、flagは次の10+5通りがありえます。

  • TMCTF{cream_ choux}
  • TMCTF{cream choux}
  • TMCTF{cream_choux}
  • TMCTF{CreamChoux}
  • TMCTF{Cream Choux}
  • TMCTF{Choux Cream}
  • TMCTF{ChouxCream}
  • TMCTF{choux cream}
  • TMCTF{choux_ cream}
  • TMCTF{choux_cream}
  • TMCTF{cream_ biscuit}
  • TMCTF{cream_biscuit}
  • TMCTF{cream biscuit}
  • TMCTF{Cream Biscuit}
  • TMCTF{CreamBiscuit}

あとは片っ端から試して、この問題のフラグはTMCTF{choux_cream}。

OSINT 100

問題文：

Category: Iot/osint/scada
Points: 100

Today you received an email that seemed to be from an online shopping site that you use - but when you followed the link something definitely did not seem right. It appears that the world's worst phisher must have set up the page - and has targeted you with a phishing attack!

The email text said you needed to visit a link to update the security of your acccount. However the link actually lead to the site ctf.superpopularonlineshop.com.definitelynotaphishingsite.com

For this challenge you must find the "Real Person" who is behind this attack - leveraging your Open Source Intelligence (OSINT) skills.

The Flag will be found on one of their social profile pages


NOTE: Pen Testing the site will not help - in fact all you need to start the trail is in this email already

要するに、

  • ctf.superpopularonlineshop.com.definitelynotaphishingsite.com というFQDNをヒントに当事者の実名を見つけてくれ。
  • サーバーを調べても何も出てこないよ

ということです。

手順：

  1. whois情報を見る
  2. OSINTツールでひたすら辿る

うまくいく辿り方

  1. http://domainbigdata.com/definitelynotaphishingsite.tk
  2. Other TLDsで出てくるドメインをクリック
  3. http://domainbigdata.com/definitelynotaphishingsite.com
  4. RegistantのOsint Isfunをクリック
  5. http://domainbigdata.com/nj/0yFrGiv7y4k017TTe3o6UQ
  6. 個人所有っぽい t3m4.com にアクセス
  7. ホームページのタイトルがPersonal Home Page for T3-M4Haxor
  8. T3-M4Haxorでググる
  9. 実名っぽい（でもこれはコンテスト用のfake情報で、仮称もあり得る←実際どうなん？）LinkedInがヒットする→開く
  10. (*)が載っている。
  11. 13という文字からしてROT暗号。文字列を回してフラグ TMCTF{FTR0SINT101} を得た

(*)

プロジェクト
Trend Micro CTF 2017
Proud to have helped with the Trend Micro CTF 2017 - especially Secret Challenge “13” -> GZPGS{SGE0FVAG101}
チームメンバー:
Davik Surik

役に立たない情報／ひっかけ情報

  1. 電話番号でググる → http://www.25cycle.com/ にたどり着く → whois で Abel Network という会社が出てくる → この会社のFacebookを見る限りCTFに関係なさそうな人物

misc 100

Wiresharkで見る前に、stringsで疑似Follow TCP Streamします。FTPでkeylog.txtファイルを送ったのが分かりました。中身がこちら：

CLIENT_RANDOM 9563c57725522ab0cebb420f2ff549cdcc214d05a2b7aa5601f1935bcd1ac7c3 c5e10df5dbd09bd97b5ea6f1b291d8cac7066178d6805cf371e12ea1095131d1e6096132d7d0e072c78005f6d1b7fe5b
CLIENT_RANDOM f51ac603ddd9c6d8146cd03028f129365e32a928a08629892be4c26a454634bb 0a9dea018920113ec333446e1a185fd072444a1db9d7a8a9b9b21f2472f39db3f92929a25e3d634d58259537a3b47d60
CLIENT_RANDOM 3e401f34cc591c8a35aeedaddf181f7c458a84e058392735d74679eb0393431a 89d66ea9f10d711b6ff8c54c86474096252b8e8173aa271d8441b38c720d9d4a5b569b14cb1d898df16473ebfa23a1d2
CLIENT_RANDOM 0e2d5ecede1cf0f7d1d75329e3e386e160d99ac89e0ec09187651096d79ba35a afe74535c230c9d7e5f08ace8ce02d8200b8078854e41c30703f7da4ab7bd405788956805e9403996aa9412e2a26d545
CLIENT_RANDOM 89e8225f13ed1b39406f25c3f634f0ec91da0be693b7dcb9044efbbf2fe9363e 60b8b92fd58faabbfe00bec7fbf1c39db21030ff3c215c079176be6bcfe167df4114f1950790aaf432312a1397be2cb6
CLIENT_RANDOM 55d1989b2b9005b72599552ff352c4eef03bdb7153aaddd9942d69a19441fdaf 07cc14d902872bbdbdf5d05463a918c585604d373d7524ff405c396a2d4adafffd82b6136de4b7204d33fd9f2ff8f113
CLIENT_RANDOM 3cd78f4befe06bdb4c5559930817c8056aa14fe0c6a67d806ea0cc34c317fa51 ac7be48df12853bae2896042829a2011225e56ccdb63a05520b574b6d9f4aedd3f6c8377d47130e995f16a588dad5858
CLIENT_RANDOM cfaf0c18297c00ba7541ae55012df1fe825727a32ab94e38e1aeb985f9cf3ce5 3f81b68f0b9df5b719a54bb364505cb29209ae7a30d0525bb5a873e375bdbc9ac77ff24aa21def886d61f7cdcc0b06d5
CLIENT_RANDOM a77cdcf8084d073ec7059933e454408e25c6a01c8dbb888e9a3a862b609d8503 b5e7230fc735a87666fd2aee430917fd97bcf5f961b4099b979453b51176c0496629fe5af17da7f52204953782c90fdb
CLIENT_RANDOM d2d06ea94000a9204ea9e2d8272e77e4758958caaff0e9b4bfa7dbe4228d9251 bb716b4ff6de9730d0cd85446f3b5682b9055a54ac071279326ad2739083f54f0d13e689b47fcbb88a0dddb9ddd44175
CLIENT_RANDOM 4955c52a45946483854a4f333493870baa838a5c54c7112252a2828931393cd3 45aef6edb24a058b613559847db56db375b2f4286f9633f26735799ac2e8b0679853e72c1ec4188908bfa9b021c829cd
CLIENT_RANDOM 2acd97c21e8d33bb349d9612cb5b6220f10e5e4106d9449bf7dc5c933292f59e f70dc2ce8a96da62b9c6c5e2dea8aa776a666908c46a34d71dd297a002ba9e6a55b39e1cc8e845a7e058c779b400f82f

Wiresharkでの初見の印象はSSL＋FTPだったので、頭の中の過去問データベースから推論して、既知のpre master secret keyからのSSL通信の復号がメインテーマっぽいと考えました。 確か特殊な環境変数の元でブラウザを起動すると指定した場所にpre master secret keyを保存してくれましたよね。Slideshareとかでサーバーの秘密鍵がなくても通信の中身が見れるよーっていうスライドを以前に見たことがあります。 ファイルに特徴的なCLIENT_RANDOMでぐぐっても同じ結論に至ると思います。

keylog.txtをWiresharkに食わせてSSL暗号化を解除しました。HTTP2が見えるようになりました。 SECCON 2016 QualsのときはHTTP2のヘッダを解析してくれなかったんですが今は対応してますね。

f:id:katc:20170625194403p:plain

見つけたHTTP GET Requestは次の通りです：

  • index.html
  • main.css
  • 404.html
  • 画像2枚

あとは、それぞれのペイロードをCopy > Bytes > Offset Hex（Cypy > … as Hex Dump）でコピーしてテキストエディタでいらないところを置換で消去してから保存。 次に、xxd -r -p FILE.hex > FILE.bin。 HTTP Response Headerからhtmlとcssはgzip圧縮がかかっていることが分かるので、画像以外は gzip -d FILE.bin.gz > FILE.binも必要。 main.cssはあとでブラウザで読み込むのでファイル名をちゃんと合わせておきます。

index.htmlをブラウザで確認すると、Lorem ipsumのような文字列と画像が2枚、モザイク状の画像が2つあるのがわかります。 画像はビールとブルーベリーで元ネタはフリー素材です。ブルーベリーだけお尻が切れた（SOSからEOIが未完結な）jpeg画像でした。 モザイク状の画像はCSSのbackgroud-image: url()で与えられたものです。2枚表示されますがどちらも同じです。サイズは8の倍数で01の2値情報を含んでいるかと思って復号してみましたが乱雑なデータしか出てこないのでノーチャンです。

f:id:katc:20170625194541p:plain

もう一度htmlのコードをよく見ると64行目に、

    <samp>HINT: visual cryptgraphy</samp>

と書いてあるのを見つけました。Visual CryptographyでググるとWikipediaのページが出てきました。

Visual cryptography - Wikipedia

f:id:katc:20170625193838g:plain

これ、ほぼ答えですねー。Photoshopでモザイク状の画像のレイヤーを2つ用意して一方を上下方向に1ピクセルずつずらしてフラグゲットしました。

f:id:katc:20170625194142p:plain

fllag: TMCTF{CanYouSeeThis?}

＠運営：
当初から掲げていた、サイバー犯罪・サイバーセキュリティの最前線の追体験を重視したCTFが体現されてましたし、今までよりもずっと洗練されてきています。 今の路線で続けてほしいと思っています。 あと知的興味を刺激されたいいCTFでした。

問題を解くのに変に時間をかかってしまう病がまた発病してますね。これじゃCTFを始めた頃と同じですわ。 負け惜しみみたいな文面になりますが、他のWriteupを見る限りForensic 100とAnalysis-Defensive 200はやるだけの簡単な問題でしたね。ノーチェックでした＞＜ 過去に類似の問題が出ているので、この問題のflagをsubmitしてないのはguiltyなレベルですわ。 今回は普段CTFで出題されないような問題（特にOSINT）を解くことを重視したので、自分の中でその問題をノーチェックだったのはまあ仕方ないといということにしておきます。

チームに2人以上いれば、誰でも解ける段階まで解けたら他の人に投げて別の問題を解くということもできるんですが、最近の有名どこのCTFは皆が忙しいときに開催されるので人数が揃わないんですよね。 CTFが超好きで、予定を調整して参加するほどの人ってなかなか居ないのが最近の悩みです。

解きたかった問題：