小柏实战学习安卓图文教程-第六课-识别加固2

本节课主题:现在所有的app都有加壳,所以我们先识别壳,通过Android Killer 和 手动分析;

 

 防止太多太乱,所以开始之前,我们回顾一下截止到上节课我们现在的已知信息有哪些?

 

根据我们截至目前的所有分析（包括目录结构、工具扫描、在线报告），以下是关于 CrackMe.apk​ 的完整已知信息汇总：

📁 已知信息总览

信息维度

具体内容与分析结论

1. 文件属性​

- 文件名：CrackMe.apk
- 大小：46.5 MB
- 哈希：fbb9c5...a0a7(可唯一标识此文件)
- 在线检测：65家中6家报毒，低检出率证实其为合法的CrackMe/学习样本，报毒原因为其保护技术触发误报。

2. 核心结构​

- 类型：典型的“双APK外壳”​ 加固应用。
- 外壳：CrackMe.apk自身，是一个精简的加载器。
- 内核：assets/目录下包含：
- main.apk(主应用模块，猜测被加密)
- proxy.apk(代理/通信模块，猜测被加密)
- script.lr(加密的Lua业务脚本)
- eng.traineddata(Tesseract OCR引擎数据)

3. 保护机制​

- 原生保护库：lib/<架构>/目录下的 libsc16.so, libsc17.so, libsc18.so, libsc19.so。文件极小，推测为保护壳的加载器或桩模块，核心逻辑可能动态加载。
- 反逆向措施：具备商业加固的常见特征（代码加密、动态加载、反调试潜力）。

4. 功能组件​

- 图像识别引擎：包含完整的OpenCV库 (libopencv_java.so) 和专用OCR库 (libocapi.so)，表明核心验证逻辑极大概率与图像识别、二维码、文字扫描有关。
- 脚本引擎：包含Lua网络库 (luasocket)，业务逻辑由加密的Lua脚本 (script.lr) 驱动，支持热更新或灵活配置。
- 多架构支持：同时提供 armeabi-v7a(真机) 和 x86(模拟器) 库，便于分析。

5. 静态分析结果​

- 工具扫描：使用Detect It Easy (DiE) 确认了 assets/proxy.apk的嵌套结构。
- 清单文件：外层的 AndroidManifest.xml为二进制格式，需使用 Apktool等工具反编译才能阅读，其中包含真正的应用入口信息。

6. 当前进度​

- 已完成：样本获取、查壳、目录结构分析、在线检测。
- 已准备：Rooted的雷电模拟器、Frida环境(准备中)。
- 卡点：assets/下的关键文件 (main.apk, proxy.apk, script.lr) 均为加密状态，无法直接静态解压或分析。

 

一、手动分析方法(上节课说过了,本节课在补充一些)

当工具无法识别或需要确认时，手动分析是最可靠的方法。

操作步骤

  1. 修改文件后缀：

    target.apk -> target.zip

  2. 解压文件：

    target.zip -> target_dir

  3. 检查lib目录：

    target_dir/lib
# 查看各架构目录下的.so文件

常见加固特征文件

加固厂商

特征文件/目录

其他特征

腾讯加固​

libmain.so
libshell.so

assets/tosversion
assets/0ooo0

360加固​

libprotectClass.so
libjiagu.so

assets/libjiagu.so
assets/libjiagu_x86.so

梆梆加固​

libsecexe.so
libsecmain.so

assets/mock.dex

爱加密​

libexec.so
libexecmain.so

assets/ijiami.dat

网易易盾​

libnqshield.so

lib/armeabi/libnqshield.so

阿里聚安全​

libmobisec.so

lib/armeabi/libmobisec.so

Apktool官网下载:https://connortumbleson.com/2025/07/06/apktool-v2-12-0-released/

网盘链接：https://pan.quark.cn/s/3bf68293aec3

 

1.下载apktool jar 包

image

