Valhalla Legends Archive

Quote from: l)ragon on December 08, 2006, 06:34 PM

Quote from: Ersan on December 08, 2006, 03:39 AM
Split clumped packets by 0xFF, or use an efficient debuffer.

Splitting by 0xFF is not a good idea, you should be processing via the packet length.

i was trying to parse using packet length, but there is "rubbish" data following some but not all packets, which presents a problem when some packets are joined together with "rubbish" data in between them.

but is there a predictable way of discarding the bytes between packets other than searching for a 0xFF or 0xF7?

The additional bytes appear to be 0, 1, 2 or 4 bytes only...

Quote from: Ersan on December 08, 2006, 03:39 AM
Split clumped packets by 0xFF, or use an efficient debuffer.

whats a debuffer?
yeh thats the method im using now... get to end of packet then look for 0xff for battle.net messages and 0xf7 for warcraft in-game messages...
theres gotta be a better way?

I have no problems dealing with the packet that comes in right after the TCP header, but,
I've noticed sometimes, 2 (or more) packets come under the one TCP header. I can't find an example with two smallish packets so I'll make one up (2x SID_PING)

(54 bytes of TCP header) FF 25 08 00 A7 30 B2 FA 10 81 FF 25 08 00 A7 30 B2 FA

I made my program find the actual data for the first packet by skipping 54 bytes, then I tried to make it find the next packet by skipping a further x bytes according to the packet length specified, but in the current example, that pointer is garbage. I can't seem to find any way of predicting it, sometimes there's no extra bytes and it works fine, but sometimes there is???

The winsock control does indeed give only the actual data, but I need to make use of WinPCap for what I'm working on, and the DLL I'm using to interface with WinPCap is handing me these extra bytes sometimes.

Any ideas?

I've had no problems dealing with packets arriving via the winsock control in VB6,
but now i'm using a packet monitor for my current project...
Here is an example of an incoming SID_PING
00 08 02 64 F5 CD 00 0D  88 ED 01 7E 08 00 45 00
00 30 54 DB 00 00 70 06  A1 E5 3F F1 53 07 C0 A8
00 67 17 E0 E7 44 BD 87  83 73 5C 76 E0 2C 50 18
FF C8 7D DF 00 00 FF 25  08 00 A7 30 B2 FA 10 81

My problem is this, there is 54 bytes of TCP header (correct?), making the actual data I want:
FF 25  08 00 A7 30 B2 FA 10 81
but that's 2 bytes too long!
Sometimes theres extra data after packets, sometimes there isn't.
Problem comes when I'm parsing multiple packets coming in under 1 TCP header and i try to skip ahead bytes according to the packet length as specified in the packet...

Is there something big I'm missing out on in the TCP protocol that says there is gonna be some bytes at the end of the packet?

The purpose of my bot is to
1. download a list of cdkeys from an internet page
2. check the availability of a cdkey (using bnls to encrypt the key)
3. 1-click cdkey changing of both warcraft 3 and frozen throne keys.

Why did I code this? sick of all my keys being in use all the time and having to change them manually.

Posting this just so people can see a (dirty) implementation of a logon sequence. I know I would have appreciated it when I made this.

I don't know how much there is by way of error catching as I never really intended this to go public.

What's needed to get it to work:
A text file containing cdkeys in pairs, a War3 key and an FT key then a War3 key then an FT key, etc, with hyphens in appropriate places and each key on a new line,  and a new line at the end of the file eg

-----------file starts below this-----------------------
ABCDEF-1234-ABCDEF-1234-ABCDEF
GHIJKL-5678-GHIJKL-5678-GHIJKL
MNOPQR-9012-MNOPQR-9012-MNOPQR
STUVWX-3456-STUVWX-3456-STUVWX

-----------file ends above this-----------------------
put this file on a webserver somewhere and change
Const sURL = "http://www.mywebserver.com/folder/keys.dat"
to point appropriately.

To change keys, put the cdkey changers (included) in the same folder as the project.

http://members.optusnet.com.au/djuhn/keychanger.zip

Ask here if you have any questions or if you want to tell me off for my dirty code.
(Possibly used the worst possible method to handle byte data, but hey, thats what you get from self teaching VB)

sorted it all out

hardcoding locations may be quick the first time you write the code but its a bitch to fix later.
(didn't take into account the fact that ver-IX86-X.mpq is 2 bytes longer, hence the crap that comes after that string should be called 2 bytes down the track as well)

thanks everyone!

That's the one... the filename...
but I just made it get the character 2 bytes after the previous location (verified that it's getting the correct value) and it's still returning a fail?
Anything else while I wade through 11 pages?

I wrote a simple application to check if a cdkey is in use or not for Warcraft 3: FT.
It was working fine for months on end, but a few weeks ago BNLS_VERSIONCHECK started returning a fail. It was working AFTER the last Warcraft patch I installed... Anyone else noticing this too? None of my code has changed and I can't for the life of me figure it out.
I will post any required info you guys may need to verify to help sort this out for me -_-

excellent... how silly of me
nice pick up thanks!

Trying to connect war3: frozen throne...

SID_AUTH_CHECK always results in status code 0x101 Invalid version...

I'm using BNLS to give me EXE version, hash and information... it all looks current, and I'm using 0x14 as the version byte...

What else could be causing the invalid version message? all the key hashing appears to be fine... and im positive i'm obeying the protocol correctly (well i'd be ip banned if not right?)

sorry if this doesnt belong here... delete/move it promptly if this is the case