首页 >> 大全

安卓逆向-入门笔记、相关知识点总结及思路

2023-07-27 大全 28 作者:考证青年

文章目录 3 、第一代加固 补充知识: 3.应用程序包分析 4.编译流程 5.1 加固5. 基于保护.dex 不被逆向的安全加固技术 二、https与http ADB(安卓调试桥)

安卓逆向思路:

总思路: app->dex->jar->java
1.对Android 应用程序的安装包Apk 文件进行解压缩,得到内部文件如图;
2.使用dex2jar 工具将解压后得到的classes.dex 文件逆向为.jar 包;
3.使用xmprinter 工具将AndroidManifest.XML 配置文件解密,使其可读;
4.使用 jd_gui这种 Java 反编译工具将②中得到的 jar包逆向为.java 代码文件。

1、查壳

检查程序是否有加固

2、未加固 2.1 工具

+ jadx 或者 ,,JD-GUI

2.2方法

使用:获取素材资源,.xml以及smali代码

使用jadx:把「.dex」转换为**.java**代码

3 、第一代加固 3.1 工具

安卓模拟器、文件管理器、开发者助手、XP框架、FDex2、ADB

3.2 方法

1、使用安卓模拟器充当已经root的手机

2、使用开发者助手查询app加固类型、分析软件布局等

3、使用XP框架作为hook工具

4、使用FDex2脱壳

5、使用ADB shell拉取文件

3.3 材料准备

安卓模拟器:mumu模拟器

文件管理器:MT管理器

XP框架:

FDex2:

adb shell:

网上找教程下载安装

3.4 实例

1、安装mumu模拟器

2、将 、FDex2、MT管理器和需要破解的软件安装在安卓模拟器上,并设置root权限.

