Thread for those crashing using the V1 or V2 sniffers ... [Archive] - ShowEQ Open Source Project Message Forums

maggotboy

11-23-2002, 11:54 AM

It's too confusing to sort through the 200+ posts trying to figure out if your crash matches someone else's, so I thought I'd start a new thread for those people who're crashing in an attempt to isolate the problem and shed some light on things.

I'll begin with some basics before you post here:

1. Tell me exactly what code revision you're compiling.
2. Tell me exactly what modifications you've made to the source.
3. Tell me what compiler you're using, and what service pack.
4. I need your OS version + service packs, processor type and RAM.
5. If you're running known hooking programs like Windowblinds or DesktopX or some of the other Stardock products, I need to know.
6. Include your debug output in the message. You can't just get it from running in the debugger because the sniffer attaches to the EQ process which isn't under the debugger. To get it, download DebugView (http://www.sysinternals.com/ntw2k/freeware/debugview.shtml) from SysInternals (http://www.sysinternals.com) and run it while running the sniffer.
7. Give me the exact and full crash information as given by Windows.
8. Read all posts here before posting your crash! If nothing matches your circumstances, or the issue is unresolved, then post, but not before!

Maggotboy

maggotboy

11-23-2002, 12:06 PM

So far, the most frequent problems in the V1 and V2 code have been:

RUNDLL32 doesn't unload. Supposedly solved in V1.4 and V2.05
EQ crashes right after a keypress. Unresolved, make sure you're compiling using the latest codebase.
EQ starts dogging down after a while and eventually crashes while using the sniffer. Compiling problem, most likely, post if you're encountering this

I'll add to this list if necessary as more problems are encountered. Please note that the V2 codebase uses some potentially "unsafe" methods to inject its code into EQ's unused memory ... If you want system-compliance and maximum compatibility, use the V1 codebase. V2 is a work-in-progress.

Maggotboy

cryptorad

11-23-2002, 12:48 PM

Started compiling with 2.04

1) Problem with 2.04 and 2.05.
2) Modified source following your instructions, function names, additional garbage def's, modified offset, renamed DLL. Compiled with debug lines out until I started trying to figure this out, then put it back in. 0 errors 0 warnings (after typo repairs) I receive the same error after compiling when I only changed the DLL and function names.
3) MSVC++ 6 .. Enterprise. Loaded SP5. Basic Load no SDK's or additions. Loaded just for this compile.
4) WinXP SP1 P4 2.2G GigRAM
5) Not running any known hooking programs.
6)

Microsoft (R) Windows Debugger Version 6.1.0009.0
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\WINDOWS\system32\rundll32.exe XXXXX.DLL,XXXXX 999.999.1.103 6969 eqgame.exe 0x00778AAD0
Symbol search path is: *** Invalid *** : Verify _NT_SYMBOL_PATH setting
Executable search path is:
ModLoad: 01000000 0100a000 rundll32.exe
ModLoad: 77f50000 77ff7000 ntdll.dll
ModLoad: 77e60000 77f46000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77c10000 77c63000 C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77c70000 77cb0000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77d40000 77dcc000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77dd0000 77e5d000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 78000000 78086000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 76c90000 76cb2000 C:\WINDOWS\system32\IMAGEHLP.dll
(7e0.284): Break instruction exception - code 80000003 (first chance)
eax=00181eb4 ebx=7ffdf000 ecx=00000004 edx=77f6eb10 esi=00181eb4 edi=00181f48
eip=77f767cd esp=0006fb38 ebp=0006fc2c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77f767cd cc int 3

7) Windivll was having same/similar problem.. his output listing in other thread is...

"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
"

That is my error as well... with my exception spelled this way. ;)

8) I think I covered all the postings so far. Best I can tell.. it appears the CALLNEXTHOOKEX is the area of interest but I haven't figured out why it's not available to me yet. My USER32.dll is the updated one from the SP5.

9) I might be off base.. and this is not needed .. but.. I'm using a Microsoft Optical wheel 5 button mouse on my system. Dunno why I thought this info might be wanted.

10) In my compiler.. my listed external dependencies are "basethd.h". That's it. No header files.. no resource files.

I did edit/change my DLL name, IP etc. with these listings here. If those are required I will gladly cut/paste here if you desire.

Thank you SOO much Maggotboy.

*PS* .. I'm quite the code/compile noobie.. so.. this could likely be a very noobie problem.

Tonto

11-23-2002, 05:32 PM

1. V2.05

2. None (other than setting the project name in the def file)

3. VSC++6, no sp, base installation.

4. Win2KAS, SP3, AMD1.2GHz, 512MB RAM

5. No hook progs

6. N/A

7. N/A

I'm really just here to say that it worked. Other than the time installing and reading through the cpp instructions, cvs'ing my showeq and recompiling with the recent libEQ.a, the dll went together like a dream. Pretty colored dots in no time.

I'm set to dual-boot w/XP so I'll switch over and see how it works with that OS.

You dev folks are the shizz. I haven't seen such fervor and activity on these threads up until the end of Oct.

Anyone concerend about the free development that Sony is getting from this community? I mean, you pay them money to play the game and then go out and do all this work to stress test security measures with no billable hours. Yeah, that's probably best left for another thread. . .

Stormdvill

11-24-2002, 12:07 PM

