The blocks from the new file are encrypted strings. I will check it later.
The new encryption is a crap.
But if you find it, please don't leak it, so they won't change it to an hard encryption.
Anyway, i found the encryption of the packets too(by dissembling), i tried to do a litte server on my computer. Just a little ss, http://www.2send.us/uploads/32c1ca2113.jpg
kornto wrote:But if you find it, please don't leak it, so they won't change it to an hard encryption.
There's always a new challenge
Disassembling the game to get the packet encryption was enough, I don't want more .
My hint is, that there is a way to figure out the new wz encryption without disassembling.
I checked one of the strings in list.wz, it is just a name of .img folder in one of the wz files.
Maybe it is a list of the encrypted folders? because not all the folders encrypted.
kornto wrote:I checked one of the strings in list.wz, it is just a name of .img folder in one of the wz files.
Maybe it is a list of the encrypted folders? because not all the folders encrypted.
What do you mean by "not all folders are encrypted"? All the *.img files in all the wz's are packed and encrypted in the same way (if it would be not this way, then my WZextract tool [and also Maplext and the Python script] wouldn't work ).
And like kornto said: Yes, the new string encryption must be crackable without disassembling (just imagine somone is sending you encrypted strings, but not the tool to decode them).
But again: The question still is, if Wizet used a fixed key (--> trial-and-error on finding all needed bytes) or a fixed calculation (--> finding out the math behind it).
kornto wrote:I checked one of the strings in list.wz, it is just a name of .img folder in one of the wz files.
Maybe it is a list of the encrypted folders? because not all the folders encrypted.
What do you mean by "not all folders are encrypted"? All the *.img files in all the wz's are packed and encrypted in the same way (if it would be not this way, then my WZextract tool [and also Maplext and the Python script] wouldn't work ).
And like kornto said: Yes, the new string encryption must be crackable without disassembling (just imagine somone is sending you encrypted strings, but not the tool to decode them).
But again: The question still is, if Wizet used a fixed key (--> trial-and-error on finding all needed bytes) or a fixed calculation (--> finding out the math behind it).
No.
In msea only some of the folders are encrypted.
For example in UI.wz, the images in WindowUI are encrypted but in another folders not.
I figured out the encryption of kmst some months ago, and i said that i did it without disassembling.
The encryption is still a crap. I keep it private because I don't want that they will change it.
kornto wrote:No.
In msea only some of the folders are encrypted.
For example in UI.wz, the images in WindowUI are encrypted but in another folders not.
I figured out the encryption of kmst some months ago, and i said that i did it without disassembling.
The encryption is still a crap. I keep it private because I don't want that they will change it.
Yes, but how long did it take you to figure out the encryption, and is the encryption overly difficult or relatively simple (both for KMS[T] and MSEA)?
EDIT: Oh wow... I think I just figured out some of the encryption. Koolk, check your PM's on Sleepywood.
EDIT2: Yeah, I just checked. What we're working with is KMST encryption. It's the exact same.
kornto wrote:Disassembling the game to get the packet encryption was enough, I don't want more .
My hint is, that there is a way to figure out the new wz encryption without disassembling.
Did you unpack the exe before doing so? If so, may you tell me what protection it is? The tools detect yoda and after unpacking AsProtect, but that can't be cause of CRC checks and so on.
kornto wrote:No.
In msea only some of the folders are encrypted.
For example in UI.wz, the images in WindowUI are encrypted but in another folders not.
I figured out the encryption of kmst some months ago, and i said that i did it without disassembling.
The encryption is still a crap. I keep it private because I don't want that they will change it.
Yes, but how long did it take you to figure out the encryption, and is the encryption overly difficult or relatively simple (both for KMS[T] and MSEA)?
EDIT: Oh wow... I think I just figured out some of the encryption. Koolk, check your PM's on Sleepywood.
EDIT2: Yeah, I just checked. What we're working with is KMST encryption. It's the exact same.
That what i said from start.
The long part was to understand that the images are just encrpyted with XOR. But than it was very fast.
Did you unpack the exe before doing so? If so, may you tell me what protection it is? The tools detect yoda and after unpacking AsProtect, but that can't be cause of CRC checks and so on.
No, I took an unpacked exe.(from GMS, not SEA)
And i think that it can be yoda and AsProtect
Are we talking about the same thing?
We talk about decrypting the text strings. They are simply XOR'd, yes, but that was known like already 2 years.
Our problem now is to find out what they changed from old to new encryption.
Old one was: Every character was XOR'd with another value. The calculation of this "key" was "old_key + 1", starting with the key 0xAA.
New one is: Every character is XOR'd, key starts with 0x01, calculation of the following keys unknown.
Can you PM me, if you don't want to make your ideas public?