3、安装、配置adb shell,使用adb 检测安装是否成功,是否可以连接到模拟器上(adb使用手册:#%E5%9F%BA%E6%9C%AC%E7%94%A8%E6%B3%95)

4、使用adb shell命令将需要破解的软件copy到模拟器文件内

5、配置环境

打开 -> 左上角 -> 模块 -> 勾选FDex2 -> 点击FDex2 -> 点击需要hook的软件(图一) -> 记录包名、输出目录 -> 后台回到主页

6、查壳

打开开发者助手,勾选悬浮窗、root、辅助服务选项,然后后台

打开需要脱壳的软件,进入程序化,点击开发者助手悬浮窗,查看加固

7、脱壳

打开需要破解的软件,进入几个页面,进行一些简单的交互,然后使用文件管理器进入dex输出目录,找到dex后缀文件(一般会输出好几个),对比脱壳后的dex文件与未脱壳的dex文件大小,相近的dex文件为实际的脱壳文件.

将源文件.dex文件删除,将脱壳后的文件重命名为.dex并移动到源文件夹内.

编译.xml文件,打开后修改程序入口,将A替换为B,并删除C部分代码.然后编译,退出.

删除加固相关文件

回退到apk文件目录、签名、打包.

7、加固检测

重新安装打包好的软件,使用开发者助手查看.

补充知识: 一、 1.加密原则:

由于Android 系统支持的应用格式主要以apk 形式存在,应用的主要逻辑实现在apk中的classes.dex 文件中,因此,对classes.dex 文件的保护是保护整个apk 安全的关键所在。

2.安全机制

Android 是建立在Linux 内核之上,并采用Dalvik 虚拟机(Android5.0之后变更为ART)作为应用程序运行环境的操作系统。

系统架构层安全机制

Linux内核

本地库及运行环境

内存管理单元

应用程序框架层

文件访问控制

虚拟机沙盒机制

强类型安全语言

移动设备安全

应用程序权限控制

签名机制

2.1内核级安全机制

由于Android是基于Linux内核的,所以也继承了Linux内核的安全机制。在Android内核级主要的安全机制包括可一直操作系统接口用户(POSIX USER)和文件访问控制。这些机制的基本元素是用户及其拥有的对象,用户再进一步分配到用户组。另外,内存控制机制也一定程度上保证了Android的运行安全。

2.2运行环境级安全机制

安卓程序运行在Dalvik虚拟机(Android5.0之后变更为ART)上.并且每一个应用程序都运行在一个独立的虚拟机上。但是不同于其他虚拟机,如JVM和.NET Runtime作为安全边界有着隔离代码的作用,由于底层Android内核已经实现了沙箱机制,所以Dalvik虚拟机并不作为隔离代码的安全边界。所有应用程序都能运行本地代码,并且均使用相同的安全等级运行在沙盒中。所以在系统运行库Android主要采取强制安全类型来加固Android的系统安全。强制类型安全机制通过赋值变量时强制检查声明类型与值是否符合,从而保证变量不被错误地使用。安卓使用java编译器来做数据类型检查,避免类型转换错误或缺少边界检查而造成的缓冲区溢出攻击.

2.3 应用程序框架级安全机制

使用数字签名保证Android系统安全.
安卓应用程序会被打包成.apk,在程序安装前会对文件做数字校验,检查这些文件是否被篡改.
Android签名文件包含以下几个要点:
1、Android系统只会安装带有有效数字签名的应用程序,禁止安装任何未签名的应用程序。
2、Android应用程序是可以自签名的,不需要权威机构的认证。
3、数字签名是有时限的,但只有在安装应用时Android系统才会检测数字签名是否过期,一旦安装成功,系统将不再关注数字签名是否过期。Android应用程序安全的核心在于权限控制。它用于限制应用程序的访问系统的API和资源。应用程序必须在权限内运行,而不能访问权限外的任何资源。

3.应用程序包分析 3.1. .dex(重要)

Java 源码被编译后生成的 虚拟机字节码文件,通过dx工具转化为虚拟机识别的执行文件

3.2. lib

lib 下的子目录 存放的是 so 文件,应用若使用 JNI调用 C/C++动态库,则需要将被调用的so 文件放到该目录下。

3.3. .xml(重要)

程序的全局配置文件。此文件在每个应用中都必须被定义和包含,它描述了应用的名称、开放权限、引用的库文件、版本号等重要信息。

3.4. .arsc

经过编译的二进制资源文件,记录资源文件和资源id的映射。

3.5. res

res 目录是存放资源文件的,包括程序使用的布局文件、图片和字符串常量等。会在R文件中生成索引ID.

3.6. META-INF

META-INF 目录下保存的则是应用中的签名信息,签名信息可以一定程度上验证原始apk 的完整性。

3.7.

存放的原生(静态)资源文件(比如so库,HTML资源等原生资源),不为/下的文件生成ID。如果使用/下的文件,需要指定文件的路径和文件名。

4.编译流程 4.1 资源文件处理(AAPT)

会原封不动打包在APK中;

res中每一个资源会赋予资源ID,以常量形式定义在R.java中,生成一个.arsc文件(资源索引表)

4.2 aidl文件

将aidl后缀的文件转换为可用于进程通信的C/S端Java代码。

4.3 Code

编译生成.class文件。

4.4 代码混淆

增加反编译难度,命名缩短为1-2个字母的名字,压缩(移除无效类、属性、方法等),优化移除没用的结构。

4.5 转换为dex

把所有claas文件转换为.dex文件,class -> 字节码,生成常量池,消除冗余数据等。(方法数超65535会生成多个dex文件)

4.6 打包

把.arsc、.dex、其他的资源一块打包生成未签名apk。

4.7 签名

对未签名apk进行debug或签名。

4.8 对齐优化

使apk中所有资源文件距离文件起始偏移为4字节的整数倍,从而在通过内存映射访问apk文件时会更快

5.1 加固

第一代:动态加载

第二代:内存不落地加载

第三代:指令抽取

第四代:指令转换

第五代:虚拟保护

5. 基于保护.dex 不被逆向的安全加固技术 5.1 .dex 工作原理

在 源码中(不同版本的源码,可能目录不一样), 虚拟机的实现位于/目录下,其中/vm 是虚拟机的实现部分,将会编译成 .so;而 / 将会编译成 .a静态库作为 dex 工具;/ 是.dex 文件的反编译工具;虚拟机的可执行程序位于/ 中,将会编译成 可执行文件。

平台应用程序在运行时,首先由 虚拟机加载解包后的.dex 文件,然后 虚拟机会从中读取指令和数据,进而运行该应用的程序逻辑。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img--22)(反编译心得./image-.png)]

5.2加固方案 .dex壳:它是用于 程序运行时被 虚拟机加载的 dex 文件,里面不再包含 程序的功能代码;.XML:它将原.XML 中的入口替换为新入口;.dex:它是原.dex 经过白盒加密后的文件,包含了程序的主要功能代码,也是重点保护对象;.so:.so 是用于解密 .dex 的 so 文件,为了确保解密方法不被泄露,将.so 文件再加密一层为.so。Entry.so:程序启动后的入口so 文件,用于调用.so 来解密.dex。

5.3实现流程

为实现保护源程序.dex 文件的安全性,用白盒算法对.dex 文件进行加密,并自定义一个新的.dex 文件。 虚拟机在将应用加载到内存中时,首先加载 .dex,.dex将对原 .dex 文件进行解密和完整性检查,再将原.dex 文件加载至内存并运行,最后将解密后的.dex 文件从本地物理存储空间中删除,从而保证了.dex 文件的安全加载,并且防止.dex 文件被篡改。由于程序的运行逻辑仍然为原.dex 文件中的实现,所以保证了应用的功能不受影响。具体调用逻辑如下:

关于我们

最火推荐

小编推荐

联系我们


版权声明:本站内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 88@qq.com 举报,一经查实,本站将立刻删除。备案号:桂ICP备2021009421号
Powered By Z-BlogPHP.
复制成功
微信号:
我知道了