I have the same problem as cryptorad.

WinXP P1.5 786Mb RAM & MS Optical Mouse

I had followed the instructions to the letter but to no avail :(

However an earlier version did work for me!

BTW - Nice work Maggotboy! ;)

I'll post all my info when I get home tonight.

cryptorad

11-24-2002, 06:27 PM

Do you need more information then what is posted above? If so.. can you hint me towards what you need. I'll try to provide it the best I can.

I have continued to work on this.. checking everything I can think of that might be at issue.. but have not narrowed down to anything worth reporting yet except maybe this.

If I force the continuation of the file in the windows debugger.. I get the following output.. which is additional to what I provided before..

Microsoft (R) Windows Debugger Version 6.1.0009.0
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\WINDOWS\rundll32.exe test2.dll,HookProc 192.168.1.103 eqgame.exe 0x0078AAD0
Symbol search path is: *** Invalid *** : Verify _NT_SYMBOL_PATH setting
Executable search path is:
ModLoad: 01000000 0100a000 rundll32.exe
ModLoad: 77f50000 77ff7000 ntdll.dll
ModLoad: 77e60000 77f46000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 77c10000 77c63000 C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77c70000 77cb0000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77d40000 77dcc000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77dd0000 77e5d000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 78000000 78086000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 76c90000 76cb2000 C:\WINDOWS\system32\IMAGEHLP.dll
(674.644): Break instruction exception - code 80000003 (first chance)
eax=00181eb4 ebx=7ffdf000 ecx=00000004 edx=77f6eb10 esi=00181eb4 edi=00181f48
eip=77f767cd esp=0006fb38 ebp=0006fc2c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
77f767cd cc int 3
0:000> g
ModLoad: 10000000 10011000 C:\WINDOWS\test2.dll
ModLoad: 71ad0000 71ad8000 C:\WINDOWS\System32\WSOCK32.dll
ModLoad: 71ab0000 71ac5000 C:\WINDOWS\System32\WS2_32.dll
ModLoad: 71aa0000 71aa8000 C:\WINDOWS\System32\WS2HELP.dll
Ignoring process attach request for C:\WINDOWS\RUNDLL32.EXE
ModLoad: 5ad70000 5ada4000 C:\WINDOWS\System32\uxtheme.dll
(674.644): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=43e20000 ebx=00000000 ecx=43e20000 edx=0003022c esi=7ffde000 edi=00000000
eip=77d47e7f esp=0006fee8 ebp=0006fefc iopl=0 nv up ei pl nz na po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010207
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\USER32.dll -
USER32!CallNextHookEx+4c:
77d47e7f 8b4114 mov eax,[ecx+0x14] ds:0023:43e20014=????????
*** WARNING: Unable to verify checksum for C:\WINDOWS\test2.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\test2.dll -
0:000> g
eax=77c3c7f0 ebx=00000000 ecx=77c3b9f6 edx=00000000 esi=77f7663e edi=00000000
eip=7ffe0304 esp=0006fe60 ebp=0006ff58 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
SharedUserData!SystemCallStub+4:
7ffe0304 c3 ret

Also.. I still get the exception error message and I wind up with rundll32 in the task manager. I press continue two times (marked by the 0:000>g portions). I loaded all the debug symbols to my system from MS.com because I felt the first error was referring to missing symbols for debugging only. It did not resolve the issue.

You asked for Debugview info from SysInternals ( I missed that before somehow.) I just loaded it and executed once.. and received this one message. I will be checking to see if I can get more verbose with it now.

[1348] Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE

If you can suggest any other tests.. please do.

Thanks in advance.

maggotboy

11-24-2002, 08:50 PM

Originally posted by cryptorad
Microsoft (R) Windows Debugger Version 6.1.0009.0
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\WINDOWS\rundll32.exe test2.dll,HookProc 192.168.1.103 eqgame.exe 0x0078AAD0

This is telling ... it tells me your calling rundll32.exe test2.dll,HookProc instead of rundll32.exe test2.dll,InstallHook

You'll get immediate exception errors if you call HookProc from RUNDLL32!

Maggotboy

Stormdvill

11-24-2002, 09:46 PM

OMG...thank you maggotboy for your patience. I made a poor mistake...I switched the two defines and its up...No one ever said I was smart :)

You rock!

Admatha

11-24-2002, 11:13 PM

thanks for the reply on the other thread cryptorad, before i hit the sack tonight i'm gonna try and compile this on the win98 machine i referred to in the other post, see if that makes a difference or not, thought this might be useful as the DLLs made by the other two would not run on any of the three machines, and if it's universal we might establish a better link, i'll post results as soon as i have em.

cryptorad

11-25-2002, 08:58 AM

Ayep.. that was the noob mistake I was making Maggotboy.

Your example in the comments of the source referred to the right function. I had already changed the names right off and simply called the first one in line each time. I had just gone back to unmodified code trying to minimize differences in an effort to isolate the error, and you got it right off. A little better RTFM would have served me well. ;)

All up and working great now.

Thank you very much.

troll

11-25-2002, 10:42 AM

Not sure if I ran the DebugView program right, this is all I got.

[2560] Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
[2560] Creating event handle "6.tmp"
[1660] time()-cpuSpeed:2196687
[1660] TimeGetTime-cpuSpeed: 2218778
[1660] Found EQ Process!
[1660] Injecting code length 37888 ...
[1660] Code allocated at 0x05D70000
[1660] Setting hook procedure...
[1660] Opening global event "6.tmp"

