MacroQuest64

I am in the process of writing some very intriguing routines for MQ that will allow for ShowEQ to work even when it's broken as-is (ie, MQ sends data directly to SEQ).

However, before I work more I'd enjoy a few educated opinions from devs that have experienced the problems on test with anti-MQ code. Feel free to send private message if you don't wish to post publically.

Please...no guesses in this thread unless you've experienced the anti-MQ code, reviewed OUR code, and have experience coding for MQ. There is a thread on the general board for blind guessing.

Thanks!

I was hoping someone might do this. If you could make a broadcasting MQ version that only sniffed memory without altering routines that'd probably make a lot more people comfortable with it given the new things Sony is looking for in their own memory space.

As much as I would love to offer help, Amadeus, specifically for the convience of having both, compiling one project to assist in the ease of use in another is a bad idea. We respect ShowEQ, and they respect us, but if MQ, in any way, publically assists ShowEQ's ease of use, the attention that SEQ has gotten will turn towards us.

Good idea though.

hehe .... I hate to tell you, but MQ has much worse press than SEQ :) ...especially with Sony

First problem is that the data between server and client is encrypted. However, with a debugger installed I can see that client memory is being checked and compared to something remote and a disconnect command is being sent from the server. This check seems to be some kind of checksum or value validation.

The client side hacking is what SoE wants to stop. The client modifications made by MQ are low hanging fruit so SoE started checking that as well. So, if I had to guess, if we recode MQ eliminating the detours (and eliminating modified response) from the client it would take another modification on the part of SoE to detect MQ, or any memory reading client modification that we make. (encryption key reader for example). Simply reading memory values from the client and sending that to another system via UDP should be doable if we are changing nothing in the EQ client memory space.

I am tring to figure out the nature of the memory checking. For example, if a local checksum is being generated and sent to the server for comparison, or if the values of certain memory offsets are simply being sent and compared for range or bounds limitations. Normaly I would try to sniff the data stream to figure this out. But with that being encrypted, this is not easy.

I think that I can come up with a quick tool that could keep the client from disconecting. However, that seems like a bad idea ......

True. MQ is much worse. But only because they've already put a thorn in SEQ's side.

Dont get me wrong, you have a great idea there. As a matter of fact, I already have a script that pull the key and echos it for me. But I keep it private. I'd be willing to work on it with you, maybe closed source.

With a little determination you can find your way around the encryption and decompression and have MQ or similar tool log decompressed/unencrypted data... The main problem probably has more to do with the compression, so in reality if you detour the zlib calls you can log decompressed data, and since you'd have the key in memory and the decryption algorithm handy it should be fairly simple :)

Sprite over at FH has managed to offset to prevent the client from telling the server that the offsets are different. My assumption is that it's having the client send the same info as in the client side *expected* mirror regardless of whether or not the data is what is actually present. With that said, I'm wondering if this will prevent EQ from detecting the resident memory leeches, since I believe that his hexxing basically controls the entirety of the server/client memory routine.

Sorry if that sounds really weird. I make homebrew, and I made up an especially ferocious batch of Irish Red, and I'm drinking the first of it tonight. Alcohol's up around 10% or so I'd say, although I don't have a potentiometer or refractometer anymore so I can't tell. What I'm saying is that 1 beer has done me in, I think.

~malachi

Malachi wrote:I made up an especially ferocious batch of Irish Red, and I'm drinking the first of it tonight.

*drool* ship me some of that...

sorry for the off-topic post!

SEQ is back up now... works like a charm...

Yes...mvern is god. It's nice having so many coding gods around :)

Just figure out how to make EQ not get the 'send me your offsets' packet. EQ server will most likely send it over and over and over and over, assuming its getting dropped.

Best fix untill you can emulate a non hacked client, because we know that no VI person is smart enough to expect us to junk to packet filtering and actually be looking for anything similar to that.

Has anyone verified that it's just the offset detection code that is trapping it?

I thought they implemented the offset detection code on production already, with this extra anti-MQ code only on test. Is that not the case?

Seems like it might be something slightly different in our case than detecting changes in offsets. Like maybe thread checking or something?

thread checking is a felony.

Hmm...i do not believe checking your OWN threads is a felony....

Note that i did not say process checking(ie, other processes).