頁遊安全攻與防，SWF加密和隱藏密匙

原文連接：http://netsecurity.51cto.com/art/201211/364775.htm

頁遊，最最核心的就是客戶端（swf）與服務端的遊戲通訊了。遊戲通訊產生的封包，內容是否可識別，可篡改，可重放，處理邏輯是否有漏洞，都決定了這款遊戲是否有重大的漏洞。

網頁遊戲的安全問題，在剛入職接觸的時候，寫過兩篇比較淺顯的文章。雖然頁遊安全整體上並無顯著變化，沒有新的攻擊方法，也沒有新的防護方法，我我的的工做重心也由頁遊安全轉向了手遊安全，但出於完美主義的偏執，仍是但願寫一篇覆蓋完整的頁遊安全文章，但願能給頁遊產業一點幫助。

1、協議安全（swf安全）：自動封包 （重點）

頁遊，最最核心的就是客戶端（swf）與服務端的遊戲通訊了。遊戲通訊產生的封包，內容是否可識別，可篡改，可重放，處理邏輯是否有漏洞，都決定了這款遊戲是否有重大的漏洞。

咱們知道頁遊前端和後臺的通訊通常有二者方式，一種是http鏈接，一種是socket鏈接，前者適用於小型頁遊，例如內嵌在QQ平臺的QQ農場，後者適用於大型頁遊。

不一樣的通訊方式，產生的數據包格式也不同，像HTTP AMF的可使用charles來抓包查看，像sockets的可使用WPE抓包查看。

以socket 通訊爲例，協議採用自定義格式，通常由兩部分組成，包頭與包體，包頭通常是固定長度，包體爲可變長度。包頭通常是一些基本信息，例如包長度，版本號，命令號，用戶ID，序列號等；包體就是操做命令對應的接收參數，參數個數不一樣，參數類型不一樣會致使包體長度不一樣。

只要摸清楚協議算法，即包是如何生成的，就能夠構造數據包與服務器自由通話，這一後果是很是嚴重的。自由通話意味着你不須要老老實實的在客戶端操做，一條數據包就能代替你一連串的操做，例如發送一條數據包完成一個任務，經常使用於快速升級，淘寶上的頁遊代練絕大多數都是採用的這種方式；自由通話更意味着你能夠繞過客戶端的邏輯判斷，傳任意參數給服務端。說到這裏，你可能以爲只要服務端能正常處理來自客戶端的參數，不出邏輯錯誤，不出配置錯誤，就萬事大吉。這種想法很常見，例如上海寶開公司的某個開發就說過，咱們的遊戲邏輯判斷都在服務端，咱們沒有外掛。我推測這我的應該不怎麼上外網。

理想是豐滿的，現實是骨感的，怎麼能保證後臺不將邏輯寫錯，策劃運營不將配置弄錯呢，特別是在高強度的通宵加班後。你可能說靠測試呀，中國頁遊行業，配給給遊戲的測試人員是很是少的，相應的測試時間也是遠遠不足的，而且測試技術也很是須要提升，總的來講，在頁遊行業，能作完整協議測試的公司很少。但玩家，特別是從事外掛製做代練服務的打金工做室會「幫你」好好地完全地作協議測試。他們會先反編譯客戶端上的SWF文件（緩存中的，內存中的）獲得協議生成算法，製做成封包工具，遍歷每一個協議號，每一個參數輸入，讓你的錯誤無從遁形。

我見過一個很是聰明的外掛製做者，在外掛中添加了腳本分享平臺，號召你們共同摸索，將有問題的封包以腳本的方式上傳以供你們下載，這種集思廣益真的很妙，腳本的分享會給「找bug」精神獎勵，將其賬號公佈出來以供你們瞻仰，所以樂意分享的人不少。並且做者還很負責的有腳本審覈機制，並支持快捷的查詢。這是什麼樣的用戶體驗呀，這就是頁遊外掛界的app store

