Question [Discussion] Rust — EAC Integrity Checks on GameAssembly.dll .text Section

[byte_corvus]

Anyone currently digging into Rust's IL2CPP assembly?

I've been spending some time reversing GameAssembly.dll, specifically looking at how weapon fire and aimcone logic is handled. The goal is to find clean endpoints for external patching to kill the cone, but the big question is always the EAC overhead.

I've done a fair bit of static analysis, so I'm not going in blind, but I'm looking for some insight into the current state of EAC's detection model for the .text section.

The Technical Concerns:

1. Does EAC perform full hash checks on the entire .text section, or is it more targeted towards high-traffic ranges?
2. Is a byte patch in GameAssembly.dll usually an instant flag/ban, or does it get queued for the next ban wave?
3. Are there specific regions that are "hotter" than others in terms of integrity checks?

I'm not looking for a full bypass writeup—we all know that's a cat-and-mouse game. I just want to understand the detection model better before I commit to a patching method. If you've messed with IL2CPP patches externally on Rust lately, what's your experience with the integrity check frequency?

Spoiler: Technical Notes

GameAssembly.dll in Rust is a massive target. If you're doing external RPM/WPM, remember that changing protection on pages can be its own detection vector even if the patch itself isn't hashed immediately. EAC has been known to scan for PAGE_EXECUTE_READWRITE in regions that should strictly be PAGE_EXECUTE_READ.

Anyone tested the threshold for these integrity checks lately?