Maggotboy's Super Stealth Sniffer V2 (code)

[maggotboy]

WARNING This code is experimental and currently seems to be crashing the game to the desktop. It's currently being discussed and debugged in this thread. If you're interested in the hard-core internals and want to experiment, then please read the entire thread before downloading and attempting to compile this code! This code was based on the 1.x code I posted at this thread: http://seq.sourceforge.net/showthread.php?s=&threadid=2453

This is version 2.0 of my super-stealth key sniffer.

** Code update to 2.05 **
Please see eqsniffer.cpp for specific instructions on how to create a project file for the various compilers. Follow it to the letter!

Revision 2.05
- Fixed my call to GetTempFileName() to pass CORRECT parameters to the call. This should fix the RUNDLL32 not unloading bug.

Revision 2.04
- Changed the InjectCode() routine to inject the entire code section of the DLL rather
than just the code for the InternalHookProc. This was done because many compilers use
jump tables at the beginning of the code section, and the pointer to the InternalHookProc
was actually at the beginning of the code section rather than at the end. Also, there
were some cases where references were being made to code further up in memory, which did
not exist when the code was injected.
- Added the _SNIFFDEBUG #define to allow debug output to appear even in release builds.
Commment the line out when you're done testing the sniffer and ready to use it for real.

Revision 2.03
- Added more debugging code to try and isolate why the DLL isn't being released properly
- Added a safety variable gsh_bInjected to prevent multiple injections of the code into the game

What's it do?
This sniffer does what most sniffers do -- it retrieves the encryption key from the running EQGAME and sends it via UDP protocol to your SEQ box. Keep reading for the juicy bits.

How's it different?
This sniffer, unlike all others, lives inside the running EQGAME. It is injected into the game's address space by a DLL (dynamic link library), and all evidence of the DLL is removed immediately after the injection occurs.

Is it a hack?
No! It is completely benign and completely legal (meaning it uses normal Windows API functions and doesn't hack anything). When the game launches, the sniffer DLL is automatically loaded along with it, courtesy of the Windows OS. It's there legitimately! Not only that, but as part of the startup procedure for all DLL's, the DLL must tell the OS whether or not to load for any given program. The sniffer DLL detects when it is being loaded into the EQ game, injects its payload, and then tells the OS NOT TO LOAD IT! Before EQ even knows what hit it, Windows loaded the sniffer and the sniffer rejected the load request -- but in between being loaded and rejecting the load request, the sniffer injects its sniffing code into EQ's memory address space (see below for more details on this) and sets the sniffer to running.

Whats this about injecting code? Do you alter EQ?
Hell no! All processes take up a certain amount of room in memory when they're running. They're certainly allowed to allocate more memory if they need it, and indeed all programs allocate more memory for their variables, their windows, etc. The sniffer DLL merely allocates more memory when it loads, and drops the sniffer code into that new memory block!

How does it work?
Windows supports something called Hooking. The exact API call (if you want to look it up for yourself) is called SetWindowsHookEx(). This built-in mechanism is used by applications far and wide to tap into mouse messages, keyboard messages, etc. If you have a Logitech mouse for example, your mouse driver uses this API to intercept a middle mouse button click and turn it into something else, like a double-click or whatnot. Windows allows this, it is perfectly legal, and much to our benefit, is completely undetectable by a running program! That's the kicker of the hooking mechanism ... none of the applications are aware of it, and there's no way to detect if a hook has been installed!
This sniffer utilizes the built-in Windows hooking mechanism to make the Windows OS automatically load the DLL into every process in the system.
When the sniffer attaches to EQ, it allocates some memory, places some more hooking code into that memory, then creates a new hook JUST FOR EQ. Once finished, it then calls the UnhookWindowsHookEx() method to unhook the original system-wide hook from all the rest of the processes in the system.

The end result is that the sniffer drops out of existance, leaving only a single hook in the EQ process, and that hook points to the sniffer procedure that was injected into legally-allocated memory in EQ's address space. It can then freely sniff the encryption key and send it to the SEQ box. EQ is unware of the hook, and no residual DLL's exist in memory.

How sneaky is it?
1. The sniffer allocates memory via VirtualAlloc(). Windows returns back with a pointer to that memory. It is entirely up to Windows to decide where to allocate the block, so it is never in the same place on any given computer or on any given run of the program.
2. The sniffer DLL dislodges itself from the EQ game before the OS even finishes loading the DLL, so the EQ game never even knows there was a load attempt on the DLL. The DLL never lasts long enough for EQ to enumerate it and detect it.
3. There's no published API calls to detect Windows hooks, disable them, or get information on them. They're ghosts in the machine, so to speak. The sniffer's hook on EQ exists only in the EQ process, and even then in a random location in memory assigned by Windows.
4. The hook mechanism means that no additional threads are created (a process may have multiple threads of execution at any given time). Since no extra threads are created and the hook executes in the main program's thread, EQ can't do a thread count or examine the threadproc's to determine if any unknown threads are running in its address space.
5. The sniffer generates no additional messages in EQ's
message loop. No timer messages, not even a peep.
6. No extra processes are running while EQ is running. The RUNDLL32 program only runs up until EQ gets loaded. When EQ loads, the RUNDLL32 program exits ... so EQ can't enumerate running programs and detect RUNDLL32. Even if they did, RUNDLL32 is a legitimate Windows program and has a right to be in the task list (and quite often IS!)

What do I need to compile this?
This is the tricky part. Due to the complexity of the injection code, I was forced to use about 3 lines of inline assembly. The Microsoft compilers can compile the inline assembly, but I have no idea if any other compilers are capable of it. I developed it using MS Visual C++ 6.0 and the latest platform SDK. It should compile on Visual C++ 6.0 and .NET with or without the platform SDK.

If your compiler doesn't support inline assembly, I recommend using the code from V1 which can be found here:

http://seq.sourceforge.net/showthread.php?s=&threadid=2453

Instructions for running the program are contained in the eqsniffer2.cpp file, along with revision information and other more detailed information.

As always, use at your own risk!

Maggotboy

[jeffo]

wow great util, and informitive post, thanks!

[guice]

Admit it, Maggotboy! You had fun writing this; didn't you?! :D

[maggotboy]

Originally posted by guice
Admit it, Maggotboy! You had fun writing this; didn't you?! :D

Darn tootin! It's one of those "can I do it" projects that keep you up until 3am and occasionally give your computer a blue-screen :)

Maggotboy

[fgay trader]

You also like to use the word "legal" alot :p

[Hannibal]

Off topic -

Can anyone tell me how in the world to do this:

#pragma comment(linker, "/section:.shared,rws")

in Borland C++ Compiler?

It doesn't like that, or:

SECTIONS
.shared READ WRITE SHARED

[DanoStu]

I usually don't post on these boards much, except to help here and there when I can.

I'm able to take what's on these boards, get it working, and am mostly the quiet guy around here.

But a program like this deserves a "Well Done," from even the lurkers :). This is nothing short of amazing.

Props to you, maggotboy.

[zeroman]

refuses to run when compiled via .NET

tried statically linking the MFC and it wont even compile.

[Talon]

OK, after i compile with Microsoft Visual C6,0++ my "keyniffer" i get a directory with several files and folders in (Debug, Release).

What do i have to start now ? There is no .exe file in this directory ?

What is this "template command file " ? A Dos line ? From which directory do i have to run

"RUNDLL32.EXE keysniffer.dll, InstallHook IP-Adress EQgame.exe Offset ??????

---> Is this a Dos command ?
or a special command in the compiler ?

Help a small noob please =)

[maggotboy]

Originally posted by Hannibal
Can anyone tell me how in the world to do this:
#pragma comment(linker, "/section:.shared,rws")
in Borland C++ Compiler?

Requires a few tweaks ... I found this article on borland's website:

http://community.borland.com/article/0,1410,20132,00.html

In addition to marking the section shared as in their example at the site, you also have to make sure its marked READ WRITE.

Maggotboy

[Digi]

Compiled without errors on MSVS++ 6 but when I call the rundll32 thing, I get an error message (trying to translate from german):
Error loading snif.dll
A DLL initializing routine failed
Any idea what could cause this?

[Hannibal]

Originally posted by Talon
There is no .exe file in this directory ?


Talon - your are compiling a DLL file. There will be no exe.

[maggotboy]

It's probably got to do with the DllMain routine. It returns FALSE when it should return TRUE at the end.

It should return FALSE inside the if(dwReason == DLL_PROCESS_ATTACH) rather than outside as well.

I'll have to test it some more.

Maggotboy

[Hannibal]

Maggotboy -

Thanks. Sorta got that working, switched over to your new source - I don't believe Borland supports inline assembly. I could be wrong, I got frusterated - uninstalled Borland CBuilder 6, and will be installing Visual Studio .NET when I get home.

[goldmund]

Thanks again for your hard work Maggotboy, it's very much appreciated! Now to my problem =)

First off, I'm running MS VC++ 6.0 standard (no service packs)
Versions 1, 1.2 and 1.3 of your code compile and run without problem on my machine.

Version 2.0 compiles fine, but when I go to run it I get the following error: "RUNDLL Error loading tcpcnt.dll A dynamic link library (dll) initialization routine failed"

The syntax I use to run is: "rundll32.exe tcpcnt.dll,tcpcntstrt 192.168.1.101 12000 eqgame.exe 0x0078AAD"

I've double checked the spelling in the .def and .cpp files to make sure there was no typo, but it all looks fine. Any suggestions?

[curio]

I wasnt getting decodes the first few times I tried this using the 2.01 release. I didnt make alot of changes on my first compile, but the one thing I did change was the INJECT_OFFSET.

here's the default:



// V2
// This offset determines where the new code is injected in the allocated
// memory block. This number will be bit-shifted to get a good
// aligned offset for the code. You may make the number anything from
// 0x00 - 0xFF (0 - 255 in decimal notation)
#define INJECT_OFFSET 0x04


I had changed mine to



#define INJECT_OFFSET 0x63


Changing it to an EVEN offset seems to have gotten my decode back. Maybe this is just anidotal evidence. Are there values we shouldn't use? Bitshifting seems like odd/even offsets might make a difference, but I havent recompiled (yet) to convince myself that odd-aligned offsets throw off the decode.

ymmv

[OrangePeelBeef]

Working on getting this wonderful piece of work to compile in either lcc or dev-cpp.

I found that #1 they do both support inline assembly

in lcc

_asm(" ");

in dev-cpp

__asm(" ");

I found this for lcc
http://www.q-software-solutions.com/lccwin32/manual/Pragma.htm

I also found *this* from the dev-cpp faq


16. How to use assembly with Dev-C++ ?

The assembler uses AT&T (not Intel). Here's an example of such a syntax :

// 2 global variables

int AdrIO ;
static char ValIO ;

void MyFunction(..........)
{
__asm("mov %dx,_AdrIO") ; // loading 16 bits register
__asm("mov %al,_ValIO") ; // loading 8 bits register

/*
Don't forget the underscore _ before each global variable names !
*/
__asm("mov %dx,%ax") ; // AX --> DX
}




To me that's just a bunch of gibberish... i know jack about ASM.

I attempted in Lcc

_asm("call $ + 5");
_asm("pop pvmem");
_asm("add pvmem 7");

and during compile i received

Internal Error 1028 on line 556
and there are only 515 lines of code.

On Dev-cpp
i attempted
__asm("call $ + 5");
__asm("pop pvmem");
__asm("add pvmem, 7");

but i got

Assembler messages::
error: suffix or operands invalid for 'call'
error: too many memory references for 'add'


I am doing some more checking... just thought I'd post what I'd found so far

edit: added link for lcc

[maggotboy]

I updated the code to 2.01 ... fixed the bug in DllMain that prevented it from loading. OOPS!

Maggotboy

[LordCrush]

/cheer Maggotboy

Ty for your great work - i have not running it now, but will start as soon as i can!

Hmm using Borland ... seems to be some obstacles to overcome :D

/cheer

/bow

[maggotboy]

I'm still researching AT&T inline assembly ...

I found this site:

http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html

I'm not really sure how to convert them ... what about:

__asm("pop pvmem");
__asm("add $7, pvmem");

...not sure how to convert the first line. Still researching.

Maggotboy

[OrangePeelBeef]

Using
__asm("call ($ + 5)");
__asm("pop pvmem");
__asm("add $7, pvmem");

