网络安全攻防实录：从应用安全技术演进看对抗与挖掘，从零基础到精通，收藏这篇就够了

最新推荐文章于 2025-04-29 16:01:50 发布

程序员肉肉

最新推荐文章于 2025-04-29 16:01:50 发布

阅读量1.1k

点赞数 26

文章标签：安全 web安全 xss 前端面试

本文链接：https://blog.csdn.net/yy1715713348/article/details/147472335

版权

应用安全的核心：成本与平衡的艺术

应用安全，说白了，就是一场旷日持久的“猫鼠游戏”。无论平台如何更迭，工具如何进化，目标始终如一：防逆向。但别天真了，理论上讲，只要时间和资源足够，任何软件都难逃被破解的命运。所以，安全的核心不在于绝对防御，而在于尽可能提高逆向成本。更重要的是，安全不能凌驾于产品之上，它必须服务于产品需求。因此，应用安全的核心，就是在满足产品需求的前提下，将逆向成本抬高到让攻击者望而却步的地步。这，就是一场成本与收益的博弈，一种微妙的平衡。

应用安全技术：逆向工程的“副产品”

应用安全技术的诞生，根本就是逆向工程“逼”出来的。当一个平台上出现了一套成熟的逆向工具和方法论，能够完成平台系统的基础逆向工作，并开始专注于对应用本身进行逆向时，安全产品自然应运而生。换句话说，安全是逆向工程发展到一定规模后的必然产物。

解码逆向工程的进化之路

各平台逆向工具“兵器谱”

Android 逆向：
- apktool: APK 文件反编译的瑞士军刀。
- smali: DEX 文件的精细化反编译利器。
- IDA: SO 文件的静态分析神器。
- 调试？Android Studio 的 smali 插件配合 AS 调试模块，或者 IDA、GDB、LLDB，各显神通！
- Linux & Windows 逆向：
- IDA, OD, Ghidra: 静态分析三剑客，动态调试也不在话下。
- Unity 逆向： (老兵不死，只是逐渐凋零…)
- 当年 C# 反编译工具横行一时，现在 IL2CPP 大行其道，本地调试才是王道。C# 专属调试工具？或许有，但我已经 Out 了。
- 前端 JS 逆向：
- 明文代码，无需反编译，浏览器调试工具足矣。
- 结论？各平台逆向工具已经就位，只待我们挥舞利刃，解剖应用。

应用：系统功能的“寄生插件”？

对用户而言，应用不过是一个安装后运行的文件。但从系统的角度看，应用就是一个“插件”，一个系统功能的扩展。它依赖于操作系统提供的接口，实现各种功能。应用本质上就是寄生于操作系统的功能模块。

编译器的“蜜语”与逆向的“解密”

应用之所以能运行，是因为它经过了特定编译器（或编译集成平台）的编译。编译器就像系统和应用之间的“翻译官”，将人类可读的代码转换成系统可执行的指令。编译器与系统平台一一对应，形成了一套约定俗成的转化规则。而逆向，就是将这个过程反过来，通过反编译工具将代码“翻译”回人类可读的形式。反编译工具，就是逆向工程的基石。开发工具集成度高，编译过程简单；逆向工具则往往分散且不完善，需要手工操作，踩坑无数。

逆向工具：开源的“草莽英雄”与官方的“正规军”

开发工具背后，是官方、社区、大公司等“正规军”的支持，工具完善，Bug 修复及时，解决方案也更可靠。而逆向工具，则往往由开源项目驱动，由技术大佬单枪匹马打造。工具本身可能存在 Bug，解决方案也可能不够全面，更新也不及时。所以，逆向工程师必须具备独立解决问题的能力。逆向，注定是一场孤独的战斗。

