1.Obfuscator-llvm源码分析
2.教程 iOS混淆加固原理篇
3.逆向入门cocos2d游戏逆向分析
4.代码混淆不再愁：一篇掌握核心技巧
5.IDA F5 增强插件，译源源码还我源代码（一）
6.[Dev] Xcode的分析记录

Obfuscator-llvm源码分析

       在逆向分析中，Obfuscator-llvm是译源源码一个备受关注的工具，它通过混淆前端语言生成的分析中间代码来增强SO文件的安全性。本文主要讲解了Obfuscator-llvm的译源源码三个核心pass——BogusControlFlow、Flattening和Instruction Substitution，分析金牛狙击指标源码它们在O-llvm-3.6.1版本中的译源源码实现。

       BogusControlFlow通过添加虚假控制流和垃圾指令来混淆函数，分析其runOnFunction函数会检查特定参数，译源源码如混淆次数和基本块混淆概率。分析在测试代码中，译源源码它会将基本块一分为二，分析插入随机指令，译源源码形成条件跳转，分析如“1.0 == 1.0”条件下的译源源码真跳转和假跳转。

       Flattening通过添加switch-case语句使函数结构扁平化，runOnFunction会检查启动标志。在示例代码中，它将基本块分隔，创建switch结构，并根据随机值跳转到不同case，使函数执行流程变得复杂。

       Instruction Substitution负责替换特定指令，runOnFunction会检测启动命令，遍历所有指令并随机应用替换策略，如Add指令的多种可能替换方式。

       虽然O-llvm提供了一定程度的混淆，但仍有改进空间，比如增加更多的替换规则和更复杂的跳转策略。作者建议，利用O-llvm的开源特性，开发者可以根据需求自定义混淆方法，提高混淆的复杂性和逆向难度。

       最后，对于对Obfuscator-llvm感兴趣的读者，可以参考《ollvm的混淆反混淆和定制修改》的文章进一步学习。网易云安全提供的应用加固服务提供了试用机会，对于保护软件安全具有实际价值。

       更多关于软件安全和源码分析的内容，欢迎访问网易云社区。

教程 iOS混淆加固原理篇

       在iOS开发中，为了保障应用免受逆向工程的威胁，混淆加固是不可或缺的措施。本文着重探讨了加固的必要性，编译过程，以及常见的混淆类型和对抗工具。

       首先，由于越狱设备的所有的源码是不是都是通用威胁，应用程序的可执行文件容易被**并逆向，导致安全风险。因此，混淆加固成为了保护程序的关键步骤。

       在编译流程中，Xcode通过预处理、符号化等步骤生成代码，Objective-C和Swift都借助LLVM进行编译。混淆则涵盖字符串、类名和方法名的加密，以及程序结构的混淆加密，以降低逆向者理解代码的难度。

       具体来说，字符串混淆加密使得源代码中的敏感信息难以辨识，类名和方法名混淆则使功能逻辑变得难以解析。程序结构混淆加密则进一步削弱代码的可读性，增加破解难度。

       逆向工具如ipa guard、Hopper和IDA等，广泛用于破解和分析iOS应用，但通过混淆技术，可以提高破解者的门槛。OLLVM和IPA guard是基于LLVM的混淆工具，而代码虚拟化则通过虚拟机技术，增强代码的保护性。

       综上所述，通过理解并实施适当的混淆加固策略，iOS开发者能够有效提升应用的安全性，抵御逆向工程和反编译的挑战。

