10 — Kiếm tiền: Quảng cáo (IAA) + Mua trong ứng dụng (IAP)

Nguồn: chưng cất từ restore SOT com.Chodun.CatGunner 1.1.59 (BardCat). Mọi C# / công thức ở đây là L1 ANALYSIS — đọc từ ARM64 / Hex-Rays của libil2cpp.so tại RVA ghi kèm, từ IL2CPP metadata đã giải mã, từ Main.unity, và từ hai lượt probe trên thiết bị: (quan sát IAA dưới segment 1 trên bản .sot — save riêng, đã pm clear sau khi xong). Không phải source gốc.

Ranh giới R1 / R9. SDK quảng cáo, IAP, attribution, offerwall KHÔNG được tích hợp vào bản restore — chúng nằm sau interface fail-closed (IAdService, IPurchaseService, …) và không bao giờ được cấp thưởng, entitlement hay purchase. Tài liệu này chưng cất THIẾT KẾ kiếm tiền (placement, trigger, gate, offer, timing), không chưng cất nội tại SDK. Không có đoạn nào ở đây mô tả cách giả mạo mua hàng hay bỏ qua quảng cáo.

Liên quan: 01 Kinh tế · 09 Prestige · 07 Tiến trình · [liveops catalog: LIVEOPS_SURFACE.md] · [liveops catalog: UNLOCK_GATES.md] · [liveops catalog: PROBE_RESULT.md] · [liveops catalog: PROBE_RESULT.md]

1. Vì sao monetization là "song sinh" của core loop

Trong game idle, người chơi chờ. Mọi thứ rút ngắn cái chờ đó là hàng hoá. CatGunner bán đúng 4 thứ:

Hai cột không cạnh tranh nhau — chúng xếp tầng: cột IAA là cách người chơi F2P nếm trải giá trị của multiplier; cột IAP bán chính cái multiplier đó ở dạng vĩnh viễn. Đó là toàn bộ ý đồ thiết kế. Điểm nối kỹ thuật của hai cột là Shop_manager.Is_Remove_AD_All / Is_Buff_Pack — hai cờ non-consumable đọc trực tiếp bởi tầng quảng cáo (§4.1, §5).

2. Stable truths

Mức bằng chứng: disasm-proven = ARM64/Hex-Rays tại RVA ghi kèm · metadata-proven = IL2CPP metadata đã giải mã (dump.cs / field-default-value blob) · scene-YAML = đọc từ Main.unity · runtime-verified (live) = đo trên thiết bị bằng probe đã disasm · UNKNOWN = chưa biết, không được thay bằng số hợp lý.

2.1 Tầng quảng cáo (IAA)

2.2 Tầng IAP

2.3 Phân khúc (segment) — công tắc tổng của IAA

Bản giải thích dân dã đầy đủ: docs/functions/segment-lieu-ops.md — segment là gì bằng ví dụ đời thường, vòng đời một người chơi (cài → attribution → cấu hình → placement → đo → chọn cấu hình thắng), phân biệt ba tầng segment / ServerConfig / placement, danh sách cạm bẫy khi tự dựng, và mục "Nếu bạn muốn tự làm" 13 bước. Viết cho người không đọc disasm; mọi số và RVA ở đó lấy từ mục này.

ĐÍNH CHÍNH (QD-28, 2026-09-06): ba nút Seg 0/1/2 của panel debug gốc KHÔNG phải R1-out — docs/functions/cheat-panel.md từng xếp nhầm chúng vào cột "sẽ không dựng". AppsFlyerInit.Cheat_SetSegment (0x2A600CC) không gọi hàm SDK AppsFlyer nào: nó đặt Segment (static 0x8) + SegmentCheatOverride (0x21), ghi PlayerPrefs["af_segment"] / ["af_segment_cheat"], đổi nhãn segmentText, rồi gọi ServerConfig_manager.Cheat_OnSegmentChanged() (0x2AC96D0 — phát OnConfigApplied + SaveSystem.Save). Đã dựng 1:1, không lấn R1. Cái thật sự R1-out là đường AppsFlyer gán segment từ mạng (OnUserSegmentReceived → ApplyServerSegment), xem §9.3.

2.3a Chứng minh ánh xạ 12 số → 12 field (đọc theo OFFSET, không theo thứ tự tên)

Đây là chỗ dễ sai nhất của cả tài liệu, nên ghi lại nguyên văn phép ghi bộ nhớ. EmbeddedDefaults(1) (0x2AC7B20) ghi ba khối 16 byte vào object ConfigResp:

*(_OWORD *)(obj + 40) = xmmword_105B0E0;   // 0x28 .. 0x37
*(_OWORD *)(obj + 56) = xmmword_105D5A0;   // 0x38 .. 0x47
*(_OWORD *)(obj + 72) = xmmword_105B890;   // 0x48 .. 0x57

Giá trị đọc từ .rodata (IDA get_dword): 105B0E0 = [15, 35, 10, 12] · 105D5A0 = [0, 6, 2, 0] · 105B890 = [0, 0, 99999, 1]

Ghép với offset field của ConfigResp (dump.cs:589438):

Nhánh segment != 1 ghi vdupq_n_s32(0x1869F) = 99999 vào cả 4 ô của khối đầu và 0 vào 8 ô còn lại; segment = 2 nếu tham số là 2, ngược lại 0.

interstitial ở 12, FreeCash bật ở 15 và ẩn ở 36. Nếu ánh xạ bị lệch một nhịp (offerwall ← 35, inter ← 15) thì OfferWall phải lật ở 35 và interstitial ở 15 — đo được là không. Hai kênh độc lập (byte trong .rodata + hành vi trên thiết bị) cùng chỉ về một bảng.

3. Danh mục AD_Type — 10 giá trị và mỗi giá trị mở cái gì

public enum AD_Type — dump.cs:584959. Dispatch: Admob.Reward_Get() 0x2A5F0B0.

Ghi chú quan trọng: IsBuffActive(type) trả true cho mọi type khi IsPermanentBuff — nghĩa là buff_pack bật vĩnh viễn cả hai buff, không phải một (0x2AE4AF8). GetBuffRemainingTime trả -1 khi vĩnh viễn (0x2AE4B4C) → Buff_Panel.Update (0x2AE4D4C) hiểu -1 là "ẩn nút xem QC, fill = 1.0".

4. Bề mặt IAA — 6 loại placement, 28 điểm kích hoạt quảng cáo trong code

|---|---|---|---| | Rewarded | 13 điểm gọi ShowRewardAd(AD_Type) (+1 overload ShowRewardAd(int) nối từ scene) | AD_Cool, _isShowing, is_AD_Disable_Version, mạng | Chạy (rewarded KHÔNG bị segment tắt) | Chạy | | Interstitial | 9 (5 Inter_Place) | 7 điều kiện §4.2 | Tắt (inter_stage_min = 99999) | Đủ tư cách chỉ Rebirth (6/ngày) + Mine (2/ngày) từ Stage 12 | | Banner | 3 show / 3 hide | Is_Banner_Blocked | Chạy khi vào Boss/Hunt/Raid | như segment 0 (không bị ServerConfig gate) | | OfferWall (Tapjoy) | 2 (Open_Hud, Open_Shop) | offerwall_stage_min | Tắt (99999) | BẬT từ Stage 10, vĩnh viễn | | FreeCash (AlmediaLink) | 1 panel + HUD + banner shop | freecash_stage_min + trạng thái Almedia | Tắt (99999) | Cửa sổ Stage 15 → 35, ngoài khoảng thì ẩn | | Ad-gun weapon_02 | (dùng lại 1 trong 13 điểm rewarded; CheckAdGunEvent là trigger cấp súng thử, không phải điểm hiện quảng cáo) | weapon_02_ad_onoff | Tắt (0) | BẬT (1) |

4.1 Rewarded — Admob.ShowRewardAd(AD_Type) 0x2A59294

ShowRewardAd(AD_Type type):
    if (Shop_manager.instance == null) -> NRE
    // ĐƯỜNG TẮT ENTITLEMENT (không có quảng cáo nào được hiện)
    if (Shop_manager.Is_Remove_AD_All || FreeCash_manager.RewardAdRemoved):
        ad_type = type; StartCoroutine(Reward_Get()); return       // @0x2a59310..0x2a59334
    if (is_AD_Disable_Version)            -> Alert("Try Later"); return
    if (_pendingShow || _isShowing)       -> Alert("Try Later"); return
    if (AD_Cool > 0)                      -> Alert("Try in {0} seconds", (int)AD_Cool); return
    ad_type = type
    if (rewardAd != null && rewardAd.IsLoaded() && Is_LoadedAdExpired())   // > 50 phút
        Log("[ADX] Loaded rewarded ad expired -> discard & reload"); Discard_RewardAd()
    if (rewardAd != null && rewardAd.IsLoaded())  -> TryShowLoadedAd()
    else if (!_sdkReady)                          -> Alert("Try Later")
    else if (Application.internetReachability == NotReachable) -> Alert("Check Network Connection")
    else { _pendingShow = true; ShowAdLoadingPanel(); StartLoadTimeout(); LoadRewardedAd(); }

Reward_Get() (0x2A5F0B0) — chạy sau khi SDK báo earned:

yield return null                                   // 1 frame
AD_Cool = 20.0f                                     // giãn cách toàn cục
Sound_manager.PlaySfx(7)
if (!Shop_manager.Is_Remove_AD_All)
    AppsFlyerInit.SendLog_AdsReward(AF_CODE[(int)ad_type])   // [5,6,1,2,3,4,7,8,9,10]
