Remote wipe on Android and Exchange ActiveSync

One day, our Microsoft Exchange administrator mentioned the functionality of a complete wipe of any device of your choice (be it an iPhone, or a BlackBerry-based or Android device) that received mail via Exchange ActiveSync. The device reports to the server whether the wipe functionality is available to it, and the administrator can prevent the transfer of mail to devices that do not support wipe.

At first, I didn’t believe it: as it is, the innocuous setup of a mail account gives the mail administrator so much authority on my personal device. After making a full backup of the SD card and all the internal memory, I suggested an experiment. And a miracle - a push-notification came, the phone was podzavis, after a while it rebooted and I was left with the factory settings. And the SD card showed no signs of life at all.


')
Interested, I decided to study this issue and, if possible, disable the malicious functionality of the mail client.



First you had to see what happened to the SD card. The phone believed that it was missing and I inserted it into the card reader. A scan in the HEX editor showed that the partition table (MBR) is overwritten, but the partitions themselves (FAT32 and Linux swap) are quite normal. With the wonderful TestDisk utility, I instantly restored the contents of the card to the state before cleaning (here you have Full Wipe)

Then I looked through the Android sources, searching for the keywords wipe, clear, factory settings. The self-destruction code is located in the /system/framework/services.jar module and is a kind of BroadcastReceiver that is waiting for a data destruction request (the source code of this class )

The Settings.apk application, part of the open-source Android package, calls it in the following way:

sendBroadcast(new Intent("android.intent.action.MASTER_CLEAR")); 

From an unauthorized call, he allegedly protected

 It can only be granted to apps signed with the platform key, or installed on the system partition. 

But, as we will see below, a regular application can bypass this protection.

After searching for other ways to start cleaning, I found a recipe on Stackoverflow, just like a normal application (without special permissions), can ask Settings.apk to show a cleaning management page, where the user can click on “Clear” on the page of the trusted application.

 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)); 

While everything is under the control of the user ...

Next, I decompiled all applications from the standard Gingerbread 2.42 (HTC Sense) firmware for Desire Z, and looked in the source for references to android.intent.action.MASTER_CLEAR, or to com.android.settings.MasterClear.

In total there were four such applications:

  CheckinProvider.apk
 MyHTC.apk
 Settings.apk
 Mail.apk 

The first two are the functionality of locking a lost device from Google and HTC online services, then clearing the device at the user's request from the settings page and the cause of the investigation, the email client.

Mailer calls for cleaning with this code:

  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); 

That is, from the previous example, he went a little further and causes not an activity with a button that the user can click, but an activity that starts after pressing the button.

I have a suspicion that special permissions are not needed to execute this code (I can’t verify it, because neither java-IDE nor Android SDK is installed).

On this my curiosity was satisfied. Having corrected the MasterClear line on MasterXlear in dizasm listing , I rebuilt Mail.apk, uploaded it to the device and checked that the wipe from exchange command no longer has power over the phone (when trying to synchronize mail, a synchronization error appears until the “lost” phone will be untied from the exchange account, after which on the next synchronization all mail is re-uploaded, like on a new device, and continues to work normally)

In conclusion, I will describe a few rakes that gave me a lot of pleasure in overcoming them. For Android developers, these are elementary things, but for novice hackers, they are not obvious.

1. Signature of the reassembled application.

Any Android application must be signed by a personal developer certificate, otherwise it will not start. A free certificate can be obtained from the openssl program, if you ask it about it like this:

 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 

As a result, we will get the desired certificate.pem , key.pem and key.pk8 , which we will sign reassembled Mail.apk with the help of the utility signapk.jar :

 java -jar signapk.jar certificate.pem key.pk8 Mail-unsigned.apk Mail-signed.apk 

2. Dalvik cache

Each application has a JIT compilation cache so as not to compile each run. When you install apk in the usual way, the cache is cleared, but when copying the application (to the system / system / app partition), you need to clear it yourself:

 rm /data/dalvik-cache/*@Mail.apk@* 

3. Glitches apktool

The apktool utility, which I used to disassemble and rebuild the application, persistently created an inoperative file. Inside apk there are resources compiled into a binary file resources.arsc (for example, xml resources in this file are converted to a binary form, most likely for easy navigation through the xml tree) and the code compiled into classes.dex . Since I only need to edit the code, when I decompiled I set the option -r (Do not decode resources) and after compiling the corrected tripe back into the apk-file, it finally started.