逆向入门cocos2d游戏逆向分析

       深入剖析cocos2d-x游戏逆向分析

       cocos2d-x是一个开源的移动2D游戏框架，它底层支持各种平台，核心用c++封装了各种库，外部则提供了lua和c++接口。关键代码可能隐藏在lua脚本中，许多安卓游戏的逻辑也主要在lua脚本里运行。通过官网示意图了解从c++进入lua世界的路径。

       探索cocos2d-x的lua虚拟机相关代码，包括CCLuaEngine.h和CCLuaStack.h。在应用结束加载中进入lua虚拟机，具体由applicationDidFinishLaunching函数调用engine->executeScriptFile("main.lua")实现。

       在luaLoadBuffer函数中，使用xxtea_decrypt解密了lua脚本，并通过luaL_loadbuffer加载解密后的脚本内容。因此，通过hook这个函数，可以将(char*)content字符dump出来，获取解密后的定时开关手电筒源码lua脚本。

       然而，luaL_loadbuffer的源码无法直接获取，它位于编译过的库cocos2d-x\external\lua\luajit\prebuilt\android\armeabi-v7a\libluajit.a中。要找到实现细节，需要下载luajit源代码进行深入分析。

       总结关键点：

       1. 从c++进入lua世界的调用逻辑。

       2. 使用xxtea加密算法，sign和key为XXTEA和2dxlua。

       3. 无论是否加密，都会调用luaL_loadbuffer函数，通过hook这个函数获取解密后的lua脚本，但需运行游戏一次。

       4. cocos2d-x\external\xxtea\xxtea.cpp中有加密解密算法，逻辑清晰，可使用python脚本本地解密或hook获取key、sign或解密后脚本。

       实战案例：

       以某捕鱼游戏为例，下载apk后内部集成十余款小游戏。通过分析游戏源码，找到luac加密文件，解密key和sign。使用ida打开libqpry_lua.so，定位到AppDelegate::applicationDidFinishLaunching函数，找到加密调用。对比源码，解密后可直接运行游戏。

       深入lua脚本分析，如子弹击中鱼的逻辑，直接查找src\views\layer\BulletLayer.luac文件。通过修改相关函数参数，实现特定功能。其他功能逻辑获取源码后易于理解，修改代码后重新加密，实现游戏破解。

       思考如何实现cocos2d-x反逆向，从浅至深可采用以下方法：

       1. 修改xxtea的key和sign，需分析so文件。

       2. 直接修改xxtea算法，增加逆向难度。

       3. 更改luajit源码，调整字节码指令顺序或数据读取顺序。

       4. 将关键代码封装到其他cpp或so文件，增加解密步骤。

       5. 使用ollvm混淆代码，需分析混淆或vm。

代码混淆不再愁：一篇掌握核心技巧

       代码混淆技术对于保护软件免受逆向工程具有关键作用。其原理是山东系统开发源码交付将原始代码转换为难以理解的形式，从而增加分析和篡改的难度。主要思路包括符号混淆、控制流混淆、计算混淆和虚拟机混淆。

       首先，符号混淆涉及去除或混淆函数名、全局变量名等标识符，以降低代码可读性。例如，ELF文件可以通过命令行工具strip去除符号表实现这一目的。

       控制流混淆旨在混淆程序的控制流程，使逻辑关系难以识别。常见的方法有控制流平坦化、虚假控制流和随机控制流。控制流平坦化通过删除跳转关系，使用集中分发块调度执行顺序。虚假控制流通过插入不可达基本块和虚假跳转，干扰攻击者分析。随机控制流通过克隆基本块和随机跳转混淆控制流。

       计算混淆通过混淆计算流程或数据，使分析者难以分辨具体计算过程。主要手段包括指令替代和常量替代。指令替代替换二元运算指令为复杂指令序列，常量替代则替换常数为复杂表达式，以混淆计算过程。

       虚拟机混淆则将一组指令集合转化为自定义指令集，通过解释器执行，极大地增加了混淆难度，但可能带来性能损耗和易被误报等问题。

       OLLVM是一款经典的代码混淆工具，支持控制流平坦化、虚假控制流和指令替代等混淆方法。Ipa Guard是另一款强大的混淆工具，无需iOS应用源码，直接对ipa文件进行混淆加密，保护代码、资源文件等，通过重命名和混淆关键代码降低可读性，提高破解和反编译难度。它同样支持对、资源、配置等进行修改，适用多种开发环境，包括OC、Swift、Flutter、React Native和H5类应用。大连桶装水溯源码作用