switch ((int)ad_type) { 0,1 -> Buff_manager.AddBuff(ad_type); 2 -> SpeedRun.Bonus_Get(); ... }

Bài học thiết kế: phần thưởng KHÔNG được trao trong callback của SDK mà trong một coroutine của game — nên đường "đã mua xoá quảng cáo" tái dùng đúng cùng một đường trao thưởng. Một điểm trao thưởng duy nhất = một điểm để kiểm toán. (Trong bản restore, đường này nằm sau IAdService fail-closed: NullAdService.ShowRewarded() trả failure, coroutine trao thưởng không chạy.)

4.1a Nhánh Granted — SỐ ĐO THẬT đầu tiên trên thiết bị (F024, 2026-09-06)

Cho tới 06-09, mọi thứ trong §4.1 là đọc từ binary: bản dựng lại đi qua IAdService, và NullAdService (fail-closed theo R1) luôn trả NotAvailable, nên không một nhánh nhận thưởng nào từng chạy trên máy. F024 (QD-23, và R1a trong quy tắc dự án (nội bộ)) thêm một provider quân xanh (SimulatedAdService, chỉ có dưới CATGUNNER_LEARNING_DEBUG, chỉ bind khi bật công tắc) để chạy được nhánh đó và đo. Quân xanh KHÔNG chứng minh luồng quảng cáo đã restore 1:1 — cái được nghiệm thu 1:1 là phía game xử lý callback.

Placement Mine_Bonus (AD_Type 3) — đo trên Pixel 8 Pro, APK f024-sim:

⇒ Xác nhận bằng số đo cái mà trước đây chỉ suy từ binary: tổng tiền của một ván Mỏ có xem quảng cáo đúng bằng 4 × Reward_Value, và hệ số của riêng nhánh quảng cáo là 3×, không phải 4×. Sai lầm dễ mắc khi chỉ đọc UI: nhãn ghi ×4 nhưng hàm chỉ cộng 3×.

Placement Fish_Gacha (AD_Type 7) — đo trên Pixel 8 Pro, APK g1722, hồ sơ p54 (2026-09-11):

⇒ Bài học placement đáng chép: quảng cáo ở đây KHÔNG mở thêm lượt — nó chỉ được cài vào 2 lượt CUỐI của 5 lượt miễn phí mỗi ngày. Lượt xem quảng cáo vẫn cộng FreeGachaCount y như lượt free, nên trần vẫn là 5/ngày. Đây là mẫu "gate muộn": người chơi nhận 3 lượt không ma sát để hình thành thói quen, rồi mới bị hỏi xem quảng cáo cho 2 lượt còn lại — khác hẳn mẫu Mine_Bonus (quảng cáo NHÂN phần thưởng lên 4×). Hai mẫu này nên được phân biệt rõ khi thiết kế: gate lượt vs nhân thưởng. SPEC: [evidence codegen: SPEC-F024-T4-fish-gacha.md].

Placement Power_Buff (AD_Type 1) / Money_Buff (0) — đo trên Pixel 8 Pro, APK g1722 (2026-09-11):

Đường bấm: biểu tượng x3 trên HUD mở popup Buff (hai thẻ Power/Money, mỗi thẻ một đồng hồ và một nút +5 min có icon video). Bấm +5 min → ShowRewarded → Granted → Buff_manager.AddBuff 0x2AE4510.

⇒ Mẫu placement thứ ba, khác cả Mine_Bonus (nhân thưởng) lẫn Fish_Gacha (gate lượt): đây là "nạp thời gian có trần" — phần thưởng cộng dồn nhưng bị kẹp, nên người chơi được khuyến khích xem ĐỀU (3 lần/15 phút) chứ không xem dồn. Hai chi tiết 1:1 dễ bỏ sót: AddBuff gọi Cat_manager.Balance_Reload() ở MỌI AD_Type kể cả loại không phải buff; và GetBuffRemainingTime dùng −1f làm sentinel "vĩnh viễn" cho gói Buff IAP. SPEC: [evidence codegen: SPEC-F024-T4-power-buff.md].

Placement SpeedRun_Bonus (AD_Type 2) — đo trên Pixel 8 Pro, APK g1722, p344 (2026-09-11):

⇒ Cùng khuôn Mine_Bonus: Reward_Value = 30 (hằng duy nhất trong .cctor 0x2B42214), panel trả 1× lúc mở, Bonus_Get (0x2B40E10) trả thêm 3× ⇒ nhãn ×4 là TỔNG, nhánh quảng cáo chỉ cộng 3×. Tổng +120 là số đo; phần tách 30+90 là suy từ L1 (chưa chụp riêng Dia lúc panel mở). Bốn mẫu placement đã phân biệt được: nhân thưởng (Mine_Bonus, SpeedRun_Bonus), gate lượt (Fish_Gacha), nạp thời gian có trần (Power/Money_Buff), mở nhánh khác (Upgrade_Rebirth). SPEC: [evidence codegen: SPEC-F024-T4-speedrun-bonus.md].

Placement Boss_Bonus (AD_Type 4) — đo trên Pixel 8 Pro, APK g1722 (2026-09-12):

Đây là placement đầu tiên đo được CẢ HAI nhánh bằng số, nên nó là chỗ chốt cho khuôn "nhân thưởng" mà Mine_Bonus/SpeedRun_Bonus mới chỉ suy từ L1:

⇒ thắng cấp 1× (150), quảng cáo cấp thêm 2× (300); nhãn 450 trên panel là TỔNG, nút từ chối ghi đúng phần đã cấp. Khớp Boss_manager.Reward_Value = 150 (.cctor 0x2AF2F14), Game_Win 0x2AF1C2C (Get_Dia(reward), Bonus_txt = reward*3), Bonus_Get 0x2AF21B0 (Get_Dia(reward*2) rồi Game_Exit()).

Bài học dàn cảnh (đắt, đã trả giá hai phiên): chế độ Boss vô hiệu hoá Upgrade Power/Speed (panel vào Boss ghi thẳng ra), và máu boss theo Boss_manager.Stage_Now (save Boss_Stage) chứ không theo Stage_Value_Max. Muốn thắng để chạm nút quảng cáo thì nâng rebirth và hạ Boss stage, đừng nâng Upgrade. Trigger interstitial cũng lặp lại đúng mẫu Mỏ: bỏ qua thì có, đã xem rewarded thì không. SPEC: [evidence codegen: SPEC-F024-T4-boss-bonus.md].

Placement Mission_Reward (AD_Type 6) — đo trên Pixel 8 Pro, APK g1722 (2026-09-12):

Mẫu thứ năm, và là mẫu dễ bị xếp nhầm nhất: quảng cáo ở đây không nhân phần thưởng, nó là một cổng đặt trên mốc battle-pass.

Nhận đúng mệnh giá in trên ô, không hơn một dia. is_AD_Reward (nội tuyến trong Reward_Get 0x2A71A34) = Lv >= 3 && Lv % 3 == 0 && degree == Normal, và đã kiểm bằng mắt: sau khi nhận Lv 3 thì ô mang biểu tượng phim kế tiếp là Lv 6 — đúng chu kỳ 3.

Kèm theo là một chi tiết UX đáng chép: mốc bị khoá tuần tự (is_Reward_SequenceLocked, Alert Mission/SequenceLocked), và mỗi lần nhận xong dải phần thưởng tự cuộn tới mốc chưa nhận đầu tiên. Người chơi vì thế luôn nhìn thấy đúng một "việc kế tiếp", và cứ 3 việc thì có 1 việc đòi quảng cáo — nhịp ép xem quảng cáo được gài vào tiến trình, không gài vào kết quả trận đấu như nhóm *_Bonus. SPEC: [evidence codegen: SPEC-F024-T4-mission-reward.md].

Placement AD_Reward_Gun (AD_Type 9) — mẫu THỨ SÁU: cho mượn rồi đòi lại. Đo trên Pixel 8 Pro, APK g1726 (2026-09-12), sau khi dựng L1 cả cụm Gun_manager (xem SPEC).

Đây là mẫu sắc sảo nhất trong sáu mẫu, vì nó không bán một phần thưởng — nó bán quyền giữ lại thứ bạn đã cầm trong tay:

1. Ngay sau lần hợp nhất súng đầu tiên, game đặt khẩu súng số 14 (hạng B, tốt hơn hẳn thứ người chơi đang có) vào thẳng kho, kèm đồng hồ đếm ngược 1800 s hiện trên ô.
2. Chạm vào nó, trang bị nó, hay hợp nhất nó — cả ba đều bật lời mời xem quảng cáo (Gun_Item.OnPointerUp, Gun_Item_List.EquipToSlot, Gun_Item_List.FuseItems).
3. Xem xong: đồng hồ biến mất, súng ở lại. Không xem: hết 1800 s, Update (nhịp 0,25 s) gọi AdRewardGun_Expire và rút súng khỏi kho.

So với "nhân thưởng", đòn bẩy tâm lý đảo chiều: người chơi không cân nhắc được thêm bao nhiêu mà sợ mất cái đang có. Hai chi tiết cho thấy thiết kế được mài kỹ: Update hoãn thu hồi khi quảng cáo đang mở (Admob.IsRewardAdBusy) — không ai xem hết quảng cáo để nhận về ô trống; và CheckAdGunEvent bỏ qua người đã có súng hạng ≥ B (đặt cờ mà không tặng gì) — mồi chỉ dành cho người nó thật sự cám dỗ được.

