- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 330
- Reaction score
- 7
Anyone currently digging into the latest Clash Royale builds?
I've been trying to tear apart the libg.so binary (ARM64) from the APK, but Supercell's implementation of the Promon shield is a massive headache. If you've worked on Supercell titles before, you know they don't make it easy, but this version is particularly stubborn.
The Technical Wall:
Usually, this game should have around 30,000 functions. When I drop the SO into IDA Pro, it only identifies about 1,000 functions. The rest of the idb is just a sea of undefined data and broken offsets. Trying to force MakeCode (C) on instructions yields nothing, which strongly suggests we're dealing with heavy control flow flattening or a custom VM (Virtual Machine) layer.
Key Observations:
Has anyone managed to get a clean dump while the process is active? I'm looking into bypassing the integrity checks to hook the loader, but I'm curious if anyone has already mapped out the VM entry points or has a script to handle the de-obfuscation.
who's tweaked this libg.so recently?
I've been trying to tear apart the libg.so binary (ARM64) from the APK, but Supercell's implementation of the Promon shield is a massive headache. If you've worked on Supercell titles before, you know they don't make it easy, but this version is particularly stubborn.
The Technical Wall:
Usually, this game should have around 30,000 functions. When I drop the SO into IDA Pro, it only identifies about 1,000 functions. The rest of the idb is just a sea of undefined data and broken offsets. Trying to force MakeCode (C) on instructions yields nothing, which strongly suggests we're dealing with heavy control flow flattening or a custom VM (Virtual Machine) layer.
Key Observations:
- Architecture: ARM64 (Android)
- Protection: Promon SHIELD
- Symptoms: IDA fails to resolve function signatures; 95% of the code is missing or obfuscated
- Roadblock: Static analysis is basically useless on the raw file from the lib folder
If you're seeing this kind of function count discrepancy, the binary is likely packed. Promon often uses runtime decryption or a loader that unpacks the real code into memory. Static analysis of the encrypted segments won't work until you get a clean memory dump after the protection has initialized.
Has anyone managed to get a clean dump while the process is active? I'm looking into bypassing the integrity checks to hook the loader, but I'm curious if anyone has already mapped out the VM entry points or has a script to handle the de-obfuscation.
who's tweaked this libg.so recently?
