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

March 13, 2014
| |
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

OBAD asking device admin permission

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.

After enabling as device admin, access app launcher is no longer present

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

Device admin list does show OBAD as an admin in non vulnerable Android

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

Where did OBAD go?

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:

Cannot uninstall OBAD after making it a device admin

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:

[email protected]:~/Malware/OBAD$ adb uninstall

[email protected]:~/Malware/OBAD$ adb logcat -d -b main -b events | grep admin | tail -1
W/PackageManager(  277): Not removing package 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}
W/ActivityManager(  291): Killing ProcessRecord{421b77a0}: background ANR

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

[email protected]:~/Android/src_4.3_r3$ diff ./frameworks/base/services/java/com/android/server/am/ ./frameworks/base/services/java/com/android/server/am/
<       //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
[email protected]:~/Android/src_4.3_r3/frameworks/base/services/java/com/android/server$ diff  am/  am/
<       if (!app.debugging)
< AppNotResponding(app, anrMessage));
<       else
<          Slog.w(TAG, "prevented ANR on (broadcast) debuggee app - Hijacked ANR appnotresponding call for debugged app");
> 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 being done via reflection, which can be examined further in jdb by setting a breakpoint.

Breakpoint hit: "thread=<1> main",, line=1,262 bci=0

<1> main[1] wherei
  [1] (,262), pc = 0
  [2] java.lang.reflect.Method.invokeNative (native method)
  [3] java.lang.reflect.Method.invoke (, pc = 17
  [4] (null), pc = 748
  [5] (null), pc = 9
  [6] (,322), pc = 7
  [7] (,363), pc = 38
  [8] (,410), pc = 172
  [9]$1100 (, pc = 0
  [10]$H.handleMessage (,304), pc = 229
  [11] android.os.Handler.dispatchMessage (, pc = 20
  [12] android.os.Looper.loop (, pc = 84
  [13] (,103), pc = 56
  [14] java.lang.reflect.Method.invokeNative (native method)
  [15] java.lang.reflect.Method.invoke (, pc = 17
  [16]$ (, pc = 11
  [17] (, 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 Name unknown: componentname
 componentname = null
<1> main[1] print componentName
 componentName = "ComponentInfo{}"
<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,,android.intent.action.MAIN,NULL,NULL,274726912]
I/am_resume_activity(  276): [0,1106900904,17,]
I/am_on_resume_called( 1118): [0,]
I/am_create_activity(  276): [0,1107200744,17,,android.intent.action.MAIN,NULL,NULL,0]
I/am_pause_activity(  276): [0,1106900904,]
I/am_on_paused_called( 1118): [0,]
I/am_restart_activity(  276): [0,1107200744,17,]

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

<!-- Security -->
127    <header
128        android:<b>fragment=</b>""
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, 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:title="@string/manage_device_admin"
44                android:summary="@string/manage_device_admin_summary"
45                android:persistent="false"
46                android:fragment=""/>

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:

                new 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())) {

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 "" ="@2130968576">
        <action name="com.strain.admin.DEVICE_ADMIN_ENABLED">

Notice the use of com.strain.admin.DEVICE_ADMIN_ENABLED, the developer docs say that DeviceAdministrator components should register to receive, 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).

Until next time stay safe.


Zubair Ashraf
X-Force Security Researcher, IBM Security

Zubair Ashraf is a security researcher and team lead for IBM X-Force Advanced Research. He is very passionate about fighting all malicious activities in cybe...
read more

Banner ad leading to the Cost of a Data Breach Report for 2020.
Banner ad leading to the Cost of a Data Breach Report for 2020.
Your browser doesn’t support HTML5 audio
Press play to continue listening
00:00 00:00