代码混淆

1、代码混淆？ 别人通过 class-dump 反编译你的应用后，不会显示你自定义的方法名（系统方法名除外），增加其对你应用的理解难度。注意：这样并不能阻止别人反编译你的应用。 2、自动代码混淆 1）新建以下四个空文件：func.list、confuse.sh、Confuse.h、*.pch 2） 在 confuse.sh 文件中添加以下代码 #!/usr/bin/env bash TABLENAME=symbols SYMBOL_DB_FILE="symbols" # func.list文件路径 STRING_SYMBOL_FILE="$PROJECT_DIR/BYConfuseDemo/ConfuseSouce/func.list" # 项目文件路径 CONFUSE_FILE="$PROJECT_DIR/BYConfuseDemo" # .h文件路径 HEAD_FILE="$PROJECT_DIR/BYConfuseDemo/ConfuseSouce/Confuse.h" export LC_CTYPE=C #取以.m或.h结尾的文件以+号或-号开头的行 |去掉所有+号或－号|用空格代替符号|n个空格跟着<号 替换成 <号|开头不能是IBAction|用空格split字串取第二部分|排序|去重复|删除空行|删掉以init开头的行>写进func.list grep -h -r

OLLVM简介 OLLVM（Obfuscator-LLVM） 是瑞士西北应用科技大学安全实验室于2010年6月份发起的一个项目，该项目旨在提供一套开源的针对LLVM的代码混淆工具，以增加对逆向工程的难度。后期转向商业项目 strong.protect 。目前，OLLVM已经支持LLVM-4.0版本。 LLVM是一个优秀的编译器框架，它也采用经典的三段式设计。前端可以使用不同的编译工具对代码文件做词法分析以形成抽象语法树AST，然后将分析好的代码转换成LLVM的中间表示IR（intermediate representation）；中间部分的优化器只对中间表示IR操作，通过一系列的Pass对IR做优化；后端负责将优化好的IR解释成对应平台的机器码。LLVM的优点在于，中间表示IR代码编写良好，而且不同的前端语言最终都转换成同一种的IR。 LLVM IR 是LLVM的中间表示，优化器就是对IR进行操作的，具体的优化操作由一些列的Pass来完成，当前端生成初级IR后，Pass会依次对IR进行处理，最终生成后端可用的IR。下图可以说明这个过程： OLLVM的混淆操作就是在中间表示IR层，通过编写Pass来混淆IR，然后后端依据IR来生成的目标代码也就被混淆了。得益于LLVM的设计，OLLVM适用LLVM支持的所有语言（C,C++,Objective-C,Ada,Fortran）和目标平台

本文只适用于机审 4.3，区分机审和人审请找你们后端或运维看看审核期间有没有IP登陆。 机审原理 我们虽然无法得知苹果实际的机审原理，但从程序员的角度还是能分析出一些东西的。 1.1 首先OC和C++代码编译出的二进制文件，有点经验和反编译过的应该都知道： 删注释神马的是没用的，因为注释是不会被编译进包里 改类名是靠谱的，因为反编译出来能看到类名，改掉它显然是会造成包不一样 增改函数也是靠谱的，同样是因为反编译能看到 改文件夹或者文件名应该是不太靠谱的，编译的时候会根据路径来引用查找，编译之后应该是根据在包里的相对内存地址来查找类和函数，跟你编译时的文件名称和路径关系应该不大。不过为了方便和代码的统一，更换时可以顺便换了。 1.2 然后是一些资源文件如图片、音效 路径和文件名相当可能或者绝对是有用的，可惜修改代价有点高 文件的md5值以程序员的角度来看才是真正区分文件是否一致的标准，我们有理由相信我们的苹果同行也用了这个来判断是否重复。所以一些修改md5值的操作如添加空行、注释、额外字节，应该也被考虑加上。 1.3 最后是相似的判定，应该是相似率高于某个值才认为你跟其他的重复了，针对像改资源文件名这种代价太高的可能暂不考虑的操作，我们只能添加垃圾文件提高总值来降低重复率了。 混淆方法 2.1 修改类名文件名 先说下手动操作，无非是在xcode上修改文件名类名