看到這裏，你或許想，我保護好SWF文件，不讓其逆向不就好了嗎？有需求，就有知足需求的地方，市面上有很多給SWF提供加密服務的收費產品，例如Amayeta SWF Encrypt 和 DComSoft SWF Protector ，由於收費，沒用過這些產品，不知道具體原理，但據瞭解，最經常使用SWF加密方式，就是破壞SWF標準文件頭，經過向SWF的二進制文件的文件頭寫入無心義的數據，從而致使反編譯軟件沒法正常解析SWF文件。下圖是使用反編譯器打開加密的SWF文件，會提示沒法解析

咱們能夠對比一下采用這種加密方式的swf文件頭內容：

（1）未加密swf文件

 

正常的SWF文件，文件頭部是由一個三字節的標識符開始，爲0×4六、0×5七、0×53（「FWS」）或者0×4三、0×5七、0×53（「CWS」）其中之一。「FWS」標識符說明該文件是未壓縮的SWF文件，「CWS」標識符則說明該文件前8個字節以後（即文件長度字段以後）的所有數據爲開源的標準ZLIB方式壓縮。

（2）加密後的SWF文件

很明顯，文件頭部變成了無心義的符號。

實現函數示例（參考http://blog.sina.com.cn/s/blog_731fdd2b01010u9k.html）

有加密就有解密，加密的SWF文件須要還原，雖然反編譯不了加密後的SWF文件，但能夠反編譯解密文件找到解密代碼來還原加密SWF文件的文件頭。（參考 http://www.2cto.com/Article/201211/167406.html ）

很明顯，這種SWF加密方法沒什麼做用。因而你們想着如何用一種沒法反編譯的實現方法來隱藏加密算法，例如利用Alchemy可以編譯C/C++代碼爲AS字節碼但沒法被反編譯的特性來隱藏加密算法。其實我懷疑目前有工具將Alchemy還原成C了，例如ASV（actionscript view 2012)就號稱是目前最強悍的SWF解密工具，網上都有該工具的團購消息了。

我不懂SWF的加密解密，但我知道有一條萬能守則，任何加密在內存中都是解密狀態的。當沒法解密的時候，就從內存中查找導出吧，咱們能夠先使用SWF Memory Dumper從瀏覽器內存中導出解密並解壓縮的SWF文件，再用傳播程度都爛大街的碩思閃客反編譯獲得源碼。這一方法對遊戲協議安全來講，是很是很是很是悲劇的。以下圖所示，包的組成結構，包中各個字段的生成算法均可以經過逆向解密SWF文件得到！

例以下圖爲遊戲協議結構

例以下圖就是遊戲協議對應的命令號

例以下圖爲遊戲配置表

一切的一切，都註定了要想徹底解決協議安全問題，只有靠AS混淆了。目前有一些收費軟件提供AS混淆，例如secureSWF 。但奇怪的是，沒有多少頁遊公司實施AS混淆。

寫到這裏，或許你會幻想遊戲協議算法不會被逆向得知，那不就完事大吉了嗎？再次申明，現實是殘忍的，即便不知道協議算法，照樣能夠修改遊戲封包。咱們能夠經過耐心的反覆操做來對比封包的不一樣，定位到修改點。通常使用WPE工具，修改包體。WPE工具的關鍵就是過濾器，查找到符合指定特徵的封包，將特定的位置替換爲修改的值。以下圖所示，

除了封包篡改，最簡單的連封包結構都不要猜想的就是封包重放做弊了，例如打怪是一條封包，只要反覆重放該封包，就能輕易刷取經驗值了。

好的協議設計，必定要考慮到防護封包篡改和封包重放，最簡單的方法是在封包的某個字段加入一個序列號，該序列號包含包體完整性檢驗值，時間因素值，來區分封包是不是重放的，是否有被篡改。

