sthlwrk Posted July 6, 2016 Share Posted July 6, 2016 Hello there! Are there some documents about the networking protocol of Red Alert 1 ? Google did not help. I created a Tunnel Server which dumped all the datagrams of my test games, and tried to reverse engineer the data. But unfortunately I did not get anything. Even chat messages are not transfered as clear text, and I could not find the coresponding datagrams. The only things I know: First 2 Bytes = Client ID of Sender Next 2 Bytes = Client ID of Receiver And some values are the same, a whole match long - but other matches have other values that keep being the same. Also some values just iterate.. maybe some synch values. Further, some values repeat within one datagram. Some Examples: (client 1 sends to client 2): 02 9A 05 39 47 81 B0 12 73 00 4B 6E 77 AA 4A 16 06 AE 4A 3B 4E 52 6B 18 7B AA 45 0F 73 AA 4A 0F 73 AA 4A (client 2 sends to client 1): 05 39 02 9A F6 20 D6 D7 73 00 4B 5B 77 AA 4A 16 14 AE 4A 3F F1 A7 68 18 78 AA 45 0F 73 AA 4A 0F 73 AA 4A Can somebody please help? Thank you for reading! - sthlwrk Link to comment Share on other sites More sharing options...
sthlwrk Posted July 7, 2016 Author Share Posted July 7, 2016 I tried to do more matches (but still only with 2 clients), different maps, sending text, moving units, etc. I don't see any similarities, and it seems that analysing the packets in hexadecimal view does not lead to results. Probably the protocol is working on bit level, which makes it analysing much more worse.. Here some findings: There are also datagrams which are longer and shorter. After a long buffer follows a short buffer by the opposite Client. Some acknowledgement datagram after an important datagram? Datagram sizes: Default datagram: 35 bytes Short datagram: 15 bytes Long datagram: > 35 bytes 4 - 7 = Random 8 - 9 = Same on match 10 = Same on match, -1 on long buffers, +1 on short buffers 11 = random, sometimes the same value one after another 12 = changes sometimes 13 = Same on match (changed on some matches, when byte 12 overflows wtf!) 15 = Same on match, +3 on match start 16 = decrements, sometimes decrements by more than 1, sometimes is set to other value, wtf? 17 = increases by 1 or more, but rarely changes 19 = 3B on first client, 3F on second client 20 - 21 = random 22 = 4A on match start, otherwise D0 or rarely D1 23 = Same on match, but different on match start 24 = small increase or small decrease, rarely 25 - 26 = Same on match (changes rarely) 27 = Always 0F 28 - 29 = Same on match 31 = Always 0F 32 - 33 = Same on match (same value as bytes 28 - 29) 14 + 18 + 30 + 34 = 4A, a terminating byte? On some matches 34 Sorry, still analysing.. Nobody? Link to comment Share on other sites More sharing options...
SiRaLeX Posted July 7, 2016 Share Posted July 7, 2016 Umm, are you saying that chat isn't sent in plain text? That's weird, bro. You have to take into consideration that when RA1 was designed 56k or even slower was prevalent. So perhaps there's some compression going on. How much do you know about hacking? How much do you know about Reverse Engineering. I would definitely look for any signs of compression, perhaps LZO? Anyways, good job, bro. 14 + 18 + 30 + 34 = 4A, a terminating byte? On some matches 34 That doesn't make any sense, to be honest. Do you even math, bro? :laugh: Anyways you have to know how BSD sockets and UDP datagrams work together. There's definitely no need to send any size or terminating byte because upon return recv tells you the number of bytes received. Just FYI. BTW, welcome to the forum!!! It's nice to have you here! :ivan: Let me introduce myself: My name is SiRaLeX and I hack everything RA2 related. I've never looked into its p2p protocol though. I mostly use(d) my knowledge to create cheats so that other players can match up to me. Now, isn't that nice? I also hold several RA2 player RaNk #1s [they are all acknowledged and registered in the Hall of Fame] on XWIS (the official RA2 server) but I swear to you I've never used any cheats in any ranked game I've ever played. Some people will tell you I'm "scum". But that's just the way it is. I'm learning that my worth is more than their word. Don't let anyone bring you down just because you're researching the RA1 p2p protocol. The game is 20 years old after all. Unleash all its dirty secrets! :heady: Link to comment Share on other sites More sharing options...
sthlwrk Posted September 12, 2016 Author Share Posted September 12, 2016 Can you tell me anything you know about it? Which compression exactly? And the protocol format too, please. Anything I already got is that First 2 Bytes = Client ID of Sender, Next 2 Bytes = Client ID of Receiver, Next 4 Bytes = CRC16 Thanks. -sthlwrk Link to comment Share on other sites More sharing options...
snake45 Posted September 14, 2016 Share Posted September 14, 2016 BTW, welcome to the forum!!! It's nice to have you here! :ivan: Let me introduce myself: My name is SiRaLeX and I hack everything RA2 related. I've never looked into its p2p protocol though. I mostly use(d) my knowledge to create cheats so that other players can match up to me. Now, isn't that nice? I also hold several RA2 player RaNk #1s [they are all acknowledged and registered in the Hall of Fame] on XWIS (the official RA2 server) but I swear to you I've never used any cheats in any ranked game I've ever played. Some people will tell you I'm "scum". But that's just the way it is. I'm learning that my worth is more than their word. Don't let anyone bring you down just because you're researching the RA1 p2p protocol. The game is 20 years old after all. Unleash all its dirty secrets! :heady: SiRaLeX? that's a really lame sounding name, go practice math bros. Link to comment Share on other sites More sharing options...
SiRaLeX Posted October 1, 2016 Share Posted October 1, 2016 Can you tell me anything you know about it? Which compression exactly? And the protocol format too, please. About what? And no, no, no. That's your work. It doesn't work that way. I'm not doing your work. I don't have Red Alert 1. Anything I already got is that First 2 Bytes = Client ID of Sender, Next 2 Bytes = Client ID of Receiver, Next 4 Bytes = CRC16 You seem to have a pervasive understanding problem. The length of a CRC16 is 2 bytes. https://en.wikipedia.org/wiki/List_of_hash_functions Besides why would there be another hash in the datagram? The transport layer already drops corrupted dgrams... SiRaLeX? that's a really lame sounding name, go practice math bros. If anything, your face is lame. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now