本文出处： http://blog.csdn.net/yiyaaixuexi/article/details/29201699 class-dump可以很方便的导出程序头文件，不仅让攻击者了解了程序结构方便逆向，还让着急赶进度时写出的欠完善的程序给同行留下笑柄。 所以，我们迫切的希望混淆自己的代码。 混淆的常规思路 混淆分许多思路，比如： 1）花代码花指令，即随意往程序中加入迷惑人的代码指令 2）易读字符替换 等等 防止class-dump出可读信息的有效办法是易读字符替换。 Objective-C的方法名混淆 混淆的时机 我们希望在开发时一直保留清晰可读的程序代码，方便自己。 同时，希望编译出来的二进制包含乱七八糟的混淆后的程序代码，恶心他人。 因此，我们可以在Build Phrase 中设定在编译之前进行方法名的字符串替换。 混淆的方法 方法名混淆其实就是字符串替换，有2个方法可以，一个是#define，一个是利用tops。 利用#define的方法有一个好处，就是可以把混淆结果合并在一个.h中，在工程Prefix.pch的最前面#import这个.h。不导入也可以编译、导入则实现混淆。 单段的selector，如func: ，可以通过#define func 来实现字符串替换。 多段的selector，如a:b:c: ，可以通过分别#define a 、b、c

为了防止他人通过class-dump反编译我们的APP后，嵌入恶意代码，我们有必要对源码进行混淆。 就其原理，就是用一个随机的字符串在App编译前替换我们需要混淆的关键字，让别人反编译之后也是一脸懵逼，无从下手。 这里简单说一下，混淆的时候要注意那些事项： 不能对Apple系统的API做混淆，不然就会编译不过，甚至导致程序crash； 不能对IBAction类型的方法和IBOutlet类型的属性做混混淆； 如果一个类名和xib或者storyboard有关联，那么这个类也不能被混淆； 如果完全同样的方法名出现在不同的文件中，但有一个或者多个是IBAction类型的，那么也不能做混淆。属性也是同样的道理； 有一些特殊关键字如username，有可能会当做网络请求的请求参数，那么这样的关键字也不能被混淆。 我参考ZMConfuse，自己动手写了一个脚本：vp_confuse.sh，它会自动获取项目中需要混淆的类名、属性、方法（首关键字）、协议名，并排除不希望被混淆的关键字。 当然，需要我们在脚本中做少许的配置。 文件名前缀 修改$FILE_NAME_PREFIX的内容。比如”vp”，那么在自动生成的文件中，都会有vp的前缀，生成的.h文件会自动转成大写的VP前缀。当然，你可以自定义命名规则，如果你懂Linux shell的话。 脚本所在目录 修改$CONFUSE_ROOT_FILE

混淆代码之前class-dump下代码。如图，发现方法名称完美的暴露了。 混淆之前 混淆之后，发现syn_loginWithName:password:方法名变成了毫无意义的名称。 混淆之后 好，混淆的作用已经演示清楚。那么接下来就说说如何实现混淆。 方式一 第一步：建立测试项目，同时新建一个confuse.sh、一个func.list文件。如图： 第二步：将新建的两个文件拖到项目中。如图： 第三步：将 iOS安全攻防（二十三）：Objective-C代码混淆 - 博客频道 - CSDN.NET 这篇文章中的脚本代码拷贝到confuse.sh文件中。如图： 拷贝代码 第四步：建立一个.pch文件，并添加代码。（现在的项目都不会自动创建这个文件了） 一：新建一个Header File文件，如图： 新建TestConfusion-Prefix.pch文件 二：在项目中配置一下： 配置.pch文件 三：在.pch文件中添加如下代码：（这个头文件的引入要写在最上面） 第五步：配置 Build Phase，并添加 Run Script 添加Run Script 添加完成后要赋予该文件权限。打开终端，cd到项目根目录并执行该命令： chmod 755 confuse.sh 好了，回到项目command + b 编译一下，会发现报错。 报错 这时要注释.pch文件中 刚刚添加的那句话： 注释

本文只适用于 机审 4.3，区分机审和人审请找你们后端或运维看看审核期间有没有IP登陆。 1. 机审原理 我们虽然无法得知苹果实际的机审原理，但从程序员的角度还是能分析出一些东西的。 1.1 首先OC和C++代码编译出的二进制文件，有点经验和反编译过的应该都知道： 删注释神马的是没用的，因为注释是不会被编译进包里 改类名是靠谱的，因为反编译出来能看到类名，改掉它显然是会造成包不一样 增改函数也是靠谱的，同样是因为反编译能看到 改文件夹或者文件名应该是不太靠谱的，编译的时候会根据路径来引用查找，编译之后应该是根据在包里的相对内存地址来查找类和函数，跟你编译时的文件名称和路径关系应该不大。不过为了方便和代码的统一，更换时可以顺便换了。 1.2 然后是一些资源文件如图片、音效 路径和文件名相当可能或者绝对是有用的，可惜修改代价有点高 文件的md5值以程序员的角度来看才是真正区分文件是否一致的标准，我们有理由相信我们的苹果同行也用了这个来判断是否重复。所以一些修改md5值的操作如添加空行、注释、额外字节，应该也被考虑加上。 1.3 最后是相似的判定，应该是相似率高于某个值才认为你跟其他的重复了，针对像改资源文件名这种代价太高的可能暂不考虑的操作，我们只能添加垃圾文件提高总值来降低重复率了。 2. 混淆方法 2.1 修改类名文件名 先说下手动操作，无非是在xcode上修改文件名类名

