iOS 方法名代码混淆

利用class-dump可以很方便的导出程序头文件，让攻击者了解了程序结构方便逆向，所以混淆方法名,可以一定程度上加大逆向的阅读难度。

混淆的方法

方法名混淆其实就是字符串替换，有2个方法可以，一个是#define，一个是利用tops。

利用#define的方法有一个好处，就是可以把混淆结果合并在一个.h中，在工程Prefix.pch的最前面#import这个.h。不导入也可以编译、导入则实现混淆。

单段的selector，如func: ，可以通过#define func 来实现字符串替换。

多段的selector，如a:b:c: ，可以通过分别#define a 、b、c 来实现字符串替换。

切换到项目目录下

打开confuse.sh文件,把如下脚本加入文件中。

shell脚本会在项目目录中生成一个codeObfuscation.h的文件,将codeObfuscation.h导入项目中,同时将之前创建的function.list文件也导入项目

打开function.list文件,把需要混淆的方法名复制进来(这里所说的方法名不单单只是.h文件中的,也可以是.m文件中的)

项目运行后,混淆的方法名会被替换成宏定义

通过class-dump查看.h文件得到的方法名是随机的字符串

原文链接： https://blog.csdn.net/yiyaaixuexi/article/details/29201699

Android APK中的Java代码可以被反编译到什么程度主要看APK的加密程度。

第一种情况：无混淆无加密无加壳。

直接利用Dex2jar和JD-GUI可把源码从APK里抠出来，代码逻辑清晰，基本上做到可复用，只是资源文件的引用需要计算一下。

第二种情况：混淆。

通常是利用Proguard做的防护。因为是对jar做的不可逆混淆（除非有mapping），因此不能还原成原来的代码。但是代码结构，代码逻辑一致，只要花长时间对代码进行梳理一样可找准核心代码，解密方法跟第一种一致。

第三种情况：加密。

这里以DexGuard为例。对于这种代码加密的方法，在程序运行中必定会进行解密，只要抽出它解密的逻辑便可。PS：我自己做过DexGuard的解密，如果用Dex2jar反编译看的话逻辑是不对的，一定要从Smali代码看。后来发现网上已经有人做了。

解密的脚本：A look inside Dexguard

第四种情况：加壳。

这种情况跟第三种类似。无论你怎么加壳，运行的时候必定是Dalvik可识别的Odex代码，建议直接在内存里dump出来。这里Xpose的ZjDroid。

---