【逆向实战】恶意勒索软件分析,揪出病毒作者_披着羊皮的狼_被注入恶意代码的apk

匿名 (未验证) 提交于 2019-12-02 23:43:01

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

文章来源: https://blog.csdn.net/ALDYS4/article/details/92376145
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!