I've integrated my latest findings into the code, the client will now receive upon zoning in a list of teleport destination points which are retrieved from a DB table. The client will then sent the destination zone when he hits a client side zone line to the server. The server will then try to find the correct destination x,y,z of the new zone.
This is an odd quirk actually - you would expect that the client (who already knows the destination x,y,z since i've sent him this info at zonein) would sent you the coordinates along with the zone name - or at least the zone teleport index # of the destination he wants to use, but that doesn't happened - i debugged that part of the client and im sure its not the intended way - maybe to prevent cheating with teleporting to specific X,Y,Z. We can at least make sure this way that the client really hit a zone line and can force a specific loc.
The db table i've found is pretty good actually, i've tested 20+ zone borders and intra zone teleports (even the ones i added manually previously like erudin and felwitheb) and it works just fine. I only found one issue from nro->freeport because these zones do not end/continue on the same X value as a zone like qeynos hills -> qeynos (when you paste these zones together, they end where the other starts /loc wise for either x or y) - this is useful for putting the player at the exact X or Y when he hits a large zone line - it would be odd when you zone from the right most corner from freeport to nro but zone in in the center of this zone line.
Oh, btw i actually had an issue with the server side "find the destination point where the client wants to zone to" logic, all zones worked fine till i tested freeport, where i zoned ALWAYS into the sewers when i went from freportw to freporte or other way around - well turns out that somebody switched X and Y for finding the correct zone entry point when calculating deltaX²*deltaY²... a few hours lost on this tiny bug
24. Januar 2011
21. Januar 2011
Its been a while...
I've been doing some reverse engineering work since the beginning of the new year.
I noticed that the intra zone teleports do not work for most zones, so i manually added them for felwitheb and erudin. While testing out the zoning, i finally figured out how to set the initial camera position upon zoning, i.e. we can no specify that a player should look up or down after zoning - useful so that the player faces the right direction.
Upon till then, our zoning worked server side, that means when the player moved to a specific location the server noticed it and if the player hit a zone border of teleport pad, we moved him manually. This works fine but is alot of unneeded overhead.
Now back to the intra zone teleporting, it was weird that some teleports did work without any interaction, in erudin for example, the pad from the harbor up to the palace worked. That meant the client knew some coordinates already.
YL provided some interesting input, he noticed that when using eye of zoom near a zone line/pad - the eye would vanishe - the client would kill it. So the client somehow must already knew the locations from WHERE a player should be teleported too, what he didnt knew was the destination of the teleport.
Well after further reverse engineering, i found out that the client had some kind of teleport table with indexes. I found the opcode which needed to be sent to the client along with an array of teleport destination and each specific magic number of each teleport destination. The client already scans the area when a player enters a zone point, he has a hard coded ID for each of these - and we just have to tell him for each of these ID where to teleport the player.
So what that means is, in classic (and afaik still to date) - the client knows only the zone lines but the server will tell him where he should teleport too upon zoning in. After some research i found that eqemu developers could simply take a live packet dump and extract the zone points from there. This is of course 1000 times easier than manually adding each destination teleport point from your own memory (setting up only 8 intra zone points took me around 5h). Of course the destinations change of time so we cant simply take a live dump now, but some older data might be useful, i think i got that covered.
BTW: One interesting info i found during reverse engineering was a funny opcode - it enables us to play a specific sound file to the player. The are all indexed by ID - so any wave file the client knows, we can play it. And the funny part is - if you use an unknown ID you get "This is an error message, please report the bug" in a muffled developer voice =p
I noticed that the intra zone teleports do not work for most zones, so i manually added them for felwitheb and erudin. While testing out the zoning, i finally figured out how to set the initial camera position upon zoning, i.e. we can no specify that a player should look up or down after zoning - useful so that the player faces the right direction.
Upon till then, our zoning worked server side, that means when the player moved to a specific location the server noticed it and if the player hit a zone border of teleport pad, we moved him manually. This works fine but is alot of unneeded overhead.
Now back to the intra zone teleporting, it was weird that some teleports did work without any interaction, in erudin for example, the pad from the harbor up to the palace worked. That meant the client knew some coordinates already.
YL provided some interesting input, he noticed that when using eye of zoom near a zone line/pad - the eye would vanishe - the client would kill it. So the client somehow must already knew the locations from WHERE a player should be teleported too, what he didnt knew was the destination of the teleport.
Well after further reverse engineering, i found out that the client had some kind of teleport table with indexes. I found the opcode which needed to be sent to the client along with an array of teleport destination and each specific magic number of each teleport destination. The client already scans the area when a player enters a zone point, he has a hard coded ID for each of these - and we just have to tell him for each of these ID where to teleport the player.
So what that means is, in classic (and afaik still to date) - the client knows only the zone lines but the server will tell him where he should teleport too upon zoning in. After some research i found that eqemu developers could simply take a live packet dump and extract the zone points from there. This is of course 1000 times easier than manually adding each destination teleport point from your own memory (setting up only 8 intra zone points took me around 5h). Of course the destinations change of time so we cant simply take a live dump now, but some older data might be useful, i think i got that covered.
BTW: One interesting info i found during reverse engineering was a funny opcode - it enables us to play a specific sound file to the player. The are all indexed by ID - so any wave file the client knows, we can play it. And the funny part is - if you use an unknown ID you get "This is an error message, please report the bug" in a muffled developer voice =p
27. Juli 2010
I took some time to find unknown opcodes the client can possibly sent.
I found a few, for example an opcode sent by the client when he receives a new spawn (player) with an unknown guild id. Normally all guilds and their ids are sent upon zoning, but if a new guild is created meanwhile the client does not know anything about the guild (name etc).
I also found a client command i had forgotten about or never used anyway, the /channel command. Apart from the server side filter command this command enables you to turn off the specific chat channels like gsay,ooc,auction,shout,ooc etc. The client can inform the server that he wants to either turn on/off a channel. I identified the requests from the client, we only need to add the filtering to the server which shouldn't be hard.
~ 240min
= 10020min (167h)
I found a few, for example an opcode sent by the client when he receives a new spawn (player) with an unknown guild id. Normally all guilds and their ids are sent upon zoning, but if a new guild is created meanwhile the client does not know anything about the guild (name etc).
I also found a client command i had forgotten about or never used anyway, the /channel command. Apart from the server side filter command this command enables you to turn off the specific chat channels like gsay,ooc,auction,shout,ooc etc. The client can inform the server that he wants to either turn on/off a channel. I identified the requests from the client, we only need to add the filtering to the server which shouldn't be hard.
~ 240min
= 10020min (167h)
26. Juli 2010
I figured out the checksum stuff, the client sents checksum for a few game specific files, and also each time for some specific actions. That the checksum is over 2000 byte was very confusing, but in reality this is all what they wanted, confuse =). For the specific game client files i added a checksum method server side, if the checksum do not match the player will simply be disconnected.
Basically, this means we have a base line of defence now for easy file hacking.
~ 600min
= 9780min (163h)
Basically, this means we have a base line of defence now for easy file hacking.
~ 600min
= 9780min (163h)
20. Juli 2010
I found some interesting opcodes previously unknown, they are the checksum of some specific files (i.e. spdat.eff) that gets transferred to the server. This way it is possible to easily detect modified files, i still have to reverse how the checksum is calculated (its quite huge! over 2000 byte) currently i could only hardcode a "valid" checksum because i know the client has a valid file.
Additionally, i also extended the trigger and traps framework to be able to spawn a random amount of npcs at a specific location (i.e. beetles in necropolis for example).
Finally i've spent alot of time of preparing a video, which is not easy todo because you can die pretty fast from a train triggered from these traps =)
~ 480min
= 9180min (153h)
Additionally, i also extended the trigger and traps framework to be able to spawn a random amount of npcs at a specific location (i.e. beetles in necropolis for example).
Finally i've spent alot of time of preparing a video, which is not easy todo because you can die pretty fast from a train triggered from these traps =)
~ 480min
= 9180min (153h)
13. Juli 2010
Since this weekend i was working on finishing the traps and triggers. I gathered over 50 different trigger messages and traps from live, funny that the zone with the most zone specific "roleplay like messages" is the vanilla zone runnyeye. Other messages happend mostly in velious zones, but also very rarely. I added a database based configuration for these triggers. Basically you just can have an existing invisible npc (or create on in the database) and define at what proximity a trigger should happend. A trigger can either be just a message, an AE spell, or a group of spawns at a specific location or all of them together.
The first spawn based trap i added was the one for frozen tower, when you enter the zone just to the left 3 shadowbones will spawn. There are more zones with triggers like this, necropolis and runnyeye comes to my mind, im not aware of any other currently.
I also worked on the spell effects a trap executes, i had issues getting the spell effects visible to the client, after a bit of debugging i found out that the invisible npcs where not sent to the client, and when you want to see a spell effect you supply a caster ID of the mob who casts the spell. If the client doesnt know this id, you will obviously see no effect.
I hope i can make a video this week about triggers, since i will be gone for a short vacation for the rest of the week.
~ 1200min
= 8700min (145h)
The first spawn based trap i added was the one for frozen tower, when you enter the zone just to the left 3 shadowbones will spawn. There are more zones with triggers like this, necropolis and runnyeye comes to my mind, im not aware of any other currently.
I also worked on the spell effects a trap executes, i had issues getting the spell effects visible to the client, after a bit of debugging i found out that the invisible npcs where not sent to the client, and when you want to see a spell effect you supply a caster ID of the mob who casts the spell. If the client doesnt know this id, you will obviously see no effect.
I hope i can make a video this week about triggers, since i will be gone for a short vacation for the rest of the week.
~ 1200min
= 8700min (145h)
9. Juli 2010
The last two days:
I fixed some doors in necropolis and pendulum traps, and added the missing qeynos doors to a delta sql. Then i create a db table for triggers with different attributes and integrated it into the base code. Triggers can now be easily assigned to "hidden" npcs. They can either cast spells, summon X mobs or just print a message. Then i made certain that mobs or players cannot attack triggers.
I also added the 15 different traps for necropolis including their spells and trigger messages. I started with exploring EQ Live again and started gathering all the environment messages i have the location of: chardok, frozenshadows, kael, runneye, westwaste. I checked some other zones i had some info on but they did not have (anymore?) the messages. There are a few kunark/velious zones left i have to check.
~ 780min
= 7500min (125h)
I fixed some doors in necropolis and pendulum traps, and added the missing qeynos doors to a delta sql. Then i create a db table for triggers with different attributes and integrated it into the base code. Triggers can now be easily assigned to "hidden" npcs. They can either cast spells, summon X mobs or just print a message. Then i made certain that mobs or players cannot attack triggers.
I also added the 15 different traps for necropolis including their spells and trigger messages. I started with exploring EQ Live again and started gathering all the environment messages i have the location of: chardok, frozenshadows, kael, runneye, westwaste. I checked some other zones i had some info on but they did not have (anymore?) the messages. There are a few kunark/velious zones left i have to check.
~ 780min
= 7500min (125h)
Abonnieren
Posts (Atom)