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

/文章作者:Kali_MG1937
QQ:3496925334
CSDN博客号: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
一 转 攻 势
病毒作者的手机号码已经拿到了
已经提交给警方备案
迫害，请