はじめに

最近Daily AlpacaHackが始まりましたね。CTFって結構がっつり時間を持っていかれてしまうのが嫌だな〜と思っていたんですが、Daily AlpacaHackは1日1問解くだけなのでモチベを保ちやすくて嬉しいです。普段解かない分野の問題に触れる機会にもなるということで、僕は今までWeb専門でしたが他にも色々手を出してみています。楽しい。

ただ、僕はMacを使っているのですが、Pwnなど分野によってはMacで解きづらいものもあります。本気でCTFをやるならx86_64のWindowsぐらい持っておけという話ではあるんですが、「Macしか持っていないからPwnは全くできない」というのはもったいないですよね。そこで、この記事ではAppleシリコンのMac上でDockerとGDBを使ってx86_64のLinux向けバイナリを解析するための環境を構築します。

Macの何がいけないのか

CPUにはいくつか種類があり、Windowsではx86_64が主流だが近年のMacではArmアーキテクチャが使われている、ということはご存知だと仮定して話を進めます。←この文がオフチョベットな人は身の回りのパソコン詳しそうな人に聞いてみましょう。なお、以下単にMacと書いた場合にはAppleシリコンのMacを指すものとします。

さて、Macで普通にアプリケーションを使う上でアーキテクチャの違いが問題になることはほとんどありません。例えば、Google日本語入力のArm版はいまだにリリースされていませんが、Intel版が普通に動きます。これはバイナリがRosetta 2によってArm向けに変換されるためです。性能面でもネイティブと大差ありません。Dockerにおいても、Rosetta for Linuxによりx86_64のLinuxコンテナをArmネイティブとほぼ同等のパフォーマンスで実行することができます。

しかし、x86_64のDockerコンテナ上でGDBを実行しようとするとうまくいきません^[1]。この辺はよく理解していませんが、多分デバッグのような実行中のバイナリに対する操作にRosettaが絡むと上手くいかないのだと思います。

QEMUでええやん

Rosettaが使えなければQEMUを使えばいいじゃない

とマリー・アントワネットも言っています。Rosettaと比べて低速ではありますが、バイナリの変換のような複雑なことはせずCPUをエミュレートするものなので互換性はこちらの方が上でしょう。GDBもちゃんと動くらしい^[2]ので変なこだわりがなければこちらの方が良いと思います。

しかし、困ったことに僕は変なこだわりがあるのでQEMUが使えません。互換性の面ではQEMUの方が優れていそうですが、仮想マシンを立てるのはセットアップが面倒です。「あーCTFしたいなー」と思ったらすぐに立ち上げられる環境があると嬉しい。そこでDockerです。CTFでは（特にWebなどで）Dockerfileが配布されることがよくあるので、他の分野で親しみのあるツールを使えるというメリットもあります。

ROSETTA_DEBUGSERVER_PORTという環境変数

突然ですが、Rosettaでx86_64バイナリを実行するとき、ROSETTA_DEBUGSERVER_PORTという環境変数を設定すると指定されたポートでRosettaがデバッガーの接続を待機してくれるようになります。これにGDBから接続してやればデバッグできるようになります。やったー！

ただ毎回その環境変数をタイプしてリモートに接続して……という手順を踏むのは面倒なので、Docker for Macのissueコメントで良い感じのシェルスクリプトを公開してくれている人がいます。targetがremoteになる関係でrunの代わりにcontinueを使う必要があるなど多少の違いはありますが、十分使えるようになります。基本的にはこれで良いのですが、このコメントで紹介されているスクリプトでは標準入力を受け付けてくれず、CTFではちょっと困るので明示的に標準入力を渡すように修正しました。

#!/bin/bash
# https://github.com/docker/for-mac/issues/6921#issuecomment-2409324575

if [ "$#" != "1" ]; then
  echo "Usage: $0 <path/to/program to debug>" >&2
  exit 1
fi

prog=$1
ROSETTA_DEBUGSERVER_PORT=1234 $prog < /dev/tty &

gdb \
  -iex "file $prog" \
  -iex "target remote localhost:1234"

また、元のissueコメントではこれを/usr/local/bin/gdbに保存するとしていましたが、僕は

• Mac以外でも同じDockerfileを使えるようにしたい
• runとcontinueなど一部コマンドの違いがあるので、Rosettaを意識しながら使うようにしたい

という理由から/usr/local/bin/gdb-rosettaという名前にしています。まぁこれはお好みで。

その他、Rosetta関係なくDockerでptraceなどのシステムコールを使えるようにするためにはオプションが必要です。僕が使っているcompose.yamlを公開しているので良ければ見てください^[3]。

ちなみにこんな環境変数どこから見つけてくるんだという感じですが、rosettaコマンドのUsageに書かれているらしいです^[4]。一般人が直接叩くことを想定されたものではなく、叩くまでに何ステップか準備が必要で面倒なので僕は確認していませんが。

【悲報】Rosetta 2はサポートの縮小が決まっている

……はい。せっかくRosettaを使いながらデバッグできるようにしたのに残念ですが、Rosettaのフル機能が使えるのはmacOS 27（仮）までで、それ以降は古いゲームのサポートを目的とした一部の機能のみが提供されることになっています^[5]。これがどれくらい大きな変更になるのかは分かりませんが、Appleの出方次第でこの記事はなかったことになるかもしれません。

Rosetta 2という名前からも分かる通り過去にもMacのアーキテクチャ移行のためのRosetta 1が存在しており現在では提供が終了しているわけですが、当時とは事情が違ってx86_64は他のOSで広く使われているので他プラットフォームとの互換性のために残してくれても良いのに……と思います。Appleがそんなことしてくれるわけないか。

おわりに

僕はまだPwnやRevの問題を片手で数えられるくらいしか解いたことがないので分かりませんが、たぶん本記事のセットアップだけでは解けない問題はたくさんあるでしょう。実際、GDBはなんとか使えるようになりましたがltraceコマンドなどは使えません。それでも、「Macだから何もできない」という状態からは抜け出すことができました。この記事がCTFを始めたいMacユーザーの助けになったら嬉しいです。

明日の投稿者は@samidare、@issaimaruです。お楽しみに。

おまけ：Windows on Armは？

Arm版WindowsにもRosettaに似たPrismというエミュレータがあり、大抵のx86_64ソフトは動きます。UTM上の仮想環境で試した限りでは、Prism自体は結構実用的であるものの、エコシステムがついてこられていないという印象を受けました^[6]。本記事の執筆時点ではDockerにもPrismは統合されていないようです^[7]。QEMUが使われているので逆にMacのDockerより互換性高かったりするんでしょうか。

おまけのおまけ

この記事の内容は@zoi_dayoの記事と丸被りしています。1つのアドベントカレンダーでこのネタが被ることあるんだ……。