元芳科普 || 一个加固apk文件的破解之路

刷单诈骗中下载app是诈骗分子的惯用套路，当破案线索仅一个app时我们该如何开展工作呢？app可以为我提供哪些线索？

办案过程往往很容易获得犯罪工具，例如受害人提供的某个诈骗软件，但是对其进行取证，找到证据链条却是困难重重；当我们对app进行侦查研究时，不能仅仅局限于apk本身，可以结合静态分析和动态分析。

静态分析在不运行代码的方式下，观察分析文件信息，在Android 平台上，静态分析就是分析apk安装包；动态分析在运行代码的情况下，通过跟踪分析相关的内存，如获取域名或IP等，挖掘可能存在的漏洞。

静态分析通过反编译apk文件，分析其中的权限、组件、敏感函数等信息，这些可以弥补动态分析中因未触发恶意行为而漏掉的行为；反编译文件就是使APK变成我们可以阅读理解的文件，本次文章我们将重点为大家讲解静态分析的基础知识并分享一个AndroidManifest.xml加固分析的实际案例。

APK (Android application package)，Android应用程序包，是一个标准的 ZIP 文件，即 1.apk == 1.zip。

1. 通过下载链接下载apk文件；

2.安卓手机例如华为、小米可直接分享apk文件；

例如小米手机：长按app出现分享按钮：

可以将apk文件微信、QQ等应用内，如果分享至微信，后续解析文件需要将后缀更为.apk形式：

3.执行adb命令获取apk安装包；

第一步：下载并安装ADB

第二步：打开命令窗口执行adb命令

如果adb安装在D盘，需要进入到D盘执行命令，如下命令框输入d:

查看是否有root权限：adb shell

查看所有应用列表：adb shell pm list packages

查看系统应用列表：adb shell pm list packages -s

查看点三方应用列表：adb shell pm list packages -3：

根据包名找出apk在内部存储空间的路径：adb shell pm path com.taobao.idlefish(你需要查询的包名）

使用adb pull命令将apk文件导出：

adb pull 

/data/app/com.taobao.idlefish-1/com.taobao.idlefish（你需要导出的apk文件的路径）

无糖浏览器的手机应用分析系统在不断升级更新后，已经可以破解大部分apk文件，因此，在破案过程中，可以直接上传解析试一下，该应用是将apk文件解压，然后将其中相关文件反编译，提取反编译之后的文件中有利于下一步工作的关键信息。界面展示如下：

当然除了无糖浏览器自带的工具可以反编译，还可以使用其他工具或提取方式例如：

1. apktool （获取资源文件）：

使用apktool工具查看apk的xml文件、AndroidManifest.xml和图片等；

2. dex2jar（源码文件获取）：

classes.dex转换成jar包；

3. jd-gui （源码查看）：

查看APK中classes.dex转化成出的jar文件；

1）解压：将后缀apk改成zip文件，解压之后找到【AndroidManifest.xml】文件，此时该文件为二进制文件，我们可以准备一个Java包，使用这个也可以将.xml文件解析成明文。

APK 的组成有 Dex 文件，资源，资源表和签名摘要信息等四部分组成，这四部分是不可或缺的，不然任何一个 OS都无法正常的运行你带 Activity 的 Android 应用。

用于保存 App 的签名和校验信息，以保证程序的完整性。当生成 APK 包时，系统会对包中的所有内容做一次校验，然后将结果保存在这里。而手机在安装这一 App 时还会对内容再做一次校验，并和 META-INF 中的值进行比较，以避免 APK 被恶意篡改。

存放我们各种资源文件的地方，有图片，字符串，动画，音频等，还有各种形式的XML文件

AndroidManifest.xml是Android应用的入口文件，它描述了package中暴露的组件（activities, services, 等等），他们各自的实现类，各种能被处理的数据和启动位置。除了能声明程序中的Activities, ContentProviders, Services, 和Intent Receivers,还能指定permissions和instrumentation（安全控制和测试）

•文件结构

• <manifest>元素

包名：package也代表着唯一的application ID，用来发布应用。

•<uses-< span="">permission> 元素：android限定了系统资源的使用，想网络设备、SD卡、录音设备等，如果希望应用去使用任何系统资源，都必须申请android的权限，这就是的作用。

格式：<user-permission android:name="string" <="" span="">

•元素：<application>此元素描述了应用的配置。这是一个必备的元素，它包含了很多子元素来描述应用的组件，它的属性影响到所有的子组件。许多属性（例如icon、label、permission、process、taskAffinity和allowTaskReparenting）都可以设置成默认值。

• <activity>元素：该元素声明一个实现应用可视化界面的 Activity（Activity类子类）。这是元素中必要的子元素。所有 Activity 都必须由清单文件中的元素表示。任何未在该处声明的 Activity 对系统都不可见，并且永远不会被执行。

• <intent-filter>元素：指明这个 activity 可以以什么样的意图（intent）启动

•uses-sdk 描述应用所需的版本

•SDK配置信息：常见的SDK大多都会在该文件中写入配置信息，如APPID，APPSECERT等信息

注：如果您需要更全面的学习AndroidManifest.xml 是每个文件的相关信息，可以通过网站学习

网址为：https://www.cnblogs.com/shujk/p/14961572.html

Android系统的可执行文件，包含应用程序的全部操作指令以及运行时数据；

在进行apk分析时，有时需要分析数据包，可是有些数据包已经被加了防护，例如修改了某个校验参数，导致该apk不能通过互联网工具进行解析，但是可以正常在手机安装打开，此时我们需要对apk文件进行手动分析，找到对抗点然后修复文件。

元芳近期在整理案件时，发现一个比较经典的案例，案件信息采集如下：

受害人momo的邮箱经常会收到工作邮件，所以都会点开进去看看，8月1日早上的时候momo顺手点了个邮件，邮件内容为抖音点赞兼职的广告，闲的没事就加了群，开始管理员会直接在群里派单，并且有其他用户晒到账截图，完成5单以后，群管理员让大家下载一个app，说后续的任务直接在app里完成，群里也再派单，momo出于好奇便下载了管理员推荐的app接任务，完成任务后，momo打算体现app上的奖励，一个客服弹窗提示要缴纳保证金才能进行提现，保证金从几十元到后来变成几百元、几千元，直到momo发现自己银行卡提示余额不足时才意识到自己被骗了，累计损失了1w元，于是报警，提交了线索。

元芳发现无糖浏览器的手机应用分析系统无法正常解析该APK文件，也无法使用apktool进行正常的分析工作，AndroidManifest.xml无法被解出，报错如下：

•通过搜索相关错误，推测AndroidManifest.xml可能被针对性

进行了加固处理，首先使用apktool导出AndroidManifest.xml，加上 -r 参数

在test目录中，可以找到AndroidManifest.xml文件，

可以使用在线的 https://hexed.it/进行查看，但是无法清晰查看AndroidManifest的结构，我们可以改用010editor进行查看。

1. 使用010editor

打开AndroidManifest.xml文件

2. 打开模板文件 AndroidManifest.bt ，

open template --> 选择第5步下载的 bt文件。

3. 运行模板文件

4. 运行结果如下

为了进一步分析AndroidManifest.xml是哪里出了问题，下载 AXMLPrinter2.jar 对AndroidManifest.xml文件进行分析，下载文件解压备用

1. 使用AXMLPrinter2打开

2. 发现报错如下

3. 这个报错的意思是程序希望读取到的是 0x80003，结果却读取到一个 0x80000，0x080003 即 08 00 03，AndroidManifest.xml  是小端模式，所以在文件里存储的应该是 03 00 08，而 03 00 08 00 是 一个正常的 AndroidManifest.xml 的 magic number（用来标记这个文件是一个 AndroidManifest.xml 的数字）。

所以，通过这个报错，我们可以知道目标 xml文件，将 magic number修改成了AXMLPrinter2 不认识的 00 00 08 00，正确的应该是 03 00 08 00。如下图所示：

恶意的xml文件

正常的xml文件

当我们遇到这种恶意修改参数时，我们可以进行三个修复步骤：

•修复1：使用 010editor 将 magic number  改为正常的 03 00 08 00

修复后再次运行AXMLPrinter2，发现依然报错。

NegativeArraySizeException，这个错误应该是指创建数组时，数组的大小使用了负数。说明目标xml可能还修改了其它位置，可以肉眼对比以下恶意的xml和正常的xml文件，是否还有不同。

stylePoolOffset 被修改

简洁界面展示模式，可方便用户快速的进行APK文件上传和最近分析文件记录的查看。

•修复2：使用010editor将scStylePoolOffset修复为 00 00 00 00

修复后，再次运行AXMLPrinter2，报出新的错误，说明上一个错误，正是由于scStylePoolOffset引起。

再修复以上两处后，发现依然无法正常解析，但是AXMLPrinter2的报错信息不明确，已经无法继续进行错误排查，为了更好的排查问题，我们使用nodejs自行编写脚本，尝试对AndroidManifest.xml里的字符串部分进行解析

•STRINGCHUNK解析说明

例如：我们想知道第一个字符串是什么？

1. 从scStringOffsets[0]，可以得到第一个字符串的相对位置（偏移），是 0

2. 那么第一个字符串的真实位置为 基准位置（scStringPoolOffset) + 相对位置 = 1392 + 0。

