# ある開発者はいかにしてPureGymの入館証をApple Walletパスに変えたのか
リバースエンジニアリングに関する解説記事は、同ジムのQRコードによる入館手順が煩雑である一方、そのAPIとアクセスモデルは驚くほど容易に調査できると指摘している。
NeoTechNews編集部
PureGymの入館手順についての長い技術解説が、日常的なジム入館時のわずらわしさをソフトウェアの物語へと変えた。筆者は、実際に機能するApple Walletパスを作成するため同社のAPIをリバースエンジニアリングし、その後、PassKit、Vapor、mitmproxyを使った手順を文書化したという。動作が遅く使いにくいQRコードの手順への不満から始まる話は、人々がどれほどの不便に耐えた末に自作ツールを作り始めるのか、という教訓へと急速に展開する。
この記事冒頭の不満は、モバイルアプリを使って建物に入ろうとしたことのある人なら誰にとってもなじみ深い。筆者は、ジムのWi-Fiに接続し、アプリが読み込まれるのを待ち、関係のないキャンペーンや通知をかき分けて進み、その後、入館用QRコードが表示されるまで再び待つ過程を説明している。このQRコードは固定されたものでもない。記事によれば60秒ごとに更新されるため、スクリーンショットは役に立たない。それだけでも、この体験は不便であると同時に、妙に大げさな演出のように感じられる。
この解説で最も印象的なのは、セキュリティー面の対照だ。筆者によれば、PureGymの回転式ゲートでは8年間にわたって同じ8桁の暗証番号を使ってきた一方、デジタルのQRコードは絶えず更新されていた。筆者はこれを「セキュリティー劇場」と呼んでいる。アプリで最も目につくセキュリティー層が最も不便である一方、物理的なキーパッドは何年も変わらないままだから、この表現は当を得ている。記事はさらに、APIの認証エンドポイントから、必要最低限に見える構成が明らかになったと述べている。その中には、Base64でデコードすると、実質的なシークレットが付いていない「ro.client」が露出する認証情報も含まれていた。
そこから記事は、リバースエンジニアリングの具体的な仕組みへと移る。筆者は、プロキシーツールを使ってアプリの通信を傍受し、その後、APIがどのように応答するか、またいつ更新が必要になるかを確認したという。この部分が重要なのは、不満についての話を技術的な話へと変えているからだ。目的は単に文句を言うことではなく、別の形で再現できるほど十分にシステムを理解することだった。完成したパスは固定されたスクリーンショットに依存せず、動的に更新された。
Apple Walletという側面が、この物語のもう半分を占める。記事は、Walletパスは単なる固定されたカードではないと説明する。パスは自ら更新し、プッシュ通知を送信し、位置情報に反応できる。そのため、利用者が施設の近くにいるときに表示されるジム用パスを実現できる。筆者によれば、バックエンドをVaporで構築し、ユーザーが何もしなくてもQRコードを更新できるよう、サイレントプッシュ通知を利用したという。また、適切な場所の近くでパスを起動できるよう、英国各地のPureGymの座標もスクレイピングした。
こうした利便性と見せ場の組み合わせが、この解説が注目を集めた理由の一つだ。これは単なるリバースエンジニアリングの記事ではない。APIを調査し、プラットフォームの細部を一つずつ処理するだけの意欲があれば、日常的なサービスを作り直せることを実演したものだ。その結果、入館時の儀式は手首をスキャンするだけになったが、同時に、元のアプリの手順の裏側にどれほどの複雑さが隠れていたかも浮き彫りになった。
より広い意味で得られる教訓は、ジムへの入館というより製品設計に関するものだ。読み込み中を示す表示を避けるためだけに、利用者が技術的な大冒険を一通りやってのけようとするなら、それは通常、元のユーザー体験に問題がある兆候だ。この解説は、ある開発者が自分のためにその問題を解決する様子を示している。同時に、小規模な入館システムから、セキュリティーや利便性、そして物理的な門に取って代わるはずのデジタルゲートのほうが、なぜ使いにくく感じられることがあるのかという、より大きな問いが浮かび上がることも示している。



