Page 1 of 2 12 LastLast
Results 1 to 15 of 17

Thread: Read this BEFORE using any key sniffers

  1. #1
    Developer Ratt's Avatar
    Join Date
    Dec 2001
    Posts
    533

    Read this BEFORE using any key sniffers

    This post will be modified as time goes on and will eventually evolve into a FAQ.

    The ShowEQ developers do not support or endorse any given key sniffer utility. The sniffer utilities your find here are used at YOUR OWN RISK. Any problems resulting from using these key sniffers found here and not the responsibility of the ShowEQ developers or anyone else. It is YOUR responsibility to review the code or place your trust in someone that is capable of reviewing the code.

    There are several things you MUST be aware of before you use any program found on this forum:

    1. There is NO 100% safe key sniffer. None. Zero. Zilch. Nada. IT DOESN'T and it will NEVER exist. The programmers at Verant/SOE, for all their faults, are not stupid. They are very competent and intelligent programmers. Just as we can "undo" anything they do to find key sniffers, they can "undo" anything we do to try and protect the key sniffer from being detected. There's no telling when code will go into the EQ program to allow detection of new key sniffers, nor is there any way to tell when that code will become active.

    2. Do NOT use pre-compiled binaries that have no source code available for review. In fact, do NOT use pre-compiled binaries at all. Compile them yourself from the source code, AFTER you review it.

    3. Do NOT post a link or an attachment. Post the SOURCE code and let others compile it. Generally speaking, any links to pre-compiled binaries will be deleted and/or edited, depending on the situation. Any links to pre-compiled binaries left by the moderators is NOT an endorsement of any given key sniffer. Especially if it's a newer post, the moderators may not have seen it yet.

    4. Using any key sniffer on this forum will likely get you banned eventually. The "safest" solution is to write your own and not distribute it. However, we realize this is impractical for the vast majority of you. Hence the existance of this forum.

    I will add to this post as time goes on. Please READ everything in this post 3 or 4 times before embarking upon your key sniffing adventures.

  2. #2
    Registered User
    Join Date
    Nov 2002
    Posts
    11

    Suggestions

    I erm...can't find my old username for this forum as it isn't one I use for anything else...Oh well, anyway, to the actual message.

    Not to step on your little webbed feet by posting this here Ratt, but perhaps a suggestions post is in order, and this seemed as good a place as any to actually be USEFUL.

    Having followed ShowEQ for a while, I know that people will learn as little as humanly possible to get these key utilities to compile and then run off away with this utility. In effect, I'm sure every developer on these boards knows that will lead to a culling of the ShowEQ community.

    Maybe it's been done elsewhere, maybe it hasn't, but a little technical information for those who might not have thought of it, or simply don't have the resources to know:

    A) There are basically two EASY ways for EQ to detect you are using third party programs. Compile a list of all the programs you are running on your machine and send them to Sony where they compile a huge list and look for similarities, much as you said Ratt.

    B) It is fairly, and I do stress FAIRLY easy for them to monitor files that change on your machine as the game is running. In their mind, the only files that should really be changing are their files and windows system files. I promise you, if you are making a key file on your machine and the program you're using calls it ShowEQ.key...they're going to figure that out. Even if you don't call it ShowEQ.key and you use a commonly compiled program...they're going to figure that out also.

    Two suggestions from my mind as a windows developer (ok, finish reading this post before you decide to flame me just because I'm a windows programmer...please =).

    First, if you decide to download and compile a popular key sniffer. CHANGE THE OUTPUT and application name of the program. This is INCREDIBLY easy to do, and I'm sure someone will post in the forums about how to do this as soon as it becomes popular practice...

    Secondly, *IF* your program puts an output file on your PC instead of sending it directly to your Linux box...rename that file. Call your app mygooberapp and mygooberfile for all I care, but make them unique.

    Again, what Ratt says is true, and there are other ways to detect these programs. If they truly want to destroy ShowEQ, then they'll have gone to better measures than these to continue to work on doing just that.

    If, as is my opinion, they don't really care about ShowEQ and are only trying to cull the population of users down a bit by intimidation to LOOK like they're punishing the cheaters to those who despise us because they're for whatever reason incapable to doing the same or honestly feel it's wrong...then these measures will be enough. Either way, the above suggestions offer you a LITTLE more protection from a technological standpoint of likely ways they have of determining you're using such a program.

    Other suggestions are welcome in my mind.

    The Duck
    Last edited by The Duck; 11-05-2002 at 12:18 AM.

  3. #3
    Registered User
    Join Date
    Oct 2002
    Posts
    25

    Lightbulb Compiler and Code Suggestions

    Adding some suggestions to Duck's comments.

    FIRST about Compiler Settings
    If you modify any sniffer source code (as you MUST do to be different from the rest). Disable any code optimization (anyway you surely don't mind if this takes more cycles, the code is small).

    If you don't disable code optimizations, the compiler will take out any useless code that you may add, like:

    - useless loops
    - invariant asignations
    - jump to functions which result is never used.

    This code will probably do that your sniffer code be very different that the original, and will take SOE lots more code to identify (and if you don't have fingerprints it will probably be near impossible)

    SECOND about constant values
    No magic numbers (or strings). This could be easily spotted. As an example you should not compare for the string name in a variable (like looking what process id is named "eqgame.exe"). This is very easy to read from memory (even if you create the variable content dinamically). Try better something idiot like looking for the process name letter by letter. Or adding to create the address from where to sniff the key.

    THIRD about memory fingerprints
    Sorry folks, but is not safe to leave the adress to look in memory. SOE could scan it and found all players that have ulong vars with 773b90 inside. I prefer the old method in which you have to enter the hex address each time and no auto lookups.

    I believe that if you add this sugestions you will probably be lots more safe than before.

    Trust no one and excuse my English as is not my native language.

    Edited to clarify a point and to change footprint by fingerprint (not feetprint as I used for a bit ) based on Ratt's definition.
    Last edited by a_necro00; 11-05-2002 at 03:19 PM.
    "solo is the only way to fight"
    a Proud Necro of ...
    :-)

  4. #4
    Registered User
    Join Date
    Nov 2002
    Posts
    1
    A few other suggestions while doing this:

    1) Change your default function calls from the ones displayed in the source. ie: in the keyscan.c example posted change the readkey and scanproclist function names to something else.

    2) Allocate extra memory to change the size of the running exe.

    3) I'm not sure if someone else mentioned this but add some extra code that might do something else so that the compiled size of your exe is different from the ones that would result by just compiling what is posted.

    These steps would help to ensure that everyone's key sniffer looks different in memory.

    Good luck to us all!

  5. #5
    Registered User
    Join Date
    Nov 2002
    Posts
    3

    Re: Suggestions

    While I posted this in another thread, it seems that it applies here as well.

    Originally posted by The Duck
    <cut>
    A) There are basically two EASY ways for EQ to detect you are using third party programs.
    <cut>
    The Duck [/B]
    Allow me to also mention this...I have reviewed some of the sniffer code posted here and have seen the use of the OpenProcess function to read the 'eqgame' PID, such as this line used:

    hProcess = OpenProcess (PROCESS_ALL_ACCESS, FALSE, pe32.th32ProcessID);

    If I remember my windows programming 101, OpenProcess is, in fact, a debug function that will attach the debugger to the process. Now correct me if I'm wrong but the process can not only detect if a debugger has been attached to it, but it can, quite easily with about exactly one line of code, send a message back to SoE that SOMETHING has done a debug read on its PID. It doesn't make ANY difference what you call the program that is sniffing AT ALL. All SoE has to do is determine that some program has done a debug read and then it's all over.

    Simply put, the EQGAME process monitors any debug reads to itself. If one happens, send a violation message to the server. Viola. If you open the process for read every 2.5 minutes or whatever to get the current decrypt key, your process will notify SoE that a suspicious process read is occurring every 2.5 minutes.

    When I get some time today I'll look up the debugger function calls and show the source code that Verant could use to send a warning message back to the server based off of defeating the existing sniffer code I have reviewed.

  6. #6
    Registered User
    Join Date
    Oct 2002
    Posts
    25

    DebugActiveProcess

    Octavius.

    I believe that you need to call DebugActiveProcess to set that flag (that you are being debugged, ouch)

    Please confirm, I am checking the available docs right now. If you are right then we must stop using the sniffers at once.
    "solo is the only way to fight"
    a Proud Necro of ...
    :-)

  7. #7
    Registered User
    Join Date
    Dec 2001
    Posts
    31

  8. #8
    Registered User
    Join Date
    Oct 2002
    Posts
    25

    IsDebuggerPresent() will NOT work for SOE

    I don't think so.

    the DEBUG_EVENT group triggers only if you are debuggin the app with a call to DebugActiveProcess(). At least, that is what is said in the MSDN docs.

    The real thing is to see if OpenProcess() sets the flag that is reported by IsDebuggerPresent() which could be a big problem.

    Edited: as mvern and Mr. Spock confirmed in this thread: http://seq.sourceforge.net/showthrea...&threadid=2253 (end of page 3). SOE could not use the function IsDebuggerPresent() to catch the sniffers that only use OpenProcess() and ReadProcessMemory(), even if they have the access for debugging. At least one point for our side.
    Last edited by a_necro00; 11-08-2002 at 09:11 AM.
    "solo is the only way to fight"
    a Proud Necro of ...
    :-)

  9. #9
    Registered User
    Join Date
    Nov 2002
    Posts
    47
    What is to stop SoE from putting something in the eqgame that reports anytime 773b90 is tickled by your computer. I read the link and while I am not a programmer by any means, it doesn't seem like it would be too difficult to set something (debug or otherwise) to lay in wait then trigger a report anytime a program reads 773b90.

    I can't imagine that it would take much in terms of programming to do such a thing, especially when you know exactly what you are watching for. Thus it wouldn't matter what your sniffer looks like, what code you used, how the code ran, what the file name was, what type of executable it was, etc... Further, why would SoE do anything like scan system processes or file names or "fingerprints" when they can just set up a trigger-trap for any sniff...

    I would love to be told why I am wrong about the above, but it seems pretty simple to me.

  10. #10
    Registered User
    Join Date
    Oct 2002
    Posts
    25
    As far as I know you can not set a trap on memory addresses. You could interfere the ReadProcessMemory() call and do it there, and it's not pretty simple.

    Some people is starting to work in a Kernel-Mode sniffer driver. The holy grail of undetectability where you don't use any API calls to do the job. We don't know at this time if it is possible or doable with our skills.

    This is being discussed at http://seq.sourceforge.net/showthrea...&threadid=2359
    "solo is the only way to fight"
    a Proud Necro of ...
    :-)

  11. #11
    Registered User
    Join Date
    Nov 2002
    Posts
    1
    I don't post here often although I do read a lot. Anyone who is a real programmer knows that what Ratt posts makes a great deal of sense. I've been programming games and stuff for ooooh more than fifteen years. Yes I am old. Yes I am an old school geek of the bedroom programming variety.

    During this long time you pick up certain things about legality around certain issues.

    I only wish I had more time to help with the work on the key sniffing stuff, although it seems to my eyes there is already a wealth of ideas and bodies bent to this task already.

    I read Ratt's post and I feel drawn to answer a few points with insights of my own. I will use the same numbers and Ratt's comments.

    1. I agree there is no way to 100% cloak a key sniffer with Windows. I have thought it over for a considerable amount of time. What ever you do it can be coded around. There is a way, you create your own OS, or alter Linux etc, with memory protection, emulate Windows and therefore Everquest, and use this method. That is a lot of work. (Understatement.) Windows just does not offer the degree of memory and storage protection needed to cloak applications 100%.

    2. Always never trust built EXE's, someone could easily use this to gain control of your EQ account. This is bad for non-programmers however...

    4. Using a key sniffer and admitting it in game could get you banned however I do not believe key sniffing any running application including EQ will get you banned. Why? Well see below.


    Let us assume that Verant can scan your machine for known programs and ban you if they don't like what you are running. We know that it is simple to scan for such programs.

    I think it is safe to say that although it is possible for Verant to scan your machine they do not do it at the moment. Assume they do not do this because it is illegal for them to do so.

    Case in point: There are lots of people using EQWindows. Verant will ban anyone who admits to using this application in game. It is safe to say that if Verant were allowed to scan for EQWindows and ban accounts, they would. I have used a variation of EQWindows for years, I have never had an account banned. I know many friends who also use EQW and they have never been banned. The only people I have seen banned from using EQW are the stupid ones who mention it in chat.

    Counter point: Verant may simply be overlooking users of EQW as people not worth worrying about and only banning the ones who admit it in game.

    The counter point is valid, I must admit that however there is a very important point that I don't see mentioned too often.

    The point is that it is illegal for anyone to scan your machine and to transmit this information back for them to store or take any action on. Anyone who is a professional programmer working for any company knows this.

    The act of reading any part of your machine memory as a user is a legitimate thing to do. The act of attaching a debugger to any process is also a legitimate thing to do, especially for programmers using Microsoft's own development system. A virus scanner could be scanning your application's memory for viruses, for example. You may be a software developer trying to track down a hard to trace memory splat bug for your device driver and you may suspect 3rd party software, such as EQ.

    Verant are quite within their right to detect tampered packets or data and send this information back, after all you are attempting to write to the application. However the key sniffer does not need to do any writes so this point is not important.

    It is true that your EQ account can be banned for no reason, Verant have the right to do that at any time. They have to supply a reason though,when you ask for one, especially with credit card billing because they have to act responsibly for refunds.
    However don't let that stop you from developing a key sniffer or even better SEQ for Windows. What will they do when thousands players of players start using such tools? They cannot start mass bannings as it destroys the customer base. They especially can't start mass bannings if they ever decide to scan machines and ban on this basis. Because it is illegal they will have a hard time justifying bans for a significant percentage of players for no reason. This would lead to the company having to disclose they did in fact break the law and scan your machine which would put them out of business.

    To recap, there is nothing wrong with running software on your machine. As long as you do not admit to using EQW or ShowEQ in game there is nothing Verant can do to scan your machine and ban you. Make it hard for Verant to spot your key sniffer but don't be overly paranoid about hiding it.
    --
    Like I would use my real name here

  12. #12
    Registered User
    Join Date
    Dec 2001
    Posts
    12

    Banned?

    Has anyone actually been banned for using a sniffer? I havent heard of that happening.


    In any case if you are overly Paranoid, why not just add a third box to your network, run EQ on that with a pre-paid card, camp some level 1 chump in Freeport and let that machine do your sniffing.

    If an account is going to be banned at least it wont be that level 65 penis that you cherrish more dearly than life itself!

  13. #13
    Registered User datadog's Avatar
    Join Date
    Mar 2002
    Posts
    152
    The key is generated each time you zone. You would have to drag your level 1 around with your main every where you go.

  14. #14
    Registered User
    Join Date
    Dec 2001
    Posts
    12
    Do'h

  15. #15
    Registered User
    Join Date
    Jan 2003
    Posts
    1

    Using different users Administrator to read key and normal to run game?

    I am not a Windows guru by any means, but what is to stop you from making a user on XP Pro w/ just user privlidges, hide all other user and system processes from this user, and run everquest. Then do any handy work with the application running as an Administrator in another session.

    Maybe someone w/ more Windows insite can comment, thank you.

    Jason

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is Off