应用文件格式：逆向工程的“藏宝图”
- 应用文件是应用的载体，包含了代码、变量、配置文件等信息。Android 的 APK 文件，Linux 的 ELF 文件，Windows 的 PE 文件，Dalvik 的 DEX 文件，都有其特定的格式。前端 JS、PHP 等脚本语言，虽然是文本格式，但同样遵循一定的规范。文件格式解析是逆向工程静态分析的基础。apktool 解析 AXML、DEX 文件，readelf 解析 ELF 文件，IDA 则支持多种文件格式。
- 代码还原：从字节码到源代码的“时光倒流”
- 将文件格式解析出来的数据内容还原成开发源码，包括反编译和反汇编。静态编译型语言存储的是字节码，需要先反编译，再反汇编。C、C++、Java 等编译的程序，都需要先解析成汇编，再还原成源码。反编译相对简单，对照手册即可。反汇编则不然，特别是对于经过人工编写或主动对抗的代码，还原程度往往不高。编译器编译出来的代码符合一定的规则，IDA 等反编译工具会针对不同的编译器采用不同的还原策略。
- 平台安全架构：突破“铜墙铁壁”
- 为了保证应用的安全性，应用平台通常会采取一些系统安全措施。想要侵入应用进程，进行动态观测，读取修改内容，就必须绕过这些安全机制。例如，Android、iOS 的签名问题，iOS 调试需要修改配置，Android 上 Java 调试需要 Root 或修改配置。还有 SELinux、MAC 等安全机制，都需要不断学习和兼容。
- 应用底层运行环境：深入“敌后”
- 逆向工程不仅要分析文件，还要在应用动态执行时对其进行观察，而且越细致越好。调试系统和进程注入是两种常用的手段。调试系统由平台提供 API 或工具，效果好，但容易被检测和对抗。进程注入方法多样，不易被检测，但颗粒度不够细。
- 应用文件加载：追踪内存中的“幽灵”
- 应用运行后，系统会将文件加载到内存中，加载方式可能会改变内存分布。为了观测应用进程，我们需要了解应用加载到内存中的分布，并对其进行解析和使用。IDA 附加进程后，会解析加载的所有 SO 文件，查看符号、函数和内存分布。
- 运行系统架构：理解 CPU 的“语言”
- CPU 代码执行，Android Dalvik 指令执行，都是逆向分析中不可避免的内容。我们需要熟悉指令，了解架构体系。例如，ARM 三级流水线，如果不了解，就无法理解代码的执行流程。
- 模块/库管理：加速分析的“导航仪”
- 模块/库管理系统可以加速分析过程，快速了解应用使用的库，并对照开源项目或系统库说明，提高分析效率。Android Native 的 SOLIST，Java 层的类加载器等，都可以通过特定的 API 或函数对接库管理系统。
- 应用语言底层运行环境：超越“汇编”
- 对接开发语言所运行的环境，而不仅仅是底层系统语言。例如，逆向 SO 文件时，目标语言是汇编，但我们可以用 C 语言环境对接，使用 C 语言的变量和函数。更进一步，可以用 C++ 对接，获取 C++ 对象的地址，导出函数成员的函数符号，完成 C++ 对象的成员函数调用。Unity 游戏经过 IL2CPP 保护后，代码全部变成 Native，但理论上仍然可以通过 Frida 等工具解析 Unity 对象和类，并直接调用。

应用安全保护：一场永无止境的军备竞赛

应用加固：静态分析的“绊脚石”

应用加固的出现，源于静态应用文件分析工具的普及。既然逆向分析已成规模，加固公司自然要宣扬应用文件的不安全性。应用加固主要分为文件格式加固和文件内容加固。

文件格式加固：争取“时间差”
- 针对静态存储的文件，即使在运行后也不会改变。包括 ZIP 加密（需要密码才能打开），AXML 加密等。这类技术往往不能长时间奏效，主要利用逆向解析工具的 Bug 和文件解析漏洞来阻止逆向程序工作。由于文件内容是静态的，会被内存 Dump，因此这类文件没必要保护文件内容。
- 文件内容加固：静态与动态的双重“迷雾”
- 当无法阻止应用文件被逆向时，就需要对文件内容进行加固。就像 HTTP 协议通讯一定会被拦截一样，才有了 HTTPS 对通讯内容加密。目前的文件内容加固需要同时针对静态分析和动态 Dump。在静态分析时，让攻击者无法找到正确的文件内容。但在动态运行时，这部分内容始终要解密出来，要加载要运行，很多 Dump 工具都是这个原理。因此，对于动态运行的对抗方式就是在运行起来以后，自定义加载方式，不依赖于系统 API，让 Dump 无处下手。VMP，添加代码转化器，提高逆向难度。想要找到真正的代码，必须先逆向 VMP 框架。代码混淆，即使找到了真正的文件内容，也难以理解代码的逻辑，无法使用。

运行对抗：动态世界的“攻防战”

对于经过加固的应用，脱壳的主要方法就是运行时内存 Dump（静态还原也是可能的，不过难度太高，基本不用）。还有风控、设备指纹、用户画像等等，也是在运行时动态计算。由于逆向工程可以突破应用或系统的安全，安全公司针对这方面进行了防护。

特征检测：识别“入侵者”
- 运行对抗主要是检测是否被攻击，无法进行防御。Android 上主动 Ptrace 自己，兼容性差不说，对于从 Zygote 注入的没有任何防御办法。PC 也是一样，比如可以修改系统等方式来完成攻击。因此，运行对抗主要在于检测，而这种检测对抗，其实完全是一种特征对抗。例如，Ptrace 的检测现在有很多种，我们可以说它是通用特征检测。像 Frida、Xposed 这些，我们可以进行专用特征检测，比如 SO 库名字、类名、符号、字符串、里面包含的库。只要开源了，基本都能被防御。
- 捕获能力：追踪“隐形人”
- 上面的特征检测主要针对开源项目和系统共用特征。但有很多逆向工具并不是开源的，这时特征检测就会失效，无法进行安全处理。这时就需要进行捕获，首先确定是否真的被攻击了，然后通过查看内存分布、系统库等情况，找到逆向工具并 Dump。这主要需要通用特征的检测点位足够多，并且和专用特征的系统完全分开，最好洒下鱼饵，就像 Web 的蜜罐一样。
- 自杀能力：壮士断腕，及时止损
- 操作系统本身拥有调试功能和故障反馈，甚至还有内存转储。在检测到已经被攻击后，势必要阻止程序继续运行。有自杀退出进程的，有卡死的，有无法联网的，有风控对抗的，很多种。但阻止进程运行的手段一点不能触发系统的反馈功能。例如，自杀退出进程，经常会有大量堆栈返回，直接暴露代码位置。卡死的，单线程退出的，在调试的时候，极容易被定位到现场位置，把现场暂停掉。还有风控对砍，功能确实无法使用，但客户端本身是可以被主动调用的，再次调用进行分析，问题多多，需要慎重。

