tanis

Is this stuff still relevant?

I don't know if this is the right place to post this topic. If not, please move it to the right place I would like to start a community effort to reverse Mobile Legends Bang Bang as I think there are quite some members of the forum that could jump in and fill the gaps. My main goal is to be able to dissect the game code. I'm using the Android version as a reference but it looks like it works the same way on iOS. So far what I can tell is the following: the game is written in Unity3D the actual game code sits in Lua files the Lua files are probably encrypted because their file size is a multiple of 8 and there are good chances that the algorithm being used is AES (more on this later) the C# DLLs have been encrypted and obfuscated Moonton modified the original mono loader to actually decrypt and deobfuscate those DLLs while loading them into memory there is another DLL inside assets/Any/android/MobaLogicAndroidData.unity3d and that DLL has been obfuscated and encrypted but it looks like it might slightly differ from the protection used with the other DLLs. There are plenty of *.lua files in the assets/android/lua folder. While they should be text files with the actual game code, it clearly shows that they've been encrypted. Checking the file size I can assume that they're using some block cypher algorithm and I guess it's almost surely AES as that algorithm is also used to encrypt pieces of the C# DLLs. I decompiled libmono.so, libmain.so, libunity.so, libunityx.so but I couldn't find any trace of the parts that should load the Lua files so far. What is clear is that the libmono.so has been modified because the C# DLLs in assets/bin/Data/Managed aren't standard .NET DLLs. They have their headers modified. Kao did a great job at analyzing them and finding out more about what's going on with them and I invite you to check his blog there: https://lifeinhex.com/unity3d-protection-in-moonton-games-part-2/ Basically the MS-DOS signature has been changed so that they know that the file is an encrypted DLL and if you replace it they just won't load it. The PE header has been encrypted with a slightly modified version of AES -128. The stream names have been changed and their size and data fields have been switched around. The size and data fields have been encoded. The method header have been encoded and both tiny and fat methods have been slightly modified in the way they work. What I'm trying to do now is to find out who's loading the Lua files and the decryption algorithm. It would be nice if we could join forces and get deeper with this. I'm looking forward for comments if you're interested

Actually the Android hack can dupe those items as well

It makes sense, I've got confused there. But now I wonder.. how would you get crash reports that make sense if you obfuscate the code? There should be a way to deobfuscate what comes through the crash reporting and it must either be stored in the game or somewhere offline for post processing of crash reports.. has anyone had a look into that by any chance?

That's weird. One more chance could be that it's stored the savegame in the Cache folder even though that would be weird as that folder gets erased occasionally by the OS if it needs more space

Well, then you can learn to use IDA or lldb to remote debug an iOS application, learn some Objective-C to understand how things work in iOS application-space and get your hands dirty with Theos to have a starting point to write your tweaks with.

You stand no chances with VB.

You've got to take your time and learn how to use IDA to analyze the code, either IDA or lldb to debug interactively as needed, learn how to code in Swift/Obj-C/C and setup Theos so that you get a framework to write your hacks with (it makes your life a lot easier). It's not something you learn over a night though

That's fine if you know the address. But in my case I don't know the address of what I'm looking for so I need to find out the virtual address space assigned to the process and read the list of regions in there to scan each of them. I stumbled upon lldbinit https://github.com/gdbinit/lldbinit and it's got a findmem command that seems to work with malloc-ed memory as well (notice the MALLOC_SMALL): (lldbinit) findmem -s ciao Found at : 0000000100000F74 base : 0000000100000000 off : 00000F74 __TEXT Found at : 0000000101000000 base : 0000000100800000 off : 00800000 MALLOC_SMALL Found at : 00007FFFC9D3FF74 base : 00007FFFC1F04000 off : 07E3BF74 __LINKEDIT Found at : 00007FFFC9D4165F off : 07E3D65F __LINKEDIT This pretty much solves most of my problems.

@DiDA it works like a charm! Thanks for pointing me in the right direction

I didn't know about DLGMemor, I'll have a look at it. Are you actually using it?

Is there anyone who tried to write something similar to iGameGuardian or who has got an idea of how it could actually work. I doubt that they hook malloc to keep a list of all the memory allocations in the heap. Is there a way to access the list of heaps arenas from within an iOS process? What would you do to find out the arenas? Maybe this could turn out in a collaborative project, wouldn't it be useful? My basic plan would be to make it a dylib and sideload it with the app I want to read the memory from.

Yes, I know about mem find -s "mystring" -- 0x000000010216b000 0x000000010295f000 but you need to find out the addresses of the memory arenas that have been allocated by malloc and friends which is not obvious. You can get a list of memory sections with image dump sections but those are the allocations made when the executable is being launched and memory allocated statically. All the memory allocation functions do not end up in that list and I'm not aware of any easy way to track them down.

Is there any simple way to search the heap memory with lldb? Anyone who erote a script to do just that? Cheers!

I'm wondering if there's any interest in a collaborative tentative hack of this one.