-
-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARM Support (Nintendo Switch, Android, etc) #6
Comments
I believe the switch uses an ARM processor, not x86, so any support will come after x86 support is to a decent state. |
What about Android architectures? armeabi-v7a, arm64-v8a, etc. |
Cpp2IL is actually based on Il2CppDumper, but I made the decision early on to strip out all the other architectures for simplicity and add them back once finished. Even if I hadn't, this wouldn't offer any advantage over Il2CppDumper right now other than speed, because the analysis is very processor-specific and I wrote all of that myself. In terms of android - both android architectures use the same basic ARM instruction set, so once I add support for one platform, the rest should work. |
In terms of supporting different architectures, wouldn't it make sense to switching over to Capstone? There are .NET bindings for it which are really nice, and it supports all major architectures (including wasm). |
Yes, that would probably be good. I had looked at capstone previously and somehow missed the bindings for .NET. I only saw the legacy C# bindings, so I thought it wouldn't be viable. However - having seen that it exists, I'll check it out. It would certainly make arm support easier (though still not easy) |
Yea it will always be tricky no matter what, each architecture would need it's own complex handlers. I haven't looked into it much but Ghidra's decompiler really interests me for something like this as from what I can tell it operates on Ghidra's PCode which is essentially a central "intermediate language". It's able to produce great pseudo-C output without having to do anything architecture specific. If it's able to produce such great pseudo-C I'm sure the PCode is just as good for this use case. The decompiler part of Ghidra has been stripped out and used in other programs like IDA. I'm not sure if someone has done it but I imagine simply Capstone+bits of Ghidra could be a powerful combination. (or just doing all this as a Ghidra plugin in general I guess might make sense...) https://github.com/cseagle/blc |
what about collaborating with DevX?as i can see he made something like working IL2CPP to ARM...i think you may share some thoughts to each other...idk if he has github account or not so here is his email... |
Support for Dummy/Stub DLL generation is added for ARMv7 and AARCH64(ARMv8) ELF binaries, so this will work on Linux il2cpp games (in theory, I haven't been able to get my hands on one to test), and manually extracted metadata/elf binaries from APKs. Switch support needs more work - mainly because I don't have any binaries. Analysis is still a long way off. |
Can you provide the correct way to use Cpp2IL with an il2cpp android app? I made a folder with the apk contents and the tool. Edit: I just realized you said that you need some binaries for testing. Inside the zip is an arm64-v8a and an armeabi-v7a sample for Pokemon Go. Both have a libil2cpp.so and a global-metadata.dat. |
Hi, you also need to provide the --force-unity-version with the other two force options - those force options are the only way to run with APK files at present. I do eventually intend for you to be able to just provide the APK path via --game-path, but that's not implemented yet |
Also, when it comes to testing binaries, I'm ok for android, it's specifically for Linux x86/x64, and Nintendo Switch games (though I have now been provided one switch game) |
Remove the a7 - just 2019.2.0 |
Awesome, it worked. DummyDLL files were generated and they look correct when I open them up in DnSpy. I had to run again with the |
That's correct, yeah. |
Any Update? |
Nope, and I don't expect to have one for a while - at least until x86 is in a decent state. |
Actually, I do have an update. |
Progress tracked in #35 |
I have a few games that have both DLL and Il2Cpp version. I usually kept DLL one for analysis so i can do more fun stuff on Il2cpp |
It's ok, I have no shortage of games in ARM. As I said, work is being done, you can see my checklist in #35 - once that is done, I can start working on ARM reasonably quickly, I hope |
Amazing progress! |
I'm focusing on arm64 specifically because most quest games are built only for arm64, while a lot of android games are built for both. |
I see, I'm kinda oldschool, and i hate ARM64 games because of its issues with modding.
This game is using Unity 2018 https://apkcombo.com/guild-of-heroes-epic-dark-fantasy-rpg-game-online/com.goplaytoday.guildofheroes/ And can you make it possible to specify APK file instead |
That's an error in your command line, not in the disassembly. Not sure exactly what. Edit: you're not specifying the force options properly as described further up this thread, so it's looking for an exe. Also, don't decompile the apk, just open it using 7zip or similar software and drag out the libil2cpp.so and global-metadata files. But yes, I'll try to add support for APKs |
Ok, I've just added a feature to allow you to use |
I forgot to force unity version. It still asked me for game path, that's why i have to decompile
But nvm, specifing an APK works fine and the process has completed but i'm not seeing any source inside DLLs. Maybe i should wait more till it's more implemented |
Unity version shouldn't have the f1 part, but as I said, it should work without the force options as of the latest version. Also if providing force options, yes, game path is marked as a required option, so you can just provide it as At the end of the day, the force options are there for development purposes - that's why they're not listed in the readme. Also, if you want source inside the dlls, read the readme, it tells you how to enable that. |
I tried, i got a few IL codes. Most of them are broken since it's still in experiment i know |
The extern thing is a bug I haven't yet been able to fix. Removing the method body as part of cleaning up failed IL generation results in the method being marked as extern. |
Extern bug has been fixed and Nintendo Switch binary suport is implemented (albeit requiring the force options for now). Closing this issue as the support of Arm64 and Armv7 is now tracked in the README and everything else mentioned here is complete. |
No description provided.
The text was updated successfully, but these errors were encountered: