• Welcome to Valhalla Legends Archive.
 

Packet Help

Started by TeEhEiMaN, March 21, 2004, 12:57 PM

Previous topic - Next topic

TeEhEiMaN

Im trying to connect onto a simple hotline connect server that connects right onto an IP, so thats the easy part, but im not sure how to send the packets to simulate the connection

Alright ive downloaded a packet Sniffer "WPE Pro" and i sniffed the connecting of the bot, but I really dont understand the packets that comes up and im also not sure how to read the numbers. How would i make it so the packet works in visual basic.

So where would i get the packet if one of the packets were like
0000          54 52 54 50 48 4F 54 4C 00 01 00 02          TRTPHOTL....


Thanks

effect

I think Feanor , or someone of the like wrote an introductory tutorial to working and reading packets.

Anyways , the reason u cant understand any of that is becuase i dont think you can read Hexadecimal.
Quote from: Mangix on March 22, 2005, 03:03 AM
i am an expert Stealthbot VBScript. Recognize Bitch.

Maddox

#2
It might be nice to look at the packet buffer class DarkMinion wrote to help understand how to construct packets in Visual Basic.

That specific packet looks like 4 values; 2 dwords and 2 words in network byte order.
asdf.

Eric

#3
Quote from: TeEhEiMaN on March 21, 2004, 12:57 PM
Im trying to connect onto a simple hotline connect server that connects right onto an IP, so thats the easy part, but im not sure how to send the packets to simulate the connection

Alright ive downloaded a packet Sniffer "WPE Pro" and i sniffed the connecting of the bot, but I really dont understand the packets that comes up and im also not sure how to read the numbers. How would i make it so the packet works in visual basic.

So where would i get the packet if one of the packets were like
0000          54 52 54 50 48 4F 54 4C 00 01 00 02          TRTPHOTL....


Thanks
Might help to know what exactly Hotline is, perhaps even a link to download the client/server.
Assuming that there's password hashing involved in the connection, you're going to need to know a decent amount of ASM so that you can decompile the program to get the hash value(s) in addition to knowing a great deal about packet formatting.

Quote from: Maddox on March 21, 2004, 11:57 PM
It might be nice to look at the packet buffer class DarkMinion wrote to help understand how to construct packets in Visual Basic.
I made one a little more in-depth that that, and including detailed comments. It can be downloaded at http://chaosx.net/lord/Programming/VB/clsPacketBuffer.cls.

UserLoser.

#4
Quote from: LoRd[nK] on March 22, 2004, 12:15 AM
I made one a little more in-depth that that, and including detailed comments. It can be downloaded at http://chaosx.net/lord/Programming/VB/clsPacketBuffer.cls.

Quote
       '(BYTE) StartPacket - always 0xF7
       '(BYTE) Packet ID
       '(WORD) Packet length, including this header
       '(VOID) Packet Data

Hey, I think I submitted that on BnetDocs!! ;)

Edit: Here's my latest one which isn't complete yet (I took CupHead's idea & like it better than the other classes floating around): http://www.userloser.net/files/CPacketBuffer.cls

dxoigmn

Quote from: UserLoser. on March 22, 2004, 07:22 AM
Edit: Here's my latest one which isn't complete yet (I took CupHead's idea & like it better than the other classes floating around): http://www.userloser.net/files/CPacketBuffer.cls

You shouldn't hardcore in form names/controls (e.g. frmMain.ws*).  Should have it return a string containing the packet's contents, or pass it a Winsock control.  Personally, I prefer the former.  I remember doing this 1 function Insert/Extract thing (similar to overloading), but it gets confusing from my experience.  So I reverted back to using putDword, putWord, getDword, getWord, etc; makes code more readable, and you don't have to do things like .Insert CInt(0), rather .putWord 0.

UserLoser.

#6
Quote from: dxoigmn on March 22, 2004, 05:27 PM
Quote from: UserLoser. on March 22, 2004, 07:22 AM
Edit: Here's my latest one which isn't complete yet (I took CupHead's idea & like it better than the other classes floating around): http://www.userloser.net/files/CPacketBuffer.cls

You shouldn't hardcore in form names/controls (e.g. frmMain.ws*).  Should have it return a string containing the packet's contents, or pass it a Winsock control.  Personally, I prefer the former.  I remember doing this 1 function Insert/Extract thing (similar to overloading), but it gets confusing from my experience.  So I reverted back to using putDword, putWord, getDword, getWord, etc; makes code more readable, and you don't have to do things like .Insert CInt(0), rather .putWord 0.

This is why I don't release things to the public (and i'm sure some other people here too) - They complain and whine.  It's mine, I like it that way (like I said above), and I do it how I want and I chose to put that up just showing how I do it.  If you prefer it a different way, that's good for you.

dxoigmn

Quote from: UserLoser. on March 22, 2004, 05:31 PM
Quote from: dxoigmn on March 22, 2004, 05:27 PM
Quote from: UserLoser. on March 22, 2004, 07:22 AM
Edit: Here's my latest one which isn't complete yet (I took CupHead's idea & like it better than the other classes floating around): http://www.userloser.net/files/CPacketBuffer.cls

You shouldn't hardcore in form names/controls (e.g. frmMain.ws*).  Should have it return a string containing the packet's contents, or pass it a Winsock control.  Personally, I prefer the former.  I remember doing this 1 function Insert/Extract thing (similar to overloading), but it gets confusing from my experience.  So I reverted back to using putDword, putWord, getDword, getWord, etc; makes code more readable, and you don't have to do things like .Insert CInt(0), rather .putWord 0.

This is why I don't release things to the public (and i'm sure some other people here too) - They complain and whine.  It's mine, I like it that way (like I said above), and I do it how I want and I chose to put that up just showing how I do it.  If you prefer it a different way, that's good for you.

It's not so much that, but rather it's good coding practice.  If you plan on taking your experience to anywhere serious, then it would be best not to form bad habits.  Otherwise, do as your please.  It was constructive critisism, no need to get on the defensive.