No Two Should Be The Same

[Resiliant]

Just an observation and a suggestion.

If you're going to use a key sniffer do NOT, and I emphasize this.. do *NOT* simply copy the code in this thread, compile it and use it. What you need to do is MODIFY it in some way. It doesn't have to be a large change... add some constant data at the beginning, put in a few non-sensical code lines that will not be removed by the optimizer, re-arrange the function definitions, add a function or two of your own just for variety.. etc.

Doing so will make your life a LOT easier, will make it MUCH safer for you, and will make SoE's life a living nightmare.

If there are 20,000 SEQ users out there, our goal sould be to create 20,000 key sniffers... EACH with a substantially different memory footprint. They are relying on us being sheep, and simply following two or three developer-types code, mindlessly copying it, and using the system in our memories. Let's NOT make it easy for them. They are hoping they can write a simple little memory scanner to look for 1,2,5 10 different memory footprints... Lets make it VERY difficult for them to do that by creating 20,000 fundamentally different Sniffers.

:)

[RavenCT]

Let the "Sample" C++ code fly!

"It'll fly Orvil"

:D

[MisterSpock]

And for goodness sake, don't give the program a descriptive name (like eqkeyscanner.exe)!

Also, don't put the program in your EQ directory.

I don't like to even use variables with "key" or "eq" in them. Nor do I define a constant for the address or the process name. I build both from several other constants.

If you produce files, do not give them descriptive names.

Perhaps I'm a little over zealous, but it doesn't take much extra time to be a bit careful.

[millie]

Keep all files related to the scanner on a different machine, e.g. your linux box with a samba server. Although EQ needs administrator priviliges on the windows machine, that doesn't automatically grant it access to network shares.

Run your keyscanner directly via a UNC path, e.g. \\linuxbox\sharename\blooblop.exe and make sure it writes the keyfile (if you're using files for the key) via a UNC path also. This removes the requirement to mount the share as a drive letter, and EQ won't simply be able to walk the entire windows namespace to find it.

Actually, I seriously doubt they'd go combing through every single drive. It would be very obvious (Hmm, why is my disk churning all of a sudden?), very slow and would annoy a LOT of people.

Port it to another language. Make it *really* different from the norm.

Write it in a scriping language of some sort, that way people don't need a compiler to use it. I rewrote it in Perl, and it works fine. Running perl processes just show up as 'perk.exe' in the process list, which is pretty innocuous. VB would be even less suspicious.

[Kermit]

Even with all of these changes, won't SOE still be able to tell that we are scanning the memory that contains the key? Is there a way to make these scans look more like a non-key sniffer? I think I remember someone suggesting making it look like a virus scanner... is that feasible/would it make a difference?