Cổng bật/tắt nằm ở liveops: weapon_02_ad_onoff == 1, và bản production đang TẮT cho phân khúc 0 (đo được từ ServerConfig_Cache của hồ sơ store thật). Bảng nhúng của client chỉ bật ở phân khúc 1. SPEC: [evidence codegen: SPEC-F024-T4-ad-reward-gun.md].

Sáu mẫu placement đã phân biệt được (xương sống để chép sang game khác):

Trigger phụ đo được cùng lượt — interstitial khi thoát Mỏ. Mine_manager.Game_Exit bắn interstitial chỉ khi _bonusAdWatched == false (cờ +0x72, do Bonus_Get bật). Đo: - thoát bằng Không, cảm ơn (chưa xem thưởng) → có interstitial; - thoát bằng đường Bonus_Get (đã xem thưởng) → không interstitial.

Đây là một mẫu thiết kế đáng chép: người chơi vừa xem một rewarded thì được miễn interstitial ngay sau đó — tránh dí hai quảng cáo liên tiếp vào đúng người vừa hợp tác.

Trạng thái đo của 10 placement. Tới 2026-09-12 (phiên 5aad97a9): 10/10 đã chạy nhánh Granted trên máy VÀ 10/10 có SỐ. Bảng này giờ không còn ô trống:

Bài học phương pháp từ ô cuối này: dòng cũ ghi "Săn là chế độ điều khiển tay ⇒ PetCoin_Accum = 0 khi để mèo tự đứng" — sai. Giả thiết "chế độ tay thì không tự tiến được" chưa từng được thử; thử ĐÚNG MỘT LẦN (vào màn, đợi 60 s, thoát) là ra số. Trước khi ghi một ô là "không đo được vì điều kiện màn", hãy bỏ 60 giây đứng yên trong màn đó.

Chi tiết bộ giả lập + cổng an toàn (bản identity không chứa một byte nào của nó): docs/functions/gia-lap-quang-cao-iap.md.

4.1b Mẫu "quota ngày có phần cho không + phần gắn quảng cáo" — placement Fish_Gacha (F008 T5b)

Đây là kiểu placement thứ hai của game, khác hẳn §4.1/§4.1a. Mine_Bonus là nhân phần thưởng vừa nhận (một lần, ở cuối một ván). Fish_Gacha là một quota ngày có hai đoạn: đoạn đầu cho không, đoạn sau gắn quảng cáo. Đo trọn từng nấc trên Pixel 8 Pro, APK f008-t5b2, 0 exception.

FreeGacha():                                      // Fish_manager 0x2B00A24 — CHỈ định tuyến
    FreeGacha_Reload()                            // nạp lại quota nếu sang ngày mới — doc 07 §3.7
    if (Inventory.Count >= MAX_FISH)  -> Alert(MaxFish);      return    // trần kho chặn TRƯỚC
    if (FreeGachaCount >= 5)          -> Alert(MaxFreeGacha); return    // hết quota
    if (FreeGachaCount >= 3)          -> ShowRewarded(Fish_Gacha); return
    FreeGacha_RewardGet()                                              // cấp NGAY, không quảng cáo

Đo được: ba lượt đầu ra thưởng ngay (x5 → x4 → x2, chỉ số cộng đúng bảng); lượt thứ tư hiện biểu tượng và đi nhánh rewarded, Granted → thưởng vào kho, nhãn x1; sau lượt thứ năm nhãn x0, biểu tượng biến mất, nút đổi màu disable. Save đối chứng: FreeGachaCount 3 → 5.

Ba quy tắc rút ra:

1. Phần cho không phải đứng TRƯỚC phần gắn quảng cáo, không được trộn lẫn. Ba lượt đầu là dạy giá trị: người chơi thấy phần thưởng rơi ra và thấy chỉ số nhích lên ngay trên cùng màn hình. Tới lượt thứ tư, câu hỏi "xem quảng cáo chứ?" mới là câu hỏi có giá đã niêm yết. Gắn quảng cáo từ lượt đầu biến bề mặt thành máy bán hàng cho một món chưa ai biết giá. Ngoài ra, phần cho không giữ lý do quay lại hằng ngày cho cả nhóm người không bao giờ xem quảng cáo — bề mặt IAA không đuổi ai đi. Và biên trên (5) giữ cho nó không thành máy cày.
2. Đặt cổng đếm bằng HAI hằng số trên MỘT bộ đếm, không bằng hai bộ đếm: FreeGacha_MaxCount = 5 và FreeGacha_NoAdCount = 3 cùng đọc FreeGachaCount. Đổi tỉ lệ cho-không/gắn-quảng-cáo chỉ là đổi một số; không có trạng thái thứ hai để lệch pha với save.
3. Hiển thị biểu tượng quảng cáo theo DẢI, không theo NGƯỠNG. csharp AD_Draw_Icon_obj.SetActive((uint)(FreeGachaCount - 3) < 2u); // count ∈ {3,4} Một phép trừ + một so sánh unsigned bắt trọn cả hai biên. Viết count >= 3 thì biểu tượng dính lại vĩnh viễn sau khi hết quota và người chơi bấm vào một nút hứa quảng cáo để nhận về một thông báo lỗi. Tổng quát: visible = (uint)(used − free) < adSlots.

Cùng bề mặt còn có một nút trả tiền, và nó KHÔNG mua tỉ lệ tốt hơn — nó mua một SÀN cao hơn. Cả hai nút dùng chung một bảng tỉ lệ cộng dồn — {60, 30, 10, 0} đọc từ scene (Main.unity:20930271); nút miễn phí trả baseGrade + i với baseGrade = 0, nút 200 Dia trả baseGrade = 1. Vì mỗi bậc mạnh gấp ~3, dịch một bậc đã là gấp ba — không cần bảng tỉ lệ thứ hai. Ưu điểm kiến trúc: một bảng duy nhất phục vụ mọi nút, thêm một hạng nút chỉ là Roll(base + 1), không có hai bảng để lệch nhau. (Đo: Dia 1368 → 1168.)

Hai điều đáng đọc trong bảng này. (a) Phân phối lệch mạnh về bậc nền và đuôi bị cắt cụt — gacha ở đây là máy rót nguyên liệu, không phải máy tạo bất ngờ; toàn bộ cảm giác tiến bộ được đẩy sang mạch hợp nhất. (b) Ô thứ tư giữ chỗ nhưng để 0: bậc thưởng cao nhất có sẵn slot, bật lại chỉ là đổi một số trong scene, không phải sửa code — một mẹo vận hành rẻ cho live-ops.

⚠️ BẪY ĐÃ LÀM SAI MỘT LẦN Ở CHÍNH TÀI LIỆU NÀY (G1682). GachaChances là field public ⇒ được serialize ⇒ giá trị trong Main.unity thắng lúc chạy. Ctor 0x2B01D08 ghi {40, 30, 20, 10}; bản đầu của §4.1b chép con số đó và publish ra dashboard. Bảng thật là {60, 30, 10, 0}. Cái bắt được lỗi là một quan sát trên máy: năm lượt Epic liên tiếp đều ra hạng thấp nhất — 0,6⁵ ≈ 7,8% (bình thường) so với 0,4⁵ ≈ 1% (đáng nghi). Quy tắc: với mọi bảng tỉ lệ / bảng giá / bảng cân bằng, kiểm loại field trước khi tin con số — xem doc 07 §4 mục 16. Ctor vẫn phải chép vào code (initializer là nợ 1:1 thật), nhưng viết con số của ctor vào tài liệu như cân bằng của game là sai. Hai việc khác nhau.

Thứ tự cổng có ý nghĩa đạo đức, không chỉ kỹ thuật: nhánh trả tiền kiểm kho đầy TRƯỚC khi kiểm tiền, nên kho đầy thì không bị trừ Dia. Đảo lại là ăn cắp.

Bẫy dựng lại (G1681): chép thẳng Admob.instance.ShowRewardAd(...) từ binary nổ NRE ở đúng lượt thứ tư vì Admob là lớp R1-out (instance không bao giờ được gán). Mọi lời gọi tới lớp R1-out phải đi qua ServiceLocator.Ads.ShowRewarded(placementId, cb) và cấp thưởng trong nhánh Granted (§9.3). Cổng kiểm cho mọi lô mới: grep Admob.instance|IAP_manager.instance| Tapjoy_manager.instance trong file vừa dựng phải rỗng.

Chi tiết đầy đủ của hệ này: docs/functions/ca-fish.md.

4.2 Interstitial — chuỗi cổng đầy đủ (Inter_Placement_Able 0x2A5CD34)