代码分析对抗：让代码“面目全非”

无论做了多少保护，最终程序还是有可能被脱壳，或者在运行时找到真正的代码所在。而安全对抗的手段就是对代码进行混淆、修改，使其在不改变原功能的基础上，变得难以理解、难以调试、难以还原。

反编译对抗：混淆“视听”
- 将一段二进制反编译成汇编，叫做反编译，很简单。但这个简单是有前提的，比如如何分辨数据和指令，如何确定代码地址（X86 架构忘得差不多了，不透的架构有不同的反编译问题）。IDA 能够做到反编译成功的原因是这些其实都是没有反编译对抗的。比如我自己写个汇编，我把指令当数据，代码的执行顺序我用 ROP 这种漏洞利用代码片段的方式，即使你反编译出来，实际的执行结果也是不同的。所以反编译是建立在程序符合一定的标准上的。国外有个开源项目，可以将二进制程序转变成汇编文件输出，还可以编译汇编文件，也是建立在这个基础上。
- 反汇编对抗：扰乱“逻辑”
- 将汇编函数还原成源代码，这个跟反编译的思路是一样的。还原的基础建立在一定规则和标准上。比如，用汇编写裸函数，不符合 C 函数调用规则，函数举例长，函数和函数中间插入一个别的函数，都有可能造成无法分析。目前见过有的公司写了一套全局跳转汇编，将函数的顺序调用变成了通过参数调用全局跳转表，然后调用目标函数，估计还是用 LLVM 写的。
- 混淆：让代码“雾里看花”
- 目前这种方案很流行，主要原因是 LLVM 解决了大部分底层问题，可以更简单地开发一个混淆编译器。混淆在 PC 上的时候就有了，但是当时我学艺不精，不知道到底是手工搞得，还是批量插入的，没有深入分析过。目前很多混淆方案都是基于 LLVM，但目前开源的这些混淆方式和我逆向中遇到的一些我认为都不太完善，它确实对于代码进行了改变，但是通过人工分析加代码优化是可以去除的，主要问题是，无法真正地融入源代码中。比如 OLLVM，虽然 MIASM 早年公布的一种还原 OLLVM 的方法不够通用，对于定制化的 OLLVM 无法还原，但是通过符号执行 + 静态代码分析的一些技术是可以对这种混淆方式进行通用还原的。我不知道是否真的有完美的混淆技术，但是如果能真正地融入代码中，和代码有所交互，保护效果会更好。
- VMP：逆向工程的“噩梦”？
- 网上说 VMP 也是混淆的一种。VMP 在逆向中，好像就是不可逆向的代名词。遇到 VMP，就可以知难而退了。目前我也有幸遇到几个 VMP，运气很好，难度都不算太高，而且还原了。对于 VMP 的逆向，需要首先对它的框架进行逆向，如果这部分完不成，基本毫无产出，这也是难点所在，很多人都是倒在这一步了。当对于框架结构完全逆向出来以后，就需要对于指令进行逆向，知道那些指令替换翻译成了什么，然后就可以还原了。所以 VMP 保护问题其实全在框架上，不要以为 VMP 就安全，如果没有对于 VMP 框架进行保护会降低分析难度。
- 动态分析运行对抗（指令 Trace）：追踪代码的“足迹”
- 在进行程序分析的时候，动态运行然后通过环境、结果进行代码分析的效果更好。目前我所知道的，Frida 的指令 Trace，调试器的指令 Trace，Unicorn (Unidbg) 的指令 Trace，还有一个是有个朋友告诉我的网上大神写的虚拟 VM 项目（外部人员不懂，也不会用），其中 Unidbg 效果是最好的，但是需要解决环境问题，Frida 这个没怎么用，调试器这个如果不遇到对抗效果也很好但是非常慢。IDA 的 Trace，很容易崩溃，很不稳定。单独写这个的原因是逆向分析中，这种动态运行分析还是占大头的，而且指令 Trace 分析 VMP，分析算法，效果非常好。甚至可以搞一个指令 Trace + 数据分析的软件，专门来进行代码分析。目前对于 Trace 的对抗我只研究了调试 Trace 对砍，Unidbg 和别的还需要尝试。这种对抗方式主要还是在指令上，有些指令是存在特殊问题的，比如调试的时候代码会执行不过去，Trace 直接卡死，或者使用批量读写指令对于当前运行的内存段进行 Copy 在运行，这种情况下是可以检测到断点的。别的方法记不住了。
```