有了好的協議設計，協議是否安全了呢？協議的實現方法在客戶端SWF中，這一事實又講安全問題引回到SWF被逆向的問題上，只要被成功逆向，一切努力都打水漂了。雖然防護艱難，但也不能放棄，一種方法不行，能夠用多種方法。總的來講，爲了協議安全，能夠作以下措施（不只僅從技術上）：

1.好的協議設計，防重放與篡改

2.SWF加密 ，注意加密算法的安全，最好AS混淆

3.耐心的作協議檢測，開發在提交測試前，作協議測試；測試在完成了功能測試，性能測試後也要搞好協議測試；策劃運營對配置表作認真的檢查；

4.設計一套監控系統，監控遊戲中的收益與消費，大量的刷取物品確定會在數值變化中體現出來；

5.留意遊戲論壇，遊戲QQ羣裏是否有新漏洞的披露，外掛是否有更新；

6.頻繁更換加密算法，與外掛製做者PK更新速度。

2、自動遊戲+加速

自動遊戲，簡單的說就是模擬鼠標或鍵盤對遊戲UI的操做，代替你作重複的工做。最簡單的自動遊戲腳本可使用按鍵精靈來製做，先對正常操做進行錄製，而後編輯，設置熱鍵，最後回放便可。程序實現中通常會有如下幾個關鍵函數

（1）模擬鍵盤

VOID keybd_event(

BYTE bVk, // 虛擬鍵碼

BYTE bScan, // 掃描碼

DWORD dwFlags,

ULONG_PTR dwExtraInfo // 附加鍵狀態

)

（2）模擬鼠標

VOID mouse_event(

DWORD dwFlags, // motion and click options

DWORD dx, // horizontal position or change

DWORD dy, // vertical position or change

DWORD dwData, // wheel movement

ULONG_PTR dwExtraInfo // application-defined information

)

自動遊戲的做弊方式常見於對戰刷怪類遊戲，自動識別地圖中怪物出現的位置，自動出招打怪，自動拾取掉落寶物。每每還會配合加速外掛，總的來講，就是靠達成那種不知疲倦（腳本操做）、準確度高（自動識別地圖中UI特徵）、快速（對頁遊就是加速flash的動畫播放速度）的操做方式來快速升級。

自動遊戲類型外掛的防護比較簡單，增長人機識別的因素，相似於論壇避免批量註冊，採用只有人類才能識別的驗證碼（題外話，很多網站的驗證碼其實能夠機器識別），例如對於對戰類遊戲，記錄每次對戰的頻率和操做時間特性，對異常的操做彈出圖片驗證，中斷自動遊戲。

在實施圖片驗證的時候，要考慮到兩個要素：

一是圖片是否真正的機器難以識別，要預防簡單的像素採集技術；

二是圖片庫是否及時更新，要預防圖片庫的遍歷。

而加速外掛，也常見於對戰類遊戲。改變操做速度有兩種狀況。一種是使用變速齒輪之類的加速外掛加快flash動畫播放速度，一種是速度值爲遊戲中的某個變量值，修改了對應的數值。

對於加快flash動畫播放速度的加速外掛，咱們能夠經過對比客戶端服務端時間是否同步來檢測，當檢測到異常的時候，能夠彈出圖片驗證，中斷加速。

對於速度由遊戲中數值控制的，作好協議安全，使其沒法改封包中對應的數值；作好SWF反逆向保護，使其沒法修改源碼中控制速度的邏輯。

3、內存安全：內存修改

修改遊戲在內存中的數值是經典的單機遊戲做弊方法，一樣也適用於網頁遊戲，緣由很簡單，不可能每一個來自客戶端的數據，服務端都作驗證。（看看頁遊公司開發前端和後臺的比例吧！）以社交類網頁遊戲爲例，其中會內嵌很多小遊戲，這些小遊戲多是用來賺取遊戲經驗或貨幣等數值的，很顯然，這種類型的小遊戲基本就是主邏輯在客戶端的單機遊戲，只是最後將遊戲分數上傳給服務器，服務器再根據遊戲分數的不一樣來下發相應數額的遊戲貨幣。咱們徹底能夠在積分上傳前，在內存中查找並修改該數值。 以下圖所示，用cheat engine去查找IE進程中游戲分數。