IDA F5 增强插件，还我源代码（一）

       许多年以后，面对IDA的F5，面对着曾经的荣光与失落，老李老板的故事被追忆。在那个时代，App的名字还是exe和com，而Asm程序员的夜晚，是面对黑洞洞的屏幕，用DEBUG敲下代码的不眠之夜。随着时代的变迁，App改名，C程序员狂欢，Asm程序员黯淡。瑞士同行的ollvm让混淆达到了新高度，而IDA F5，成了对抗这一挑战的希望。

       如今，ollvm已经进入了第年，混淆技术愈发强大，而IDA F5以其独特的魅力再次成为焦点。它像是当年的小甜甜，现在则是牛夫人，每一次变身都充满着挑战与机遇。

       对于使用IDA 7.x+的用户，有一个简单的步骤可以尝试。只需将d文件夹和D.py文件放置在C:\fenfei\IDAPro7_5\plugins目录下，然后运行D.py，使用Ctrl-Shift-D进行操作，选择配置文件default_instruction_only.json。点击”Start“按钮，然后F5，奇迹即将显现。尽管结果可能没有那么惊艳，但至少能辨认出其本质。

       对于那些在配置好D后仍无法获得预期效果的用户，他们可能会遇到IDA F5的缓存问题。解决方法并非立即可见，但通过重新启动IDA或尝试等效的方法，可以清除缓存并让D的增强效果再次显现。

       IDA Microcode的引入，为汇编代码到C代码的转换过程提供了一个层次，使得这一过程更加细致和可定制。它就像是烹饪米饭，不同成熟度代表了代码转换的不同阶段，每一步都能添加自己的“私货”，使得最终的C代码更加“可口”。Microcode的深度探讨为读者提供了一种新的视角，通过github资源，可以更深入地了解这一过程。

       D的原理在于通过指令替换和流程重组来对抗混淆。它将混淆后的代码抽象为算式，利用AstNode对象进行表示，然后通过模式匹配进行替换。流程重组则寻找主分发器和真实块，重组正确的流程，这一过程在d/optimizers/flow中实现。

       动手实践是学习的最好方式，通过添加额外的优化规则，可以显著提升D的性能。小学数学知识在这里扮演着关键角色，而github资源提供了强大的工具，让这一过程变得既有趣又有效。

       总结而言，学习逆向工程技巧和思路是不断进化的，没有一劳永逸的方法。IDA F5的挑战与机遇并存，它与攻击者的对抗是一场永无止境的游戏。在这一过程中，技术的迭代与人的智慧同样重要，没有单一的决定性因素。而IDA社区的资源与知识，为每一个寻求进步的人提供了丰富的支持。

[Dev] Xcode的记录

       构建过程可以分为预处理(preprocess) -- 编译(build) -- 汇编(assemble) -- 连接(link)这几个大的过程。

       LLVM(Low Level Virtual Machine)是强大的编译器开发工具套件，其核心思想是通过生成中间代码IR，分离前后端（前端编译器，后端目标机器码）。这样做的好处是，前端新增编译器，不用再单独去适配目标机器码，只需要生成中间代码，LLVM就可以生成对应的目标机器码。下面就是LLVM的架构。

       预处理：头文件引入、宏替换、注释处理、条件编译等操作；

       词法分析：读入源文件字符流，组成有意义的词素（lexeme）序列，生成词法单元（token）输出；

       语法分析：Token流解析成一颗抽象语法树(AST)；

       CodeGen：遍历语法树，生成LLVM IR代码，这是前端的输出文件；

       汇编：LLVM对IR进行优化，针对不同架构生成不同目标代码，以汇编代码格式输出；

       汇编器生成.o文件：将汇编代码转换为机器代码，输出目标文件（object file）；

       连接器：将目标文件和(.dylib、.a、.tbd、.framework)进行连接，生成可执行mach-o文件。

       dwarf：debugging with attribute record formats，一种源码调试信息的记录格式，用于源码级调试；

       dSym：debug Symboles，调试符号，即符号表文件。符号对应着类、函数、变量等，是内存与符号如函数名、文件名、行号等的映射，崩溃日志解析非常重要。可以用dwarfdump 命令来查看dwarf调试信息。

       DW_AT_low_pc表示函数的起始地址 DW_AT_high_pc表示函数的结束地址 DW_AT_frame_base表示函数的栈帧基址 DW_AT_object_pointer表示对象指针地址 DW_AT_name表示函数的名字 DW_AT_decl_file表示函数所在的文件 DW_AT_decl_line表示函数所在的文件中的行数 DW_AT_prototyped为一个 Bool 值, 为 true 时代表这是一个子程序/函数(subroutine) DW_AT_type表示函数的返回值类型 DW_AT_artificial为一个Bool值，为true时代表这是一个由编译器生成而不是源程序显式声明

       使用symbolicatecrash命令行

       使用dwarfdump和atos工具

       xcode-project-file-format这里对xcodeproj文件格式进行了说明。

       xcodeproj文件包含以下元素

       总体说明

       结合上面的说明，对project.phxproj文件结构进行说明

       项目中setting有2处，project和target中都有，那么他们之间的关系是怎样的？

       在Xcode中添加代码块步骤

       1、选择代码，右键选择 create code snippet，或者在顶部导航，选择Editor-create code snippet；

       2、编辑信息和代码即可，其中completion表示输入的快捷方式；

       3、需要修改的参数用形式添加 ；

       4、所在目录~/Library/Developer/Xcode/UserData/CodeSnippets 。

       还需要注意xcshareddata目录下

       参考

       Xcode build过程中都做了什么 Xcode编译疾如风-3.浅谈 dwarf 和 dSYM iOS崩溃日志解析&原理 - 掘金 LLVM编译流程 & Clang插件开发 8. Xcode 工程文件解析 - 掘金 XCode工程文件结构及Xcodeproj框架的使用( 二 ) XCode: Target Settings和Project Settings的区别 Xcode-项目重命名

