前幾天朋友讓我幫忙破解一個遊戲，奈何我太菜，Failed Over。
不過，在這個過程裏還是學到了很多東西。現在把筆記放上來，爲了以後自己查閱方便，也爲了更多人有方法可循。
在此感謝知乎和遊戲安全回答下的各位老大哥。Respect !
網頁遊戲破解
1.遠程文件引入
網頁遊戲的研發，常用框架來做。即request 的參數，作爲請求文件名的一部分來使用
2.SQL注入
注入原理方式和普通web操作無差別。但是在使用request來的參數時，過濾處理即可。
但往往研發會忽略請求參數過濾。所以，防禦方式做過慮處理，或者SQL預編譯。
-
待查：AMF消息 ，後端pinta模擬操作，請求接口，參數構造，webgame架構 ,數據存儲用Nosql，(java/c/c++的遊戲數據直接在內存中操作，遊戲關服才寫到DB)
3.通訊協議與消息格式
網頁遊戲的通訊協議並非全是http,也有很多用socket，以及http+socket並用/http+amf消息格式的做法。
-
http與https的取捨上，後者ssl啓用後，大量ssl解密加密運算，勢必增加服務器大量cpu壓力。
-
socket在遊戲中，除了聊天應用，在組隊、幫派戰等需要多玩家指尖同步數據信息
-
socket作爲所有業務傳輸的協議時，協議格式一般都是開源。比如msgpack、protobuf、及自定義的協議。（自定義協議，務必檢測整個消息包的每一個參數，類型範圍，避免個別超大數值，邊界數值出現，導致主程序內存越界，以至於服務宕機）
金幣複製&整型溢出
-
金幣數按日成指數增長，2^32=2147483647 . 同時在java中,4字節的存放Int型變量的範圍是 -2147483648至2147483647. 在java/c的有符號Int行存儲時，數的最高位描述符號位屬第32個位置。所以，實際範圍爲2^31個。
-
C中使用無符號數值類型，即可完成數值類型溢出刷錢行爲，但在java中，好像沒有無符號的類型。
-
所以在遊戲業務中，先做大小判斷，再做正正相加，不能得負。負負相加，不能得正,來判斷是否發生溢出問題。
金幣複製&併發請求
Rpg類型的網頁遊戲中，多數都有道具出售的功能。當玩家同時針對買入賣出時，瞬間大量併發請求，在服務器的處理邏輯一般有兩個進程處理。共享數據分別給數據庫中對應的賬戶餘額表。
-
當數據庫發生併發操作時，無論最後哪個進程寫入餘額，都是錯誤結果。
-
考慮找資料研究一下多種事務同時操作修改多個表的多條記錄時容易發生的死鎖問題。
6.金幣複製&邏輯漏洞
-
研發的邏輯不嚴謹。如DNF漏洞新聞（《利用網遊漏洞狂刷遊戲幣賺錢 玩家自爆三天賺十七萬》）
道具複製&揹包整理
類比剛纔金幣的讀入與寫入問題。穿裝備與整理包裹的請求併發。
-
查cgi線程的內存存放。
-
java/c的程序，數據放入內存的遊戲。鎖等待問題（鎖等待造成的線程佔用阻塞後面請求的處理，堆積大量請求導致系統負載升高服務器繁忙無法響應）--------------+ ★ 他團隊解決：用戶併發請求鎖
-
查nosql的K-V形式結構、redis的setnx接口
-
查 利用鎖的過期時間和nosql的過期機制實現用戶解鎖。
8 . 類CC攻擊&多用戶共享資源鎖的timebomb
-
redis 沒有成熟的事務處理機制，watch算不上關係型數據庫中的事務處理。對此，更需要對錶進行加鎖解鎖。
-
java之類的語言項目很多是直接操作內存的，更是需要資源鎖，來解決併發問題。（多個請求操作同一份數據的問題）
-
使用json消息格式的webgame要注意，php只是在接收請求時，做了大量數量的限制。在json解碼之後的數據中，是沒有處理的。
日誌
所有操作必須寫入日誌，當安全事件發生後，可以作爲各種數據回滾，交易糾紛處理的可靠數據。
協議與外掛
網頁遊戲意味着，網頁用的是瀏覽器。而瀏覽器支持普通的http協議的基本網頁數據通訊，支持以socket協議的flash插件或者java Applet 實現，以及unity 3D開發的遊戲。
-
flash的源碼很容易逆向出來，之後 通訊協議的消息格式也是一覽無餘。
-
定時更換通訊密鑰，防外掛
-
遊戲內部機制限制
-
人肉判斷，驗證碼
道具移動業務
從A位置移動到B位置，若兩者是同一類型，且可疊加，則疊加數量到其中一個上，並且銷燬另一個。
Hacking 角度
-
遊戲網頁分爲 flash 遊戲和html遊戲
-
flash 遊戲與服務端通信的消息格式有兩類：
-
flash特有的amf消息格式。
此格式可逆，一般外掛就會逆出這個格式然後自動化
-
http協議 ，導致的服務端安全問題和普通的網站基本沒有什麼區別
因爲此時服務器是nginx,lighttp,apache,tomcat之類，
服務端語言是 php, java，python 之類的。
-
-
有些flash遊戲，相關邏輯在客戶端進行，缺乏服務端驗證。反編譯出源碼很容易，比如用swfscan，很多時候的攻擊直接在瀏覽器中間人抓包攔截就更容易。
-
html遊戲
-
和服務端通信就是http了。如果用html5，也許會用websocket。不過由於是http協議，所以服務端安全問題和普通網站無區別。
-
由於是html , 所以在客戶端上還可能出現XSS,CSRF等問題。
這類客戶端安全問題可能導致用戶賬號被劫持等問題。
-
網頁遊戲角度
在防禦入侵，釣魚，外掛等安全方面，由於網頁受Web環境的限制，不太可能使用變態的通訊加密手段。大部分網頁遊戲還是都是純 HTTP API 的形式，沒有加密和混淆，容易抓包然後寫出腳本類。
-
大部分網頁遊戲沒有使用ssl,在不受信任的網絡中很容易被抓包，竊取敏感數據，或者釣魚。
-
另外網頁遊戲由於技術門檻低，在服務器的維護工作上不如客戶端網遊的服務器那麼正規，容易出現疏忽。而且網頁遊戲的服務器可能會用知名的軟件如Nginx等，和編程語言及框架，相比於完全自行編寫的客戶端網遊服務器，出現通用的漏洞的可能性比較大。
Another harvet
通訊協議
-
HTTP通訊可以採用 xml 或者 json,在通訊的可讀性上非常方便，但是缺點是在通訊中佔據了多餘的帶寬。
-
socket 通訊協議在可讀性上比http差太多。但只要前後端在協議的封裝上做好了，遇到問題也很容易解決。
-
HTTP協議在底層也是基於TCP/IP，但在單臺機器上，socket明顯要比http快，這也降低了web單臺服務器的瓶頸以及多線程問題。
遊戲安全
-
遊戲的基本數據多是保存在內存中的，玩家上線加載，存儲分爲三種
（離線存儲，定時週期存儲，直接存儲）
-
對於socket的協議來講，SQL注入的問題可以忽略，因爲是對內存數據的操作，所以不會對外來數據影響
推廣類小遊戲
-
開發周短，又考慮被禁封。所以通常直接使用html5的網頁開發。計算邏輯通過前端實現。
但 前端代碼很難加密。