bool Inter_Placement_Able(Inter_Place place):
 1. if (is_AD_Disable_Version)                                   -> false   // @0x2a5ce5c
 2. if (Is_Interstitial_Blocked())                               -> false   // @0x2a5ce98
        = is_Interstitial_Disable || Is_Remove_AD_forced || Is_Remove_AD_All
 3. if (_interShowing || _interPlacementRunning)                 -> false   // @0x2a5cf34
 4. stageDisplay = Tree_manager.instance != null
                   ? Tree_manager.instance.Stage_Value_Max / 10 + 1 : 0     // @0x2a5d080
    if (stageDisplay < ServerConfig.InterStageMin)               -> false   // @0x2a5d0b0
 5. cool = ServerConfig.InterCooltime
    if (cool >= 1 && _lastInterShownUtc != DateTime.MinValue
        && (UtcNow - _lastInterShownUtc).TotalSeconds < cool)    -> false   // @0x2a5d1d4
 6. Inter_DayCheck()                                                        // @0x2a5d270
    cnt = PlayerPrefs.GetInt("inter_place_cnt_" + (int)place)
    if (cnt >= Inter_DailyLimit(place))                          -> false   // @0x2a5d29c
 7. whole = PlayerPrefs.GetInt("inter_place_cnt_whole")
    if (whole >= ServerConfig.InterDailyCntWhole)                -> false   // @0x2a5d2e0
    return true

ShowPlacementInterstitial(place, onClosed) (0x2A5D508) → nếu không able thì gọi thẳng onClosed() (không bao giờ chặn luồng game). Nếu able → PlacementInterCo (0x2A5EADC):

_interPlacementRunning = true; interLoadingPanel.SetActive(true)
yield WaitForSecondsRealtime(interLoadingSeconds)          // scene: 1.2 s
for (attempt = 0; attempt < interLoadMaxAttempts; attempt++) {   // scene: 1
    if (IsInterstitialReady) break
    if (interstitialAd.IsLoaded() && Is_InterExpired()) Discard_InterAd()
    LoadInterstitialAd()
    t = 0; while (t < interLoadWaitPerAttempt) {                 // scene: 3 s
        if (IsInterstitialReady) break
        if (_interLoading) { t += unscaledDeltaTime; yield null } else yield WaitRealtime(0.5) }
}
interLoadingPanel.SetActive(false); _interPlacementRunning = false
if (IsInterstitialReady) { ShowInterstitialAd(onClosed); if (_interShowing) Inter_CountUp(place) }
else { LogWarning("[ADX] Placement 전면광고 로드 실패({0}회) → 스킵 — {1}"); onClosed?.Invoke(); LoadInterstitialAd() }

Inter_CountUp(place) (0x2A5D644): DayCheck → +1 cho khoá của place → +1 cho whole → PlayerPrefs.Save() → _lastInterShownUtc = UtcNow → log.

is_AD_Disable_Version = 0 · is_Interstitial_Disable = 0 · Is_Interstitial_Blocked = Is_Remove_AD_All || Is_Remove_AD_forced = 0 · reentrancy = 0 — chỉ duy nhất cổng stage (gate 4) đổi trạng thái theo tiến trình. Challenge / Boss / Hunt không xuất hiện ở bất kỳ hàng nào — chúng bị chặn thuần tuý bởi trần/ngày = 0 (gate 6), không phải bởi cổng stage. Ở segment 1, toàn bộ ngân sách interstitial nằm ở Rebirth (6/ngày) + Mine (2/ngày): đúng hai khoảnh khắc "vừa nhận một khoản thưởng lớn", nơi người chơi ít khó chịu nhất.

BIÊN QUAN SÁT (đừng đọc quá): phiên đo chỉ chứng minh ĐIỀU KIỆN ĐỦ TƯ CÁCH (Inter_Placement_Able trả true/false). IsInterstitialReady = 0 suốt phiên vì mediation không có fill trên bản .sot sideload ⇒ không quảng cáo nào được hiện, Inter_CountUp chưa bao giờ chạy, và việc bộ đếm/cooldown có được thực thi lúc hiện hay không vẫn UNKNOWN

9 điểm kích hoạt (tất cả đều là "đóng màn kết quả", không bao giờ giữa trận):

Luật vàng nhìn thấy được: nếu người chơi vừa xem một rewarded ad (_bonusAdWatched), hoặc đã mua/được miễn quảng cáo (Is_RewardBonus_Auto), thì KHÔNG chèn interstitial. Game không bao giờ "phạt" người vừa tự nguyện xem quảng cáo.

4.3 Banner

• Bật: Admob.ShowBannerAd() 0x2A5BCF4 ← Boss_manager.<Enter_Cor>d__27, Monster_manager.<Enter_Cor>d__36, Raid_manager.<Enter_Cor>d__29.
• Tắt: HideBannerAd() 0x2A5BD58 ← Boss_manager.Game_Exit, Monster_manager.StopAllGameCoroutines, Raid_manager.Game_Exit, và Handle_InAppPurchaseChanged.
• Chặn: Is_Banner_Blocked() = Is_Remove_AD_forced || Is_Remove_AD_All (0x2A5BC70).
• Update_BannerPlaceholder() + Refresh_SafeArea() đẩy layout lên 50 dp để banner không che UI.
• ⇒ Banner chỉ tồn tại trong 3 chế độ trận đấu có thời lượng cố định, không có ở màn idle chính. Raid_manager xuất hiện ở đây là bằng chứng độc lập rằng Raid là nội dung đã code nhưng chưa mở (khớp UNLOCK_GATES §3 "Raid — KHÔNG có cổng nào").

4.4 OfferWall (Tapjoy, placement offerwall_aos)

(khối mã nội bộ đã lược bỏ)

• Phần thưởng: kim cương, qua currency của Tapjoy → OnEarnedCurrency → GrantGem(amount) (0x2B2AB4C).
• Chống mất thưởng: nếu save chưa nạp, ghi PlayerPrefs["ow_pending_gem"] = amount và trao ở lần chạy sau (RecoverPendingGem 0x2B29740). Timeout claim ClaimTimeoutSec = 20.
• 2 nơi mở: Open_Hud() (place hud) và Open_Shop() (0x2B2A0F4/0x2B2A13C).
• 3 object UI theo event: OfferWall_Hud_obj, Event_Hud_obj, Event_Shop_obj.
• Đo sống (segment 1): OfferWall_Btn bật ở MaxStageDisplay = 10 và giữ bật vĩnh viễn tới

4.5 FreeCash (AlmediaLink) — "liên kết tài khoản để hết phải xem quảng cáo"

(khối mã nội bộ đã lược bỏ)

vẫn không làm nút hiện; chỉ khi ghi off_5E27948 + 0x38 = 1 nó mới bật. Mặc định trên máy fresh là 3.

Đính chính nhãn (có bằng chứng tĩnh): trường đó không phải AppsFlyerInit.Segment. script.json/ScriptMetadata ánh xạ off_5E27948 → AlmediaLink.AlmediaLinkSDK_TypeInfo, và AlmediaLinkSDK._almediaStatus nằm đúng ở static 0x38 (dump.cs:1108434). AppsFlyerInit.Segment là static 0x8 của off_5E27E20 (dump.cs:585775), do AppsFlyerInit.Cheat_SetSegment 0x2A600CC ghi — một trường hoàn toàn khác. enum AlmediaStatus = NotInitialized 0, Eligible 1, Linked 2, NotAvailable 3, Blocked 4, Disabled 5 (dump.cs:1110114) ⇒ mặc định 3 = NotAvailable, khớp chính xác quan sát "máy fresh không bao giờ thấy FreeCash dù ServerConfig có bật". Kết luận hành vi KHÔNG đổi — chỉ nhãn cơ chế được sửa: bản cài mới, hoặc thị trường mà Almedia không phục vụ, thì FreeCash không bao giờ lộ diện, bất kể ServerConfig nói gì.

• Cửa sổ nổi: HUD chỉ hiện trong khoảng [freecash_stage_min, freecash_stage_max_hud] (segment 1: stage 15 → 35). Banner trong shop thì không có trần trên. Đo sống: Stage_Value_Max = 349 (Stage 35) ⇒ hiện; 350 (Stage 36) ⇒ ẩn lại
• Phần thưởng: CURRENT_REWARD = RewardType.RemoveRewardAd (1) ⇒ TryGiveLinkReward (0x2A6D3C4) đặt isRewardAdRemoved = true và gọi Admob.On_FreeCash_RewardAdRemoved() (0x2A5A37C) để huỷ quảng cáo đang nạp. Từ đó ShowRewardAd trao thưởng thẳng (§4.1). (RewardType.Gun = 2 + REWARD_GUN_NUM = 25 tồn tại nhưng không được chọn ở 1.1.59.)
• Nếu save chưa nạp: pendingReward = true, trao sau (0x2A6D3C4 @0x2a6d3d8).
• place lưu ở PlayerPrefs["fc_link_place"], xoá sau khi trao; log AppsFlyer m_freecash_link.
• Hằng độ bền: INIT_MAX_RETRY 20, INIT_RETRY_DELAY 1 s, LINK_CHECK_TIMEOUT 10 s.

4.6 Súng thưởng quảng cáo weapon_02 — Gun_manager

CheckAdGunEvent()   0x2B0C74C          // gọi từ Gun_Item_List.FuseItems (sau khi người chơi GHÉP súng)
  if (AD_Gun_Event_Given) return
  if (!ServerConfig.Weapon02AdOn) return                    // weapon_02_ad_onoff
  if ( Has_Degree_Or_Higher(2)                              // đã có súng bậc >= 2 -> khỏi cần tặng
    || ( Has_Merged && AD_Gun_SlotIndex == -1
      && AddAdRewardGun(gunNum: 14, cooltimeSec: 1800f) != -1 ) )
      AD_Gun_Event_Given = true                             // một-lần-cho-cả-đời-tài-khoản

