web-dev-qa-db-ja.com

Androidリバースエンジニアリングに対する保護

私は特に、APKをリバースエンジニアリングや乱用から保護するための最も効果的な対策を見つけるよう努めてきました。調査を続けている間に、さまざまな最高評価のアプリに出くわしました。そして、私の注目のほとんど（おそらく他のものも）を獲得したのはSnapchatでした。

今、Snapchatは、2017年秋のリリースに続くアプリの乱用を防ぐために、セキュリティ対策を再構築し、結び目を強化しようとしました。簡単に言えば、Snapchatは、X-Snapchat-Client Auth Tokenと呼ばれる特別なヘッダーを使用して、アプリからのすべてのリクエストに署名し始めました。単純な逆コンパイルと再コンパイルであるという美しさは、アプリを役に立たないままにし、おそらくリクエストが不正であり、信頼できないソースから発信されたため娯楽ではないというSnapchatサーバーの検出に役立つ特別なヘッダーに要約されます。

この特別なヘッダーは、実際にはlibscplugin.soと呼ばれる特別なネイティブライブラリによって準備されます。これは、初回ログイン時にアプリによって呼び出され、ヘッダーの生成とリクエストへの署名に役立ちます。少し掘ってみると、このライブラリ（実際には共有オブジェクト（.so）であり、他の.dexファイルとは異なり簡単に逆コンパイルできない）が次のJavaメソッドの呼び出しです。

  • com.snapchat.Android.app.shared.crypto.DeviceTokenManager.getInstance
  • com.snapchat.Android.app.shared.crypto.DeviceTokenManager.getDeviceToken1

これは、Deviceトークンでいくつかのことをしている可能性があるため、理解されています。

また、次の呼び出しもあります。

  • Java.lang.ClassLoader.loadClass
  • dalvik.system.BaseDexClassLoader.findClass
  • dalvik.system.DexPathList $ Element.toString
  • 他の多くのDalvikおよびStringメソッド呼び出し

この特定の保護方法とは何か、Snapchatが不正なアプリを特定するのにどのように役立つかを理解したいと思います。上記のメソッド呼び出しは、メッセージを象徴または伝達するものは何ですか？ネイティブレイヤーからアプリの署名を取得しようとしているのですか、それともdexファイルなど、気づいていない、非常に興味深く役立つものの状態を計算しようとしているのですか、それをさらに使用して、証明トークンを生成していますか？

これらの呼び出しが何をするにせよ、それが非常に成功し、時の試練に耐えてきたことはかなり明白です。

それ以上の考えや洞察は大歓迎であり、高く評価されています。

androidreverse-engineering
7
Akash Gorai

したがって、.soバイナリをリバースエンジニアリングして、アルゴリズムの詳細を確認し、検証トークンを偽造できるかどうかを確認することができます。以下のソフトウェアを参照してください。

https://ghidra-sre.org

https://www.hex-rays.com/products/ida/

どちらも非常に強力な逆コンパイルソフトウェアであり、機械コード（ASM）を人間が読めるC++に変換してリバースエンジニアリングを行うことができます。それはREの難易度を増加させますが、それは不可能ではありません。

彼らはそれをどのようにしたのですか？コード署名を使用して、実行前にコードの整合性を検証できます。ただし、すべての.soは、C/C++コードからコンパイルされたLinux共有オブジェクトです。したがって、攻撃者がモデルについて詳しく知るのを困難にしたい場合は、必要に応じて、C++でアルゴリズムを記述し、それを共有オブジェクトとしてアプリにリンクして、その関数をアプリにインポート/使用できます。 Androidプロジェクト。これにより、アプリと検証アルゴリズムの間の抽象化レイヤーが提供されます。

1
leaustinwile