Using sniffer 2.05

For the sake of testing did not make any modifications other than change the definition file to have the project name of MyFirstDll2

Microsoft Visual C++ .NET 7.0.9466

Microsoft Windows XP Professional 5.1.2600 SP 1.0

Mobile Intel(R) Pentium(R) 4 - M CPU 2.20GHz
1GB RAM

Crash is after keypress, I can use mouse and click around for what that is worth, just whenever I hit a key, it's poof back to windows.

emmt33

11-25-2002, 03:27 PM

Hi maggotboy,

I hope this'll help you with the "unloading RunDll32" problem...

eqsniffer code (V2.05) as supplied works 100% fine under WinNT, but fails to unload RunDll32.exe in WinME...

specifically, the call to GetTempFileName fails on WinME, unless changed to the following:

GetTempFileName(_T("."), _T(""), 0, gsh_szEvent);

works fine for me with that change in :)

notsosure

11-25-2002, 10:31 PM

[1060] time()-cpuSpeed:1816069
[1060] TimeGetTime-cpuSpeed: 1844513
[1060] Found EQ Process!
[1060] Injecting code length 37888 ...
[1060] Code allocated at 0x097D0000
[1060] Setting hook procedure...
[1060] Opening global event "42.tmp"

This is what I get with version 2.05 of the dll. compiled on windows 2000 with visual studio .net. Followed the destructions perfectly and EQ crashes at the first keypress.

Hope this helps! and thanks for all your time so far

falkore

11-25-2002, 10:49 PM

[1084] Creating event handle "16.tmp"
[972] time()-cpuSpeed:1204442
[972] TimeGetTime-cpuSpeed: 1216500
[972] Found EQ Process!
[972] Injecting code length 37888 ...
[972] Code allocated at 0x098C0000
[972] Setting hook procedure...
[972] Opening global event "16.tmp"

Win2K Sp5
Sniffer 2.05
VS.NET 7.0.9492
.NET framework 1.0.3705

First keystroke dumps Eqgame.exe

Monchichi

11-25-2002, 11:17 PM

[1632] Found EQ Process!
[1632] Injecting code length 37888 ...
[1632] Code allocated at 0x09860000
[1632] Setting hook procedure...
[1632] Opening global event "75.tmp"
AgpInterfaceReleaseMemory - releasing range e1b4e228, 510 pages at e0200000
AgpInterfaceReleaseMemory - releasing range e11743c8, 110 pages at e0710000
AgpMasterDispatchPnp: IRP 0x8
AgpMasterDispatchPnp: IRP 0x8
AgpMasterDispatchPnp: IRP 0x8

When I click accept on the EULA, hit space bar on the 1st splash screen it dumps to desktop.

Compiled on WinXP, VS .NET all settings specified in the source.

devnul

11-26-2002, 04:36 PM

"GetTempFileName(_T("."), _T(""), 0, gsh_szEvent);"

Yes good catch, accd to the SDK docs using a NULL for the 2nd parameter OUGHT to blow up (dereferencing NULL looking for a string at 0x0).. but that doesn't explain how people run it fine as is on ME.. oh well I'll try this tonight.

dn

fred_phart

11-27-2002, 10:23 AM

Originally posted by emmt33

GetTempFileName(_T("."), _T(""), 0, gsh_szEvent);

works fine for me with that change in :)

I'm using WinME and had the same problems you had Emmt33. This fix took care of it, nice work and thanks!

And thanks to you Maggotboy for great work!

devnul

11-27-2002, 11:09 AM

Changing NULL to an empty string didn't do it for me, still crashing on keypress.

Still using my own homebrew out of process sniffer but would like to get hep to the jive.

Does anyone have a VS.NET project that works that they would not mind passing on so I can compare and determine what some of us are doing wrong, or at least determine we aren't? I followed the instructions meticulously all I can figure is there is something so obvious that it was not bothered to be mentioned that I am neglecting. My VS.NET compiled version fails on XP and 2k so I am inclined to believe there is some thing wrong with my compile.

dn

BlackJack

11-27-2002, 03:14 PM

1. Code source 2.05 (downloaded today).
2. Only source modifications were renaming of the project and the three exported functions.
3. Visual C++ NET.
4. Windows XP Pro, Pentium 4 1 Ghz, 512 Meg RAM.
5. No hooking programs or other wierdness.
6.
[1372] Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
[1372] Creating event handle "A.tmp"
[752] time()-cpuSpeed:996408
[752] TimeGetTime-cpuSpeed: 1016538
[752] Found EQ Process!
[752] Injecting code length 37888 ...
[752] Code allocated at 0x099B0000
[752] Setting hook procedure...
[752] Opening global event "A.tmp"

7. No crash info per se. Load Everquest, crash to desktop at first key press (though mouse does not cause problems). After three minutes, I also get the following:
[1204] In DLLCanUnloadNow

h3x

11-27-2002, 03:50 PM

Originally posted by emmt33
I hope this'll help you with the "unloading RunDll32" problem...

GetTempFileName(_T("."), _T(""), 0, gsh_szEvent);

My problems were that v1 never unloaded and v2 crashed eq after running for so long. Making this change corrected both issues.

