Closed neowutran closed 8 years ago
Rechecked, nearly sure they have changed the traffic encryption key.
Probably need to change those lines? https://github.com/neowutran/ShinraMeter/blob/master/Tera/Sniffing/Crypt/Cryptor.cs#L11 The new key should be available in the program memory I suppose
Don't know how to find them. @Gl0 any idea?
The only part, can be changed in this lines without other code changes is second params (30, 50, 39). And they could not be higher than first params. So it should not take much time to bruteforce them, using captured traffic and trying to parse s_login packet until find correct name. (or simply correct opcode+known data after it). BTW, first 2 bytes of S_Login seems to be offset of Name field (306 for now), so it better to change static reader.skip(272) to something like reader.Skip(nameOffset-34) for future updates, that can add another unknown fields to S_Login packet, causing change of name offset. (All dynamic-sized fields are always at the end, after all fixed-size).
oh ok, thanks for the info =) will try to write a small piece of code to brute force that
They also could change not params, but code itself. And even if they didn't do that this time, they can do it in any update if they want to block us. And this changes can automatically arrive to other publishers, causing problems in all regions. So if we want to play with it - we need to find a skilled reverse engineer, ready to dig into game encryption every patch... or we could loose ability to use tera dps meters at all.
I wonder if this is a coincidence that they changed things right after meter started working on KTera.
Not a coincidence, seems like Nexon really don't like 3rd party application
I wrote and run a brute force program against the cryptor keys https://github.com/neowutran/ShinraMeter/blob/master/Tera/Sniffing/Crypt/Cryptor.cs#L11 (second parameter only) Not working, they changed another thing / more than only that
They could change any parameter here. It is easier - not to touch key generation, but to scramble it differently before sending to network. But scrambling algo may be also changed. If you can attach debugger - you may try to brake at SHA initialization (it uses known constants) and trace back to key initialization.
Yep I will try to find the information with a debugger. But I don't really have any experience in reverse engineering (except from some easy program challenge on training website) , so I will be stuck here for long, as I need to first learn how to really use a debugger and then find the needed information.
And if I m desesperate I can also try a bruteforce here: https://github.com/neowutran/ShinraMeter/blob/master/Tera/Sniffing/Crypt/Session.cs#L33 But If they changed any other thing than the shit and xor parameter, that will just be a waste of time
There can be changed only shifts, all other changes can be obtainable only by RE.
Reverse engineering increased to 2
I found the new key exchange protocol in the program memory =p and I checked it on EU & KR, can be reproducted "easily"
Publishing a patch maybe tomorrow, need to sleep now
Nice one.
So they changed only shifts? My vanga mode was right.=) But next time they can do something more difficult to reconstruct...
yep ^^ At least that give me a training in RE x)
It look like korean have changed the traffic encryption key, but need to verify