Help! How to bypass a game that detects literally everything?

[jacob42]

- Merely resign the app (no modifications whatsoever)? Game crashes. (Assuming signature verification.) "Try CorePatch" they said. Still crashed. "Try Lucky Patcher to remove signature verification" they said. Didn't work.
- Try to use Game Guardian on the app? Throws "detection" message (anti-cheat/Liapp). "Try VirtualXposed with virtual root" they said. Still detected. "Try enabling Hide Game Guardian from Game options 1 through 4" they said. Still detected. "Try v8sandbox" they said. App detects v8sandbox itself, so I didn't even get to try Game Guardian lmao. "Hide the app with LSPosed on Magisk" they said. Still detected.
- Try to use Frida on the app? "Hide the app with LSPosed on Magisk" they said. Throws "detection" message. "Try to hook the app once it's already started" they said. Frida cannot connect (system protected process). "Try to launch the app with Frida itself" they said. Throws "detection" message.
- Try to use Lucky Patcher? Detection literally just for having it installed, no need to even launch it. "Try LSPosed" they said. OK, actually doesn't say detected. Let me patch the game now... Oh wait, none of the patches work.

I'm either trying to edit/recompile the app (so I can hook functions with C++/mod menu, or try to patch the HEX/ASM of the libraries), use Game Guardian, or Frida. But... why does everything I try result in detection. Are there are other, more reliable methods of avoiding detection? Virtualization, injections, more Magisk modules, I don't care what it is... just help me find something that actually works pls. I'm rooted, using ARM64 device on Genymotion. I have dumped the app already using GameGuardian and BlueStacks... oddly, the game does not detect GG when it is run on x86/x86_64-emulated ARM64 (libhoudini.so) devices like BlueStacks, Windows Subsystem for Android, etc. But, the ARM64 libraries (libil2cpp.so), which are the ones I'm trying to modify, cannot be edited with GG (read-only so I could dump) or even seen at all with Frida, because they can only be accessed on native ARM64 devices. That is why I switched over to Genymotion. But, now on a native ARM64 device, the detection seems a lot more powerful with the app.

 

[NotALegitGuy]

That's super interesting, what is the name of the game?

 

[jacob42]

That's super interesting, what is the name of the game?

Legend Slime. It's using Liapp protection.

 

[NotALegitGuy]

Legend Slime. It's using Liapp protection.

After some testing i found how it protects the app, it makes a new classes.dex for handling Java stuff and a new Native Lib for handling JNI Stuff

I'm pretty sure the native lib is what contains all the protections while the classes.dex has the dialogs, I'll check it out later tomorrow and see what i find.

 

[NotALegitGuy]

I don't think I'll be able to bypass it but if possible i will at least try to get as much information as possible so if another person with more experience than me happens to encounter this thread they can also try

 

[jacob42]

After some testing i found how it protects the app, it makes a new classes.dex for handling Java stuff and a new Native Lib for handling JNI Stuff

I'm pretty sure the native lib is what contains all the protections while the classes.dex has the dialogs, I'll check it out later tomorrow and see what i find.

Interesting. Since all the detections are liapp-based, it wasn't hard to find several references to Liapp. One in classes6.dex (smalis6/com/liapp and smalis6/com/lockincomp), another in assets/.fwazyd.dex, and another in lib/libfwazyd.so. I'm guessing "fwazyd" is just random name to hide itself. I tried deleting them but it results in crash since the library can't be found. Maybe the classes in classes6.dex are just decoys, or at least not the main bit, and the rest is in the place you described.

 

[NotALegitGuy]

Interesting. Since all the detections are liapp-based, it wasn't hard to find several references to Liapp. One in classes6.dex (smalis6/com/liapp and smalis6/com/lockincomp), another in assets/.fwazyd.dex, and another in lib/libfwazyd.so. I'm guessing "fwazyd" is just random name to hide itself. I tried deleting them but it results in crash since the library can't be found. Maybe the classes in classes6.dex are just decoys, or at least not the main bit, and the rest is in the place you described.

I protected an APK using it and i got the same files except for the .dex in assets/

It also seems to encrypt strings and names ( functions, variables and more ) in it's Liapp directory and in the game's directory, except for the game it doesn't encrypt any strings.

 

[NotALegitGuy]

Dumping the game from memory works and isn't detected.

 

[NotALegitGuy]

All of the strings of the library are encrypted with a XOR which makes it hard to find things

