Lolthnemesis
New member
- Joined
- Aug 8, 2006
- RedCents
- 0¢
SoE is probably working on some way to detect if MQ2 is even just simply running (someone here has claimed that they got busted in this way, although they did not specify if they had "Allow Sysinfo Send" on) with no macros or hacks whatsoever, or possibly have some way to detect even using the map which shows you all the players and mobs on it. It is obvious that even if MQ2 was made completely invisible to their servers, that performing actions such as warping, and/or chain zoning, always have a significant potential to get you busted, if for no other reason that a GM Admin could simply be completely invisible to you, and monitor your actions.
That being said, it would be a shame if MQ2 was inherently a risk just to RUN (which is what SoE WANTS PEOPLE TO BELIEVE, they want you to be afraid), even with absolutely no plugins, with just the map features, or /tar. Especially if you've already been caught and suspended, and you are at a sever risk from that point forward, you don't want to risk losing 7 years of work into your account. Many people have Fear Of The Unkown (FOTU). We MUST assume that everything is being done in their power to make what may currently be regarded as "tin foil hat stuff", as future reality. I propose a solution to this, it would involve adopting what is being developed for WoW, namely Antifreeze, a highly advanced rootkit stealth, and memory cloaking technology.
MQ2 utilizes dll injection to modify the client memory of Everquest. Now, IF their is some kind of checksum comparative monitoring toll being developed or implemented, then eventually YOU WILL be caught, as they begin to identify certain "signatures" of memory modification that doesn't match up with what the server is expecting to "see" from the client.
In my own words I will outline what I would like to see someone code for an "Everquest version" of Antifreeze, for use with MQ2 but not being limited to just that.
1) Make the MQ2 (or any) executeable INVISIBLE and NON-EXISTANT in windows task manager, as well as to all other parts of the operating system.
2) HIDE the DLL file that MQ2 injects into Everquest so that only the correct number of DLL files would be shown as running should SoE develop some kind of detection technology that will be able to see the prescence of the MQ2 dll even with no plugins running. Again, in my opinion, we must ASSUME that this is either already a reality, or WILL be a reality in the future. Remember, SoE is never going to tell you exactly what you were doing and when, that resulted you in getting busted, they want everyone to fear the unknown, which is BS.
3) CLOAK the modified memory within Everquest, so that ANY altered memory is NOT visible serverside, the server ONLY sees what it is supposed to see, which is a "legitimate" EQ client running with no 3rd party software. Of course this will NOT work with serverside hacks obviously, I'm not stupid and I'm not advocating that it's possible to make MQ2 safe to use with whatever hack you want, that is obviously impossible, I am only talking about securing and ensuring the safety of its use with very limited, client side only plugins, that do not show obvious characteristics of non-standard play within the game to those who are watching you secretly.
Please see this document or download the one I have attached:
http://www.rootkit.com/redirect.php?http://www.rootkit.com/vault/hoglund/GregSlidesWoWHack.rar
Supervisor.sys rootkit:
No Process
No Injected DLL
No Injection Thread
No Attached Debugger
No Scannable Memory
No Code Patches
Utilizes Shadow Branching:
*Instead of a detour, it uses hardware breakpoints to hijack the main program thread --A hook on any number of points (i.e., PspGetContext) can protect the context from being read from the usermode
*Uses memory cloaking to protect injected code --Page table manipulations and/or timely memory movements.
To validate the points I have made, I include this:
"I just wrote some code to hide a process from the OS. In essence this allows MQ (or any other process for that matter) to run completely undetectable by all Win32 API; e.g. PSApi and the ToolHelp API can't detect the process and even System Internals Process Explorer and the Windows Task Manager can't detect the cloaked process(es).
Since SoE doesn't check client side running processes this isn't a big deal right now. Just so the rest of you know, however, we do have this stealth ability if we ever need it."
--------------------------------------------------------------------------
"Well, before they start checking processes, they are going to check the DLLs loaded into the eq client. Can you cloak that API?"
--------------------------------------------------------------------------
"dont_know_at_all - Yes. I can cloak a DLL from a process that has loaded it - including making calls to open handles to it fail; e.g. GetProcAddress( hDLL, "") - without unloading the DLL. Note, however, that this will cause the DLL to be unloadable until reboot.
We can also do the following:
* Freeze individual threads in a process.
* Completely freeze a process from running (this is done by freezing all its threads which I already made a UI for).
* Make a process forget about which Threads it has running without terminating them.
* Make a process forget about which Handles it has opened without closing them.
Not to toot my own horn.. but... it's pretty major; especially for worm authors and the current flurry of RPC exploits as delivery mechanisms."
--------------------------------------------------------------------------
"I would think you could detour this api, just like any other and prevent it from reporting the names of dll's you dont want known, AMadMonk and I had talked about doing this before but never got around to trying it."
--------------------------------------------------------------------------
"Detour'ing GetProcAddress() is very easy. Unfortunately it's equally easy to tell if you have detoured it.
... but, why stop at GetProcAddress? You're going to have to hook all the API that PSAPI and Tool Help use because they can get module lists and find you that was as well. THEN you're going to have to hook the NtDll.dll calls that provide the same features - but I know that most of you can't write (or figure out) code at this level so you may as well not even try. Oh, did I mention that you may want to check the PEB?
So, it would seem that you're best bet is to forget about detouring GetProcAddress() - that's script kiddie talk. If SoE wanted to find you then they'd start with calling IsDebuggerPresent(). That'll probably weed out half of the attempts right there; or at least those that can't get/use SoftIce, write their own inter-process breakpoint/read/write memory app, kernel mode inspection API, or injection debugger."
http://www.macroquest2.com/phpBB2/v...previous&sid=36da2b6fd6ba3f8213f1bf19169f0afd
That being said, it would be a shame if MQ2 was inherently a risk just to RUN (which is what SoE WANTS PEOPLE TO BELIEVE, they want you to be afraid), even with absolutely no plugins, with just the map features, or /tar. Especially if you've already been caught and suspended, and you are at a sever risk from that point forward, you don't want to risk losing 7 years of work into your account. Many people have Fear Of The Unkown (FOTU). We MUST assume that everything is being done in their power to make what may currently be regarded as "tin foil hat stuff", as future reality. I propose a solution to this, it would involve adopting what is being developed for WoW, namely Antifreeze, a highly advanced rootkit stealth, and memory cloaking technology.
MQ2 utilizes dll injection to modify the client memory of Everquest. Now, IF their is some kind of checksum comparative monitoring toll being developed or implemented, then eventually YOU WILL be caught, as they begin to identify certain "signatures" of memory modification that doesn't match up with what the server is expecting to "see" from the client.
In my own words I will outline what I would like to see someone code for an "Everquest version" of Antifreeze, for use with MQ2 but not being limited to just that.
1) Make the MQ2 (or any) executeable INVISIBLE and NON-EXISTANT in windows task manager, as well as to all other parts of the operating system.
2) HIDE the DLL file that MQ2 injects into Everquest so that only the correct number of DLL files would be shown as running should SoE develop some kind of detection technology that will be able to see the prescence of the MQ2 dll even with no plugins running. Again, in my opinion, we must ASSUME that this is either already a reality, or WILL be a reality in the future. Remember, SoE is never going to tell you exactly what you were doing and when, that resulted you in getting busted, they want everyone to fear the unknown, which is BS.
3) CLOAK the modified memory within Everquest, so that ANY altered memory is NOT visible serverside, the server ONLY sees what it is supposed to see, which is a "legitimate" EQ client running with no 3rd party software. Of course this will NOT work with serverside hacks obviously, I'm not stupid and I'm not advocating that it's possible to make MQ2 safe to use with whatever hack you want, that is obviously impossible, I am only talking about securing and ensuring the safety of its use with very limited, client side only plugins, that do not show obvious characteristics of non-standard play within the game to those who are watching you secretly.
Please see this document or download the one I have attached:
http://www.rootkit.com/redirect.php?http://www.rootkit.com/vault/hoglund/GregSlidesWoWHack.rar
Supervisor.sys rootkit:
No Process
No Injected DLL
No Injection Thread
No Attached Debugger
No Scannable Memory
No Code Patches
Utilizes Shadow Branching:
*Instead of a detour, it uses hardware breakpoints to hijack the main program thread --A hook on any number of points (i.e., PspGetContext) can protect the context from being read from the usermode
*Uses memory cloaking to protect injected code --Page table manipulations and/or timely memory movements.
To validate the points I have made, I include this:
"I just wrote some code to hide a process from the OS. In essence this allows MQ (or any other process for that matter) to run completely undetectable by all Win32 API; e.g. PSApi and the ToolHelp API can't detect the process and even System Internals Process Explorer and the Windows Task Manager can't detect the cloaked process(es).
Since SoE doesn't check client side running processes this isn't a big deal right now. Just so the rest of you know, however, we do have this stealth ability if we ever need it."
--------------------------------------------------------------------------
"Well, before they start checking processes, they are going to check the DLLs loaded into the eq client. Can you cloak that API?"
--------------------------------------------------------------------------
"dont_know_at_all - Yes. I can cloak a DLL from a process that has loaded it - including making calls to open handles to it fail; e.g. GetProcAddress( hDLL, "") - without unloading the DLL. Note, however, that this will cause the DLL to be unloadable until reboot.
We can also do the following:
* Freeze individual threads in a process.
* Completely freeze a process from running (this is done by freezing all its threads which I already made a UI for).
* Make a process forget about which Threads it has running without terminating them.
* Make a process forget about which Handles it has opened without closing them.
Not to toot my own horn.. but... it's pretty major; especially for worm authors and the current flurry of RPC exploits as delivery mechanisms."
--------------------------------------------------------------------------
"I would think you could detour this api, just like any other and prevent it from reporting the names of dll's you dont want known, AMadMonk and I had talked about doing this before but never got around to trying it."
--------------------------------------------------------------------------
"Detour'ing GetProcAddress() is very easy. Unfortunately it's equally easy to tell if you have detoured it.
... but, why stop at GetProcAddress? You're going to have to hook all the API that PSAPI and Tool Help use because they can get module lists and find you that was as well. THEN you're going to have to hook the NtDll.dll calls that provide the same features - but I know that most of you can't write (or figure out) code at this level so you may as well not even try. Oh, did I mention that you may want to check the PEB?
So, it would seem that you're best bet is to forget about detouring GetProcAddress() - that's script kiddie talk. If SoE wanted to find you then they'd start with calling IsDebuggerPresent(). That'll probably weed out half of the attempts right there; or at least those that can't get/use SoftIce, write their own inter-process breakpoint/read/write memory app, kernel mode inspection API, or injection debugger."
http://www.macroquest2.com/phpBB2/v...previous&sid=36da2b6fd6ba3f8213f1bf19169f0afd
