分析某个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关键词过滤功能的开发人猿，是的，人袁？人缘？人猿？！！！敏感成了公务袁？？？？？？