（cheat engine是我最喜歡的內存修改工具，手游上的內存修改工具和這個比起來簡直是胎兒版的。該工具支持自定義格式的內存搜索，具有強大的反彙編功能，更妙的是能夠直接生成外掛，特別讚的是居然採用了遊戲通關的方式來教授工具使用，個人博客中有第八關於第九關通關方法）

程序實現通常會有如下幾個關鍵函數

（1）讀取進程數據ReadProcessMemory

（2） 查找，查找算法能夠按數值類型、掃描類型及內存掃描方式來實現

例如數值類型有二進制，1字節，2字節，4字節（遊戲最經常使用），8字節，浮點數，雙浮點數，文本，字節數組，自定義（這個最牛）；

例如掃描類型能夠支持精確查找，模糊查找（比...大，比...小，二者之間），數值變化趨勢（數值處於增長中，數值出於減小中，數值沒有變更，與首次掃描數值相同，數值增長了某個指定值，數值減小了某個指定值）；

例如內存掃描方式有自定義掃描起始與終止地址，同時掃描只讀內存，深度掃描，快速掃描，掃描時暫停遊戲

（3）寫數據WriteProcessMemory

內存修改的防護，有如下幾種建議：

（1）重要數值在內存中拆分存放，使其沒法簡單定位到（會使得遊戲邏輯變複雜）

（2）默承認以修改，在服務端控制收益上線。（考慮到成本，爲目前主流控制方法）

4、存檔安全：存檔修改

在flas在flash單機遊戲時代，修改本地存檔文件，是遊戲做弊的重要方式，相信有很多人就用過Flash存檔修改器。

隨着頁遊興起到如今的頁遊繁盛，依賴於存檔進行邏輯判斷的設計減小了，但這塊也不能徹底忽略掉。總會有一些功能是須要調用本地存檔的。例如登陸模塊中，記住密碼功能，會將密碼信息存儲在本地，以IE瀏覽器爲例，在C:\Documents and Settings\（你的Windows用戶名）\Application Data\Macromedia \Flash Player\#SharedObjects\（一些隨機數字和字母）\ 文件夾下就能夠看到存儲密碼的SOL文件，可使用minerva工具查看，以下圖所示，密碼明文明文存儲的，SOL文件是永久性保存的，除非手動清除，若是玩家在公共環境下登陸，就會有盜號威脅。

也有些開發意識到了這個問題，而採用加密存儲方式，通常採用md5（其實md5不是真正的加密算法）。md5解密的在線網站很是多，以下圖所示，密碼經過兩次md5後存儲，咱們能夠在http://www.cmd5.com/ 查到。

因此建議存檔加密，採用自定義的加密算法，例如md5後轉置再md5，等等。

5、賬號安全/充值安全：盜號/低價充值

賬號安全和充值安全不只頁遊如此，全部遊戲，甚至全部線上應用都如此。若是說開是個大的話題，我僅僅介紹頁遊中常見的威脅與防護。

（一）、賬號安全

威脅：

1.外掛盜號

例以下面號稱能夠無限刷取遊戲貨幣的外掛，實際上在用戶輸入賬號和密碼後，將信息發送給盜號者的郵箱。

2. 社工盜號

在遊戲中獲取信任，覺得對方代練等好處爲引誘盜取賬號。或經過獲取我的信息，從密保問題下手進行盜號。

3.從遊戲的賬號管理中心等web入口下手，進行盜號。

例如登陸模塊沒有驗證碼或驗證碼實現機制漏洞，使用字典掃描批量盜號

4.傳輸嗅探盜號

5.利用賬號申訴流程漏洞進行盜號

