maststef wrote: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?
I know what is your problem, but they didn't encrpyt only the text.
They encrypted the images too.
And i already made a working extractor with this encrpytion.
maststef wrote: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?
I know what is your problem, but they didn't encrpyt only the text.
They encrypted the images too.
And i already made a working extractor with this encrpytion.
I wrote an extractor, too (see my sig). That's why I don't get this discussion...
Or wait, what do you mean by "images"? The pictures or the *.img files?
The only problem right now is the new string encryption.
Or did you mean they changed the way how the pictures are stored wz files? (the pictures are not really encrypted, just , let's say, "packed" to keep the file size small)
maststef wrote: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?
I know what is your problem, but they didn't encrpyt only the text.
They encrypted the images too.
And i already made a working extractor with this encrpytion.
I wrote an extractor, too (see my sig). That's why I don't get this discussion...
Or wait, what do you mean by "images"? The pictures or the *.img files?
The only problem right now is the new string encryption.
Or did you mean they changed the way how the pictures are stored wz files? (the pictures are not really encrypted, just , let's say, "packed" to keep the file size small)
My extractor is working with KMS. I know what i am talking about.
Well, that's fine if you know what you are talking about. But not telling these actual facts has no use in a forum that wants to discover the file structure.
Don't get me wrong, I don't want to be offensive. But the only thing you write here is, that you can extract it. But that doesn't help us.
To summarize:
The exe file is encrypted for sure. It used to be ASprotect, but I haven't checked since before we even started this.
The new text encryption was easy to decode for the regular ASCII strings. The unicode stuff took a bit more work and just comparing string between GMS and KTMS. From what I found, the decryption string was different for ascii and for unicode, but they looked fairly similar so I'd assume it just has to do with the character location and the byte ("more different" as you progress through the string)
They also redid the way images are stored. Before there was a clear zlib stream with the magic word stored at the beginning of the string. The magic word is no longer there (or it's encrypted somehow). Comparing the length of the images between the GMS/KTMS files showed that they were different lengths (at least the ones I checked...could have been those images were modified....I didn't really look into that much)
As for a complex encryption scheme, I doubt they would overcomplicate it. The more encryption they add, the longer it takes to load. XOR is used since it is super fast to do.
The same way I did decode the ASCII strings. But did you found out the math behind the new key? Or do you think there is no math (--> only random bytes in an array)?
With "magic word" do you mean the "0x78 0x9C" bytes? These are not needed for the decompression. The plain deflate algorithm (that's used in many programming libraries, so without all the additional zLib stuff) does not need them. For example, my tool is written in C#.Net, I also use the deflate algorithm from it. And it only works if I skip the first two zLib bytes (because they don't really belong to the stream, they are just saying "Here come's zLib with this or that compression level", but as stated above this is not needed to run the deflate algorithm on it).
Maybe Nexon did throw away their zLib library and switched to another deflate routine.
If you want, you can send me one of these new compressed blocks (copy and paste it in a new file) than I can check, if it is still a deflate block. (I'm not downloading KMSt, because I focus on GMS [and I can't read Korean])
Oh cool, Nexon works together with Valve. I didn't knew that.
On the first view this has nothing to do with the file structure that MapleStory uses.
And in all games I saw from Nexon the file structure was different each time.
Ah, okay. I suppose it depends on the development house etc.
I suppose it was worth a look anyway!
I'll keep my fingers crossed for help with the other files, I looked through the tutorial for archive research etc, but it really is just a bunch of numbers and letters to me.. I just don't "get it".
themoviefund wrote:Hmm. I have a question, is the KMST encryption the same as MapleSEA's new encryption?
I think it is. I can not imagine that Nexon would use three different encryptions at the same time. Knowing how they mess up several things each patch or server check, they would completly mess up the wz files, too.
This is no fact, it's just how I see it, because I have no MSEA wz file to check it, if someone has a MSEA file I could check it!
I ask my question again: Anyone already figured out some math behind the new encryption (KMSt)? I only have all the bytes needed to decrypt, found out by trial-and-error decrypting. But I can't tell where this byte order does come from...
But I will implement one in my WZextract tool. But to do so, I will have to rewrite some parts of it. But because I'm busy with studies this may take a while (weeks or months).