Its getting past the initial asm errors in Dev-CPP
I will try in lcc also

Dev-cpp is tossing out some different ones now
C:\Dev-Cpp\eqsniffer2.o
[Warning] In function `InstallHook(HWND__ *, HINSTANCE__ *, char *, int)':

[Linker error] undefined reference to `inet_addr@4'
[Linker error] undefined reference to `htons@4'

C:\Dev-Cpp\eqsniffer2.o
[Warning] In function `InternalHookProc(int, unsigned int, long)':

[Linker error] undefined reference to `$'
[Linker error] undefined reference to `pvmem'
[Linker error] undefined reference to `pvmem'

[goldmund]

Deleted my previous project, redownloaded the code, and recompiled a new dll without problems. However I'm still getting the "error loading tcpcnt.dll a dll initialization routine failed"

I noticed in the .cpp file it still said Revision 2.0. Do I still have the older version of the zip file cached maybe?

[Alwayslost]

Ok, I'll admit it, I was absolutely chicken-shit to try any of the sniffers before now. SEQ had become nothing more than a glorified GPS device for me.

But damn.

You put together a tool that has gotten nothing but praise from those that seem to know whats what. THEN you make it accessable to those of us that don't know a compiler from a compressor AND build into it the ability to customize it to make it even better.

This is so good that others were even pointing people from their code to yours. That was the deciding factor for me.

I can't wait to get home to try it!

THANK YOU!

[wizard]

in mingw obviously i renamed the eqsniffer2.cpp to snif2.c just causei hate dealing with long filenames at a dos prompt.. line 483 is the { before the inline asm.

I tried some of the examples for lcc and the other compiler given but that just produced more errors.. gcc gives no help on command line arguments near as i can find and the "documentation" in the doc directory is weak at best..

C:\MinGW\bin>gcc -c snif2.c
snif2.c: In function `InternalHookProc':
snif2.c:483: parse error before '{' token

[maggotboy]

goldmund -- aye, the .cpp file should say "Revision 2.01"

wizard -- this inline assembly is gonna kick everyone's ass, unfortunately. I'm a complete n00b when it comes to assembly, and only got this code from USENET.

Near as I can tell ... if you're using a non-MS compiler the inline assembly has to be converted to "AT&T syntax" ... that is, if the compiler even supports assembly ...

So ... guess some research is in order.


OrangePeel -- the unresolved references to htons and inet_addr are easy to fix -- make sure wsock32.lib is included when the linker runs. The other errors are probably related to the differences between the AT&T syntax and the Intel syntax. Wish I had more info on this, but I don't.

Maggotboy

[cheeze69]

maggotboy, you are SO the man! :D

I'll try to slam your new code through VS.net tonight when I get home.

[The Mad Poet]

Borland supports inline assembly - just preface it with [asm] I believe...

[wizard]

yea i am at the same point Orange is.. i did the same changes as he did and i am getting the same three pvmem errors he is getting.. not the others though. does the AT&T syntax use something different from a $ as thats what it appears to be barfing on..

[wizard]

google search AT&T inline intel got me this link..

its all greek to me though..



http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html

[OrangePeelBeef]

w00ps my brain must be mush to not have noticed i forgot the wsock32.lib :)

as for lcc i am getting nowhere as to the cryptic 1028 internal error, and can't get that bastard to compile.

wizard: that link is the same one maggot posted about 4 posts up ;)

here are a couple of things from the link that may be useful.. ?


Addressing a particular C variable:

AT&T: _booga
Intel: [_booga]

Note: the underscore ("_") is how you get at static (global) C variables from assembler. This only works with global variables. Otherwise, you can use extended asm to have variables preloaded into registers for you. I address that farther down.


and this one



: "c" (count), "a" (fill_value), "D" (dest)


that second one is interesting.. moving c variables into registers.. may be what we need to do to get past the undefined pvmem?

something like
__asm(: "c" (pvmem) );

i have no idea if that even works :) just tossing out ideas here again i know jack about ASM

[maggotboy]

Borland supports inline assembly ...

http://community.borland.com/article/0,1410,16118,00.html

According to the article, you need to change my code from this:

__asm
{
call $ + 5
pop pvmem
add pvmem, 7
}

to this:

asm {
call $ + 5
pop pvmem
add pvmem, 7
}

I'll post 2.02 in a few hours with a couple changes to at least make this thing workable with Borland compilers ...

Maggotboy

[wizard]

lol i posted my link not long after he did.. i was trying different things while typing mine up must have overlapped somewhere.

[SurfAngel]

I think this OS-dependent-pseudo-trojan deserves a new term. Anyone?

[wizard]

eqtickler

[maggotboy]

I'll tell ya what ... you could write one hell of a virus with this technique.

Maggotboy

[MisterSpock]

I can get everything except the

call $ + 5

line to compile in lcc.

Can you explain a little more on what this line does, exactly. (well, other than the obvious "it's a call to a procedure at a memory location." )

I should be able to make lcc happy eventually :)

edit: I've tried several replacements for the $ (which lcc just doesn't like). I've gotten compiles to fly, but no go yet. Actually, one time it completely closed all my open browsers, though! lol

[cllnsj]

MisterSpock: Thank you for your assistance on the prior lcc instructions for the original version of this. It worked perfectly :D. Please (if you don't mind & have time) post another step-by-step guide regarding this version if you ever get it to work. Much appreciated to everybody's effort on this, great job ;).

[OrangePeelBeef]

Misterspock: how did you get past the undefined pvmem in lcc?

Commenting out the call line results in

Error eqsniffer2.obj: Undefined (*UND*). Symbol pvmem

[MisterSpock]

asm code stub looks like this:

_asm
{
call $ + 5
pop pvmem
add pvmem, 7
}


The _asm function is *terribly* documented. I did some hunting online and found several source files using _asm. Some used this technique, others used:

_asm("pop pvmem");

The docs are so bad that I haven't yet discovered the differences in the two variants.

I've also not had any luck doing my normal debugging routine (ie - attach to iexplore.exe) using even the one compiled with M$VC.

[OrangePeelBeef]

That code snippet produces only

Error illegal character '$'

So we just need to figure out what the hell call $ + 5 does... and find out what the equivalent for $ is.. which is probably harder than it sounds :)

[MisterSpock]

Yeah, I know you get the error. If you comment out the call line, the rest compiles okay.

My M$ compiled version of this causes eq to crash right after the SOE screen... Time to fire up the debugger :)

"God help me, I do love it so!"
(George C. Scott as Patton)

[OrangePeelBeef]

I found this it says that call entry point 5 does this

http://www.powernet.co.za/info/DOS/Int/31.htm

could be completely useless :) but what i think its saying is it dumps the program into real mode.

and i found this

http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&as_qdr=all&q=%22call+%24+%2B+5%22+_asm

but of course the top link is invalid so only get whats in the display window which isn't much

edit: dammit its [ url ] not [ html ]

[nino2469]

ok this is weird. I compiled the dll and then ran the command line. When I start EQ as soon as I hit a key on the keyboard it dumps me back to desktop. Anyone know why this is happening?

[foo]

is call $ + 5 to mean the instruction is 5 bytes long?

also, should all the instructions be 'long'? (i.e., call-> calll, add-> addl, etc)

foo

p.s., I was using this inline asm reference

http://www-106.ibm.com/developerworks/linux/library/l-ia.html

[maggotboy]

call $+5 means: Call code 5 bytes from the current position (relative address)

It essentially is a "trick" to get the EIP register which isn't directly accessible from assembly. EIP is the execution instruction pointer, which tells us where in memory the function being executed is located.

The call itself is 5 bytes long, so its essentially saying in ASM terms "jump to the instruction following this one".

Here's exactly what the assembly does ...

the first line executes a "call" 5 bytes further down, which is in fact the next instruction, "pop pvmem". The "call" function pushes the current position onto the stack. The "pop pvmem" pops the execution location off the stack. These first 2 instructions are the important ones. The 3rd instruction, add, can (and WILL) go away in the 2.02 release because it isn't really necessary.

Maggotboy

[rencro]

same prob as nino, run from command line, start eq, hit any key, dumped to desktop

[maggotboy]

Originally posted by rencro
same prob as nino, run from command line, start eq, hit any key, dumped to desktop

What compiler and what OS?

[nino2469]

MSVS.net and WinXP

[OrangePeelBeef]

Changed code to:

_asm
{
call eip + 5
pop pvmem
add pvmem, 7

}

and it compiled... i'm at work tho so i don't know if it works :)

kinda feel like i'm trying to bait a fish hook with my eyes closed... :)

[tldtms]

I'm having the same problems. Compiles great, but EQ crashes after SOE screen.

OS: Windows XP SP1

MSVS 6.0

[MisterSpock]

MS Version crashing to desktop with VC++6 and WinXP

Still cracking the lcc nut. Thanks, Maggotboy, for the tip. Once you mentioned the $ + 5 trick, I had a good idea of what you're doing. Now, I just need to see how to get lcc to like it ...

[OrangePeelBeef]

I think i'll just leave the lcc up to you Spock, I'm just thrashing here and it's doing no good =)

I did happen to find some assembler code in chinese that makes references to call getstradd //5 bytes
and getprocaddress. I unfortunately can't read chinese :)

and again i don't know if i'm helping at all.. I haven't gotten anywhere with dev-cpp either.

here's this weird link
http://haowawa.com/king/article/writeshellcode_win_technology.txt

[maggotboy]

I'm working on a non-assembly solution ... dunno if its gonna work or not.

Maggotboy

[VanillaShake]

hmm, trying to remember my assembly (long time ago)...

try this for lcc? I think this will put EIP on the stack and then pop it off into pvmem.

_asm
{
call near +0
pop pvmem
}

[UncleBen]

Crashing to desktop also.

Compiled with VC++ 6.0 standard, no patches


also getting warning on compile with the code unmodified:

sniffer.exp : warning LNK4070: /OUT:EQSNIFFER.dll directive in .EXP differs from output filename "Debug/sniffer.dll"; ignoring directive

sniffer.dll - 0 error(s), 1 warning(s)

[maggotboy]

UncleBen -- you forgot to edit the EQSNIFFER.DEF file and change the "LIBRARY eqsniffer" to "LIBRARY sniffer" -- the name of the library must match (without the extension) the DLL name.

Maggotboy

[maggotboy]

