How to write a rotmg proxy.

[eth0nic]

Because so many people are talking about it ... here is how you do it. I have done it a few times and it is a good way to learn how to write nice object oriented and reusable code.

Step 1: Learn a programming language. Learn how sockets work. Learn the concept of a proxy. Learn what non-blocking vs. blocking sockets mean.

Step 2: Search for/write a basic TCP proxy only capable of dealing with http traffic for example. Test that proxy. Try to understand it as good as possible.

Step 3: Use Wireshark and mitmproxy to learn how the game gets initialized. You will especially want to focus on the Flash policy string and the rotmg.com/char/list XML game config. See how account creation and password changes are simple http/JSON/XML based transactions (character creation and choosing an in-game name are done via game packets).

Step 4: Use mitmproxy's rewrite rules to change the game config to make the client connect to your proxy and not the real rotmg server. See https://www.mpgh.net/forum/654-realm-...ml#post7998244

Step 5: Serve the client a fake Flash policy string from the proxy. (I don't know if this is still required? It was back when I wrote my first proxy and I stick with it)

Step 6: Make sure the proxy works. You should now be able to play the game using your own proxy. Use your programming language's pack/unpack functionality to dump the data being transmitted. Note: changing realms and "levels" will not work yet.

Step 7: Until now you only got a "pass through" proxy incapable of peeking into the packets let alone modifying them. In order to obtain that functionality you will need to implement the four RC4 keys and states.

# game->server
#my $rc4fromgame = Crypt::RC4->new(pack('H*','72c5*'));
#my $rc4toserver = Crypt::RC4->new(pack('H*','72c5*'));
# server->game
#my $rc4fromserver = Crypt::RC4->new(pack('H*','311f*'));
#my $rc4togame = Crypt::RC4->new(pack('H*','311f*'));

This will be tricky for newbies. Make sure you use good/clean OO code and to store the keystates in a meaningful way ... you might want to use two $connection objects storing the respective socket, stream buffer and the two RC4 states (2 sockets * 2 key states = 4 key states)

Step 8: Implement stream2packet methods and packet2stream methods. This is straight forward. Just make sure you understand how RC4 key states work and that you will need to use non-blocking sockets (or have a separate thread handle sockets so that the 200msec NEW_TICK<->MOVE timing does not get fucked up).

Step 9: Implement a packetId2packetName mapping ... see https://www.mpgh.net/forum/654-realm-...ml#post7979033

Step 10: Make the proxy print packetId, packetName, packetSize on every packet. Now your proxy does not just pass through rotmg packets but decrypts and re-encrypts every single one of them. This is the first time you could actually modify packets without messing up the RC4 states. Once you modify your first packet the 2 client side and the 2 server side RC4 states will be out of sync. This is why you need 4 of them ;-)

see https://www.mpgh.net/forum/654-realm-...hers-info.html

some packets have slightly changed since then ... use the client's source or common sense to figure out those changes ... some of them are described here https://www.mpgh.net/forum/654-realm-...ml#post7806548

if you can't figure out some packets just ask me for help ...

Step 11: Start the proxy up, launch the game ... hope for the best. You should see many large packets at the beginning (those are the initial UPDATE packets telling your client about the initial game state)

Step 12: Save your progress. You now have a fully working rotmg proxy.

Step 13: Until now your proxy does only decrypt and re-encrypt packets but not actually understand what is being transmitted within them. In order for your proxy to be able to change the packets you will need to write a different method for every packet you are interested in modifying. To do so implement a OO style packet factory. I.E. inherit the basic packet behavior (decompile(), compile(), packetName(), packetSize(), etc.) from your packet class and add packet specific functionality based on the packetName.

Step 14: Implement a connection (re)-mapper that will map the ip/host from RECONNECT packets to different local ips and vice versa. So you once you leave nexus and enter MEDUSA your mapper should remap medusahost->127.0.0.2 for example but also 127.0.0.2->medusahost ... use that mapping whenever you get a new connection.

Step 15: Read this book. Learn C++, join https://opencog.org/ and help us save the world!

Step 16: Voila!

[gorgor]

did something changed since yesterday ?
seems like my working proxy don't anymore since yesterday, it even not manage to connect, before HELLO and all

[eth0nic]

no, nothing changed ... maybe you changed the proxy config of your browser and the game does not connect to your mitmproxy? how about making your proxy print a status message every time a client connects so you see whether the connection game<->proxy actually gets initiated?