这是很多厂商API设计的一个漏洞，希望本文能给开发者们带来对安全的重视。
密码学
首先，什么是加密？
编码
像Base64这种算法只能算是编码算法，和8421bcd一样，根本谈不上加密，这种算法最多也只能防止你的小妹妹偷看你的日记，对于任何从事计算机行业的人来说，就像光着屁股一样，毫无隐私可言。
加密
密码学研究的加密是指在公开加密算法的情况下，不知道密钥时，如何在保密时间范围内使解密密文的可能性接近于0。目前主流的对称加密算法，除了一些弱密钥可以破解以外，如果密钥长度大于256位，即便集合了世界上的所有计算资源，通过穷举攻击获得真正的明文可能也要用上上千年的时间。保密密钥就意味着保密明文。
对称加密
如果加密密钥和解密密钥相同，获取密钥就意味着可以解密或者加密信息。这种加密也就是我们平时所说的对称加密。再次声明Base64不是加密，更不是对称加密，只是具有对称性的编码方式。
非对称加密
当然，还有一种我们通常说的非对称加密。对称加密算法在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。比如A发消息给B，这样A只需要使用B公开出来的密钥对明文进行加密，将密文发送给B，B使用自己的私钥对密文进行解密获取明文，由于B的私钥只有B自己知道，所以这种通信是安全的，但是非对称加密和解密的过程对计算资源的消耗要比对称加密大很多。
所以，常用的密码协议通常为A得到B的公钥，然后A生成一个对称加密的密钥，并使用B的公钥对对称密钥进行加密，然后将加密过后的密文发送给B，B用私钥对A发来的密文进行解密，B此时就获取到了A生成的对称加密的密钥，此时A和B就可以开始正常通讯了，最常用的类似于这种逻辑的常用的通讯协议是HTTPS。
散列
散列算法最常见的是MD5。散列算法常用于验证文件的有效性以及数字签名上，严格意义上来说并不算加密，散列算法具有非对称性，并不能反向操作。散列算法于本文想说的内容并没有多少相关性，所以不再赘述。
应用
笔者通过抓包截取了某App的密文如下：
9UQapcjMdfKaNYHZQb00pBbXOF16DMOEhLlkVUm$vsY1vX4ECu8Ji1G3qLOZkrfIjuTcSY0TduHCPCP56njgrx0W/ptgpelQXy3UQIWAKc12DfMMdvIVygkq$10rnKtnfcjg4jor9DYBITRN7nJEaf9AMP60$EJEE3BNm/KLlN3CT9RREDolAjZhFJlyJi3/tBCExcVbpAUOaWOPbDBZnNDhzelIG847i4E0Skyp3vntq8mrX4bifoVjGel7VB4R4rzjULdRH1ELQY5eOpnSdcXMUWxBgCxU5coprntoGWVBx4BO3bf5wJBSO$tp51RvhpBfOsqMksTchR$xQoN7sCMbbSjLCZ66Mx0oZa2O5brDC9uZ1/cBryA$HhGBM2sRM6kos/UhNS3kZw4dbBpa$edDdEBBWr88c5jQ/UJcgaWLoTl8f1k$S4qb5e7jxd$mnEY6dXe6$7A*
由于非对称加密的性能问题，所以首先我假定这组密文是使用对称加密算法进行加密而成的密文。我仔细观察发现了'*''$'这两个符号很奇怪，由于主流对称加密算法的结果集并不包含这两个字符，所以我猜测这两个符号可能是一组密文的分隔符。我做了一些操作，结果否定了我的猜测。我变换了该API中我输入的内容进行请求之后发现上面两个符号的位置和数量并不固定，甚至有可能没有，所以我认为这两个符号是分隔符的概率非常小。进而，我推断，这组密文可能在加密过后对密文进行了局部或者全部字符的偏移。但是，App的开发者是如何对密文进行偏移操作的我很难知道。
到这，对于加密方式的探索陷入了僵局，我不可能把如此长度的密文的各种偏移一一尝试。
逆向工程
最简单的逆向工程可以让你的代码几近透明。
相关工具
dumpdecrypted
Hopper
越狱过的iOS设备
逆向破解
首先打开越狱过的iOS设备，在Cydia中搜索安装OpenSSH，安装成功后可以在同一网络环境下ssh到该设备，默认用户名是root，密码是alpine。
# ssh root@ip
App Store下载的所有的ipa文件中的可执行文件（Mach-O type文件）都是经过苹果加密的，所以第一步我们需要使用dumpdecrypted来进行解密。dumpdecrypted解密的原理是：iOS运行app的时候一定会先将执行程序解密并载入到内存，dumpdecrypted就是从内存中重新获取了解密后的文件。从https://github.com/stefanesser/dumpdecrypted 下载源码之后进入到文件目录输入
# make
编译过后，生成dumpdecrypted.dylib备用。
iOS在安装App Store下载的App的时候会自动的安装与系统相对应的版本，大部分iOS App在App Store上都编译了至少两种CPU架构，由于我们后边要说的Hopper并不能对arm64 CPU架构进行伪代码转换，加上我本人对汇编并没有研究过，所以我只能想办法提取32位版本进行反编译。OSX自带的lipo工具可以帮我们做到这点，首先我们将ipa文件进行解压，然后进入Playload/APPNAME.app/目录，目录中有个Info.plist打开可以查看可执行文件的名称Executable file。在该目录下找到这个文件，使用
# lipo -extract armv7 /Path/To/EXCUTABLEFILE -output /Path/To/Output
这样，我们就可以在output路径下获取到提取的armv7架构的可执行文件。可以使用ifunbox等工具或者直接通过ssh拷贝可执行文件以及dumpdecrypted.dylib到越狱过后的iPhone，我习惯拷贝到/var/root目录下。拷贝过后记得设置文件的权限，设置Executable file的权限为755就可以。cd到/var/root目录，然后执行
# DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/root/EXECUTABLEFILE
命令执行结束后，会在该目录中获取到一个扩展名为.decrypted的解密后的可执行文件，将这个文件copy出来。然后开启神器Hopper，将文件拖入Hopper即可进行反汇编，在经过一段时间的反汇编之后得到类似下图的界面
在App没有进行代码混淆的情况下，很容易通过方法名和类名判断出哪一部份是我想要寻找的代码。右侧界面是汇编代码。可惜，笔者功力不够，没办法直接阅读这个。好在我们可以通过Hopper对汇编代码进行解释并生成Objective－C伪代码。经过一番对代码的搜索，我成功的找到了我的目标方法。左侧方法列表找到目标方法，然后点击右上角"if(b)f(x);"按钮即可得到该方法实现的伪代码。
由于是汇编反解释出来的伪代码，可读性不是很好，但是足够我们提取出我们想要的信息了，经过一番整理，找到了加密规则，代码中体现为
r4 = [[r0 encryptUseDES:r6 key:@"IamKey"] retain];
r6 = [[r4 stringByReplacingOccurrencesOfString:@"+" withString:@"$"] retain];
[r4 release];
r4 = [[r6 stringByReplacingOccurrencesOfString:@"=" withString:@"*"] retain];
App使用DES加密算法对明文使用密钥IamKey进行了加密，然后将加密的结果中的'+'替换成了'$'，将'='替换成了"*"，所以导致了之前分析的密文里有这两个奇怪的字符。其实App作者可以做更多，比如把A和C交换，5和b交换这种，但是实际结果就是，这种操作毫无意义。在反编译的面前，安全性荡然无存。至此，我了解到了该App的加密规则，并且很容易的在网关截获用户的敏感数据。
HTTPS
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，也被称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种网络安全传输协议。在计算机网络上，HTTPS经由超文本传输协议进行通讯，但利用SSL/TLS来对数据包进行加密。HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。（抄自维基百科）
更多内容请移步 https://zh.wikipedia.org/wiki/超文本传输安全协议