• AddAdRewardGun (0x2B0C340): đặt súng #14 vào ô trống đầu tiên, ghi AD_Gun_EndUtcTicks = UtcNow + 1800 s (30 phút đếm ngược).
• Update() (0x2B0C64C): mỗi 0.25 s (unscaled), nếu hết giờ và không đang xem quảng cáo → AdRewardGun_Expire() — súng biến mất.
• Chạm vào súng đó (Gun_Item.OnPointerUp, Gun_Item_List.EquipToSlot, FuseItems) → AdRewardGun_TryWatch() → ShowRewardAd(AD_Reward_Gun).
• Xem xong → AdRewardGun_Acquire() (0x2B0C508): xoá timer + slot marker ⇒ giữ súng vĩnh viễn, bật NewGun_UI_ForceShow.

Đây là mẫu "dùng thử có hạn giờ" kinh điển: đưa món đồ vào tay người chơi, cho họ nếm sức mạnh, rồi đặt một quảng cáo giữa họ và việc giữ nó. Trigger là hành vi (vừa ghép súng lần đầu), không phải thời gian — nên nó rơi đúng lúc người chơi đang quan tâm tới súng.

5. Kinh tế Buff ×3

Giá của cùng một thứ: 300 s ×3 tiền = 1 quảng cáo. Vĩnh viễn ×3 cả hai = buff_pack 210.000đ (phaseA/01_shop.png). Đó là toàn bộ luận điểm bán hàng — và nó được đặt ở dòng thứ hai của cửa hàng, ngay dưới gói Auto Upgrade.

6. IAP — danh mục đầy đủ

6.1 34 product id → chỉ số offer → thứ được trao

Chỉ số lấy từ Shop_manager.ItemIdxFromProductId (0x2B2DE44), dùng cho log AppsFlyer m_offer_page.

Chỉ số 31-35 bỏ trống — có thể là sản phẩm đã gỡ hoặc chừa chỗ. Đây là bằng chứng phủ định, không phải suy đoán: ItemIdxFromProductId không trả về giá trị nào trong khoảng đó.

Giá: 33/34 id đã có giá thật (đóng G162). Dump Shop_manager.Localized_Price_return (0x2B367D4) read-only trên bản Play Store chính hãng: dict_count = 33, resolved = 33 ([liveops catalog: iap_prices_store.json]). 8/8 giá trùng khớp ảnh chụp cửa hàng của do store cấp — không phải hằng số trong build (§6.3).

vip_pass_2 KHÔNG phải sản phẩm Play — nó có mặt trong TryApplyPurchase/ItemIdxFromProductId nhưng không nằm trong 33 id mà store trả giá ⇒ 34 id trong code, 33 id đang bán. Nhiều khả năng là SKU cũ giữ lại để người đã mua vẫn khôi phục được. (Bằng chứng phủ định, không suy đoán về lý do.) Tương tự, fish_free, mine_ticket, sp_iap, reward_hub, f_cash, banner_* không xuất hiện trong dump giá — củng cố kết luận §2.2 rằng chúng là chuỗi place/khoá analytics.

Phân bố giá (33 SKU, VND): thấp nhất remove_forced_ads 79.000đ · cao nhất dia_4 = dia_pack 1.300.000đ. Ba bậc giá lặp lại rõ rệt — 26.000 / 105.000 / 210.000 / 631.000 (Core) và 26.000 / 130.000 / 261.000 / 523.000 / 1.050.000 (StepUp) gần như nhân đôi mỗi bậc: đây là một thang giá hình học ×2, không phải giá đặt tay từng món.

6.1b Số đo trên thiết bị — cả 34 SKU đã CHẠY THẬT (F024 NT4, 2026-09-12)

Bảng §6.1 ở trên đọc từ binary. Mục này là phép đo: từng product id được đẩy qua đúng đường của game (Shop_manager.BeginPurchase → ServiceLocator.Purchases → quân xanh F024 → Granted → TryApplyPurchase) trên Pixel 8 Pro, trạng thái đọc bằng save trước/sau từng giao dịch. 34/34 thành công, 0 exception, mọi con số ở §6.1 trúng. Công cụ: tools/iap_catalog_oracle.py; bảng đầy đủ: [evidence codegen: SPEC-F024-T5-iap-catalog.md].

Bốn hình thái SKU — đây mới là thứ tái dùng được, bảng 34 dòng chỉ là dữ liệu của một game:

Một SKU có thể lai hai hình thái: ba gói Core theo nhịp vừa cấp tiền vừa đóng dấu Last*CorePurchase_Date để tính "đã tới lượt mua lại chưa".

Cái bẫy trung tâm của hình thái 2, đo được bằng hai vế đối xứng trong cùng một lượt chạy:

• vip_pass_2 mua khi is_Vip đã true ⇒ vẫn +500 dia. ApplyVipPass không có cổng "đã có thì thôi".
• autoupgrade_pack / mine_pack mua khi cờ đã true ⇒ không đổi một bit. Phần Get_Dia của chúng nằm trong if (!<cờ>), còn <cờ> = true nằm ngoài.

Cùng mang tiếng "gói vĩnh viễn" nhưng hai nhóm xử quà kèm ngược nhau. Đây cũng là lý do RestorePurchases chạy lại được bao nhiêu lần cũng an toàn với nhóm sau — và không an toàn với VIP nếu ai đó nối nhầm khôi phục vào ApplyVipPass. Quy tắc framework: quyền và quà kèm phải qua HAI cổng riêng — cổng "đặt quyền" idempotent, cổng "trao quà" một lần.

Năm số đo còn lại mà đọc code không cho ra (chi tiết G1789):

1. catgunner_rebirth_single thi hành luôn một lượt Rebirth ngay lúc mua, không phát một lượt để dành: đo được Upgrade_Lv [100,100,99] → [0,0,0] và Ruby 484,97 → 96484 trong cùng giao dịch.
2. Bảy SKU Core đổ vào một ô duy nhất Adventure_Currency_Core[3] (Core_Type.ALL); ba ô theo vùng [0..2] không đụng ⇒ Core bán ra là tiền VẠN NĂNG.
3. Mua chồng PlusPack là mất tiền: ô ngày chỉ DỜI mốc (03:17:19 → 04:51:44), không cộng dồn hạn.
4. remove_forced_ads đánh thức heo đất ngay lúc mua — diaPig.LastTickTime nhảy trong cùng giao dịch, tức nhánh DiaPig.Init(null) có thật chứ không phải mã chết.
5. StepUp_Start_Date do lần mua bậc 0 đóng dấu — đồng hồ của cả chuỗi StepUp bắt đầu từ lần mua đầu, không phải từ lúc mở panel.

6.1a "Core" là tiền tệ gì (giải quyết phần lớn G163)

enum Core_Type { Forest = 0, Desert = 1, Tundra = 2, ALL = 3 }         // dump.cs:591540
Adventure_manager.Currency_Core : int[]                                 // instance +0x28
Adventure_manager.Core_Get(Core_Type type, int value)  0x2ADA8C8
    => Currency_Core[(int)type] += value;  OnCoreChanged?.Invoke();  Alert_Reload()
Adventure_manager.Core_Lose / CoreCount_return  — cùng chỉ mục
const Adventure_Reward_Core_perHour     = 20      // kiếm được bằng cách đi Trip
const Adventure_Reward_Core_PetDegree   = 0.1     // +0.1 Core mỗi bậc pet

⇒ Core là tiền tệ của Trip (Adventure), kiếm bằng cách cử pet đi chuyến (20/giờ), tiêu vào cây Ability của Trip. Có 4 ô: 3 ô theo map (Forest / Desert / Tundra) + ô ALL (index 3). Mọi IAP catgunner_core_* đều nạp vào ô ALL — tức loại Core dùng được cho mọi map. Panel Trip đang chạy hiển thị đúng 4 chip tiền tệ: 3 viên màu (xanh lá / cam / xanh dương, khớp thứ tự enum Forest/Desert/Tundra) + 1 ngôi sao tím "PrismCore" HYPOTHESIS (mức trung bình): ngôi sao tím = ô ALL (index 3) = "PrismCore" — dựa trên (a) Core_Type có đúng 4 giá trị, (b) panel có đúng 4 chip, (c) banner promo của panel mở PrismCore_Purchase_popup (Main.unity:22690) và (d) scene có 7 object Prism_Pack, 3 trong đó đánh dấu (Limited). Chưa xác nhận: chuỗi UI ↔ index chưa được đọc từ code (Adventure_Panel dump.cs:592475, Core_sprite_return dump.cs:591675-591681) → xem §10.

6.2 Đường đi của một giao dịch

Đính chính 2026-09-12 (QD-61, G1768, F024 T5): tiêu đề cũ của mục này ghi "không có bước nào ở đây được tái hiện trong bản restore" — nay SAI. Hai đầu của chuỗi CHẠY THẬT và đo được: BeginPurchase (đã dựng, chuyển hướng qua ServiceLocator.Purchases) và TryApplyPurchase cùng toàn bộ họ Apply* (dựng đủ, đã chạy 34/34 SKU, §6.1b). Phần còn chưa dựng là khúc GIỮA — OnPurchasePending → StartValidate → ValidateAndComplete → CompletePurchaseSuccess — vì nó cần mô hình PendingOrder/receipt của store thật (R1-out, G218/G1691).

