本文針對的是cocos2d-x 3.4 版本進行研究。

做加密解密的思路

加密解密演算法的簡單介紹

首先，加密解密應該是一個單獨的話題，一般不會涉及具體使用的引擎、框架和技術。

加密演算法有Base64，DES等。

Base64的原理類似於凱撒密碼，啥是凱撒密碼呢，就是一個字元用另一個字元來代替。

比如：a用i代替，b用k代替，以此類推。加密和解密的過程就是一個互相對映的過程。

DES是一種使用金鑰的加密演算法。

DES和Base64這種無金鑰的演算法在使用上的區別是：

DES演算法本身是可以不保密的，只要保密金鑰即可，金鑰才是解密的關鍵。

Base64如果用於加密的話，演算法本身就是金鑰。要保密演算法。

MD5，SHA等是摘要演算法。

Base64，DES都可以把密文還原出明文。

而MD5，SHA則不能對演算法作用後的輸出還原出原始資料。

摘要演算法一般做身份驗證。

我們做資源加密是要選擇能把密文還原出明文的演算法。

設計自己的加密解密演算法

這屬於密碼學的內容了，可深可淺。

可以借鑑凱撒密碼的原理自己對每個位元組的內容進行對映來加密。

也可以對1位元組，2位元組，4位元組的資料，用某個數進行異或運算來加密。

異或的特性是，用數A對內容B進行異或得到內容C，再用數A對內容C異或可以得到內容B。

這個特性可以被用來加密。同時，數A的作用就是金鑰了。

設計的加密演算法不同，加密演算法的使用的介面也不同。

如果是用上面的2種思路做加密演算法的話，加密演算法的實現可以“in place”操作，

就是可以直接在密文所在的記憶體進行解密，不單獨分配記憶體來儲存解密後的資料。

如果加密演算法很複雜，無法“就地還原”，就需要新申請記憶體來儲存解密資料。

當然，執行速度一般是”就地還原“快。

我覺得，如果可以的話，最好是自己設計加密演算法。

使用現成的DES之類的演算法，金鑰是關鍵。

如果是自己設計一個用金鑰加密的演算法，金鑰和演算法本身都是不公開的。

破解者要獲取資源明文要經過如下步驟：

1.在程式中找到金鑰的常量。

2.看懂反出來的彙編還原出演算法，或者想辦法利用加密演算法的彙編程式碼。

其中步驟2會加大解密者解密的難度，這是自己設計加密演算法比用現成的DES之類著名演算法的好處。

加密解密的運用機制

我見過有一些人加密是對欄位內容進行加密。

比如，他用xml儲存資料，他只對儲存的值進行加密。

內容類似這樣 <Entity Hp = "密文" AttackValue = "密文" >

這並不是一種好的運用加密的方式，因為這種方式會：

1.透露程式的配置檔案結構。XML、json等。

2.透露了程式可能使用的資料結構。看以上內容可猜想Entity實體類有2個欄位，Hp（血量），AttackValue（攻擊力）

更徹底的加密方式是，對整個xml、json等檔案進行加密。

這樣別人就不會知道關於你的資料的一丁點資訊。

這種做法不是直接用資料解析庫封裝的類似LoadFile的函式直接讀取檔案。

而是，先把加密檔案用檔案讀取方法讀入記憶體，在記憶體解密後，再把解密資料傳給解析庫的解析函式。

這種做法要求解析庫有對記憶體進行解析的介面。

比如，若用XML解析庫，就會棄用LoadFile，要求有Parse方法。

有一種情況可能無法對整個資料檔案進行加密。

就是使用sqlite等資料庫的時候，這時候只能對欄位進行加密了。

有些人設計加密機制會要求配置程式本身。

比如：程式需要一個配置（一個開關變數或者條件編譯）來決定是否對資源進行解密。

釋出時，把資源都加密好，開啟程式對資源的解密。

開發時，資源不必加密，遮蔽程式對資源的解密。

這種做法需要來回設定解密開關，比較繁瑣。

有一種實現思路更有擴充套件性、更靈活、使用更方便。

那就是自己設計檔案頭。

熟悉Win32程式設計的人可能會知道PE檔案格式。

