關於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關鍵詞過濾功能的開發人猿，是的，人袁？人緣？人猿？！！！敏感成了公務袁？？？？？？