il2cpp: cannot resolve export il2cpp_method_get_pointer

[Jnetops]

I know this isn't anything that you have done wrong, however I would love your assistance. In working with an Il2cpp library a good portion of the methods are found without issue but on several different applications I have tested, this particular method is not present. The unity version, at least for one, is "2019.4.15f1".

I know that method_get_pointer is very important to this process. By chance, do you know if newer versions of unity have utilized a different method or methods to achieve this functionality? Or if by chance, we can take this conversation to a different forum and I can show you a dump of methods available? I tried to locate what could be utilized for this and it doesn't appear to be present. Doesn't seem to be an obfuscation issue as everything appears to be pretty clear cut as to what it does. Thanks in advance.

[vfsfitvnm]

Hi, this is strange: il2cpp_method_get_pointer doesn't actually exist, because it's a function I implement here https://github.com/vfsfitvnm/frida-il2cpp-bridge/blob/a05a34851920e9826a22120c1babd1af89a5b6fd/src/il2cpp/api.ts#L1035 so it must always be present. What's the (Android, Linux) application you are playing with?

Also, are you using the newest version of frida-compile etc?

[Jnetops]

I am using the newest version, downloaded it and this at same time for the first time. I guess I was confused about that. Hmm not sure what's happening then. I am testing it on a series of different games, haven't got it to work using trace and attach, only printing unity version.

[vfsfitvnm]

Could you tell me the application id of any of those apps?

[Jnetops]

Ya my apologies seen

[Jnetops]

global_metadata isn't obfuscated for that game so able to freely dump to dnspy view as well. Didn't think there would be much issue. There is a hook detector built in it appears, which I will patch the .so after the fact. But at least if I got to the stage of hooking something and then it panicing i'd go from there messing with .so patching.

[vfsfitvnm]

I confirm there isn't any issue:

Il2Cpp.perform(() => {
    console.log(Il2Cpp.Image.corlib.class("System.Object").method("ToString").virtualAddress); 
});

it correctly prints the virtual address of that function.

So there's a problem on your side: 1 - rm -r ./node_modules 2 - Update every dependency to the latest version 3 - npm i 4 - rm _.js 5 - npm run build

[Jnetops]

I have noticed one other issue, and maybe this should be for a seperate ticket, but Module.findExportByName(responsible, name) whether I put in "libil2cpp.so","name of method" or null, "name of method", this returns null. However if I do Module.enumerateExports("libil2cpp.so").forEach(function(val) { if (val.name == "method name") { code to assign method to something }); this works. Any idea why that would be?

I am having to modify your library to support this and I might have fudged something else up in the process.

And to clarify, when I say "when I put" what I mean is I frida -F -U --realm=emulated into my app, and execute Module.findExportByName myself, and it returns null, however if I enumerate and do == or stricter === to find the exact same export, I find it.

[vfsfitvnm]

It looks like a Frida "issue" to me: enumerateExports works, but findExportByName doesn't - I clearly can't do nothing about this, this is entirely a Frida thing.

I quoted the word issue because you are using an emulator - this a wobbly context - you should expect to encounter several issues (this is probably the first of many).

[vfsfitvnm]

If your game doesn't need the Google Service Framework, I suggest you to replace whatever closed source emulator you are using with a proper Android arm or arm64 image (e.g. the one you can download with Android Studio - make sure to download a google-play-less image)

[Jnetops]

I am using android studio, with avd, on a pixel 4 api 30 x86_64 but with playstore and rooted ofc. I can switch to a non-playstore image. I'll fuss around with it, see what I can do. Appreciate the help.

[Jnetops]

I had to do some heavy modifications to things, but I got it working :) thanks again.

[vfsfitvnm]

@Jnetops Thanks for reporting, would you post some sort of patch or whatsoever?

[Jnetops]

Well tbh I am pretty sure the issues where more related to my dysfunctional environment and not so much an issue you or your libraries brought on. Now one improvement I can commit a change for is the couple places findExportByName I replaced with a loop of enumerated modules to locate them that way and that has fixed one of my issues. If you'd like I can put that together as a strand alone.

[vfsfitvnm]

Unfortunately I cannot replace findExportByName with enumerateExports + enumerateModules globally (you know). However, on your side, instead of editing the source code of this package (which may be inconvenient), you could do something along these lines:

Process.findModuleByName = function (name: string): Module | null {
    return Process.enumerateModules().find(module => module.name.includes(name)) ?? null;
}

[Jnetops]

Such a better way to go about it than the way I did it lmao. Learned so much from this library and ur still dropping knowledge appreciate it. Mine was more of a monkey patch lmao. Works but not as elegant.

Any other way to get a hold of you beyond submitting a ticket? Would be awesome to chat about what you have used this library for.

[vfsfitvnm]

I'm not incline toward private chats, however if you think your topic of public interest, there's the "discussion" section to talk about ideas/questions.

I'm closing this issue