IL2CPP and new protections (Cytus 2)

[RubberDuckShobe]

Hello, I'm trying to remove AppGuard from Rayark's Cytus 2 to play it on my rooted device and stumbled on a bunch of new info.
It seems to mess with libil2cpp.so and the global-metadata.dat file, probably encrypting them. However, for .so files, it seems to leave the ELF header intact, but it doesn't have any .sox files anymore and it also doesn't appear to encrypt any other data.
Another thing worth noting is that it has new classes for the string encryption that aren't listed in this repository.

I've managed to make an edited APK file that skips the AppGuard activities and launches the Unity player normally and replaced the libil2cpp.so file with one I've dumped from memory and fixed (because that works before the game closes due to the security policy violation, honestly quite incredible), but that either results in a black screen or a crash with a fatal error caused by libil2cpp. I can't confirm this as of now, but I suspect that it might be due to the fact that it can't load the encrypted global-metadata.dat.

I'd like to get some advice on how to deal with this and I'd do anything to help with getting to the bottom of this.

[leohearts]

I'm also working on Cytus 2. It doesn't launch on custom roms, but on stock rom even with magick and Xposed it works without any issue.

[RubberDuckShobe]

That's good to know at least. Though, libcompatible.so has functions that seem to check for Magisk.
Do you know how to decrypt the libil2cpp.so? I've managed to dump it from memory but I can't just use it like the original file.

I also have the decrypted global-metadata.dat that I dumped from memory, if you want it then I can send it

[sinyo1015]

I also have a same case like Cytus 2 but in another game. As far as I know my target game were encrypt global-metadata.dat and libil2cpp.so too and in additional I guess mine also obfuscate libcompatible.so and libstub.so. After researching some methods, I find that libil2cpp.so and global-metadata.dat are decrypted via libunity.so and yeah, some of them were obfuscated symbols.

I Interested to @RubberDuckShobe on how you managed to dump global-metadata.dat, maybe you can show some tricks that you use? 😄

[RubberDuckShobe]

I Interested to @RubberDuckShobe on how you managed to dump global-metadata.dat, maybe you can show some tricks that you use? 😄

@sinyo1015 I used GameGuardian to search the magic bytes that are at the start of a valid global-metadata.dat and dump the memory starting from where that's located. Then, I opened the memory dump file and trimmed it to be the same size as the game's encrypted metadata file (the size doesn't change from the encryption).

[sinyo1015]

@RubberDuckShobe
I've managed to dump both unencrypted global-metadata.dat and also libil2cpp.so directly from the memory. Both of them can be processed to Il2cppDumper or Il2cppInspector by inputting offset address respectively.

In your message stated that :

but that either results in a black screen or a crash with a fatal error caused by libil2cpp. I can't confirm this as of now, but I suspect that it might be due to the fact that it can't load the encrypted global-metadata.dat.

It can be various of reasons that I've also experiencing the same problem either :

1. Injection of a native so files trough smali codes
2. Injection via rewriting of required library by using LIEF
3. And also dynamically inject by using Frida

All the methods that I mentioned are detected by AppGuard.

Recently, I've also tried your method by replacing dumped libil2cpp.so and unencrypted global-metadata.dat and it did crash. Following by the produced logs, apparently (cmiiw) what global-metadata.dat ask for some addresses were not matched within dumped libil2cpp.so and so it creates application crash.

[RubberDuckShobe]

The dumped libil2cpp.so won't be properly byte aligned. I remember following this (in chinese, google translate works though) to fix the .so file, but it will still crash. If I remember correctly, this has something to do with relocations. IDA also shows some seemingly hardcoded addresses in the code of the dumped .so file, which is also a result of it just being dumped from memory.

[Kitsunejasutin]

Is this issue still working in progress? Still having a hard time playing it in custom roms. Stuck rom here sucks that's why I have to do custom rom