Well, since everyone seems to be crashing to the desktop on the first keypress (which is when the whole shootin' match with the injection begins) it looks like I'm gonna have to do some more testing. :(

Guess the code was posted just a little prematurely. Sorry guys!

Maggotboy

[maggotboy]

Code updated to 2.02 -- see page 1 of this thread for revision information and the updated code.

One of the biggies I fixed was the INJECT_OFFSET calculation code. My MAKELONG command set the offset in the HIWORD rather than the LOWORD, causing the program to allocate WAY TOO DAMN MUCH MEMORY!

I am betting this is why people are crashing to the desktop.

Maggotboy

[h3x]

crashing to desktop

[gezs]

still crashing after your last update

[maggotboy]

h3x -- still crashing with 2.02? What'd you set the INJECT_OFFSET to ... or did you change it at all? Also, what compiler, and what OS?

Sigh .... I'll keep plugging away on it.

Maggotboy

[gezs]

didnt change offset, vc6.0, win2k

edit a bit more info..
once I run it I have to manually kill rundll32. Using the removehook command doesnt remove it from memory.

[h3x]

only changed the names in the def and the defined

vc++6
win me

[MisterSpock]

MSVC6 here, still major kaboom to the desktop.

Question --

I may have misunderstood one of the maneuvers you are doing here, but it appears you are stuffing code in the memory space allocated.

The only thought that comes immediately to mind is this: Does the program account for the differences in the size of the code that is to be placed in there? Even the same compiler with a few minor setting differences can produce a radically different memory footprint for a given piece of code.

[maggotboy]

I thought of that, too. I'll have to run some more tests to make sure I'm allocating the memory correctly.

The first thing I do is call VirtualAlloc() on the pointer to the InternalHookProc. The struct returns the base address of the memory along with the size of the region. All pages with the same attributes are considered part of the region.

Using the size of the region as an end marker, and the pointer to the InternalHookProc as a start marker, I copy everything in that range to the allocated memory block.

Maggotboy

[cheeze69]

I'm trying to get 2.02 to run after compiling with VS.net (on XP).

I don't get any crash errors, but my decode is not working. I get all "unknown" in the mob list.

I enabled the Debug configuration in VS.net, but where do the messages from the DLL get put??? I can't find them anywhere and they are not getting printed to the cmd.exe where I'm starting it from.

Finally, I'm using

rundll32.exe C:\Projects\VS\eqs202\Debug\eqs202.dll,InstallHook 192.168.1.2 1069 eqgame.exe 0x0078AAD0

to start the DLL. Is this the correct offset for the new eqgame.exe that was patched out today?

Thanks!

P.S. I just fired-up my previous 1.02 build with the new offset, and decode is working fine, so it's something specific to 2.02 I think.

[maggotboy]

To see the debug output, you must run the DBMON.EXE program that comes with the VC++ compilers. You can also get it from Microsoft's website.

http://www.microsoft.com/ddk/debugging/

The debug output doesn't show up in your development environment because the DLL is attached to another process and outputting debug messages to nowhere ...

Maggotboy

[cheeze69]

Is it normal for the process to keep allocating memory? I'm wondering if this is why some people are seeing crashes and maybe why my decode is not working:

908: >> MSEnv extensibility IClassFactory::LockServer(TRUE), lock count: 1
1300: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
1292: Ignoring process attach request for C:\WINDOWS\SYSTEM32\TASKMGR.EXE
260: time()-cpuSpeed:1405200
260: TimeGetTime-cpuSpeed: 1417381
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02AE0000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02AF0000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B00000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B10000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B30000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B40000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B60000
260: Found EQ Process!
260: Injecting code length 11971 ...
260: Code allocated at 0x02B70000

All of this was just *up until* it was asking me for the password :confused: I had not even entered the game yet.

Also, the rundll32 does not die even after exiting the game, so it appears that maybe something is not triggering properly.

Again, this is compiled with VS.net on XP. Let me know if I can provide any extra info.

Thanks,
Mike

[maggotboy]

OOOH!!!

You've just hit on something there, cheese! Dang, I wish I was at my development box so I could further isolate this.

The fact that the global hook is not dislodging is the big issue here. If the global hook doesn't dislodge, then it'll keep rehooking the keyboard over and over and over, and re-injecting over and over and over.

What I can't figure out is ... why isn't the hook being released? I'm running VC++ 6.0 on XP SP1, and its releasing properly every time.

Maggotboy

[cheeze69]

That would explain the increasing jerkiness the longer I played.

Fortunately, I have 1Gb of RAM, so it can leak for quite a while before I dump to the desktop! ;)

Let me know if I can help with the debug since you're not having the same issues.

Mike

[maggotboy]

You sure can ...

I use the CreateTempFileName() to generate a funky filename to use as the named Event in a subsequent call to CreateEvent().

OutputDebugString() on that baby to find out what it is.

In the RELEASEHOOK() proc, I call OpenEvent() to open the named event. Call OutputDebugString() on the string I am passing to OpenEvent(). It should match. If it don't, there's trouble and means the shared data segment may not be configured properly.

If OpenEvent() fails, the return value is supposed to be NULL. It should never fail if the hook is running! May want to check that too.

If you want to debug the actual release procedure (which occurs outside the debugger) ... Then in the RELEASEHOOK() function, add an "__asm int 3" at the beginning of the function. It'll raise an exception and allow you to open up your debugger and step through the code. Alternatively you can place a call to DebugBreak() which is an API call which does the same thing as "__asm int 3"

Maggotboy

[cheeze69]

I'll see what I can do. I must admit that I'm not very knowledgable about C++, so even something so trivial as adding a print statement can be troublesome :p

For example, I'm trying to figure-out how to output the gsh_szEvent in the wsprintf statement. I'm guessing that it is not a string due to all of the pukage I get from the build.

heheheeh....

If you get a chance and can post the changes that I can paste into my source (presumably, while you're at work?), I can do the build and test. I wish I knew more about C++ and Windows programming, but not knowing either one makes me pretty ineffective...

Mike

[cheeze69]

OK, I finally got the print statements in there. I did not see the repeated hooking attempts, but here is the output:

260: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
260: TempFileName: \5.tmp
1044: time()-cpuSpeed:1405199
1044: TimeGetTime-cpuSpeed: 1419015
1044: Found EQ Process!
1044: Injecting code length -12349 ...
1044: OpenEvent: 5.tmp
1044: 0 Removed
1044: 0 Removed


I wonder if the negative code length is indicating anything?

This "transcript" was from starting EQ to actually entering the game.

Mike

[orenwolf]

Anyone have this working with MinGW Yet?

I didn't notice a success with either the 1.x or 2.x codebase yet.

[guice]

Crash to desktop, too.

Dont know how to use the MSV6 Debugger, but when I hit 'Debug' I get an alert window pop up saying:
Unhandled exception in eqgame.exe: 0xC0000005: Access Violation

Not sure if that's a MSV6 thing, or that's the error that crashed EQ.

[UncleBen]

Originally posted by maggotboy
UncleBen -- you forgot to edit the EQSNIFFER.DEF file and change the "LIBRARY eqsniffer" to "LIBRARY sniffer" -- the name of the library must match (without the extension) the DLL name.

Maggotboy

LOL, shoulda flamed me for missing that, read over file again and saw it :).



Sure you dont' want to hear this, but EQ's still crashing with v2.2 after compiling np with VC++ 6.0 on Windows XP SP1.

Tried changing the INJECT_OFFSET numerous times also.

[UncleBen]

Originally posted by guice
Crash to desktop, too.

Dont know how to use the MSV6 Debugger, but when I hit 'Debug' I get an alert window pop up saying:
Unhandled exception in eqgame.exe: 0xC0000005: Access Violation

Not sure if that's a MSV6 thing, or that's the error that crashed EQ.


Getting same thing here

[maggotboy]

I've posted the 2.03 code ... its for debugging purposes only, and doesn't really contain much else by way of useful changes. There's a couple minor piddly tweaks, but nothing serious.

Hopefully with the added debug messages, I may get a glimmer of what's going on with the DLL not unloading.

Maggotboy

[UncleBen]

kk, gonna give it a whirl before I hit the sack for ya


EDIT: Not sure on how to get the debug output from this using VC++ 6.0. Tried debug -> attach to process -> rundll32.exe. . Dunno what else to do for ya :(

[nok]

Thanks for all the great work maggotboy. Very impressive.

Compiled with VC6 on XP SP1. Crashes on first keypress, but I can use the mouse just fine.



324: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
528: time()-cpuSpeed:1740769
528: TimeGetTime-cpuSpeed: 1768024
528: Found EQ Process!
528: Injecting code length 189159 ...
528: Code allocated at 0x099B0000
528: Setting hook procedure...


I'm not very smart but after spending a while staring at my screen it looks like you allocate the memory block to the size of the HookProc but you write the injection struct and the HookProc to that space... I'm probably just not understanding it correctly.

[Talon]

*cough cough*

I am a bit further. Have some ready keysniffer.dll file in folder DEBUG, everything fine, no compile errors.

Then i switch into this folder and enter :

RUNDLL32.EXE keysniffer.dll,InstallHook 192.168.0.1 10000 eqgame.exe 0x0078AAD0

keysniffer.dll = name i entered into eqsniffer.def
192.168.0.1 = IP of my EQ Box
10000 = Port that many peeps tell us to work
eqgame.exe = program
0x0078AAD0 = new offset since patch

I get some error message :
error loading keysniffer.dll
an initializing routine went wrong
(translation from the german message)

Anyone an Idea ? Dont FLAME me down /hide

[Fletch]

Originally posted by Talon

I get some error message :
error loading keysniffer.dll
an initializing routine went wrong
(translation from the german message)

Anyone an Idea ? Dont FLAME me down /hide [/B]

One page 1 of the thread Digi had the same problem and on page 2 maggotboy posted that he had updated the code. You will need to redownload the source files and recompile.

[Talon]

So far ok, Version 2.03 works after compile.

BUT

when i start EQWin afterwards and hit any key EQ breaks down to desktop.

I use Port 10000
is this wrong ?

[Fletch]

Originally posted by Talon
So far ok, Version 2.03 works after compile.

BUT

when i start EQWin afterwards and hit any key EQ breaks down to desktop.

I use Port 10000
is this wrong ?

No its not wrong, V2 is still buggy as far as I understand. I am guessing it will be debugged shortly.

However, Verison 1.3 is working and can be found at this thread:

http://seq.sourceforge.net/showthread.php?s=&threadid=2453/

[Jel321]

Just a thanks for the nice work Magg :)


C'mon guys, its so simple maybe you need a refresher course! Its all ball barings nowadays!

Great quote!

[Sodom]

quote:
--------------------------------------------------------------------------------
C'mon guys, its so simple maybe you need a refresher course! Its all ball barings nowadays!
--------------------------------------------------------------------------------


Those who quote Chevy Chase are doomed to failure

[Talon]

Confirmed : V1.03 works fine, thx for helping )

[Alwayslost]

Maybe I'm just lucky...

I compiled 2.01 last night and it worked GREAT.

I followed all the steps in the 1.3 thread.

MSVC6++ Standard (no SP, no SDK)
Compiled on WinXP
New Empty DLL
Project > Add to project > Files (.cpp and .def from the zip file)
Project > Settings > Link (tab) > Input (category) > "eqsniffer.def" (additional Library Path)
Build > Configuration > Debug stuff (Delete)

-- Edit the two files for protection
-- Definition file I did not alter spacing in any way, 4 edits,
-- .cpp file copied the 3 edits from the .def file

Press f7

Done.

Copied it to my system32 folder and set up a pair of shortcuts on my desktop to set and release the DLL. I used a 4 digit ODD number for the port to send to my EQ box (7531), set SEQ with the same port number, and BAM. GTG.


It worked EXACTLY as expected from what I could tell. I launched the DLL and RUNDLL32 popped into the task manager, (the release hook dropped it as expected) Launched it again then started EQ with Task manager still up. the screen flickered and showed me the Task manager again after the slpash screens and RUNDLL32 was gone from the task manager BEFORE I got to my login screen. I logged in and started seeing pretty colors all over my SEQ screen.


Maggotboy, you have, in my eyes, saved SEQ. Thank you.

P.S. You're a genius also.

:cool:

[guice]

Project > Settings > Link (tab) > Input (category) > "eqsniffer.def"

Uh? There's another method for adding the def file?! Ooops ... I've always added it via the Add to project > Files method. :eek:

I don't know if that makes any difference, but that's the only difference in my attempts to get this running.

That and I didn't do any of the Build debug stuff.

I'll have to play with it tonight when I get a chance. I'll post my findings, if anything different.

[Alwayslost]

I did both.

I know almost nothing about what I'm doing, that step may be completely redundant.

But I compiled it and it worked, so I was reporting the exact process I used to help those like myself. (I have about the same level of programming experience as I do landing the Space Shuttle)

I compiled 1.3 on a Win2k box and it ran on XP (I never launched EQ tho, but got no error when I launched it and the release worked fine)
I compiled 2.01 on WinXP and it worked fine, released fine and gave me colors is SEQ.



Side note:

I am a bit annoyed with the default selection of the (guilded lvl 0) "unknown" that appears in every zone, but I can live with it. In some zones like Nexus, by the time I'm finished zoning in this "BUG" has run off so far that the map has dropped in size to require me to use 25x zoom to see the full zone... Most weird.

[KaL]

I also experience the crash to desktop the first time I attempt to press a key on the keyboard.

[maggotboy]

I've posted 2.04, and hope its making steps toward stability :)

Here's a rundown on how I configured VS.NET and VC++ 6.0:

The Compiler Setup:

VS.NET Users (and others who want an idea what to tweak)
Create a new WIN32 Project
Project Options, choose DLL Project
Create the project and copy eqsniffer.cpp and eqsniffer.def into the new folder for it.
Remove stdafx.h, stdafx.cpp and ReadMe.txt from the project.
Right-click the project and add the eqsniffer.cpp file to it.
Right-click the project, and go into Properties
Change the Configuration to "All Configurations"

Expand the C/C++ options
Under "General"
- Debug Information Format: Disabled
- Detect 64-bit portability issues: No
Under "Code Generation"
- Enable String Pooling: Yes
- Enable Minimal Rebuild: No
- Enable C++ Exceptions: No
- Runtime Library: Single Threaded
- Buffer Security Check: No
- Enable Function-Level Linking: Yes
Under "Precompiled Headers"
- Create/Use Precompiled Header: Not Using Precompiled Headers