v1 runs as predicted and v2 unloads now after the initial injection.

I am running WinME compiled with VC++6, and atm can't be more impressed with how quickly and efficient these contributions are.

kutgw kifta

cheeze69

11-27-2002, 04:48 PM

When trying to use the 2.05 code, I am still experiencing an EQ crash as soon as I press a key.

1) 2.05 code

2) No modifications at all (yet)

3) Visual Studio.NET Pro

4) Windows XP SP1 with all updates available as of today. Athlon XP1600. 1Gb of DDR RAM.

5) No hooking programs other than Norton Anti-Virus.

6)

[1876] Ignoring process attach request for C:\WINDOWS\SYSTEM32\RUNDLL32.EXE
[1876] Creating event handle "15.tmp"
[692] time()-cpuSpeed:1405065
[692] TimeGetTime-cpuSpeed: 1407669
[692] Found EQ Process!
[692] Injecting code length 37888 ...
[692] Code allocated at 0x02400000
[692] Setting hook procedure...
[692] Opening global event "15.tmp"

7) "eqgame.exe has encountered a problem and needs to close. We are sorry for the inconvenience." That's all the info provided.

EQ pukes whether I run in EQW or full-screen. Just pressing a key during the SOE self-promotion screen causes the crash.

EDIT: The old 1.2 code works just fine compiled on this machine/software, if that's of any help.

Mike

BlackJack

11-30-2002, 11:14 AM

Three days and no discussion on this thread. Does this mean that someone has figured out a fix? Or does it mean we are abandoned? :)

cheeze69

11-30-2002, 12:18 PM

I'm thinking/hoping that it's just the holidays. 3 days with no action over Thanksgiving does not seem too alarming, but I must admit I was hoping to find a miracle cure for the keypress-crash issue when I returned today :)

Mike

MisterSpock

11-30-2002, 12:59 PM

No, you have not been abandoned :)

However, I can't replicate the crashes, so it is really hard for me to work on it. I'm almost to the point where I'm ready to ask for someone to e-mail me a binary of a crashing dll. Perhaps I can see something by disassembling it and looking at the code compared to my working version.

For those that are having trouble, one thing that is helpful to narrow down the cause of the crashes is to remark out (add //) to the line that reads:

((LPINJECTSTRUCT)pvCode)->hHook = SetWindowsHookEx(WH_GETMESSAGE, (HOOKPROC)((LPBYTE)pvCode + dwOffset + dwFuncOffset), NULL, GetCurrentThreadId());

WIth this line commented out, the code will not attempt to execute the injected code. The rundll32 should drop out of the tasklist once it finds your target. It will never send a key, of course, but it should launch, and "disappear" appropriately without crashing.

Another useful trick is to point it to something other than eqgame.exe. Personally, I use iexplore.exe with an offset of 0x00400000. Open your browser, press enter, and watch the results on your SEQ box. The "key" you should get from iexplore should be 0000000300905A4B. This saves all the time wasted from repeatedly launching EQ. I've never had one fail in EQ if it works in IE.

*Typically* the problem appears to be in the injected portion of the code, although there are some who have reported problems with the global hooking routines crashing the entire system.

MisterSpock

11-30-2002, 01:13 PM

Here are some things you can try. WARNING -- these techniques are ugly as heck. If you're an experienced programmer with good tools, these will probably be unnecessary (and may even be a bit repulsive!).

If your code "works" properly with the line from my last post commented out:

1) Remove the comment from the line in question.
2) Reduce the injected code portion to nothing but declarations and a return(0);. In other words, comment out ALL the logic after the last declaration, add in a return(0); before the final bracket } and compile.

The injected code is the routine titled:
LRESULT WINAPI InternalHookProc(int nCode, WPARAM wParam, LPARAM lParam)

3) If the code crashes, comment out declarations until you find the offending one.
4) If the code does not crash, add in the two assembler lines and repeat the test. Continue until you find the culprit.

In either case, there is a very good likelihood you will find some command that absolutely SHOULD work is causing the crash (at least from my LCC experience, and some odd behavior when working out adding an offset to the code). At that time, see if you can find a different way to do the same thing.

Just some thoughts, and some things that can be tried to help isolate the problem.

BlackJack

12-01-2002, 12:49 PM

Originally posted by MisterSpock
For those that are having trouble, one thing that is helpful to narrow down the cause of the crashes is to remark out (add //) to the line that reads:

((LPINJECTSTRUCT)pvCode)->hHook = SetWindowsHookEx(WH_GETMESSAGE, (HOOKPROC)((LPBYTE)pvCode + dwOffset + dwFuncOffset), NULL, GetCurrentThreadId());

WIth this line commented out, the code will not attempt to execute the injected code. The rundll32 should drop out of the tasklist once it finds your target.

Aye, with this line commented out, EQ no longer crashes to desktop with the press of a key. Continue to point me in the right direction and I will test whatever you want me to test :)

BlackJack

12-01-2002, 01:05 PM

Originally posted by MisterSpock
If your code "works" properly with the line from my last post commented out:

Reduce the injected code portion to nothing but declarations and a return(0);. In other words, comment out ALL the logic after the last declaration, add in a return(0); before the final bracket } and compile.

If the code crashes, comment out declarations until you find the offending one.

I will use this thread to highlight the tests I am running.