例若有些申訴打分機制存在提供屢次充值證實就能夠取回密碼的方式，先充值，再盜號。

防護：

1.安全意識宣傳

2.弱口令檢測

3.異地登陸提醒

4.登陸行爲監控

5.設計好賬號相關功能，例如申訴流程

（二）、充值安全

威脅：

1.社工

在網上發帖慌稱發現充值漏洞，騙取貪心網友給本身指定的賬號進行充值

2.利用手機充值漏洞

使用快過時的手機廢卡進行充值，大多數的充值不會再次檢測手機卡是否存活狀態

3.利用寬帶充值漏洞

盜取寬帶賬號進行充值，因爲不會實際影響遊戲收益，頂多會出現受害者損失嚴重的狀況下投訴帶來的很差影響。

4. 真正的充值漏洞

好比說普遍採用的點卡充值，可能存在點卡被重放使用的漏洞

防護：

1.安全意識宣傳

2.充值相關功能的安全檢測

結論

總的來講，頁遊的各類外掛問題很廣泛，端遊有的它都有，但安全防護不如端遊，這很大程度上是由於頁遊的開發週期短，生存週期也短，例如較長的神仙道遊頁才兩年了，甚至大多數頁遊，只是爲了短期洗用戶搶錢，所以不會投入人力物力在外掛防護方面，或許第三方的安全服務會有點市場吧，好比說他們樂意購買支持多項目的AS混淆工具。總之，頁遊是個浮躁的市場，只有生命週期強大的遊戲，纔會注意到外掛問題。

 

==========================================================================================================================

SWF加密之隱藏密鑰篇

本片博文介紹的加密方式爲最基礎的隱藏密鑰的加密方式，固然目前來講這樣的加密方式也是能夠被破解的,也只是防君子不能放小人，加密最終極的辦法仍是混淆。（在swf文件個公開的狀況下，若是adobe不提供支持，大部分狀況下對swf的加密都是徒勞的），本篇只是對swf加密方式的一個整理，分享一種思路。若是您是swf加密高手很期待和您交流，
密鑰隱藏
破環swf標準文件頭是最簡單也是最經常使用的方法。 向swf的二進制文件的文件頭寫入無心義的數據，這樣就能夠致使破解軟件沒法正常解析swf。




如圖所示，向core.swf的ByteArray開始位置寫入無心義的數據，
這樣作的原理是Swf文件的前幾位表示這個swf的版本信息，以及解析swf須要的參數數據，把它修改成無心義的數據，反編譯程序天然也就沒法解析了， 固然若是你這樣作了以後，也會形成在運行時flashPlayer沒法解析core.swf，
    正所謂加密和解密是一定會是同時存在的一對好基友。因此咱們就須要在core.swf加載好以後把破環的文件頭還原回來，你就須要如一個正常的loader.swf來加載被加密的swf，而且把加載的swf文件頭還原回來。以下代碼

因爲總所周知的緣由，這樣作只能防君子不能防小人，只是增長了破解者一點點工做量而已，破解者不能直接反編譯core.swf、可是他能夠破解loader.swf來找到解密代碼(如上圖紅框的數字7是明文存在在loader.swf裏的)，來還原core.swf的文件頭。而後繼續用反編譯軟件進行反編譯，
 
參考資料 （摘自不知出處的地方）
SWF文件頭
       全部的SWF文件均以如下頭部開始：
SWF文件頭

字段	類型 *	說明
簽字標識	UI8	標識字符： 「F」表示未壓縮 「C」表示已壓縮（版本6或後續版本）
簽字標識	UI8	此標識一般爲「W」
簽字標識	UI8	此標識一般爲「S」
版本	UI8	單字節文件版本數（例如，0x06表示版本6）
文件長度	UI32	整個文件的字節長度
幀尺寸	RECT	單位幀的尺寸
幀率	UI16	每秒的幀數，其16個位是按照8.8的格式表示的
幀數	UI16	影片的總幀數
* 此類型在基本數據類型一節中定義

 

