SOME/IP (Scalable service-Oriented MiddlewarE over IP)

What is SOME/IP?

SOME/IP is a remote procedure call and event protocol for ECUs connected by Ethernet. Each message begins with a 16-byte header: a message ID made of a 16-bit service ID and a 16-bit method ID (method IDs with the top bit set denote events), a 32-bit length that covers the rest of the header plus the payload, a request ID made of a client ID and a session ID, the protocol version 0x01, an interface version, a message type and a return code.

A request to service 0x1234, method 0x0001, with no payload is 12 34 00 01 00 00 00 08 00 01 00 01 01 01 00 00: length 8, client 0x0001, session 0x0001, protocol version 1, interface version 1, message type 00 (REQUEST), return code 00. A normal reply uses message type 0x80; an error reply uses 0x81, and return codes such as 0x02 (unknown service) and 0x03 (unknown method) reveal to a receiver what does and does not exist.

Where is it defined?

AUTOSAR specifies SOME/IP in its Foundation standard, in the SOME/IP protocol specification and the SOME/IP Service Discovery protocol specification, and it is implemented in both the Classic and the Adaptive Platform. There is no ISO standard for it. The threats that bear on it, spoofed messages and unauthorised access to functions, are among those listed for in-vehicle communication in UN R155 Annex 5.

What it means in practice

Because Service Discovery announces offered services to the network, the set of services an ECU exposes is visible to anything that listens. On infotainment and driver-assistance networks the recurring issues are services offered to the whole segment when a single client needs them, methods that run without checking who called, and subscriptions accepted from any address. Each of these widens what a node already on the network can do.

A SOME/IP map is therefore a good early picture of an Ethernet ECU: what it offers, to whom, and whether anything answers that should not.

How AutoST tests it

AutoST discovers SOME/IP services both passively, by listening to Service Discovery, and actively, with FindService. It maps services, methods and eventgroups to their endpoints, scores the exposure and feeds the result into the shared Fix Plan alongside the UDS, DoIP and IVI findings. It works at the service and network level and does not attack application logic behind a method, which is penetration-test work.

Common misunderstandings

SOME/IP is middleware, not a security layer, so an offered service is not a protected one. A reachable method is not automatically a vulnerability, but a method reachable by nodes that should never call it is worth a finding. And mapping services on the bench is discovery, not exploitation.