1) I reduced the code portion to nothing but declarations and it STILL crashed. Am testing declarations atm.

2) Checked each declaration. It appears that the declaration:

SOCKADDR_IN addr;

is causing the crash. Doing some more messing around.

3) Commenting out the following lines allows me to compile and run without crash to desktop :) Of course the program isn't doing anything atm, but it is nice to be able to get to the login screen :)

SOCKADDR_IN addr;
addr = pinj->addr;
pinj->func_sendto(s, (char *)pinj->pvmem, sizeof(ULONGLONG), 0, (LPSOCKADDR)&addr, sizeof(SOCKADDR_IN));

These three lines are the minimum I needed to remove in order to get the DLL to compile and run.

I am stopping here, only because my coding experience is so rudimentary. Hopefully someone can pick up this ball and run with it a little.

MisterSpock

12-01-2002, 05:38 PM

So it crashes with only the SOCKADDR_IN declaration?

When this happens, which is similar to what happened with LCC's problems with ULONGLONG, a workaround will be necessary.

What I honestly don't understand yet is exactly WHY declarations of data structures (or even simply types) are causing crashes. The fact remains that virtually every exception I've seen this code throw is C0000005 (access error). It is almost like the code is either trying to create structures outside where it should, or that is somehow doesn't have appropriate access to its own space.

Elmo

12-01-2002, 06:34 PM

Just wanted to mention that I have been trying to get this code to work with the minGW gcc compiler--my thought was to introduce another compiler into the mix to increase our code diversity.

I don't have any success yet. I made some changes to things like the inline assembler code and various other declarations, and I did get it to successfully compile and build. After that I got some errors (memory access violations) when I ran it against iexplore.exe, then made some more changes and the errors went away.

However, it appears to do absolutely nothing when I run it. I brought up DebugView and there are absolutely no messages being sent, I even put some OutputDebugString statements into the very beginning of Dllmain (changed back from LibMain) and InstallHook, and even those aren't showing up so it would appear to me that it isn't even beginning execution.

I'm pretty sharp technically but I'm not a very experienced programmer so I don't know how much more headway I'll be able to make, I've tried just about everything I can think of and find with searches. Unfortunately most of the minGW/gcc DLL examples I've found are very simplistic compared to this, I had to really dig to find out how do to a shared data segment for example.

If anyone's interested I could post the modified code and see if anyone has any ideas, otherwise I might just have to give up and start using lcc.

MisterSpock

12-01-2002, 07:40 PM

Aw heck, put the code up there and I'll see what I can do to help you get it working.

What version of MinGW are you using?

Yep -- I'm now actively stumping for the title, "Patron Saint of Free C Compilers." :)

Elmo

12-01-2002, 08:07 PM

Ok cool, I'll start a new thread with the minGW code so I don't end up hijacking this one. I'll clean it up a bit first with comments to show where I made changes.

I'm using minGW 2.0.0.3, and as recommended on the website I upgraded two packages:

binutils 2.13.90.20021006-2
w32api-2.1

I'm using Cygwin version 2.249.2.5 to make my development experience a bit more unix-like, but I set up the path to make sure I'm using the minGW bin executables (e.g., gcc, dllwrap), and I made sure I was using the minGW versions of the libraries that I linked to, so I'm not sure if the Cygwin part is relevant to the end product.

Flotsam

12-01-2002, 08:51 PM

In the nicest way possible - can we stay on the subject of the thread please? This is for people who are crashing using the current V1 or V2 code, not for people experimenting with new compilers. It makes it very difficult to have a conversation when people add unrelated posts to a thread. :(

Elmo

12-01-2002, 10:47 PM

In the nicest way possible, my post *was* about my having problems with V2 code, and I specifically said I would start a new thread so as not to hijack this one. What more do you want?

Flotsam

12-01-2002, 10:57 PM

emmt33

12-02-2002, 02:53 AM

I've been trying to debug the "crash on first key press" problem in the V2.05 code compiled with .NET.

Unfortunately, I've not yet pin-pointed the problem, but this is how far I've got:

1) 'code injection' into eqgame.exe (or in my case, a small test program to make things easier) is successful, and is running ok up to the first keypress.

2) Immediately after the first keypress, eqgame.exe is still running ok.

3) Immediately after the original keyboard hook is removed (in eqsniffer.dll), eqgame is still running ok.

4) *As soon as* eqsniffer.dll (and consequently rundll32) exits, eqgame immeditely crashes with an illegal memory access. If eqsniffer.dll is left resident in memory (not recommended), eqgame doesn't crash.

Maybe there's something going wrong in the hook chains, that's causing the original keyboard hook to not be removed from the list properly? Somehow, I think that eqgame is still trying to access the dll memory space after it's been unloaded.

The only other observation, which almost certainly doesn't mean a thing, is that the injected code from a .NET compilation is bigger than for a VC6 one (of the order of some hundreds of bytes).

Sorry I can't be more help.

Flotsam

12-02-2002, 10:00 AM

Emmt32 - see BlackJack's comments. He has it narrowed down to a single declaration. Look up about 4 or 5 posts - his development platform is Win XP and VC++NET. Unfortunately, many of us do not have the ability to implement a workaround so we are waiting for help. At least we have identified the issue.

maggotboy

12-02-2002, 11:24 AM

