Chống các phiên bản mod game trong NATV

changx

Game NATV xuất hiện bản mod từ phía ios như sau: https://iosgods.com/topic/195120-night-valley-tower-defense-v1022-2-jailed-cheats/#google_vignette
-> đúng với mô tả của mod, và trên web admin tool xuất hiện những người chơi phía ios sử dụng version này có thể mua hàng và tăng thêm gem, blueprint... (phiên bản 1.0.20, 1.0.22)
-> phía android sẽ xuất hiện bản mod sớm.

mod game là việc download bản origin về, chỉnh sửa lại file đã build như asset hình ảnh, âm thanh để cho đẹp mắt hơn, hoặc can thiệp bằng cách inject thư viện thứ 3 hoặc đoạn code rời từ bên ngoài vào, sử dụng reflection để can thiệp và thay đổi code chính, hoặc chỉnh sửa trực tiếp code gốc của tác giả (developer), kể cả là đã build IL2CPP để giúp game có những tính năng bất lợi cho tác giả như remove quảng cáo, thay đổi logic game, thay vì trừ gem thành cộng gem, mod speed
mình có thể làm là xáo trộn mã, vd như https://assetstore.unity.com/packages/tools/utilities/obfuscator-source-plug-and-play-code-protection-v2026-210262 giúp cho bản build ra tên hàm và biến trở thành các đoạn như a, b, c chứ không còn là origin name như TakeDamage, PurchaseGem, IsAlive như trong source code ban đầu, (ngoài ra biến các string thành các dạng mã hoá để chống search code) khiến mod khó hiểu và tốn nhiều công sức để có thể hiểu được hàm này có ý nghĩa gì, từ đó khiến mod sẽ mất nhiều thời gian, thậm chí nản và từ bỏ việc cố gắng mod bản game này.
-> lợi ích là chống mod hiểu được code thì chính nhà phát triển cũng gặp rủi ro trong runtime như sau: ví dụ dùng Newtonsoft.Json để parse 1 json như {type: "monster", hp: 500, damage: 300,...} thành 1 đối tượng class Monster { string type; float hp; float damage; }, thế nhưng các biến như type, hp, damage đã bị obfuscator đổi thành a, b, c thay thế, vậy thì lúc này parse json sẽ ra a, b, c null, có thể giải quyết điều này bằng cách thêm các attribute JsonProperty("type"), hoặc cho vào danh sách ignore list để obfuscator bỏ qua không thực hiện làm rối mã cho Monster.
-> đây chỉ là 1 trường hợp nhỏ, trong rất nhiều trường hợp khác mà chúng ta chưa nghĩ ra, chỉ có test thấy trường hợp thì mới biết.

vậy có cách nào an toàn hơn obfuscator?
có một giải pháp nữa là mọi code gốc đều không cần làm xáo trộn, và mình dùng kỹ thuật checksum để kiểm tra xem bản game đang chạy có bị thay đổi file code:

trong android, các bước thực hiện, sau khi build xong lấy ra checksum của file global-metadata.dat, libil2cpp.so cho vào trong integrity.json StreamingAssets của build.apk, đồng thời khi mở game lên, kiểm tra checksum hash của global-metadata.dat, libil2cpp.so hiện tại còn giống với checksum hash của integrity.json lúc developer build hay không, cấu trúc file integrity.json:

nếu hash không giống nhau chứng tỏ đã global-metadata.dat hoặc libil2cpp.so đã bị thay đổi, đây chính là bản mod.
điều này chỉ hoạt động trên file build.apk, còn file build.aab upload lên google play thì hoạt động như thế nào? khi download từ google play và cài đặt vào thiết bị thì có 2 file base.apk và armeabi-v7a.apk hoặc arm64-v8a.apk tuỳ theo kiến trúc thiết bị, mình chỉ cần kiểm tra trong cả base.apk, armeabi-v7a.apk hoặc arm64-v8a.apk các hash tồn tại và chính xác là được
nếu vậy kẻ tấn công sau khi mod chỉ cần chỉnh lại file integrity.json để hash khớp với lần chỉnh vừa rồi là bypass mất cái validate của developer thì sao? vì vậy mình cần xác minh độ hợp lệ file integrity.json là chính xác bằng cách dùng signature ký lại nội dung bằng private secret key (mỗi nội dung duy nhất thì signature là duy nhất, bất kỳ 1 thay đổi nhỏ kể cả dấu cách thì signature sẽ không chính xác), sau đó khi runtime kiểm tra xem signature này có hợp lệ hay không, là biết file này thực sự có bị mod chỉnh sửa hay không?
cấu trúc final integrity.json
đối với ios, công việc sẽ khác biệt một chút so với android, mình cần validate build.app/Frameworks/UnityFramework.framework/UnityFramework (thay thế cho libil2cpp.so của android)

trong hình dưới dây cho thấy có 3 file lạ (được bôi đen, đây là file và thư viện được inject kèm vào để thay đổi logic trong runtime) trong bản mod ios khác với bản build gốc của mình, vì vậy trong ios cần thêm 1 bước kiểm tra các file ở /Frameworks/* có file nào được thêm vào khác với bản gốc của mình hay không, nếu có nghĩa là file mod

Vậy kẻ tấn công chỉ cần tìm ra đoạn code thư viện kiểm tra của mình và sửa lại để bypass thì làm sao? Vậy mình cần xáo trộn mã của thư viện kiểm tra này, chống search text, thay đổi ý nghĩa tên hàm, class, ngoài ra có thể đặt thêm các code check giả để kẻ tấn công đi sâu vào đó nhưng không thể làm được gì vì code check thật đã bị che dấu kỹ ở nơi khác.
ví dụ về chống search text

tham khảo repo https://github.com/Pitaya-VN/AntiMod-Checksum, đã test build android apk, aab upload Google play internal testing, iOS
Cách sử dụng thư viện Antimod-Checksum:

if (useValidateAntiMod) {
    var validateResult = await CheckSum.CheckSumChecker.TryValidate();
    if (!validateResult.success) {
        SendReportUseMod(userId, validateResult.error);

        if (forceCrashIfMod) Application.Quit();
    }
}

Các settings mà developer có thể chỉnh sửa thêm nằm ở file CheckSumConstance.cs https://github.com/Pitaya-VN/AntiMod-Checksum/blob/master/Assets/CheckSum/Runtime/Scripts/CheckSumConstance.cs