SOME/IP security testing: what to check and why

SOME/IP security testing answers one question: which services does an ECU offer on the network, and is each one reachable only by the clients that should reach it? The protocol has no authentication of its own, so a service is protected only by where it lives on the network and by whatever extra layer the project added. Testing therefore starts by building an inventory from service discovery, comparing it against the communication matrix, and flagging anything that is offered where or to whom it should not be. Robustness testing comes after that, on the bench.

The header, as a reader needs it

A SOME/IP message begins with a 16-byte header. Reading it is what lets you interpret a capture and tell one service from another.

12 34 00 01   Message ID: Service 0x1234, Method 0x0001
00 00 00 0A   Length field
00 01 00 01   Request ID: Client ID and Session ID
01            Protocol Version
01            Interface Version
00            Message Type (REQUEST, RESPONSE, NOTIFICATION, ...)
00            Return Code

Method IDs with the top bit set (0x8000 and above) are events rather than methods. Responses carry a return code that is as useful to a tester as a UDS NRC: 0x00 E_OK, 0x02 E_UNKNOWN_SERVICE, 0x03 E_UNKNOWN_METHOD, 0x07 E_WRONG_PROTOCOL_VERSION, 0x08 E_WRONG_INTERFACE_VERSION. These codes tell you whether a service exists and is addressable before you know anything about what it does.

Step 1: build the inventory

Service discovery (SOME/IP-SD) is where the inventory comes from. ECUs announce their services with OfferService entries that carry the service ID, instance ID, major and minor version, a time-to-live and an endpoint option with the IP address, transport protocol and port. Listening to this traffic, and optionally asking for services with a FindService entry, produces a list of what is on the network:

Field	What the tester records
Service ID / Instance ID	Which service, which instance
Major / minor version	Interface version offered
Endpoint (IP, protocol, port)	Where it is reachable
TTL	How long the offer is valid

AutoST does this part passively and with active FindService, and maps the methods and eventgroups it can observe to each service.

Step 2: compare with the communication matrix

The inventory on its own is just a list. The findings appear when you lay it next to the communication matrix (the ARXML or the project’s service design) that says what each ECU is supposed to offer and to whom:

• A service that is offered but not in the matrix: an undocumented or leftover service, the SOME/IP equivalent of a hidden diagnostic service.
• A service offered on the wrong network segment: reachable from a domain or a VLAN that the design never intended, for example from an externally facing head unit.
• More methods or events than the matrix lists: an interface wider than its specification.
• A version mismatch: an ECU still offering an old interface version alongside the current one.

Step 3: check reachability and access

For each service that should be restricted, the question is whether the restriction actually holds. On the bench, confirm from which segments the service answers at all, whether it responds to a client that the design does not list as a consumer, and whether an event can be subscribed to from an endpoint that should not receive it. A service that answers E_OK from a client it was never meant to serve is an access-control finding, independent of what the method does. Where the project layered authentication or TLS on top of SOME/IP, confirm it is actually required and not merely available.

Step 4: robustness

Last, and only on the bench, comes robustness: how the service stack handles malformed headers, wrong length fields, unexpected message types and truncated payloads. The same crash and hang detection used for UDS and CAN fuzzing applies, because a service implementation that falls over on a bad header is a denial-of-service surface.

Reading the results

Observation	What it means
Service not in the matrix	Undocumented or leftover service
Service reachable from the wrong segment	Network segmentation gap
Extra methods or events offered	Interface wider than specified
Answers a client that should not reach it	Missing access control
Stack fails on a malformed message	Robustness and denial-of-service finding

Most SOME/IP findings are about reachability and configuration, not about a broken algorithm, so the fix is usually in the network design, the service configuration or the gateway rules.

How AutoST tests SOME/IP

AutoST discovers SOME/IP services passively and with active FindService, maps services, methods and eventgroups to their endpoints and scores the exposure, and runs over the same Ethernet link it uses for DoIP so the diagnostic and service findings land together. The results feed the same risk score and Fix Plan as everything else. The deeper work on individual services, the application logic behind a method and the link to safety functions stays with a penetration tester.