[clang]: llvm 前端编译流程

       clang编译流程分为五个主要步骤：预处理器、编译器、后端生成、汇编、链接器。

       预处理阶段主要进行文本替换操作，处理编译语言中的预处理指令，如导入头文件和宏替换等，不进行语法和词法检测。

       编译器阶段通过词法分析和语法分析，将预处理结果转换成抽象语法树（AST），以便生成中间表示（IR）。例如，从文件test.cc生成的AST将会被转换成可读的文本中间表示（ll）或不可读的bitcode（bc）文件。

       生成IR阶段，AST被转换为中间表示格式，确保正确识别代码的语法结构。bitcode（bc）和ll文件为两种不同的中间表示形式，二者可以相互转换。通过指令可以实现从中间表示到汇编语言的转换。

       汇编阶段，使用指令将中间表示转换为汇编代码（test.s），汇编语言代码可用于运行或进一步转换。

       最后阶段是链接器，将生成的汇编代码（或其他类型的目标文件）链接为可执行文件或动态库。

       总结，整个流程包含以下关键输出文件：

       - test.c：源代码输入

       - test.i：预处理输出文件

       - test.bc：bitcode中间表示文件

       - test.ll：可读的文本中间表示文件

       - test.s：汇编代码输出

       - test.o：单文件生成的二进制文件

       - image：最终的可执行文件

       注意流程图中箭头方向表示文件转换方向，实线部分介绍Clang编译器相关功能，虚线部分不涉及。

一文带你梳理Clang编译步骤及命令

       摘要： 本文简单介绍了Clang编译过程中涉及到的步骤和每个步骤的产物，并简单分析了部分影响预处理和编译成功的部分因素。

       本文简单介绍部分Clang和LLVM的编译命令。更关注前端部分（生成 IR 部分）。

1. Clang编译步骤概览

       我们可以使用命令打印出来Clang支持的步骤，如下：

clang-ccc-print-phasestest.c+-0:input,"test.c",c+-1:preprocessor,{ 0},cpp-output+-2:compiler,{ 1},ir+-3:backend,{ 2},assembler+-4:assembler,{ 3},object5:linker,{ 4},image

       根据上面的介绍，可以根据每一部分的结果，分为5个步骤（不包含上面的第0步）：preprocessor、compiler、backend、assembler、linker等。

       具体到 Clang 中每一步骤生成的结果文件。我们可以使用下面的示意图来表示：

       说明：上面的示意图以Clang编译一个C文件为例，介绍了Clang编译过程中涉及到的中间文件类型：

       (1) test.c 为输入的源码（对应步骤 0）；

       (2) test.i 为预处理文件（对应步骤 1 的输出，cpp-output 中，cpp 不是指 C++ 语言，而是 c preprocessor 的 缩写）；

       (3) test.bc 为 bitcode文件，是clang的一种中间表示（对应步骤 2 的输出）；

       (4) test.ll 为一种文本化的中间表示，可以打开来看的（对应步骤 2 的输出， 和 .bc 一样都是中间表示，可以相互转化）；

       (5) test.s 为汇编结果（对应步骤 3 的输出）；

       (6) test.o 为单文件生成的二进制文件（对应步骤 4 的输出）；

       (7) image 为可执行文件（对应步骤 5 的输出）。

       注意：示意图画的也并不完整，如下介绍：

       (1) 箭头所指的方向，表示可以从一种类型的文件，生成箭头所指的文件类型；

       (2) 图中箭头并没有画完，比如可以从 test.c 生成 test.s, test.o 等。如果将上面的示意图当做一种 有向图，那么基于 箭头 所指的方向，只要 节点能连接的点，都是可以做转换的；

       (3) 图中的实线和虚线，只是表示本人关心的Clang编译器中的内容，并没有其他的含义，本文也只介绍图中实线部分的内容，虚线部分的内容不做介绍。

2. 转换命令集合

       下面介绍部分涉及到上面步骤的转换命令：

