Here I am, all excited about EQ2, and I've just got my Detours working, I've rewritten my DLL injector to include process module list spoofing (and unspoofing), and I've wrote-up a nice memory-space differ, and I come here and you guys are already hard at work.
Wonder if anyone remembers me. Howdy Plazmic, coworker or ex-coworker!
My pokings inside of EQ2 show a remarkable similarity to EQ1 so far. Sort of disappointing.
And almost NO countermeasures. I mean, come on, at least patrol your loaded module list, Sony... jeez.
Anyway, it's late.
-- T
ps: I think my old username was madmonk or something along those lines.
Hmph.
Moderator: MacroQuest Developers
Well, my network packet receive detour is finally working (including my reverse of their silly XOR packet "encryption" -- heh) and it's a good news/bad news thing.
The good news is, it works. EQ2 is far from unhackable.
The bad news is, Sony really redesigned a lot of stuff in EQ2. First of all, it appears that spawn updates are radiused at the server. This means that, unlike in EQ1, you don't get updates about spawns halfway across the zone; you only get updates about spawns near you. This is a smart change on their part, since at the cost of a tiny bit of extra processing on the server end, they save a ****load of network traffic, and they have made programs like ShowEQ impossible in one fell swoop. Dammit.
Also, it appears that a lot more of what happens is determined on the server side. I'm still looking for the right offsets to do a teleport jump (ala my private version of MQ used to do), and I think that may work (since due to the facts of life of distributed network games, you end up having to have the client tell you where he is, and possibly verify that, rather than telling the client where he is, to avoid rubber-banding effects). But a lot of other stuff is just text messages sent from the server to be displayed raw on your end; this doesn't leave a hunter-killer script much to do except do raw text-parsing, which is fugly in C++. Perl is a lost cause since embedded Perl is leaky as a sieve.
There is still hope, but it appears that some of the really sneaky things you could do in EQ1 simply won't be possible in EQ2. Dammit.
Ah well, at least my packet detour works. I've dumped out megs and megs of packet data with associated chat logs, so the ShowEQ guys, if they're interested, can use them to try to decrypt the protocol.
Bugger.
-- atomx (formerly: amadmonk)
The good news is, it works. EQ2 is far from unhackable.
The bad news is, Sony really redesigned a lot of stuff in EQ2. First of all, it appears that spawn updates are radiused at the server. This means that, unlike in EQ1, you don't get updates about spawns halfway across the zone; you only get updates about spawns near you. This is a smart change on their part, since at the cost of a tiny bit of extra processing on the server end, they save a ****load of network traffic, and they have made programs like ShowEQ impossible in one fell swoop. Dammit.
Also, it appears that a lot more of what happens is determined on the server side. I'm still looking for the right offsets to do a teleport jump (ala my private version of MQ used to do), and I think that may work (since due to the facts of life of distributed network games, you end up having to have the client tell you where he is, and possibly verify that, rather than telling the client where he is, to avoid rubber-banding effects). But a lot of other stuff is just text messages sent from the server to be displayed raw on your end; this doesn't leave a hunter-killer script much to do except do raw text-parsing, which is fugly in C++. Perl is a lost cause since embedded Perl is leaky as a sieve.
There is still hope, but it appears that some of the really sneaky things you could do in EQ1 simply won't be possible in EQ2. Dammit.
Ah well, at least my packet detour works. I've dumped out megs and megs of packet data with associated chat logs, so the ShowEQ guys, if they're interested, can use them to try to decrypt the protocol.
Bugger.
-- atomx (formerly: amadmonk)
Hmm.
A lot of peeps are looking forward to a macro program for EQ2. Just being able to target mobs and macro an attack would be an accomplishment. The EQ hacking community as already stated it's objection to any open source EQ2 macro utility on another board. It seems that I am not the only one who doesnt like what a thousand freeloading noobs does to a game with opensource cheat software. :)
-j
-j
Movement is usually client-side, with some exceptions.
The reason is that movement is a continuous process; if the client had to wait for the server to tell it where it is, movement would appear to be jerky, updating as packets arrived.
What happens is that the client calculates location based upon time, velocity, all those good physics variables, and then updates the server. The server can either accept this or reject it based upon its own calculations of where you are and where you could reach -- in EQ1 you could set your location to any zoneloc you wanted, but the server would reject loc changes that were out of your LOS (with one important exception; a hack that Kaz found and I absolutely loved). Within your LOS, you could "hop" to any location you wanted simply by poking in new coords.
The big concern is getting caught; if you suddenly report that you're 3/4 of the way across the zone, the server *might* report that to someone who took a closer look at you -- and bam. You're banned. However, this isn't as risky as it sounds because the latencies in communication mean that sometimes the server and client will have a fairly large discrepancy in their opinion of where you are.
It looks like this hasn't changed much in EQ2, which makes sense since there's not really any other way to do player motion that results in smooth, believable game-world movement. Other games that try to wait for the server to update the position tend to have bad "rubber banding" effects as the client predicts the location at one point (and renders the display for that loc) and the server updates the client with the REAL location, causing the display to jump pos. Fugly, and Sony chose to make motion client-side.
The reason is that movement is a continuous process; if the client had to wait for the server to tell it where it is, movement would appear to be jerky, updating as packets arrived.
What happens is that the client calculates location based upon time, velocity, all those good physics variables, and then updates the server. The server can either accept this or reject it based upon its own calculations of where you are and where you could reach -- in EQ1 you could set your location to any zoneloc you wanted, but the server would reject loc changes that were out of your LOS (with one important exception; a hack that Kaz found and I absolutely loved). Within your LOS, you could "hop" to any location you wanted simply by poking in new coords.
The big concern is getting caught; if you suddenly report that you're 3/4 of the way across the zone, the server *might* report that to someone who took a closer look at you -- and bam. You're banned. However, this isn't as risky as it sounds because the latencies in communication mean that sometimes the server and client will have a fairly large discrepancy in their opinion of where you are.
It looks like this hasn't changed much in EQ2, which makes sense since there's not really any other way to do player motion that results in smooth, believable game-world movement. Other games that try to wait for the server to update the position tend to have bad "rubber banding" effects as the client predicts the location at one point (and renders the display for that loc) and the server updates the client with the REAL location, causing the display to jump pos. Fugly, and Sony chose to make motion client-side.
Hmm.
Perhaps it once was that way, but it certainely isn't the case now. When a location update is sent, there aren't any sanity checks related to line of sight. If you notify the server that you're at a particular set of coordinates, it doesn't ask questions.atomx wrote:in EQ1 you could set your location to any zoneloc you wanted, but the server would reject loc changes that were out of your LOS
cronic
I actually agree. I am a macroer and an exploiter (there, I said it), but I will not give out my source to anyone who hasn't proven to me that they can and will contribute, and if I distribute binaries, I'm going to hardcode the offsets into the binary (which is far from impossible to reverse, but if you can reverse-engineer the offsets out of a compiled binary, get off your lazy ass and help with the project!)eqjoe wrote:A lot of peeps are looking forward to a macro program for EQ2. Just being able to target mobs and macro an attack would be an accomplishment. The EQ hacking community as already stated it's objection to any open source EQ2 macro utility on another board. It seems that I am not the only one who doesnt like what a thousand freeloading noobs does to a game with opensource cheat software. :)
-j
I want to put together a core of a few people to make a MacroQuest look-alike for EQ2. With the packet engine detoured, we've got about 10% of the work done. Still remaining:
Offsets
-----------------
* commands entered
* chat output (found!)
* network receive (found!)
* location/heading
* spawn lists (these appear to be in std::map's now, key is spawnid)
Components
------------------
* IPC -- I want to do the macro processing out-of-process; there are a lot of reasons for this, but the biggest one is that if the macro-processor crashes, it won't take EQ2 with it. So, IPC is necessary.
* Stealthing -- I already hide my injected DLL from the loaded module list, but I'd like to have some folks pay close attention to making sure that Sony can't detect our code. I'd also like to find a way to make it hard for others out of the "inner circle" to get ahold of the code/binaries. I'm not sure what the best way to do this is -- as a hacker, I'm well aware that no security is insurmountable, but if you make it inconvenient enough, people won't do it (usually).
Information
-------------------
* Packet encryption --I need someone to reverse engineer the RSA encryption that's on about 1% of the packets still, and to properly inflate the packets that have been deflated (again, about 1%). This will give me 100% of the packets that I receive, not just 98% (like now).
* Packet protocol -- now that we have the packets, we need to start figuring out which opcodes mean what, what the offsets are, etc.
[Note that it's a *lot* better to use packets to trigger events than detoured offsets within the binary, because detours require offsets (that are not always trivial to find) and are inherently vulnerable to code changes. There are a few (very few) events that will require "internal" hooks, but almost everything else can be based on events received in packet form.]
* Class layouts for the important classes (or at least as much as we can get of the SPAWNINFO, ACTORINFO, etc. classes)
Tools
--------------
* Offset finder. I think maybe this is already solved (with IDA scripts? Don't know anything about IDA scripts yet...), but manually re-locating the offsets with each patch is a pain in the ass. I'd like some kind of tool to mostly reautomate rediscovery.
* Macro processor -- with the macro processing out of process, this becomes pretty easy. It can be written in damned near anything -- perl, c#, LISP, whatever -- as long as it can talk the IPC protocol we come up with (which should be as simple as possible; command-response and broadcast, at most; I don't want to deal with passwords and permissions and stuff like that).
* Process explorer -- to find new offsets/values. I've already got a tool that diffs (CRC32's) pages of memory to find static/changing ones. It also searches for known values. I'd like to see someone run with this and flesh it out to simplify finding further offsets.
This is all I can think of right now. I'm sure I left something out. I'm willing to talk to people about helping, and once I've determined that folks can help out, I'll share my code with them only. I don't think I want more than 2-3 other people involved, just so that if we have a leak, we'll know really quickly who to blame.
*whew* Sorry if I come off sounding like a prick, but I don't want to waste a lot of time with people telling me that they know Java or some shit and asking for code. C++/Win32/asm only please! :)
Hmm.
Really? That's wild. I wonder why they did that -- seems like a step backwards, in terms of hackability.cronic wrote:Perhaps it once was that way, but it certainely isn't the case now. When a location update is sent, there aren't any sanity checks related to line of sight. If you notify the server that you're at a particular set of coordinates, it doesn't ask questions.atomx wrote:in EQ1 you could set your location to any zoneloc you wanted, but the server would reject loc changes that were out of your LOS
cronic
I know that I used to be able to set my zoneloc to whatever I wanted, but the server would treat me like I was at the old loc -- the display would draw the new loc, but I'd be getting hit by mobs at the old loc. In other words, unless you used the teleport-anywhere exploit, the "teleport" was cosmetic only.
There are some things that you could do by modifying your local loc this way (exploits that I won't mention here), but real teleporting wasn't one of them...
Hmm.
-
Virtuoso65
- a hill giant
- Posts: 150
- Joined: Wed Oct 15, 2003 2:29 pm
I'm just going out on a limb here, but I might have a reason why there could have been a line of sight check before when there isn't one now. I seem to remember hearing about a switch from some previous system to UDP packets back in May or something, before I was really involved with this project. Since UDP packets can be lost (right?), it would be tough to enforce a line of sight check on all location updates if it can't be guarunteed that every one of them would be accounted for.
Or something.
cronic
Or something.
cronic
Nah, afaik they've always used UDP. I complained about this a while ago (like >1 or 2 years) because my ISP at the time was dropping UDP packets under load (which is fully within their rights in the IP specs) and causing me to go linkdead (usually right at some critical time in a raid or something).
I have no idea on the LOS stuff. I'm thinking that maybe because of the different ways we're doing it (setting the pos fields vs. sending a jooked-up pos packet) maybe my way was running into some checks that your way skipped.
I have no idea on the LOS stuff. I'm thinking that maybe because of the different ways we're doing it (setting the pos fields vs. sending a jooked-up pos packet) maybe my way was running into some checks that your way skipped.
Hmm.