2.创建一个apktool 的目录,把样本文件apk放进去,再把apktool_2.12.1.jar放进去,最后当前目录右键打开cmd,执行以下命令:

java -jar apktool_2.12.1.jar d CrackMe.apk

image

 

3.这条命令会在当前目录生成一个名为 CrackMe的文件夹，里面就是反编译出的所有资源、AndroidManifest.xml（已解码为可读的XML）和 smali代码。

进入CrackMe的文件夹,查看解码后的 AndroidManifest.xml吧！这是我们分析其入口和组件的关键一步。

image

image

4.检查并分析AndroidManifest.xml

这份反编译出来的 AndroidManifest.xml信息量非常丰富，它清晰地描绘了这个应用的核心架构和行为权限。下面我们来逐层解析。

这个应用 (com.liushi.nz) 是一个具备系统级操作能力的复杂工具，其设计远超普通应用。

分析维度

关键发现

说明与潜在影响

应用身份​

包名：com.liushi.nz

应用的唯一标识。

核心入口​

主入口：SplashActivity(LAUNCHER)

用户点击图标后第一个看到的界面。
 

主界面：MainActivity(launchMode="singleTask")

应用的主要功能界面，设置为单个实例。

后台服务​

主服务：MainService(导出)

常驻后台，处理核心逻辑。
 

下载服务：DownloadService(导出)

负责文件下载功能。
 

无障碍服务：AssistService(BIND_ACCESSIBILITY_SERVICE)

用于模拟用户操作（如点击、手势），自动化任务核心。
 

输入法服务：InputText(BIND_INPUT_METHOD)

可将自身设置为输入法，具有监听输入的能力。

特殊组件​

开机自启：RebootReceiver监听 BOOT_COMPLETED

设备启动完成后自动运行应用或服务。
 

文件共享：FileProvider

安全地与其他应用共享文件。
 

动态代码加载：DexClassLoaderProviderService(by Tencent)

可能用于动态加载插件或更新，常见于热修复方案。

关键权限​

高敏感权限：SYSTEM_ALERT_WINDOW (悬浮窗), REQUEST_IGNORE_BATTERY_OPTIMIZATIONS (忽略电池优化), KILL_BACKGROUND_PROCESSES (结束后台进程)

这些是系统级权限，通常需要用户手动授权。获取后应用能力极强。
 

隐私相关权限：READ_SMS, SEND_SMS, CALL_PHONE, RECORD_AUDIO, READ_CONTACTS, ACCESS_FINE_LOCATION

涉及用户敏感数据，需高度关注其使用目的。
 

存储与网络权限：INTERNET, READ/WRITE_EXTERNAL_STORAGE, REQUEST_INSTALL_PACKAGES

基础功能所需，允许网络访问、读写存储和安装应用。

关键组件深度解析

  • SplashActivity：这是用户启动应用时看到的第一个界面，通常负责初始化工作或展示启动图。

  • RebootReceiver：这个组件监听系统启动完成的广播 (BOOT_COMPLETED)，意味着应用可以在设备重启后自动运行，旨在保持长期活跃。

  • AssistService：这是实现自动化操作（如模拟点击、手势）的核心，通常需要用户手动在系统“无障碍”设置中开启。它的存在表明这个应用可能用于自动化脚本、游戏辅助或辅助功能工具。

  • InputText：此服务声明了输入法功能，意味着应用可以获取输入焦点和文本内容，能力很强，需谨慎对待。

权限安全评估

此应用申请的权限数量多、级别高，特别是SYSTEM_ALERT_WINDOW（悬浮窗）和BIND_ACCESSIVITY_SERVICE（无障碍服务），这些权限一旦被滥用，风险很高。结合其组件功能看，它确实需要这些权限来实现系统工具类应用的功能（如自动化、后台保活、界面覆盖等）。然而，从安全角度看：

  • 权限与功能基本匹配：申请的权限与其声明的组件功能是相符的，并非无端索取。

