SOME/IP traffic (Benign and Attack samples)

<b>Dataset Overview</b>• This repository provides a packet-capture dataset collected from a SOME/IP-based network consisting of nine ECUs.• The traffic is distributed in PCAP format (.pcap)• Communication: publish-subscribe <br><b>Normal Scenario </b>(benign_traffic.pcap)• The normal traffic was recorded under benign operating conditions.• ECUs communicate using a publish–subscribe architecture.• Upon event generation, data is dynamically delivered to subscribing ECUs.<br><br><b>Attack Scenarios</b><b>•</b><b> </b><b>Scenario name: Denial-of-Service (DoS) via Event Notification Flooding </b>(dos_noti_flood.pcap)- This DoS scenario models a malicious in-vehicle node that degrades network and ECU availability by generating an abnormally high volume of service event notifications in a short time window. Unlike stealthy attacks that attempt to mimic normal periodic behavior, the attacker prioritizes traffic amplification to induce congestion, queue buildup, and processing overload. As a result, legitimate messages may experience increased latency, jitter, or loss, and receiver-side CPU and buffer pressure can rise.• The attacker sends SOME/IP Event Notifications for: - service_id = 0x1001 - instance_id = 0x0001 - event_id = 0x0001 (carried in SOME/IP as method_id = 0x0001 for notifications) - 3000 notifications, sent as fast as possible (tight loop).<b>•</b><b> </b><b>Scenario name: Protocol Fuzzing (FUZZY) via SD OfferService/OfferEvent Identifier Flooding + Random ADAS Notifications </b>(fuzzy_sd_offer_rand_noti(1-3).pcap)- This fuzzing scenario models a malicious in-vehicle node that attempts to stress and confuse service-oriented communication by advertising a large number of randomized service/event identifiers and simultaneously emitting non-semantic event notifications. Instead of targeting a single ECU with a clean high-rate flood, the attacker primarily disrupts the service discovery and service model consistency by injecting many synthetic service instances and event definitions, which can increase discovery traffic, enlarge receiver side state, and create ambiguity for monitoring/IDS logic that expects a stable service topology.• The FUZZY attack traffic can be labeled using a union of (A) SD fuzzing offers and (B) ADAS notifications with fixed size random payload:(A) SOME/IPSD identifier fuzzing - L4: UDP destination port = 30490 (SOME/IPSD) - SOME/IP SD outer header appears as: - service_id = 0xFFFF (SD) - method_id = 0x8100 (SD) - message_type = 0x02 (Notification) - SD Entries inside payload (parse SD payload fields): - Entry type includes OfferService(B) ADAS fuzzing notifications (random payload)SOME/IP Event Notifications: - service_id = 0x1001 - instance_id = 0x0001 - event_id = 0x0001 (carried as method_id = 0x0001 for notifications) - eventgroup_id = 0x0001<br><b>Scenario name: Man-in-the-Middle via Event Relay, SD Spoofing (Withdraw), and ADAS Data Injection </b>(mitm_multi_attacker.pcap)- This scenario models an adversary that positions itself between a legitimate publisher and downstream subscribers in a SOME/IP service oriented in-vehicle network. The attacker first eavesdrops on a legitimate ADAS event stream, then relays the same payload through a malicious service to create an attacker controlled “middle hop.” In parallel, the attacker issues spoofed SOME/IP-SD control traffic that can force receivers to drop the legitimate provider (availability disruption), while it simultaneously impersonates the original service and transmits a forged ADAS notification stream. This combination yields a practical MITM behavior: observation/relay plus disruption and replacement with attackerinjected content.<br>• The traffic consists of (A) attacker relay notifications, (B) spoofed SOME/IPSD withdraw packets, and (C) forged ADAS notifications:(A) Relay stage (Attacker → subscribers): SOME/IP Event Notifications - service_id = 0x100B - instance_id = 0x000B - event_id = 0x0001 (carried as method_id = 0x0001 for notifications) - eventgroup_id = 0x0001 - Payload: byte identical copy of the legitimate ADAS event payload observed from service_id 0x1001(B) SD spoofing stage (raw UDP → victim SD port): SOME/IP-SD “withdraw” - L4: UDP destination port = 30490 (SOME/IPSD) - SOME/IP SD outer header commonly appears as: - service_id = 0xFFFF (SD) - method_id = 0x8100 (SD) - message_type = 0x02 (Notification) - SD Entry inside payload: - Entry type = OfferService (0x01) with TTL = 0x000000 (withdraw / stopoffer semantics)Advertised (withdrawn) identifiers: - service_id = 0x1001 - instance_id = 0x0001 - IP spoofing observable in PCAP: - IP.src = 172.18.0.10 (forged as “legitimate provider” in the raw packet) - IP.dst = 172.18.0.2 (victim/target in this setup)(C) Injection/impersonation stage (Attacker acting as provider): forged SOME/IP Event Notifications - service_id = 0x1001 - instance_id = 0x0001 - event_id = 0x0001 (carried as method_id = 0x0001 for notifications) - eventgroup_id = 0x0001<br><b>Scenario name: Man-in-the-Middle via SD “Withdraw” and ADAS Event Injection </b>(mitm_single_attacker.pcap)- This scenario models an adversary that interferes with a SOME/IP service oriented in vehicle network by (i) disrupting the victim’s binding to a legitimate provider using SOME/IP-SD withdraw semantics, and (ii) impersonating the original service to inject forged ADAS notifications. The attacker also listens to the legitimate ADAS stream (for visibility/triggering), but its primary effect is to force a service disconnect and then replace the expected event stream with attacker controlled content.<br>• The traffic is identified as the union of (A) SD-withdraw control packets and (B) injected ADAS notifications:(A) SOME/IP-SD withdraw (service disruption) - L4: UDP destination port = 30490 (SOME/IP-SD)SOME/IP header (SD outer header): - service_id = 0xFFFF - method_id = 0x8100 - message_type = 0x02 (Notification) - SD Entry inside payload: - Entry type = OfferService (0x01) with TTL = 0x000000 (withdraw semantics)Withdrawn identifiers: - service_id = 0x1001 - instance_id = 0x0001Options : - IPv4 endpoint address advertised: 172.18.0.10 - TCP port advertised: 30501 - UDP port advertised: 31097 - Destination (as sent in this setup):- IP.dst = 172.18.0.2, UDP.dstport = 30490(B) Forged ADAS event injection (service impersonation)SOME/IP Event Notifications: - service_id = 0x1001 - instance_id = 0x0001 - event_id = 0x0001 (carried as method_id = 0x0001 for notifications) - eventgroup_id = 0x0001<b>Test/Training set file (Used in our research)</b> - File name: tr_te_sets.tar - The related study may be published as a paper in the future, and the relevant information will be updated accordingly.