Looking for ShowEQ update for Project 1999 after v33 6/25 patch

Its dsetup.dll in their patch that does this: http://www.project1999.com/files/P99Files33.zip

I think that giant opcode is the result of a memory leak in SEQ due to the struct sizes being wrong. If you do zone log file you can clearly see that the spawns and such are not encrypted, including location and name in clear text, and if you run the client in gdb and it doesnt crash, you can con mobs and gray skittles will be drawn in the correct place. I'd try correcting the structs too even it if just means creating dummy fields at least to keep the client sane.

the reason i think it's a memory leak is because on my vm i could see text such as file paths, etc that clearly would not be transmitted from the game client.

Even though I have not looked, I still feel that it is the struct size mismatch that is causing a lot of the problem. I really do not think it is a new encryption since you are getting some things.

Quote:

---

Originally Posted by amiraldayuk

I'm not sure if I am barking up the wrong tree but I applied some of the techniques that others have been discussing and found a couple of inconsistencies that I'm not sure are relevant. I generated a zone log and then compared the data with structs that are currently in the 5.2.2.0 everquest.h. All but two of the structs that I have found so far are consistent as far as size but there were two exceptions:

First exception: In everquest.h, ServerZoneEntryStruct has a length of 383 octets but the struct was logged as size 385:
(from everquest.h)
/*
** Server Zone Entry struct
** Length: 383 Octets
** OpCode: ZoneEntryCode (when direction == server)
*
* This is just a spawnStruct for the player
*/
struct ServerZoneEntryStruct : public spawnStruct
{
};

(from zone.log)
Jul 04 2014 15:13:20:033 [Decoded] [Server->Client] [Size: 385]
[OPCode: 0x7213]
[Name: OP_ZoneEntry][Updated: 10/27/05][Type: ServerZoneEntryStruct (385) ==]
000 | 00 00 00 00 00 00 00 4d 53 3c 20 22 45 59 39 5a | .......MS< "EY9Z
016 | 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | <...............
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
064 | 00 00 00 00 00 00 00 82 00 00 00 00 00 00 00 00 | ................
080 | 00 00 00 00 00 00 4e 29 00 00 00 00 00 00 00 00 | ......N)........
096 | bb 52 ce bb 46 00 2f 00 00 00 00 cd 34 00 00 00 | .R..F./.....4...
112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
128 | 00 00 00 00 00 00 00 00 00 00 00 49 00 00 00 00 | ...........I....
144 | 00 00 00 00 00 00 00 4b 00 00 00 00 00 00 00 00 | .......K........
160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
192 | 00 00 00 00 00 4f 00 00 00 53 00 00 00 31 00 00 | .....O...S...1..
208 | 00 4a 00 00 00 39 00 00 00 4f 00 00 00 53 00 00 | .J...9...O...S..
224 | 00 23 00 00 00 9e 00 00 00 0b 79 33 70 00 da 49 | .#........y3p..I
240 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
256 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
272 | 00 00 00 00 b0 b2 c9 b7 00 00 00 00 40 00 00 00 | ............@...
288 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
304 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
320 | 00 00 00 00 d0 aa d6 73 00 00 00 5b 00 00 4b 32 | .......s...[..K2
336 | 00 00 00 b7 37 55 00 00 00 00 00 00 00 00 00 ae | ....7U..........
352 | 00 00 00 cc 00 00 00 b7 00 00 00 c7 00 00 00 b2 | ................
368 | 00 00 00 ae 00 00 00 cc 00 00 00 b7 00 00 00 c7 | ................
384 | 00

Second exception: In everquest.h, zonePointsStruct has length of 24 octets but is logged with 52:
(from everquest.h)
/*
** ZonePoint
** Length: 24 Octets
** Sent as part of zonePointsStruct
*/

struct zonePointStruct
{
/*0000*/ uint32_t zoneTrigger;
/*0004*/ float y;
/*0008*/ float x;
/*0012*/ float z;
/*0016*/ float heading;
/*0020*/ uint16_t zoneId;
/*0022*/ uint16_t zoneInstance;
/*0024*/
};

(from zone.log)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 52]
[OPCode: 0x3eba]
[Name: OP_SendZonePoints][Updated: 10/27/05][Type: zonePointsStruct (28) nc]
000 | 01 00 00 00 01 00 00 00 33 f3 cd 44 cd ac 4a 44 | ........3..D..JD
016 | 00 00 74 42 00 00 02 43 2f 00 00 00 00 00 00 00 | ..tB...C/.......
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
048 | 00 00 00 00

Is this worth pursuing? It seems on track with the forum guidance regarding inconsistencies in struct sizes. I should also note that the console window didn't produce any useful error messages about inconsistent opcodes or struct sizes during these captures.