分析完成之后,我们就知道这个app是干嘛的了: 一个文字识别和图像识别后模拟用户操作的外挂软件; (话说这结论不如直接雷电模拟器安装app看一眼)

这个 AndroidManifest.xml揭示了一个功能全面、系统集成度很高的 Android 应用。它不仅仅是一个简单的工具，而是一个旨在深度集成到系统中、拥有广泛权限和强大后台能力的应用。

 

apktool 总结:

优点：无需安装，立即使用。

缺点：每次都要输入完整的 java -jar apktool_2.12.1.jar，且必须在jar文件所在目录操作。 (你也可以配置环境变量,和java的配置差不多,直接path里面添加这个目录就行了)

 

 

二、Android Killer内置查壳(简单的图形画面操作更加适合新手,不用像上面要进行黑窗口命令行)

链接: 上面的网盘链接里面就有了

1.下载后放到虚拟机中解压

image

2.双击打开.exe

image

image

4.工具 -> apk查壳 ->选择样本文件 -> 打开

image

哈哈,正常没啥用

image

再试试反编译,

image

哦哦,报错了,他说编译失败,报错信息看了一下,可能是apktool太老了,我们换成新的apktool

image

 Android -> apktool管理器 -> 添加 -> 路径 -> 选择下载的最新的组件 -> 改个名称 -> 确定

image

image

image

 默认版本换成刚刚的新的

image

右键这个页签

image

 关闭

image

重新打开 -> 确定

image

分析工程 -> 是

image

 分析结果如下图: (看看是不是和上面我们手动分析的一样)

image

图形化工具就是简单呀,左侧看不懂的,可以鼠标悬浮在上面,会给你解释这个是干什么的 这样就可以和上面的分析结论交叉验证了:

这个APK看起来是一个功能非常“典型”的辅助工具。详细分析如下：

📱 基本信息概览

  • 应用名称：球球英雄脚本 (名字已暗示其用途)

  • 包名：com.liushi.nz

  • 入口Activity：com.nx.main.activity.SplashActivity(标准启动页)

  • SDK信息：TargetSDK: 28(适配到Android 9)

🔍 关键组件与风险分析

工程信息中暴露了几个关键组件，揭示了其核心工作机制：

  1. 动态加载与加固/热更新特征

    • ProxyActivity (com.nx.sdk.ProxyActivity)：这是一个非常明显的信号。这类Activity通常用于动态加载或作为加固壳的代理入口。真正的业务逻辑可能被加密或隐藏在资产（assets）文件中，运行时才被加载。

    • Tencent X5内核服务 (com.tencent.smtt.export.external.DexClassLoaderProvider)：这明确集成了腾讯TBS X5 WebView内核。该内核除了用于增强网页渲染，其DexClassLoaderProvider服务也常被用于热更新或动态加载dex文件。这进一步佐证了应用存在动态代码加载行为。

  2. 自动化脚本核心服务

    • AssistService (com.nx.assists.AssistService)：“辅助服务”，这是实现自动化操作（如模拟点击、手势）的核心后台服务。

    • InputText服务：顾名思义，很可能用于模拟文本输入。

    • MainService：主后台服务，负责协调脚本运行、保活等。

  3. 自启动与保活机制

    • RebootReceiver (com.nx.main.service.RebootReceiver)：监听系统启动完成广播，实现开机自启，确保脚本常驻。

    • DownloadService：可能用于静默下载更新脚本或配置。

⚠️ 敏感权限解读

申请的关键权限组合，完美匹配了其“前台辅助脚本”的定位：

权限

用途分析

SYSTEM_ALERT_WINDOW​ (悬浮窗)

核心权限。用于在其他应用上层绘制控制界面、显示模拟点击的“手指”图标，或进行无障碍辅助。

REQUEST_IGNORE_BATTERY_OPTIMIZATIONS​ (忽略电池优化)

