總的來說，還是要看開發者比較在意哪方面的安全，才好考慮如何防護：
1、想要保證程序中的信息不被截取
幾乎是不可能的，因為即使再加密，密文也總要變成明文供業務邏輯來使用，攻擊者只要盯住這個點就能達到目標；
2、想保護服務器的資源
客戶端在相當程度上只是一個UI展現，即使被破解也不是那么重要的，真正重要的是服務器端的資源，那么就要在網絡層進行防護了。現在大家都比較喜歡用http，而且都集中喜歡使用AF、ASI等幾個開源庫，逆向者只要盯住這幾個口，就能把來往的request+response全部獲取，進而可以仿制一個客戶端，此時服務器的資源也就全面開放了。同樣的，使用AsyncSocket也是一回事。
此時有3種防護措施：
1）服務器控制，不允許同一IP/客戶端頻繁抓取數據；
2）對url加上token、timestamp，甚至url編碼，雖然碰上高手還是不能100%安全，但是破解者想要達到目的，就需要考慮付出的精力是不是值得了；
3）傳輸數據加密，并且將加解密的代碼層級加深，尤其是放到C或block函數中，這樣又將安全等級提高了一級。
3、想保護程序不被偽造或克隆
克隆/偽造其實是件非常容易的事，甚至都不需要太多逆向工作，只要能把網絡請求搞定，剩下的就是代碼量、以及是否比被仿者做的更好的問題了。
總的來說，客戶端沒太多可保護的空間，它應該就是個業務展現和數據解析的工具，與其花精力想防這個防那個，不如把精力放在網絡接口的保護上，尤其是加解密代碼提取到C或block中。
以上只是筆者個人的一些經驗，希望大家能多多補充。
附：微信的安全防護措施，筆者認為是比較值得學習的，他們的步驟是：
1、不在業務表現上做太多無用功
除了代碼結構比較龐大之外，微信沒有做特別的動作；
2、服務器控制
所有的決斷性的動作由服務器控制，幾乎不可能靠通過篡改客戶端的代碼來獲取更大的權限。筆者曾經針對每天20個漂流瓶的限制嘗試擴大權限，但是即使把本地代碼邏輯放開，在超過20個瓶子之后，再撈回來的永遠是海星，顯然是服務器控制住了。
當然，本地LBS坐標是無法被服務器控制的，這也就是坐標穿越插件能起作用的根本原因。
3、網絡數據加密
通過對網絡接口的攔截，雖然能得到socket收取的二進制數據，首先是無法直接解密，其次是從那許多代碼中找解密代碼非常費勁，縱然加解密都能搞定，想偽造也十分麻煩，packet中包羅了相當多的信息，我估計就是把他們的代碼開放給開發者，想理清這一部分都不是一件輕松的事情。
4、登錄唯一性
即使能夠偽造微信的請求，一旦登錄獲取數據，原賬號就會被踢下線并且得到通知，這本身就是一個安全警告，說起來也算是服務器控制。
如果開發者對于安全性的設計都能達到微信這一級別，安全級別就是比較值得信賴的了，但是這也不表示就解不出來，只要逆向者的水平達到熟練程度以上（自然是越高越好），并且愿意投入大量精力在某個他們認為值得的app上，幾乎都能攻的下來。
作者：Exia_L
鏈接：http://www.lxweimin.com/p/c3b41c3f6692
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
