force_server_validation: pass-through hooks, force-invoke BuildCheatData, NetCacheOne dump + replay

[devin-ai-integration]

Summary

A default-OFF force_server_validation master switch that lets an owned-server operator study the post-battle settlement-validation flow end-to-end without any fabrication. Three layered, opt-in features, all built on the same five validation entry points the v7.9.1 static dump in Archero-7.9.1-hook-gold-report.md already identified:

• BattleModuleData.BuildCheatData()
• HTTPSendClient.CheckGameOverCheat(NetCacheOne)
• LocalSave.BattleIn_DropEquipByServer
• LocalSave.BattleIn_DropEquipDataByTransId(uint)
• GameOverModeCtrlBase.CheckDropEquipsByServer(...)

1. Pass-through observation (force_server_validation=1)

Each of the five methods gets a pass-through hook that calls the original, returns whatever the original returned, and bumps a hits.validate_* counter visible in archero_mod_status.txt. The hook never alters return values or fabricates server responses, so it cannot fake a successful validation. If hits.validate_check_gameover_cheat ticks up after every battle, the operator knows the server actually received and validated the settlement packet.

Resolution is metadata-only via the existing HookSpec table. The five new rva:: entries (0xFE000001-0xFE000005) are intentional sentinels — they're outside any real libil2cpp.so executable mapping, so install_hook's address_in_libil2cpp_exec(target) guard safely skips any hook whose metadata lookup fails on a future Archero version.

2. Force-invoke BuildCheatData at settlement (force_server_validation=1)

To make the settlement payload reproducible run-over-run, the AddGold pass-throughs (BattleModuleData.AddGold(float) / (int)) capture the live BattleModuleData* into a global. At settlement (LocalSave.BattleIn_UpdateGold) the unmodified original BattleModuleData.BuildCheatData is re-invoked on that pointer so the cheat-data payload is rebuilt against the final coherent battle state right before the gameover packet is sent — even if some other code path tried to skip the natural rebuild. Numbers are not altered. Counters: hits.force_build_cheat_invoked, hits.force_build_cheat_missed.

Per-function install guards (g_hooked_add_gold_float, g_hooked_add_gold_int, g_hooked_battlein_update_gold) make this coexist with the existing g_gold_* switches without ever A64-hooking the same target twice.

3. NetCacheOne layout dump (dump_netcacheone=1, requires force_server_validation=1)

On every HTTPSendClient.CheckGameOverCheat(NetCacheOne) call, the pass-through walks the live NetCacheOne* argument with the IL2CPP runtime API and writes the result to archero_mod_netcacheone.txt:

• Class chain via il2cpp_object_get_class + nested il2cpp_class_get_declaring_type (already used elsewhere in the module).
• Every field via il2cpp_class_get_fields(klass, &iter).
• Field name (il2cpp_field_get_name), full .NET type (il2cpp_field_get_type + il2cpp_type_get_name), byte offset (il2cpp_field_get_offset), and the primitive value read directly from obj + offset.
• System.String slots are dereferenced via il2cpp_string_chars + il2cpp_string_length, ASCII-clamped, length-bounded (≤ 512 chars), and quoted in the file.
• Reference-type slots that aren't strings are printed as name : ClassName @offset = pointer, with optional one-level-deeper recursion controlled by netcacheone_dump_max_depth (default 1, max 8).

Pure read — no field is written, no constructor is called, no object is allocated. The operator gets the exact wire layout the server sees for a real run.

4. NetCacheOne replay (replay_netcacheone=1, requires force_server_validation=1)

After the natural CheckGameOverCheat call returns, the pass-through immediately re-invokes the original implementation a second time with the exact same live HTTPSendClient* and live NetCacheOne* arguments the game just produced. The replayed packet carries the real transid from the run; nothing is fabricated. The server's idempotency / replay-rejection behavior on a legitimate request becomes observable: accept → server is undervalidating; reject → server's replay detector is working. Counters: hits.netcacheone_replay, hits.netcacheone_replay_skipped.

