views:

677

answers:

4

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 [email protected] 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 [email protected]")) {
            return;
        }

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

        device.PcapSendPacket(tcpPacket);
    }
}
+3  A: 

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.

Jon Skeet
Thanks for the answer. I had the same idea about it thinking its a doubled packet, but if that is true, how can windows know it? It must have some kind of hashcode or something somewhere. And I can't find that somewhere. When I say nothing appears on msn, i mean the repeated packet. The original is showing up.
devoured elysium
and i can't find that somwhere = and i can't find that property on the TcpPacket instance, i mean.
devoured elysium
It would be in the TCP header - the sequence number.
Jon Skeet
(Indeed, there's a `SequenceNumber` property in `TcpPacket`.)
Jon Skeet
I'll look into it asap (tomorrow).
devoured elysium
Um, my previous version of the answer had IP and TCP round the wrong way. Basically because this is TCP, I'm 99% sure that this is the problem.
Jon Skeet
Hello again. I still can't understand what can I do if I want to resend some packet. I mean, if anyone sends me the same message twice, it does appear twice on my msn. What property/method should I call so it generates different numbers/checksums/whatever so that windows doesnt count this packet as just a copy of the first one, but counting as a packet on itself? I've tried creating a new TCPPacket instance and setting its data property to the old one's, but then everything seems to be the same.
devoured elysium
If someone sends the same message twice, they're sending different packets, with different sequence numbers. They're legitimately putting more data into the stream... because they own the other end of the connection. You're trying to inject data into the stream, and that's *much* harder. Assuming that you can't tamper with what they send, I suspect you'll find it very hard indeed to inject extra data without screwing up the rest of their stream. If you want to do that, you basically need a man in the middle attack, where you are the endpoint of the connection (and you create another one).
Jon Skeet
+6  A: 

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

Bdiem
+1  A: 

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.

jakobengblom2
A: 

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.

M. Utku ALTINKAYA