#1..c->.iclang-E-ctest.c-otest.i#2..c->.bcclang-emit-llvmtest.c-c-otest.bc#3..c->.llclang-emit-llvmtest.c-S-otest.ll#4..i->.bcclang-emit-llvmtest.i-c-otest.bc#5..i->.llclang-emit-llvmtest.i-S-otest.ll#6..bc->.llllvm-distest.bc-otest.ll#7..ll->.bcllvm-astest.ll-otest.bc#8.多bc合并为一个bcllvm-linktest1.bctest2.bc-otest.bc

       上面列出了一部分Clang不同文件直接转换的命令（和第 1 部分的 示意图 序号匹配，还是只关心前端部分）。只是最后增加了一个将多个 bc 合并为一个 bc file 的命令。

3. 查看Clang AST结构

       我们可以通过如下的命令查看源码的AST结构：

clang-Xclang-ast-dump-ctest.c

       打印出来的AST信息，其实是预处理之后展开的源码信息，源码的AST内容在打印出来的内容的最下面。

       如下面的代码：

#include<stdio.h>intmain(){ printf("hello");return0;}

       打印出来的部分AST（仅根当前文件内容匹配部分）如下：

       头上的头文件引用等已经展开，没有了，但是下面的 main 函数定义，则如上面的 FunctionDecl 所示，并且给出了 代码中的位置。这里就不详细分析AST的结构了，写几个例子比对一下就很容易理解。

4. 编译正确性的影响因素

       当前，很多静态代码分析工具，都采用 Clang 和 LLVM 作为底座来开发静态代码分析工具。Clang自己也有 clang-tidy 工具可以用来做 C/C++ 语言的静态代码分析。为了能够用 Clang 和 LLVM 来成功分析 C/C++ 代码，需要考虑如何成功使用 Clang 和 LLVM 来编译 C/C++ 代码。可以考虑的是，成功生成 bc file，是静态代码分析的基础操作。

4.1 影响预处理结果的因素

       预处理过程，作用跟名字一样，都可以不当做编译的一个步骤，而是编译的一个预处理操作。我们说得再直白一点儿，其实就是做了一个文本替换的活儿，就是对 C/C++ 代码中的 预处理指令 进行处理。预处理指令很简单，比如 #include，#define 等，都是预处理指令（可以参考：/en-us/cpp/preprocessor/preprocessor-directives?view=msvc-，或者google下，很多介绍的）。

       如果程序中没有预处理指令，即使我们随便瞎写的代码，预处理也一般不会有问题，如下的代码（main.c）：

abcdef

       我们仍然可以正确得到 预处理结果：

#1"main.c"#1"<built-in>"1#1"<built-in>"3#"<built-in>"3#1"<commandline>"1#1"<built-in>"2#1"main.c"2abcdef

       为了成功执行预处理执行，很容易理解，就是可以对程序中的所有的 预处理指令 进行处理。比如：

       (1) #include，依赖了一个头文件，我们能不能成功找到这个头文件；

       (2) #define，定义了一个宏，在程序中定义宏的时候，我们能不能准确找到宏（找到，还必须准确）；

       (3) 其他指令。

4.2 影响IR生成因素

       这一步是针对上一步生成的预处理指令，进行解析的操作。这一步才是最关键的，归根结底，我们需要保证一点：使Clang编译器可以正确识别出来代码中内容表示的语法结构，并且接纳这种语法结构！

       举一些简单例子：

       (1) -std 用来指定支持的 C/C++ 标准的，如果我们没有指定，那么就会采用 Clang 默认的标准来编译，就可能导致语法不兼容；

       (2) -Werror=* 等参数，可能将某些能识别的语法，给搞成错误的使用；

       (3) 其他的部分，跟语法识别的参数；

       (4) 还有一部分的语法，可能 Clang 自始至终就没有进行适配，这种就要考虑修改源码了。

4.3 链接相关因素

       在真正编译中，如果链接有问题，那就会失败，但是在静态代码分析中，链接有失败（无法链接）或者错误（不相关的给链接在一起），可能多点儿分析误报或者漏报，一般不会导致分析失败。这类问题，影响的不是中间表示的生成，而是分析结果（影响跨文件的过程间分析，影响对built-in函数的建模等）。

       一般，链接命令的捕获，target信息配置等，会影响这部分的能力。当然，也跟你实现的工具有关（如果实现的工具，就没有跨文件的能力，这部分内容也没啥影响）。

       作者：maijun。