Packet Length

Home Forums Discussions Support Packet Length

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
      Keymaster

        @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
          Keymaster

            '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
              Keymaster

                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
                  Keymaster

                    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
                      Keymaster

                        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.