Inside the JNI OnLoad function you can find all of this.
It might be better to use a debugger and find what function is called when you get the Lucky patcher alert and start reversing from there, sadly i can't use debuggers due to issues with my system so rip

 

[jacob42]

All of the strings of the library are encrypted with a XOR which makes it hard to find things

Inside the JNI OnLoad function you can find all of this.
It might be better to use a debugger and find what function is called when you get the Lucky patcher alert and start reversing from there, sadly i can't use debuggers due to issues with my system so rip

In which library? I already dumped libil2cpp.so and can see all the strings with il2cppdumper. I can see a good chunk of the strings in libfwazyd.so minus the obfuscated ones with IDA Pro.

I tried to use Frida for a few days to be able to hook functions to track things like Liapp, but all of the ARM64 libraries were invisible when using an X86_64 system, but I was only really looked at libil2cpp.so. When I tried it with a native ARM64 system, Frida kept crashing the game on launch (presumably Liapp). Liapp cannot see Frida/GameGuardian on x86_64 system (no detection) but can see it on ARM64 system (detection). But Liapp can see Lucky Patcher on x86_64 system... Idk, it's super f'ing weird

 

[Yaskashije]

"Try CorePatch" they said. Still crashed. "Try Lucky Patcher to remove signature verification" they said. Didn't work.

Those things are to bypass device's signature detection when trying to install unsigned apks or install apk with different signature than the one that is already installed.






"Do ... they said. Throws "detection" message. "

Thats also what happens in the modding world; everything someone said can be read by the AntiCheat devs who are getting paid to prevent that thing someone said from bypassing their protection.

 

[NotALegitGuy]

In which library? I already dumped libil2cpp.so and can see all the strings with il2cppdumper. I can see a good chunk of the strings in libfwazyd.so minus the obfuscated ones with IDA Pro.

I tried to use Frida for a few days to be able to hook functions to track things like Liapp, but all of the ARM64 libraries were invisible when using an X86_64 system, but I was only really looked at libil2cpp.so. When I tried it with a native ARM64 system, Frida kept crashing the game on launch (presumably Liapp). Liapp cannot see Frida/GameGuardian on x86_64 system (no detection) but can see it on ARM64 system (detection). But Liapp can see Lucky Patcher on x86_64 system... Idk, it's super f'ing weird

libfwazyd, the strings you mostly seee are from the other libs and imports, search JNI_OnLoad then go to it's XREF which should be a LOAD, and go to the sub_ on that same line then just decompile it and you'll begin to see obfuscated strings, and right below them is the decryption.

So far I've found the obfuscated strings to be function names from other libs ( dlopen,mkdir,etc) and also one that was a path to the com/lockincomp liapp dex.

 

[jacob42]

"Try CorePatch" they said. Still crashed. "Try Lucky Patcher to remove signature verification" they said. Didn't work.

Those things are to bypass device's signature detection when trying to install unsigned apks or install apk with different signature than the one that is already installed.






"Do ... they said. Throws "detection" message. "

Thats also what happens in the modding world; everything someone said can be read by the AntiCheat devs who are getting paid to prevent that thing someone said from bypassing their protection.

ah, I had seen a lot of posts say that the crashing was due to “signature verification” and figured the solution people recommended (corepatch) was for the same type of app-level compiling/signature verification, not a different type of system-level one.

And right. That’s why I made this thread, to show all the possible things I’ve tried and that this anti cheat is surmounting all the common methods and to see if there was a way to do it. It’s a very good anticheat I agree.

 

[Ikkegwn]

Any more info? I get it to work from tipe to time, dunno what else it detects after removing luckypatcher. No clue why it works and doesn't. Usually works a bit after deleting lp

 

[MatiasMunk]

up, we need more on this kind of obfuscation method - not just for this app but for other apps as well.

 

[Adickt]

I also have this issue with Slime Idle (Legend Slime). I even tried clean install from Google Play and it still detects Lucky Patcher (which is installed as an apk with random package name)

 

[thoheobaby]

Tôi cũng gặp vấn đề này với Slime Idle (Slime huyền thoại). Tôi thậm chí đã thử cài đặt sạch từ Google Play và nó vẫn phát hiện Lucky Patcher (được cài đặt dưới dạng apk với tên gói ngẫu nhiên)
[/TRÍCH DẪN]
Please , copy lucky patcher package in root/data/app and move it to system/pri-app
after that it can not detect LP anymore

 

[nowhere_222]

Try more methods..

 

[mxrx2]

smartys