March 13, 2014 By Zubair Ashraf 6 min read

DIY: Android Malware Analysis – Taking Apart OBAD (Part 1)

It has been much longer that what I intended for a follow-up post on OBAD analysis, but better late than never. In this post we’ll look at the following:

Let’s give OBAD a run

Last time we discussed about various tools for analysis, setting up the app to be debugged in jdb, identifying anti-emulator code, hacking and compiling AOSP code and then running the emulator with our modified system image to bypass antivm check. So now that you can bypass the anti vm checks, if you run OBAD in the emulator you would see it asking for enabling it as a DeviceAdmin

So it uses the label “System” for itself and if the user denies the request, it will keep asking for it. Once it is activated as a device admin, launcher icon disappears and it does not even appear as a device admin in the Device Admin list that can be seen via Settings -> Security -> Device Administrators.

The figure above shows that there is no app launcher icon visible for OBAD, and that is why in our previous post we mentioned that you have to manually launch the activity as we don’t see a launcher icon for it.  If you go and take a list of device administrators for the emulator/device you would not see it there either. The picture below shows how you would expect to see it listed as a Device Administrator

Here is what you would see in vulnerable Android (more about the vulnerability later)

So we don’t have a launcher icon, and we don’t have it in the device administrator’s list, may be our AV product detected it and deleted it? Let’s check it in the apps list (Settings -> apps), and you will find it there and perhaps we can then uninstall it from there, can you? Let’s take a look at the image below:

The uninstall button is disabled, but one might say ‘Hey! wait a second, I am better than this I can use the “adb uninstall”  command, and if you try that then you will fail and if you look at logcat output you will learn the following:

mobisec@Mobisec-VM:~/Malware/OBAD$ adb uninstall com.android.system.admin
Failure

mobisec@Mobisec-VM:~/Malware/OBAD$ adb logcat -d -b main -b events | grep admin | tail -1
W/PackageManager( 277): Not removing package com.android.system.admin: has active device admin

We can’t deactivate the device admin from Settings menu as it is not even listed as a device administrator and hence we can’t uninstall it. Let’s analyze how it does all this.

How to avoid process being killed due to Activity Not Responding (ANR)

In my previous blog entry for analyzing OBAD, we showed how one can trace methods entered and exited, after dealing with the AntiVM check, if you try to trace methods again you would see your process being killed and you will the following in logcat output

W/ActivityManager( 291): Timeout executing service: ServiceRecord{421b03d8 u0 com.android.system.admin/.MainService}
...
W/ActivityManager( 291): Killing ProcessRecord{421b77a0 1129:com.android.system.admin/u0a10053}: background ANR

Here is how you can patch Android code to avoid it:

zashraf@ubuntu-10-x64:~/Android/src_4.3_r3$ diff ./frameworks/base/services/java/com/android/server/am/ActiveServices.java.modified ./frameworks/base/services/java/com/android/server/am/ActiveServices.java.orig
1852,1857c1852
<  //Slog.w(TAG, " .... Hijacked ANR appnotresponding call for debugged app");
<  if (!proc.debugging)
<   mAm.appNotResponding(proc, null, null, false, anrMessage);
<  else
<   Slog.w(TAG, "prevented ANR on debuggee app - Hijacked ANR appnotresponding call for debugged app");
<
---
>  mAm.appNotResponding(proc, null, null, false, anrMessage);

=> for broadcast ANR
zashraf@ubuntu-10-x64:~/Android/src_4.3_r3/frameworks/base/services/java/com/android/server$ diff  am/BroadcastQueue.java  am/BroadcastQueue.java.orig
956,959c956
<  if (!app.debugging)
<   mHandler.post(new AppNotResponding(app, anrMessage));
<  else
<   Slog.w(TAG, "prevented ANR on (broadcast) debuggee app - Hijacked ANR appnotresponding call for debugged app");
---
>  mHandler.post(new AppNotResponding(app, anrMessage));

How did the launcher icon disappear?

I traced method entries as I described in my last post, and use the following exclude command in jdb to avoid tracing standard java code but still trace the methods invoked by reflection.