<nút UI> -> Shop_manager.Purchase*(type, place)       // ghi _pendingPlace + _pendingIdx
        -> BeginPurchase(productId)   0x2B2E7D8       // ShowPurchasingPanel(); StoreController.PurchaseProduct
        -> [Unity IAP + store]
        -> OnPurchasePending(order)   0x2B31758       // GetTxnId, AlreadyOwned, _inflightTxns
        -> StartValidate(order, product) 0x2B32144
        -> ValidateAndComplete(...)   0x2B33DAC       // POST receipt -> Cloud Function verify*
        -> CompletePurchaseSuccess(...) 0x2B34164
        -> TryApplyPurchase(id, type) 0x2B32204       // <== ĐIỂM TRAO DUY NHẤT
        -> MarkProcessed(txnId); SaveSystem.Save(); LogFacebookPurchase / LogFirebasePurchase

TryApplyPurchase (0x2B32204) là một chuỗi so khớp id: 6 non-consumable → ApplyNonConsumable; catgunner_rebirth_single; catgunner_luxury_upgrade; catgunner_luxury_pass; vip_pass/vip_pass_2; TryGetCoreTypeFromId; rồi 4 nhánh theo prefix (dia_, catgunner_stepup_, catgunner_dailygun_, catgunner_pluspack_); không khớp gì → LogError("[IAP] Unknown product id '{0}' (type={1}) → apply 실패 처리") và trả false.

Ba mẫu đáng học từ đoạn này: 1. Trao hàng là idempotent và hoãn được. Nếu manager phụ trách còn null (chưa xong Awake), hàm trả false và log "확정 보류, 다음 실행 재시도" — giao dịch không được finalize, store sẽ phát lại ở lần chạy sau. Người chơi không bao giờ mất hàng vì thứ tự khởi tạo. 2. Một điểm trao duy nhất cho cả mua mới, khôi phục (RestorePurchases 0x2B35AD0) và đơn hoãn (_deferredOrders). 3. Prefix hoá sản phẩm có chỉ số (catgunner_stepup_0..4) — thêm bậc mới không phải sửa code dispatch, chỉ sửa mảng phần thưởng.

6.3 Định giá — cái game LÀM và cái game KHÔNG làm

• Game không hardcode giá. Localized_Price_return(...) (6 overload, 0x2B367D4…) đọc giá từ Product.metadata của store, rồi FormatPrice_Display(price, iso) (0x2B368B0) định dạng theo CurrencyFormat / ZeroDecimalCurrency (2 bảng static trong .cctor 0x2B36F9C). ⇒ Mọi con số đồng trong tài liệu này là giá cửa hàng quan sát được ở VN tại thời điểm chụp, KHÔNG phải hằng số trong build.
• TryGetPrice(productId, out decimal, out string currency) (0x2B36D00) cho phép UI hiển thị giá chuẩn từng thị trường.
• Bảng giá thật (VN, 33 SKU) nằm ở §6.1 — dump từ chính Localized_Price_return trên bản store chính hãng ([liveops catalog: iap_prices_store.json]). Đọc nó như một mẫu định giá, không phải như hằng số của game: cùng build ở thị trường khác sẽ hiện con số khác.
• ZeroDecimalCurrency là lý do VND hiện 52,000đ chứ không phải 52,000.00đ. Nội dung hai bảng (đọc từ .cctor 0x2B36F9C, G399): CurrencyFormat = 23 mục tiền tệ → chuỗi định dạng (+0x68); ZeroDecimalCurrency = {KRW, JPY, VND, IDR, CLP, HUF} (+0x70) — sáu tiền tệ không có phần thập phân. Cùng .cctor cấp ProcessedTxnIds (+0x40) và PurchaseHistory (+0x48) — thiếu chúng là autosave trên save mới ném mỗi 10 s (G399).

7. Kích hoạt offer & thời điểm

7.0 BA LỚP CỔNG xếp chồng — tutorial → thang stage → segment

LỚP 1 — TUTORIAL  (Tutorial_manager, dump.cs:602669)
    Save mới: CHỈ SpeedRun_Btn + Setting_Btn active.
    Shop / Gun / Skin / Mission / DailyCheck / Auto / Eco / DiaPig / Buff đều tắt,
    và KHÔNG do Contents_Lock_Reload bật  ->  Tutorial_manager mở dần.
    TutorialStep: Upgrade 0 -> Challenge 1 -> GunOpen 2 -> GunBuy 3 -> GunEquip 4 -> Done 5
    Scene: DisableOnTutorial[] = 32 object (Main.unity:20342185+)
        v   (người chơi làm xong tutorial)
LỚP 2 — THANG STAGE  (Tree_manager.Contents_Lock_Reload 0x2B4441C)
    Stage_Value_Max >= 20/30/50/90/110/110/340  ->  Rebirth/Mine/Fish/Boss/Pet/Hunt/Trip
        v   (nội dung mở dần)
LỚP 3 — SEGMENT  (ServerConfig_manager, 15 số từ server)
    MaxStageDisplay >= offerwall_stage_min / inter_stage_min / freecash_stage_min
    + trần ngày theo place + cooldown  ->  bề mặt QUẢNG CÁO bật/tắt

Hệ quả cho phễu kiếm tiền: một người chơi mới không nhìn thấy cả cửa hàng cho tới khi tutorial mở Shop_Btn. Nghĩa là thứ tự tiếp xúc là gameplay trước, cửa hàng sau, quảng cáo sau nữa (bề mặt IAA sớm nhất là OfferWall ở Stage 10 — tức khoảng 100 màn sau khi bắt đầu).

7.1 Công tắc tổng: segment

boot -> ServerConfig_manager.Awake 0x2AC8154
     -> LoadFromSaveData 0x2AC1FA8 (dùng cache) -> Tree_manager.Contents_Lock_Reload
     -> FetchRoutine 0x2AC9864 : POST {BASE_URL}/[endpoint], TIMEOUT_SEC 2,
        FAIL_RETRY_DELAY 60, FAIL_RETRY_MAX 1, POST 1 lần/ngày (NeedPost/TodayKey),
        FIRST_POST_WAIT_CONVERSION_SEC 10  (chờ AppsFlyer trả conversion data trước khi POST lần đầu)
     -> nếu chưa có phản hồi: EmbeddedDefaults(segment) 0x2AC7B20

⇒ Bài học vận hành lớn nhất của tài liệu này: một game có thể ship toàn bộ hạ tầng IAA và vẫn chạy 0 quảng cáo cho một phân khúc, chỉ bằng 15 con số từ server. Phân khúc quyết định bởi nguồn cài đặt / quốc gia / lịch sử chi tiêu (ConfigReq), không phải bởi build.

7.2 Offer gắn với TIẾN TRÌNH (đọc Stage_Value_Max, xem UNLOCK_GATES.md §1)

stageDisplay = Stage_Value_Max / 10 + 1

7.3 Offer gắn với HÀNH VI (không phải stage, không phải giờ)

7.4 Tương tác popup Review ↔ interstitial (mẫu đáng chép)

Rebirth_manager.Rebirth()  0x2B22AE0 — đuôi hàm:
    bool reviewOpened = Review_manager.instance.Review_Panel_Open();     // @0x2b22d24
    Mission_manager.instance.MissionValue_Increase(Mission_Type.Rebirth);
    if (is_UpgradeRebirth) { if (!is_UpgradeRebirth_IAP) { UpgradeRebirth_UseCount++;
                                                           UpgradeRebirth_LastDate = today; }
                             is_UpgradeRebirth = is_UpgradeRebirth_IAP = false; }
    SaveSystem.Save();
    if ( !(boosted || reviewOpened) && Admob.instance != null )          // @0x2b22d9c
        Admob.instance.ShowPlacementInterstitial(Inter_Place.Rebirth, null);

Review_Panel_Open() (0x2AC0DE8) trả true đúng một lần trong đời tài khoản (is_reviewed lưu trong SaveData) và chỉ có một người gọi: Rebirth().

⇒ Ba luật ưu tiên popup được mã hoá trong đúng một dòng if: 1. Người vừa trả tiền / xem quảng cáo để boost ⇒ không ăn thêm interstitial. 2. Xin đánh giá app thắng interstitial (chỉ có một cơ hội, và nó rơi vào lần rebirth đầu tiên — đúng khoảnh khắc người chơi vừa cảm thấy phần thưởng lớn nhất của game). 3. Còn lại thì interstitial, và vẫn phải qua 7 cổng ở §4.2.

7.5 Offer theo LỊCH (cố định trong binary, không remote)

7.6 Điểm danh 7 ngày (DailyCheck) — hệ retention, đọc trọn từ binary (G378)

Mục tiêu học R9: đây là vòng lặp quay lại mỗi ngày của game — thứ nuôi số ngày hoạt động (retention) mà mọi offer khác đứng trên. 13 method đã dựng lại (OnSynced 0x2A6B470, OnCheckSettled 0x2A6B588, RefreshOrShow 0x2A6B4DC, is_DateChange 0x2A6B90C, is_GetAble 0x2A6BC64, CheckStatus_return 0x2A6B9F0, UI_reload 0x2A6B58C, NewUser_Reload 0x2A6B828, Open_Btn 0x2A6B720, Test_Btn 0x2A6B678, Get_Reward 0x2A6BC7C, DailyReward_Get 0x2A6BA9C, Show_WhenReady MoveNext 0x2A6BD08).

