Android アプリで証明書のピン留めの採用が増えているのは素晴らしいことです。 リクエストをプロキシしようとしているときに接続エラーをスローするアプリに遭遇すると、より深く掘り下げたいと思う傾向があります。 最近 Subway アプリを使用したときもそうでした。 APK を元に戻すと、他の興味深い発見の中でも特に証明書の固定が明らかになりました。
リクエストのプロキシ中にアプリを起動すると、次のエラーが発生しました。
ピン留めはバイパスするのに十分簡単です。 まず、アプリを逆コンパイルし、キーワードを固定するためにソース コードを分析しました。 実際に、実装を実装した 2 つの別個のクラスでピン留め実装を見つけました。 X509トラストマネージャー. 固定を強制する方法の 1 つを次に示します。
// Code removed at request of Subway leadership
これをバイパスするには、smali コードに return ステートメントを追加して、上記のメソッドの固定コードをスキップするだけで済みます。 の追加に注意してください。 返品無効 以下の声明:
// Code removed at request of Subway leadership
アプリを再コンパイルしてインストールした後、次の新しいエラーが表示されて驚きました。
Subway は、APK の取り消しを防ぐためにカスタム アプリ署名検証プロセスを使用していました。 ソースを調べてこのプロセスについて言及したところ、次のメソッドにたどり着きました。
// Code removed at request of Subway leadership
これはリバース エンジニアリングを防ぐ興味深い試みでしたが、実際にはわずかな遅延が発生するだけでした。 このプロセスをバイパスするために、別の行を追加してメソッドの実行をスキップする行を追加しました。 返品無効 これは、上記のピン留めバイパス プロセスと同様です。
// Code removed at request of Subway leadership
アプリを再コンパイルしてインストールした後、リクエストを正常にプロキシできるようになりました。
研究中に私はつまずいた このレディットの投稿. どうやら、Subway はユーザーのデバイスが root 化されているかどうかも判断していたようです。 ソースを調べて、ルート検出方法についての言及を確認しました。
// Code removed at request of Subway leadership
これは、アプリがセキュリティを非常に重視していることを示す良い例ですが、ルート チェック プロセスの背後にある理由がよくわかりません。 証明書のピン留めと署名検証技術は一般に良いアイデアですが、リバース エンジニアリング プロセスをわずかに妨げるだけです。