exclude android.os.*,org.apache.*,java.lang.D*,java.lang.N*,java.lang.P*,java.lang.U*,java.lang.F*,java.lang.Ru*,java.lang.E*,java.lang.T*,java.lang.V*,java.lang.I*,java.lang.A*,java.lang.S*,java.lang.B*,java.lang.ref.*,java.lang.C*,java.lang.O*,java.lang.S*,java.lang.V*,javax.*,sun.*,com.sun.*,java.s*,java.u*,java.s*,java.n*,java.i*,java.lang.reflect.A*,java.lang.reflect.C*,java.lang.reflect.F*,java.lang.reflect.Method.g*,java.lang.reflect.Method.<*

I noticed a call to android.app.ApplicationPackageManager.setComponentEnabledSetting being done via reflection, which can be examined further in jdb by setting a breakpoint.

Breakpoint hit: "thread=<1> main", android.app.ApplicationPackageManager.setComponentEnabledSetting(), line=1,262 bci=0

<1> main[1] wherei
 [1] android.app.ApplicationPackageManager.setComponentEnabledSetting (ApplicationPackageManager.java:1,262), pc = 0
 [2] java.lang.reflect.Method.invokeNative (native method)
 [3] java.lang.reflect.Method.invoke (Method.java:525), pc = 17
 [4] com.android.system.admin.cCoIOIOo.ollIIIc (null), pc = 748
 [5] com.android.system.admin.cCoIOIOo.onActivityResult (null), pc = 9
 [6] android.app.Activity.dispatchActivityResult (Activity.java:5,322), pc = 7
 [7] android.app.ActivityThread.deliverResults (ActivityThread.java:3,363), pc = 38
 [8] android.app.ActivityThread.handleSendResult (ActivityThread.java:3,410), pc = 172
 [9] android.app.ActivityThread.access$1100 (ActivityThread.java:141), pc = 0
 [10] android.app.ActivityThread$H.handleMessage (ActivityThread.java:1,304), pc = 229
 [11] android.os.Handler.dispatchMessage (Handler.java:99), pc = 20
 [12] android.os.Looper.loop (Looper.java:137), pc = 84
 [13] android.app.ActivityThread.main (ActivityThread.java:5,103), pc = 56
 [14] java.lang.reflect.Method.invokeNative (native method)
 [15] java.lang.reflect.Method.invoke (Method.java:525), pc = 17
 [16] com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:737), pc = 11
 [17] com.android.internal.os.ZygoteInit.main (ZygoteInit.java:553), pc = 70
 [18] dalvik.system.NativeStart.main (native method)
<1> main[1] locals
Method arguments:
componentName = instance of android.content.ComponentName(id=830033869864)
Local variables:
newState = 2
flags = 1
<1> main[1] print componentname
com.sun.tools.example.debug.expr.ParseException: Name unknown: componentname
componentname = null
<1> main[1] print componentName
componentName = "ComponentInfo{com.android.system.admin/com.android.system.admin.cCoIOIOo}"
<1> main[1]

Why don’t we see the OBAD listed as a Device Administrator?

If you are trying this with one of the latest build of Android, you would notice that OBAD is actually listed as a device administrator, the reason is that this vulnerability has already been fixed. To understand the vulnerability we can simply look at patch logs and analyze the patches, I think it would be more interesting to take a look at it without seeing the patch. So what code gets executed when you open up Settings -> Security -> Device Administrators? You can open it up and then take a look at the output from logcat from event buffer you would see:
adb logcat -d -b events

...

I/am_new_intent( 276): [0,1106566944,17,com.android.settings/.Settings,android.intent.action.MAIN,NULL,NULL,274726912]
I/am_resume_activity( 276): [0,1106900904,17,com.android.settings/.Settings]
I/am_on_resume_called( 1118): [0,com.android.settings.Settings]
I/am_create_activity( 276): [0,1107200744,17,com.android.settings/.SubSettings,android.intent.action.MAIN,NULL,NULL,0]
I/am_pause_activity( 276): [0,1106900904,com.android.settings/.Settings]
I/am_on_paused_called( 1118): [0,com.android.settings.Settings]
I/am_restart_activity( 276): [0,1107200744,17,com.android.settings/.SubSettings]

So this tells us where to start looking for the code that lists device administrators, we can search for it on androidxref and find Settings.java and there you will find use of R.id.security_settings, if you search for it you will find it in settings_headers.xml as:

<!-- Security -->
127 <header
128  android:<b>fragment=</b>"com.android.settings.SecuritySettings"
129  android:<b>icon=</b>"@drawable/ic_settings_security"
130  android:<b>title=</b>"@string/security_settings_title"
131  android:<b>id=</b>"@+id/security_settings" />

