Some analysis of Android Device Manager

Author: limitemp Time: 2014-01-12,20:43:04 Links: http://bbs.pediy.com/showthread.php?t=183692 Presumably a lot of people know sensation Android Trojan Obad, the Trojan uses the vulnerability of Android Device Manager, when the user activates Device Manager, the program will be hidden in the setting Device Manager list, after the application is activated into Device Manager, the lock screen can be implemented, Erase user data and other functions, and can not be uninstalled using the general Uninstall method, this article mainly and describes the vulnerability principle and vulnerability patches to share some of the things that individuals encountered during the analysis. Android in the implementation of Device Manager, you need to register a broadcast receiver in Manifest.xml, the code is as follows <receiver Android:name= ". Mydeviceadmin " android:permission= "Android.permission.BIND_DEVICE_ADMIN" > <meta-data Android:name= "Android.app.device_admin" Android:resource= "@xml/device_admin"/> <intent-filter> <action android:name= "Android.app.action.DEVICE_ADMIN_ENABLED"/> </intent-filter> </receiver> Obad How to hide it in the Setting Manager list, we can find the answer by setting source code. Related code: Packages\apps\settings\src\com\android\settings\deviceadminsettings.java Main methods: void Updatelist () { Mactiveadmins.clear (); List<componentname> cur = mdpm.getactiveadmins (); if (cur! = null) { for (int i=0; i<cur.size (); i++) { Mactiveadmins.add (Cur.get (i)); } } Get activated Device Manager list Mactiveadmins Mavailableadmins.clear (); Mavailableadmins setting list of device managers list<resolveinfo> avail = getactivity (). Getpackagemanager (). Querybroadcastreceivers ( New Intent (deviceadminreceiver.action_device_admin_enabled), Packagemanager.get_meta_data); Get all registered deviceadminreceiver.action_device_admin_enabled that's Android.app.action.DEVICE_ADMIN_ENABLED List of broadcast recipients for action avail int count = Avail = = null? 0:avail.size (); for (int i=0; i<count; i++) { ResolveInfo ri = Avail.get (i); try { Deviceadmininfo dpi = new Deviceadmininfo (getactivity (), RI); if (dpi.isvisible () | | mactiveadmins.contains (dpi.getcomponent ())) { Mavailableadmins.add (DPI); If the app registers a broadcast recipient that contains the action and the Device Manager is activated, it is displayed in the Device Manager list in setting } } catch (Xmlpullparserexception e) { LOG.W (TAG, "skipping" + Ri.activityinfo, E); } catch (IOException e) { LOG.W (TAG, "skipping" + Ri.activityinfo, E); } } Getlistview (). Setadapter (New Policylistadapter ()); } However, applications that do not register Android.app.action.DEVICE_ADMIN_ENABLED action can also be activated as Device Manager. This causes the Device Manager after activation to not appear in the setting Device Manager list. How to solve this situation? Now let's analyze the security Butler's Device Manager patch. The patch is a normal apk, decompile it, and the code structure is as follows Code structure. png The main class Deviceadminproxy code is as follows: Deviceadminproxy.png The main content of the above method is to compare the activated Device Manager list A directly obtained through devicepolicymanager and register through traversal Android.app.action.DEVICE_ADMIN_ENABLED If the Device Manager in List A does not appear in List B, call the following code to eject the deactivated activity and let the user cancel it manually, if the action list B is compared. Deactivate. png There is a Rootmain class in the code that is used when the root permission is available, to find a Device Manager that exploits this vulnerability to invoke Devicepolicymanager's Removeactiveadmin method to deactivate This method requires more than system permissions to execute. About the android.app.action.DEVICE_ADMIN_ENABLED caused by the hole is here to end, the following is the analysis of another interesting thing to encounter. As mentioned earlier, when setting gets the manager list, there is a piece of code such as Deviceadmininfo.png The instance Deviceadmininfo object in the code, Deviceadmininfo.java in Frameworks\base\core\java\android\app\admin\deviceadmininfo.java Key code: Di2.png Previously, we had the following configuration in manifest Receiver: Manifest.png If you do not configure the Meta-data,deviceadmininfo class will throw an exception, deviceadminsettings to get the exception, according to the code in the figure above can be found, the same setting Device Manager list will not be displayed. This setting does not appear, however, if you do not configure Meta-data, Device Manager is not able to activate normally. What do we do? Install with normal Device Manager program, normal activation, and then remove the program's meta-data configuration, build apk, install to the Android device in the form of update installation. This time uninstalling the program will find that the program has been activated as Device Manager, but not found in the setting Device Manager list. Because Device Manager has registered Android.app.action.DEVICE_ADMIN_ENABLED, it is not available to use the above device management vulnerability patches. So how do I deactivate it? From the above for the Device Manager Vulnerability Patch APK analysis can be obtained two methods of deactivation analysis (actually three kinds): One, Devicepolicymanager gets the list of activated device managers, and then uses the following code Deactivate. png Initiates the deactivation activity. The test results are not feasible because Deviceadminadd also needs to parse the information in the Meta-data. See Deviceadminadd.java in Packages\apps\settings\src\com\android\settings\ Deviceadminadd.java. Second, get to the activated Device Manager list directly call Devicepolicymanager's Removeactiveadmin method deactivated, the test result is successful, but requires the permissions above system. Devicepolicymanager.java is located in Frameworks\base\core\java\android\app\admin\devicepolicymanager.java. Problem analysis here may be some children's shoes have been found, use the normal apk to activate the Device Manager, and then use the exception of the APK to avoid the device Manager is canceled. What if the Android device restarts? Will I be able to keep it active after rebooting? The answer is no, after restarting the device, it cannot remain active. What is the reason? The analysis is as follows: Main code Frameworks\base\services\java\com\android\server\devicepolicymanagerservice.java After the Android device restarts, Systemserver starts the Devicepolicymanagerservice service and calls the Systemready method to reinitialize the Device Manager list. As follows: Systemready.png Call Findadmin in the Loadsettingslocked method Findadmin.png As you can see in the code here, the exception is caught when the meta-data is fetched, and a null value is returned. Exception.png So the third method: Restart ... If there is a wrong place, please correct me. Finally attach the use of the apk* reprint please specify from the Snow forum @pediy.com Uploaded attachments Do not register action.apk (202.7 KB, 89 downloads) Do not register meta.apk (202.7 KB, 58 downloads) Device Emulator Vulnerability patch. APK (65.4 KB, 77 downloads) Normal. APK (202.8 KB, 81 downloads)

Some analysis of Android Device Manager