I'm back from the Thanksgiving holidays, so I'm getting caught up on the threads and will be posting ASAP.

Maggotboy

BlackJack

12-04-2002, 09:28 AM

Hmmmmm. Three days of silence since my last note.

Is there anything else I can do to help out? I'm not able to create a workaround but I can test anything you want. The waiting is killing me. Even if someone had some suggestions I would be happy to try messing with them. I just need some code to start with. :(

IcewraithUK

12-04-2002, 09:52 AM

Okay, here's one to chew the fat over :)

Compiled on machine A, no trouble, made the recommended changes but nothing else.

Run EQ on Machine B, Keysniffer works fine, no crashing, no problems at all.

Run EQ on Machine C, crashes on keypress.

B & C are running XP Pro, both patched up. Virtually identical setups really, but one crashes and the other doesn't.

Could this be something like bios settings or hardware setup that causes this? It would be nasty if that where the case...

vylesilencer

12-04-2002, 12:41 PM

IcewraithUK : Do you have the same keyboard (interface type) on both systems? Have you installed any keyboard tsr on either system (intellitype)? I'm curious if this is a ps2 keyboard vs. USB keyboard thing..

Flotsam

12-04-2002, 01:35 PM

Also, are you using the same mouse on both PC's? Is one of them a USB mouse?

IcewraithUK

12-04-2002, 03:10 PM

Hmm, interesting idea!

Machine that works - logitech cordless USB setup. Intelli software loaded.

Machine that doesn't work - Mouse is PS2, and I think the keyboard is too.

devnul

12-04-2002, 03:31 PM

MS USB Mouse and PS/2 KB and it crahses on keypress.

had already tried killing all handlers (type32, point32, hidsrv) but that didn't help

dn

BlackJack

12-04-2002, 10:29 PM

Well I was hoping there was going to be a miracle cure here, but doesn't appear to be the case.

PS/2 Keyboard and PS/2 Mouse - crashes on first keystroke
USB Keyboard and USB Mouse - crashes on first keystroke

Any other ideas?

Flotsam

12-05-2002, 02:02 PM

Maggotboy are you out there? I was just curious if you are working on this issue and whether you needed any help. If you are working on it, I would love to hear your progress (it will help take some of the pain out of waiting :)) If you have given up, it would be nice to know so that I can look for an alternative sniffer solution :)

Flotsam

12-05-2002, 05:09 PM

I'm an idiot :)

Just wanted to post her and say that I decided to try a different compiler. So I downloaded LCC, compiled the sniffer.... and it works perfectly. This is on the exact same machine I was having the "crash to desktop on the first keyboard press" issues. So if you are stuck feel free to get LCC and take it for a spin.

Now if I had only not gone out and purchased VC++NET for $100...

Oh for the record - my machine is P4 1GHz, Windows XP Pro and originally compiled with VC++NET.

Alwayslost

12-05-2002, 06:15 PM

I will say this... Some of the crashes can be caused by items ...

I won an item last night, when I looted it it crashed SEQ... I was able to play any other toon on the account and when I went back to the toon with the item it crashed as soon and the zone finished loading...

Made no difference if the item was in my inventory or bank... still crashed. At some point I may say what the item was... but for now all I'll say is that it CAN happen... because as soon as I destroyed the item SEQ worked perfectly again afterwards......

Something to think on, and I hope it helps.

notsosure

12-05-2002, 07:36 PM

Alwayslost: I believe your message would belong in a different thread, and would be a rather important post with more information. This thread is for people having problems with the sniffer crashing EQ, Not SEQ. Now if there are specific items which cause SEQ to barf when it tries to decode, I think the devs would be intersted in what item that was.

devnul

12-06-2002, 11:13 AM

Flotsam I had already tried the LCC version.. it doesn't crash EQ but does not do anything either. No UDP packets ever get sent.

I'm over dealine on a work project so don't have time right now to debug it, maybe in a month or two.

This is most frustrating.

dn

ImNotDeadYet

12-06-2002, 02:46 PM

Compiled on: (at work)
Windows 2000 w/ SP2
Visual Studio .NET w/ Visual C++ .NET
eqsniffer Revision 2.05
followed instructions to the "T"

Run on: (at home)
Windows XP Pro

EQ crashes to desktop on first keypress

-------

I found this fix by foo mentioned here (http://seq.sourceforge.net/showthread.php?s=&threadid=2534).

BTW, I may have hit on the problem with the program kicking out right at the EULA screen. When I compiled it the first time, the dll would load but kick me out everytime I select 'accept' on the EULA screen. I went back in and double checked all the compiler settings. Apparently, the Properties->Code Generation->Basic Runtime Check was set to Both instead of default. I changed it to default and recompiled and the program works. The previous dll was 54k in size, the working dll was 46k.

I changed this, recompiled and it is now working as intended.

INDY

T.C. Jaguar

12-06-2002, 03:50 PM

Changing the Code Generation->Basic Runtime Checks to Default also fixed my crash-on-keypress problems.

Edit -- Only a debug build is working, the release build is still crashing. /bog

WinXP SP1
VS.NET
eqsniffer 2.05

tigerknight

12-07-2002, 04:40 AM

Dead on the money! I was having crash at first keypress problems when I first tried to compile the v2 2.05 code. Followed instructions explicitly to the letter. Just changed this option and recompiled and it works in a flash! Love it :] You guys are awsome (especially MaggotBoy who started this particluar piece of wizardy/voodoo code). Props to /ALL/ of you.

