search

vfsfitvnm / frida-il2cpp-bridge

A Frida module to dump, trace or hijack any Il2Cpp application at runtime, without needing the global-metadata.dat file.
https://github.com/vfsfitvnm/frida-il2cpp-bridge/wiki
MIT License
1.03k stars 202 forks source link

Generate header file (for IDA) #206

Closed RimuruChan closed 2 years ago

vfsfitvnm commented 2 years ago

I won't do it. Contributions are welcomed!

vfsfitvnm commented 2 years ago

PS: I attempted many times to correctly generate valid .h files - but unfortunately I never succeeded in doing so.

I also attempted in generating a JSON file containing the types and methods metadata - so I could use the program (Ghidra in my case) scripting to generate the structures and stuff.

RimuruChan commented 2 years ago

PS: I attempted many times to correctly generate valid .h files - but unfortunately I never succeeded in doing so.

I also attempted in generating a JSON file containing the types and methods metadata - so I could use the program (Ghidra in my case) scripting to generate the structures and stuff.

https://github.com/Perfare/Il2CppDumper

I think we can do the same in runtime. I'm trying reimplementing it from Il2CppDumper

RimuruChan commented 2 years ago

I researched it, the theory is feasible, but the memory needs to be searched, and it may not be able to be searched (if there is special treatment)

RimuruChan commented 2 years ago

Maybe a better way is to use Il2CppDumper with global-metadata.dat and binaries dumped from memory

vfsfitvnm commented 2 years ago

researched it, the theory is feasible, but the memory needs to be searched, and it may not be able to be searched (if there is special treatment)

I don't understand this - would you tell me why memory needs to ne searched?

RimuruChan commented 2 years ago

researched it, the theory is feasible, but the memory needs to be searched, and it may not be able to be searched (if there is special treatment)

I don't understand this - would you tell me why memory needs to ne searched?

We could not get enough imformation through the exported il2cpp api, such as all the typeinfo. The typeinfo table only exsist in global-metadata and there is no way to access it from any known struct. It has to be searched from memory. To dump with frida, we have to know where the global-metadata, the MetadataRegistration and the CodeRegistration is.

RimuruChan commented 2 years ago

This is the same as what Il2CppDumper does. So just use Il2CppDumper. frida-il2cpp-bridge should work as a hook tool, not a dumper, I think.

vfsfitvnm commented 2 years ago

We could not get enough imformation through the exported il2cpp api, such as all the typeinfo. The typeinfo table only exsist in global-metadata and there is no way to access it from any known struct. It has to be searched from memory. To dump with frida, we have to know where the global-metadata, the MetadataRegistration and the CodeRegistration is.

This is correct, but there are two things you should know. First, we could find where the global-metadata is, in fact frida is capable of scanning memory - but the biggest problem here is dealing with customized il2cpp structures. It's so easy for companies to change such structs (i.e. change field orders, adding fake fields and so on) I don't think it's worth it. It's also true there's no way to access all the typeinfo using the il2cpp exported api: I noticed inflated types (i.e. generics with actual types) are missing. But if these are the only types missing, we can "easily" check their existence calling Il2Cpp.Class::inflate against every value type and System.Object - reference types shares the same type info, actually.

This is the same as what Il2CppDumper does. So just use Il2CppDumper. frida-il2cpp-bridge should work as a hook tool, not a dumper, I think.

I don't know how much Il2CppDumper has evolved, but frida-il2cpp-bridge won't have problems with packed/encrypted/missing/customized global-metadata. So I think there are situations where Il2CppDumper can't be used