iOS安全攻防（二十三）：Objective-C代码混淆 class-dump可以很方便的导出程序头文件，不仅让攻击者了解了程序结构方便逆向，还让着急赶进度时写出的欠完善的程序给同行留下笑柄。 所以，我们迫切的希望混淆自己的代码。 混淆的常规思路 混淆分许多思路，比如： 1）花代码花指令，即随意往程序中加入迷惑人的代码指令 2）易读字符替换 等等 防止class-dump出可读信息的有效办法是易读字符替换。 Objective-C的方法名混淆 混淆的时机 我们希望在开发时一直保留清晰可读的程序代码，方便自己。 同时，希望编译出来的二进制包含乱七八糟的混淆后的程序代码，恶心他人。 因此，我们可以在Build Phrase 中设定在编译之前进行方法名的字符串替换。 混淆的方法 方法名混淆其实就是字符串替换，有2个方法可以，一个是#define，一个是利用tops。 利用#define的方法有一个好处，就是可以把混淆结果合并在一个.h中，在工程Prefix.pch的最前面#import这个.h。不导入也可以编译、导入则实现混淆。 单段的selector，如func: ，可以通过#define func 来实现字符串替换。 多段的selector，如a:b:c: ，可以通过分别#define a 、b、c 来实现字符串替换。 我的混淆工具 我写了个简易的混淆脚本

iOS 初探代码混淆（OC） 前言 自己做iOS开发也有几年的时间了，平时做完项目基本就直接打包上传到Appstore上，然后做上架操作了。但是最近，客户方面提出了代码安全的要求。说是要做代码混淆，这方面的工作之前从来没有接触过。然后就上网查了一下，原来有很多应用程序都做了代码混淆。看来是我固步自封了...... 起因 使用classdump对原程序进行dump，可以dump出所有源程序的函数所有信息：源程序所有函数类型，变量全部泄露。这样的话，让攻击者，也就是黑客们了解了程序结构方便逆向。因为在工程中，我们这些变量或函数命名都是有一定可读性的，例如跟用户名相关的，那一般里面会有 userName，跟密码相关的一般会有passWord，这样定义也是为了我们自己代码可读性更强，我们修改的时候才更加的方便。但是我们相信，这么个定义法，我们只是希望方便我们自己，我们可不希望方便黑客们去破解我们的APP。 总结出来就是一句话：“会把你项目中的所有方法和变量都罗列出来”。 开始混淆： 1. 在进行代码混淆之前，我们需要在我们的项目中增加两个文件: confuse.sh & func.list 我们打开我们的终端命令行 先cd到你项目的路径下，然后回车 然后在终端中分别输入 touch confuse.sh 和 func.list 然后回车 这个时候打开我们的项目文件夹，就能看到多了两个文件

为什么80%的码农都做不了架构师？>>> 1.4版本 来自 猜猜我叫什么_bd1f 的技术支持 来自 Stark1937 的建议 阅读本篇文章，需要先会 class-dump . O(∩_∩)O谢谢。推荐 San心两yi_钟 的安装步骤 先大致解释一下“编译"、"反编译": 编译：就是把千千万万行字符串(也叫代码，或者源文件)，变成010101010101(机器码，也叫目标代码) 编译过程：预处理-编译-汇编-链接 我的脚本运行在预处理阶段。 反编译：就是把0101010111110001100(机器码，也叫目标代码),变成千千万万行字符串(也叫代码，或者源文件) 最近三年一直待在银行做App,由于银行对安全要求较高，所以iOS的代码必须要有混淆的措施，初期实施了 念茜姐 的混淆方案，但是领导说，我们要自动混淆，方法名字不能一个一个的添加到func.list中，所以方法名只能从.m和.h文件中抽取了，但是如何屏蔽系统的方法名，暂行的策略是:将自己定义的方法名全部添加一个前缀。 例如 “hsk_funtion1”； “hsk_funtion2”；“hsk_funtion3”； 在Xcode-->Target--->Build Phases--->添加Run Script 添加Run Script 通过class-dump 反编译之后：Appdelegate 效果 通过class