Bốn quyết định đáng chép: (1) thưởng đầu tiên ngay lập tức (lùi ngày người mới) — chi phí bằng 0, gỡ rào cản đầu tiên; (2) chuỗi lặp, không phạt — bỏ lỡ một ngày không mất tiến độ, chỉ chờ; (3) đồng hồ tin cậy là điều kiện tiên quyết, không phải kiểm tra sau; (4) ghi sổ trước khi cấp — mọi thưởng theo thời gian đi qua cùng một sổ cái (RecordGain, doc 07 §2.6) nên có thể đối chiếu ngược.

8. Mô hình hành vi — phễu kiếm tiền

 TUTORIAL (lớp 1)
 ────────────────
 save mới ──> chỉ SpeedRun_Btn + Setting_Btn ──> Tutorial_manager mở dần Shop/Gun/Skin/Mission/
              DailyCheck/Auto/Eco/DiaPig/Buff ──> CHỈ TỪ ĐÂY cửa hàng mới tồn tại với người chơi

 TIẾN TRÌNH (lớp 2)            ĐIỀU KIỆN LỘ DIỆN (lớp 3)        OFFER                PHẦN THƯỞNG          TÁC ĐỘNG KINH TẾ
 ─────────                    ─────────────────                ─────                ───────────          ────────────────
 Stage_Value_Max  ──┬──> stageDisplay = SVM/10 + 1
                    │
                    ├──> >= inter_stage_min ────────────> interstitial ───────────> (không thưởng) ────> 0  (chỉ doanh thu)
                    │      && cooldown ok && cap ngày ok
                    │      && !boosted && !justWatchedRewarded
                    │
                    ├──> >= offerwall_stage_min ───────> OfferWall (Tapjoy) ──────> Dia ───────────────> mua shop / gacha
                    │      && Tapjoy connected
                    │
                    ├──> [freecash_min, freecash_max] ─> FreeCash link ───────────> RewardAdRemoved ───> MỌI rewarded
                    │      && Almedia ∈ {Eligible, Linked}                                                tự trao ⇒ buff/bonus
                    │      (seg 1: Stage 15→35, CÓ TRẦN TRÊN)                                             không còn ma sát
                    ├──> > 189 ─────────────────────────> WeeklyShop / PlusPack banner
                    └──> > 988 ─────────────────────────> catgunner_rebirth_single

 HÀNH VI                                                                                             CHUỖI THU NHẬP (doc 01)
 ───────                                                                                             ───────────────────────
 ghép súng lần đầu ─────> ad-gun #14, 30 phút ──> rewarded ──> giữ súng ────────────────────────────> Damage ↑ ⇒ stage nhanh hơn
 bấm nút Buff ──────────> rewarded ────────────> +300 s (trần 900) ─────────────────────────────────> ×3 Money hoặc ×3 Power
                                                                                                       (InvalidateMoneyCache)
 xong Mine/Boss/Hunt ───> rewarded "Bonus" ────> nhân thưởng màn ───────────────────────────────────> Money / PetCoin / Dia
 nhấn Rebirth ──────────> popup "xem QC để ×3" ─> is_UpgradeRebirth ────────────────────────────────> Ruby ×3 (doc 09 §4)
                          (1 lượt/ngày)
 IAP                                                                                                  
 ───
 buff_pack ─────────────> IsPermanentBuff ─────────────────────────────────────────────────────────> ×3 Money & Power VĨNH VIỄN
 remove_all_ads ────────> Is_Remove_AD_All ────────────────────────────────────────────────────────> tắt inter+banner,
                                                                                                       rewarded tự trao,
                                                                                                       DiaPig tick +1
 autoupgrade_pack ──────> Is_AutoUpgrade_Pack + 500 dia ───────────────────────────────────────────> tự mua upgrade
 dia_* / core_* ────────> Dia / Core ──────────────────────────────────────────────────────────────> gacha, relic, adventure
 rebirth_single ────────> +1 lượt Rebirth ×3/ngày (stage >= 100) ──────────────────────────────────> Ruby ×3 lần thứ hai

OfferWall (Stage 10 →, vĩnh viễn) · Interstitial (Stage 12 →, chỉ Rebirth 6/ngày + Mine 2/ngày) · FreeCash (Stage 15 → 35, rồi tự ẩn). Challenge/Boss/Hunt bị trần-0 chặn tuyệt đối.

Năm quan sát về hình dạng của phễu này:

1. Interstitial là lớp duy nhất không trao gì cho người chơi — nên nó cũng là lớp bị gate nặng nhất: 7 điều kiện, cap theo từng place, cap toàn cục, cooldown, và 2 lần "miễn" (vừa xem rewarded, vừa được boost).
2. Mọi thứ IAA trao đều là thứ IAP bán ở dạng vĩnh viễn. Không có phần thưởng quảng cáo nào không có bản IAP tương ứng. Quảng cáo là bản dùng thử của cửa hàng.
3. FreeCash là một "IAP giá 0đ": nó cấp đúng cái mà remove_all_ads cấp cho tầng rewarded (Is_RewardBonus_Auto gộp cả hai vào một vị ngữ, 0x2B2D510). Người chơi trả bằng dữ liệu liên kết tài khoản thay vì tiền.
4. Cửa sổ lộ diện có cả trần trên (freecash_stage_max_hud). Sau stage 35 (segment 1) HUD FreeCash tự biến mất — đo sống: 349 ⇒ hiện, 350 ⇒ ẩn. Offer chuyển đổi kém ở late-game thì bị thu hồi, không để rác trên màn hình.
5. Ngân sách interstitial được dồn vào đúng 2 khoảnh khắc "vừa được thưởng lớn" (Rebirth, Mine), và bị tắt hẳn ở 3 chế độ còn lại bằng cách đặt trần/ngày = 0 — chứ không phải bằng một cờ bật/tắt riêng. Một con số 0 trong config làm việc của một feature flag.

9. Framework takeaway — tầng placement/offer/segment tổng quát

9.1 Bốn khái niệm, tách bạch

// 1) PLACEMENT — "ở đâu, khi nào có thể hiện"
interface IPlacement {
    string   Id { get; }                 // "inter.rebirth", "rewarded.money_buff"
    bool     CanShow(IGateContext ctx);  // chuỗi gate, fail-closed
    void     Show(Action onClosed);      // KHÔNG BAO GIỜ chặn: not-able -> onClosed() ngay
}

// 2) GATE — mỗi gate là một vị ngữ thuần, xếp theo thứ tự RẺ→ĐẮT, log lý do từ chối
interface IGate { bool Pass(IGateContext ctx, out string reason); }
// BuildFlagGate  -> hằng build (is_AD_Disable_Version)
// EntitlementGate-> người chơi đã mua quyền không thấy (remove_ads)
// ReentrancyGate -> đang hiện / đang chạy
// ProgressGate   -> progressMetric >= remote.minThreshold  (và <= maxThreshold nếu có trần)
// CooldownGate   -> now - lastShownUtc >= remote.cooldownSec
// PerPlaceCapGate-> counter[place] < remote.dailyCap[place]
// GlobalCapGate  -> counter[global] < remote.dailyCapWhole
// CourtesyGate   -> !justRewarded && !justPaid          <-- luật "không phạt người vừa trả"

// 3) OFFER — "bán cái gì, khi nào bật, hết hạn khi nào"
interface IOffer {
    bool IsActive(DateTime now, IPlayerState s);   // lịch + tiến trình + hành vi
    IReadOnlyList<Reward> Preview { get; }         // để UI vẽ trước khi mua
}

// 4) SEGMENT — công tắc tổng, do server cấp, có bản nhúng fail-safe
interface IRemoteAdConfig {                        // 15 số, KHÔNG có số kinh tế
    int  Segment { get; } string RuleVersion { get; }
    int  MinStage(string placementId); int  MaxStage(string placementId);
    int  CooldownSec { get; } int DailyCap(string placementId); int DailyCapGlobal { get; }
    bool FeatureOn(string featureId);
}

9.2 Bảy quy tắc rút ra từ SOT (mỗi quy tắc là một quyết định thật trong libil2cpp.so)

