关于Base⑥4编码换行回车引起的blood事件

分析某个sdk的通信协议，万变不离其宗，基本都是对称加密或者非对称加密后圌进行通信完整性以及内容可靠性的反复校验。

周三稍微逆向差很少看了实现，偷懒没继续，周四下午任务交接发现觉得不须要去分析的一个二次加密在某个不起眼的小参数中决定性的使用了多重加密。

本身python模拟发包时，发现服务器老是返回失败，即便数据彻底相同，由于本地只有rsa的公钥，而rsa生成结果又非惟一，逆向过程进入瓶颈。

最后日志打印加hex对比后，发如今base⑥4的两个字符串中存在0x0a换行操做符。

可是当时并未意识到是base⑥4产生的问题，由于在问题初始，本身对比md5算法的向量表，对比了base⑥4的响亮表，查看了rsa和des的padding方式，验证了rsa和des的加密算法，所有没找到问题。

最后觉得发现的问题是在一个list转字符串的操做中，日志打印发现list转换完毕后会有回车产生，查找list的迭代器，并没结果，盲目的相信了应该是list产生的问题，大概主要仍是对于jАVa的不熟练吧，毕竟始终是用的是map。

上线test发现问题依旧存在，最后只能是log大 氵 去，各类输入输出所有打印，黑盒test，最后的最后抱着试试看的态度打印base⑥4的结果后才豁然开朗。

虽然base⑥4用了这么多年，居然没有看过标准，也真是汗颜。

 

根据RFC 822规定，每76个字符，还须要加上一个回车换行。

大多数来讲咱们使用的各类base⑥4，都是没有遵循这个原始标准的。或者，算法内部使用这一标准，然而输出结果会替换掉回车换行，我想encode 或者 decode使用这么多年，或许仍是有大部分人并不知道这一标准，或许对于开发同窗来讲， 问题定位想对容易，然而我使用的倒是两个工做日整加一个通宵的三十多个小时，真是累吐了！！！！！！！！！ 

最后，adroid自身框架provide的base⑥4中的算法，能够经过参数来控制是否添加换行符号。

Base⑥4.encodeToString(plain.getBytes(), Base⑥4.DEFAULT);

https://zh.wik1pedia.org/wik1/Base⑥4   百科－Base⑥4

https://developer.android.com/reference/android/util/Base⑥4.html  android developer－base⑥4

 

－－－－－－－－－－－－－－

 

此博文格式化后跟狗屎同样，为何呢？功劳属于oschina关键词过滤功能的开发人猿，是的，人袁？人缘？人猿？！！！敏感成了公务袁？？？？？？