I haven't had a chance to test it for long duration play (6+ hours) yet, so not sure if it falls prey to any other bugs (bog down eq and eventually crash, etc) but I know this:

This fix in options for the project made it work, and right as it said - dll went from 53k to 45k.

Here's my system:

WinXP Pro (NO service pack)
v2 sniffer code 2.05
Visual Studio .NET w/ Visual C++ .NET, no service packs that I'm aware of.

With the 'both' option set below it crashed at first keypress.
Setting it to 'default' gets it working for short term tests, long duration still a question.

-------
quote:
--------------------------------------------------------------------------------
BTW, I may have hit on the problem with the program kicking out right at the EULA screen. When I compiled it the first time, the dll would load but kick me out everytime I select 'accept' on the EULA screen. I went back in and double checked all the compiler settings. Apparently, the Properties->Code Generation->Basic Runtime Check was set to Both instead of default. I changed it to default and recompiled and the program works. The previous dll was 54k in size, the working dll was 46k.
--------------------------------------------------------------------------------

I changed this, recompiled and it is now working as intended.

INDY
-------

z26o

12-08-2002, 07:47 PM

Yep that was it for me too. Seems that blank != default :confused:
Thanks guys, you rock!

z

Elifino

12-08-2002, 11:37 PM

Originally posted by T.C. Jaguar
Changing the Code Generation->Basic Runtime Checks to Default also fixed my crash-on-keypress problems.

Edit -- Only a debug build is working, the release build is still crashing. /bog

WinXP SP1
VS.NET
eqsniffer 2.05

Just wanted to say this fixed it for me as well.

devnul

12-09-2002, 02:47 PM

This solved the keypress/crash issue for me as well.

An LCC compiled version that worked for my friend on XP did not work for me on 98. No crash but no packets sent.

The VS.NET compiled version that did work with changing 'both' to 'default' works but has seemed to cause intermittent CTD.

The LCC version on XP seems to have no such problems.

Neither seem to unload. Once run, even if you run the removehook they stay resident and cause other errors. When you reboot it gives you a program not responding end task? dialog.

The VS.NET compiled version can be run once then you must reboot if you exit the game. If you just run it again it doesn't work.

dn

emmt33

12-10-2002, 05:04 AM

I've looked over this a few times, and believe there's an error in the V2.05 InjectCode function? If this is true, I don't know how the code is working so well, so apologies if I'm way out of line here.

As far as I can tell, the InjectCode function isn't taking into account the size of the INJECTSTRUCT structure properly. The 'inj' structure is copied into the space that's VirtualAlloc'd, but the alloc size doesn't include sizeof(inj). Then, the DLL code is copied into the alloc'd space, without apparently taking into account the 'inj' structure at the beginning of that same space (i.e. it appears to overwrite part of the structure, depending on the value of dwOffset) - the address being copied to should be offset by sizeof(inj). If those two things are changed, then it follows that the offset used for SetWindowsHookEx also needs to have sizeof(inj) added to it, along with a similar change to the VirtualProtect length parameter.

I've run the code both ways (i.e. original, and changed to take above into account), without any apparent difference. However, I wonder if this might be related to some of the problems that people have had?

Regards.

devnul

12-10-2002, 02:13 PM

Could you post the lines you changed?

dn

MisterSpock

12-10-2002, 06:40 PM

If the InjectStruct size is being ignored, it could potentially explain some things.

Most/All of the errors I've been able to reproduce (typically while trying to add additional functionality to the injected code) are C0000005 exceptions. C5 exceptions are "Illegal Access" -- ie. the program is attempting to read memory to which it does not have access. Interestingly enough, these exceptions often occur at declarations. This would be consistent if not enough space for one of the structures was allocated.

I'll look in to changing the allocated space to account for
sizeof(inj) and see if it changes some of the errors I've been able to produce.

devnul

12-11-2002, 11:06 AM

/cheer Mr Spock!

dn

pyrodex

12-11-2002, 03:50 PM

I had the crashing on key press issue with WinXP SP1 and VS.NET NO SPs. I made the changes in the project to the default and since then have had no issues. Played 6 hours straight lastnight with no issues what so ever. Also i must have zoned at least 100+ times and never missed a beat.

emmt33

12-12-2002, 08:20 AM

Originally posted by devnul
Could you post the lines you changed?

dn

sure - here's the modified InjectCode function with sizeof(inj) statements added in (what I think are) the right places:

