Page 1 of 4 123 ... LastLast
Results 1 to 15 of 59

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

Hybrid View

  1. #1
    Registered User
    Join Date
    Jun 2014
    Posts
    5

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

    After a small update, showEQ is no longer tracking correctly in Project 1999. I doubt that anyone is going to pursue an updated seq client so I'd like to see if I can support a fix. But first, two questions:

    1. Up until the patch this week, I had been using the old showeq-5.2.2.0 in an ancient version of Red Hat that used all of the old, required dependencies. I would try one or more of the subsequent versions to see if they worked but they are not available in the seq code archive. Is it possible that one of those may work or did the recent updates create an "alternate reality" that archived versions won't address without doing additional surgery on opcodes?

    2. Is it preferable to find the updated opcodes myself and manually patch my current 5.2.2.0? I saw a HOWTO in one of the forums and it looked doable but I don't want to waste the time identifying the opcode changes and updating the code if there is an easier solution.

    // A

  2. #2
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    I added 5.2.3, 5.2.4, 5.2.5 and 5.3.0 (in the repo there is no 5.2.6-9) to the file section. I hope it helps.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  3. #3
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    If you get it working, please post how you did it.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  4. #4
    Registered User
    Join Date
    Jun 2014
    Posts
    5

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

    Thanks for the archive update, Blue. Unfortunately, none of the 5.2/5.3 archives worked so the update did indeed create an "alternate reality" that can only be resolved by a new branch of opcode/struct fixes. Currently, maps will still properly render for the current zone but SEQ doesn't recognize or render any of the skittles. I suspect that the update changes were minimal (unlike the extensive changes that Sony dropped on big patches back in the day).

    Since I didn't generate any traffic logs when SEQ was working in order to establish a baseline for identifying changes, I'll have to use a hex editor to dig through memory for the opcode tables that Fee, Baelang, ksmith, and the others were talking about. I'd like to use the tools that they used years ago to help expedite this process but I suspect that they are out of date and won't help. Starting from scratch is going to suck but I'm kind of looking forward to the challenge. I will post progress updates.

    // A

  5. #5
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    Great. If need be, I can start a branch for 1999. Let me know if you need anything. I might be able to help.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  6. #6
    Registered User
    Join Date
    Jul 2014
    Posts
    1

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

    fwiw, my suspicion is this change is due to the removal of the con color from the UI. The client likely relied on the mob's lvl or similar, which was changed/removed in order to prevent the client from displaying the color. That'd be the first place I'd check. Haven't looked that deep into the network protocol yet, so treat these thoughts accordingly.

    Do protocol changes required an updated dsetup.dll? If so, another approach may be to reverse engineer the dsetup.dll changes in the last patch.

  7. #7
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    Con colors are based off of your level vs mob level. It used to be a fixed scale, but the blue/lt blue was converted to a sliding scale at some point.

    If you are seeing all gray spawns, I would first check to make sure that SEQ is seeing your level and the mobs level correctly. SEQ should automatically color them. If the mobs are showing the right level, but your toon is not, you can set your level (in one of the menus) and it should color the mobs accordingly.

    In the debug window, are you getting any struct mismatches or wrong op code warnings?
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  8. #8
    Registered User
    Join Date
    Jul 2014
    Posts
    2

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

    Thanks to everyone working on this, I just got seq going again and a week later the patch broke it Most of the NPC types show up as level 83 mermaids. Also seems to be a lot of garbage for pathing directions and the names in the NPC list are garbled. I'm happy to provide any assistance I can

  9. #9
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    What kind of errors are you seeing in the console?
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  10. #10
    Registered User
    Join Date
    Jun 2014
    Posts
    5

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

    I also suspected that the removal of con color may have been a contributing factor but it isn’t something that is easily fixed by manually updating the character level in seq. Not only are the NPC and other player attributes showing up as random garbage, the coordinates are showing up as random locations, some way beyond the constraints of the map, which ruins map rendering. Leaving seq running for a while eventually results in segfault.

    For troubleshooting, the console window doesn’t give much that is likely to help in identifying opcodes and structs that are off. The following is one reoccurring series of warnings that is given every time a zone change occurs:

    Warning: L Line 14 in map '/usr/local/share/showeq/maps/oggok.map' has 44 points as opposed to the 45 points it specified!
    Warning: L Line 42 in map '/usr/local/share/showeq/maps/oggok.map' has 11 points as opposed to the 7 points it specified!
    Warning: L Line 44 in map '/usr/local/share/showeq/maps/oggok.map' has 11 points as opposed to the 7 points it specified!
    Warning: L Line 59 in map '/usr/local/share/showeq/maps/oggok.map' has 17 points as opposed to the 16 points it specified!
    Warning: L Line 62 in map '/usr/local/share/showeq/maps/oggok.map' has 17 points as opposed to the 16 points it specified!


    I also turned on all logging and debug dump options but I’m not quite sure what to do with the data that it generates in ~/.showeq. There is quite a bit of this but I am not sure whether it is significant to the problem:

    Jul 04 2014 13:49:47:343 [66.55.145.2:7042->client:57631] [Size: 77]
    [OPCode: 0x300] [Flags: 5a] [CRC ok]
    000 | 00 03 5a 78 5e 93 38 2d 22 c0 c5 60 c3 c9 d8 f1 | ..Zx^.8-"..`....
    016 | d9 fc e1 ff ff cf 19 72 ee 1f ff c7 f0 e0 c9 6e | .......r.......n
    032 | 01 06 4e 96 5f e7 ad 9d 99 18 18 40 58 9e 49 e2 | [email protected].
    048 | b4 c8 3c 6e 06 17 4f f9 07 5f 96 3f d0 62 30 f8 | ..<n..O.._.?.b0.
    064 | bf d5 7e 13 58 25 00 6e 15 1b 4e 09 26 | ..~.X%.n..N.&
    Jul 04 2014 13:49:47:443 [66.55.145.2:7042->client:57631] [Size: 27]
    [OPCode: 0x14cb] [Flags: a5] [CRC ok]
    000 | cb a5 14 9c 08 00 00 18 00 a3 05 a0 e0 80 ff df | ................
    016 | 00 b5 3f ce fe 00 e0 e4 bb a0 84 | ..?........


    In reading the HOWTOs on addressing patch day problems, the reoccurring methods involved finding the opcodes and structs in memory and making sure that the corresponding values in everquest.h were consistent. That may have been an oversimplification of the solution but the forum discussions unfortunately assumed a significant level of familiarity with the code.

    So in the spirit of giving a man a fishing pole instead of a fish, my questions would be:

    1. Where would be the best source of log/dump/console data for identifying opcodes/structs that need to be fixed? From the development forum, it isn’t clear whether it is too late to use any of that information because seq isn’t working, as opposed to pulling logs to establish a baseline when seq IS working.
    2. How much of the problem involves pulling opcodes from memory? I can decompile .exe’s and hex dump memory but the forum discussion isn’t clear about the relevancy. Some of the forum solutions discussed don’t involve using a hex editor at all.


    Please advise?

    Thanks - A

  11. #11
    Registered User
    Join Date
    Jun 2014
    Posts
    5

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

    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

  12. #12
    Registered User
    Join Date
    Oct 2011
    Posts
    12

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

    They are encrypting spawn info, dont think this is something they ever did on live, so you're going to have to get much deeper, I have my doubts its easily fixable.

  13. #13
    Registered User
    Join Date
    Jul 2014
    Posts
    10

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

    Quote Originally Posted by amiraldayuk View Post
    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.

  14. #14
    Did you SEQ today? BlueAdept's Avatar
    Join Date
    Dec 2001
    Posts
    2,005

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

    On live, I believe they encrypted everything (spawns were all unknown and user was level 1). I believe it used to be an 8 bit encryption then they changed it to 32 bit (might have been 64 bit) but for some reason they got rid of it and changed it to an xor. For a long time, there was a libeq.a file, it had all the decryption in it. I believe it is in the libeq.cpp in the versions used by 1999.

    I was never very good at the code, I helped occasionally. Structvis used to help me quite a bit. (it is still somewhere on the forums). You will have to take my posts with a grain of salt. It has been MANY years since I really played and even longer since I had done anything with the code.
    Filters for ShowEQ can now be found here. filters-5xx-06-20-05.tar.gz

    ShowEQ file section is here. https://sourceforge.net/project/show...roup_id=10131#

    Famous Quotes:

    Ratt: WTF you talkin' about BA? (Ok.. that sounds like a bad combo of Diffrent Strokes and A-Team)

    Razzle: I showeq my wife

  15. #15
    Developer
    Join Date
    Jul 2004
    Posts
    920

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

    Project 1999 uses the Titanium client? So they can really only do what that client allows them plus whatever they inject into it. I guess it wouldn't be that hard to inject actual encryption into the client, but nothing in what you cut and pasted above screams "This is encrypted" to me. That last packet with the huge payload is an issue, but it could be a seq bug. If you are serious about making it work and they have been serious about stopping network sniffing, your biggest asset will be someone who can disassemble the client and see what it is doing differently. It's a really difficult problem to protect the network stream when the client is by default compromised.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is On