Introduction

To connect the packets specified in the MembersMgmtCommAttack-parameters with the actual packets generated the attack will create a xml-file next the resulting pcap with all the information needed. The file's basename will be the same as the output-pcap's plus a "_mapping"-suffix. Also the file-extension will be changed from "pcap" to "xml". "telnet-raw-id2t.pcap" will have "telnet-raw-id2t_mapping.xml" as its mapping-file.

Mapping-XML-structure

The mapping-file contains a <mappings>-tag as root-element. It will contain several <mapping>-tags which will have a list of attributes:

• CSV_XML_Time: The time listed in the original CSV/XML-file
• Dst: The bot-id of the destination-bot of this packet, specified by the original CSV/XML-file
• Src: See above, but this time it's the source-bot
• PCAP_Time-Timestamp:
• PCAP_Time-Relative:
• PCAP_Time-Datetime: Those are the datetime of the resulting pcap-packet. All of these describe the same datetime, but in differently formatted. See the sections below.
• Type: The type of the botnet-packet as specified by the original CSV/XML-file. For an explanation of all possible values look up "MessageTypes" in MembersMgmtCommAttack.
• line_number: The line number of the packet at which the botnet-packet appears in the original CSV-file. If a XML-file was used the line-number defaults to -1. That is because XML-files were mostly created by converting a CSV-file and therefore were only temporary files which only contain one line. This and the fact that python provides no method to determine the line- and column-number while parsing incluenced the decision to not provide line-numbers for XML-files.
• mapped: A boolean indicating if the botnet-packet was mapped to a pcap-packet. This should always be "True" and a value of "False" indicates an unforseen error. At the time of writing every packet should be mapped and there is no valid reasion why this shouldn't happen.
• packet_time: A legacy attribute with the same content as PCAP_Time-Timestamp, however it only exists when mapped is "True".

Date formats

The mapping-file contains a variety of formats of the packet's timestamp. Those are the three formats used by wiresharkm, one for every kind of dateformat-lover. These are the xml-attribute-names and the corresponding formats:

1. PCAP_Time-Timestamp: The unix-timestamp format, the number of decimal digits is up to pythons internal implementation of float-to-string-conversion. An example is 944192097.3452476
2. PCAP_Time-Relative: Same format as 1., but this time all numbers are relative distances to the first packet of the pcap. A value of 3.1415926 indicates the packet appeared pi seconds after the first packet of the pcap.
3. PCAP_Time-Dateformat: A datetime formatted by ISO 8601 with the format string "YYYY-MM-DD hh:mm:ss.s". Please not that this is not UTC-format and that the number of millisecond-digits is fixed to six instead of "one or more" as specified in the standard. However it is the datetime-format that wireshark uses and this explains the odd choice. An example-date is 1999-12-03 04:34:58.354494.

Unique identification of packets

Packets in pcap-files are usually identified by their packet-number, but the pcap-file created by MembersMgmtCommAttack is a temporary pcap that will get merged into the final pcap and its package numbers will be rendered invalid. The only field that is precise enough to identify packets uniquely is the packets timestamp. Therefore this will be used as packet-ID, other suggestions are welcome.