This is a small application that has been an exercise in the C# language by both my roommate and myself.
This is a project I don't think I'll be working on much more... as I've decided to quit playing DFC.

A quick summary... for the things you can do with this code ... is write your own Autohunter, autohealer, auto pker.
The possibilities are endless really.

Contact me on AIM @ "DFC GIR" if you have any questions or comments.
GIR Application
(formatted logging and mob parsing disabled but SIR dll still writes raw logs!)
Quick Start: download and extract the above files into your dfc directory and change your dllname=wsock32 to dllname=sir
NOTE THAT THIS APPLICATION LOGS ALL PACKETS... DFC SENDS ITS ACCOUNT AND PASSWORD IN PLAIN TEXT SO DELETE THE LOGS OR EDIT THE SOURCE SO IT DOES NOT LOG YOUR PACKETS
The information isn't being sent to anyone, just giving you a heads up.

You will need the Microsoft .Net Framwork if you intend to run the program as is.
http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en

Developers
SIR Source
GIR Source

Overview and Documentation

It is comprised of a Winsock Proxy DLL which allows you to monitor and control the packets being sent to and by the DFC Client
And a Helper Application which uses the callbacks provided by the Proxy dll to interact with the DFC Client.
Note** The reason this was structured this way was to run the app within the same process space as the DFC client
**What this means is that you can hook the DFC Window and make the application draw inside the Map window for DFC :P

The features I have gotten in so far are
*WinXP Clipboard Fix
*Boat Timer ( Notes on this below )
*Anti-Idle
*Ability to parse the monster's in room ( foundation of auto hunter )

Note on the boat timer... After logging boat arrivals and departures... I noted that the docking time varies between 9-12 seconds each time... that is to say it stays docked for 2 minutes 3 seconds sometimes... and 2 minutes 12 another... This means that you'll have to account for margin of error every rotation.

Here are some notes discovered from analyzing the packets regarding data parsing ( all the account / password / login stuff is plainly visible by the logging functions shown in the open sourced files ).

In all received packets information that is intended to update the UI is surrounded by a "boundry code" these all start with 0x80 and have been identified as follows:

9E = HP Update
9F = FP Update
A0 = PP Update

A8 - Updates all vital statistics
A4 - Experience update

A3 - Bleed ( value contained in boundry is number of rounds the bleed will last, i believe dmg is calculated off this value as well... each round varies between 9-12 seconds )

A2 - Disease
A1 - Poison - 068 = 7dmg per 9-12 seconds 058 = 6 dmg per 9-12 seconds

DE - Idol Update
D4 - Chat

Room boundries are identified as 0x81 ( preceded by 0x80 )
Format is: Roomid then a '1' as a constant ( doesn't change between realms ) then followed by n s e w ( didn't test order of the rest of the exits, simple to figure out )
and ending with all 1's as a constant... Not sure of the purpose of those.
Here's an example from the log.
ascii 0 0 4 0 2 1 0 0 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
hex-- 80 81 30 30 34 30 32 20 31 30 30 31 31 30 30 30 30 30 30 30 20 31 31 31 31 31 31 31 31 31 31 31 31 80 81

The next series of boundries has been identifed as color codes that the client uses to highlight stuff in your scrollwindow. This makes it easy to parse monsters items and players. These boundries are prefixed with 01





01 30 - termination code

01 31 - Chat

01 32 - Sends

01 33 - MOB / Enemy

01 34 - Items

01 35 - Players



Here's an example of a mob

01 boundry

33 Monster



ascii    3  a     f  a  r  m  e  r     0 

hex-- 01 33 61 20 66 61 72 6D 65 72 01 30




Here is a definition for a DFC Packet


 struct sendPacket_t {               
                                                                     
	short	header				= 0x1b1b;
                              
	short	length				= size of buffer

	short	sequence			= current sequence number;            

	short	unknown_1 			= command? 128 (0x08) for typed commands;

	short	unknown_2			= FF F2 for typed commands;                  
            
	byte	zero1				= '\0';                               

	byte	buffer[length]		= data for the buffer; first byte signifies packet type( 0x07 = F_COMMAND etc )                

	byte	zero2				= '\0';                               

	short   checksum 			= checksum generated from packet

};