见过一些系统和应用在裸奔，也见过一些简单的应用设计了极其复杂的安全机制，不仅团队成员很难掌握，而且还影响到业务开发。所以我经常会想，什么样的网络请求才是合理的？ 1. 一个APP或者网站，怎么区分当前用户是谁呢？我可以在请求参数里附带UserID，通过UserID我可以知道返回什么样的数据或者展示什么样的内容。这时只要我在请求时修改一下UserID，就能看到其他用户的信息了，别笑，这样的系统确实存在，只在登录时确认了下UserID。 2. 当然能犯这么低级错误的比较是少数，为了防止这种情况，有些系统每次请求都附带了用户名和密码(加密后的也可以直接使用)，这样你不知道别人密码 ，很难冒充别人请求了，但是这种设计依然很差劲，即使你的用户名和密码是加密的，每天这么传来传去也不合适，传输过程中随便有人抓个包，拿到你的用户名和密码，就可以冒用你身份了，关键还要把用户名这么重要的东西存储的客户端。 3. 于是有人更进一步，通过登录请求返回一个token，这个token有一个有效期，这样后面所有请求都通过传递token标识用户身份。虽然登录请求时依然要传递用户名密码，但是大部分情况下只需要传递token还是安全很多的，毕竟可以有很多token失效策略用来提高安全性。当然token可以像上面改UserID一样被暴力试出来，尤其是量级很大的应用，所以UserID+token比单纯token被试出概率低很多。目前很多应用都是采用这种方式，虽说可以被抓包，毕竟这个门槛还是很高的，当然前提是你不要轻易连接未知WIFI。 4. 怎么可以不怕被抓包呢？有一个简单的方法就是给请求加一个验签，简单说就是每个请求都加一个签名用来证明是你发出的请求，而不是恶意第三方。最常见的一个方法就是根据请求的参数生成一个签名附带到请求中，那么即使有人抓包拿到了你的请求，他也很难冒充你去发请求，因为他不知道签名生成策略，而拦截到的签名，通常也都跟时间戳相关，所以也很难再继续使用。当然也可以把所有数据都加密，抓包抓到的就是一堆乱码。目前主流的网络请求基本都是采用这种策略。攻击者可以通过分析前端代码或者分析反编译后的客户端代码，获取加密或者生成验签的算法来破解这种安全方案。 5. 还有一种方法，就是使用https，它能保证数据传输过程中实安全的。尽管有中间者攻击，但是只要客户端验证服务器证书，就可以很容易识破攻击者。浏览器默认可以验证CA签署的证书的，自签名或者攻击者的签名，浏览器会有安全警告。手机APP的话需要自己实现证书验证步骤。各方面来讲，https还是很安全的，目前各个大厂都在推https，如果说缺点的话，那就是可以通过抓包工具分析请求，上面说了可以防止中间者攻击，但是用户安装中间者证书并且信任它那就没办法了，并且通常场景https都是单向验证，那么如果接口设计不合理，攻击者就可以通过直接发送请求完成攻击。 6. 根据上面分析，可以把5和4组合使用，达到类似于双向验证的效果来提高安全性。那么这种方案唯一的攻击入口就在于破解4中提到的加密算法。 7. 前端代码通过混淆实现算法保护，android也是通过混淆对java代码进行保护，不过它的反射机制暴露了每一个Activity，给破解者提供了一个很好的切入点，所以为了提高安全性，很多Android开发者都把一些核心算法的实现放到lib.so中实现。放lib.so中就很安全吗？答案肯定是否定的，但是它把破解难度提高了很多，它是ELF文件格式，通过工具可以拿到汇编代码，尤其android中native方法名不能混淆，也暴露了默认C/C++实现的函数名。不少Android应用仅仅通过lib.so获取字符串方式隐藏加密密钥或者特殊code，这种方式破解难度就更低了，找到特殊关键字直接从汇编代码中搜索，更有甚者破解者直接写代码调用你的lib.so获取结果。为了再次提高安全等级，就出现了加壳技术。IOS程序就是加壳后的ELF文件，如上分析Android做了这么多工作才达到了IOS的安全程度，这也是为啥大家都说IOS难破解，当然加壳后也不是绝对安全，大家应该经常听到脱壳技术。梆梆和360都推出了针对Android的加固服务，但是很快就被安全爱好者脱壳并公布方法(当然它们肯定会推出新的加固方案)，所以安全没有绝对的，就看你要做到什么地步了。
根据上面的分析，为了防止被轻易破解，Android通常需要把核心代码放到lib.so，并且采用一些方法对APP加固(通常是360、梆梆等第三方方案)。现在我们就设计一套自己的安全方案。
通常生成一个签名标识请求的合法性，我们可以参考微信支付签名的生成步骤，大致可以用以下伪码实现：
sign = MD5("k1=v1&k2=v2&appid=xxxx&nonce_str=xxx);后台接收到一个请求时，先验证一下签名，不符合的话可以认为是非法请求，不予处理。 微信的签名算法是公开的，但是appid的值是每个应用向微信申请的，所以如果APP不想办法隐藏这个key，这个sign对于攻击者没任何意义。在上一篇文章提到过，增加破解难度的第一步就是把核心算法放到lib.so里面，这里我们可以设计一个自己的算法并且由C/C++实现，我按照下面的方式生成的签名：
MD5("secret" + "param" + "secret")其中param是请求的参数，在java层根据自己的规则拼接好传到native层。
我们把要加密的内容生成byte数组，把byte数组直接传到native层进行加密。加密解密我们使用AES加密，秘钥全部在native层拼接生成。
对上面两个功能做个封装，可以生成如下一个类，
public class SecureUtil { native public static byte[] encryptData(Context context, byte[] data); native public static byte[] decryptData(Context context, byte[] data); native public static String getSign(Context context, String data); }因为native方法不能混淆，所以它对应的C++函数名根据JNI规则不难得出：
Java_com_dfqin_encrypt_SecureUtil_getSign(JNIEnv *env, jobject instance, jobject context, jbyteArray temp_)例如安装官方JNI写的demo生成的lib.so拖到反汇编工具里面，如下图可以一眼找到java方法对应的函数
可以采用动态注册函数的方式，把对应的C/C++函数生命为任意名称。如下图是修改后的函数名
上一篇文章也提到过，你把核心算法封装到lib.so中，虽然破解算法的难度增加了，但是别人可以不破解，直接调用你的lib.so，谁说破解一定要正面刚。像上面我们封装的SecureUtil，其他人拿到lib.so后可以直接调用里面的三个方法，完全不需要关注你怎么生成签名的和怎么加密解密的。为了避免这种尴尬，我们要想办法限制其他人调用我们的lib.so。为了达到这个目的，我们可以在native层读取当前app的packageName，当然其他人可以创建一个包名一样的项目来调用。另外一个办法就是在native层读取当前应用的签名看是否满足要求，因为别人没有我们签名的秘钥，所以这时就很难作假了。
当我们开发遇到问题时，一个最有效的方法就是调试，直接查看代码运行现场和上下文，很多问题瞬间迎刃而解，反编译动态库时也是，所以如果能防止被动态调试，也就提高了破解难度。网上有很多反调试的方法(当然也有很多破解反调试的方法:`)，我们可以定制自己的反调试策略，这里我选择通过ptrace()自己附加线程防止动态调试。
ptrace(PTRACE_TRACEME, 0, 0, 0);一个简单的加密方案已经完成，虽然这只是个原型，根据自己项目需求改一下基本可以直接用了，代码已经放到github。 如果你对自己技术足够自信，可以自己再实现一套加壳方案，不过我还是推荐使用梆梆、爱加密这类公司的加固方案，他们加固时会对lib.so加壳的。
