#21 Port scans are not being inserted into the target in correct time sequence

When instructing to inject a PortscanAttack, the first injected packets are correctly placed at the timestamp specified by "inject.at-timestamp" but subsequent packets are wrongly placed using the current timestamp.

To test this problem, execute the command:

./CLI.py -i test_me_short.pcap -a "PortscanAttack" ip.src="66.66.66.66" mac.src="32:08:24:DC:8D:27" inject.at-timestamp=921506778

on the attached file. (cannot attach files right now, will attach later)

@carlos.garcia I cannot confirm this behavior with the latest build on the development branch. I tried to reproduce it with one of my test files and all seems to be ok as far as I can judge it: The first attack packet has the timestamp 921506778, as specified by the attack parameter inject.at-timestamp=921506778. The timestamp of all following packets is thereafter. Please see the screenshot enclosed.

I would appreciate if you can attach the files and provide more details, so that I can reproduce it. Thanks!

@patrick.jattke I am attaching an example PCAP file which you can use to test this issue.

But hold on! I only see a JPG image... (you might have wondered) Due to the limitations of our GOGS setup, I can only upload images. So as a good software engineer, I have embedded a PCAP file into the screenshot (using steganography).

To extract the PCAP file install "steghide" (apt install steghide) and extract the file, using the passphrase "id2t", with the command

steghide extract -sf screenshot.jpg

Once you have the PCAP (named test_me_short.pcap) issue the following ID2T command to see the issue I mentioned:

./CLI.py -i test_me_short.pcap -a "PortscanAttack" ip.src="66.66.66.66" mac.src="32:08:24:DC:8D:27" inject.at-timestamp=921506778

@carlos.garcia Thanks for the details! I finally could reproduce and fix the bug (see commit a488186a79 on development branch).

Details about the bug:
The C++ module contains the method for merging pcaps, called merge_pcaps. In this method the base pcap (the input dataset) is looped and the attack packets are injected into the appropriate position.

// Go through base PCAP and merge packets by timestamp
for (; iterator_base != sniffer_base.end();) {
    //auto &packet_base = sniffer_base;
    auto tstmp_base = (iterator_base->timestamp().seconds()) + (iterator_base->timestamp().microseconds()*1e-6);
    //auto &packet_attack = sniffer_attack;
    auto tstmp_attack = (iterator_attack->timestamp().seconds()) + (iterator_attack->timestamp().microseconds()*1e-6);

    if (!all_attack_pkts_processed && tstmp_attack <= tstmp_base) {
        writer.write(*iterator_attack);
        //writer.write(packet_attack);
        iterator_attack++;

        if (iterator_attack == sniffer_attack.end())
            all_attack_pkts_processed = true;
    } else {
        writer.write(*iterator_base);
        //writer.write(packet_base);
        iterator_base++;
    }
}

However, if the base pcap has less packets than the attack packets, then not all packets might be written to the new pcap. In this case the following loop adds these packets:

// This may happen if the base PCAP is smaller than the attack PCAP
// In this case append the remaining packets of the attack PCAP
for (; iterator_attack != sniffer_attack.end(); iterator_attack++) {
    //writer.write(*iterator_attack->pdu());
    writer.write(*iterator_attack);
}

Commented out is the line introducing the bug. The method write is overloaded: If a PDU is given, the current time is used as timestamp. If a Packet is given, then the writer uses the packet's original timestamp. I had this kind of bug already earlier, but it looks like I did not make the required changes in both loops. Thanks again!