arXiv:2606.30564v1 [cs.CR] 29 Jun 2026
The Role of Vehicles in Digital Forensic Investigations: A Structured Synthesis of Digital Vehicle Forensic Characteristics Kevin Mayer Technische Hochschule Rosenheim June 30, 2026 Abstract Modern vehicles are cyber-physical, networked systems that may contain valuable digital traces for accident reconstruction, crime investigation, warranty analysis, and cybersecurity incident response. However, digital vehicle forensics (DVF) remains less mature than computer, mobile, and cloud forensics because relevant data is distributed across in-vehicle components, mobile devices, manufacturer back ends, thirdparty services, and physical evidence. This article addresses this gap through a structured synthesis of academic literature, standards, and practitioner-oriented sources. First, we define DVF as the identification, preservation, acquisition, verification, interpretation, and reporting of vehicle-related digital evidence under safety, legal, privacy, and forensic-soundness constraints. Second, we formalize the DVF triage problem as the selection and correlation of evidence sources subject to volatility, accessibility, safety, integrity, and authorization constraints. Third, we explain how eight characteristics were derived from the literature and case material: multiple users, massively networked, cyber-physical system, dependencies between components, functional data, safety implications, accessibility, and limited abstraction. Finally, we add an adversarial perspective and a characteristic-driven triage procedure that helps investigators prioritize evidence sources while documenting assumptions, limitations, and failure cases. The resulting contribution is not an algorithmic performance claim; it is a reproducible conceptual framework for understanding, planning, and communicating DVF investigations.
1
1
Introduction
sic evidence. This gap matters because investigators need a defensible way to decide which sources to preModern vehicles introduce a variety of digital services serve first, which evidence to correlate, and which and features, such as smartphone integration, remote assumptions should be documented. vehicle assistant applications, traffic-light communiWe addresses three research questions: cation, vehicle-to-everything communication, telema1. Which capabilities can a vehicle, its components, tics, function-on-demand services, and manufacturer and the vehicle ecosystem contribute to digital back-end connectivity. These services enlarge the atforensic investigations? (RQ1) tack surface and generate traces that may be relevant to cybersecurity, crime, warranty, insurance, and 2. What characteristics can be assigned to vehicles accident-related investigations. At the same time, inin the domain of digital vehicle forensics, and vestigators cannot assume that every involved vehicle how were those characteristics derived? (RQ2) has the capabilities of the newest vehicle generation. 3. How can the characteristics support transparent, The German Federal Motor Transport Authority readversary-aware triage of vehicle-related digital ported an average passenger-car age of approximately evidence? (RQ3) ten years in Germany in 2023 [1]. Hence, digital vehicle forensic practice must work across legacy and The contributions are: modern vehicles, manufacturers, and heterogeneous evidence sources. 1. a definition of DVF and a system-level problem Digital Vehicle Forensics (DVF) is still an emerging formulation that makes explicit the relevant variresearch area. Compared with computer forensics, ables, constraints, and assumptions; mobile forensics, cloud forensics, and industrial con2. a structured review and synthesis protocol, introl system forensics, DVF is challenged by limited cluding search dimensions, inclusion/exclusion tool availability, proprietary vehicle architectures, criteria, and a coding process for deriving charsafety-critical behavior, and the fact that vehicle data acteristics; is often collected for functional or diagnostic purposes rather than for forensic purposes [2–4]. Exist3. a comparative positioning of the work against ing research has demonstrated individual processes, the closest prior studies and a set of eight charcomponent-level acquisitions, infotainment analyses, acteristics with practical implications; event-data-recorder (EDR) studies, and vehicle assistant application investigations. However, the litera4. a characteristic-driven triage procedure, analytiture still lacks a consolidated explanation of how the cal ablation table, limitations, failure cases, and vehicle context differs from generic digital forensics adversarial/anti-forensic discussion. and how those differences can guide evidence-source prioritization. Digital Vehicle Forensics and Research gap. Prior work has largely addressed 2 one of four topics: investigation processes, in-vehicle Problem Formulation component analysis, ecosystem artifacts, or forensicreadiness tools. These contributions are valuable but 2.1 What constitutes digital forensics fragmented. What remains insufficiently articulated in a vehicular context is a characteristic-level synthesis that (i) explains the vehicular forensic context, (ii) identifies recurring Digital forensics generally concerns the identification, constraints across vehicles, components, and ecosys- preservation, acquisition, verification, analysis, intem sources, (iii) makes the derivation of such char- terpretation, and reporting of digital evidence while acteristics reproducible, and (iv) considers deliber- maintaining evidential value, integrity, and chain of ate attempts to avoid, manipulate, or degrade foren- custody [5–7]. In the vehicular context, the evidence 2
where vi is volatility, bi is accessibility, ri is safety risk of acquisition, τi is expected integrity or trustworthiness, ℓi is legal/privacy cost, and qi is expected relevance to the investigative question. These attributes are not universal constants. They are case-specific assessments that must be documented. The investigator seeks a reconstructed timeline or explanation Ĥ of the incident:
space extends beyond a single seized device. It includes the vehicle as a whole, in-vehicle electronic control units (ECUs), infotainment and telematics systems, EDRs, diagnostic interfaces, paired smartphones, vehicle assistant applications, cloud back ends, charging infrastructure, insurance and fleet platforms, and physical traces produced by the vehicle. DVF differs from generic computer forensics in three practical respects. First, many artifacts are functional rather than forensic: they were recorded for safety, diagnostics, control, warranty, or user convenience. Second, acquisition may influence safetyrelevant state, especially during live or online examination. Third, interpretation often requires translating proprietary encodings into physical meaning, for example, mapping CAN frames to speed, braking, steering, or door-state signals.
2.2
Ĥ = f (D, P, K),
D = {di | si ∈ SA },
(4)
where SA ⊆ S is the set of acquired sources and K is prior knowledge such as vehicle architecture, service documentation, physical laws, standards, and chainof-custody records. A practical triage objective can be expressed as X wi · I(di ; e) (5) max SA ⊆S
si ∈SA
subject to
System model
ri ≤ rmax , (6) Let a vehicle-related incident be denoted by e ∈ E, ℓi ≤ ℓmax , (7) such as a crash, vehicle theft, suspected manipula∆state(s , a ) ≤ ϵ , (8) i i i tion, cyberattack, hit-and-run, or disputed driver action. Let the vehicle and its ecosystem be modeled t(ai ) ≤ tmax (vi ), (9) as V = (C, N, U, E, P, T ), (1) with Equation 6 being the safety constraint, Equation 7 the authorization and privacy constraint, Equation where C = {c1 , . . . , cn } is the set of relevant com- 8 the forensic-soundness constraint, and Equation 9 ponents, N is the set of in-vehicle and external volatility constraint. communication links, U is the set of drivers, pasHere, I(di ; e) is the expected information about sengers, maintainers, remote service operators, and the incident, wi is a documented case-specific priority other users, E is the external ecosystem of phones, weight, and ∆state denotes the extent to which accloud services, infrastructure, and third-party sys- quisition changes the source. This formulation is not tems, P is the set of physical traces and constraints, intended to compute a universal optimum. It makes and T is the time base or set of time bases used by explicit the trade-offs that investigators already face: sources. evidence value must be balanced against volatility, accessibility, safety, integrity, legality, privacy, and The candidate evidence-source set is cost. S = {si | si ∈ C ∪ E ∪ P }. (2)
2.3
Core vehicular forensic challenges
Each source si may yield an artifact di if it is lawfully and technically acquired through an acquisition Isolation of connectivity. A vehicle may comaction ai . Each source is associated with attributes municate over cellular, Wi-Fi, Bluetooth, keylessentry, GNSS, V2X, diagnostic, and charging interαi = (vi , bi , ri , τi , ℓi , qi ), (3) faces. Isolation can preserve evidence by preventing 3
remote wiping, synchronization, or command execution. However, isolation can also alter the vehicle state, interrupt ongoing logging, prevent back-end acquisition, or create safety risks. DVF therefore requires explicit documentation of connectivity state, isolation actions, timing, and consequences. Data extraction. Extraction methods include diagnostic acquisition over OBD-II, Unified Diagnostic Services (UDS), Diagnostics over Internet Protocol (DoIP), USB or storage acquisition, mobile-device extraction, API-based cloud acquisition, JTAG/debug-interface acquisition, chip-off techniques, and manufacturer-assisted production. Each method differs in intrusiveness, repeatability, legal authority, and evidential risk. For example, infotainment chip-off analysis can provide rich artifacts but may be time-consuming and irreversible [16, 18]. Interpretation of vehicle-generated data. Vehicle data is often not self-explanatory. CAN messages, diagnostic trouble codes, EDR parameters, timestamps, GPS points, mobile app caches, and cloud telemetry require context. Interpretation can be undermined by proprietary data formats, undocumented signal mappings, clock drift, different time bases, sensor uncertainty, unit conversions, and missing metadata. Reverse-engineering approaches such as CAN-D demonstrate the complexity of decoding CAN data when manufacturer signal definitions are unavailable [27].
2.4
3
Review Method and Characteristic Synthesis
3.1
Review design
The work uses a structured scoping review rather than a full systematic review. The goal is to identify recurring capabilities and constraints that define DVF, not to estimate the prevalence of a phenomenon or compute pooled performance statistics. The reporting structure follows scoping-review principles by making the search dimensions, selection criteria, and synthesis process explicit [8].
3.2
Derivation of the eight characteristics
The characteristics were not copied verbatim from a single publication. They were synthesized by coding the included sources for recurring forensic capabilities and constraints, grouping similar codes, and retaining candidate groups that changed how an investigator would preserve, acquire, interpret, or validate evidence. Table 2 summarizes the resulting characteristics and explains the derivation logic.
4
Related Work and Positioning
This section reorganizes the related work into four areas and explains how the present synthesis differs from them.
Boundary conditions and assumptions 4.1
This article focuses on road vehicles and vehiclerelated digital evidence. It does not assume that all vehicles are connected, that all OEMs expose the same artifacts, or that evidence is always obtainable without manufacturer cooperation. It assumes lawful authority, a documented chain of custody, and compliance with safety requirements. It further assumes that investigators should prefer the least intrusive acquisition method that can answer the question, unless volatility or imminent loss of evidence justifies a more intrusive method.
Processes for digital vehicle forensics
Kuhlmann et al. studied how IT incidents can affect automotive safety and driver reactions [9]. Mansor discussed security, privacy, and process challenges in automotive systems, including data availability and privacy [10]. Altschaffel et al. proposed a five-step process that distinguishes strategic preparation, operational preparation, data collection, examination, and analysis [11]. Gomez Buquerin et al. proposed a generalized automotive-forensics process with forensic readiness, data collection, data analysis, and doc4
Table 1: Review and synthesis protocol used to identify capabilities and derive DVF characteristics. Element
Protocol used in this article
Academic search spaces
IEEE Xplore, ACM Digital Library, ScienceDirect, SpringerLink, Scopus/Google Scholar, and backward/forward snowballing from key DVF papers. (“vehicle” OR “automotive” OR “connected car” OR “smart vehicle”) AND (“digital forensics” OR “forensic” OR “digital evidence” OR “event reconstruction”); (“CAN” OR “OBD” OR “UDS” OR “DoIP” OR “EDR” OR “infotainment” OR “telematics”) AND (“forensic” OR “evidence”); (“vehicle assistant app” OR “vehicle cloud” OR “automotive back end”) AND (“forensic” OR “investigation”). Standards, regulation documents, practitioner material, training/tool descriptions, manufacturer-facing cybersecurity rules, and legal/practitioner discussions were considered when they clarified acquisition, admissibility, or artifact availability. They were not used as sole evidence for a characteristic unless supported by technical literature or case material. A source was included when it described a vehicle, component, or ecosystem artifact; introduced or evaluated a forensic process, method, tool, data source, architecture, or standard; or provided a technically relevant limitation for evidence acquisition, preservation, interpretation, or reporting. Sources were excluded when they discussed general automotive security without forensic relevance, contained only marketing claims, lacked sufficient technical detail, duplicated a more complete version, or addressed non-road-vehicle domains without a transferable forensic implication. Evidence source, acquisition interface, volatility, data semantics, user attribution, physical interpretation, component dependency, ecosystem dependency, safety impact, privacy/legal issue, anti-forensic risk, tool or standard dependency, and stated limitation. A candidate characteristic was retained when it appeared across multiple independent sources or when a case study demonstrated a distinct forensic action or constraint that could not be adequately explained by generic computer forensics alone.
Query families
Non-academic sources considered
Inclusion criteria
Exclusion criteria
Coding fields
Characteristic retention
umentation, and demonstrated the process through diagnostic communication with a modern vehicle [12]. These process papers clarify investigation phases but do not provide a characteristic-level taxonomy that explains why certain vehicle evidence sources behave differently from generic digital sources.
motive data types and analyses, including debugging interfaces [13]. Koscher et al. experimentally analyzed a modern automobile and showed the security implications of internal networks and controller interactions [14]. Hoppe et al. reconstructed a driven route using automotive communication data [15]. Jacobs et al. extracted artifacts from a Volkswagen infotainment system using embedded-forensics tech4.2 In-depth vehicle and component niques [16]. Vandiver and Anderson analyzed Berla investigations iVe acquisitions from Ford SYNC systems [17]. LeComponent-level studies show that DVF can recover Khac et al. showed that classical forensic tools do valuable evidence but also reveal acquisition and in- not reliably analyze all tested automotive file systerpretation barriers. Kiltz et al. investigated auto- tems, motivating DVF-specific tooling [18]. Gomez 5
Table 2: Derived characteristics and their forensic interpretation. ID
Characteristic
Definition in DVF
Why it was retained
C1
Multiple users
Recurrent user-attribution problem in infotainment, smartphone, car-sharing, assistant-app, and cloud artifacts.
C2
Massively networked
C3
Cyber-physical system
C4
Dependencies between components
C5
Functional data
C6
Safety implications
C7
Accessibility
C8
Limited abstraction
A vehicle may be used or influenced by several drivers, passengers, owners, app users, service personnel, or remote account holders. Vehicle data is distributed across internal buses, diagnostic interfaces, telematics, mobile devices, cloud services, infrastructure, and third-party platforms. Digital traces correspond to physical states and actions such as motion, braking, steering, acceleration, door state, location, or impact. Components may require other ECUs, cryptographic material, gateways, sensors, clocks, or back-end services to operate or be interpreted. Many artifacts exist for diagnostics, control, safety, warranty, or user services rather than for forensic logging. Acquisition, analysis, or manipulation may affect safety-critical systems or involve a safety-relevant incident. Vehicles and components may be physically remote, integrated, locked, encrypted, cloud-dependent, or proprietary. Compared with general IT, many vehicle artifacts lack standardized abstraction layers, logs, names, file systems, and public schemas.
Buquerin and Hof analyzed a Tesla Autopilot file system [19], and Kurachi et al. evaluated manipulation concerns for EDR data [20].
Enables physical plausibility validation and distinguishes DVF from many purely digital investigations. Affects live acquisition, bench testing, and attribution of where the same event may be recorded. Explains semantic gaps, missing forensic metadata, proprietary formats, and limited evidential context. Live analysis and reinstallation can create hazards; safety constrains forensic actions. Determines whether evidence can be acquired before volatility, overwriting, or legal delay reduces value. Necessitates reverse engineering, OEM cooperation, and careful uncertainty reporting.
mentation, and legal access mechanisms must be considered in addition to academic papers.
4.4 4.3
Recurrent need to correlate vehicle, phone, cloud, and network data; single-source analysis is often incomplete.
Vehicle ecosystem, mobile, cloud, and third-party artifacts
Forensic readiness, standards, and comparative surveys
Strandberg et al. systematically reviewed automotive digital forensics and classified challenges, data sources, communication, software, hardware, algorithms, cryptography, processes, infrastructure, and virtualization [3]. Altschaffel compared automotive, desktop-IT, and industrial-control-system forensic influence factors [2]. The Automotive BlackBox work proposed forensic requirements and a standardization-oriented architecture for automotive forensic-enabled vehicles [4]. Li et al. proposed public-auditing mechanisms for in-vehicle forensic data in connected and automated vehicles [26]. These works provide broad coverage or forensic-by-design proposals. The present article differs by deriving a compact set of characteristics and translating them
Vehicles increasingly create evidence outside the car. Attenberger identified automotive forensic data sources beyond isolated in-vehicle storage [21]. Ebbers et al. analyzed vehicle assistant applications and showed that smartphone and manufacturer back-end data can reconstruct driver activities [22]. Sumaila and Bahsi investigated automotive maintenance applications and found differences in the quantity and quality of artifacts [23]. Recent work has extended the ecosystem view to APIbased vehicle cloud acquisition and usage-based insurance data [24,25]. These studies support the “massively networked” and “accessibility” characteristics and show why industry reports, practitioner docu6
Table 3: Positioning against closest prior work. Work
Process
Altschaffel et al. [11]
✓
Gomez Buquerin et al. [12]
✓
Le-Khac et al. [18]
Component
Ecosystem
✓
✓
✓
Automotive BlackBox [4]
This article
✓
✓
✓
✓
✓
✓
✓
into triage, assumptions, adversarial risks, and failure cases.
partially
✓
partially
✓
✓
✓
Main distinction from this article Proposes a DVF process; does not derive recurring characteristics or adversarial triage implications. Demonstrates a generalized process and diagnostic acquisition; does not provide a characteristic taxonomy. Provides a smart-vehicle case study and tool challenge analysis; narrower component focus. Focuses on apps, back ends, and API acquisition; supports but does not generalize to all DVF characteristics. Broad systematic review; categories are research areas and challenges rather than investigation characteristics. Forensic-by-design architecture and requirements; this article focuses on current-investigation characteristics and triage. Defines DVF, formalizes the triage problem, derives eight characteristics, and adds assumptions, limitations, failure cases, and anti-forensic considerations.
thesized from the coded literature.
5.1
5
Adversarial
✓
Ebbers et al. [22, 24]
Strandberg et al. [3]
Taxonomy
Multiple users – C1
Characteristics of Digital Ve- Vehicles can be shared by households, employees, rental users, car-sharing subscribers, passengers, hicle Forensics maintenance personnel, remote app users, and service providers. User attribution is therefore a central DVF challenge. Infotainment systems may store paired Bluetooth devices, call logs, navigation destinations, media identifiers, contacts, or smartphoneintegration artifacts. Vehicle assistant apps and cloud services may link actions to accounts or de-
Table 4 maps representative sources to the eight characteristics. A check mark indicates that the source provides evidence, an example, or a challenge supporting the characteristic. The mapping is not a claim that each source explicitly named the characteristic; it documents how the characteristic was syn7
Table 4: Representative literature support for the eight characteristics. C1
Source Kuhlmann et al. [9] Mansor [10] Altschaffel et al. [11] Gomez Buquerin et al. [12] Kiltz et al. [13] Koscher et al. [14] Hoppe et al. [15] Jacobs et al. [16] Vandiver and Anderson [17] Le-Khac et al. [18] Gomez Buquerin and Hof [19] Sumaila and Bahsi [23] Attenberger [21] Ebbers et al. [22, 24] Kurachi et al. [20] Strandberg et al. [3]
C2
C3
C4
C5
C6
C7
C8
✓ ✓ ✓ ✓
✓ ✓ ✓ ✓ ✓ ✓
vices, while seat, climate, and profile settings may suggest but not prove individual use. For investigations, C1 means that a vehicle artifact should not automatically be attributed to the registered owner or the last known driver. A Bluetooth identifier may show that a phone was paired; it does not by itself prove who drove the vehicle at a particular time. Conversely, separating multiple users can help exclude irrelevant artifacts or identify co-offenders. The implication is that DVF reports should distinguish device attribution, account attribution, physical presence, and driver attribution.
✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓
✓ ✓ ✓ ✓ ✓ ✓ ✓
✓ ✓
✓ ✓ ✓
✓ ✓ ✓ ✓ ✓
✓
✓ ✓ ✓ ✓ ✓ ✓
✓ ✓
✓ ✓ ✓ ✓ ✓ ✓
✓ ✓ ✓ ✓ ✓ ✓
✓ ✓
✓
✓
✓
hicle diagnostic interface [12]. We also performed an illustrative network scan of a Tesla Model X by connecting to the internal WLAN and scanning IPv4 endpoints and ports. The scan identified 96 IPv4 endpoints and showed dominant TCP and TLS traffic; the protocol hierarchy is given in Appendix A. This example is not a statistically representative dataset. Its purpose is to illustrate the internal networked nature of a modern vehicle and to motivate why triage and correlation are needed. Networked evidence can also exist outside the vehicle. Shodan queries have been used to identify exposed vehicle-connected services, such as electricvehicle chargers and GPS-tracker interfaces [29]. 5.2 Massively networked – C2 From a forensic viewpoint, C2 requires investiVehicles are networked internally and externally. In- gators to decide whether the vehicle, paired deternal buses and gateways connect ECUs, infotain- vices, cloud services, infrastructure, or third-party ment, telematics, comfort systems, safety systems, providers should be preserved first. and diagnostic interfaces. External links may include cellular connectivity, Wi-Fi, Bluetooth, GNSS, 5.3 Cyber-physical system – C 3 V2X, manufacturer back ends, charging infrastructure, insurance platforms, and third-party services. Vehicles are cyber-physical systems because digital The global sale of vehicles with embedded telema- states correspond to physical behavior. Speed, braktics increased substantially during the 2010s [39], ing, steering angle, acceleration, seat-belt state, imand vehicle-centric connected services have been pro- pact events, door state, and geolocation are not jected as economically significant [40]. merely software variables; they describe physical acThis characteristic enables correlation across tions and constraints. This property enables plausisources but creates a data-volume and data-location bility checks that are not available in many purely challenge. Gomez Buquerin et al. found more than digital investigations. For instance, an EDR report 100 logical addresses reachable through a modern ve- showing a physically impossible acceleration profile 8
Delta-V (km/h) should be treated as suspect or at least requiring explanation. Time (ms) 0 The cyber-physical character also creates interpre0 50 100 150 200 250 tation risk. A sensor value may be valid but misin-10 terpreted if units, sampling intervals, coordinate systems, or event triggers are misunderstood. Nilsson -20 and Larson emphasized the value of combining physical and digital evidence in vehicle environments [28]. -30 EDR studies show that vehicle speed, brake state, accelerator pedal state, and related parameters can support reconstruction, but the trustworthiness of such Figure 1: Recreated longitudinal delta-V plot from a Tesla Model 3 EDR-style report. The figure ildata must still be assessed [20, 30, 31]. lustrates functional data that can support physical 5.4 Dependencies between compo- plausibility checks but requires contextual interpretation.
nents – C4
Vehicle components may depend on other components, gateways, clocks, cryptographic material, sensors, or manufacturer services. A removed ECU may not boot or may not expose data without the correct harness, gateway, immobilizer state, time source, or security access. Hardware-in-the-loop systems can simulate some dependencies for testing and acquisition, but they are not always available to forensic laboratories [32]. For investigations, C4 affects both acquisition and interpretation. A diagnostic trouble code in one ECU may be caused by a fault or manipulation elsewhere. A telematics unit may hold data whose meaning depends on cloud synchronization. A component dependency may also provide corroboration: if several controllers observed the same event, their timestamps and state changes can be compared.
5.5
quirements, data formats, integrity properties, and standardized extraction paths [4, 26]. Figure 1 shows a recreated, readable version of an EDR-style longitudinal delta-V plot. Such data can support crash reconstruction, but it does not necessarily explain intent, cyberattack causality, or user identity. Functional data must therefore be translated into forensic propositions with appropriate uncertainty.
5.6
Safety implications – C6
DVF may concern safety-relevant incidents, and forensic actions may themselves affect safety. Live acquisition from a running vehicle can change timing, bus load, controller state, or driver information. Kuhlmann et al. showed that IT-related incidents can influence automotive safety, highlighting the interaction between cybersecurity and safety [9]. Consequently, investigators should avoid live actions on an operating vehicle unless the safety case is understood and documented. Post-mortem acquisition also has safety implications. If a component is removed, powered externally, altered, or reinstalled, its correct operation must be considered. This is especially important for safetycritical components and for vehicles that may later be returned to service.
Functional data – C5
Most vehicle data is collected for functional reasons: diagnostics, safety, control, warranty, maintenance, user convenience, or service delivery. Standards such as ISO 26262 address functional safety [33], while UNECE Regulation No. 155 and ISO/SAE 21434 address cybersecurity management and engineering [34, 35]. These standards and regulations do not by themselves provide a complete forensic logging standard for all vehicle artifacts. Recent forensic-bydesign proposals therefore argue for additional re9
5.7
Accessibility – C7
Vehicles are usually not in forensic laboratories. They may be at crash scenes, private homes, dealerships, impound lots, repair shops, or remote locations. Components may be physically difficult to access, encrypted, locked behind secure gateways, or dependent on OEM cooperation. Volatile memory, cloudretention windows, and synchronization behavior can make delay harmful. Chip-off and embedded acquisition can recover data but may be destructive or irreversible [16, 18]. Practitioner sources show that vehicle forensic work often requires disassembly, specialist tools, and training [37, 38]. The implication is that DVF planning must document what was accessible, when it was accessible, why more intrusive methods were or were not used, and how volatility was mitigated.
5.8
Limited abstraction – C8
Algorithm 1 Characteristic-driven DVF triage Require: Incident question e, candidate sources S, constraints (rmax , ℓmax , ϵ, tmax ), characteristic set C1 . . . C8 Ensure: Prioritized acquisition plan PA and documented assumptions 1: Preserve the scene; record time, power state, connectivity state, odometer, visible damage, and legal authority. 2: Identify candidate vehicle, component, mobile, cloud, infrastructure, and physical sources S. 3: for all si ∈ S do 4: Assign documented attributes αi = (vi , bi , ri , τi , ℓi , qi ). 5: Mark applicable characteristics Cj (si ), j ∈ {1, . . . , 8}. 6: Exclude or delay si if safety risk, legal authority, or state-change constraints are not satisfied. 7: Estimate priority from relevance, volatility, accessibility, integrity, and corroboration value. 8: end for 9: Acquire sources in priority order using the least intrusive method that can answer the question. 10: Verify integrity by hashing, chain-of-custody records, tool validation, and repeatability when possible. 11: Correlate artifacts across users, time bases, components, ecosystem sources, and physical constraints. 12: Identify contradictions, missing sources, antiforensic indicators, and assumptions. 13: Report Ĥ with evidence, uncertainty, limitations, and alternative explanations.
Unlike general-purpose computers, vehicles often lack standardized forensic abstractions such as uniform logs, stable file paths, public schemas, and consistent time sources. Frameworks such as AUTOSAR and automotive-grade Linux provide abstraction for development, but they do not guarantee forensic access or uniform evidence semantics across manufacturers and components. Proprietary CAN signal definitions are a clear example: without manufacturer mappings, raw traffic may be hard to interpret [27]. C8 requires investigators to report uncertainty. A decoded signal, inferred user action, or reconstructed route should be linked to the method used, its validation status, and its limitations. Where reverse engineering is required, reproducibility and peer review is not a classifier or signal-processing algorithm; nevbecome especially important. ertheless, the characteristics can be operationalized as a reproducible triage procedure. Algorithm 1 conthe characteristics into a documented evidence6 Characteristic-Driven Triage verts source prioritization workflow.
Procedure
6.1
Complexity and scalability
Reviewer feedback requested clearer algorithmic structure, assumptions, complexity, ablation, and pa- Let n = |S| be the number of candidate sources, rameter justification. The contribution of this article m = 8 the number of characteristics, and k the num10
Table 5: Characteristics and practical use in investigations. ID
Characteristic
Practical application
C1
Multiple users
C2
Massively networked
C3
Cyber-physical system
C4
Dependencies between components
C5
Functional data
C6
Safety implications
C7
Accessibility
C8
Limited abstraction
Separate device, account, passenger, and driver attribution; avoid assuming that vehicle ownership equals driver identity. Preserve and correlate vehicle, phone, cloud, infrastructure, and network traces; handle big-data and jurisdictional issues. Validate digital evidence against physical constraints such as speed, acceleration, braking, location, and impact dynamics. Account for component dependencies during bench testing, live acquisition, and cross-controller corroboration. Translate diagnostic, safety, warranty, or service data into forensic propositions while documenting semantic uncertainty. Avoid acquisition actions that can create hazards; document safety cases for live analysis and component reinstallation. Prioritize volatile or remote sources; document why inaccessible, encrypted, cloud-dependent, or intrusive sources were not acquired. Use reverse engineering, OEM cooperation, validation, and uncertainty reporting when standard abstractions are absent.
ber of artifact records acquired from a source after parsing. Characteristic annotation is O(nm), which is linear in the number of sources because m is fixed. Pairwise correlation across sources is O(n2 k) in the naive case, but practical investigations reduce this by filtering on time windows, event type, location, and relevance. Memory cost is O(nk) for artifact metadata, excluding raw forensic images. The framework therefore scales conceptually with the number of sources and artifacts, not with model hyperparameters.
6.2
Metric selection and validation rationale
DVF triage should not be evaluated only by speed. Useful evaluation dimensions are: (i) coverage of plausible evidence sources, (ii) preservation of volatile data, (iii) integrity and repeatability of acquisition, (iv) corroboration across independent sources, (v) safety risk, (vi) privacy/legal proportionality, and (vii) explanatory value for the incident question. These metrics align with forensic goals rather than machine-learning accuracy. The Tesla network scan and EDR plot in this article are illustrative case material; they are not a dataset for statistical perfor11
mance claims. Consequently, mean, variance, confidence intervals, runtime benchmarks, noise-injection results, and hyperparameter sensitivity plots are not reported. Future empirical studies should evaluate these dimensions across multiple manufacturers, model years, and incident types.
6.3
Analytical ablation
Because the contribution is a characteristic framework, the appropriate ablation is analytical: what investigative capability is lost if a characteristic is ignored? Table 6 summarizes the effect of omitting each characteristic.
6.4
Parameter selection and reproducibility
Algorithm 1 contains case-specific priorities rather than universal hyperparameters. If an organization assigns numerical weights to relevance, volatility, safety, or accessibility, those weights should be justified in the case file and sensitivity should be checked by re-ranking sources under plausible alternative weights. For reproducibility, investigators should retain: search warrants or legal authority,
Table 6: Analytical ablation: effect of ignoring each characteristic. Omitted
Likely loss
Example consequence
C1
Weak user attribution
C2
Incomplete source coverage
C3
No physical plausibility check
C4
Misinterpreted component evidence
C5
Overstated semantics
C6
Unsafe acquisition
C7
Lost volatile or remote evidence
C8
Undocumented uncertainty
A paired phone is treated as driver proof without considering passengers or account sharing. Cloud, app, infrastructure, or diagnostic data is missed even though it could corroborate the vehicle. Implausible speed, acceleration, or location data is accepted without validation. A fault in one ECU is analyzed without considering gateway, clock, or sensor dependencies. Diagnostic or functional data is interpreted as direct evidence of intent or cyberattack causality. Live examination interferes with safety-relevant systems or reinstallation occurs without validation. Cloud retention windows, volatile memory, or inaccessible components are not prioritized. Reverse-engineered signals or proprietary formats are reported as if they were standardized logs.
tool versions, acquisition commands, vehicle state, The adversarial view changes the evidential stanconnectivity state, time synchronization notes, hash dard. It is not sufficient to show that a data item exvalues, parsed-artifact schemas, reverse-engineering ists; the investigator must ask how it could have been notes, and reasons for excluding sources. created, deleted, altered, or misinterpreted. Countermeasures include early preservation, independent corroboration, physical plausibility checks, tool vali7 Adversarial Perspective and dation, hash-based integrity verification, documentation of acquisition side effects, and explicit reporting Anti-Forensics of uncertainty. DVF cannot assume that evidence is passively produced and preserved. A driver, owner, attacker, in8 Discussion, Limitations, and sider, or remote service operator may try to prevent collection, manipulate artifacts, or create misleading Failure Cases traces. Automotive security studies demonstrate that remote and local compromise of vehicle systems is re- 8.1 Generalization of the characterisalistic [14, 41, 42]. EDR-focused research also shows tics that crash-related data can be a target for manipulation [20]. The Automotive BlackBox paper explic- No single characteristic is unique to vehicles. Multiitly motivates forensic-by-design partly because vehi- ple users exist in smart homes, networked evidence cle attacks may erase or tamper with evidence [4]. exists in cloud and IoT systems, and cyber-physical 12
Table 7: Adversarial and anti-forensic considerations in DVF. Anti-forensic tactic
Vehicle manifestation
Evidence deletion or reset
Infotainment factory reset, mobile-app cache deletion, removal of paired devices, cloud-token revocation. Disconnecting telematics, SIM removal, RF shielding by suspect, GNSS jamming or spoofing, disabling Bluetooth/Wi-Fi. CAN injection, diagnostic abuse, replayed UDS sessions, spoofed sensor states.
Connectivity manipulation
Message injection or replay
Firmware or configuration tampering
Clock and timestamp manipulation
Data poisoning through user behavior
Physical destruction or access denial
Affected characteristics C1 , C2 , C5 , C7
C2 , C3 , C7
C2 , C3 , C4 , C6
ECU reflashing, unauthorized coding changes, modified telematics or infotainment firmware. Incorrect vehicle clock, app clock drift, inconsistent cloud/vehicle time bases.
C4 , C5 , C6 , C8
Phone swapping, account sharing, deliberate route creation, fake GPS apps, staged trips. Damaged ECUs, removed memory, destroyed phone, vehicle inaccessible at private or remote location.
C1 , C2 , C3
constraints exist in industrial control systems. The contribution is the combination of all eight characteristics in the vehicle context. A modern vehicle can be a shared consumer object, a safety-critical cyberphysical system, an embedded network, a cloudconnected service platform, and a proprietary diagnostic environment at the same time. This combination explains why direct transfer of computer-forensic processes is insufficient.
The characteristics are expected to apply broadly to modern vehicles, but not uniformly. A legacy vehicle may provide limited telematics or app data, reducing C2 and ecosystem evidence. A highly centralized software-defined vehicle may reduce some component dependencies but increase cloud, account, and software-update dependencies. Therefore, the characteristics should be treated as prompts for investigation rather than as assumptions that every vehicle contains every artifact. 13
C2 , C5 , C8
C6 , C7
8.2
Forensic response Acquire volatile and ecosystem sources early; request back-end data; compare phone, vehicle, and cloud traces. Document connectivity state; preserve logs from multiple time bases; compare GNSS with physical route and external sources. Correlate multiple ECUs; inspect diagnostic session traces; validate physical plausibility and timing consistency. Preserve firmware versions, signatures, calibration identifiers, update logs, and OEM records. Establish time offsets; compare independent clocks; report uncertainty and time-window assumptions. Separate account, device, and driver attribution; correlate with physical evidence and independent ecosystem records. Prioritize less fragile sources, obtain legal authority promptly, use manufacturer or cloud records where available.
Practical implications
The characteristics help investigators prioritize work. In a robbery involving a vehicle, C1 directs attention to user attribution; C2 expands the source list to phone, cloud, tolling, charging, and infrastructure records; C3 supports route plausibility; C5 prevents overclaiming diagnostic data as intent; and C7 highlights retention and access windows. In a suspected vehicle cyberattack, C4 , C6 , and C8 emphasize component dependencies, safety constraints, and reverseengineering uncertainty.
8.3
Failure cases and boundary conditions
DVF may underperform or fail when no relevant digital source exists, when sources have been overwritten, when cloud retention has expired, when legal authority does not permit access, when encryption prevents acquisition, when manufacturer cooperation is
unavailable, or when physical damage destroys storage. Interpretation can fail when proprietary encodings are unknown, clocks are inconsistent, or multiple plausible drivers and devices fit the evidence. Antiforensic actions such as factory resets, fake GPS applications, remote wiping, or firmware tampering can further reduce confidence.
forensic triage problem, clarifying the review protocol, explaining how the eight characteristics were derived, comparing the work with close prior studies, and adding adversarial, limitation, and failurecase analysis. Vehicles can contribute valuable evidence through in-vehicle components, physical behavior, user interactions, diagnostic systems, mobile applications, cloud services, and infrastructure. However, this evidence is constrained by user attribution, 8.4 Limitations networking, cyber-physical semantics, component deThis article has four main limitations. First, the re- pendencies, functional data, safety, accessibility, and view is a structured scoping review and not a full sys- limited abstraction. Treating these as explicit charactematic literature review with exhaustive database teristics helps investigators plan acquisitions, explain counts. Second, the Tesla Model X network scan uncertainty, identify missing sources, and communiand EDR-style plot are illustrative; they do not sup- cate findings in a more defensible way. port statistical claims about all manufacturers, model years, or configurations. Third, practitioner literature, industry reports, and legal cases can be important in DVF but are not always public, technically detailed, or peer reviewed. Fourth, the framework does not implement an automated parser, classifier, or detector; therefore, empirical ablation, runtime benchmarks, noise-injection experiments, and hyperparameter plots are outside its claim boundary. These omissions are not hidden; they define the scope and motivate future empirical work.
8.5
Future work
Future research should test the characteristics across multi-OEM datasets, controlled acquisition settings, and realistic adversarial scenarios. Useful studies would include controlled clock-skew experiments, data-loss and noise perturbation, back-end retention comparisons, safety-case analysis for live acquisition, and validation of characteristic-driven triage against completed case studies. Standardized artifact schemas, forensic-by-design logging, and public benchmark datasets would improve reproducibility and allow statistical validation.
9
Conclusion
This article revised and strengthened the contribution by defining DVF, formalizing the vehicle14
Table 8: Protocol hierarchy of the illustrative Nmap scan with a Tesla Model X. Protocol Ethernet Internet Protocol Version 4 User Datagram Protocol Network Time Protocol NetBIOS Name Service NetBIOS Datagram Service SMB (Server Message Block Protocol) SMB MailSlot Protocol Microsoft Windows Browser Protocol Multicast Domain Name System Domain Name System Data Transmission Control Protocol Transport Layer Security NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol Microsoft Windows Lanman Remote API Protocol Hypertext Transfer Protocol Online Certificate Status Protocol Data Internet Control Message Protocol Data Address Resolution Protocol
A
Illustrative Nmap Scan
Percent packets
Percent bytes
100.00 99.91 0.78 0.06 0.17 0.02 0.02 0.02 0.02 0.24 0.17 0.11 99.05 4.22 0.09 0.09 0.04 0.04 0.05 0.01 0.03 0.07 0.06 0.09
11.15 15.91 0.05 0.02 0.10 0.03 0.01 0.00 0.00 0.20 0.09 0.03 72.36 32.04 0.06 0.06 0.00 0.01 0.22 0.09 0.25 0.03 0.00 0.02
and automotive,” Ph.D. dissertation, Otto-vonGuericke-Universität Magdeburg, 2020.
Table 8 reports the protocol hierarchy observed in the illustrative Tesla Model X Nmap scan discussed in Section 5. The scan is included as a case example of C2 and should not be interpreted as representative of all vehicles.
References
[3] K. Strandberg, N. Nowdehi, and T. Olovsson, “A systematic literature review on automotive digital forensics: Challenges, technical solutions and data collection,” IEEE Transactions on Intelligent Vehicles, vol. 8, no. 2, pp. 1350–1367, 2023, doi: 10.1109/TIV.2022.3188340.
[1] KBA, “Durchschnittliches Alter von Personenkraftwagen in Deutschland von 1960 bis 2023,” 2023. [Online]. Available: https://de.statista.com/statis tik/daten/studie/154506/umfrage/durchschnitt liches-alter-von-pkw-in-deutschland/
[4] K. Strandberg, U. Arnljung, and T. Olovsson, “The Automotive BlackBox: Towards a standardization of automotive digital forensics,” in Proc. IEEE International Workshop on Information Forensics and Security (WIFS), Nuremberg, Germany, 2023, pp. 1–6, doi: 10.1109/WIFS58808.2023.10375003.
[2] R. Altschaffel, “Computer forensics in cyber-physical systems: Applying existing forensic knowledge and procedures from classical IT to automation
[5] K. Kent, S. Chevalier, T. Grance, and H. Dang, “Guide to integrating forensic techniques into incident response,” National Institute of Standards and
15
Technology, Special Publication 800-86, 2006, doi: 10.6028/NIST.SP.800-86. [6] ISO/IEC, “ISO/IEC 27037:2012, Information technology - Security techniques - Guidelines for identification, collection, acquisition and preservation of digital evidence,” International Organization for Standardization, 2012. [7] ISO/IEC, “ISO/IEC 27043:2015, Information technology - Security techniques - Incident investigation principles and processes,” International Organization for Standardization, 2015. [8] A. C. Tricco et al., “PRISMA extension for scoping reviews (PRISMA-ScR): Checklist and explanation,” Annals of Internal Medicine, vol. 169, no. 7, pp. 467–473, 2018, doi: 10.7326/M18-0850. [9] S. Kuhlmann, R. Altschaffel, T. Hoppe, J. Dittmann, and C. Neubüser, “Evaluation of impacts of IT-incidents on automotive safety with regard to supporting reaction strategies for the driver,” in Traffic Safety through Integrated Technologies: 24th Enhanced Safety of Vehicle Conference, 2015, p. 9. [10] H. Mansor, “Security and privacy aspects of automotive systems,” Ph.D. dissertation, Royal Holloway, University of London, 2017. [Online]. Available: https://pure.royalholloway.ac.uk/porta l/files/28425623/2017mansorhphd.pdf [11] R. Altschaffel, K. Lamshöft, S. Kiltz, and J. Dittmann, “A survey on open automotive forensics,” in International Conference on Emerging Security Information, Systems and Technologies, 2017, pp. 65–70. [12] K. K. Gomez Buquerin, C. Corbett, and H.J. Hof, “A generalized approach to automotive forensics,” Forensic Science International: Digital Investigation, vol. 36, p. 301111, 2021, doi: 10.1016/j.fsidi.2021.301111. [13] S. Kiltz, M. Hildebrandt, and J. Dittmann, “Forensische Datenarten und -analysen in automotiven Systemen,” in DACH Security, 2009, pp. 141–152. [14] K. Koscher et al., “Experimental security analysis of a modern automobile,” in Proc. IEEE Symposium on Security and Privacy, 2010, pp. 447–462, doi: 10.1109/SP.2010.34.
16
[15] T. Hoppe, S. Kuhlmann, S. Kiltz, and J. Dittmann, “IT-forensic automotive investigations on the example of route reconstruction on automotive system and communication data,” in Computer Safety, Reliability, and Security, F. Ortmeier and P. Daniel, Eds. Berlin, Germany: Springer, 2012, pp. 125–136, doi: 10.1007/978-3-642-33675-1_12. [16] D. Jacobs, K.-K. R. Choo, M.-T. Kechadi, and N.-A. Le-Khac, “Volkswagen car entertainment system forensics,” in Proc. IEEE Trustcom/BigDataSE/ICESS, 2017, pp. 699–705, doi: 10.1109/Trustcom/BigDataSE/ICESS.2017.302. [17] W. Vandiver and R. Anderson, “Analysis of Berla iVe acquisitions of vehicle speed data from Ford SYNC systems,” SAE International Journal of Transportation Safety, vol. 6, no. 2, pp. 257–274, 2018, doi: 10.4271/2018-01-1442. [18] N.-A. Le-Khac, D. Jacobs, J. Nijhoff, K. Bertens, and K.-K. R. Choo, “Smart vehicle forensics: Challenges and case study,” Future Generation Computer Systems, vol. 109, pp. 500–510, 2020, doi: 10.1016/j.future.2018.05.081. [19] K. Gomez Buquerin and H.-J. Hof, “Digital forensics investigation of the Tesla Autopilot file system,” in SECURWARE 2022, The Sixteenth International Conference on Emerging Security Information, Systems and Technologies, 2022, pp. 82–87. [20] R. Kurachi, T. Katayama, T. Sasaki, M. Saito, and Y. Ajioka, “Evaluation of automotive event data recorder towards digital forensics,” in Proc. IEEE 95th Vehicular Technology Conference (VTC2022Spring), 2022, pp. 1–7, doi: 10.1109/VTC2022Spring54318.2022.9860722. [21] A. Attenberger, “Data sources for information extraction in automotive forensics,” in Computer Aided Systems Theory - EUROCAST 2019. Cham, Switzerland: Springer, 2020, pp. 137–144, doi: 10.1007/978-3-030-45096-0_17. [22] S. Ebbers, F. Ising, C. Saatjohann, and S. Schinzel, “Grand theft app: Digital forensics of vehicle assistant apps,” in Proc. 16th International Conference on Availability, Reliability and Security (ARES), 2021, pp. 1–6, doi: 10.1145/3465481.3465754.
[23] F. Sumaila and H. Bahsi, “Digital forensic analysis of mobile automotive maintenance applications,” Forensic Science International: Digital Investigation, vol. 43, p. 301440, 2022, doi: 10.1016/j.fsidi.2022.301440. [24] S. Ebbers, S. Gense, M. Bakkouch, F. Freiling, and S. Schinzel, “Grand theft API: A forensic analysis of vehicle cloud data,” Forensic Science International: Digital Investigation, vol. 48, p. 301691, 2024, doi: 10.1016/j.fsidi.2023.301691. [25] A. R. Onik, T. T. Spinosa, A. M. Asad, and I. Baggili, “Hit and run: Forensic vehicle event reconstruction through driver-based cloud data from Progressive’s Snapshot application,” Forensic Science International: Digital Investigation, vol. 49, p. 301762, 2024, doi: 10.1016/j.fsidi.2024.301762. [26] J. Li, Z. Song, Z. Zhang, Y. Li, and C. Cao, “Invehicle digital forensics for connected and automated vehicles with public auditing,” IEEE Internet of Things Journal, vol. 11, no. 4, pp. 6368–6383, 2024, doi: 10.1109/JIOT.2023.3310578. [27] M. E. Verma, R. A. Bridges, J. J. Sosnowski, S. C. Hollifield, and M. D. Iannacone, “CAN-D: A modular four-step pipeline for comprehensively decoding controller area network data,” IEEE Transactions on Vehicular Technology, vol. 70, no. 10, pp. 9685–9700, 2021, doi: 10.1109/TVT.2021.3092354. [28] D. K. Nilsson and U. E. Larson, “Combining physical and digital evidence in vehicle environments,” in Proc. Third International Workshop on Systematic Approaches to Digital Forensic Engineering, 2008, pp. 10–14, doi: 10.1109/SADFE.2008.11. [29] J. Jarvis, “Awesome Shodan search queries,” 2022. [Online]. Available: https://github.com/jakejar vis/awesome-shodan-queries [30] J. S. Daily, N. Singleton, E. Downing, and G. W. Manes, “The forensic aspects of event data recorders,” Journal of Digital Forensics, Security and Law, vol. 3, no. 3, pp. 29–42, 2008, doi: 10.15394/jdfsl.2008.1053. [31] Y. Lee and S. Woo, “Practical data acquisition and analysis method for automobile event data recorders forensics,” Journal of Internet Services and Information Security, vol. 12, no. 3, pp. 76–86, 2022, doi: 10.22667/JISIS.2022.08.31.076.
17
[32] A. Joshi, “Powertrain and chassis hardware-in-theloop (HIL) simulation of autonomous vehicle platform,” in SAE Intelligent and Connected Vehicles Symposium, 2017, doi: 10.4271/2017-01-1991. [33] ISO, “ISO 26262:2018, Road vehicles - Functional safety,” International Organization for Standardization, 2018. [34] UNECE, “UN Regulation No. 155 - Uniform provisions concerning the approval of vehicles with regard to cyber security and cyber security management system,” United Nations Economic Commission for Europe, 2020. [35] ISO/SAE, “ISO/SAE 21434:2021, Road vehicles Cybersecurity engineering,” International Organization for Standardization, 2021. [36] A. M. Shaaban, C. Schmittner, T. Gruber, A. B. Mohamed, G. Quirchmayr, and E. Schikuta, “Ontology-based model for automotive security verification and validation,” in Proc. 21st International Conference on Information Integration and Webbased Applications & Services, 2019, pp. 73–82, doi: 10.1145/3366030.3366070. [37] DIGITPOL, “Vehicle forensics,” 2023. [Online]. Available: https://digitpol.com/automotive-for ensics/ [38] AB Forensics, “Digital vehicle forensics training,” 2021. [Online]. Available: https://abforensics. com/digtial-vehicle-forensics-training/ [39] BloombergNEF and MarkLines, “Global sales of cars with embedded telematics from 2011 through 2019,” 2020. [Online]. Available: https://www.statista.c om/statistics/301129/global-sales-of-cars-w ith-embedded-telematics/ [40] PwC, Bertrandt, and Strategy&, “Vehicle-centric connected services market potential in 2030, by key region,” 2019. [Online]. Available: https://www.st atista.com/statistics/1033365/vehicle-centr ic-connected-services-market-potential-by-r egion/ [41] S. Checkoway et al., “Comprehensive experimental analyses of automotive attack surfaces,” in Proc. 20th USENIX Security Symposium, 2011, pp. 77– 92. [Online]. Available: https://www.usenix.org/c
onference/usenix-security-2011/comprehensiv e-experimental-analyses-automotive-attack-s urfaces [42] C. Miller and C. Valasek, “Remote exploitation of an unaltered passenger vehicle,” Black Hat USA, 2015. [Online]. Available: https://www.ioactive.com/w p-content/uploads/pdfs/IOActive_Remote_Car_ Hacking.pdf [43] M. H. Shahriar, W. Lou, and Y. T. Hou, “CANtropy: Time series feature extraction-based intrusion detection systems for controller area networks,” in Proc. Symposium on Vehicle Security and Privacy (VehicleSec), 2023, pp. 1–8, doi: 10.14722/vehiclesec.2023.23090. [44] Bundesverband CarSharing, “Number of car sharing vehicles in Germany from 2012 to 2023,” 2023. [Online]. Available: https://www.statista.com/stati stics/808220/car-sharing-number-of-vehicle s-germany/ [45] Bundesverband CarSharing, “Number of car sharing users in Germany from 2014 to 2023, by type,” 2023. [Online]. Available: https://www.statista.com/s tatistics/415644/car-sharing-number-of-use rs-by-type-in-germany/
18