The State of MacroQuest - 2/24/03

OldNecro · Post by **OldNecro** » Mon Feb 24, 2003 1:31 pm

I set my alarm clock for patch time today just so I could attack this thing as soon as it happened... What has happened is not good.

Firstly, it appears the OldUI has been removed *completely*. The new EQGame.exe is over 2000 pages shorter than the old one, and the left/right click offsets are nowhere to be found. We're just going to have to find the NewUI ones.

The click offsets aren't the only ones I can't find, and this is why I believe many of the structs may have changed again. Not all of them, because I was able to find many of the offsets. I would post them, but it won't do any good considering they are mostly the ones that are trivial to MQ's most important functions.

Furthermore, additional checking has been implemented for offset hacks, as well as other 3rd party applications like MQ that use "detours". (Not actually 'checking' in some cases per se, more like roadblocks...) Also, we don't know if this checking is setting off any alarms at Sony when it is tripped. I would suggest, as others have, to discontinue use of any memory-intrusive 3rd party applications until we get this sorted out.

With Plaz being MIA and those of us actually looking at the code dwindling in numbers, this is gonna take a while to fix. It would be nice if we could all get together and assign projects or something so we don't dupe work, btw. Maybe someone can start a thread in the dev form on that topic.

I've got over 300 pages of source code printed out that I spread all over my table at SubWay at lunchtime, all over my desk while I'm at work, and all over my kitchen table when I'm at home and I have only reached one conclusion thus far...

I can't do it alone, that's for sure...

-OldNecro

Tanarin · Post by **Tanarin** » Mon Feb 24, 2003 1:49 pm

I just would like to say I appreciate this service very much. After years of EQing, I have developed CTS and as a bard, that makes me very ineffective. MacroQuest makes me a viable gamer again and I highly appreciate this. Good luck with your endevours, and if I find a way to help, believe me I will.

insanitywiz · Post by **insanitywiz** » Mon Feb 24, 2003 4:28 pm

I'm just a hardware junky, and can barely code my way through a mac, but I'm willing to dedicate some time to learning new things, what would I need to get ahold of (love work software contracts) to start learning my way around this thing?

fwiggles · Post by **fwiggles** » Mon Feb 24, 2003 5:22 pm

i have looked at the code and i'm like WTF this makes no sense lol, i'll keep working and if i knew more about it I would have already contributed. I'm more of a PHP/mysql person though and it is similar in some ways. But if there is anything i can contribute i definately would

Amadeus · Post by **Amadeus** » Mon Feb 24, 2003 7:58 pm

The code I can understand ....the offset hacking bit ..(ie,anything that is NOT C++) I do not.

So, someone fix it, then I'll be glad to add some new features :)

eqjoe · Post by **eqjoe** » Tue Feb 25, 2003 4:08 am

I believe we need to make some radical changes... maybe rather than injecting the dll into EQgame.exe, we should move some of the funtions to DX8 simular to what Xylobot does. For example, if we can grab target location from memory and face that target without the injected /face command and use an DX8 API instead, EQgame memory space is unchanged. From memory we can get our character location and the target location. We use DX8 to turn our character the desired direction.

I am looking for DirectX and DirectInput SDKs now.

Zaviar · Post by **Zaviar** » Tue Feb 25, 2003 10:07 am

Sounds very interesting joe.

Zav

insanitywiz · Post by **insanitywiz** » Tue Feb 25, 2003 12:33 pm

Sounds a lot like what some people were talking about in the dev forum awhile ago. Hell, all I want out of whichever program ends up being alive after these changes is the ablity to control my extra characters/accounts in background windows.

gnome001 · Post by **gnome001** » Tue Feb 25, 2003 1:03 pm

the main thing i used it for was /target... being a mage this was very helpful for coh.. rather than having to get a wizzy, necro, druid to go to zone in and invite. kinda like the old /pet attack pcname trick on pvp servers... where the pet could target anyone in the zone so long as they were in pvp range, and then you could just assist the pet for target.

eqjoe · Post by **eqjoe** » Tue Feb 25, 2003 3:02 pm

The /target used with MQ is not the same /target used by the unmodified client. That ability would not work without replacing the standard EQ client /target command. That would require a change in EQ memory space. The idea is to get from memory what we need without changing it.. read only. Then control the character going through Windows APIs (DirectX or DirectInput) leaving EQ memory untouched. What we are doing would then be undetectable without some other method like process scaning.

fwiggles · Post by **fwiggles** » Tue Feb 25, 2003 4:04 pm

even though i hardly understand at all what that means...i say go for it lol i'm sure we have enough coding/offset people around here that can figure it out.

wilso132 · Post by **wilso132** » Tue Feb 25, 2003 4:17 pm

First time poster, but long time user and lurker. I can do a good bit of coding for my age, but I'm afraid I won't be able to help much other than helping for some new ideas/fixes. If some of you who understand the code better could answer a few questions for me, maybe I can help come up with some ideas:

#1- Does the new client actually check for memory tampering (in the basic functions that macroquest uses, I understand it checking for speed hacks)?

#2- Would it be possible to create a real-time packet sniffer/injector? That might be a possible work around for some of the functions that are flagged in the memory checking (if it actually checks for tampering).

Joe's idea sounds like a good one, but I'd have no clue how to go about it.
I've been looking at this code trying to figure as much of it out as I can, but I'm running into a few problems. If someone could help me understand how to get an actual memory address on each variable it would help me out a LOT.

-"My style is impetuous, my defense is impregnable, and I'm just ferocious. I want your heart! I want to eat his children! Praise to Allah." -Mike Tyson

insanitywiz · Post by **insanitywiz** » Tue Feb 25, 2003 4:33 pm

wilso132 wrote:#1- Does the new client actually check for memory tampering (in the basic functions that macroquest uses, I understand it checking for speed hacks)?

Thats pretty much what it does, yes. It was implemented to deal with offset hackers, and hit MQ along the way.

wilso132 wrote:#2- Would it be possible to create a real-time packet sniffer/injector? That might be a possible work around for some of the functions that are flagged in the memory checking (if it actually checks for tampering).

Something along these lines has been done once, though with a far more malicious tool. I don't really know the end result of it, which may be a good thing.

wilso132 · Post by **wilso132** » Tue Feb 25, 2003 4:42 pm

I was only curious about the packet sniffing because, to my understanding, EQ now has a client to server check stating that memory hasn't been tampered with. Could it be possible to edit out this call in the client, but then create a packet to say "everything is fine, no memory tampering here." It seems to me that with enough recording of info on the packets, you could create one with the same information and just call a routine to send it???

kaz · Post by **kaz** » Tue Feb 25, 2003 5:17 pm