小心android广告木马恶意使用root权限（发现及清理过程）

    个人nexus 7平板，到手后天然是root了。平时也不会去开SuperSu，然而某一天，我无心打开SuperSu，竟然看到有两个游戏被授予的root权限，心中感到有点不妙。估计是小孩玩的时候，游戏中的恶意插件请求root权限，小孩顺手赞成了。

    哎，这两个游戏是google play上下的，立即把这两个游戏删除，root权限许可也删除。没多久，一个android.process.acore的进程开始请求root权限。好吧，从名字上来看应该是个系统进程，应该是能够相信的。然而稍微细想一下，要知道原厂出的ROM都是没有root过的，那么原厂ROM里的进程请求root权限是一件奇怪的事。我断然拒绝了这个进程的请求，到了次日发现电量离奇的没了，看到一个叫“RC Services”的应用消耗了许多的电量。SuperSu里的日志显示android.process.acore这个进程开始每过十几分钟到半小时请求一次root权限，显然平板电脑不能正常sleep，致使电量消耗巨大。

    平板电脑显然中招了。一段时间以来，只要平板电脑一联网，就会出广告，甚至正在使用时，自动弹出广告的现象也有合理解释了。上网搜索android.process.acore和RC Services都没有什么有用的信息。到google play上下载了360平板卫士也没有查出个毛来。只有本身动手了。先治标，既然android.process.acore不断请求root权限，Y的我把SuperSu和/system/xbin/su删除掉，没的root权限了，耗电的问题是暂时解决了。

    周末有时间，开始进一步的清理。先进入recovery模式（由于正常模式没root权限了），把记录系统安装的应用的文件抓下来。

adb pull /data/system/packages.xml .
adb pull /data/system/packages.list .

在这两个文件里搜索了一下，没有RC Services和 android.process.acore的信息。有点犯傻了，不知道该怎么进一步进行，想起在系统的应用程序信息里看到RC Services是内置应用，因此到/system/app目录了胡乱翻了一下，发现有几个apk文件没有对应的odex文件，以为可疑。由于我用的是原厂ROM，没有deodex，因此通常而言系统内置的apk会有一个对应的odex文件（后来发现，原厂ROM里也有少数几个不带odex文件的apk）。无论怎么说，缩小了检查范围，随便挑了一个，SystemServices.apk，到packages.xml里竟然没找到对应的记录。总算有点蛛丝马迹了，因而弄个脚本，看看/system/app下有几个apk没有在packages.xml里记录，

#!/sbin/sh
for f in `ls /system/app/*.apk`; do
  i=`grep "$f" /data/system/packages.xml`
  if test -z "$i"; then echo $f
  fi
done

for f in `ls /data/app`; do
  i=`grep "$f" /data/system/packages.xml`
  if test -z "$i"; then echo $f
  fi
done

保存为f.sh，把他push到平板上，执行。使用前先把system分区mount上。

adb push ./f.sh /tmp/
adb shell
cd /tmp
chmod 777 ./f.sh
./f.sh

找到了3个文件：

/system/app/MediaUtil.apk
/system/app/SystemServices.apk
/system/app/VPST-3.apk

第三个文件，根本就不是apk应用，而是假装成apk的su程序。好吧，su不是木马，咱们热衷于的root，核心就是它。正常的su文件是放在/system/xbin下，放在/system/app下，且假装成apk，就是别有用心了。用文件编辑器能够看到SuperSu和其做者Chainfire的字样。

余下的两个MediaUtil.apk和SystemServices.apk用apktool反编译，看看包里的AndroidManifest.xml描述信息。反编译后，能够看到SystemServices.apk的package名字为： android.process.core.daemon.services，进程名为： android.process.acore

<manifest android:versionCode="20012" android:versionName="1.03" package="android.process.core.daemon.services"
  xmlns:android="http://schemas.android.com/apk/res/android">

.....

    <application android:label="System Daemon" android:name="android.process.core.daemon.services.CoreApp" android:persistent="true" android:process="android.process.acore">

找到一个元凶了，用包名 android.process.core.daemon.services，到packages.xml里查找，发现包android.process.core.daemon.services，又是由另一个apk安装而来，

<package name="android.process.core.daemon.services" codePath="/system/app/MediaDaemon.apk" nativeLibraryPath="/data/app-lib/MediaDaemon" flags="573005" ft="13d71addae0" it="13d71addae0" ut="13d71addae0" version="20012" userId="10153">

好的，又抓到一个元凶MediaDaemon.apk。一样的分析MediaUtil.apk，其包名为com.android.phone.daemon.services，进程名为com.android.phone，而这个包又是指向另外一个apk文件，SettingsAvrcp.apk。

    到目前为止抓到5个文件，可是RC Services仍是没有找到来源。想起之前用CyanogenMod时有一个Dev Tools能够看到应用程序的实际package名，因而从其余ROM里抽取了一个Development.apk，安装上，用Packages Browse功能，找到RC Services对于的包名为：com.skd.bowling，到packages.xml里找到了对应的apk文件为SystemAvrcp.apk。

/system/app/MediaUtil.apk
/system/app/SystemServices.apk
/system/app/VPST-3.apk
/system/app/MediaDaemon.apk
/system/app/SettingsAvrcp.apk
/system/app/SystemAvrcp.apk

    遂把这几个文件删除之。