Windows執行一個exe之前，會檢查PE檔案頭，

取得EXE檔案的資料常量、程式碼區塊等資訊後，系統才能正確執行一個EXE。

我們可以設計一個加密檔案頭，加密檔案頭有一個欄位標識該檔案是否是被加密過的。

解密演算法可以通過判斷加密頭的識別符號來決定是否進行解密、採用哪種解密演算法等。

這是一種資料驅動式的解密機制，解密資訊都儲存在加密資料本身中。

對於沒有被加密過的資料，程式判斷沒有檔案加密頭標識，就不執行解密。

這樣，程式可以同時讀取未加密的資料和已經加密的資料，而不需要對程式進行任何修改。

注意：加密頭的識別符號應該足夠特殊，保證和未加密的資料不會產生衝突。

若未加密的資料剛好出現了加密頭的內容，那麼程式就會對未加密的資料進行解密。

在Cocos2d-x 中做加密解密的研究過程

我的專案配置是用CSV檔案。解析器，用的是我自己寫的CSV解析器：

在遊戲中這部分的解密，比較容易實現，就是對整個檔案加密，

遊戲啟動時把加密檔案讀入記憶體進行解密，然後把解密資料傳到解析器進行解析。

一些由遊戲產生的需要儲存的資料，我用XML進行儲存。加解密思路也如上。

但是，對於圖片、動畫，粒子、cocostudio1.6匯出的UI 等資料，加密就不那麼簡單了。

因為，像 Sprite::create 這樣的介面，並沒有提供一個從記憶體獲取紋理資料來初始化精靈的方式，

而是直接從磁碟檔案中讀。使用者在外部是無法干預檔案資料的讀取載入的。

遊戲資源的加密要怎麼做？——只有修改引擎了。- -！

我覺得，修改引擎並不是一個好的做法。

引擎應該由引擎提供商來維護，而不是靠使用者自己來動手。

使用者自己動手會造成專案維護升級困難。

自己把引擎改得亂七八糟，想升級引擎到新的版本會變成很麻煩。

就算是修改了一點，升級引擎版本一次，就要做一次修改，這樣也很麻煩。

要修改引擎，首先要跟蹤除錯，

以cocos2d-x 3.4 作為試驗版本，從Sprite::create入口，一步步跟下去，

看看引擎是在哪裡載入檔案資料的。

經過除錯跟蹤，Sprite::create的呼叫堆疊如下：

getData

FileUtilsWin32::getDataFromFile

Image::initWithImageFile

TextureCache::addImage

Sprite::initWithFile

Sprite::create

在windows上，精靈載入圖片，是呼叫到了

CCFileUtils-win32.cpp 這個檔案中的 

static Data getData(const std::string& filename, bool forString) 函式。

這個函式是一個非類成員靜態函式。

再除錯下其他的資料載入，cocostudio1.6做的動畫的呼叫堆疊是：

cocos2d::FileUtilsWin32::getFileData
cocostudio::DataReaderHelper::addDataFromFile
cocostudio::ArmatureDataManager::addArmatureFileInfo

經過了多種檔案型別載入的跟蹤除錯後，總結，

基本上檔案的載入函式有2個，都在CCFileUtils-win32.cpp檔案中，

1.FileUtilsWin32::getFileData

2.getData

要做解密的話，就是修改這2個函數了。

值得注意的一點是：getData函式的簽名是：

static Data getData(const std::string& filename, bool forString)

forString這個引數，用於標識讀入的檔案是不是一個文字檔案。

如果forString為真的話，buffer就要多分配一個位元組，用來放置C語言的字串結束符 \0 

截圖一下引擎的程式碼：

要做解密，我們的解密資料記憶體也要用forString來判斷是否多分配一個位元組的記憶體。

FileUtils單件類，很多函式是虛擬函式。FileUtils::getInstance，

在Windows平臺上，返回的是 FileUtilsWin32子類物件。

在Android平臺上，返回FileUtilsAndroid子類物件。

Cocos2d-x 3.4 實現在Windows和Android平臺上的解密需要修改2個檔案：

Windows 平臺的：cocos\platform\win32\CCFileUtils-win32.cpp

Android 平臺的：cocos\platform\android\CCFileUtils-android.cpp