防止系统在省电模式下杀死后台服务，是保活关键。

RECEIVE_BOOT_COMPLETED​ (开机启动)

配合RebootReceiver，实现开机自启。

WRITE_EXTERNAL_STORAGE​ (写存储)

可能用于下载脚本、写入日志或配置文件。

📊 综合评估与逆向建议

性质判断：这极有可能是一个需要动态加载核心代码、以前台辅助服务形式运行的游戏自动化脚本（外挂）。

逆向分析建议：

  1. 重点目标：详细分析 AssistService、InputText服务及 ProxyActivity的逻辑。

  2. 寻找载荷：在 assets或 lib目录下查找可能加密的dex、jar或配置文件，这些可能是真正的脚本逻辑。

  3. 动态调试：由于存在动态加载，静态分析反编译的代码可能不够。我们肯定需要动态调试（如Frida, Xposed）来跟踪运行时加载的类和方法了。

  4. 注意X5内核：尝试了解TBS X5内核的Dex加载机制，这样可能有助于我们找到热更新的代码存储位置。

 

核心结论：Android Killer 的结果证明了什么？

Android Killer 成功地反编译了 CrackMe.apk这个“外壳”，但它没有、也不可能得到我们真正想要的核心代码。这完全符合预期：

  1. 它反编译了什么？​ 外壳的 classes.dex（很小），生成了外壳的 smali代码。我们在“工程信息”里看到的 Activity、Service列表，就是我们在 AndroidManifest.xml里分析过的那些外壳的组件。

  2. 为什么 dex2jar 失败了？​ 错误日志 Detail Error Information in File .\classes-error.zip是典型特征。因为外壳的 classes.dex可能被故意破坏、结构异常，或者其逻辑极度精简（主要就是用来加载解密库 libsc*.so和 assets/里的加密文件），导致 dex2jar这个将DEX转为JAR的工具无法正常处理。这个失败本身就是一个强烈的信号：核心逻辑不在这里。

  3. 最重要的验证：在工程目录里（projects/CrackMe/），我们绝对找不到 assets/main.apk或 assets/proxy.apk对应的解密后的代码。它们仍然以加密的二进制文件形式存在。

所以，Android Killer 的运行结果不是一个“终点”，而是一个关键的“路标”。它告诉我们：“静态反编译此外壳，此路不通。请使用动态方法。”

 

Android Killer小结:

使用方法

  1. 使用Android Killer打开APK

  2. 在工程信息窗口查看加固信息

  3. 或使用菜单"工具"→"查壳工具"

适合场景

  • 已经在使用Android Killer进行逆向

  • 需要快速判断是否加固

  • 一体化工作流程

 

其实做到这里就已经知道了,现在应该立刻停止在静态分析上花费更多时间，完全转向我们的 动态脱壳​ 作战计划

但是毕竟是教程类的,所以接下来还有一节课的静态分析,

不过下面我还是可以放出实际的动态脱壳计划

🚀 明确的后续攻击路径

所有前期侦察已完成，结论高度一致：必须进行动态脱壳。下一步的选择非常清晰：

路径

操作

目标

A. 通用动态脱壳​

在模拟器中运行APP，直接使用 frida-dexdump -U -a或附加进程。

尝试自动化工具能否直接 dump 出内存中的DEX。如果成功，最省力。

B. 针对性Hook​

编写Frida脚本，Hook libsc*.so的 JNI_OnLoad或导出函数。

监控壳的解密流程，在内存中精准定位并导出解密后的 main.apk和 script.lr数据块。

C. 静态逆向辅助​

用IDA Pro/Ghidra静态分析 libsc16.so(x86版)，寻找解密算法和密钥线索。

为动态Hook提供精准的函数名、偏移地址或密钥信息，提高成功率。

 

posted on 2026-01-09 14:41  shaun88  阅读(75)  评论(0)    收藏  举报

导航