Expand the Linker options
Under "Input"
- Module Definition File: eqsniffer.def
Under "Debug"
- Generate Debug Info: No

MS VC++ 6.0 Users
Create a WIN32 DLL Project
For the options, select Empty Project
Copy the eqsniffer.cpp and eqsniffer.def file into the project folder.
Add eqsniffer.cpp and eqsniffer.def to the project (right-click and select "Add Files to project"
Right-click the project and select Settings
Change "Settings For" to "All Configurations"

In the C++ Tab ...
Category: General
- Debug Info: None

Category: C++ Language
- Enable Exception Handling: UNCHECKED
- Enable run-time type information: UNCHECKED
- Disable construction displacements: UNCHECKED

Category: Code Generation
- Use run-time library: Single Threaded

Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED

Switch to the "Link" Tab
Category: General
- Generate Debug info: UNCHECKED

As more people get up and running with different compilers I will incorporate those instructions into this post and in the source code.

Maggotboy

[Alwayslost]

Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED


I don't have these options, might be a service Pack thing? Or SDK?

Edit: I have the above options, just they are greyed out, so I cannot check them.

I followed all the rest of the instructions and it compiled with no problem.

[orenwolf]

Any hope of getting this to compile in MinGW or another free compiler?

I *really* don't want to have to pirate a compiler to get this to work. :(

[wiz60]

Nice job.

I havent tried this version yet - but the technology alone is worth the time to analyze this.

Last night I had thought to post a comment similar to yours regarding viruses etc. I didnt want to sound ungrateful - but you are exactly right. The technique is so good it's frightening!!

Of more consequence than viruses is the potential for this technology to forever change the "sacred" realm of EQ game. It is very applicable to MacroQuest and any number of other "assist" or "stats logging" functions.

Years hence I suspect someone willl look back and realize that inviting an incursion into the windows environment vs tolerating network sniffing - was a major error in judgement.

Regardless of how "smart" you think the SOE programmers are - there will be much smarter, larger groups of programmers working in lock step to defeat them.

*dodges a dog of war*

[maggotboy]

Lately I've been spending more time on detecting my sniffer than I have in writing new code. This is normally the fatal flaw of virus writers ... they spend more time trying to be sneaky than trying to defeat and/or detect their own code.

I've found a vulnerability in both my sniffers ... its not serious, but it IS there. I'm not going to go into detail until I have a resolution for it, though.

Maggotboy

[nok]

Used your instructions for building 2.04 and it works great. Excellent job sir!

[zeroman]

followed your instructions for .NET

it won't link

tons of unresolved external symbols

[scottie]

I may be missing something, but since this code is injected into eqgame.exe's memory space, why couldn't SoE just scrub their own memory for either 1) unused or "corrupted" memory, or 2) a footprint of this program which they can easily obtain since you're open source?

I used to do something similar. Not to detect injected code, but to scrub my own memory to watch for memory leaks or data that was being overwritten inappropriately. As long as you have a rough idea of what should be in your memory space, you should be able to determine if there is something there which should not be.

[Chutney]

Originally posted by Fatal


Does this mean it shouldn't be used? Is every other version available currently susceptible to the same detection method?

As i understand it, every sniffer posted on this board can be detected, however the task of detection has become much more complex with maggotboy's code (kudos maggotboy!). As to "should't be used", that is, as always, your decision.

In theory, is that there is currently no attempt on Verant's part to detect sniffers, however this may be wrong, or change in the near future. I like the theory tho.

The large number of different sniffers available will make any detection done by Verant that much more difficult, so if you do use a sniffer here, BE SURE to customize it slightly. Don't ever use the code as it is posted.

[maggotboy]

What it means is that when the next patch comes around (as you ALWAYS SHOULD) do not use the sniffer until someone with some authority has analyzed the new EQGAME.EXE for detection code.

The nature of the vulnerability is such that EQ could potentially identify the hooks that are installed in their process space, but they would be unable to determine where the hook came from, what/who installed it, and whether or not it was legitimate. For example ... they could identify the Logitech mouse driver's hook, but they wouldn't be able to determine whether it was installed by Logitech or some other entity. Likewise, they could identify the hook I'm using, but they wouldn't know where it was, when it was installed, etc. The information returned is extremely vague.

As I said...the vulnerability is not serious. Identifying hooks is a FAR cry from being able to trace into them to determine where the hook is going and where it came from.

At any rate ... I've got a solution for the 1.3 codebase, but not for the V2 codebase. There may not BE a solution for V2.

Maggotboy

[maggotboy]

Originally posted by zeroman
followed your instructions for .NET

it won't link

tons of unresolved external symbols

Fork 'em over ... can't give you an answer until I see 'em.

Maggotboy

[maggotboy]

Originally posted by scottie
I may be missing something, but since this code is injected into eqgame.exe's memory space, why couldn't SoE just scrub their own memory for either 1) unused or "corrupted" memory, or 2) a footprint of this program which they can easily obtain since you're open source?

I used to do something similar. Not to detect injected code, but to scrub my own memory to watch for memory leaks or data that was being overwritten inappropriately. As long as you have a rough idea of what should be in your memory space, you should be able to determine if there is something there which should not be.

What method did you use for scrubbing? Did you walk the heap? You must've had a starting point somewhere ... Did you examine your .data segment to ensure your global vars are scrubbed? Did you also go into the additional DLL's your program linked to and scrub their memory as well? Unfortunately, you've no idea what to look for in those DLL's to see if their memory was scrubbed. Not only that, but you'd also have to heapwalk their heaps as well, without knowing what you're looking for. Finally, you've no idea how many DLL's got attached to your process and where Windows may have relocated them in the event of a location conflict. Yes, you can find out, but how can you say for sure whether or not those DLL's are there legitimately?

Of course, all of those methods are completely ineffective with the V2 codebase. VirtualAlloc() doesn't allocate into the heap, so it can't be heapwalked. VirtualAlloc() also decides where to allocate the memory, so only the OS and the function that allocated the memory knows where that memloc is. Furthermore, when the code is injected into the memloc, the original function that allocated the memory and has that golden pointer disappears, leaving only the code in the new memloc with nobody referencing it except the OS and the code itself.

Maggotboy

[Alwayslost]

Too bad we can't get the sniffer hook to come FROM one of the legitimate sources...

If I understand all I have read we are using Windows RUNDLL32.exe to set the hook

Make the hook launch on to a logitech mouse driver (or similar), that then sets the hook for eqgame.exe...

Sort of a double blind... Show then an origin that they cannot have doubt about, or ban for.

GM_Techno_Feeb tells you, "You are being banned for using WindowsXP you hacker!"
You tell GM_Techno_Feeb, "??? WTF?"

[zeroman]

posting the linker errors
---------------------------------

tutorial5 error LNK2019: unresolved external symbol __imp__wsprintfA referenced in function _DllMain@12
tutorial5 error LNK2019: unresolved external symbol __imp__CharUpperA@4 referenced in function _DllMain@12
tutorial5 error LNK2019: unresolved external symbol __imp__UnhookWindowsHookEx@4 referenced in function "void __stdcall ConvDB2(struct HWND__ *,struct HINSTANCE__ *,char *,int)" (?ConvDB2@@YGXPAUHWND__@@PAUHINSTANCE__@@PADH@Z)
tutorial5 error LNK2019: unresolved external symbol __imp__SetWindowsHookExA@16 referenced in function "void __stdcall ConvDB2(struct HWND__ *,struct HINSTANCE__ *,char *,int)" (?ConvDB2@@YGXPAUHWND__@@PAUHINSTANCE__@@PADH@Z)
tutorial5 error LNK2019: unresolved external symbol __imp__CallNextHookEx@16 referenced in function "long __stdcall DispDB2(int,unsigned int,long)" (?DispDB2@@YGJHIJ@Z)
tutorial5 fatal error LNK1120: 5 unresolved externals

[MisterSpock]

What Maggotboy wrote is a general 'true-ism' regarding the WinNT/2K/XP family...

It is possible to detect many things.
Knowing where they came from is very difficult.
Knowing their intent is more difficult, still.

[maggotboy]

Zeroman --

In VS.NET in your project, right-click it and select Properties.
Next, expand the Linker settings, and go to "Command Line" at the bottom of the linker settings.

In the grey area where it shows the cmdline for the linker, copy all that and paste it into a post here.

Maggotboy

[UncleBen]

2.04 fixed my crashing np. Runs perfectly compiling with VC++ 6.0 on Windows XP SP1.

Thanx once again for your awesome work

[zeroman]

/OUT:"Debug/tutorial5.dll" /INCREMENTAL /NOLOGO /DLL /DEF:".\tutorial5.def" /SUBSYSTEM:WINDOWS
/IMPLIB:"Debug/tutorial5.lib" /MACHINE:IX86

[maggotboy]

Zeroman -- just as I suspected.

You've somehow zero'd out all the default libraries. For example ... creating a brand new blank DLL project, I get the following command line:

/OUT:"Debug/foo.dll" /INCREMENTAL /NOLOGO /DLL /DEBUG /PDB:"Debug/foo.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"Debug/foo.lib" /MACHINE:IX86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

See all those libs at the end? Those are the default libraries that are linked with the application. You're missing KERNEL32.LIB and USER32.LIB along with WSOCK32.LIB ...

Are you sure you made the project correctly?

File->New->Project
Visual C++ Projects
Scroll down to the bottom where "Win32 Project" is and select it. You won't see it unless you scroll down!
Punch in a name for the project.
Hit OK
In the Win32 Application Wizard, select the "Application Settings" tab.
Change it from Windows Application to DLL
Under "Additional Options" select "Empty Project"
Hit FINISH.

The rest of the compiler configuration steps are in the eqsniffer.cpp file.

Maggotboy

[BlueAdept]

I finally got around to looking at this. I must say it is probably the cleanest code I have ever seen. Everything is commented and proper.

What is wrong with you? Dont you know that programmers are never supposed to be neat? Your going to give 99.99% of programmers a bad name with this code!

Thanks maggotboy. That is a nice piece of work.

[Quick]

WinXP MS C++ 6


It all works great. Fantastic instructions.



Quick

[falkore]

Could be I am retarded, but the download (after Extracting) reads:

/* eqsniffer2.cpp written by Maggotboy

Revision 2.0






Why dosen't mine read 2.04?

[septara93]

I compiled it fine in VC6 and it worked 100%.. no crashing etc.

I will now hold off and see if people start getting banned.. but I think this is a step in the right direction. :)

[Alwayslost]

Mine says 2.04

Check your download location? Or maybe your Unzip location?

[fryfrog]

something along the way is probably caching it. i had the same problem, i ended up just using a different computer to get it cause i didn't feel like finding out if it was my squid proxy or my local cache.

[noacess]

Hey I just download the zip from maggotboy's first post and the .cpp file says Revision 2.01 not 2.04. Do I have the wrong file? Can some one repost the link to 2.04 for me? Thanks

[h3x]

does not crash right off the bat like the original :) yer a fine programmer...

feedback:
after running eq for sometime, with a working dll. eq crashed to desktop. do not have any out put to show. what went wrong or where. so not sure if i can say it was related. if this continues will post again.

/salute
thanks for the great efforst maggotboy

[rencro]

noaccess, check out fryfrog's post just above yours...But for good measure download to a new location and unzip from there, worked for me.....Or just do what fryfrog did.....

[guice]

it's 2.04 on the zip.

If you're using Mozilla, make sure you clear your disk cache. Mozilla isn't reading that the zip file changed and using your cache.

Once I cleared Mozilla's cache, I got 2.04 successfully.

[LordCrush]

Quick notice for Borland users :

if ou have problems to compile


__asm{
call $ + 5

(error says: syntax error) include this line in front


#pragma inline


From Borland developer forum:


TN162C.txt Using inline assembly
Category :ASSEMBLY
Platform :All
Product :BC 2.00-

Description:
QUESTION:
How can I, using inline assembly, jump to a function instead of calling
that function?
ANSWER:
You must add #pragma inline to the top of the source module that
contains the jmp assembly instruction and you must prototype the
function in assembly itself.
Assuming your using the small (near) memory model you can prototype the
function in assembly by saying:
asm extrn _funcname : near
To call the function use the following statement:
asm jmp _funcname
This will allow the person to use inline assembly to "jump" to a
function instead of "calling" it.


**** WARNING: I have only complied it with this - the first time now - never tested it *****

[gerbil42]

Trying to Compile in VC++6 on XP SP1 - Errors

--------------------Configuration: gerbil - Win32 Debug--------------------
Linking...
eqsniffer.def : error LNK2001: unresolved external symbol UDPINST
Debug/gerbil.lib : fatal error LNK1120: 1 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
Error executing link.exe.

gerbil.dll - 3 error(s), 0 warning(s)

Guess I should add a little more info:

When I try to do this step from the .cpp file,

Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat strings: CHECKED

those two options are greyed out and not able to be checked. Would this have anything to do with it?

I'm a n00b when it comes to C, please be gentle :)

[pyrodex]

winxp SP1, VS.net

v2.04

Followed directions in the files, everything compiled file. I installed the dll without any issues. Started a ngrep on my linux box and sniffed that specific port i configured. Started EQ clicked accept and after hitting the space bar to get past the screens EQ crashes. However the dll did work and I saw a blank key sent over to the linux box. Any ideas on the crash of EQ.

[Poser]

Compiled on XP SP1 with VC++ 6. Compiled fine after obfuscating the code and ran like a charm for 2.5 hours. By then it was late, so I went to bed. GREAT WORK, MAGGOTBOY!!!!!

[gezs]

I compiled 2.04 with Vc6.0 on win2k and all went well with your instructions. EQ doesn't crash with keystrokes anymore but the hook isn't releasing. I still have to manually kill rundll32.exe. Using the release command doesn't work either. I also left it running for approx 30 minutes while eq was sitting at the eula and task manager running. Slowly but surely the everything started getting bogged down. I killed rundll32 and performance came right back.

I followed your directions exactly only difference being:

Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED

were greyed out so I couldnt check them.

Any suggestions?

[fgay trader]

v 2.04, WinXP SP1, MS VS6 w/SP5. Compiled with no problems, runs just like the good old days :) Great job, maggotboy! And thanks a million.

P.S. Somebody give the man a "Developer" tag :)

[Monchichi]

I think I'm in the same boar as Pyrodex. I followed the instructions like a good boy, it compiles without a single complaint. I'm using MS VStudio .NET on Windows XP. Once I launch EQ, it crashes at the login screen back to desktop.

Version 2.04, compiles and crashes EQ
Version 1.3, compiles but doesnt appear to do a damn thing.

Ahu, Ahu :(

[Dedpoet]

I'm having the same issue as gezgs and gerbil42. I am able to compile with no errors or warnings (can't test yet from work), but the options below are also grayed out for me:

Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED

I tried checking and unchecking different options to see if these would activate, but no luck so far. I'm working blind since I'm not a C++ guy, but I'm going to keep digging on this. I'll post if I figure it out.

[Fletch]

[Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED

I was having this problem, you need to download Service Pack 5 for MSVS6. That will allow you to ungrey the boxes.

[maggotboy]

For those having problems where RUNDLL32 is not unloading

If you're running Win2k/XP, you need to get a hold of a program called DBMON.EXE. If you have VS.NET, its part of the installation, though it may not have a shortcut. If you have MSVC++6, you'll either have to download debugging tools from Microsoft at their site, or (gack) get a Platform SDK. I'd upload it here (its quite small) but we can't do binaries.

Run DBMON.EXE ... It's a console app, so it opens a DOS-like window and sits there intercepting debug output from all processes and displays it.

What I need is a copy of the debug output you get when you launch RUNDLL32 .... up to the point where you press a key in EQ that triggers the hook to start. Make sure #define _SNIFFDEBUG is set in the source code when you compiled it.

For those experiencing crashes in VS.NET
If you performed ANY steps above and beyond what I specified in the source code, then I need to know *exactly* what they are so I can duplicate them on my box. I am running VS.NET w/o the Platform SDK on XP SP1. I can't emulate your hardware (I'm running dual Xeon's), but at least I can compile the same way.

Maggotboy

[flobee]

2.04 codebase, compiled with a fresh install of MSVC++6 under XP with no problems at all.

The zone decodes before I'm even in it, I love it!

Thanks maggotboy!

[monster69]

Particulary Gezs

I am running XP SP1
compiled on VS6

Runs great, works great.

I see the same thing as Gezs does, RUNDLL32 does not unload when eqgame.exe starts. However, as soon as I press a key (not mouse movement) RUNDLL32 unloads, the code injects and the sniffer runs as advertised.

So, press a key, it should work.

Monster

p.s. Amazing work maggotboy.

[devnul]

I have similar behavior. Compiles fine under W2K VS.NET, hooks fine on my WME EQ box.

The FIRST time I start EQ, as soon as I press a key, it sends ONE all zero key and crashes EQ to the desktop.

It does not unload. Using the unload does not work either. You have to kill it or reboot (which prompts you to kill it, since it doesn't respond to close).

After the first time you run EQ you can run EQ fine but no more keys are sent. Whether you rehook or not, doesnt make any difference. EQ runs fine but the key is never sent again.

I suspect it may be because many people use 98/ME to actually run EQ. I am using ME, trimmed down to bare essentials.. no other task running.

So I guess my question is whether anyone has this working on ME or 98?

dn

[h3x]

i am running win ME the dll works but i do see that it does not unload after being injected also after a period of time eq does crash to desktop, i have yet to run a debug to see where my problem lies...

but yes it does catch the key and sends the key after a crash i do have to reboot the system to get it to function again. since it never closed out after the initial injection.

[Dedpoet]

SP5 did enable the boxes and allow me to check them, thanks, Fletch. The dll grew to about 68k from 56k, so whatever was supposed to be changed was, or so it seems.

I have the same problem with rundll32 not unloading after I call the unhook (on Win2k right now). I have access to DBMON at work, but unfortunately not EQ. Maggotboy, if no one gets you that info you need this afternoon, I can probably get it to you tonight.

[devnul]

h3x did you compile with VC6 or VS.NET? Which OS?

What mem offset did you use? (I used what was there (4) after having initial troubles)

dn

[h3x]

compiled with vc6 under ME using in ME didn't change the mem offset.

and all the compiler settings are as suggested. the first version of this dll 1.3 works great with no errors... it's this new fangled gizmo stuff that the confuzer isn't werking with :)

[wizard]

anyone get this to compile and work with one of the free compilers out there? mingw etc.

[bonkersbobcat]

Maggotboy -- did you see this question?

(It wasn't really posted on the right thread and it ended up on the end of a page. You have been pretty quick at answering questions, and I haven't seen your comment on this yet.)

http://seq.sourceforge.net/showthread.php?s=&threadid=2453&perpage=1&pagenumber=120

[gerbil42]

quote:
--------------------------------------------------------------------------------

[Category: Customize
- Enable function-level linking: CHECKED
- Eliminate duplicat string: CHECKED
--------------------------------------------------------------------------------



I was having this problem, you need to download Service Pack 5 for MSVS6. That will allow you to ungrey the boxes


I must be a dumbass or something, because SP5 did not ungrey the boxes for me.

[gezs]

I'll do the sp5 update and then run the debug tools when I get home tonight.. don't have access to any of it from work.. it'll be about 5 hours till I'm home..

[fryfrog]

Originally posted by gerbil42


I must be a dumbass or something, because SP5 did not ungrey the boxes for me.

same here, applying sp5 was the first thing i did after installing my old ass copy of vc++. it didn't make these available, if you right click and choose help it says something about some other option that has to be un/checked to make this one available.

it compiled fine, but i haven't tried it with eq yet.

[fhm]

68k? Wow. Mine is only 27k.

Regards,

CJ

[Fletch]

I just tested from home and V2 is working great. /cheer Maggotboy and everyone who contributed.

[Ataal]

quote:
--------------------------------------------------------------------------------
Originally posted by gerbil42


I must be a dumbass or something, because SP5 did not ungrey the boxes for me.
--------------------------------------------------------------------------------


Brand new install of Visual Studio(c++ comes with it) on winxp, did the SP5 thing, still gray'd out. I'm at work still so I'll try it at home too and see if there's any differences.

[Raelik]

Kudos to maggotboy for his incredibly well-documented code! I got it modified and compiled in under 5 minutes. Granted, I don't know if it actually WORKS yet (compiling qt... good god!), but the code is beautiful!

[h3x]

just to guess what's happening to me cause i can't get a debug properly... it's not run32 isn't shutting down and it's continually loading the code or injecting the code each time windows alloc's memory and it's eating away at the resources causing either eq to crash or just windows all together running dbmon the system complete lock up when it decides to go down.. =\

[Ataal]

Ok, I have a work-around for the gray'd out boxes and sp5 doesn't fix it.

By right clicking on the the boxes, it mentions that you cannot modify this setting if you have selected 'edit and continue' in the debug info drop down list under the general category. Actually, you can't either way, lol. Ok, back to my point here, if you select 'program database' and go back to customize, those boxes will not be gray'd out anymore. So, check the boxes, go back and put the debug info drop down back to 'none'. You will notice that even if you go back to customize, those boxes will now always not be gray'd out.

I haven't compiled it yet by doing this, on my way home now.

[gezs]

Well the good news is I got it all working properly even decodes in seq and everything.. BUT rundll32 is still stuck in memory. When I kill it manually seq continues to recieve the key. I am downloading the debug tools.. damn dial up sucks.. I want my dsl back.. I'll update after I get debug going..

[cheeze69]

Bummer!

I just built 2.04 using XP and VS.NET and EQ craps-out whenever I press a key, for example, to speed past the SOE self-promotion screen.

I added #DEFINE _SNIFFDEBUG to the code and captured the following using dbmon:

1816: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
1816: Creating event handle "1A.tmp"
440: time()-cpuSpeed:1391062
440: TimeGetTime-cpuSpeed: 1415350
440: Found EQ Process!
440: Injecting code length 37888 ...
440: Code allocated at 0x02590000
440: Setting hook procedure...
440: Opening global event "1A.tmp"



I followed the directions that maggotboy posted on setting the options for VS.NET, so that's my environment. Here are the compiler flags just in case it's useful:

C/C++ options:
/Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_USRDLL" /D "EQS204_EXPORTS" /D "_MBCS" /D "_WINDLL" /GF /FD /RTC1 /ML /Gy /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /nologo /c /TP

Linker options:
/OUT:"Debug/eqs204.dll" /INCREMENTAL /NOLOGO /DLL /DEF:"eqs204.def" /PDB:"Debug/eqs204.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"Debug/eqs204.lib" /MACHINE:IX86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Resources:
/fo"Debug/eqs204.res"

MIDL:
/nologo /env win32 /tlb "Debug/eqs204.tlb" /h "eqs204_h.h"

Any idea?

Thanks,
Mike

[nino2469]

still have crash to destop with v2.04. Using WinXP and MSVS.NET

[RUiNER]

I just want to say that I followed your instructions in this thread and if you follow them close enough.. it does work.. cookie-cutter recipe to me :)

[Crux]

Also having the problem with the greyed out boxes

xp, msvc++6 sp5

only way i can get those 2 boxes to become checkable is if i change the "Settings For:" option in the top left corner of the settings to "Win32 Debug"

Compiles fine though, no warnings or errors.

3180: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
3180: Creating event handle "E8.tmp"
2356: time()-cpuSpeed:1468713
2356: TimeGetTime-cpuSpeed: 1483468
2356: Found EQ Process!
2356: Injecting code length 33792 ...
2356: Code allocated at 0x02990000
2356: Setting hook procedure...
2356: Opening global event "E8.tmp"

it seems to hook and release fine, but my seq box isnt catching the key. Doublechecked that i had the correct ip/port for my seq box in the dll call and that seq is waiting on the correct port, but no decode =\ still gps mode.

i fired up tcpdump listening on the correct port and didnt recieve anything.

Would those two checks im missing because theyre greyed out have anything to do with this?

~Crux

[Raelik]

I also having the grey box problem, and I do have SP5 installed. I tried Ataal's trick, but that wouldn't work for me. I'm installing the Platform SDK to see if that helps.

[RUiNER]

I've had the grey box problem too.. You know how to fix it? Do all the other changes then click apply/ok.. then go back in and the boxes won't be grey anymore.

I didn't really see that as an issue but it's like order of operations.. some function needs to save for others to appear!

Hope I made sense!

[fooo]

my own lameness was the cause.




~fooo


(actual name withheld for silliness and paranioa)

[Raelik]

Originally posted by RUiNER
I've had the grey box problem too.. You know how to fix it? Do all the other changes then click apply/ok.. then go back in and the boxes won't be grey anymore.

I didn't really see that as an issue but it's like order of operations.. some function needs to save for others to appear!

Hope I made sense!

Are you sure that's what's happening? Or is it because after you save and then go back in, the "Settings For:" is set to Win32 Debug, because that's the default Active Configuration is. If you pull that pull-down back to All Configurations or Win32 Release, they will grey out again. I've already tried compiling in with a debug configuration, but that doesn't work.

[maggotboy]

Unfortunately, I have limited environments from which to test here ... I would love to solve the unhooking problem first. I'm sure its related to some of the crashes people have been seeing, and plagues both the V1 codebase and the V2 code. I'm gonna have to rely on those of you with debuggers that are experiencing the problem to provide me with some output ...

Fooo -- those messages are coming up because the "Perform 64-bit compatibility tests" option was not unchecked in your project settings. They're merely warnings about incompatibility with a 64-bit build, and nothing to worry about.

Maggotboy

[Raelik]

I successfully compiled without the greyed out options, using the Win32 Release config, and here's my DbMon output:

968: Ignoring process attach request for C:\WINNT\SYSTEM32\RUNDLL32.EXE
968: Creating event handle ""
1108: time()-cpuSpeed:1150105
1108: TimeGetTime-cpuSpeed: 1162844
1108: Found EQ Process!
1108: Injecting code length 28416 ...
1108: Code allocated at 0x02650000
1108: Setting hook procedure...
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""
1108: Found EQ Process!
1108: Opening global event ""
1108: Unable to open global event ""

any ideas?

[maggotboy]

Ok, that's enlightening, Raelik!

Creating event handle "" -- this means the name didn't take for some reason. I call GetTempFileName(), perhaps this function is failing somehow.

This would cause the release not to function. Gonna do some research on it.

Maggotboy

[maggotboy]

Maggotboy gets a RTSM (Read The Stinking Manual for those of us who don't swear) for this blunder with the event handle ...

Thanks to Raelik and a quick look at GetTempFileName, I'm not supposed to use NULL for the directory name. It causes the function to fail!

I'm posting a 1.4 version in the old thread, and a new V2 in this thread.

Maggotboy

[bonkersbobcat]

Swear? Everyone knows that RTFM stands for Read The Fine Manual. :/

[fooo]

ok got the code to run, but pressing keys in EQ leads to crashes.

is it still happening to other people with the latest code?

~fooo

[gezs]

Its fully functional now.. releases on first key strok..

very well done..

[Dedpoet]

Maggotboy for President!

Unloading beautifully now, thanks man.

[Crux]

still hounding out why my seq box isnt recieving a key.

New code compiles, hooks, and releases as did before. DBmon looks a little different:

2508: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
2508: Creating event handle "118.tmp"
836: time()-cpuSpeed:1468821
836: TimeGetTime-cpuSpeed: 1483508
836: Found EQ Process!
836: Injecting code length 33792 ...
836: Code allocated at 0x02990000
836: Setting hook procedure...
836: Opening global event "118.tmp"
2400: DIB resource not found, trying RT_BITMAP.
836: 0 Removed
836: 0 Removed
568: DIB resource not found, trying RT_BITMAP.
2400: DIB resource not found, trying RT_BITMAP.
2400: DIB resource not found, trying RT_BITMAP.
836: 6 Removed
2400: DIB resource not found, trying RT_BITMAP.
2400: DIB resource not found, trying RT_BITMAP.


..that "resource not found" message part of the sniffer or another program? I get 2 or 3 every time i zone

tcpdump shows a udp 8 being sent from my eq box to my seq box on the correct port, but no decode.

EQPacket::dispatchZoneData():CharProfileCode:Not Decoded

~Crux

[Raelik]

Ok, v. 2.05 seems to be working fine. It attaches to a valid handle, and the dll unloads when I hit a key. I don't have time to test it right now, but this afternoon I'll see how well it works. I've compiled it without those grey boxes being checked.

[cmore]

I get the following attempting to build the project in visual studio .net as a c++ project.

error LNK2005: _DllMain@12 already defined in eqsniffer2.obj
warning LNK4006: _DllMain@12 already defined in eqsniffer2.obj; second definition ignored
fatal error LNK1169: one or more multiply defined symbols found

I have followed the directions for project setup contained in the eqsniffer2.cpp file twice to make sure I am doing it per the instructions. The only exceptions are
1) for the step "Project Options, choose DLL project", I instead have a modular window still up (because the project hasn't been created yet' titled 'Win32 Application Wizard', and can set the project to be a DLL under the 'Application Settings' tab.
2) When setting the options for the project, instead of just xyz: <setting> I instead have many of them that the closest matching option is listed such as 'Enable String Pooling'/'Yes (/GF)'. I don't know if this matters.

I am compiling it on my machine at work, and will try to run it on my machine at home. Both are w2k.

[EnvyEyes]

Originally posted by Crux
still hounding out why my seq box isnt recieving a key.

~Crux
Have you made sure you are using the newest libEQ.a?
I know I was having the same issue when I first used V1, then a friend told me that (unknown to me) there was a new libEQ.a dated 11Nov, I believe.

I grabbed the new libEQ and re-compiled.... I had Skittles!!! =~)

Hope this helps

[ColdBrew]

Ok got v2.05 working on two different machines using VC++6.
Thanks for the very nice program!

[maggotboy]

cmore -- make sure the eqsniffer2.cpp file is the only .c or .cpp file in the project. The linker is telling you more than one DllMain is declared somewhere, which means you probably forgot to take out the additional files VS.NET created for your DLL project.

Maggotboy

[OrangePeelBeef]

Now we just need it to compile in Lcc =)

[gawker]

Just my input to fix the grey box problem. Make the project setting changes before adding any files to the project. This corrected my grey box problem.

[MisterSpock]

OPB -- I know we need Lcc instructions... I have not yet been able to get it to not crash the target program in LCC yet. :(

[Raelik]

Came home for lunch to test this puppy. Works like a charm.

[Crux]

yeah, using the new libEQ.a and verified md5.

is there a way to tell if seq is picking up the key being sent? is there a broadcast that should be showing somewhere in the shell that seq is recieving the key or an option im missing somewhere to tell seq to look for the incomming key (aside from the key port option under the Decoder dropdown) ?



~Crux

[Raelik]

Yeah, you'll see a message in the console telling you that it grabbed a new key. Can't remember exactly what it looks like though. This is assuming you're starting SEQ from a shell as opposed to your window manager.

[Mongo222]

Maggotboy could you address this issue?

Before I start seriously start beating my head against the issues involved with the mods needed to compile this with the cygwin/gcc envirornment....


Is there any known show stoppers that would make this impossible?

[maggotboy]

Mongo222 - which issue ... the LCC compiling issue, the not sending SEQ a key issue or the crash on keypress issue?

LCC: I've never used it, and since other people are, I would rather leave this to someone with more experience to resolve.

Sending keys: Make sure SEQ is listening on a port above 1000, preferably above 4000. Make sure the RUNDLL command is also using the same port.

Crash on keypress: Not sure how to resolve this yet. I'll need someone who's experiencing this issue to give me OS details, compiler details, and be willing to run DBMON.EXE and give me some debug info so I can proceed.

Maggotboy

[MisterSpock]

I'll have the LCC egg cracked eventually. I had to put it aside for a day or two as (annoying) RL stuff took priority.

Good news is -- I know where the problem is. Bad news is I don't know how to fix it (yet).

[kabl]

well i dug through the doc i seen about converting the data segment for borlands use but im at a bit of a loss as to what i have to fo now

i made a file for the datasegment

//file
#pragma option -zRSHARED

LPVOID gsh_pvEQKey = NULL;
BOOL gsh_bInjected = FALSE;
HHOOK gsh_hHook = NULL;
TCHAR gsh_szFileName[MAX_PATH] = {_T("\0")};
SOCKADDR_IN gsh_SEQAddr = {0};
DWORD gsh_xorby = 0;
TCHAR gsh_szEvent[MAX_PATH] = {_T("\0")};

//eof

i modifyed the .def file like so

//file
LIBRARY EQSNIFFER

SECTIONS
SHARED READ WRITE SHARED

EXPORTS
blah
blahblah
blahblahblah
//eof

and inside the main .cpp im not really 100% what i had to do as that doc isnt very detailed but im assuming i had to declare allthe datatypes extern but whatelse if any to modify im at a loss...

extern LPVOID gsh_pvEQKey;
extern BOOL gsh_bInjected;
extern HHOOK gsh_hHook;
extern TCHAR gsh_szFileName[MAX_PATH];
extern SOCKADDR_IN gsh_SEQAddr;
extern DWORD gsh_xorby;
extern TCHAR gsh_szEvent[MAX_PATH];

now when i try a comile with this as it is i get erros pointing to the shareddata seg .cpp saying declaration syntex error.....

far as i can tell i did what it said lol any input on this would be welcome..

[fooo]

To address the key press issue...

downloading platform sdk right now (to get dbmon) grats me on having Universal MSDN subscription.

I'm running the latest patch of windows XP, compiling with Visual Studio.NET 2003 (final beta) with no complile errors.

I have an athalon XP 1700 with 512 mb of ram on a MSI motherboard that uses the Via KT266A chipset.

I get the problem both with eqwin and normal everquest.

key presses do not always crash out eq!

it seems to be timing related. The login screen doesn't generally crash you out. But skipping past the everquest splash screens always does.

could be a race condition or something like that that is affecting the crash bug.

will get back with dbmon output.

~fooo

[maggotboy]

fooo -- hehe, aye... I'm an independent software developer, and for what I do, its worth the 2k/yr to have the Universal subscription.

However, you don't need it to download the platform sdk. Besides, if you have VS.NET, you've already got DBMON.EXE -- do a search in the VS install directory.

Maggotboy

[fooo]

heh my boss bought me the universal becuase I told him to... he fired me a while back, and forgot to cancel the subscription. poor him.

anyways here's the DBMON output

2100: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
2100: Creating event handle "27.tmp"
2264: time()-cpuSpeed:1462311
2264: TimeGetTime-cpuSpeed: 1470296
2264: Found EQ Process!
2264: Injecting code length 25600 ...
2264: Code allocated at 0x02470000
2264: Setting hook procedure...
2264: Opening global event "27.tmp"




eqcrashes right at 2264 =)

~fooo

[T.C. Jaguar]

Maggotboy,

EQ is crashing when I press a key at the Sony splash screen. rundll32 does exit once eqgame.exe is found.

Athlon 1 GHz, 512 MB RAM, WinXP SP1, VS.NET

1764: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
1764: Creating event handle "6F.tmp"
224: time()-cpuSpeed:999984
224: TimeGetTime-cpuSpeed: 1020220
224: Found EQ Process!
224: Injecting code length 132096 ...
224: Code allocated at 0x02460000
224: Setting hook procedure...
224: Opening global event "6F.tmp"

[fooo]

heh... looks like the bug is verified =P

[notaguru]

using VC++ 6.0 Sp5

Ver 2.05 compiles fine with no errors and sends key to the proper port and address.

Hardware:
P4 1.8 512mb intel board geforce4 video

Os:
Win98se

Problem:
after exiting eq, rundll32 is still in the process list and I have to ctr/alt/del then end task to get it out. Going to system info show ******.dll as a system hook, type: Keyboard. Using the renamed ReleaseHook function doesn't exit either.

Question:
Any idea on where I screwed up? What other information do I need to give?

Thanks

PS Great work Maggotboy, Thanks for all the effort and help you have provided here

[Crux]

Make sure SEQ is listening on a port above 1000, preferably above 4000.



'twas my problem. thanks

[Stormdvill]

My Project compiles fine with VS6

When I launch Rundll32 mydll.dll,myInstallHook x.x.x.x 5555 eqgame.exe 0x0078AAD0

With version 1.4 or 2.0 I get the following error dialog box:
An exption occurred while trying to run "mydll.dll,myInstallHook x.x.x.x 5555 eqgame.exe 0x0078AAD0"

It stop on the return statement in the debugger:

// Global hook procedure which captures all mouse events for all processes.
LRESULT CALLBACK EQHOOKPROC(int nCode, WPARAM wParam, LPARAM lParam)
{
// Do-nothing hook procedure ...
return CallNextHookEx(gsh_hHook, nCode, wParam, lParam);
}

It was working great with one of the older version of 2. However I seem to have copied over the working code :(

Thanks for any help :)

*Edit I'm on WinXP on my development workstation and gaming workstation if that helps at all...

[seqseq]

Unexpected EOF, line 605 when I try to compile with VC++.net

Version 2.05 of the code as well.

Hmm..

By the way, Maggotboy, this is absolutely amazing!

[Lube~]

Just want to say great work Maggotboy, keep up the good work.

I just downloaded revision 2.05, followed your guide to the letter ;) and it compiled and works like a dream.

Used the following if anyone is interested.

MS Visual Studio C++ 6.0 Enterprise Ed. with SP5
Win2k with SP3

Lube~

[falkore]

DBMON.EXE not installed with VS.net.

Anyhow. Win2K all SP's, VS.NET (academic).

First keystroke dumps eqgame.exe from process list (Kills the Pid, seems)..


It's a bug. =)

[domesticbeer]

Once I press any key bam! right to desktop

Here is dbmon output
2552: Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
2552: Creating event handle "7C.tmp"
3660: time()-cpuSpeed:1495734
3660: TimeGetTime-cpuSpeed: 1512344
3660: Found EQ Process!
3660: Injecting code length 37888 ...
3660: Code allocated at 0x09940000
3660: Setting hook procedure...
3660: Opening global event "7C.tmp"


using winxp sp1 and VS.Net Enterprise Arch to compile it.

[Ekin]

Finally , it work . Thanks guys.

But , any idea how to make it work with eqw ?

It seem the key screwed up if eq running on eqw .

[darkgrue]

If all you need is a simple debugger, just to view output from OutputDebugString() function, then you may want to check out DebugView (http://www.sysinternals.com/ntw2k/freeware/debugview.shtml) from Sysinternals (http://www.sysinternals.com/). It is a much, much smaller download.

I was able to get it up and running instantly, as opposed to the Microsoft Debugging Tools (http://www.microsoft.com/ddk/debugging/). For that you can expect a 7MB download. I gave up trying to decode the bewildering array of options just to get it to cough up the debug messages I wanted. It's obviously a much more powerful tool, but for someone who isn't familiar with the MS development environment or tools, the learning curve is nearly vertical.

I rewrote Maggotboy's 2.05 code to improve the debugging output. However, I was an idiot and left my source at home. I'll post it come the new week. No one will probably miss it, since the code works great without the changes. Mostly did it as part of eyeballing the code to understand at least in broad terms what it was doing and when.

I really wanted to use OutputDebugString within InternalHookProc, but it didn't take me long to realize (CRASH!) that OutputDebugString would probably have to be referenced in the INJECTSTRUCT for the same reason everything else is. I'll play around with that, but if someone who knows what they're doing wants to beat me to the punch (you'll have all weekend <grin>), be my guest.

[dpaschal]

What compiler should
I use to compile this code? I need something that is FREE. ;)

[cryptorad]

I have the same problem as Stormdvil. But .. I started compiling at 2.04 and have always had it. I was/am still checking everything over prior to posting.. but since there is another.. I felt I'd add my voice. I have not found anything out of the norm yet and looks like I followed all instructions correctly.

I have not been compiling since loading this machine and only loaded VSC++6 to for this specific compile, so I don't have what may be normal compiler setups. I only loaded VC6+ for this and followed the setup instructions. The SDK wasn't required I read so it's not in.

I'll provide more info as I find it.


Tks to any looking at it.

[cryptorad]

Storm.. used a different debugger on mine.. it tells me the symbol search path is invalid. Basically.. looks like some missing symbol files. Working on figuring it out right now.

[h3x]

Start up dbmon
load up .dll
start eq

i'm not seeing any debug printouts
is there some setting before comiling to have them to display?

[nok]

Originally posted by h3x
is there some setting before comiling to have them to display?

Make sure you are downloading the newest version (clear your browser cache and check that the version in the source code is 2.05.

Make sure that the next line is not commented out :



#define _SNIFFDEBUG

[h3x]

yes to both got the code for 2.05 and that line is not commented out. does dbmon have to be in the same directory as the dll or is there a setting to have set, i used the recomended vc++ settings that are included with the cpp file yet when i load dbmon and the dll i see no output msg's as been posted

[sequsr1]

Alright guys, I am at a complete loss here. Getting kind of frustrated, so maybe you can figure out what I am doing wrong.

Have downloaded the newest and oldest versions of Maggotboy's code. Have successfully compiled and re-compiled them.

Downloaded the newest libEQ.a.

Downloaded the latest CVS of SEQ, and compiled successfully.

Setup the rundll32 command properly each time and was able to see it hooked into memory.

No matter what I do, I am still getting unknowns in the SEQ window. The weird part is that it seems to be decoding some of it as it is listing Items, but that is it.

Been working on this for a few days now and I am sure there is something I am completely missing. Any ideas?

I am following the instructions to a T, just don't know what could be wrong.

Any help is greatly appreciated.

Thanks.

[nok]

Originally posted by sequsr1
Downloaded the newest libEQ.a.

Are you sure that it replaced the old version? check your md5.


The weird part is that it seems to be decoding some of it as it is listing Items, but that is it.

Items are not encrypted at all, thats why you see those.

Try using port 10000.

Make sure that the IP for your seq box is correct.

Do any of the more basic keygrrab routines work? If so, do any of the other UDP program work?

Any strange debug output in dbmon?

[Ataal]

For those of you 'n00bs', like me out there....I have a suggestion that fixed every single problem that I had.

Let me first start off by giving you a brief history of what I have tried since I first learned about the whole sniffer thing:

I first tried a couple of the other sniffers and realized at that point that I had no clue what I was doing. Feeling completely overwhelmed, I just dealt with the gray dots for a week or two. I became increasingly wanting of the 'skittles'. I've been using seq now for about 8 months and had been through several adaptations and figured I have been through so many others, I can do this, I know I can.

I came to this thread and decided I'd give this one a try. I was able to download MS Visual Studio from Microsoft's site license agreement site from work. I copied the code into it and fired it up, still gray dots. I made sure I had the latest seq version, reran cvs -z3 update, deleted the old libEQ.a and got the latest one, still gray dots. I tried several UDP port numbers ranging from 4444 to 10064. gray dots. /sigh

I was getting these inflation errors in seq....so I did a search(yes I know how that function works now), the first thread about that said something about syncing issues and a complete wipe of seq and re-install fixes it.

Guess what, I GOT SKITTLES NOW!! WOOT!!

So, even though I had the latest version of seq, for some god awful reason, a complete wipe/re-install fixed it.

This is a suggestion to all of you peeps out that there that are just like me, those that feel so overwhelmed by all this.

[sequsr1]

Did the md5sum with the libEQ.a I have and compared it with the one posted in the Annoucements...it is the same.

Did a re-compile with the .dll file and it compiled successfully and is loading successfully.

Still nothing.

At the moment, I am running EQ on a Windows XP box on a hub with the Mandrake 9.0 box.

I did what was suggested above and completely wiped out any trace of SEQ on my linux box.

Downloaded the latest CVS, compiled and installed.

Still getting my name and information picked up on SEQ. But as far as the colored dots go, there is nothing.

How can I go about making sure my linux box is picking up the UDP packets from the EQ box?

I am thinking that may have something to do with it, but I can get Chat in the chat window and spells and such appear there too so I know it is listening.

well, tried the complete re-install of SEQ today.

I am just not sure how to get around the unknowns and get the "skittles" :(

About ready to give up and just go with the navigation tool for a while as I am at a loss atm.

Any help is appreciated. Thank you.

[maggotboy]

What port are you telling SEQ to listen on?

Maggotboy

[sequsr1]

Port 5555 atm

Tried all kinds of ports.

Also, I am getting this in the SEQ terminal. Have anything to do with it?

EQPacket::dispatchZoneData():CharProfileCode:Not Decoded

If you have any other questions, let me know. Will try to respond promptly.

[link129]

How can I go about making sure my linux box is picking up the UDP packets from the EQ box?

On your SEQ box type:
tcpdump dst port 12666 (use your port number)

You should see something like the following:

tcpdump: listening on eth0
09:33:55.964567 eqbox.1054 > seqbox.12666: udp 8

If you don't the packets aren't getting there.

[sequsr1]

Thanks for the tip Link129.

Changed the port that SEQ is listening to to 12666

Re-ran the .dll file on port 12666:

rundll32 tcplnk.dll,tcplnkih 192.168.1.102 12666 eqgame.exe 0x0078AAD0

Ran tcpdump dst port 12666

tcpdump: listening on eth0

17:49:28.770391 192.168.1.100.1916 > 192.168.1.102.12666: udp 8

192.168.1.100 = EQ box
192.168.1.102 = SEQ box

Seems like the information is getting there, but not being decoded?

[link129]

When you updated you libEQ.a did you update you ld.so.conf? Are you using a softlink to showeq that is a old version? Did you tell showeq to use your port # from the decode menu?

Only things I can think of right now.

[fhm]

Ask a simple question...

Are you guys just logging into EQ and staying in the same zone?

Sometimes I find that SEQ doesn't start to decode until I move to a new zone (not camp and come back, just walk from one zone to another). I know the keys are getting there, because SEQ is telling me that they are (the whole "decrypting and dispatching with" line).

Regards,

CJ

[Admatha]

ok, i also posted something similar on the thread about v1, but i thought i'dd add it here. i have compiled this using MSVC++ 6.0 on two different computers, and attempted to run it on 3, the two compile computers are both win XP tho one was a clean install, the other has the most recent service packs, the test comps were 2 winXP (same as before) and one windows 98SE. in all cases after typing in the line

c:\<path>\rundll32.exe <filename>.dll,installhook 192.168.254.99 10000 eqgame.exe 0x0078AAD0

i get the message

rundll
An exception has occurred when trying to run "<filename>.dll,installhook 192.168.254.99 10000 eqgame.exe 0x0078AAD0"

and no i didn't type in <path> i typed in the path to the rundll32 file and so on for the items in <>. i have no idea what might cause this problem, especially with BOTH versions of the sniffer, and i would very much apreciate any feedback that might help me fix it, thanks.

[cryptorad]

There are two of us battling a similar error on our machines.

Seems we are all running MSVC6 on WinXP machines is the most common link so far. I'm suspicious of some things but nothing I have tried has resolved it yet.

The posts with the information is located on the other thread in this forum located here ...

http://seq.sourceforge.net/showthread.php?s=&threadid=2505

Keep your eye out there for possible information.

[S_B_R]

Looking at the code, "InstallHook" is also a variab le in the commandline. Meaning if you replaced the "InstallHook" in the .def file you need to use the word you replaced it with. That is, IF, you replaced it. ;)

[sequsr1]

Uhhh...no idea what happened.

On my last post, I put that the tcpdump was picking up the packets, but nothing was appearing.

Left to go see the new Bond flick.

Come back and I have red dots all over my SEQ window.

Guess it took some time for the decode to happen; maybe with the traffic on my network.

Well, thanks for the help guys. It is working like a champ now!

[Ekin]

I am wondering if the sniffer monitor the eqgame.exe 's program ID will work .

I having hard time to run 2 everquest on same machine but the seq keep using wrong key to decode after I zone.

Showeq did checked the session tracking .

[learningquick]

ok, Great code!

I am experiencing just a couple of issues.

1 - after several times zoning (or when I camp in and out) SEQ displays the itty bitty maps. I have to shut down SEQ and restart it to make the maps work again.

2 - SEQ sometimes misses a decode or I get mixed results (some unknown spawns and some decoded spawns).

3- GMs in invisamode show up as Unknown. Have noticed this 2 times now. Can be a problem if you are actually using SEQ for anything other than a GPS (and possible even then depending on how obvious you are).


Over all it is excellent code. Kudos Maggotboy!

[Fletch]

Originally posted by learningquick
ok, Great code!

I am experiencing just a couple of issues.

1 - after several times zoning (or when I camp in and out) SEQ displays the itty bitty maps. I have to shut down SEQ and restart it to make the maps work again.


Not sure about the other issues, but this can be fixed by zooming in from 1x and SEQ doesnt need to be restarted.

Hope this helps.

[learningquick]

hehe that isnt a fix it is an anoying workaround. Sort of "microsoftish" at that ( Gpfault -- doh reboot and try again!) or live with the distorted screen that you get with a 5x zoom in.

Didnt seem to have this issue with the other keysniffer I used (I just had a problem with timing). Maybe it is an easy fix, maybe not, but the developer needs to know so he can look at it.

My grand papy used to say .. if it is broke . use bailing wire, if it aint use duct tape!

lq

[emmt33]

Great stuff maggotboy :)

a suggestion from me, albeit of little significance...

UINT GetTempFileName(
LPCTSTR lpPathName, // directory name
LPCTSTR lpPrefixString, // file name prefix
UINT uUnique, // integer
LPTSTR lpTempFileName // file name buffer
);

If uUnique is nonzero, the function appends the hexadecimal string to lpPrefixString to form the temporary file name. In this case, the function does not create the specified file, and does not test whether the file name is unique.

Would it be slightly more obfuse (i.e. such that a temp file isn't actually created) to use the value of gsh_xorby for uUnique, or maybe the return value of another GetTickCount? The following call to DeleteFile could then also be omitted. Of course there isn't then a specific uniqueness check of any kind, but it's probably implied?

Regards!

[gothopie]

if you're feeling extra paranoid, and want your sniffer to blend in as much as possible, here's a list of commonly used ports to pick from;
http://www.xploiter.com/security/ports.html

[DrgnWolf208]

Well, I can confirm that the DLL not loading is not a WinXP-only issue.
I'm running Win98, VC6 SP5.
The DLL compiles with no errors, but running rundll32 with it simply causes an error message to immediately pop up.

RUNDLL32 caused an invalid page fault in
module <unknown> at 0096:0063fe3a.
Registers:
EAX=00000000 CS=0167 EIP=0063fe3a EFLGS=00010246
EBX=81d46c8a SS=016f ESP=0063fdec EBP=00530000
ECX=ee213010 DS=016f ESI=00000000 FS=1a17
EDX=bffc9490 ES=016f EDI=00000001 GS=0000
Bytes at CS:EIP:
63 00 60 b5 f8 bf 00 00 00 00 a8 61 d6 81 00 00
Stack dump:
00000001 81d661a8 00000044 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000401 00000001 00000000

[maggotboy]

Wolf208 -- are you sure you're not doing what many have done, and calling the HookProc from RUNDLL32 instead of InstallHook?

Maggotboy

[DrgnWolf208]

Aye, that was the problem. The names I used in the DEF file got me backwards. It is working flawlessly now. Thanks!!
And awesome work, BTW! :)
-DrgnWolf208

[devnul]

Is everyone that is getting the crash on keypress using VS.NET to compile?

Is anyone using VS.NET and it works?

dn

[MisterSpock]

I have compiled this code (v2), and various homebrew variants of it on VC6 and VS.Net and they work flawlessly. The only nut I've been unable to crack is the LCC-Win32 compiler issue. It crashes with a C00000005 exception every time it picks up the global hook (keypress) and attempts to launch the relocated code.

[Ataal]

FYI, I am running version 6.0 on a WinXP home machine and I cannot even get the crash to happen on purpose. /shrug

[cmore]

Originally posted by maggotboy
cmore -- make sure the eqsniffer2.cpp file is the only .c or .cpp file in the project. The linker is telling you more than one DllMain is declared somewhere, which means you probably forgot to take out the additional files VS.NET created for your DLL project.

Maggotboy

Thanks for answering. Yes, I removed the default .cpp it created for my project: <ProjectName>.cpp and it builds and creates the .dll successfully now.

Thanks again.

[steve]

Successfully compiled with VC6.

Ran the hook, no error, assuming it's working.

Run ShowEQ, input port that the hook is sending to.

Now, half the time I zone, SEQ segfaults. The other half, it doesn't do anything.

I'm using the latest libEQ.a, and am patched up to the CVS current. The only questionable thing I changed was:

#define INJECT_OFFSET 0x04
to
#define INJECT_OFFSET 0x08

I think this is where I goofed. Does it have to be in hex?

EDIT: Changed it back to the default, and SEQ still SEGFAULTS every time I zone. Any ideas?

[steve]

Using 2.05 of the code. I editted out my cpuspeed. Below is the output of DBMON.EXE:

2712: Ignoring process attach request for C:\EQW\EQW.EXE
2532: time()-cpuSpeed:XXXXXXXX
2532: TimeGetTime-cpuSpeed: XXXXXXX
2532: Found EQ Process!
2532: Injecting code length 33792 ...
2532: Code allocated at 0x02520000
2532: Setting hook procedure...
2532: Opening global event "13A3.tmp"

SEQ still segfaults.

Additionally, is this supposed to be spammed every second? It is, for some odd reason.

D:\Documents and Settings\steve\Desktop>dbmon.exe
1780: SymMsg: LoadLibraryASymMsg: psapi.dllSymMsg: PSAPI.DLLSymMsg: C:\WINDOWS\S
ystem32\psapi.dllSymMsg: LoadLibraryA done.SymMsg: LoadLibraryASymMsg: psapi.dll
SymMsg: PSAPI.DLLSymMsg: C:\WINDOWS\System32\psapi.dllSymMsg: LoadLibraryA done.
SymMsg: LoadLibraryASymMsg: psapi.dllSymMsg: PSAPI.DLLSymMsg: C:\WINDOWS\System3
2\psapi.dllSymMsg: LoadLibraryA done. etc...

[wrk2hard]

I have it working great on Win98se.
Compiled using .net (once I pulled my head out and followed the instructions closer).
Had some problems with SEQ still not working so I renamed the seq directory and reinstalled everything. No problems since then.

Great work to Maggotboy and everyone else who has contributed here.

Thanks!

[TrackingWarrior]

Installed and compiled using win2k, with vc++ 6, works awesome, instant decodes, seq is better then before =D

thanks maggotboy, u pwn!

[ml2517]

WinXP Home SP1 & VC++ 6 SP5. Followed the instructions verbatim and it works like a charm. =)

[The Mad Poet]

Ok I've tried to get this going under a Borland compiler but it gets stuck on ONE of the assemly lines..

call $ + 5 ...

Anyone familiar enough with the differences between TASAM and MASAM to know what to change?

I'm a assembly newb =(

[MisterSpock]

Try this:

__asm
{
call next
next: pop pvmem
}

[sauron]

Steve,

My only suggestion is to do the following:

(1) Completely delete your ShowEQ code directory.

(2) Do a complete search for all occurrences of "libEQ.a"

(3) Re-verify MD5sum of libEQ.a

(4) Pull down complete CVS and re-compile.

I say this because it sounds like a problem with SEQ/libeq.a, not the sniffer. With the new libeq.a and SEQ, there is much better handling of invalid keys, so it shouldn't be crashing.

BTW, 2.05 is working 100% for me. Great job Maggotboy! This code is just fantastic!

P.S. I'm using Redhat 7.2, Visual Studio 6 C++, and EQW. I use a batch file to "start Rundll [etc]" and then it will "start EQW".

[steve]

Thanks sauron. ShowEQ doesn't segfault any longer.

When I zone, I see in ShowEQ:

Decrypting and dispatching with key: 0xXXXXXXXXXXXXXXXX

So it's definately receiving the key. Only, after it gets the key, it does nothing, no spawns appear, the zone still shows as unknown, and EQ time shows unknown. It's getting the key, but isn't doing anything.

Any ideas? I summoned a pet like we used to have to, and no luck. Zoned 7 times, nada.

[rencro]

Yea, try what Sauron just suggested...

[steve]

Erm, I did. That's why I thanked him. It solved my segfaulting problem. SEQ is getting the key, but isn't doing anything with it.

[sauron]

Well, I'm not sure what the problem could be at this point. A couple of times, I've started EQ up and the code appeared to inject okay, but SEQ wouldn't decode. I exited EQ, restarted the sniffer, started EQ, and the next time it worked fine. I think I had told ShowEQ to "Detect next client seen" which might have thrown something off too (just a shot in the dark).

Anyway SEQ is seeing you running around on the map and such, right? Only decoding is the problem now?

One suggestion that comes to mind is to use the "simple" memory sniffer, not the "stealth sniffer". Play with entering this code (from the memory sniffer) manually into SEQ using the menu option. If this works, then perhaps try the "simple" memory sniffer that sends the key via UPD. If you can prove the normal memory sniffer works (or doesn't) then this may lead you to figuring out why the stealth sniffer isn't working.

Good luck!

[showeqgratefull]

WOW, awesome code and instructions, only issue i am seeing is i cannout release the hook.

I use the ReleaseHook variable but te rundll still stays loaded..

any ideas.

I got the latest code and compiled it
in vc++6.0 and i can start up the sniffer.

not really woried, but i am wondering if i missed something...

Thanks for the code and instructions


showeqgratefull

[steve]

No, the map stays empty now too. I've changed my network setup ever since SEQ stopped working normally (before PoP), now that I think about it.

Right now, both computers are plugged into my Linksys firewall/router, instead of into the hub, and then the hub into the router. Would this be why it's not working?

[MisterSpock]

Steve,

For SEQ to work, both the EQ machine and the SEQ machine must be connected to a HUB, not a switch.

(Post should probably be in the help section)

[forrest]

I also seem to be having the same problem as Steve,

I definately recieve the key from the sniffer, but nothing appears to happen in Showeq, I have checked both libeq for the latest version and recompiled showeq with the latest version but am unsure where to go from here

any help greatly appreciated

actually not sure if it is same as steves as I get all the info from eq box ok ie gps type map info so my network setup is ok

[z26o]

Rev2.05 using MS VS.NET on W2K system - Compiles fine, but crashes to desktop on first keypress. Usually with no error message, but sometimes it give a mem address that can not be read. I am sorry I do not know how to use debugger so I can not provide much info. Rundll32 does unload though, so thats good at least! :)

Will be happy to help if you want to tell me what to look for.

-z-

[seqseq]

I compile fine. WinXP MSC++ 6.0 sp5 but I simply can't get a decode no mater what I do.

Anyone else having a problem?

Using port 32741 for UDP. Hmm.

[forrest]

Hi all,

Solved my problem, I reinstalled Redhat7.2 followed install guide etc and it worked a treat, must have been some old libeq kicking around,

/sigh oh well segmentation errors now

[steve]

It's working now like a champ.

Plugging the computer into the hub, and then the hub into the router works like a charm.

[Aurelius]

I have compiled the sniffer and SEQ but I don't know how to get the linux (Mandrake 9.0) computer to listen for then pass along to SEQ the sniff'd information. I didn't find any specific reference to this just that the sniff'd packet has to be sent to port that SEQ is listening to. What do I need to do to get SeQ listening on a particular port for the information from the sniffer?

I await your aid )

thanx in advance ))

[S_B_R]

From the Announcements forum (http://seq.sourceforge.net/showthread.php?s=&threadid=2372):
Originally posted by fee
fee (floyd) 11/05/2002
----------------------
+ ShowEQ 4.3.2

+ Bug Fixes
- player corpses will now appear as yellow boxes, not cyan +
- player corpses will now appear at the correct coordinates
- corpses will not have the extra Soandso's corpse's corpse (not working 100% but close)

+ Features and Updates
- ShowEQ can now be configured to listen on a specified port
for a decryption key, expects a udp packet with an 8 byte
payload containing the key in little endian byte order
- updated races.h, thank you Ty
- updated concolors for post 60 players

+ New Maps, Thank you Dok
- Povalor
- Powater
- Potactics
- Bothunder
- Potorment
- Pofire
- Postorms
- Poair




Explanation:

ShowEQ can now sniff a generated key packet sent by your key sniffer. See this example http://seq.sourceforge.net/showthread.php?s=&threadid=2354

The packet sent by you key sniffer should be sent to your Showeq box with a specified port, you will have best results using a destination port that is not in use by any other protocol on your network, I would recomend using ports in the range 10000 to 65000. ShowEQ defaults to port 10000 but can be configured using the Decoder menu. The packet itself MUST be UDP and the first 8 bytes of the payload MUST be the key in little endian byte order.

Showeq has little to no error handling mechanism for these key features at this time. You may encounter crashes and/or lockups if you send key packets at the wrong time. I'll be working to make the key handling sane for the next update.

Enjoy
Fee