[Help] MU Packeting [Select Character] Enc/Dec

[nagasheiro]

Hey guys, so basically I've been to a great success using the decrypt functions that this community so gladly gave me (us). I am talking about ENC1/DEC1, XOR tables, etc, and well, it works.

However, I am having problems while trying to manufacture the "select char" packet.

Couple notes here:

The "select char" packet is NOT encrypted, could be encoded, but it doesn't go through the regular C1/C3 encryption. It sorts of drive me crazy because the packet is composed by the following.

This is the "select char packet" for a characther named aaaaaaaaaa [10 letters]

[ C1 0E F3 79 A4 77 89 9B D9 10 8F 58 70 4C ]

C1 0E F3 79 A4 77 89 9B D9 10 8F 58 70 4C

C1 = Header
0E = Size [14]
F3 79 = [Select Char]
A4 77 89 9B D9 10 8F 58 70 4C = aaaaaaaaa

a in hex = [0x61]
a in "int" = 14


Now the "select char" packet for a characther named bbbbbbbbbb

[ C1 0E F3 79 A7 77 8A 9B DA 10 8C 58 73 4C ] - bbbbbbbbbb
[ C1 0E F3 79 A4 77 89 9B D9 10 8F 58 70 4C ] - aaaaaaaaaa
Let's see whats changed?

C1 0E F3 79 A7 77 8A 9B DA 10 8C 58 73 4C

Green = Same
Red = Different

---

Let's now grab the select char bbbbbbbbbb packet and change one byte only.

C1 0E F3 79 A7 77 8A 9B DA 10 8C 58 73 4Cto
C1 0E F3 79 A8 77 8A 9B DA 10 8C 58 73 4C

RESULT

It tried to select a char named mmbbbbbbbb

Proof:




I am using a 0.97D Gameserver by Darkteam, regular encrypt/decrypt keys.

Keypoints

1. The packet is not encrypted, it does not count against the counter, it is indeed a C1 packet after all
2. The previous packets have no influence on this packet, it is not grabbing information from the previous packet to encrypt
3. The packet is 100% static, it won't change, if you can replay it, and you're the owner of the char, it will actually select the character without a problem
4. There is probably a XOR operation going on but I cannot find it, I tried debugging with AIDA but I could only find regular keys
5. Maybe it is using UTF-16 instead of UTF8? It is weird.

If any of you have information on this, please go ahead and shed some light, I will be grateful.

Thank you all!

[MentaL]

[nevS]

The result of the weakest 3 byte xor key/algorithm would instantly jump into to your eyes with repeating bytes every 3 positions, so you can exclude that, too.

I don’t know exactly how it’s working at the 0.97d version, but imho it looks like the „regular“ xor encryption algorithm with the 32 byte key.

[nagasheiro]

But why changing one byte changes two letters?
Maybe some UTF16 crazy magic going on?

I mean, there can be Chinese named characters, maybe they are using 4 bits instead of 2.

Anyway, thanks for the answer nevS, I will keep looking.

[nevS]

Hm, yes that’s a bit strange. Maybe it’s working by taking two bytes in every xor operation and taking the previous result into account (like the normal C1 encryption). Then you would see a result like this:

[ C1 0E F3 79 A7 77 8A 9B DA 10 8C 58 73 4C ] - bbbbbbbbbb
[ C1 0E F3 79 A4 77 89 9B D9 10 8F 58 70 4C ] - aaaaaaaaaa

Then it’s still a question why changing the first byte changes the first two letters. one thing is, the decryption works by starting at the end of the packet, so that following characters are not affected. Then, why changing the first byte changes the second character? Maybe it’s using two rounds of XOR... one that takes 2 bytes and then one which xores one byte with the other one.

[nagasheiro]

I will try the regular C1 decode a little more now. It is probably using the previous byte.

Thanks nevS, I will keep posting my """"""progress""""""

[nagasheiro]

thanks nevS, managed to fix it, doing the regular C1 going backwards and skipping the last.

by the way, what do you know about the sync packet? I can't seem to make any sense out of them too. Any tips? I need to keep sending it, I know the header, but not sure what information I should encode.

[nevS]

Do you mean the ping packet every 20 or 30 seconds? It contains the tick count and attack speed to detect speed hacks... ;)