人気の Android アプリでコードの難読化はどの程度一般的ですか?

知的財産の窃取、機密性の高いユーザー情報へのアクセス、あるいはバックエンドサーバー上のあらゆる情報へのアクセスなど、標的型攻撃の多くは、クライアント側アプリケーションの一部をリバースエンジニアリングすることから始まります。これにより、アプリケーションの構造を理解し、弱点を特定します。最終的な攻撃がバックエンドで発生した場合でも、クライアント側を分析することで、APIや認証メカニズムに関する重要な情報が明らかになることがよくあります。

このため、コードの強化は 独自のアルゴリズムを使用するアプリや機密データを扱うアプリでは交渉不可.

2023年にOWASPは第2版を定義しました。 モバイル Application Security 検証標準（MASVS）これは、モバイルアプリのセキュリティ確保を目指すアプリ開発者や、脆弱性の発見を目指すセキュリティテスターのためのガイドラインとして役立ちます。また、 Application Security 製品ベンダーは Digital.ai 今日のアプリセキュリティの現状について考えるためのフレームワーク。OWASPの MASVS-レジリエンス コントロールは、 Digital.ai (そしてその前の Arxan) は、コードの強化と改ざん防止について次のように考えています。

• MASVS-レジリエンス-1: アプリはプラットフォームの整合性を検証します。
• MASVS-レジリエンス-2: アプリは改ざん防止メカニズムを実装しています。
• MASVS-レジリエンス-3: アプリは静電気防止分析メカニズムを実装しています。
• MASVS-レジリエンス-4: アプリは反動的解析技術を実装しています。

プラットフォームの整合性を確保するには、改ざん防止と動的分析がより効果的であることが多いですが、静的分析なしで実装すると、高度な攻撃者によって簡単に発見され、無効化されてしまう可能性があります。

これを念頭に置いて、まずは今日のアプリが実装するのがどれほど一般的であるかを評価することから始めましょう。 MASVS-レジリエンス-3 制御。このために、Google Play の無料アプリ上位 40 件をレビューし、コードの難読化の明らかな兆候を探しました。

私たちが見つけたもの

調査結果を完全に理解するために、まず私たちの手法について説明する必要があります。JavaやKotlinのようなバイトコードベースの言語では、クラス名やメソッド名がそのまま残ることがよくあります。コードが難読化されている場合でも、これらの識別子はリバースエンジニアにアプリのアーキテクチャを理解し、攻撃を仕掛けるのに十分な手がかりを与える可能性があります。名前の変更、つまり名前の難読化は、コードからこうした識別情報を削除します。名前の変更（つまり、判読可能な識別子の欠如）は視覚的に非常に分かりやすく、容易に発見できるため、この分析の基準として使用しました。

対象アプリを逆コンパイルした後、名前変更の範囲に基づいて 3 つのカテゴリに分類しました。

• 名前の変更はできません: アプリ内の何も名前が変更されていないため、セキュリティが存在しないか、セキュリティが弱いことを示します。
• ローカル名の変更: アプリの特定の部分のみの名前が変更されます。これは、セキュリティのためにランタイム アプリケーション自己保護 (RASP) ライブラリが使用されているか、または労力の少ない構成になっていることを示している可能性があります。
• 世界的な改名: コードの大部分の名前が変更され、包括的なセキュリティ ソリューションと慎重な構成が使用されていることを示しています。

選択されたアプリのうち、37% は完全に保護されておらず、28% では少数のクラスの名前のみが変更され、残りの 35% ではほとんどのクラスに名前の変更が適用されていました。

ここで注目すべきは、特定のコンポーネントのみの名前変更（分析対象アプリの28%）は、実際にはそれらの部分を目立たせてしまう可能性があることです。これは、攻撃者が注目して削除しやすい、最も機密性の高いロジックやセキュリティ制御を浮き彫りにするためです。一方、コードベース全体（分析対象アプリの35%）に均一に名前変更を適用すると、これらのシグナルが隠蔽され、重要なターゲットを見分けることがはるかに困難になります。これにより、保護されたコードの解読がはるかに困難になり、アプリ（攻撃者にとって最も重要かつ限られたリソース）のリバースエンジニアリングにかかる​​時間が大幅に増加します。多くの場合、この複雑さの増加だけで、さらなる攻撃を阻止するのに十分です。

これらの結果は、アプリ開発者のかなりの部分がアプリのセキュリティ保護について少なくともある程度考慮しているものの、注目されているアプリの少なくとも 3 分の 1 は依然として簡単に検査、変更、再パッケージ化できるコードで市場に投入されていることを示しています。

これは何を意味するのでしょうか？

これは重要な問題です。なぜなら、保護されていない、あるいは保護が緩いアプリは、リバースエンジニアリングや改ざんの標的になりやすいからです。ほとんどのアプリにとって、これは知的財産の漏洩、APIキーの露出、あるいは攻撃者が悪用可能なビジネスロジックの漏洩につながる可能性があります。ゲームの場合、不正行為、改造、あるいはクローンリリースへの道を開き、収益とブランドの信頼性に直接的な影響を与えます。現在の分布を見ると、セキュリティを真剣に考えているチームもある一方で、多くのチームが依然としてコードベースの大部分を無防備な状態に放置していることがわかります。

明らかなのは、基本的なクライアント側保護は、注目度の高いアプリであっても、依然として普遍的な標準とはなっていないということです。より一貫性と意識向上が切実に求められています。このシリーズの次の投稿では、保護が全く施されていないアプリや、手間をかけずに実装されたアプリと比べて、十分に保護されたアプリの分析がどれほど困難になるかを詳しく見ていきます。