-
-
[原创]恶意代码plankton分析记录（1）
-
发表于: 2013-7-30 21:04
-
搜了下还没有写plankton的帖子。第一次写分析帖，主要督促自己养成整理的习惯。水平较低 高手就不用浪费时间看了。
正文：
恶意程序名称：plankton
MD5：5aff5198c2fe5798bd7f1519dab0cd4ee737d5d2
主要功能：上传用户手机信息到远程服务器。并从服务器接收命令。远程执行jar文件并搜集信息上传。
此种恶意程序主要通过感染其他应用来进行传播。也就是将其本身作为一个单独的服务，通过用户启动被感染的应用来激活。
通过分析几种被感染的应用程序可以发现一个共同的特点：plankton有一个完整的可作为服务的包，被感染的应用中的主活动中的onCreate()方法中被嵌入了一句代码：AndroidMDKService.initMDK(); 来启动此恶意服务。
此次分析的这个被感染程序为一款《愤怒的小鸟》作弊器。分析过程如下：
1. 首先将apk文件反编译(使用的apktool)。查看AndroidManifest文件。
在其中找到主活动为AngryBirdCheater类。并且在这个活动中还包括一个服务AndroidMDKService。从下面分析可以知道这个服务就是恶意程序要开启的。
2. 使用dex2jar将应用文件反编译成jar文件，使用jd-gui查看：
其中crazyapps包为被感染应用程序的原始包，而plankton.device.android.service为恶意应用包，通过查看几种被感染的应用会发现，plankton都是以一个单独的包出现。
3. 查看应用的主活动。
定位到onCreate方法中，发现此处有启动服务的操作，通过initMDK进行了初始化。然后转到plankton包中的AndroidMDKService文件中去查看。程序进行了混淆。
initMDK中进行了一些变量设置。包括远程服务器地址和要下载的文件地址。
然后发现文件中的有些方法进行了混淆，不容易通过方法名来进行分析，但是发现这些方法中有些Log()信息。所以这时候选择安装此应用，将应用跑起来查看日志信息是怎样的，然后再从代码中查找。
打开应用进入主活动后得到了上图的日志信息。通过日志信息对应可以定位到了服务类的onStart()方法。在这个方法中，又调用了另外一个方法：
str11,12,13分别表示APPLICATION_ID, DEVELOPER_ID, M_INSTALLATION_URL。然后继续查看文件b中的内容。
4. b类继承了AsyncTask类，这是一个开启多线程的类。
继续查看其中的关键代码，定位到d()方法中。并且发现有日志输出，和实际的运行相对应，可以确定此方法被执行过。
其中的关键代码如下：
可以看出str4表示permissions，是通过e.b(this.b)获取的。查看e.b()方法的代码：
最后返回的是localStringBuilder1。
5. 继续看调用了e.a()方法，转到文件e中查找。发现其中有3个a方法，因为此时的调用存在两个参数，就可以在这3个方法中定位到了一个，但发现是有错误的。
6. 转向分析smali代码。查看对应文件smali – com – plankton – device – android – service – e.smali. 定位方法a如下：
经过系列的方法调用： BasicHttpParams.init, HttpConnectionParams. setConnectionTimeou, DefaultHttpClient.init, HttpPost.init, UrlEncodedFormEntity.init, HttpPost. setEntity, HttpClient. execute, HttpResponse. getStatusLine, StatusLine. getStatusCode, ByteArrayOutputStream.init, HttpResponse. getEntity, HttpEntity. writeTo, ByteArrayOutputStream.close, ByteArrayOutputStream. toString, return.
其中较关键的是：
这句以方法接收到的第一个参数（p0保存的）调用HttpPost，查看p0的内容可以发现代表M_INSTALLATION_URI, 实际内容也就是http://www.searchwebmobile.com/ProtocolGW/installation.
这一句以收到的第二个参数(p1保存)来调用UrlEncodedFormEntity.init，也就是将要传送到服务器端的信息格式化。
此方法返回的是从服务器端返回来的相应。
7. 继续返回到java代码中b.class：
从这里可以看到应用会打印日志信息，包含”getNewJarInfo() response…”信息。但是从实际的运行当中可以看到，这个日志记录是没有打印出来的。所以可以判断，这一步没有执行。进一步可以判定应该就是e.a()方法的调用没有成功返回，也就是没有得到从服务器端发来的相应信息。
总结：这篇绝对不是完整版的分析。安装这个应用运行后已经无法正常和远程服务器通信。这里只是应用的一种功能，按照安全播报和代码上可以知道另外一个功能是从远程服务器下载.jar文件然后执行。在此也希望有成功触发过恶意功能的高手或者感兴趣的朋友分享经验。
第一次写难免很多不足的地方，望各位不吝指正。
继续补充：自己抓包看了下和服务器的交互过程，确实是404了，很遗憾。下图是交互过程，每隔若干秒会重复向服务器发送请求，包都是一样的。
下面可以看出http请求内容，还有其中附带了所有的permission信息。
下面是服务器端返回的信息
样本文件： 5aff5198c2fe5798bd7f1519dab0cd4ee737d5d2.apk
[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
