Packet Length

Home Forums Discussions Support Portal Packet Length

This topic contains 9 replies, has 2 voices, and was last updated by  Vadim Smirnov 10 years, 6 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #5104

    kdub
    Participant

    Hi,

    Is the PacketBuffer.m_Length property supposed to hold the length of the entire packet or does it contain the total length of the headers (ETH,IP,TCP)?

    I am filtering for only ETH_P_IP packets and the m_Length is always 54 which appears to be the header sizes (14,20,20). I am not able to get the payload data but I can get the IP and TCP header data successfully. What is the correct way to get the length of the entire packet (ETH, IP, TCP,PAYLOAD,CHECKSUM) using the VB PassThru example?

    Thanks,

    KDUB

    #6261

    Vadim Smirnov
    Moderator

    @kdub wrote:

    Hi,
    Is the PacketBuffer.m_Length property supposed to hold the length of the entire packet or does it contain the total length of the headers (ETH,IP,TCP)?

    Yes, this is entire packet length (headers and payload).

    @kdub wrote:

    I am filtering for only ETH_P_IP packets and the m_Length is always 54 which appears to be the header sizes (14,20,20). I am not able to get the payload data but I can get the IP and TCP header data successfully.

    Believe or not, not all packets on the network are 54 bytes length and not all packets are TCP. In order to check if packet is TCP you have to check protocol field on the IP header which specifies next protocol.

    @kdub wrote:

    What is the correct way to get the length of the entire packet (ETH, IP, TCP,PAYLOAD,CHECKSUM) using the VB PassThru example?

    Read Ethernet header, check if next protocol is IP. Read IP header, check if next protocol is TCP. If it is then read TCP header and follow up data if there is any.

    #6262

    kdub
    Participant

    @SerpentFly wrote:

    @kdub wrote:

    Read Ethernet header, check if next protocol is IP. Read IP header, check if next protocol is TCP. If it is then read TCP header and follow up data if there is any.

    I am checking for TCP packets and trying to read the data but I am still unsuccessful. How can I get the original Hex dump of the entire packet using the NDISAPI.dll?

    #6263

    Vadim Smirnov
    Moderator

    'Dump packet size
    sOut = sOut & vbTab & "Packet size = " & PacketBuffer.m_Length & vbCrLf
    CopyMemory EthHeader, PacketBuffer.m_IBuffer(0), Len(EthHeader)

    The code above is taken from VB passthru sample. Here PacketBuffer.m_IBuffer array contains the entire packet, you can dump it if necessary.

    #6264

    kdub
    Participant

    Hi,

    I got the packet data finally!! Thank you for your help.

    I am now successfully intercepting the packets between two applications that communicate using TCP. Using my intercepting application, can I send a tcp request to one of the two applications by filling the Request.EthPacket.Buffer with a new packet that I create and then send it using SendPacketToMstcp or SendPacketToAdapter? Would either application be able to tell that the packet didn’t originate from the application it is connected to?

    KDUB

    #6265

    Vadim Smirnov
    Moderator

    Using my intercepting application, can I send a tcp request to one of the two applications by filling the Request.EthPacket.Buffer with a new packet that I create and then send it using SendPacketToMstcp or SendPacketToAdapter?

    Yes, you can. However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.

    Would either application be able to tell that the packet didn’t originate from the application it is connected to?

    If packet is injected properly then it won’t.

    #6266

    kdub
    Participant

    @SerpentFly wrote:

    However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.

    Can you direct me to any websites that document the shifting of the SEQ and ACK fields. Also is shifting a set incremental value or is it based on the content of the packet?

    Thanks,

    KDUB

    #6267

    Vadim Smirnov
    Moderator

    Can you direct me to any websites that document the shifting of the SEQ and ACK fields. Also is shifting a set incremental value or is it based on the content of the packet?

    I don’t think you will be able to find this sort of information anywhere. The only thing I can suggest is reading some good description of TCP protocol (by R. Stevens http://www.kohala.com/start/ an example).

    #6268

    kdub
    Participant

    @kdub wrote:

    @SerpentFly wrote:

    However, please note that injecting data into the TCP stream is not as easy as it may seem at the first look, because you should properly shift SEQ and ACK fields in your newly inserted packet and all sequent packets.

    Before I try to inject a packet into the TCP stream I thought I would check with you to see if there is another way to do what I need at the winsock level. If application 1 and application 2 are communicating via TCP using windows sockets on a set port, is there a way from my intercepting application to send a message to application 1 using Winsock so that is appears it came from application 2? I can’t figure out how to send messages using winsock using a port that is already open.
    (e.g. App1 is connected to App2 on local port 9999, I want App3 to be able to send messages to App1 using local local port 9999 as well).

    KDUB

    #6269

    Vadim Smirnov
    Moderator

    You could use LSP for this. Probably this is the most suitable solution in this case.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.