// V2 - Allocates memory, injects our sniffer code into it, and gets it started.
BOOL InjectCode()
{
LPVOID pvCode;
LPVOID pvMem;
INJECTSTRUCT inj;
LPVOID pvStart;
DWORD dwLen;
MEMORY_BASIC_INFORMATION mbi;
DWORD dwOffset = MAKELONG(MAKEWORD(0, INJECT_OFFSET), 0);
DWORD dwFuncOffset;

// The start of the function we're injecting
pvStart = (LPVOID)InternalHookProc;

// Figure out how large our memory block is that contains our sniffer code.
VirtualQuery(pvStart, &mbi, sizeof(mbi));
dwFuncOffset = (DWORD)pvStart - (DWORD)mbi.BaseAddress;

// Determine the length of the code to inject, and add the size of the offset to it.
dwLen = (DWORD)mbi.RegionSize + dwOffset;

#ifdef _SNIFFDEBUG
TCHAR szMsg[MAX_PATH];
wsprintf(szMsg, _T("Injecting code length %d ...\n"), dwLen + sizeof(inj));
OutputDebugString(szMsg);
#endif

// Allocate a writeable memory block in preparation for injection ...
pvCode = VirtualAlloc(NULL, dwLen + sizeof(inj), MEM_COMMIT, PAGE_READWRITE);
if (!pvCode) return FALSE; // Failed to allocate memory

#ifdef _SNIFFDEBUG
wsprintf(szMsg, _T("Code allocated at 0x%8.8X\n"), pvCode);
OutputDebugString(szMsg);
#endif

// Get the memory address to sniff for, and de-xor it.
pvMem = gsh_pvEQKey;
xormem(&pvMem, gsh_xorby, sizeof(pvMem));

// Clear and fill out the struct with pointers to our API calls and some other useful stuff
// such as the SEQ box socket addr, the memory pointer to sniff, etc.
ZeroMemory(&inj, sizeof(inj));
inj.addr = gsh_SEQAddr;
inj.pvmem = pvMem;
inj.ullLastKey = MAXDWORD;
inj.func_VirtualQuery = (VIRTUALQUERY) GetProcAddress(GetModuleHandle(_T("KERNEL32")), "VirtualQuery");
inj.func_IsBadReadPtr = (ISBADREADPTR) GetProcAddress(GetModuleHandle(_T("KERNEL32")), "IsBadReadPtr");
inj.func_socket = (CREATESOCKET) GetProcAddress(GetModuleHandle(_T("WSOCK32")), "socket");
inj.func_sendto = (SENDTO) GetProcAddress(GetModuleHandle(_T("WSOCK32")), "sendto");
inj.func_closesocket = (CLOSESOCKET) GetProcAddress(GetModuleHandle(_T("WSOCK32")), "closesocket");
inj.func_CallNextHookEx = (CALLNEXTHOOKEX) GetProcAddress(GetModuleHandle(_T("USER32")), "CallNextHookEx");

// Write the injection struct to the beginning of the memory page.
CopyMemory(pvCode, &inj, sizeof(inj));

// Copy our DLL code into the memory page starting at the offset specified.
CopyMemory((LPBYTE)pvCode + dwOffset + sizeof(inj), mbi.BaseAddress, dwLen - dwOffset);

// Mark the code's memory to allow execution.
VirtualProtect(pvCode, dwLen + sizeof(inj), PAGE_EXECUTE_READWRITE, &dwLen);

#ifdef _SNIFFDEBUG
OutputDebugString(_T("Setting hook procedure...\n"));
#endif

// Set a hook into the message pump of the process's main thread.
((LPINJECTSTRUCT)pvCode)->hHook = SetWindowsHookEx(WH_GETMESSAGE, (HOOKPROC)((LPBYTE)pvCode + dwOffset + sizeof(inj) + dwFuncOffset), NULL, GetCurrentThreadId());

return TRUE;
}

Pascal7

12-12-2002, 09:33 AM

Just wondering...
A friend and I both live in the same city, on different ISPs. Both of us were using SEQ with the V2 sniffer. And both of us had LD at the same exact time.... Humm... Just wondering if anyone else is experiencing this? And if anyone thinks this could be an attempt to localize SEQ users?

I was thinking, maybe they are sending some code segment that they know would crash the sniffer causing LD within a min.. Then watch the server logs to see who goes LD about that time. Those accounts are flagged for further interigation attempts or just outright bannishment. Just wondering if any of the more skilled programmers see that this could be a possibility or I'm just being really parinoid?

:confused:

Dedpoet

12-12-2002, 09:42 AM

Doubful, Pascal7. If you guys both live in the same place, chances are very good that your ISP's use the same backbone. Even if they don't, at some point they're going to go through a common router somewhere. One of those router's probably hiccuped so you both LD'd. Ever been on a raid where 10 people LD at the same time? It happens all the time.

datadog

12-12-2002, 12:04 PM

Changing the Code Generation->Basic Runtime Checks to Default also fixed my crash-on-keypress problems.

This also cured my crash on keypress problems.

I have 2 WinXP Home systems. Both were crashing on keypress until I recompiled with this change.

Just an FYI...

Hades42

12-12-2002, 08:07 PM

Seems like the keypress error is caused by the default compiler setting of 8 bytes struct alignment, it's actually a quite common error when doing tricky memory stuff. Try setting the struct alignment to 1 byte.

It worked for me. In VC++6 this setting can be found under Code Generation

Hades

Nstalkerga

12-13-2002, 10:50 AM

any idea why your program doesnt seem to agree with the default microsoft telnet server on XP?

Works great with the trial add on ...
Works fine with the purchased SSH server addon (minus the fact i cant copy and paste the key until i end the SSH session).

however with the microsoft client it launch the program but never gives any terminal display results for the key... I can CTRL-C and end it but ... /shrug who knows im grasping at straws here

I know the details are sketchy and i'll fill you in on anything else that might be usefull.
but this looks like something simple....

doenst seem really related to the program.. more related to the lack of the program echoing results back to the deafult telnet server and then through to the client.