Another device has been added back to the official device roster! 🚀
• POCO F4 (
Maintainership applications are now open!
• POCO F4 (
munch ) - maintained by @WazzupSensei911Maintainership applications are now open!
Regarding Garena Free Fire 30d soft ban:
Now they are detecting custom roms , xposed modules and God knows what else ....
It's not just Axion Specific , it's overall in a custom rom scenario ... Maybe we will try rechecking once again in future and try to find the exact cause & fix ? Maybe ?? for now be cautious and check out the attached Screenshot..
Might be because of game spoofing?? So do not add FF in game spoofing. We are completely unsure rn ..just do not add in gamespoof irrespective of what rom u using.
Don't say bro i haven't got banned or smt blah blah ...it's an active development game they do changes all the time so we can't pin point anything.
Now they are detecting custom roms , xposed modules and God knows what else ....
It's not just Axion Specific , it's overall in a custom rom scenario ... Maybe we will try rechecking once again in future and try to find the exact cause & fix ? Maybe ?? for now be cautious and check out the attached Screenshot..
Might be because of game spoofing?? So do not add FF in game spoofing. We are completely unsure rn ..just do not add in gamespoof irrespective of what rom u using.
Don't say bro i haven't got banned or smt blah blah ...it's an active development game they do changes all the time so we can't pin point anything.
❤26
Free Fire's Anti-Cheat Checks
The real enforcement happens in ACE Anti-Cheat Engine (native code). The Java layer just collects info and feeds it to ACE and the server.
Checks
Root - looks for Superuser.apk, su binaries, and test-keys
Play Integrity - requests tokens, flags UID mismatches as attacks
APK tampering - verifies checksums and signing certs against hardcoded values
Frida - scans process maps and checks for port 27042
Xposed - walks every thread's stack trace for Xposed classes
System properties - reads 20+ props for root, emulator, and native bridge indicators
Build type - flags eng and userdebug builds
Emulators - checks for goldfish, ranchu, Genymotion, generic fingerprints
Debugger - detects debuggable flag and attached debuggers
Device binding - generates a hardware-backed key to tie your identity to the device
ROM detection
There is no ROM name blocklist. No hardcoded "lineage", "AxionOS", "crDroid", or anything like that in the Java source. Instead, they use indirect detection that catches any custom ROM.
Client-side - only checks generic indicators
Build.TYPE - most custom ROMs ship as userdebug, stock is user
Build.TAGS - custom ROMs not signed with Google's release keys show test-keys
Build.FINGERPRINT - checked for generic/unknown (emulator detection), but the full string also reveals custom ROM identity
Server-side - this is where the real ROM detection happens
ro.build.display.id is sent raw to the server, so your ROM name shows up as-is (e.g. "AxionOS-16-20260331-felix-OFFICIAL")
Build.FINGERPRINT, Build.PRODUCT, Build.MODEL, and Build.MANUFACTURER are all sent as telemetry to AppsFlyer and DataDome
The server can pattern-match against known custom ROM strings without the client needing a blocklist
ACE handles the actual bans, Java checks are just telemetry
AppsFlyer (marketing SDK) doubles as an anti-fraud collector
No Magisk, KernelSU, or LSPosed checks in Java - probably inside ACE's native binaries, but it was seen on the java side that they look for lsposed and frida
ACE's command obfuscation is just a +5 Caesar cipher, which is hilarious
ACE's native libraries may have additional ROM-specific checks but those aren't visible in the Java decompilation
Now Stop playing the blame game and read this ..This is what we found over more research.
The real enforcement happens in ACE Anti-Cheat Engine (native code). The Java layer just collects info and feeds it to ACE and the server.
Checks
Root - looks for Superuser.apk, su binaries, and test-keys
Play Integrity - requests tokens, flags UID mismatches as attacks
APK tampering - verifies checksums and signing certs against hardcoded values
Frida - scans process maps and checks for port 27042
Xposed - walks every thread's stack trace for Xposed classes
System properties - reads 20+ props for root, emulator, and native bridge indicators
Build type - flags eng and userdebug builds
Emulators - checks for goldfish, ranchu, Genymotion, generic fingerprints
Debugger - detects debuggable flag and attached debuggers
Device binding - generates a hardware-backed key to tie your identity to the device
ROM detection
There is no ROM name blocklist. No hardcoded "lineage", "AxionOS", "crDroid", or anything like that in the Java source. Instead, they use indirect detection that catches any custom ROM.
Client-side - only checks generic indicators
Build.TYPE - most custom ROMs ship as userdebug, stock is user
Build.TAGS - custom ROMs not signed with Google's release keys show test-keys
Build.FINGERPRINT - checked for generic/unknown (emulator detection), but the full string also reveals custom ROM identity
Server-side - this is where the real ROM detection happens
ro.build.display.id is sent raw to the server, so your ROM name shows up as-is (e.g. "AxionOS-16-20260331-felix-OFFICIAL")
Build.FINGERPRINT, Build.PRODUCT, Build.MODEL, and Build.MANUFACTURER are all sent as telemetry to AppsFlyer and DataDome
The server can pattern-match against known custom ROM strings without the client needing a blocklist
ACE handles the actual bans, Java checks are just telemetry
AppsFlyer (marketing SDK) doubles as an anti-fraud collector
No Magisk, KernelSU, or LSPosed checks in Java - probably inside ACE's native binaries, but it was seen on the java side that they look for lsposed and frida
ACE's command obfuscation is just a +5 Caesar cipher, which is hilarious
ACE's native libraries may have additional ROM-specific checks but those aren't visible in the Java decompilation
Now Stop playing the blame game and read this ..This is what we found over more research.
❤33