So let’s take a look at com.android.settings.SecuritySettings, you will see it creating device admin preference category as:

PreferenceGroup deviceAdminCategory= (PreferenceGroup)
261    root.findPreference(KEY_DEVICE_ADMIN_CATEGORY);

If you track KEY_DEVICE_ADMIN_CATEGORY you will get to security_settings_misc.xml and see

43  <Preference android:<b>title=</b>"@string/manage_device_admin"
44    android:<b>summary=</b>"@string/manage_device_admin_summary"
45    android:<b>persistent=</b>"false"
46    android:<b>fragment=</b>"com.android.settings.DeviceAdminSettings"/>

So next step is to get to DeviceAdminSettings, browsing around you would get to updateList (note: I am taking you to an unpatched version of updateList) and you will notice that for something to be displayed in the device administrator list it must meet the following conditions:

1. Should be in the list returned by:

getActivity().getPackageManager().queryBroadcastReceivers(
    <b>new</b> Intent(DeviceAdminReceiver.ACTION_DEVICE_ADMIN_ENABLED),
    PackageManager.GET_META_DATA | PackageManager.GET_DISABLED_UNTIL_USED_COMPONENTS);

2. Should be visible or active:

DeviceAdminInfo dpi = new DeviceAdminInfo(getActivity(), ri);
    if (dpi.isVisible() || mActiveAdmins.contains(dpi.getComponent())) {
mAvailableAdmins.add(dpi);

With some trivial debugging you would realize that OBAD device admin component is not being returned by queryBroadcastReceivers and further debugging would eventually lead you to manifest file of OBAD saying:
<receiver "System" =".OCllCoO">
   <meta-data "android.app.device_admin" ="@2130968576">
   </meta-data>
   <intent-filter>
    <action name="com.strain.admin.DEVICE_ADMIN_ENABLED">
    </action>
   </intent-filter>
 </receiver>

Notice the use of com.strain.admin.DEVICE_ADMIN_ENABLED, the developer docs say that DeviceAdministrator components should register to receive android.app.action.DEVICE_ADMIN_ENABLED, but the bad guys don’t have to listen to that and they don’t and this is how they hide their device admin. As it is not registered to receive such broadcasts, it does not appear when receivers of it are retrieved in updateList (discussed above).

Looking around a bit I found something interesting that I will share in my next post soon (hopefully within two weeks) so stay tuned and think about this: you give a friend keys to your kingdom/palace/house and he gives his to you, but what you have given him was fake.

Until next time stay safe.

 

More from Malware

Ongoing ITG05 operations leverage evolving malware arsenal in global campaigns

13 min read - As of March 2024, X-Force is tracking multiple ongoing ITG05 phishing campaigns featuring lure documents crafted to imitate authentic documents of government and non-governmental organizations (NGOs) in Europe, the South Caucasus, Central Asia, and North and South America. The uncovered lures include a mixture of internal and publicly available documents, as well as possible actor-generated documents associated with finance, critical infrastructure, executive engagements, cyber security, maritime security, healthcare, business, and defense industrial production. Beginning in November 2023, X-Force observed ITG05…

X-Force Threat Intelligence Index 2024 reveals stolen credentials as top risk, with AI attacks on the horizon

4 min read - Every year, IBM X-Force analysts assess the data collected across all our security disciplines to create the IBM X-Force Threat Intelligence Index, our annual report that plots changes in the cyber threat landscape to reveal trends and help clients proactively put security measures in place. Among the many noteworthy findings in the 2024 edition of the X-Force report, three major trends stand out that we’re advising security professionals and CISOs to observe: A sharp increase in abuse of valid accounts…

Hive0051’s large scale malicious operations enabled by synchronized multi-channel DNS fluxing

12 min read - For the last year and a half, IBM X-Force has actively monitored the evolution of Hive0051’s malware capabilities. This Russian threat actor has accelerated its development efforts to support expanding operations since the onset of the Ukraine conflict. Recent analysis identified three key changes to capabilities: an improved multi-channel approach to DNS fluxing, obfuscated multi-stage scripts, and the use of fileless PowerShell variants of the Gamma malware. As of October 2023, IBM X-Force has also observed a significant increase in…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today