当心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

    遂把这几个文件删除之。

来源：oschina

链接：https://my.oschina.net/u/947271/blog/122704