New update #54
Comments
|
The first message is not encrypted actually and thats all I know for now. Will dig into it when I have more time. |
|
Looking more into it, Protocol structure of most of calls has not changed. e.g i looked at disassembled login subroutine, and it was same structure as in past. New login Old login As you can see its same structure, yet when we try to decode it, it breaks. So I believe that packet structure has not changed, but whole encryption mechanism on packets has changed. This is the subroutine which deals with new packet (id 10100) that is sent by client so it should be int, int, int, int, int, string, int, int |
|
there is a new key, i posted it here http://ultrapowa.com/forum/showthread.php?2843-Message-10100-20100&p=16895&viewfull=1#post16895 |
|
I think I have a proper message captured from the network traffic and the message is not encrypted as I've said above. http://bit.ly/1O1GlLX |
|
The KeepAliveRequestMessage and KeepAliveResponseMessage has changed also they are 16 bytes long now. |
|
Ouch, not a good news. Looks like it won't be so easy to just keep accounts connected. But maybe it's not as usefull as it was before anyway with this update. public int Data1;
public int Data2;
public byte[] SomeData;
public string MasterHash;
public int Data4;
public int Data5;
#region BaseMessage
protected override void Decode(PacketReader reader)
{
Data1 = reader.ReadInt32();
Data2 = reader.ReadInt32();
SomeData = reader.ReadByteArray();
MasterHash = reader.ReadString();
Data4 = reader.ReadInt32();
Data5 = reader.ReadInt32();
}
#endregion BaseMessageAnd for the answer from the server, just this will do it: public byte[] SessionKey;
protected override void Decode(PacketReader reader)
{
SessionKey = reader.ReadByteArray();
}But you first have to make sure that those two messages are not Decrypted, as other messages are. |
|
I am going to push a commit soon on the branch 'rewrite' with 10100 and some other stuff. I am worried that it would be extremely hard to run clients because they might have added a new checksum to the keep alive messages. |
|
so this seems to be the flow
there is also a matter of new key that they put: "77035c098d0a04753b77167c7133cdd4b7052813ed47c461" |
|
As libsodium seems to be part of the new encryption, this may be useful: |
|
Great! I thought it was only available in C! |
|
Didn't realize this would be the most active thread on sharing information (that I've found anyways). :P Sweet! Wish I found this over the weekend instead of when I'm starting work for the day. That new key is likely just a pepper (https://en.wikipedia.org/wiki/Pepper_(cryptography)). There is a new configuration in clients.csv file that set its use to true. There is a C# port of libsodium. I had to hack at ProxyNetworkManager.cs a bit. ReadPacket wants to |
|
I will look into KeepAliveRequestMessage later and see what they have added. Here is the functions in which i believe all the pacts are going though. This is the subroutine which i believe handles all packets. and here you see special casing for 20100 this is sub routine which calls crypto box |
|
So does it mean that libsodium lib is only used once for the message 20100, and never again at a later time? |
|
would be too early to say that. i found 25 instances of string "crypto_box_curve". analyzing it will take some time edit: looking a bit more most of it was function declarations. and actual implementation of all the cryto functions. its only used at 3 places. 1 i posted above. other inside sub_174AE4 which is called by sub_174178 (which i posted above; 20100 flow). call inside sub_174AE4 then there is 3rd calling which is called inside a function called by routine which parses all packets. ^ i posted this above. so seems like there is some sort of fallback crypto_box_curve25519xsalsa20poly1305_tweet_open (not sure what open means) for rest of packets |
|
"crypto_box_curve25519xsalsa20poly1305_tweet_open (not sure what open means)" this is Decrypt method set by libsodium Anyways, what bothers me the most is the 32 byte reqired key for this to work. So far we have seen only 24 byte arrays being exchanged, which is the standard length for nonce in libsodium. Even 20100 responds with 24 byte long array. |
|
Note that the message 10100 also has an additional 8 bytes array. It may have something to do with the 8 bytes you're looking for. |
|
"this is Decrypt method set by libsodium"
on too those missing bytes. i looked into that crypto_box_curve25519xsalsa20poly1305_tweet_keypair randombytes??? as side note guys, i can stop pasting code if its note helpful. just give me heads up |
|
"Note that the message 10100 also has an additional 8 bytes array. It may have something to do with the 8 bytes you're looking for." Where do you find this, i only see: Note the number of arguments used in that open sub call (7) and take a look at original definition for those subs here: Unless we are able to attach to process and debug it that way, this is all going to be our best guess only. I have no means to try this out :( |
|
I thought that |
|
the number of parameter mismatch is not only just in crypto_box_curve25519xsalsa20poly1305_tweet_open. inside crypto_box_curve25519xsalsa20poly1305_tweet_open_afternm (coc sends 4 parms, while lib takes 5) there are lots of things off. and as warclans said without live debugger it will be really hard to figure this out. seriously wonder how imod/xmod figured it out (with in 4 hours of update going live). or do they work in memory? |
|
run-time debugging is the key. I tried once to attach to bluestacks process but wasn't successful :( just installed the libsodium-net package, so i will play with this tonight |
|
The structure for 10100 is int, int, int, int, int, string, int, int and published by FICTURE7 above, but here is the summary of it so far int unknown1 (1, 0x01) We may need to capture more 10100 packets to see if unknown1/2/3/4 ever change. 20100 returns 24bytes, so it's not a full 32byte key. Not sure if unknown1/2/3/4 come in to play there or not, but currently appears unlikely. As has been pointed out, there are 3 nonce strings now. "nonce" which has been in use for a long while, "4c444a4b4c396876736b6c3b6473766b666c73676a90fbef" which was in use on the stage server for quite some time, and a new one of "77035c098d0a04753b77167c7133cdd4b7052813ed47c461" which is unknown if it is used. The current server does appear to know to attempt multiple decryption methods, and if an old method is detected, it always sends a 20103 login failure packet with a status of 8 (version is out of date and needs to be updated, which is a slight change from previous functionality). It does appear only the handshake is changed, and we will set the updated nonce and continue as it was with the current scramble/decryption once we figure out the handshake. d3death, I'd say those function dumps are actually quite helpful, but posting everything we need would indeed get a bit verbose. |
|
Remote debugging bluestacks and ganymotion is tricky because they are running the ARM code in an x86 emulator I believe. I'm not sure IDA supports debugging an ELF binary on x86. If you had a rooted android phone then you can remotely debug ARM. I'd love to be wrong about remote debugging bluestacks/ganymotion so feel free to prove me wrong. 👍 I thought it was pretty clear from d3death's comment above what the structure of the 10100 packet was: There are 5 dwords: Followed by a string (which is structured as DWORD "length" followed by "length" number of UTF-8 characters): Followed by 2 dwords: v4 is the reader |
|
"4c444a4b4c396876736b6c3b6473766b666c73676a90fbef" is the client salt we've had forever. "77035c098d0a04753b77167c7133cdd4b7052813ed47c461" is newly added and likely just appended (I haven't seen this in code yet - just a guess based on the new option "USE_PEPPER_CRYPTOGRAPHY" and the normal meaning of "pepper" in cryptography). I suspect 10100 makes sure the client is giving the proper masterhash to the server. The 20100 response is a server generated session key. The client will then use that and the salt+pepper+nonce to respond back with its side of the handshake for full encryption. The point is... network sniffers can see the 20100 contents so there must be an agreed upon hash that both the client and server know (this is the salt+pepper+nonce). Prior to 8.x this was just salt+nonce. If I could figure out why the heck IDA 6.8 isn't analyzing my file correctly I'd be all over this - I'm chomping at the bits. :) Glad to see others working at this as well. |
|
Not sure if we need to pay attention to this or not, but the 10101 and 20104 packets have data in the 6th & 7th bytes of the packet, whereas all other packets are 0 10101 is 0x0007 All other packets appear to be 0x0000, as this project has always generated for all packets. |
|
This may or may not help. This suggestion was found here: http://ultrapowa.com/forum/showthread.php?2843-Message-10100-20100 [23:28:28] Ultrapowa: I want to give you a hint about 8.0 |
|
i could upload complete ida disassembled file if you want |
|
I think it may be convenient for those who do not have IDA, but it makes quite a big file.
|
|
@Snargie No, bypassing 10100/20100 will not work, as if you send an unencrypted 10101 packet (or encrypted using the older encryption method) now, it will always return a 20103 login failed packet with a status code of 8 which indicates your client is out of date. |
|
@zyxwvuts |
|
@expl0itr I was just trying to translate @clugh 's code as closely as possible to C#, and he uses afternm() (technically he uses PyNaCl's Box.decrypt(), which uses afternm()). Apparently, though, afternm() does return -1 if the key is invalid, so I guess it doesn't matter which method I use if my keys are wrong. Thanks for the info. I'll give your instructions a try, though, since it fits the way my existing classes are structured a little better than clugh's. |
|
The keepalive is 16bytes because of the encryption padding... Or checksun of some sort. |
|
@zyxwvuts Depending on the implementation you use, the zero padding may or may not be added automatically. The client strips the padding before sending packets, but the encryption also uses a 16 byte Poly1305 authenticator, so the ciphertext (without zero padding) will always be 16 bytes larger than the plaintext (which is why KeepAlive has a 16 byte payload). My suggestion would be to run through some of the examples and/or tests of the library you're using, so you can see the expected input and output. |
|
@zyxwvuts No problem! Glad to see people working on a C# implementation. Would be great to see more C# geeks here. |
|
@expl0itr I modified my code to use your suggestion and I got crypto_box_easy to return a byte[] while decrypting packet 10101. You mentioned above that you call beforenm to generate a shared key; did you ever use the shared key since you're using crypto_box_easy? Also, can anybody confirm that they dropped the RC4 and scramble function? I didn't see it in clugh's code, but Python might have some magic line of code that does this and I missed that line. |
|
Oh yeah, thanks, @clugh, my library didn't want me to pad ciphertext. That suggestion was key to me getting a result from cypto_box_easy. |
|
@zyxwvuts No, I never used that shared key but stored it just in case it's needed. |
|
I finally have my 10101 decrypting with crypto_box_easy, but there are a variable number of bytes (between 60 and 72 so far) at the front of the bytes returned by crypto_box_easy. Have other people seen and handled this, or is it a peculiarity with my implementation? |
|
Between 60 and 72?? ... facepalm |
|
@DevilMental Thank you for that very informative information.. @zyxwvuts Number 1 rule of compiled commercial application programming. Never remove anything. Only modify and add, or your code will break for absolutely no reason, at all, whatsoever. While ARC4 is still there, because of ^^above, it is not being used. Could it be used for something? I have my theories, but no evidence to prove or disprove them. At this point in time it is safe to say ARC4 is out of the equation for a while. |
|
Do not expect Redmoon team to do or share anything useful. They just hope to convert their amazing superiority complex into cash. I think they already have lost any kind of credibility from the eyes of the community. I just hope they won't hurt the open source spirit too much in the process. |
|
The clash of clans industry does not need biased people like lil' FastFrench. If you wish to have a talk with us, better do it directly instead of mentioning it indirectly. 😉 ~ DevilMental |
|
Alright we got it bois, no need for drama here. |
|
@zyxwvuts The first 48 bytes of the decrypted 10101 packet should be the 24 byte binary string from 20100 and a 24 byte nonce. Anything beyond that would seem to indicate some irregularities. |
|
I am stuck on step 24 on the protocol page, do we use |
|
For all packets sent from the client to the server (message ID < |
|
I made a simple proxy in C#. It is based heavily on Microsoft's asynchronous sockets examples, and has basically no error checking, but it should be a decent reference for those trying to accomplish something similar. _Note:_ This is my first C# project, so if I've done things that make no sense, try not to judge me too harshly. |
|
Gives me a CryptoGraphicException but thank you for the example proxy! |
|
Post an issue in the repo, so we don't clutter up this thread, but it's working fine for me. The first thing I'd check is that |
|
Works for me, too, clugh... You are the man! I want to be like you when I grow up. Was generating the Blake2 nonce already built into the Sodium library? GenericHash? |
|
@clugh you're impressive mate, thanks for proxy in Python and C#! I found my mistake, I was using |
|
I implemented a packet decoder in C# using Json.NET and the previously mentioned Json packet definitions. It currently requires .NET 4.0 because of Json.NET also provides the means to easily map the results to objects. |
|
@clugh Thanks for Proxy. I'm trying to use it but I'm having a problem. In ClientCrypto the state.serverState.nonce is null and when he tries to Utilities.Increment error occurs. Line 35 |
|
It sounds like you're getting a LoginFailed packet. I haven't yet added any handling for it. To avoid cluttering up this thread, please create an issue in the repo, and we'll do any further communication on the topic over there. |
|
Tranks |
|
The proxy is working fine with the latest encryption so I guess we can close this issue. |
As expected, with the new update it doesn't work anymore.
It will probably need some time to find out the new encryption schema.
This update introduced two new messages to support new encryption.
The first one is id=0x2774, it is sent by the client,
The Server answers with message 0x4E84.
LoginMessage only comes after those.
The text was updated successfully, but these errors were encountered: