【逆向实战】恶意勒索软件分析_披着羊皮的狼_被注入恶意代码的apk

/文章作者:Kali_MG1937

QQ:3496925334

CNBLOG博客号:ALDYS4/

今天逛某论坛的时候发现了一篇求助贴



有意思，好久没分析过恶意软件了

今天就拿它来练练手

反编译工具

apktool

jd-gui

eclipse(CFR,JD-CORE等反编译引擎)

JADX

DEX2JAR

0x01>分析AndroidManifest.xml

先看看恶意软件的基本信息



先百度一下恶意软件的包名



搜索结果显示这是一个被各大应用市场收录的软件

那么我分析我手上的这个恶意软件应该是被注入了恶意代码

如果我是恶意软件的开发者，一定会在第一时间让受害者触发恶意代码

那么先查看软件的主入口



com.superthomaslab.rootessentials.main_screen.MainActivity

看来这就是软件主入口了

0x02>分析代码

跟进主入口



可以看到截屏中的第6行

程序引入了一个包(Unlock.Unlock)，而且我与未被注入代码的软件对照

原软件并没有引入此包

果断搜索Unlock



程序在重写onCreateOptionsMenu方法时调用了Unlock中的方法

并向方法内传入了一个Context

跟进Unlock



查看Unlock方法

在第一句就申请了root权限，emm

不管，先看下去



第12行，变量名为file2的File获取了软件本身的资源

并将参数传递给zipFile2,调用getEntry方法获取了软件内的/lib/armeabi/libbaidu.so

接着程序又new了一个FileOutputStream对象并赋予了一个参数作为文件输出口

输出的文件名为Unlock

再看看19行

程序利用Runtime实例执行了一系列命令：

挂载/system

复制Unlock文件到/system/app/内，并命名为Unlock.apk

给Unlock.apk以644权限（写入系统）

接下来软件调用了isAZ方法,并传入了一个参数com.antilock.antilock



isAZ方法是判断软件是否存在的

如果手机安装了包名为com.antilock.antilock的软件，就调用runtime卸载掉它

根据包名来判断，这个软件大概是某个木马查杀软件

全部的代码执行完毕后调用reboot重启手机

（之前恶意代码向system分区写入了一个apk，重启才能让apk安装在手机上）

0x03>解密libbaidu.so文件

通过上一步的代码分析可知

libbaidu.so是一个被加密过的apk安装包，需要调用程序内的算法来进行解密



图中就是解密算法了

程序调用了一个while死循环

循环中的变量名为i的int被赋予了inputStream调用read方法后的值

而inputStream方法正是读取libbaidu.so的，

若i的值为-1（文件不存在）则跳出循环

否则就对变量名为bArr的byte进行一系列异或算法

最后输出文件

按照这个逻辑，我果断打开eclipse进行代码编写



最后输出一个可以正常打开的zip，将其后缀改为apk



是个伪装成正常应用的apk，看来之前分析的是个壳子，这就是真正的锁机文件了

不过这包名....

0x04>分析锁机文件代码

老样子，先看AndroidManifest.xml



软件入口：com.fuck.lock.MainActivity



从第20行看出，软件的log日志被传入com.aide.ui这个软件

看来作者是用aide开发的这个软件

A I D E 风 评 被 害（暴论）

可以看到onCreate方法内软件发送了一个意图

启动了com.fuck.lock.mc这个服务

跟进



mc这个类内的一个值引起我的注意

eq参数貌似是一个被加密的值

先不管，看看onCreate方法



其中调用了a方法和c类

值得一提的是a方法



程序在手机上创建了一个覆盖整个屏幕的悬浮窗

并且进一步分析发现，这个程序禁止了用户在悬浮窗以外的地方进行手势接触

很可疑

其中0x7f700...等等16进制，通过与软件自带的R文件对照

发现这几个16进制分别代表了几个布局文件



从病毒作者绘制的layout文件内容来看，软件在创建悬浮窗时其真正的意图就已经暴露了

勒索受害者，若不给钱，就恶意锁定受害者手机

而c类就是一些密码的加密解密之类的

不过我在浏览mc类的时候发现了一个有意思的方法：init



可以看到init方法内的代码：如果有人打来的电话，就记录下号码

这就有意思了，为什么病毒要记录号码？信息收集？这些信息这对作者有用吗？

并且受害者已经被锁定，也没法接电话，那么收集号码也没什么用啊

但是，柳暗花明又一村

我发现了一个广播类：IncomingReceiver

这个广播内调用了mc类的init方法

很有意思的类名，对吧



onRecevie方法内

程序正不断监听广播

如果广播内容是android.intent.action.PHONE_STATE

则程序就会截取extra为incoming_number的值

并且利用md5加密算法加密这个值

程序正在不断监听来电！

调用mc类的access$L100025方法



这个方法返回了eq这个值

你还记得吗！mc类最开始时的那个eq参数，是一串加密的密文

这让我的大脑兴奋了起来！

继续查看广播内的代码

程序校验了eq这个值是否与加密过的来电号码一样

如果一样，调用endCall方法挂断来电电话

并且将锁机悬浮窗移除！

整理一下逻辑，程序的大致意思是：

如果有电话打来，并且加密过的电话号码和eq密文一样

则停止锁机

这是作者留的后门吗？

ん？流 向 改 变 了

不管了，将密文复制

926e459bfecfc239953d3ff5aec1446a

解密



解密后：15527952330

一 转 攻 势

病毒作者的手机号码已经拿到了

已经提交给警方备案

迫害，请