EQExtractor and EQCollector
 

Hi,

as promised before, the source for eqextractor and eqcollector. I havent had time to make this fully working!
Both Programms run, but need a lot of work to make them usefull again!

EQEmuCollector:
The Collector is designed to use dynamic libraries to extract the collect data (currently linux only).
I haven't look at the linux build system, but it should be not so hard to do this again.
Under windows i had to modify eqemucollector.cpp to use dump_packetfiles.cpp, see line 48-51 and 213-217.
It should be possible to use dll's too, with i it of work. There are some dump modules to use look at:
dump_doors.cpp, dump_messages.cpp, dump_packet.cpp, dump_packet_header.cpp, dump_packetfiles.cpp, dump_pf_privacy.cpp
and dump_unknowns.cpp

I have modified the nic selection part! in a hackish way ;)
added
void GetAdapterList() - to make the option "-d list" working
and added line 255

You need the WinPcap sdk to compile the collector !

Usage: i think you will find out howto!

EQEmuExtractor:
Nothing special here, done so far:
- copied SoF structs, opcodes into "Current" sources
- updated the patch_Live.conf with opcodes from ShowEQ

Thats it! Have fun ;)


P.S. Sorry for my bad english!

Source

Compiles perfectly, thank you!

This is really good news.

Hi,

i forgot some files to include :( this will break zone compilation!
I will update the archive tomorrow and start to rewrite the collector.

Some goals so far: (collector)
- make it less hackish ;)
- add win32 dll support
- provide linux makefiles

I have not yet understand the sources completly, so it will take some time.

greetings Stefan

I've setup a SVN for the tools here: http://code.google.com/p/eqemutool/source/checkout

If anybody wants access, please post with your gmail address or an address tied to google.

I got some other little projects I want to tackle first, but once I got them out of the way I may try to help contribute with this project. Would love a new collector.

I compiled it fine and been tryin to use this, seems like its working but it never opens the .pf file?

D:\eqemu\tool\EQEmuTools\eqcollector\conf>eqemucol lector -d 0
Opcodes file ./opcodes.conf successfully loaded.
Sniffing on 'Realtek RTL8168C/8111C PCI-E Gigabit Ethernet NIC', net=0.0.0.0, target=
Starting live network collect.
New Stream: Server=199.108.9.80:9000, Client=192.168.1.107:49885 Detected!
Stream: Server=199.108.9.80:9000, Client=192.168.1.107:49885 Key=3f827bbd (World)
Destroying stream pair 0x112f7d8: 192.168.1.107:49885 -> 199.108.9.80:9000
New Stream: Server=199.108.15.111:1377, Client=192.168.1.107:49885 Detected!
Stream: Server=199.108.15.111:1377, Client=192.168.1.107:49885 Key=786e37b6 (Zone)
Destroying stream pair 0x112f7d8: 192.168.1.107:49885 -> 199.108.15.111:1377
New Stream: Server=199.108.9.80:9000, Client=192.168.1.107:49885 Detected!
Stream: Server=199.108.9.80:9000, Client=192.168.1.107:49885 Key=7d611c5f (World)
New Stream: Server=199.108.9.86:1351, Client=192.168.1.107:49885 Detected!
Destroying stream pair 0x1668048: 192.168.1.107:49885 -> 199.108.9.80:9000
Stream: Server=199.108.9.86:1351, Client=192.168.1.107:49885 Key=3d45ff08 (Zone)

I have a logs directory.

You have to specify the output plugin:
the collector may crash, i havent found the cause yet. Has something to do with the class initialization of PacketHandler.cpp

3 plugins are available: dump_packetfiles.dll, dump_packet_header.dll and dump_pf_privacy.dll

dump_packet_header.dll - does not work yet, it crashes. i have not looked at the cause yet.

Call it as 'eqemucollector -d 0 -p dump_packetfiles' under windows. I found the crash relating to calling it with ext that was difficult to find because attaching the debugger changed the behavior of LoadLibrary(). :roll:

I'm still trying to track down the one in stream processing with the plugin attached.

I think i have found the proplem! My LoadLibrary code is buggy
after changing
pWideStr = (PWSTR)malloc(iLength);
to
pWideStr = (PWSTR)malloc(iLength*2);

the heap corruption was gone ;) This is just a temporary fix!

Ah I see why it was so elusive then: MSdebugger loves to let heap corruption go until you try to delete an object in the corrupted heap.