文件頭部是由一個三字節的標識符開始，爲0x4六、0x5七、0x53（「FWS」）或者0x4三、0x5七、0x53（「CWS」）其中之一。「FWS」標識符說明該文件是未壓縮的SWF文件，「CWS」標識符則說明該文件前8個字節以後（即文件長度字段以後）的所有數據爲開源的標準ZLIB方式壓縮。
 
上述方法僅僅只能防止一些對swf不瞭解的外行人，
 

 
如上圖紅框的數字7是明文存在在loader.swf裏的。 那如今的思路就很清晰了,要作的就是把好個明文的數字7給隱藏起來，達到讓破解者沒法還原core.swf文件頭。因爲swf文件格式是公開的，毫無保密性，因此任何用AS實現的加密算法都是耍流氓（沒用的），那咱們有沒有辦法用其餘方法來隱藏數字7呢。答案是有的：
有2種方法
1.alchemy
   Alchemy 可以編譯C/C++代碼爲AS3字節碼(運行在AVM2上)可以運行在Flash或者Flex平臺，而且Adobe宣傳Alchemy可以爲計算密集型任務提高性能(可是比原生C/C++慢)，
介紹完畢，我能夠看到adobe把alchemy吹的神呼其神，事實上好像確實不錯^_^。可是咱們今天要用到的不是alchemy執行C/C++代碼飄逸的效率，而是利用alchemy暫時（我只能說暫時，鬼知道之後asv會不會也能把alchemy給還原成C）沒法被反編譯的特性，有點旁門左道了，我想adobe搗鼓alchemy的初衷確定不是讓開發者用來加密本身的swf。但誰讓adobe把swf格式公開了呢(這裏扯個淡，任何東西均可能是雙刃劍，破解使開發的勞動成果被瞬間複製的同時也間接間或一部分紅就了flash的遍地開花，山寨起來容易啊，在天朝山寨纔是王道，我的觀點僅供參考，不要糾結flash真正火的緣由)，
 


如上圖爲alchemy的一個HelloWorld的示例程序，你能夠在C（alcnemy）返回咱們解密用到的數字7，或者你以爲用數字其不放心。能夠用個公式算一個數字出來返回。Alchemy的性能，我想再複雜的運算都是輕鬆搞定的。
 
 
如上圖所示。 我僅僅寫了個helloworld的程序。Alchemy就給我編譯出幾百個AS類來（截圖只是一部分），你能找出還原算法在哪一個文件裏面嗎。反正我是找不出，
 
還原時你要作的就是。 把alchemy編譯的swc放到工程庫裏，執行以下代碼，用返回的數字來歡迎core.swf的文件頭。




   
 
 
二:Pixel Bender
    Pixel Bender是Adobe開發的一種編程語言，用戶可使用該語言建立自定義濾鏡、效果和混合模式，以用於Flash、AE（After Effects）和Photoshop。
　　Pixel Bender與硬件無關，可高效地運行於各類GPU和CPU體系結構之上。Pixel Bender開發人員經過編寫Pixel Bender代碼來建立濾鏡。 欲知道詳情請點擊度娘
和alchemy同樣。Adone 搗鼓Pixel Bender的初衷確定也不是讓開發者用來加密本身的程序。可是沒辦法，被adobe逼的呀、 

 
如圖所示，你能夠在pixelBender的返回值裏，返回咱們還原core.swf須要的用到的數字7。
用pixelBneder解密的過程過程可能有點複雜，不能直接調用方法並返回值。須要監聽渲染成功事件。



如圖fuckNum（罪過粗口了）就是咱們的還原core.swf文件頭須要用到的數字了=======================================    好了。回到開始，以上介紹的加密方式目前來講都是能夠被破解的,只增長了點破解的難度，加密最終極的辦法仍是混淆。這裏只是對swf加密方式的一個整理，分享一種思路。若是您是swf加密高手很期待和您交流