這2個檔案裡面都有 getData 和 getFileData 函式，都需要修改之。

檔案資料的讀取在不同平臺上有不同的實現，

如果要在目標平臺上做資源加密，就需要修改目標平臺上的讀取實現。

FileUtils是一個檔案讀取基類，提供有預設的實現，一些平臺會提供特定的實現。

通過多型，FileUtils讓我們的遊戲客戶端程式碼不需要對特定平臺做特定處理，

也不需要關心FileUtils子類的型別。

比較遺憾的是，由於時間關係，目前我沒有找到對音訊檔案解密的方法。

除錯跟蹤發現，Cocos2d-x 在Windows上播放音訊是直接呼叫了Win32 API，這些介面API是輸入一個檔案路徑來播放音訊的。

之前有提到，做加密解密需要應用資料的介面從記憶體中獲取資料。

介面直接讀磁碟檔案，就沒有辦法干預檔案的載入進行資料解密了。

我覺得引擎的設計者，可以提供一個介面，利用觀察者模式，

讓引擎使用者可以在不修改引擎本身的情況下，干預資料的讀取進行資料變換來實現解密。

畢竟自己改引擎不是一個好的做法。

加密解密支援工具

一般要做資源資料加密，大體會做2件事：

1.寫一個工具，能對磁碟檔案進行加密。這個工具，可能需要遍歷資料夾、可批量選擇檔案等功能。

2.在軟體程式中加入解密功能，對工具加密後的資料進行解密。

工具能方便操作、提高生產力，很重要。

這裡，我自己做了2個工具。

1.對cocos2d-x引擎進行修改和恢復的工具，使其具備解密功能。如下：

2.對磁碟檔案進行加密解密的工具，方便打包時的批量篩選操作。如下：

這個工具能識別出文件是否已經被加密，原理是用了之前說的”加密檔案頭“設計。

這樣可以防止對已被加密後的檔案再次執行加密，防止對未被加密的檔案執行解密。

降低誤操作的可能性同時，也直觀地顯示檔案的加密狀態。

如果沒有”加密檔案頭“，工具程式就無法識別一個檔案到底是否被加密過。

加密解密的額外開銷

做了資源加密會降低程式的效能，原因很簡單，需要對檔案資料進行額外的處理。

稍微複雜一點的加密演算法，可能要申請記憶體空間來儲存解密資料。delete , new 都是耗時操作。

資源的加密也可能會使得apk包體體積增大。這是為什麼呢？

原因是，用Cocos2d-x 開發，資源會有很多*.plist *.ExportJson *.tmx 等檔案。

plist 可能是配置，也可能是粒子。

*.ExportJson 等檔案是 Cocostudio1.6 做出的動畫、UI 匯出檔案。

*.tmx 是Tilemap輸出的地圖格式。

以上說的這些檔案，都是用文字儲存資料的，可以用Windows記事本開啟檢視內容。

apk包實際上是一個壓縮包，壓縮演算法對於有大量冗餘資料的檔案壓縮率是很高的。

有興趣的同學可以看看。

我做過一個試驗，600多KB的 UI *.plist *.ExportJson 檔案，打成apk包後，實際上只佔60多KB。

這是因為壓縮演算法能對這些配置的文字檔案有很高的壓縮率。

如果我們的加密演算法會降低冗餘資料。

比如：一個檔案的內容是“111111...."，10萬個1。

我們的加密演算法為了增加安全性，會把這些內容加密成為："sfsadfsa...."。

解密者很難從無規律的不重複的資料推出原先的”111111....“的內容，

但同時對這樣的資料，壓縮率也會很低。

我之前設計了一個使用金鑰加密的演算法，會消除冗餘資料，

對於都是同樣的一個字元的內容，可以加密成一個看似無規律的亂七八糟的內容，

其實還是有規律可言，只是無規律迴圈節很大而已。

然後，這些加密後的資料，幾乎就不能壓縮了。

加密資源之後輸出的apk包相比沒加密資源的包，體積增加不少。

對於這種情況，可以僅對圖片等關鍵資源加密，而不對非關鍵性的文字檔案加密。

或者降低演算法的加密強度，保留資料冗餘性。