Winpcap - Having troubles sending data

Question

I'm using Tamir's SharpPCap to try to send data to my msn.

Currently, for testing purposes, my idea is to wait for any msg received by mymsn@msn.com and then send the packet itself again, that is, make any message appear repeated forever on my msn. I thought this had to work, as I am simply getting the packet itself I receive, and resending it again.

For some reason nothing appears on my msn, although I will see printed in the console a lot of "caught data, resending it". Any ideas? Thanks

class Program {
    static PcapDevice device;

    static void Main(string[] args) {
        device = SharpPcap.GetAllDevices()[0];
        device.PcapOnPacketArrival +=
                new SharpPcap.PacketArrivalEvent(device_PcapOnPacketArrival2);
        device.PcapOpen(true, 1000);
        device.PcapStartCapture();

        Console.ReadKey();
    }

    static void device_PcapOnPacketArrival2(object sender, Packet packet) {
        TCPPacket tcpPacket = packet as TCPPacket;

        if (tcpPacket == null) {
            return;
        }

        string data = Encoding.Default.GetString(tcpPacket.Data);

        if (!data.StartsWith("MSG mymsn@msn.com")) {
            return;
        }

        Console.WriteLine("caught data, resending it");

        device.PcapSendPacket(tcpPacket);
    }
}

Answer 1

One key feature of TCP is "discarding duplicate packets"

So to solve your problem with WinPcap you'll have to capture of all packets of one MSN message and resend it in new packets. Hopefully MSN won't accept that.

In that case learning how to deal with the MSN protocol could bring a solution to this problem.

CodeProject Howto: Connect_To_MSN_Messenger

Maybe this C# lib MSNP-Sharp somehow solves your problem or at least gives you a better understanding of Microsoft Notification Protocol

Answer 2

Here's my suspicion...

You're resending the packet, which I believe will make the network driver think it's received the same packet twice. That can happen in various cases, such as the first occurrence taking a while to arrive, so the sender resending in case it's got lost.

The network driver (or MSN) will then spot the duplicate and discard it - after all, it's already seen that data, so it doesn't need the redundant copy. So explicitly sending the same packet again basically has no purpose.

You've also got to consider that you're seeing one packet in a stream of data. There's no guarantee that that packet contains exactly a single command saying "here's a single message". It may end with the first bit of the next message, for example. Just inserting extra data into the stream would not only be hard, but you'd also need to understand the protocol in order to do it properly.

---

Now when you say "nothing appears on my MSN" do you mean no extra messages, or that the first message doesn't appear? If it's that you're just not getting repetition, then the above explains it. If you're effectively blocking MSN by running this program, then that's clearly somewhat different.

Answer 3

I would assume that MSN has some kind of application-level packet numbering, integrity checking, and spoof-checking. Anything else would be criminally incompetent for this kind of high-profile target.

Assume that MSN applies chained stream encryption to the packets it sends... in that case, receiving a duplicate packet will just result in garbage, as the state of the encryption algorithm will be different (the decryption of a packet sets up the decryption state for the next packet in the sequence). Thus, the duplicated packet will look like a bad packet to MSN, and it will be ignored.

So replaying packets will likely work, but MSN will make sure to ignore them at the application level. Unless you understand the MSN application-level protocol, you will not be able to duplicate messages in any simple way.

Answer 4

You cannot repeat a tcp packet and expect socket to receive it, there are order numbers on every packet. If it was UDP it would maybe work but you also can not rely on packets to represent whole message either udp or tcp.

You are working on too low level, use Layered Service providers to get between the interface and the socket, it is like implementing a protocol over TCP, there you can repeat packets, and most likely there will be no check on application side.