- Joined
- Jan 24, 2014
- Messages
- 119
- Reaction score
- 62
So, for the last few days I've been taking apart this game (
I've been a player since all the servers merged together early last year, and I didn't really start thinking about this until early October when the devs started making some very stupid decisions to push the game more towards paid content in areas which they had never done before, i.e. one of the things which put them above other gacha games was that you never needed to roll or pay for characters, you could earn them in game, but that changed on October 4th with their last character release, and needless to say, a lot of people were extremely pissed, hurting their already heavily dwindling player counts. This is feeling like the beginning of the end to me, and if it is, then that pushes me even harder to get going on this project before I lose access to being able to get data from the live server entirely. Yeah, it might not be the best game ever, but I personally enjoy it, it's a decent time killer, and a guilty pleasure, I guess you could say.
So, how far along have I come? Well, here's some general information I can provide about the game and it's architecture:
- The game uses Stock Unity 2020.3.38f1 without any source edits.
- The game code is compiled with IL2CPP. No encryption or obfuscation is being used on the resulting binaries.
- There is a very minimal AC involved, but from what I can tell from reading some of the code, it's extremely basic and only looking for the typical things such as CE. I've been able to inject into it using BPE 6 without any issues.
- The primary library they are using for networking is ProudNet and the documentation for it is publicly available to read without any registrations or anything like that.
- The packets seem to be all TCP based and are handled by a single server on port 50001.
- The crypto they are using for the packets is from ProudNet, based on RSA and a simple XOR. 3 of the 6 packet types seem to use the XOR because they are considered more "sensitive" than the others (Client/ProudNet's wording). The XOR algo doesn't seem to be different per packet or type or anything like that thank god. It also hasn't changed at all between game updates. I'm not sure if the algo is made by the game's devs or ProudNet itself.
- All the traffic is easily redirectable using the hosts file.
- I have all the packet definitions and their read/write functions pulled out of the IL2CPP. The write methods definitely help to see how the packets are put together and take a huge amount of the guesswork away right out the gate.
- I have a fair number of the handlers for packets pulled out as well to see how the client handles them, that together with the above should honestly make the entire process of putting together the server way faster compared to trying to guess and trial and error everything.
- The backend itself, from what I've seen from both playing the game and reading through the code, is nothing more than a combined glorified state management system and persistent storage system. The only thing is that it likely has a copy of the client's data tables to reference like all these games tend to.
This leads into the areas in which I need some help, almost all of which requiring lower level reverse engineering skills than I myself have or very intimate knowledge with Unity's file formats. In order of importance to me at this moment:
- Dealing with the crypto. This is primary enemy number one, the big blocker, the thing preventing me from writing any real code. I see two approaches to this: A) find the RSA key and the algo being used to generate the XOR and reproduce it on the server side, or B) bypass the crypto entirely and work with everything on an unencrypted level. I'd be inclined to say that because this server isn't meant to work over the network and is meant to just be ran locally, the latter option might make more sense.
- Packet sniffing and logging. While I may have all the packet definitions and whatnot on hand, it'd still be nice to be able to grab data from the live server and observe how it's doing things, so it'd be nice to have hooks into the send/recv functions to both see the data flow and record some of that data for analyzing and comparison.
- Data table extraction. If I don't want to manually rewrite all the game's data tables (honestly possible, but would take a long time), then they need to be pulled out of the client's files. I haven't really looked into where exactly they are yet since I've been too focused on trying to deal with the first two points so much and finding help with them, but if I had to hazard a guess, I'd say they're in the system AssetBundle, and the AssetBundle looks encrypted to me, so that could be it's own "fun" to deal with in and of itself. The client code I have pulled out of the IL2CPP might help here when it's looked into though.
There's also one other thing that's worth a mention in regards to this. None of this might not theoretically even be necessary, as from my perusing of the code, I have found a class called NetLocalSvr, which seems to serve the purpose of emulating a live server locally for client testing and debugging. It has a huge ton of logic in it and the function names alone suggest it covers a sizable portion of handlers. I've made some attempts to figure out how to enable this, as I've seen it's tied to a flag in the Config class and tried disabling it on the constructor level as is wanted by the initialization code to start the local server, but that didn't really get me anywhere and I imagine there's more to it than that. The Config class is a ScriptableObject so that might require some actual resource file modifications, which I'm not really sure how to do. Either way, this may not be the best course of action anyway, as they could rip this out of the client at any given time, and that would be the end of that.
I think that covers most things at this stage. If anyone needs any more details, my decompiled assemblies, or whatever else I have, I will happily provide it.
You must be registered to see links
and F2P) for the purposes of building a server to play it offline. I don't know if you'd call my end goal a traditional private server per se, since it's ultimately just a single player game with some very meager social elements like a friends list and automated account vs account PVP, but rather something more akin to Single Player Escape from Tarkov is what I'm thinking about in scope.I've been a player since all the servers merged together early last year, and I didn't really start thinking about this until early October when the devs started making some very stupid decisions to push the game more towards paid content in areas which they had never done before, i.e. one of the things which put them above other gacha games was that you never needed to roll or pay for characters, you could earn them in game, but that changed on October 4th with their last character release, and needless to say, a lot of people were extremely pissed, hurting their already heavily dwindling player counts. This is feeling like the beginning of the end to me, and if it is, then that pushes me even harder to get going on this project before I lose access to being able to get data from the live server entirely. Yeah, it might not be the best game ever, but I personally enjoy it, it's a decent time killer, and a guilty pleasure, I guess you could say.
So, how far along have I come? Well, here's some general information I can provide about the game and it's architecture:
- The game uses Stock Unity 2020.3.38f1 without any source edits.
- The game code is compiled with IL2CPP. No encryption or obfuscation is being used on the resulting binaries.
- There is a very minimal AC involved, but from what I can tell from reading some of the code, it's extremely basic and only looking for the typical things such as CE. I've been able to inject into it using BPE 6 without any issues.
- The primary library they are using for networking is ProudNet and the documentation for it is publicly available to read without any registrations or anything like that.
- The packets seem to be all TCP based and are handled by a single server on port 50001.
- The crypto they are using for the packets is from ProudNet, based on RSA and a simple XOR. 3 of the 6 packet types seem to use the XOR because they are considered more "sensitive" than the others (Client/ProudNet's wording). The XOR algo doesn't seem to be different per packet or type or anything like that thank god. It also hasn't changed at all between game updates. I'm not sure if the algo is made by the game's devs or ProudNet itself.
- All the traffic is easily redirectable using the hosts file.
- I have all the packet definitions and their read/write functions pulled out of the IL2CPP. The write methods definitely help to see how the packets are put together and take a huge amount of the guesswork away right out the gate.
- I have a fair number of the handlers for packets pulled out as well to see how the client handles them, that together with the above should honestly make the entire process of putting together the server way faster compared to trying to guess and trial and error everything.
- The backend itself, from what I've seen from both playing the game and reading through the code, is nothing more than a combined glorified state management system and persistent storage system. The only thing is that it likely has a copy of the client's data tables to reference like all these games tend to.
This leads into the areas in which I need some help, almost all of which requiring lower level reverse engineering skills than I myself have or very intimate knowledge with Unity's file formats. In order of importance to me at this moment:
- Dealing with the crypto. This is primary enemy number one, the big blocker, the thing preventing me from writing any real code. I see two approaches to this: A) find the RSA key and the algo being used to generate the XOR and reproduce it on the server side, or B) bypass the crypto entirely and work with everything on an unencrypted level. I'd be inclined to say that because this server isn't meant to work over the network and is meant to just be ran locally, the latter option might make more sense.
- Packet sniffing and logging. While I may have all the packet definitions and whatnot on hand, it'd still be nice to be able to grab data from the live server and observe how it's doing things, so it'd be nice to have hooks into the send/recv functions to both see the data flow and record some of that data for analyzing and comparison.
- Data table extraction. If I don't want to manually rewrite all the game's data tables (honestly possible, but would take a long time), then they need to be pulled out of the client's files. I haven't really looked into where exactly they are yet since I've been too focused on trying to deal with the first two points so much and finding help with them, but if I had to hazard a guess, I'd say they're in the system AssetBundle, and the AssetBundle looks encrypted to me, so that could be it's own "fun" to deal with in and of itself. The client code I have pulled out of the IL2CPP might help here when it's looked into though.
There's also one other thing that's worth a mention in regards to this. None of this might not theoretically even be necessary, as from my perusing of the code, I have found a class called NetLocalSvr, which seems to serve the purpose of emulating a live server locally for client testing and debugging. It has a huge ton of logic in it and the function names alone suggest it covers a sizable portion of handlers. I've made some attempts to figure out how to enable this, as I've seen it's tied to a flag in the Config class and tried disabling it on the constructor level as is wanted by the initialization code to start the local server, but that didn't really get me anywhere and I imagine there's more to it than that. The Config class is a ScriptableObject so that might require some actual resource file modifications, which I'm not really sure how to do. Either way, this may not be the best course of action anyway, as they could rip this out of the client at any given time, and that would be the end of that.
I think that covers most things at this stage. If anyone needs any more details, my decompiled assemblies, or whatever else I have, I will happily provide it.