Also, there are many entries in the log file of which I'm not sure of the significance. What do these mean?
Examples:
(opcode but zero size)
Jul 04 2014 15:13:15:244 [Decoded] [Server->Client] [Size: 0]
[OPCode: 0x3cdc]

(opcode and size but no label)
Jul 04 2014 15:13:18:256 [Decoded] [Server->Client] [Size: 768]
[OPCode: 0x1234]
000 | bf 00 00 00 03 00 03 00 09 00 09 00 12 00 12 00 | ................
016 | 13 00 13 00 21 00 77 21 39 00 5e 21 3d 00 3d 00 | ....!.w!9.^!=.=.
032 | 3f 00 3f 00 40 00 40 00 48 00 48 00 50 00 50 00 | ?.?.@[email protected].
.... to 768

(opcode and name but no size)
Jul 04 2014 15:13:20:268 [Decoded] [Client->Server] [Size: 0]
[OPCode: 0x7ac5]
[Name: OP_ReqNewZone][Updated: 10/27/05]

(a gigantic one that I'm not sure what to make of - seems to contain opcode information later on)
Jul 04 2014 15:13:31:448 [Decoded] [Server->Client] [Size: 4294967295]
[OPCode: 0000]
000 | 00 00 fe d5 00 00 00 00 00 00 ff ff ff ff 00 00 | ................
016 | 00 00 62 00 09 00 e6 47 0f 00 00 00 00 00 00 00 | ..b....G........
032 | 00 00 00 00 00 fd 01 00 00 31 00 00 00 00 00 00 | .........1......
048 | 00 94 11 00 7f 00 00 00 00 66 66 6c 42 00 80 c1 | .........fflB...
064 | 43 00 00 58 43 49 54 36 33 5f 41 43 54 4f 52 44 | C..XCIT63_ACTORD
080 | 45 46 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | EF..............
096 | 00 00 00 00 00 fe d5 00 00 00 00 00 00 ff ff ff | ................
....

Thoughts?

// A

---

Looking at the two opcodes you mentioned it doesn't look like either of them are the wrong size. The first struct is a spawnStruct which is 385 bytes (the comment in the header must be off because spawnStruct does appear to be 385.) The second opcode is actually zonePointsStruct (not zonePointStruct) which looks to be a wrapper around zonePointStruct for the 52 byte packet.

Something is causing a memory leak which makes the client crash eventually, i'd wager it's struct changes from the con color updates.

So, bad news.

Just looked at it again and I do have some zone logs from pre-patch.

Before:

Code:

---

May 18 2014 xx:xx:xx [Decoded] [Server->Client] [Size: 38500]
[OPCode: 0x2e78]
[Name: OP_ZoneSpawns][Updated: 10/27/05][Type: spawnStruct (385) %]
000 | 00 00 00 00 00 00 00 6f 72 63 5f 63 65 6e 74 75  | .......orc_centu
016 | 72 69 6f 6e 30 30 31 00 00 00 00 00 00 00 00 00  | rion001.........
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
064 | 00 00 00 00 00 00 00 00 00 00 00 00 00 e0 40 00  | ..............@.
080 | 00 00 00 01 00 00 64 64 00 00 00 00 00 00 00 fc  | ......dd........
096 | 48 01 df 1c 00 00 53 fe 07 00 00 80 a6 00 00 00  | H.....S.........
112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
128 | 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00  | ................
144 | 01 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00  | ................
160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................

---

Now

Code:

---

Jul 02 2014 xx:xx:xx [Decoded] [Server->Client] [Size: 38500]
[OPCode: 0x2e78]
[Name: OP_ZoneSpawns][Updated: 10/27/05][Type: spawnStruct (385) %]
000 | 00 00 00 00 00 00 00 53 09 39 55 40 2d 24 35 47  | .......S.9U@-$5G
016 | 30 6d 34 39 41 42 2d 7a 6b 02 00 00 00 00 00 00  | 0m49AB-zk.......
032 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
048 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
064 | 00 00 00 00 00 00 00 00 00 00 00 00 00 b2 17 00  | ................
080 | 00 00 00 4b 00 00 27 56 00 00 00 00 00 00 00 86  | ...K..'V........
096 | 7e 33 b5 54 00 00 aa 42 00 00 00 d2 8d 00 00 00  | ~3.T...B........
112 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
128 | 00 00 00 00 00 00 00 00 00 00 00 4a 00 00 00 00  | ...........J....
144 | 5b 00 00 00 00 00 00 16 00 00 00 00 00 00 00 00  | [...............
160 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
176 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................

---

I guess I am wrong.

yup, spawn data is surely encrypted now. dsetup.dll ballooned by almost 1MB since last release and it already foils debugger hooks so unless someone can deobfuscate and disassemble the dll and inspect the encryption, seq is dead on p99.

I do not know if anyone who knows how the old encryption worked is still around (I believe it was just an XOR (might have been ROT13 cant remember) and since everything still lines up correctly, might still be an XOR but just changed a little). I know purple is still around (since he posted) but I do not know if he worked on any of the encryption in the past or would be willing to look at it. Even though IEATACID doesn't show up here much, he is still at the MQ2 boards. Since he is still current on things, he might be your better shot at fixing it.

Using a zone log where we know what the spawn names should be, XOR encryption could be cracked using frequency analysis (in theory).

Or if we know what the plaintext of an encrypted string is, we could XOR them together:

encrypted = plaintext XOR key
key = encrypted XOR plaintext

After a little research, I verified that everquest used XOR. Since the client is titanium, I would assume that they are still using XOR but changed the key/method. If anyone is able to fix it, I can start a new section and branch for 1999 if there is interest.

Well, there is definitely some XOR going on. Just figured out an XOR key that can decrypt my character name. Going to see if it generalizes to other things.

I do not know if this will help anyone but thought I would post it.

This kind of encryption is trivial to break, even without computers [587,1475]. It will only take a few seconds with a computer. Assume the plaintext is English. Furthermore, assume the key length is any small number of bytes. Here’s how to break it:

Discover the length of the key by a procedure known as counting coincidences [577]. XOR the ciphertext against itself shifted various numbers of bytes, and count those bytes that are equal. If the displacement is a multiple of the key length, then something over 6 percent of the bytes will be equal. If it is not, then less than 0.4 percent will be equal (assuming a random key encrypting normal ASCII text; other plaintext will have different numbers). This is called the index of coincidence. The smallest displacement that indicates a multiple of the key length is the length of the key.
Shift the ciphertext by that length and XOR it with itself. This removes the key and leaves you with plaintext XORed with the plaintext shifted the length of the key. Since English has 1.3 bits of real information per byte, there is plenty of redundancy for determining a unique decryption.

I am by no means an expert here, I never worked on the encryption nor dealt with a lot of the code. The only thing I can provide is information that I remember being talked about and hopefully it will help.

Back in the libeq.a days, I remember being told that the key is sent upon zoning. I do not think it was the key for that zone, but for when you zone again. If you figured out that key for your name, you might want to search previous packets for that key. As I said, I believe it changes each time you zone.

I believe the decoding of the packets comes from packetinfo.cpp and packetinfo.h, as always, I could be wrong. I only glanced at the code.

I havent programmed anything in C since college (over 25 years ago). I was rusty when I was helping with the structs, now it looks like greek to me now. I, unfortunately, will not be much help.

Some good news:

Same key that can decrypt my user name works for names in the spawn struct:

Code:

---

  'a_Krag_Chick003', 
  'a_rock_spiderlind@8',
  'Glisse_Bluesea000',
  'a_goblin_whelp039',
  '\u0002N\u001ei\u0016\u0007\u000b',
  '\u0003E\u0010t\u0003\n\u0012\u0015\u001botw',
  'H\u001de\n\u0006\u001f\u0011',
  'a_dwarf_skeleton003'

---

I'm doing this somewhat manually so it's not working 100% (as you can see above). And, it doesn't seem to work for the two structs I tried it on in this thread (that others posted). However, some of that might be choosing an incorrect offset to start reading the encrypted name.

Here's how I got this far in broad strokes:

1. turn on zone logging
2. cast spell on myself to see what my encrypted name is in ascii (let's pretend it's e8wR&!)
3. search the zone log for the encrypted ascii (cat zone.log | grep e8wR&! -a2)
4. pull out the encrypted bytes for that ascii [65 38 77 52 26 21]
5. since I know my name is "Muffin" [4d 75 66 66 69 6e] the key = [4d 75 66 66 69 6e] XOR [65 38 77 52 26 21]
6. we now have the key: [28 4d 11 34 4f 4f]

After doing this I realized that the key found this way wasn't long enough, so I made a character with a longer name to find a longer key. The longer key shared the first 6 bytes with the shorter key, had for new bytes, and then started repeating. Looks like it's a 10 byte key truncated or repeated to fit the string length.

Any thoughts on where we should go from here?

Nice work. You get an Attaboy for that.

Just need to find someone who can figure out how to change the source now.

Blue, thanks for the help! Missed this post when I commented.

Quote:

---

Originally Posted by BlueAdept

Back in the libeq.a days, I remember being told that the key is sent upon zoning. I do not think it was the key for that zone, but for when you zone again. If you figured out that key for your name, you might want to search previous packets for that key. As I said, I believe it changes each time you zone.

---

It doesn't look like the key changes on every zone as I was able to use the same key to decode the character names for different characters in different zones. It might be possible that different accounts/clients get different keys, as that would explain me not being able to decode the structs from earlier in this thread, but probably too soon to make that assumption.