IL2CPP API surface added

Extended Il2CppApi with object_get_class, class_get_fields, field_get_name, field_get_type, field_get_offset, gchandle_new/free/get_target, string_chars, and string_length. The gchandle_* entries are wired up but unused by the current implementation (inline dump + inline replay), so any build where they don't resolve still works.

Default behavior unchanged

With every new flag at default 0, none of the new hooks install and the new counters all read zero. archero_mod_status.txt reports force_server_validation=0 / force_server_validation_installed=0 / dump_netcacheone=0 / replay_netcacheone=0.

Files touched

• archero_mod/app/src/main/cpp/mod.cpp — sentinel RVAs, HookSpec entries, hook trampolines, install routine, force-invoke at settlement, NetCacheOne walker + replay, config-key parsing, status-file output, IL2CPP API table extension.
• archero_mod_config.low-risk.txt — force_server_validation, dump_netcacheone, netcacheone_dump_max_depth, replay_netcacheone keys with full comments.
• README.md and Archero-7.9.1-hook-gold-report.md — describe all three features and re-state the "server is the authority" rule.

Review & Testing Checklist for Human

• Build the APK with the project's existing Gradle/NDK setup (the workstation here has no Android NDK, so only a host g++ -fsyntax-only pass was performed locally). Confirm the release build still produces libarchero_mod.so and the APK still stores it uncompressed.
• On a v7.9.1 device, set force_server_validation=1 in the in-app config and play one battle. In archero_mod_status.txt confirm:
  • force_server_validation_installed=1, resolver.metadata count increased by ~5 over the previous boot, and resolver.last_error does NOT reference any of the new method names.
  • hits.validate_check_gameover_cheat and hits.validate_build_cheat are both non-zero (other counters depend on battle type — e.g. equipment-dropping stages light up hits.validate_drop_equip_by_server and hits.validate_check_drop_equips_by_server).
  • hits.force_build_cheat_invoked is non-zero (i.e., AddGold did fire and the cached pointer was usable at BattleIn_UpdateGold); hits.force_build_cheat_missed should stay at 0 for normal PvE.
• Toggle on dump_netcacheone=1 and play one battle. Confirm archero_mod_netcacheone.txt is created and contains a class=...NetCacheOne... line followed by a fields block. Skim the field types and values for anything unexpected.
• Toggle on replay_netcacheone=1 and play one battle. Confirm on the server side that two CheckGameOverCheat-style requests arrive in rapid succession with the same transid, and that the server's existing replay detector rejects the second one (or accepts it — either result is a useful data point about your server validators).
• Toggle all four flags back to 0 and confirm the client returns to the pre-change behavior: force_server_validation_installed=0, all new hits.* counters stay flat across multiple battles.

Notes

• If the IL2CPP metadata search fails for any of the five validation methods (e.g. arg count mismatch on a future Archero version, or a renamed class/method), the affected hook simply does not install; no other hooks are affected; the failure is surfaced as resolver.last_error / resolver.metadata_state in archero_mod_status.txt. The fix in that case is a one-line HookSpec tweak.
• The NetCacheOne walker prints reference-type slots as pointer rather than recursing by default. Bump netcacheone_dump_max_depth=2 (or higher, up to 8) if you want one level of inner-object expansion; each step is bounded and there's no cycle detection, so depths above ~3 may emit duplicate sub-objects on graph-shaped fields. Field-count is also clamped to 96 per object to keep the file size sane.
• Forward declaration of g_orig_build_cheat_data lives near the top of the globals block so hk_battlein_update_gold (which appears earlier in source order than the rest of the force_server_validation hook definitions) can re-invoke it.
• The pass-throughs and force-invoke are designed to leave client-reported numbers untouched. A clean default-config run should still validate as a successful run on a correctly-configured server — that's exactly the "force a successful, accurate run" case from the original request.

Link to Devin session: https://app.devin.ai/sessions/5488d011d57741d68989cc85932d562f
Requested by: @Jordan231111

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring