Is it safe to use it now post -POP?
Does verant or GM check even if your not abusing it?
MacroQuest - Is it Safe?
Moderator: MacroQuest Developers
MacroQuest - Is it Safe?
DragonWar
No certain answer on this. The consensus from people I've spoken with that I trust, and from my own thinking about this is:
It's POSSIBLE. There are a few ways that they COULD detect you, even if you aren't blatantly macroing.
However most of these require recoding either the client, the server, or both. It's far more likely that, unless MQ becomes a bigger problem and hence higher on their radar (*cough cough because of a million script kiddiez macroing plat cough cough*), only the BLATANT macroers will get nailed. There's pretty good reason to believe that, right now, EQ doesn't have "anti-macro" detection built in, and that GM's are banning or suspending players due to blatantly obvious macroing.
Caveat emptor: let the buyer beware.
It's POSSIBLE. There are a few ways that they COULD detect you, even if you aren't blatantly macroing.
However most of these require recoding either the client, the server, or both. It's far more likely that, unless MQ becomes a bigger problem and hence higher on their radar (*cough cough because of a million script kiddiez macroing plat cough cough*), only the BLATANT macroers will get nailed. There's pretty good reason to believe that, right now, EQ doesn't have "anti-macro" detection built in, and that GM's are banning or suspending players due to blatantly obvious macroing.
Caveat emptor: let the buyer beware.
-
Reliable Skeleton
- orc pawn
- Posts: 10
- Joined: Sat Aug 10, 2002 4:22 am
Re: MacroQuest - Is it Safe?
No it is not safe. Stop using the program immediatelyDragonWar wrote:Is it safe to use it now post -POP?
Know that using any 3rd party programs to change the way EQ runs on the Client or Server is against the EULA.
The company has a business to run. They have to click "I ACCEPT" each time you log in.
They own the software on the server end. they own the copyright of the server and client end.
So, if you agree to their terms, you click I accept, otherwise don't play the game.
SOE has their base covered. If you get caught using a 3rd party program of any type to change the way EQ functions as SOE intended, your in violation of the agreement.
So get caught, get banned.
Only you decide to Accept the EULA, then disregard that EULA by using MQ.
So if you get caught, you get banned, don't go crying to the people that share your interest in doing the same thing. Frankly, i for one would laugh at you.
VI did at one time awhile back incorporate a process snoop. It was removed after a comotion over Privacy.. But that doesn't mean they can't see your processes if they choose to take a look, there is nothing stopping them.
Here is example that happend to me while in Chat:
Had a character zone into Misty Thicket.
Character got stuck in the zone. EQ crashed. No 3rd party software running. All other choices to fix were exhausted, so i went to chat channel at the login. few GM's and a couple Guides sitting there.
So i tell them the problem. After finally getting an answer, the GM says to me something like "Ok <soandso>, may i look in your EQ directory to check for you?" .. I accepted.
Know that it took that GM just a mere 1 second to take a peek and could have checked ALL files on my drive.. anything at all.
The a few minutes go by.. the GM responds with something like "Hmm. All seems to be ok. Let me check something here"
Few more minutes i wait...
GM comes back and says something like "Ok <soandso. Looks like you'll need to delete EQ and reinstall"
I gave out a heavy sigh. and Did as i was told. Repatched EQ.
10 hours later, i got back onto EQ and the character was STILL stuck.
Gave login and pw to a known friend and had them walk my character out of Misty Thicket. and never had the problem again.
Now. Planes of Power, or not. I'm telling you now! they can check processes any time they choose and it just takes 1 second. You can't even tell they are looking.
So don't get bent on thinking that PoP has some new form of snooping.. it doesn't.. they already have the ability to snoop.. always did.
Only way to catch a GM snooping on the client is to make a program to detect it. Allowing for normal server file checks, and if the snoop is discovered, then to write a log file with the computer address, and any other info necessary to cover your butt in Court.
So suppose i run EQW+MQ with EQ, and that snoop program detects a snooping GM, then i have all rights to take SOE to court for violating my privacy.. EVEN THOUGH i am running 3rd party software. Yes we are both wrong, but i would win.
Peace. My hands hurt now,lol
The company has a business to run. They have to click "I ACCEPT" each time you log in.
They own the software on the server end. they own the copyright of the server and client end.
So, if you agree to their terms, you click I accept, otherwise don't play the game.
SOE has their base covered. If you get caught using a 3rd party program of any type to change the way EQ functions as SOE intended, your in violation of the agreement.
So get caught, get banned.
Only you decide to Accept the EULA, then disregard that EULA by using MQ.
So if you get caught, you get banned, don't go crying to the people that share your interest in doing the same thing. Frankly, i for one would laugh at you.
VI did at one time awhile back incorporate a process snoop. It was removed after a comotion over Privacy.. But that doesn't mean they can't see your processes if they choose to take a look, there is nothing stopping them.
Here is example that happend to me while in Chat:
Had a character zone into Misty Thicket.
Character got stuck in the zone. EQ crashed. No 3rd party software running. All other choices to fix were exhausted, so i went to chat channel at the login. few GM's and a couple Guides sitting there.
So i tell them the problem. After finally getting an answer, the GM says to me something like "Ok <soandso>, may i look in your EQ directory to check for you?" .. I accepted.
Know that it took that GM just a mere 1 second to take a peek and could have checked ALL files on my drive.. anything at all.
The a few minutes go by.. the GM responds with something like "Hmm. All seems to be ok. Let me check something here"
Few more minutes i wait...
GM comes back and says something like "Ok <soandso. Looks like you'll need to delete EQ and reinstall"
I gave out a heavy sigh. and Did as i was told. Repatched EQ.
10 hours later, i got back onto EQ and the character was STILL stuck.
Gave login and pw to a known friend and had them walk my character out of Misty Thicket. and never had the problem again.
Now. Planes of Power, or not. I'm telling you now! they can check processes any time they choose and it just takes 1 second. You can't even tell they are looking.
So don't get bent on thinking that PoP has some new form of snooping.. it doesn't.. they already have the ability to snoop.. always did.
Only way to catch a GM snooping on the client is to make a program to detect it. Allowing for normal server file checks, and if the snoop is discovered, then to write a log file with the computer address, and any other info necessary to cover your butt in Court.
So suppose i run EQW+MQ with EQ, and that snoop program detects a snooping GM, then i have all rights to take SOE to court for violating my privacy.. EVEN THOUGH i am running 3rd party software. Yes we are both wrong, but i would win.
Peace. My hands hurt now,lol
My perception is my reality.
[url=http://www.phpbb.com/][img]http://www.mutedfaith.com/images/illusion.jpg[/img][/url]
[url=http://www.phpbb.com/][img]http://www.mutedfaith.com/images/illusion.jpg[/img][/url]
-
Oldnworeout
- decaying skeleton
- Posts: 6
- Joined: Sat Oct 12, 2002 8:01 pm
fyi, i was reading the entire eula just cause, and according to it the only time they can scan your system processes or anything outside the everquest directory is when you make a request for technical help. Otherwise the agreement says they can only look at your eq directory.
So just keep that in mind 8)
So just keep that in mind 8)
Isn't MacroQuest technicall IN-process with EQ executable?
Ok... So, I'm not the worlds most experienced Windows programmer, but based on my reading of source to MacroQuest, I could make the argument that MacroQuest is at least partly in process with the EQ exectuable (specifically the Detour stuff.)
There are obvious good reasons why this is the case. For example, the chat handler should prevent the MacroQuest slash commands from being transmitted to the server.
Therefore, isn't this detectable within the constraints of the EULA?
The worst case scenario is that this could be detected in a silent way (e.g. not break MQ, but build up a log of people to ban.) Isn't it reasonable to assume that this is possible, especially on NT/XP, but also probably on 9X as well.
Again, I'm not a super-duper Windows coder and I haven't even run MQ on an EQ account so I could be way off the mark. I'm just trying to understand what the real risks are here, because man I'd sure love to have some "help" 2-boxing and this program looks damn cool.
It's just that statements like: "The Detours Library intercepts target functions by re-writing their in-process binary image." (from the Detour's docs) scare the **** out of me.
There are obvious good reasons why this is the case. For example, the chat handler should prevent the MacroQuest slash commands from being transmitted to the server.
Therefore, isn't this detectable within the constraints of the EULA?
The worst case scenario is that this could be detected in a silent way (e.g. not break MQ, but build up a log of people to ban.) Isn't it reasonable to assume that this is possible, especially on NT/XP, but also probably on 9X as well.
Again, I'm not a super-duper Windows coder and I haven't even run MQ on an EQ account so I could be way off the mark. I'm just trying to understand what the real risks are here, because man I'd sure love to have some "help" 2-boxing and this program looks damn cool.
It's just that statements like: "The Detours Library intercepts target functions by re-writing their in-process binary image." (from the Detour's docs) scare the **** out of me.
...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
It's just that statements like: "The Detours Library intercepts target functions by re-writing their in-process binary image." (from the Detour's docs) scare the **** out of me.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Well, think about it this way. A computer program is made up of instructions, yes? These instructions are a series of bytes 'instructing' the processor on how to behave.
So if we have a set of instructions that looks something like this:
0050 mov eax, somevalue
0056 call someaddress
(i don't remmeber how to determine how many bytes that mov instruction would be, so no yelling at me for the wrong value there ;p)
Let's just pretend for a minute that 0050 is the beginning of another function's instructions. Somewhere else, there's a 'call 0050' sitting around, and that is what detours is intercepting.
First, it makes a byte sequence that will jump to your new function you want to be calling instead of this existing function, and determines the length (in bytes) of this new jmp or call ... if the length in bytes of the new instruction is say, 8 bytes, that's going to fill the space of that mov eax, somevalue, and ALSO fill 2 bytes of the call someaddress line ... which will really screw things up someth'n fierce ...
So, to compensate, they copy the mov and call instructions somewhere else, put the new sequence in, then replace the last bytes of the call instruction with nop's (which mean 'do nothing', or 'no operation'). Then, it jumps out to your new function, executes what you wanted it to do, when that is done it executes the mov eax, somevalue, executes the mov operation, and then sets the stack pointer (forgive me if i used the wrong term there, been awhile since i did any asm) up such that when the call someaddress line is executed & return's from someaddress, it returns where it originally would have had detours not interfered.
It may sound complicated and maybe scary, but it's really about as scary as getting your oil changed -- that is to say, as long as the person changing the oil/filter know what they're doing and don't put in the wrong kind of oil, then it's perfectly safe.
-Phantal
It's just that statements like: "The Detours Library intercepts target functions by re-writing their in-process binary image." (from the Detour's docs) scare the **** out of me.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Well, think about it this way. A computer program is made up of instructions, yes? These instructions are a series of bytes 'instructing' the processor on how to behave.
So if we have a set of instructions that looks something like this:
0050 mov eax, somevalue
0056 call someaddress
(i don't remmeber how to determine how many bytes that mov instruction would be, so no yelling at me for the wrong value there ;p)
Let's just pretend for a minute that 0050 is the beginning of another function's instructions. Somewhere else, there's a 'call 0050' sitting around, and that is what detours is intercepting.
First, it makes a byte sequence that will jump to your new function you want to be calling instead of this existing function, and determines the length (in bytes) of this new jmp or call ... if the length in bytes of the new instruction is say, 8 bytes, that's going to fill the space of that mov eax, somevalue, and ALSO fill 2 bytes of the call someaddress line ... which will really screw things up someth'n fierce ...
So, to compensate, they copy the mov and call instructions somewhere else, put the new sequence in, then replace the last bytes of the call instruction with nop's (which mean 'do nothing', or 'no operation'). Then, it jumps out to your new function, executes what you wanted it to do, when that is done it executes the mov eax, somevalue, executes the mov operation, and then sets the stack pointer (forgive me if i used the wrong term there, been awhile since i did any asm) up such that when the call someaddress line is executed & return's from someaddress, it returns where it originally would have had detours not interfered.
It may sound complicated and maybe scary, but it's really about as scary as getting your oil changed -- that is to say, as long as the person changing the oil/filter know what they're doing and don't put in the wrong kind of oil, then it's perfectly safe.
-Phantal