3. 由于还有一个文件头（8个长度），所以这个字符串在整个文件里的位置 = 真实位置+头长度 = 1392 + 8 = 1400 （16进制 = 0x578）

4. 所以我们到文件的 0x578处，可以查看对应的字符串。

STRINGCHUNK是用来存放androidmanifest.xml里所有用到的字符串的一块区域，紧跟在 header后面。

自行写编写脚本如下：

在解析stringchunk时发生错误，报错如下，说明在stringchunk部分存在问题：

首先，我们根据stringchunk的scStringCount显示，一共有2901个字符串（string）

但是使用js代码，读取索引等于341号的字符串时发生错误。使用010Editor查看索引等于341号的字符串位置。

可以看到这个字符串的位置位于文件的第7602181个偏移处，而整个文件的长度都只有10W字符长度，说明从341号索引开始的字符串，应该是无效的，也就是被恶意插入的。

所以可以推测出，实际字符串的个数，应该只有341个（索引 0 -> 索引 340）。

修复3：将scStringCount修改为 341

修改完成后，重新运行模板（快捷键：F5）！

运行模板完成后，再次查看 scStringOffset，可以看到，索引号最多到 340了

经过这3个修复之后，再次运行AXMLPrinter2，可以发现，不报错了，能够正常运行了，但是会输出一堆非预期的字符，将输出结果保存下来，

使用编辑器（例如vscode）打开result.txt，然后切换为GBK编码，结果如下图所示：

吃吗小伙子。。。。。吃！！！

通过查看以上result.txt，可以知道这里实际上是将xml里的 namespace名称（xmlns:），改成了一个超长的字符串，让xml看起来不可读。通常情况下，xmlns = android，那么解决方法也简单，我们只需要将xml里的这些“恶意”字符串全部替换为正常的android即可：

使用vscode编辑result.txt （编码选择GBK）进行正则替换：

最后可以看到xml回归正常：

如有疑问，可以扫描下方二维码，进入无糖学院。