最初は信じていませんでした。メールアカウントを無害に設定することで、メール管理者は個人のデバイスで非常に多くの特権を得ることができます。 SDカードとすべての内部メモリの完全なバックアップを作成した後、彼は実験を提案しました。 そして奇跡-プッシュ通知が来て、電話がハングアップし、しばらくしてから再起動し、工場設定のままにしました。 また、SDカードには生命の兆候はまったく見られませんでした。
興味を持って、私はこの問題を調査し、可能であれば、メールクライアントの悪意のある機能を無効にすることにしました。
最初のステップは、SDカードに何が起こったのかを確認することでした。 電話はそれが欠落していると思い、私はそれをカードリーダーに挿入しました。 HEXエディターで表示すると、パーティションテーブル（MBR）は上書きされていますが、パーティション自体（FAT32およびLinuxスワップ）は非常に正常でした。 すばらしいTestDiskユーティリティを使用して、クリーニングの前の状態にカードの内容を即座に復元しました（ここで完全ワイプがあります）
次に、Androidのソースを見て、ワイプ、クリア、工場出荷時設定のキーワードを検索しました。 自己破壊コードは/system/framework/services.jarモジュールにあり、データ破壊要求を待機している特定のBroadcastReceiver（ このクラスのソース ）を表します
オープンソースのAndroidパッケージの一部であるSettings.apkアプリケーションは、次の方法でそれを呼び出します。
sendBroadcast(new Intent("android.intent.action.MASTER_CLEAR"));
おそらく不正な通話から保護されている
It can only be granted to apps signed with the platform key, or installed on the system partition.
ただし、以下で説明するように、通常のアプリケーションはこの保護を回避できます。
クリーニングを開始する他の方法を探した後、Stackoverflowで、通常のアプリケーション（特別な権限なし）がSettings.apkにクリーンアップ管理ページを表示する方法のレシピを見つけました。ユーザー自身が信頼できるアプリケーションページで[クリーニング]をクリックします。
Context ctx = createPackageContext("com.android.settings", Context.CONTEXT_IGNORE_SECURITY | Context.CONTEXT_INCLUDE_CODE); Class<?> mc = ctx.getClassLoader().loadClass("com.android.settings.MasterClear"); startActivity(new Intent(ctx, mc));
すべてがユーザーの制御下にある間...
次に、Desire Zの標準Gingerbread 2.42ファームウェア（HTC Sense）からすべてのアプリケーションを逆コンパイルし、android.intent.action.MASTER_CLEARまたはcom.android.settings.MasterClearの呼び出しのソースを調べました。
合計で4つのアプリケーションがありました。
CheckinProvider.apk MyHTC.apk Settings.apk Mail.apk
最初の2つは、失われたデバイスをGoogleおよびHTCオンラインサービスからブロックする機能です。その後、デバイスは設定ページからのユーザーの要求に応じて消去され、調査の犯人はメールクライアントです。
メーラーは、次のコードでクリーニングを呼び出します。
Intent i = new Intent("android.intent.action.MAIN"); i.setClassName("com.android.settings", "com.android.settings.MasterClear"); i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); i.putExtra("EASRemoteWipe", true); this.mContext.startActivity(i);
つまり、前の例から、彼はもう少し進んで、ユーザーがクリックできるボタンでアクティビティを呼び出しませんが、ボタンがクリックされた後に開始するアクティビティを呼び出します。
このコードを実行するのに特別な権限は必要ないと思われます（java-IDEもAndroid SDKもインストールされていないため、確認できません）。
これで私の好奇心は満足しました。 dasasmaリストの MasterXlearのMasterClear行を修正した後、 Mail.apkを再構築し、デバイスにアップロードして、ワイプ交換コマンドが電話で電力を供給していないことを確認しました（メールを同期しようとすると、電話が失われるまで同期エラーが表示されます） Exchangeアカウントから解放され、その後、次の同期で、すべてのメールが新しいデバイスのように再び注がれ、引き続き正常に動作します）
結論として、私はそれらを克服することで私に多くの喜びを与えたいくつかの熊手を説明します。 アンドロイド開発者にとって、これらは基本的なものですが、初心者のハッカーにとっては明らかではありません。
1.再構築されたアプリケーションの署名。
Androidアプリケーションは、個人の開発者証明書で署名する必要があります。署名しないと、起動しません。 以下の方法で質問すると、 opensslプログラムから無料の証明書を取得できます。
openssl genrsa -out key.pem 1024 openssl req -new -key key.pem -out request.pem openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt
その結果、切望されたcertificate.pem 、 key.pem 、およびkey.pk8を取得し、 signapk.jarユーティリティを使用して、再構築されたMail.apkに署名します。
java -jar signapk.jar certificate.pem key.pk8 Mail-unsigned.apk Mail-signed.apk
2. Dalvikキャッシュ
各アプリケーションにはJITコンパイルキャッシュがあり、実行ごとにコンパイルされるわけではありません。 通常の方法でapkをインストールすると、キャッシュはクリアされますが、アプリケーションを（/ system / appシステムパーティションに）コピーするときは、自分でクリアする必要があります。
rm /data/dalvik-cache/*@Mail.apk@*
3.グリッチapktool
アプリケーションの逆アセンブルと再構築に使用したapktoolユーティリティは、操作不能なファイルを永続的に作成しました。 apk内には、binary resources.arscファイルに収集されたリソース （たとえば、このファイルのxmlリソースがバイナリに変換されます。これは、xmlツリー内でのナビゲーションに役立つ可能性が最も高い）とclasses.dexでコンパイルされたコードです 。 コードを編集するだけなので、逆コンパイル時に-rオプション（リソースをデコードしない）を設定し、固定エントレイルをコンパイルしてapkファイルに戻した後、ようやく開始しました。