12

現在のAndroid Permission System では、次の問題が発生します。

アプリ A は、次のカスタム アクセス許可を定義します。

com.package.permission.READ_APP_DATA

アプリ B がカスタム アクセス許可を宣言してインストールされると、それが付与されます。

ただし、アプリ B の後にアプリ A がインストールされた場合、アプリ B には権限が付与されません。

これはよくあることではないかもしれませんが、アプリ B はアプリ A のプラグインであることが多いため、もちろん発生する可能性があり、私のアプリケーションでは発生します。

SuperUser アプリケーションがこれのグローバル カスタム許可を導入することに同意するとandroid.permission.ACCESS_SUPERUSER、ユーザーが SuperUser アプリを切り替えることを決定した場合、大きな問題になる可能性があります。

この問題を処理するために、宣言を開始しようとしているカスタム アクセス許可に対して、アプリケーションで次のコードを使用する予定です。

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;

この質問のタイトルによると、この方法は「安全」ですか? または、アプリケーションのマニフェストがインストールされ、プログラムでアプリ B に「追加」された後にアプリケーションのマニフェストを変更できる方法/ルートハックはありますか?

4

2 に答える 2

10

インストール後にマニフェストへのアクセス許可をハッキングすると、上記で投稿したコードに接続する方法がわからないため、質問が正しいかどうかはわかりません。しかし、最後の段落に答えるには：

簡単な方法ではありません。ユーザーは自分のデバイスに mod をインストールする必要があります。これにより、アプリが要求している間にその場で任意の権限を付与できます。IIRC マニフェスト ファイル自体は、インストール時に解析されます。

mod で使用したのはgrantPermissionsLPw、 class のメソッドを変更することcom.android.server.pm.PackageManagerServiceです。

android.permission.EXPAND_STATUS_BARマニフェストで宣言していないパーミッションをランチャーに付与するために使用されます。

ただし、これがアプリに使用されるかどうかはわかりません。要約すると、ユーザーがアプリに任意の権限を付与したい場合、カスタム許可: はい、可能です。

アップデート

もちろん、もう少し詳しく説明できます。2 つのシナリオが発生していることがわかります

1.静的モッド

上記のクラスは にありservices.jarます。ご存じのとおり、このようなファイルは逆コンパイル、変更、および再コンパイルできます。実際、このファイルの編集はかなり簡単です。電話でこれを直接行う方法はわかりませんが、可能だと思います。かなりの処理能力が必要なため、広範なソリューションが利用可能であることは、それほど実現可能ではありません。攻撃者は、ユニバーサル ファイルを提供することはできません。これらのファイルは、デバイスごとに変更され、ファームウェア バージョン間でも変更されます。攻撃者は、膨大な量のパッチを適用したファイルを提供するか、サーバーにアップロードしてパッチを適用し、再ダウンロードしてインストールすることにより、パッチをライブで実行する必要があります。あなたが私に尋ねると、このシナリオはあまりありそうにありません。

2.ダイナミックモッド

使用可能なフレームワークは複数あり、動作中にプロセスを変更できます。それらの中で最も人気があるのはXposed Frameworkです。基本的に、これは実行中のプロセスを変更するためapp_processに活用する、パッチが適用された対応する API です。Reflection攻撃者は、このフレームワークを使用してアプリを出荷し、root アクセス権を持ってサイレント インストールできます。root アクセスがあれば、通常はユーザーの操作が必要なモジュールを自分で有効にすることもできます。そのようなモジュールが有効になると、攻撃者は上記のメソッドにフックして、要求された権限を変更できます。彼は、要求されたアクセス許可を保持するオブジェクト フィールドを取得し、必要なものを追加してから、元のメソッドを実行して、最初に定義されたアクセス許可を追加することでこれを行います。

どちらのシナリオでも、ユーザーが悪意のあるアプリを自分でインストールする必要があることに注意してください。アプリの目的について言及していないので、リスクの評価に関してこれ以上お手伝いすることはできません. 私が言えることは、攻撃者はそのようなことを行うことができるということだけです。

于 2013-10-23T13:22:57.617 に答える
0

アプリ A がアプリ B の前にインストールされていて、<permission>要素がアプリ A で宣言されていない場合、ユーザーにアクセス許可要求が表示されないという問題があります。<permission>ただし、アプリ A で要素を使用する必要がある場合は、同様のアプローチを使用して、ユーザーに表示されるラベルと説明が正確であることを確認できます。

于 2014-02-10T04:46:30.047 に答える