1. Mặc định nhúng phải là "tắt", không phải "bật". EmbeddedDefaults(segment != 1) = 99999/0. Server chết ⇒ người chơi thấy ít quảng cáo hơn, không phải nhiều hơn. (0x2AC7B20)
2. Remote config chỉ được chứa số PLACEMENT, không chứa số KINH TẾ. 15/15 field của ConfigResp là ad-placement — đã kiểm chứng bằng payload production thật. Cân bằng nằm trong build ⇒ mọi người chơi cùng một game. (PROBE_RESULT.md §4)
3. Bộ đếm quảng cáo tách khỏi save game. PlayerPrefs cho inter_place_cnt_*, ow_pending_gem, fc_link_place; SaveData cho tiến trình. Reset save không mở lại quota quảng cáo, và ngược lại.
4. Không bao giờ chặn luồng game vì quảng cáo. ShowPlacementInterstitial gọi onClosed() ngay khi gate fail; PlacementInterCo có timeout từng lớp (interLoadingSeconds, interLoadMaxAttempts, interLoadWaitPerAttempt, LOAD_HARD_RESET_SEC, adLoadTimeout).
5. Entitlement chảy ngược vào tầng quảng cáo qua MỘT vị ngữ. Is_RewardBonus_Auto gộp "đã mua" và "đã liên kết FreeCash" — thêm nguồn miễn quảng cáo thứ ba chỉ cần sửa một hàm.
6. Điểm trao thưởng duy nhất, idempotent, hoãn được. Cả rewarded (Reward_Get) và IAP (TryApplyPurchase) đều hội tụ về một hàm; nếu hệ thống đích chưa sẵn sàng thì không finalize và thử lại lần chạy sau.
7. Lịch sự với người vừa trả. !_bonusAdWatched, !Is_RewardBonus_Auto, !boosted, !reviewOpened — bốn lần "miễn" nằm rải trong code, tất cả cùng một tinh thần.
8. Xếp CHỒNG cổng, đừng gộp. Ba lớp độc lập — tutorial (onboarding), thang stage (nội dung), segment (kiếm tiền) — mỗi lớp một chủ sở hữu, một vòng đời, một cách đổi. Người chơi mới không
9. Tắt một placement bằng SỐ, không bằng cờ. inter_daily_cnt_challenge = 0 tắt hẳn placement Challenge mà không cần thêm một trường boolean nào. Một trục số duy nhất (0 … 99999) vừa là công tắc, vừa là van tiết lưu — và cùng một dòng code (cnt >= limit) phục vụ cả hai.
10. Bề mặt kém hiệu quả phải TỰ THU HỒI. freecash_stage_max_hud cho offer một hạn dùng theo tiến trình. Rất ít game làm điều này; hầu hết chỉ biết bật.
11. Cho không trước, gắn quảng cáo sau — trên CÙNG một bộ đếm. Fish_Gacha: quota 5/ngày với 3 lượt đầu không quảng cáo (§4.1b). Hai hằng số (max, noAd) đọc một biến duy nhất, nên tỉ lệ cho-không/gắn-quảng-cáo là một tham số chỉnh được, không phải một nhánh code.
12. Chỉ báo quảng cáo hiển thị theo DẢI, không theo ngưỡng. (uint)(used − free) < adSlots. Ngưỡng để lại một biểu tượng chết sau khi hết quota — nút hứa quảng cáo, trả về lỗi.

9.3 Ranh giới fail-closed cho bản restore (R1)

// Assets/Scripts/Services/IAdService.cs
public enum AdResult { Failed, Dismissed, Rewarded }
public interface IAdService {
    bool IsRewardedReady { get; }
    void ShowRewarded(string placementId, Action<AdResult> done);
    void ShowInterstitial(string placementId, Action done);
    void ShowBanner(); void HideBanner();
}
public sealed class NullAdService : IAdService {           // BINDING MẶC ĐỊNH
    public bool IsRewardedReady => false;
    public void ShowRewarded(string p, Action<AdResult> d) { Debug.Log($"[NullAd] {p}");
                                                             d?.Invoke(AdResult.Failed); }   // KHÔNG Rewarded
    public void ShowInterstitial(string p, Action d) => d?.Invoke();  // no-op, không chặn
    public void ShowBanner() { } public void HideBanner() { }
}
public interface IPurchaseService {
    bool IsOwned(string productId);                        // luôn false ở Null
    void Purchase(string productId, string place, Action<bool> done);   // luôn done(false)
}

Với IRemoteConfigService, bản Null phải trả đúng profile "tắt" — không phải null, không phải throw: MinStage(*) = 99999, DailyCap(*) = 0, FeatureOn(*) = false. Đó chính là (EmbeddedDefaults(1) trả đúng profile bật) — nên cả hai nhánh đều là hành vi đã kiểm chứng.

Bất biến bắt buộc: NullAdService không bao giờ trả AdResult.Rewarded; NullPurchaseService.IsOwned không bao giờ trả true; NullRemoteConfig không bao giờ trả giá trị bật quảng cáo — nó trả bản nhúng "tắt" (99999/0), đúng như SOT làm cho segment ≠ 1. Nhờ đó bản restore chạy được toàn bộ luồng UI monetization mà không cấp một entitlement nào.

10. UNKNOWN / bằng chứng phủ định — và probe phải bắt gì để đóng

11. Raw evidence

• [liveops catalog: PROBE_RESULT.md] — payload ServerConfig production thật (segment 0), sweep ngưỡng, đóng G144
• [liveops catalog: 01_shop.png], 02_shop_scrolled.png — giá + phần thưởng shop thật (VND)
• [liveops catalog: phaseA_capture.json] — 9 419 node canvas, trạng thái active của mọi nút liveops
• [liveops catalog: sweep.json] — bảng sweep ngưỡng 0→1000
• [liveops catalog: PROBE_RESULT.md] — thang bật/tắt IAA dưới segment 1 (§1.3), gate kép FreeCash (§1.4), biên quan sát "no fill" (§1.5), panel late-game (§2), lớp cổng tutorial (§6)
• [liveops catalog: probe2d_capture.json] — bảng đo MaxStageDisplay → OfferWall/FreeCash/interstitial
• [liveops catalog: iap_prices_store.json] — 33 giá VND thật dump read-only từ Localized_Price_return trên bản store chính hãng (dict_count 33, resolved 33)
• [liveops catalog: 31_panel_Rebirth.png] — "Super Rebirth! ×3" + nút quảng cáo 1/1
• [liveops catalog: 31_panel_Trip.png] — 4 tiền tệ, banner Mua → PrismCore, lịch map theo thứ
• [liveops catalog: 30_all_unlocked_hud.png] — HUD sau khi mở đủ 7 feature
• [liveops catalog: LIVEOPS_SURFACE.md] — 15 key ConfigResp, EmbeddedDefaults, Firebase RC, endpoint
• [liveops catalog: UNLOCK_GATES.md] — thang Stage_Value_Max và công thức stageDisplay
• [phân tích nội bộ] §U2, §B-6, §B-7 — cờ boost-kind, buff 300/900, ảnh hưởng segment
• [evidence codegen: Rebirth.c] — Rebirth() 0x2B22AE0 (đuôi: review ↔ interstitial)
• [evidence codegen: PRESTIGE_RULES.md] — boost ×3, daily limit, kind 1/2/3
• dump.cs — Admob :585348, AD_Type :584959, Inter_Place :584976, FreeCash_manager :586919, Review_manager :588967, Buff_manager :592886, OfferWall_manager :599641, DailyGun :599310, PlusPack :599810, Shop_manager :600302, InApp_* enum :600059-600102, Mission_manager.is_Vip/is_Luxury :587346
• stringliteral.json — product id, place, khoá PlayerPrefs, log ADX
• [native: global-metadata.decrypted.dat] — blob khởi tạo mảng static (DiaRewards, StepUp.Gun_Rewards/Dia_Rewards, DailyGun.MaxCounts/PetCoin_Rewards/GunNum_Base)
• [export AssetRipper: Main.unity:20647245-20647268] — giá trị Admob serialize trong scene
• [restore project: Services] — ranh giới R1 fail-closed của bản restore

12. NGUỒN MỚI (2026-09-13): IAPProductCatalog — bảng khai báo SKU CÓ KIỂU

Độ tin cậy: CAO (đọc thẳng từ asset trong gói SOT, 4 bản sao trùng nhau từng byte).

Tài liệu này trước đây suy kiểu consumable/non-consumable từ hình dạng hàm Apply*. Có một nguồn thẩm quyền hơn mà bản cũ không nhắc tới:

[SOT: IAPProductCatalog.txt] — catalog Unity IAP codeless, 8.264 byte, sha256 7f76ad2e14b640eb…, trùng byte với 3 bản sao khác trong repo. Nó khai 32 product (không phải 34 như số mã trong code), mỗi mục có trường type rõ ràng.

Hai điều nó nói mà không nguồn nào khác nói được:

1. vip_pass và vip_pass_2 khai là type: 0 = CONSUMABLE, không phải non-consumable như §6.1 đang ghi. Bằng chứng hỗ trợ phía mã: ApplyVipPass (0x2B32C50) không có cổng "đã sở hữu" — mua lại là cộng thêm 500 dia, khác hẳn khuôn của 6 gói non-consumable; và Is_Purchased(InApp_Type) chỉ phủ 6 cờ, không phủ VIP. ⇒ Mâu thuẫn CHƯA giải quyết giữa §6.1 và catalog — giữ cả hai trên bàn, đừng chép một phía vào thiết kế game mới.
2. Hai SKU Luxury (catgunner_luxury_pass, catgunner_luxury_upgrade) KHÔNG có trong catalog 32 mục, nhưng store vẫn trả giá cho chúng (394.000₫ / 210.000₫). ⇒ chúng được đăng ký ở đường khác; đường đó chưa chứng minh được vì Shop_manager.InitializeIAP là state machine rỗng ở bản dựng lại (R1-out).

Ba điều cần đính chính khi đọc tài liệu cũ:

• googlePrice.num = 0.0 và applePriceTier = 0 cho cả 32 mục ⇒ không giá nào nằm trong build. Mọi con số VND trong §6.1 đến từ đo store thật, không từ gói.
• title/description để rỗng cả 32 mục ⇒ chữ hiển thị đến từ Play Console + I2.Loc.
• Trường entries_len: 37 trong dump không phải "37 SKU" — đó là dung lượng mảng nội bộ của Dictionary. Ai đọc file thô rất dễ đếm nhầm thành 37 sản phẩm.

Cho người làm game idle mới — đây là phần đáng chép lại:

Nguồn từng dòng: IAPProductCatalog.txt; [reconstructed: Shop_manager],StepUp,DailyGun,PlusPack,Rebirth_manager,DiaPig,Mission_manager}.cs (mỗi hằng có chú thích RVA tại chỗ); dump.cs,stringliteral.json}; giá VND: [liveops catalog: iap_prices_store.json].