2. Mobile Game Hacking - BZ

Moblie Game Hacking and Security 

 

周庭鈺 吳紹瑋 陳冠宇 劉昱揚 胥正誠

前言

現在免費連線手機遊戲主流:買斷單機 ,免費單機遊戲 +  (遊戲內付費 IAP In App Purchase)

而遊戲部分即為一網路服務,其組成必然為:Client-Server

為了取得遊戲中的獲利,除了 iap,剩下只剩非合法手段,分成四種方向

Hack Target:

Hack Clect / Hack server / Fack  Client / Fack Server

但方式可以分為以下五種 Hack Method :

1.Hack Client:

修改記憶體 (八門神器/遊戲修改大師),用以修改遊戲本身。

 

2.Hack Server:

尋找Server漏洞打斷他,像是APT (進階長期威脅)。

 

3.Fack Client ( Bot )

例如:Pokemon Map,遊戲外掛等

(按鍵)巨集、執行腳本/機器人,達到瞬移打怪,自動升級等效果

4.Fake Server  

只能欺騙自己,不能讓紀錄被儲存到真的伺服器上

5.MITM(Man In The Middle)

經由代理伺服器,對使用者假裝伺服器,對伺服器偽裝使用者

 。對使用者連線修改request

 。對伺服器回應修改response

 

觀察:錄封包

Wireshark

偷看內容

Burp Suite

HTTPS ( TLS/SSL )

Certufuacate Pinning?

 

wireshark

burp ( 類似  Proxy Server )

手機網路不穩定 (很少遊戲會開WS )

現在幾乎都會選擇走http/https

 

加密 解密  更新

 

觀察:反編譯

手機通常有雙平台:

開發友善的語言: Android

Java Decompiler : Java Bytecode -> 原始碼

 

大多數遊戲Unity開發:

Unity C# JS -> MS DLL

 

 

廠商會做Obfuscation(混淆)原始碼的動作防止反編譯

 

手機另外常見的檔案:(.so) Shared Object (類似Windows DLL )

Android 比較好反編譯 因為IOS反編譯是組語

補充:

若想要了解服務的行為就須了解背後他運作的機制,最直接現有的,就是手機上的程式本身,我們藉由反組譯去理解其運作機制:

手機APP通常會有開發雙平台: 即 Android 和 iOS。

Android 基於JAVA 開發,執行是Java Bytecode,即容易反組譯,。
應該說是容易就可以被反編譯出近乎原始的程式碼 (反編譯工具: dex2jar) 。

而 iOS 則是 ipa 檔案反組譯是將裡頭的 binary 檔案 ( 通常跟app名稱一樣 )
翻成組語而已其中解成組語是用 arm-elf-objcopy 和 arm-elf-objdump 指令 (Mono 是一個 .Net開源套件) ,
藉此來達到跨平台的效果 Mono为Unity提供了脚本化的环境。Mono目前支持的语言有C#、Visual Basic、JavaScript、Python、Boo等等。

我們能從DLL動態連結函示庫反組譯回C#,手機另外常見的檔案:(.so) Shared Object 。

我們也可以針對它做反編譯,有攻擊當然有防備的手段,也就是一些程式隱匿技術 ( Code obfuscation technique ):

1. shrinker(壓縮) :

  檢測沒有用到的類別、方法、變數、屬性 並移除。

2. optimizer(最佳化) :

  程式碼最佳化,縮少一些不必要的code。

3. obfuscator(混淆) :

  使用短又沒有語意的名詞 代換 類別、方法、變數 名稱。

4. preverifier(預校驗) :

  預校驗程式碼是否符合 Java1.6 或者更高的規範
 

實作:加密解密

 

App能做到的:理論上都能夠重現

從程式碼找出加解密方法!!!

一般分兩種

1. AES (對稱式 只有一組 key)

2. RSA (非對稱 需要public / private key 搭配) [ 一個存在Server,一個存在Client ]

 

使用被記錄到的資料

實作:傳輸方法(協定方法)

先了解App 在 HTTP (與其它網路應用層的) 做了什麼事情

注意 HTTP Header有沒特別資訊

壓縮/ 解壓縮

編碼/解碼

 

嘗試重新再送一次封包,如果 OK ,那就成功了

 

實作:傳輸內容

加密解密:一一了解每個錄到的API (傳輸格式、內容、時效、權杖......etc.)

了解程式碼中參數的來源或意義 ~

 

當你到這一步,你已經可以完成 Server / Client 了

 

HTTP 方法:

GET  單純取得資料 ( list Stage )

POST 上傳DATA    (Enter Game)

post/entergame

post/resultgame

 

確認防護機制
驗證資料正確性否?

有簽名(signature)的話能夠偽造?

(將封包所有內容Hash 後,一起加入到封包內傳給伺服器,伺服器檢查hash可以知道封包是否被更動:破解方法,修改封包後,重新hash封包,修改簽章後送去伺服器)

 

修改遊戲關卡值會發生什麼事?

 

確認什麼能做什麼不能做

加解密的KEY不一定可以取得,簽名不一定能偽造

 

1.修改記憶體 (限制多 JB/權限,能做的事太少 修改數值)

2.修改遊戲

 

舊版Android 漏洞:修改程式碼而不更動到驗證簽章

https://github.com/Fuzion24/AndroidZipArbitrage

若APP 不會驗證簽名,就可以自己建立驗證

 

Case Study

 

Case A. CC

 

Burp Suite 抓取,因為內容沒有加密,可以直接修改

寫 Bot 抽獎( 透過觀察參數變化 , 修改取得自己想要的東西)

 

HMAC SHA1(但key就在程式碼裡....)

 

金鑰雜湊訊息鑑別碼

https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

 

Android 寫隻程式用JNI直接呼叫.so內部的function

(直接載入他們的Libary)

JNI - Java Native Interface

 

後來發現:Android 封裝的簽名會影響getKey方法

改APK/or重新包裝->失敗

 

每次換一次key都要重新編譯專案 -> 很麻煩

 

XOR

 

1 0 0 0 1

1 1 0 0 0

1 0 0 0 1

1 0 1 1 0

1 0 1 1 0

1 1 0 0 0

 

{

“result”:{},

“res”: 406;

“msg”: “not found”

}

 

無法修改Request 只能修改Response
 

 

Case B. 白貓

 

紀錄遊戲封包,傳輸內容經 AES 加密

但是加密用的IV存在程式碼中

(initialization vector,初始向量,以初始向量加上種子作為密碼)

 

每個USER會有一把獨立的KEY

驗證前會有一把公用key確認身分

然後一直改用獨自的key

 

沒辦法改回傳資料( 無法取得 Server 簽章 Key )

所以轉向了BOT

 

Bot 要加上擬真參數( 中間隨機延遲、傷害控制、移動速度 )

 

Pokemon GO

Protocol Buffer 被人們反組譯解出來,接著出現各種語言加解密功能的API Library

 

結論 - 要保持低調