Jump to content
  • 0

Il2cpp patching doesn't affect the code execution


Acessor

Question

I've created a POC (Proof of concept) project in unity to test out Il2cpp android patching using Game Guardian. When you click the button it gets the values returned from each method and formats them so we can see the results.

photo_2023-02-06_10-08-25.thumb.jpg.bd257f30040cac46f7dd0b2f16383455.jpgimage.thumb.png.2ae299e59f8750b749af8972a8d2297e.png

I use IlDumper to get the offsets.

2005840194_.thumb.PNG.3a14b85a79dbd964bdd0f7e2b4d3a94d.PNG

And I made a script for il2cpp method patching in GG (it supports offset patching)

1510603142_photo_2023-02-06_10-26-39(2).thumb.jpg.d1e9829d308b95c0c4d4173dcf754cb9.jpgdemo.lua

The script seems to work and the values do change in memory. But still the POC application login doesn't change (it still returns true and not false, for example)

photo_2023-02-06_10-26-39.thumb.jpg.46759329bdb94cc802c1f5e1fff13f26.jpgphoto_2023-02-06_10-08-25.thumb.jpg.906465459a35756eca9d975af50e6d82.jpg

I need help figuring out what the problem is

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

It's unclear where the dumper got 0x2FCD50 from, but in the comment on the screenshot values are different. There RVA is 0x2080 and this is much more likely (than 0x2FCD50) to be the offset to start of the method in process memory. If you can provide your "libil2cpp.so" file, it should become clear which offset is correct.

Link to comment
Share on other sites

11 hours ago, CmP said:

It's unclear where the dumper got 0x2FCD50 from, but in the comment on the screenshot values are different. There RVA is 0x2080 and this is much more likely (than 0x2FCD50) to be the offset to start of the method in process memory. If you can provide your "libil2cpp.so" file, it should become clear which offset is correct.

Nope RVA is 0x2080 is the offset of the dumped .NET assembly that is displayed by DnSpy and not of the .so file itself. Here's the apk file itself (you can unzip .so file and metadata to get offsets). (Also this POC is an updated version, I've impoved the design so the offsets will be different from the ones from my post above.

POC.apk

Link to comment
Share on other sites

The offset was indeed correct, the issue is with your code. "GetValues" method doesn't use "getBool" method for determining what to print, it gets value of "v_bool" field directly. The instruction that gets the value is at offset 0x2FD33C, it is disassembled as "LDRB R1, [R7, #16]". By modifying it to "MOV R1, #0" one can achieve what was intended: 

image.thumb.png.063a04577d2f60ea0475f4b6d92bfa26.png

Link to comment
Share on other sites

17 hours ago, CmP said:

The offset was indeed correct, the issue is with your code. "GetValues" method doesn't use "getBool" method for determining what to print, it gets value of "v_bool" field directly. The instruction that gets the value is at offset 0x2FD33C, it is disassembled as "LDRB R1, [R7, #16]". By modifying it to "MOV R1, #0" one can achieve what was intended: 

image.thumb.png.063a04577d2f60ea0475f4b6d92bfa26.png

Thank you a lot. There was no direct method calls because of the compiler optimizations. If you select a "release" build mode that all the fields are acessed directly without the method calls. But if "master" or "debug" is selected then all the methods are executed directly, as expected. Now, when the project is done, you can check it out - https://github.com/acessors/Il2Cpp-Exploitation-POC

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.