Convert the vehicle Ethernet to standardRJ45Ethernet
Pinnacle Intelligence Technology Co., Ltd
100BT1
ZLG USB CAN
Used for analysisCAN，LINprotocol
Zhiyuan Electronics
U200
USB CAN FD
Used for analysisCAN FDprotocol
PEAK
FD version
V7610
Flexraydiagnostic instrument
Vector
7610
Software
IDA
A mainstream disassembly and reverse engineering platform.
Hex-Rays
8.1
Ghidra
A mainstream open-sourcedisassembly and reverse engineering platform
National Security Agency (NSA)
10.1.5
Binwalk
Firmware unpacking tool
Craig Heffner
2.3.3
dd
Tool for extracting content from binary programs
GNU Core Utilities
8.32
readelf
AnalysisELFfile header, dependency library, and other information tool
GNU Binutils
2.38
Wireshark
Wiresharkis a network packet analysis software.
Wireshark Community
Version 3.4.0
Nmap
Nmapis a port scanning tool.
Gordon Lyon
7.8
Nessus
Nessusis currently the mainstream operating system vulnerability scanning and analysis software.
Tenable Network Security
Essentials
Tcpdump
TCPdumpisawell-known protocol packet capture tool on Linux systems.
TcpdumpOpen Source Group
4.99.4
boofuzz
boofuzzis a highly extensibleFuzzframework that canFuzztest objects such as protocols and files.
Automatak
0.4.1
burpsuite
Mainstream packet capture tools
PortSwigger Ltd.
Community edition
010editor
A professional text editor and hexadecimal editor
SweetScape Software Inc.
12.0.1
CANoe12
Diagnostic instrument's supporting software
Vector
12.0
1.2.3 Laboratory Environment
1.3 Tester Information
Name
Job description
Qualification
Xu Derong
Security testing
CISP
Huang Yilong
Security testing
CISP
Linghu Jiaqi
Security testing
/
1.4 Test Results
This report is a security test of the target system and provides a report on its security, with a total of8vulnerabilities found, including:
Vulnerability harm
Quantity
High-risk vulnerability
0
Medium-risk vulnerability
2
Low-risk vulnerability
3
The following is a statistical table of the discovered vulnerabilities and non-conformities. For recommendations on actions taken, please refer to the corresponding test case serial numbers.
Serial number
Related categories
Chapter number
Test case name
Vulnerability Name
Vulnerability harm
1
FlexrayCommunication Security
3.5.2
FlexrayBusDoSAttack Test
Construct a script to maliciously occupy normal time slots, causingthe device under testVCUto be unable to send messages regularly, resulting in denial of service
Medium-risk vulnerability
2
FlexrayCommunication Security
3.5.3
Flexraybus malicious message injection attack
The attacker can initiateCM1E'sFlexray bus, opening up the attack surface for further attacks
Low-risk vulnerability
3
LINCommunication Security
3.6.1
LINBus Packet Sniffing Test
To be testedVCUwill default to sending data packets, posing a risk of information leakage
Low-risk vulnerability
4
CANbusUDSdecoding
3.9.12
XCPIs it disabled
IfXCPthe interface is not closed, potential attackers may obtain diagnostic information throughXCPto understand the internal workings and data structures of the system
Low-risk vulnerability
5
CAN/CANFDCommunication Security
3.10.2
CAN-DOSattack
By constructingDDoSattack datapackets, it causes important CAN messages to be unable to send or receive
Medium-risk vulnerability
1.5 Terminology
The definitions of the terms used in the requirements are as follows, in order to obtain standardized concepts and a more detailed overview.
Must: This word means that the definition is an absolute requirement of the norm.
Must not: This phrase indicates that the definition is an absolute prohibition against the norm.
Should: It means that there may be justifiable reasons to ignore a specific clause in special circumstances, but one must understand its full meaning and consider carefully before choosing a different course of action.
Should not: This means that there may be legitimate reasons for certain behaviors to be acceptable or even practical in special circumstances, but before engaging in any behavior described by this label, one should understand its full meaning and carefully weigh the situation.
Possible: This word means that a matter is actually optional.
2. Introduction to Security Testing
2.1 Test Reference Basis
2.1.1 International Standard Specifications
《ISO/SAE 21434 Road vehicles — Cybersecurity engineering》（International Organization for Standardization (ISO) and Society of Automotive Engineers (SAE）
UN Regulation No. 155《Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system》
“Proposals for Interpretation Documents for UN Regulation No. 155 on Cyber Security and Cyber Security Management System”
2.1.2 National Standards and Specifications
GB/T 20984-2007 Information Security TechnologyInformation Security Risk Assessment Standards
GB/T 38628-2020 Information Security TechnologyGuidelines for Automotive Electronic System Network Security
GB/T 40861-2021 General Technical Requirements for Automotive Information Security
2.1.3 Industry Standards and Specifications
CSAE 101-2018Technical Requirements for Information Security of On-board Systems in Intelligent Connected Vehicles
YD/T 3752-2020 Technical Requirements for Security Protection of Internet of Vehicles Information Service Platform
2.2 Test Process Description
The penetration testing service process is defined in the following stages.
Penetration testing process:
Information collection: Collect information about the target system's network, services, known vulnerabilities, etc
Penetration Testing:Discovering security vulnerabilities from the attacker's perspective
Exploitation of vulnerabilities:Using discovered vulnerabilities to gain system access or find other vulnerabilities
Results Collection:Document the attack process and operational steps, analyze the reasons and methods for the success of the attack
Threat Analysis:Assess potential risks and threats
Output Report:Write a penetration testing report, including identified vulnerabilities, risk assessment, and recommendations
3. Information Security Penetration Testing
3.1 Hardware Security
3.1.1 DAPDebug Interface Security
Test CaseID
CM1E-HARD-01
Safety objectives
CSG-02
Test case description
Manually check whether there are availableDAPdebug interfaces or important chipsilkscreen
Execution steps
1) Disassemble the testing device, and found the MCU model is Infineon TC387QP-160F
2）PCB boards do not have reservedDAP debugging interfaces by default. To facilitate testing, the debugging ports have been pre-soldered.
3）However, due tothe official versionMCUbeing lockedDAPcannot access debugging, that is, through.
Expected result
There are no available reservedDAPdebugging ports on the motherboard. If available debugging ports exist, they should have a secure protection mechanism.
Test results
through
3.1.2 UARTDebug Interface Security
Test CaseID
CM1E-HARD-02
Safety objectives
CSG-02
Test case description
Manually check whether there is a usableUARTdebug interface or important chip silkscreen on the device
Execution steps
1）Disassemble the test device, noPCBreservedUARTdebug port
2）STThe electric control chip ofdatasheetfor cracking could not be analyzed to obtain specific chip signals, which should beBWcustom chip
3）Use a multimeter to measure the ground pin to determine whether to continue using theST series chip's common pin definition;
The analysis of pin definitions does not match after measurement
4) Use a logic analyzer to probe the pins that may have aUARTpinconnection
5）No communication found betweenUARTpinsRX TX.
Expected result
There is no reserved availableUARTdebug port on the motherboard; if an available debug port exists, it should have a secure protection mechanism
Test results
through
3.1.3 JTAGDebug Interface Security
Test CaseID
CM1E-HARD-03
Safety objectives
CSG-02
Test case description
Manually check whether there is a usableJTAGdebug interface or important chip silkscreen on the device
Execution steps
1) Obtainthe TC387 datasheet pin information
2）JTAGrelated pins are inH16 17and so on. ThisECUuses aBGApackaging method that only exposes the outermost pins,H16and17and other internal pins cannot be accessed without disassembling the chip.
Expected result
There is no available reservedJTAGdebug port on the motherboard. If there is an available debug port, it should have a secure protection mechanism.
Test results
through
3.1.4 SPI FlashFirmware Extraction Test
Test CaseID
CM1E-HARD-04
Safety objectives
CSG-02
Test case description
Through the motherboardSOP QFPand other packagesFlashchips,try using a chip clip to see if the firmware can be extracted
Execution steps
1) By observing the PCB, according to the MCU chip nearby the SPI bus to track the corresponding chip
2）TJA1145chip is a high-speedCANtransceiver, not aflashchip
3）A1027isLinbus related chip
4）95260eis a clock generator
5）VQ7050A HSDchip
6) Up to this point, tracking allspichips on the bus has not found any usingflashoreepromchips to store firmware information, so this risk point is estimated to be nonexistent
Expected result
SPIdoes not exist on the busflashoreepromchip to extract firmware
Test results
through
3.1.5 MCUFirmware Extraction Test
Test CaseID
CM1E-HARD-05
Safety objectives
CSG-02
Test case description
AnalysisMCUchips and whether there are reserved debugging ports,try using a chip clip to see if firmware can be extracted through methods like flying leads.
Execution steps
1) Obtainthe TC387 datasheet pin information
2）JTAGrelated pins are inH16 17and so on. ThisECUuses aBGApackaging method that only exposes the outermost pins,H16and17and other internal pins cannot be accessed without disassembling the chip.
3）DAPdebug portthe official version does not reserve and the chip will be locked
4) No method to extract firmware was found through otherSPIchips; refer to3.1.4 SPI Flashfirmware extraction test.
Expected result
Unable to read through the Infineon series debugger, unable to flashMCUfirmware
Test results
through
3.2 Software Security
3.2.1 Before starting, it is necessary to verify the legality of the code signature to prevent the program from being illegally tampered with
Test CaseID
CM1E-SOFT-01
Safety objectives
CSG-03
Test case description
Manual inspection, by replacing the image file or tampering with the image. Check if it can be started normally
Execution steps
Test premise: To ensure the depth of testing, this deviceMCUis not locked and hasDAPdebug interface soldered
1) Use Infineonminiwiggler programming tool, connect toDAP debugging interface to the TC387 chip
2) Throughcm1e_23N5_app_filled_merged_exclusive_asw.s19firmware package analysis reveals thatappthe firmware address range is
0xA0300000-0xA03FBFFF
3）Extractthe firmwarefromthe MCUfor this section and save it ashexfile
3) Place the extracted hex file into IDA Pro for analysis, locate the assembly instruction operation section, and during the disassembly and dynamic analysis of the target code, a special code segment was found, which is located within a certain subroutine and mainly contains a series of MOVS instructions and other operations interacting with registers and memory. Based on the structure and behavior of the code, it is suspected that it may be related to signature information.
4）UsingMOVS R2，R0as the tampering point, locate its position in thehexfile
R2indicates02 R0indicates00
5) InMOVS R3,R0 instruction, it can be identified as03 00 which proves thatR3 represents03
6）So modifyMOVS R2，R0 instruction toMOVS R2,R3 which means to locate and change02 00 to02 03 accordingly
Locate010editorin the editor, change02 00to02 03and then save
7) Because the firmware is in standardhex format, the last two digits after each line of data are the checksum, which needs to be recalculated; otherwise, it is an invalidhex file
8) Recalculate the value of the hex checksum using the tool, and replace and save it
9) Use the modified firmware with the memtool flashing tool to open it, and if no errors occur, it will be recognized as legitimate firmware
10）Attempt to tamper with the rewriting
11) Analyze the error cause: Based on the observation of the current, the device has not entered the flashing boot program or cannot be flashed due toHSMconfiguration reasons
Expected result
Replace the image file or tamper with the image. Should not be able to start
Test results
through
3.2.2Software anti-debugging, preventing code injection, and malicious behaviors such as auxiliary tools
Test CaseID
CM1E-SOFT-02
Safety objectives
CSG-03
Test case description
Combining manual and tool-based methods to perform illegal debugging, code injection, and other operations on image files and application files. Check if it works properly
Execution steps
1) DeviceMCUis locked; it can prevent attackers from debugging and code injection
Test premise: Ensure testing depth,MCUtesting under unlocked conditions
2）After breaking through the anti-debugging mechanism; the attacker can maliciously construct a legitimate upgrade package to be flashed and run on the device.
3）In the editor locate the address in hexadecimal, change 09 FF to 09 F1
4) The modifieds19firmware will be used forLauterbach flashing;
5）Successful flashing, and the systemstay in boot and cannot start normally, this test case passes
Expected result
The software within the chip has corresponding security mechanisms that cannot be debugged or injected
Test results
through
Attachment
3.3 Safe Startup
3.3.1 Supports secure boot, verification is required before startup Bootloader signature validity and its own integrity to prevent Bootloader from being tampered with illegally
Test CaseID
CM1E-BOOT-01
Safety objectives
CSG-03
Test case description
Manual inspection,tamperingBootloaderfirmware, reflash to see if it can boot normally
Execution steps
Through3.2.1Test ProcesspassedInfineon Miniwigglerdebugging tool cannotmodifythe VCUfor rewriting, there are corresponding security mechanisms
1) Analyze the error cause: Based on the observation of the current, the device has not entered the flashing boot program or cannot be flashed due toHSMconfiguration reasons
Expected result
After flashing the tampered firmware, the system should be unable to start, unable to be flashed, or have relevant protective mechanisms to prevent unauthorized access
Test results
through
3.3.2 The system cannot execute any unsigned or invalidly signed Bootloader and firmware
Test CaseID
CM1E-BOOT-02
Safety objectives
CSG-03
Test case description
Manual inspection, the component has mechanisms to verify the validity of the Bootloader and firmware signatures
Execution steps
Through3.2.1Test ProcesspassedInfineon Miniwigglerdebugging tool cannotmodifythe VCUfor rewriting, there are corresponding security mechanisms
1) Analyze the error cause: Based on the observation of the current, the device has not entered the flashing boot program or cannot be flashed due toHSMconfiguration reasons
Expected result
The firmware with invalid signatures should not be able to start, be flashed, or have related protection mechanisms to prevent unauthorized access
Test results
through
3.3.3 Before each execution of the Bootloader the system should verify the validity of the Bootloader and firmware signatures
Test CaseID
CM1E-BOOT-03
Safety objectives
CSG-03
Test case description
Manual inspection, the system should have a secure boot verification, andBootloaderand firmware flashing should have secure access control, and there should be a verification of signature validity during the secure flashing process
Execution steps
Through3.2.1Test ProcesspassedInfineon Miniwigglerdebugging tool cannotmodifythe VCUfor rewriting, there are corresponding security mechanisms
1) Analyze the error cause: Based on the observation of the current, the device has not entered the flashing boot program or cannot be flashed due toHSMconfiguration reasons
Expected result
Before each execution ofBootloader, the system should verify theBootloaderand the validity of the firmware signature
Test results
through
3.4 Security Upgrade
3.4.1 Before use, the legitimacy and integrity of the upgrade package source must be verified through signature verification.
Test CaseID
CM1E-UPDATE-01
Safety objectives
CSG-04
Test case description
Manual inspection, using tools to tamper with normal signature upgrade packages and signatures, to check if the system can upgrade normally
Execution steps
Through3.2.1Test ProcesspassedInfineon Miniwigglerdebugging tool cannotmodifythe VCUfor rewriting, there are corresponding security mechanisms
1) Analyze the error cause: Based on the observation of the current, the device has not entered the flashing boot program or cannot be flashed due toHSMconfiguration reasons
Expected result
By using tools to tamper with normal signature upgrade packages and signatures, the upgrade should not be successful or there should be relevant protective mechanisms in place to prevent unauthorized access
Test results
through
3.4.2 Block upgrades with invalid authorization detection for upgrade packages and failed integrity checks.
Test CaseID
CM1E-UPDATE-02
Safety objectives
CSG-04
Test case description
Tool detection, tampering with the upgrade package,to determine if the upgrade can proceed normally; if the upgrade fails;check if there is a normal rollback process
Execution steps
Test premise: To ensure the depth of testing, this deviceMCUis not locked and hasDAPdebug interface soldered
1) Use the Lauterbach programming tool to connect to the TC387 chip via the DAP debugging interface
2) Throughcm1e_23N5_app_filled_merged_exclusive_asw.s19firmware package analysis reveals thatappthe firmware address range is
0x80400000-0x807FBFFF
3）In the editorlocate the address using hexadecimal,change09 FFto09 F1
4) will rewrite the modifieds19firmwareLauterbach tool;
5）Successful flashing,the system has detected the tampered software, andstay in boot，the test case passes
Expected result
Analyze and tamper with the upgrade package;The integrity verification mechanism of the upgrade package should not be easily analyzed, leading to the malicious construction of upgrade packages that can bypass integrity verification by attackers.
Test results
through
Attachment
3.4.3ThroughUDSdiagnostics, test theintegritycheck logic of the upgrade package, and those that do not comply should be blocked
Test CaseID
CDM-UPDATE-03
Safety objectives
CSG-04
Test case description
Tool inspection,throughUDSdiagnosticsto tamper with the upgrade package,check for integrity verification, and those that do not comply should be blocked.
Execution steps
1）Through010edit editor, modify the values of each file corresponding tosignature_dev and save
VCU_SBL_signed_dev-modify（4DModifyFF）
VCU_ESS_20210709_signed_dev-modify（56ModifiedFF）
miniapp_v03_dev-modify（19modifiedFF）
3) throughDSAconnectthe device under testVCU
4）Import thevbffile after modifying the signature into DSA, and set the correspondingpincode
5) ThroughSWDL upgrade, found upgrade failed
6) At this time, the VCU is operating normally, with no power loss and no system crashes due to upgrade failures
Expected result
Tampering with the upgrade packageUpgrades should have integrity checks for the data packets, and there should be a blocking mechanism for those that do not comply
Test results
through
Attachment
3.5 FlexrayCommunication Security
3.5.1 FlexrayBus Data PacketSensitivity Sniffing
Test CaseID
CM1E-Flexray-01
Safety objectives
CSG-05
Test case description
By sniffingFlexraychannel data packets, audit whether there are sensitive communication packets for communication
2) Configure activationFlexraybus,by auditingFlexraystatic frames in the bus, combined with the definition of data, no sensitive data frames were found in the buswith obvious signal contenttransmission
3）Further audit the dynamic frame, the dynamic frame'spayload is0 with no sensitive information leakage
Expected result
By sniffingFlexraychannel data packets, there are no sensitive communication packets for communication
Test results
through
3.5.2 [Medium Risk Vulnerability]FlexrayBusDoSAttack Test
Test CaseID
CM1E-Flexray-02
Safety objectives
CSG-05
Test case description
Build test scripts based onFlexraystatic frame transmission mechanism, maliciously occupying normal time slots, causingECUto be unable to send messages regularly,resulting in denial of service
Execution steps
1) Connect the Flexray bus and confirm that the interactive rx data packets can be received
2) Write a script to implementFlexray static frame transmission mechanism to maliciously occupy normal time slots
3) Configure the test script and successfully send data (you can see my printed DDOS-start). It can be found that the entire Flexray bus has been filled with malicious DDoS packets, and all the original RX data packets on the bus cannot be received
4) Click on the analysis tab, confirm again, and no data packets will be received afterwards, achieving the DDOS effect
Expected result
FlexrayThe bus should be able to withstandddosattacks, and there should be no situation where the bus functionality is unavailable
Test results
Not approved
Attachment
Repair suggestions
Time slot monitoring and detection:
Implement time slot monitoring to detect abnormal time slot occupancy. If it is found that a certainECUis being maliciously occupied, corresponding measures can be taken, such as restarting theECUor switching to a backup channel.
Time slot reservation strategy:
Reserve time slots for key messages andECUto ensure they can be sent on time.
Limit the time slot occupancy of non-critical messages to prevent malicious occupation from affecting critical communication.
Traffic analysis and anomaly detection:
MonitorFlexraynetwork traffic patterns and identify abnormal traffic.
Set a threshold, and trigger an alarm or take appropriate measures when the traffic exceeds the threshold.
FlexrayThe bus communication lacks authentication and message verification mechanisms, so it cannot identify and alert against abnormal messages that are forged or tampered with by attackers. Test by sending some crafted malicious messages onto the bus to conduct an attack and verify whether a correct response will be made.
Execution steps
1) AddFlexray database file, start the test VCU bus, found to be in an inactive state
2) Build the Flexray wake-up frames for all Geely systems, other OEM manufacturers
3) Start the entireFlexray bus and send the wake-up frame
4) At this time, it was observed that the VCU to be tested can be awakened, and the wake-up frame is effective
Expected result
BuildFlexraykey frames, such as building otheroemmanufacturers on the same platformFlexraywake-up frames, should not be effective onCM1E.
Test results
Not approved
Repair suggestions
Remove the activation frame fromthe testVCUactivation frame data definition
3.5.4 FlexraySecure Access29Service Reverse Cracking Test
Test CaseID
CM1E-Flexray-04
Safety objectives
CSG-05
Test case description
By means of binary reverse engineering, attempt to obtain theX.509certificate in the firmware and verify29the service compliance with encryption standards
Execution steps
1) According to29services ofAPCEmodel, the process includes the key transfer process required for secure diagnostic communication after successful authentication (secure diagnostic communication).
2）Decomposing this process, in two-way authenticationclientauthenticatesserver in a manner that is no different from one-way authentication, just in the opposite direction;
clientsend the certificate toserver, the certificate containsclient's public key
serverconfirms the validity of the certificate after receiving it (using thePKIcertificate validity check function), verifying whether theclientis legitimate. If it is not legitimate, the authentication process is stopped, and a negative response is returned; if it is legitimate, the authentication process continues.
serversends achallengemessage regarding the certificate, requestingclientto prove ownership of the issued certificate (proof of ownership), the message includes the random number required for authentication
clientreceivedchallengeand used the private key to compute the signature of the received random number, which is included in the response message sent toserver
serverusesclient'spublic key to decryptand verify the signature information in the response message, comparing it withthe challengemessage, and replies tothe clientwith the authentication result
3）Therefore, the key to penetration testing is whether it is possible to obtainX.509 which is a public key certificate in cryptography.
3-1) Try to loadMCU firmware intoIDA, and attempt to reverse engineerMCU firmware. Before reversing, confirm the chip model and architecture information:
According to the silkscreen on the chip, the chip model isTricore architecture, the chip model isTC387QP, after loading the firmware usingIDA, wait forIDA to complete preprocessing, then select the device type:
However, fromIDAsupported models, I did not seethe TC387series, so I temporarily chosethe TC1766to try loading:
The entire loading process takes about fifteen minutes.
3-2）After the loading is complete, confirm whether the cross-reference is available. If the cross-reference is available, it indicates that the firmware has been successfully loaded:
3-3) However, further analysis revealed that the system cannot recognize all code segments, and string references cannot be recognized properly. Therefore, it is determined thatIDA's default loading address does not meet the requirements of the current chip version. Further analysis ofIDA loadingAURIX shows that we need to define the memory architecture information for theTC387QP series, such as the definition ofTC1797:
3-4) According to the chip manual andIDA's format, increase support forTC3xxseries chips as much as possible:
After adding the memory mapping, useIDAto reload the firmware, and then select our newly addedTC-3xx:
3-5）However, since the entire firmware lacks a symbol table, it is necessary to find a way to repair the basic symbol table before better analyzing the meaning based on context.
3-6) PrepareTircore development environment, and call as manyAPI functions as possible based on the examples provided by the official documentation:
3-7After writing the code, try to compile it to generate the firmware:
3-8）UseIDAto load the compiled firmware and save theidbfiles of the firmware to be analyzed and the manually compiled firmware.
3-9）Attempted to use function similarity matching algorithms to identify functions in the symbol table, but the comparison results were not ideal; the identified functions were merely individual digits:
3-10) Try to findTircore integration autosar development tools, attempt to manually compile autosar symbol information firmware, but found that autosar compilation environment requires a subscription to use:
Therefore, this approach cannot continue.
3-11) Attempt to connect the large model to the decompilation tool, allowing the large model to automatically identify function functionality, asIDAcannot generateTirCorearchitecture pseudocode, soGhidrawas chosen to perform this step, and the script for calling theGhidrato invokeLLM model is as follows:
Load the project intoGhidra. Add the directory where we have stored our scripts, and then double-click to execute and call theAI model generation function annotations:
After waiting for the script to complete execution, annotations for all functions will be generated:
WithAI's intervention, successfully located the relevant code snippets for encryption and decryption:
Then trace the code forwardCall tree：
And the upper-level function call of this function isentry function. Based on the context and semantic analysis, this function should be responsible for initializing some encryption algorithm modules.
3-12) Look for keywords related to certificates in the completed code and check if there are anycertificate files:
It can be seen that no information related to the certificate was found. Therefore, it is determined that the certificate is stored inTEE, and the certificates stored in the firmware are encrypted and not stored in plaintext.
4) Individual verification29Function of the service
Send the PDU of 29 01, receive a negative response NRC of 12, indicating the presence of permission verification control
Send PDU 29 02, received negative response, NRC is 22, there is permission verification control
Send PDU 29 03, received negative response, NRC is 22, there is permission verification control
Send PDU 29 04, received negative response, NRC is 12, this function is not supported
Send PDU 29 08, received negative response, received negative response, NRC is 22, there is permission verification control
Send PDU 29 00, receive negative response, receive negative response, NRC is 22, there is permission verification control
5) In summary, the certificate cannot be obtained through reverse engineering,29 and the service has security checks, so this case is valid.
Expected result
By means of binary reverse engineering, it is impossible to obtain theX.509certificate and verify that the29service complies with encryption standards
Test results
through
Attachment
3.5.5 Flexray secure access 27 service algorithm anti-collision test
Test CaseID
CM1E-Flexray-05
Safety objectives
CSG-07
Test case description
Verify the generality of Party A's other components27algorithm (includingkey) to see if it is effective on thisECU.
Execution steps
Use otherGeelysuppliers'DSAand the VCUto connect
DSAcontains27algorithms for services, at this time input other suppliers' pincode
3）At this time, unlocking and flashing is performed, but an error is found, so it cannot be securely authenticated and unlocked using the pincode or algorithm from other vendors for the VCU.
Expected result
The security algorithm of Party A should ensure that the algorithmkeyis independent(which can be implemented through differentkeyimplementations), and there should not be a single algorithmandkeythat can be used interchangeably across different components
2) Register the slot, concatenate the diagnostic frame to send the PDU, received a negative response, according to NRC 22, defined as condition not met, there are constraints
Expected result
Send hard reset(0x11)function command, there should be security checks or restrictions
Test results
through
3.5.8 Flexray bus 2E fingerprint writing permission verification test
Test CaseID
CM1E-Flexray-08
Safety objectives
CSG-07
Test case description
Performfingerprint writing operation on ECU to test whether there is a security access permission verification
Execution steps
1) Connect the FlexRay bus interface to the gateway device, and diagnostics and debugging of the FlexRay bus can be performed through the gateway
2) ToCC change the value, send2E E1 04 66 08 24 15 27 20 20 41, and the response received is negative, with relevant permission restrictions
Expected result
Performfingerprint writing operation on ECU, there should be a security access permission verification
Test results
through
3.5.8Flexraythrough31memory erase permission verification test
Test CaseID
CM1E-Flexray-09
Safety objectives
CSG-07
Test case description
Performmemory erase operationon31to test whether there is a security access permission check
2) Through the canoe diagnostic instrument, construct the request frame data format for 31 as 31 01 PDU, receiving a negative response, with limitations present
Expected result
ForECUperforming31memory erase operations, there should be a security access permission check
Test results
through
3.5.9Flexraythrough34service request download operation permission verification test
Test CaseID
CM1E-Flexray-10
Safety objectives
CSG-07
Test case description
PerformECU34request download operation to test whether there is a security access permission verification
2) Through the canoe diagnostic instrument, construct the request frame data format for 34 as PDU 34 01, and receive a negative response, indicating a limitation
Expected result
ForECUperforming34request download operations, there should be a security access permission check
Test results
through
3.5.10Flexraythrough36service segment transmission operation permission verification test
Test CaseID
CM1E-Flexray-11
Safety objectives
CSG-07
Test case description
Perform36segmented transmission operations onECUto test whether there is a security access permission check
2) Through the canoe diagnostic instrument, construct the request frame data format for 36 as PDU 36 01, and receive a negative response, indicating a limitation
Expected result
Perform36segmented transmission operations onECU, with security access permission verification
By sniffingLINthe packets in the channel, audit whether there aresensitive communication packetsfor communication
Execution steps
1) ConnectLIN upper computer diagnostic instrument to the VCU of LIN1
2）Start the diagnostic tool inslavemode, at which point the diagnostic tool can receivethe data packetssent by theVCUand therxdoes not require a response from the slave
4）At this time, the audit error frames are as follows
Sort outidas follows:
id：0x30
id：0x01
id：0x37
id：0x1C
id：0x38
id：0x39
...
5）Sampling detection, configurationslavenode configuration only responds to node0x38and sends, found0x38node no longer reports errors,indicatingVCUwill send externally meaningfulTX
15）In summary,The testedVCUwill send default messages containing business meaningLINdata packets externally, but considering that this test only involves a single testedVCUunit and there are no interactions with other components, thereforethe testedVCUin this similar“broadcast”manner may lead attackers to guess the frames with business meaningid, and conduct further probing, so it is initially not approved, and the development engineer can confirm again.
Expected result
Through sniffingLINthe packets in the channel, there should not be sensitive communication packets for communication
Test results
Not approved
Repair suggestions
If there is no business requirement,theVCUwill not default to sendingLINrequest frames externally
Build test scripts based onLINtransmission mechanism, increase concurrency, cause denial of service attacks, and verify the robustness of the system
Execution steps
1）Switch the upper computer'sLINbus mode, at this time start16threads, simultaneously sendingLIN'stx packets, and send10,000 times
2) At this time, monitor the bus status to confirm the normal sending of data packets, and they are parsed by the bus
3) At the same time, monitor the fluctuations of the overall data
4) During the testing process, the defaultRX data can still be received normally,LIN bus functions normally, and there has been no power failure situation.
Expected result
LINThe LIN bus must not crash or become unavailable under high load conditions.
Test results
through
3.6.3 LINBus Malicious Message Injection Attack
Test CaseID
CM1E-LIN-03
Safety objectives
CSG-07
Test case description
Test sending some constructed maliciousLINmessages to the bus for attack, checking whether it will respond correctly
Execution steps
1) Due to the absence ofLDF database files, most ordinary signals are custom-defined by the manufacturer, making it impossible to pinpoint the specific function of each frame. However, it is possible to attempt sending diagnostic frames to attack the module(but you need to know the module'sNAD slave node address), for example, the module reset signal, if there is noNAD, you can use the wildcard0x7F
2) Use LIN upper computer software zxdoc software, configure wildcard 0x7F, general uds diagnostic frame ID 0x3C, 0x3D afterwards, perform a reset operation on the VCU to be tested
3) Send reset diagnostic signal
4）After observation,the testedVCUsystem did not reset, nor did it experience a device restart
Expected result
Test sending some constructed maliciousLINmessages to the bus for attack, the system should not respond correctly
Test results
through
3.7 Data Storage
3.7.1 Support for secure encrypted storage of key data
Test CaseID
CM1E-STO-01
Safety objectives
CSG-08
Test case description
Tool inspection, reading the local storage area and memory area of key data to check whether encryption processing has been performed.
Execution steps
1) Try to loadMCU firmware intoIDA, and attempt to reverse engineerMCU firmware. Before reversing, confirm the chip model and architecture information:
According to the silk screen on the chip, the chip model isTricore architecture, the chip model isTC387QP, after loading the firmware usingIDA, wait forIDA to complete preprocessing, then select the device type:
However, fromIDAsupported models, I did not seeTC387series, so I temporarily choseTC1766to try loading:
The entire loading process takes about fifteen minutes.
2）After the loading is complete, confirm whether the cross-references are available. If the cross-references are available, it indicates that the firmware has been successfully loaded:
2-1) However, further analysis revealed that the system cannot recognize all code segments, and string references cannot be recognized properly. Therefore, it is determined thatIDA’s default loading address does not meet the requirements of the current chip version. Further analysis ofIDA loadingAURIX shows that we need to defineTC387QP series memory architecture information, such as the definition ofTC1797:
2-2) According to the chip manual andIDA's format, increase support forTC3xxseries chips as much as possible:
After adding the memory mapping, useIDAto reload the firmware, and then select our newly addedTC-3xx:
3）However, since the entire firmware lacks a symbol table, it is necessary to find a way to repair the basic symbol table before better analyzing the meaning based on context.
3-1) PreparationTircore development environment, call as manyAPI functions as possible based on the examples provided by the official documentation:
3-2）After writing the code, try to compile the code to generate the firmware:
3-3) Use IDA to load the compiled firmware and save the idb files of the firmware to be analyzed and the manually compiled firmware.
3-4）Attempt to use function similarity matching algorithms to identify functions without symbol tables, the comparison results are not ideal, and the identified functions consist only of digits:
3-5) Try to findTircoreintegrationautosardevelopment tools, attempt to manually compileautosarsymbol information firmware, but found thatautosarcompilation environment requires a subscription to use:
Therefore, this approach cannot continue.
3-6) We attempt to connect the large model to the decompilation tool, allowing the large model to automatically identify the function's purpose.
WithAI's intervention, successfully located the relevant code snippets for encryption and decryption:
Then trace the code forwardCall tree：
And the upper-level function call of this function isentryfunction. Based on the context and semantic analysis, this function should perform some initialization work for encryption algorithm modules. Therefore, it can be confirmed that the system supports secure encryption storage of key data.
3-7) During the above analysis, we looked at the chip architecture diagram and the chip manual. According to the instructions in the chip manual, this chip has a built-inHSMmodule
Expected result
The developer has encrypted the data in the key local storage areas and memory regions
Test results
through
3.7.2 Protection of key data integrity to prevent key data from being illegally tampered with.
Test CaseID
CM1E-STO-02
Safety objectives
CSG-09
Test case description
Tool testing,illegal tampering of key data, checking whether the system has integrity checks for key data
Execution steps
Through the analysis ofs19firmware's file structure; its firmware integrity check can be bypassed for tampering and rewriting.
1）In the editor locate the address using hexadecimal, change 09 FF to 09 F1
2）Use the modifieds19firmware withLauterbach for flashing;
3）Successful flashing,the system recognition software has been tampered with, andstay in boot，the test case passes
Expected result
There is a relatively secure security mechanism to prevent critical data from being tampered with
Test results
through
3.8 Firmware Vulnerability Scanning
3.8.1 MCUFirmware Vulnerability Scanning
Test CaseID
CM1E-MCU-01
Safety objectives
CSG-03
Test case description
Use a firmware vulnerability scanner to detect binary vulnerabilities in the firmware program
Execution steps
1) Upload the firmware VCU cm1e_23N5_app_filled_merged_exclusive_asw.hex to FACT vulnerability scanning platform
2）ThroughFACT's scan, it is not possible to obtain valuable information through firmware black box scanning. The scan results are as follows
Expected result
Use a firmware vulnerability scanner to detect binary vulnerabilities in the firmware program; there should be no vulnerabilities
Test results
through
Attachment
3.9 CANBusUDSDecryption Test
3.9.1 Propulsion CANBusUDSAnalysis Decryption Test
Test CaseID
CM1E-UDS-01
Safety objectives
CSG-07
Test case description
Test whether it is possible to decipher UDS services and arbitration IDs on the CAN bus using scripts and tools
Execution steps
1) Activate the frame activation bus, and use our self-developed multi-threaded brute force tool toCANbrute force potentialUDSservices on the bus, and usewiresharkto monitor the sent packets
Confirm the return packet with the upper computer in parallel
2) Obtained the followingUDS arbitration ID
Plain Text Send: 0x7e6 Received: 0x7ee
3) Send verification separately,0x7e6 02 10 01 , received0x7ee's response, indicating that the obtainedUDS arbitrationID is correct
4) Scan theUDS arbitration ID supported services, and found the following services(for details, please refer to the attachment), but these services do not meet the specifications, and after a second verification, they are false positives, the tested VCU's CAN bus should have routing functionality, and even knowing the UDS's ID does not present an actual attack surface, therefore this test case passes
Expected result
Unable to decode arbitrationCANbus IDandUDSrelated services
Test results
through
Attachment
3.9.2 Calibration CANBusUDSAnalysis Decoding Test
Test CaseID
CM1E-UDS-02
Safety objectives
CSG-07
Test case description
Test whether it can be decrypted through scripts and toolsCANon theUDSservices and arbitrationID
Execution steps
1) Brute force potential UDS services on the CAN bus using a self-developed multithreaded brute force tool, and monitor the sent data packets.
2）CAN and CANFD cannot obtain the arbitration ID, there is no UDS service on this bus
Expected result
Unable to decode arbitrationCANbus IDandUDSrelated services
Test results
through
Repair suggestions
UDSService migration: migratingUDSservice to a more secure communication protocol, such asdoipetc.
Access Restriction:UDSAccess is restricted and requires relevant backdoors to enable(add jumpers, activate lines, activate frames, etc.)
3.9.3 Chassis1 CANBusUDSAnalysis and Decoding Test
Test CaseID
CM1E-UDS-03
Safety objectives
CSG-07
Test case description
Test whether it can be decrypted through scripts and toolsCANon theUDSservices and arbitrationID
Execution steps
1) Use a self-developed multithreaded cracking tool to crack the potential UDS services on the CAN bus and monitor the sent data packets.
2) Obtained the following two sets ofUDSarbitrationID
3）The individual verification sent has received positive responses, indicating that the obtainedUDSarbitrationIDis correct
4) Scan thisUDSarbitrationidsupported services, no existing services found
5）In summary, arbitration can be obtained through script brute forceID, buttheVCU'sCANbus should have routing functionality, and even if theUDS'sIDis known, there is no actual attack surface, so this use case passes
Expected result
Unable to decode arbitrationCANbus IDandUDSrelated services
Test results
through
3.9.4Chassis2 CANBusUDSAnalysis and Decryption Test
Test CaseID
CM1E-UDS-04
Safety objectives
CSG-07
Test case description
Test whether it can be decrypted through scripts and toolsCANon theUDSservices and arbitrationID
Execution steps
1) Brute force potential UDS services on the CAN bus using a self-developed multithreaded brute force tool, and monitor the sent data packets.
2) Obtained the followingUDS arbitration ID
Result: Send: 0x618 Received: 0x718
3) Scan theUDS arbitration id supported services, and find that there are no corresponding services
5）In summary, arbitration can be obtained through script brute forceID, buttheVCU'sCANbus should have routing functionality, and even if theUDS'sIDis known, there is no actual attack surface, so this use case passes
Expected result
Unable to decode arbitrationCANbus IDandUDSrelated services
Verify the generality of Party A's other components27algorithm (includingkey) to see if it is effective on thisECU.
Execution steps
1) Through project experience, using the algorithm commonly used by mainstream car manufacturersseed2key.
2) Write the upper computer software to achieveseed2key integration in the diagnostic software
3) Connection CME1 component CAN bus, unable to obtain seed, it should have done CAN bus routing, UDS is not implemented in the tested VCU component, so this test case is first passed through
Expected result
The security algorithm of Party A should implement one algorithm per item (which can be achieved through differentkey), and a single algorithm should not be applicable across different components
2) Construct the request frame34 using the upper computer diagnostic tooldata format as 34 00 44 20 01 f0 00 00 00 00 2c and request, but there is no response from the diagnosis. Considering the above phenomena, UDS diagnosis should not have been implemented on the CAN bus, so first through
Expected result
ForECUperforming34request download operations, there should be a security access permission check
Test results
through
Attachment
3.9.10 CANBusthrough36service segment transmission operation permission verification test
Test CaseID
CM1E-UDS-10
Safety objectives
CSG-07
Test case description
Perform36segmented transmission operations onECUto test whether there is a security access permission check
2) Construct36 request framedata format as 36 01 24 00 00 11 12 13, no response from the diagnosis, based on the above phenomena, UDS diagnosis should not have been implemented on the CAN bus, so first through
Expected result
Perform36segmented transmission operations onECU, with security access permission verification
Send hard reset(0x11)Function command to test for the existence of security checks or restrictions
Execution steps
1) UseCANdiagnostic tool (ZLG U200) to connect to theECU bus
2）Switch to extended session and programming session, received a negative response, there may be routing issues
3) Then send 02 11 01 to the bus, receive a negative response, and the current remains unchanged, therefore this test case passes
Expected result
Send hard reset(0x11)function command, there should be security checks or restrictions
Test results
through
Attachment
3.9.12 [Low Risk Vulnerability]XCPIs it disabled
Test CaseID
CM1E-UDS-12
Safety objectives
CSG-07
Test case description
Check through the scriptXCPwhether it is disabled
Execution steps
1）ConnectInstrument CAN，use the test script to scan different arbitrationXCPconnection messages through brute forceIDto find outif theECUsupportsXCP
2) Send probe data packets and monitor the accurate arrival of data
3) Through scanning, it was found thatXCP calibration function is not disabled,XCP is usually used to measure and debug ECU data during the development and testing phases. If the interface is not closed, potential attackers may obtain diagnostic information throughXCP, understand the internal workings and data structure of the system, and further look for other attack points. Therefore, it is recommended to fix this issue.
Expected result
TheXCPfunction of the test item should be disabled
Test results
Not approved
Repair suggestions
1）Authentication and authorization forXCP access: Ensure that only authorized users or tools can accessXCP communication. Encryption, authentication, and other methods can be used to protectXCP sessions.
2）Disable unnecessaryXCPfeatures: Before deploying to the production environment, turn off all unnecessaryXCPfeatures or services
Attachment
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N
3.10 CAN/CANFDCommunication Security
3.10.1 CANBus Data Replay Attack
Test CaseID
CM1E-CAN-01
Safety objectives
CSG-05
Test case description
By recordingthe Internet of Vehiclesexisting data packet interactions, perform data playback to verify if there are any anomalies
Execution steps
1) The CAN diagnostic tool connects to the Propulsion CAN bus and records bus data. In a simulated vehicle scenario, there is a default transmission of CAN bus data with business significance. By recording and replaying this part of the CAN signals, we can check whether the bus will respond to these signals, preventing attackers from obtaining and exploiting sensitive bus information through this operation
2) Through CAN diagnostic software, replay all data on the bus
4) Through observation, the system status is normal,by analyzing the meaning of the signal names defined in theDBCto exclude sensitivekeytransmissions such as power control, braking, steering control,andCANframe leaks.Return
5) There was no power loss throughout the entire current
Expected result
By recording the existing data packet interactions of the Internet of Vehicles and performing data playback, without any sensitive data leakage
Test results
through
Attachment
3.10.2 [Medium Risk Vulnerability]CANBusDOSAttack
Test CaseID
CM1E-CAN-02
Safety objectives
CSG-05
Test case description
Connect using in-vehicle network security testing toolsCANbus.Send a large number of high-speed high-arbitrationCANmessages to check if the vehicle's bus data is responding normally
Execution steps
CAN2.0Concurrent scenarios:
1）Send messages to the tested partIDset to1，interval time set to0ms，send10000frames each time, length is8，datarandom
2）At this time, the channel utilization of the monitoring bus is76%+，with no other interactive data on the bus
3) Stopddos and the bus data returns to normal
CANFDConcurrent scenarios:
1）Send messages to the tested partIDset to1，interval time set to0ms，send10000frames each time, length of64，datarandom
2）At this time, the channel utilization of the monitoring bus is81%+，and the bus is not receiving other data
3) Stopddos and the bus returns to normal
Expected result
Send high arbitration messages with a bus load rate greater than80%, the pre-set function should not cause any impact
Test results
Not approved
Repair suggestions
1.Rate limiter: Configuration CAN interface or introduce rate limiting through gateway devices to ensure that no single node can send large amounts of data at an unreasonable frequency. In particular, a sending frequency limit can be set for low-priority messages to prevent them from occupying bus resources.
2. Increase bus arbitration and priority management
ID Reallocation: Set your important control messages to have a higher priority CAN ID (with smaller values ID), ensuring that under the arbitration mechanism of the CAN bus, these critical messages are prioritized for transmission, even if an attacker sends a large number of low-priority messages, they cannot completely block critical communication.
High priority node isolation: Dividing the key systems (such as security, power control, etc.) CAN messages into a separate high priority bus to prevent them from being affected by low priority nodes.
Attachment
CVSS
CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H（5.4 Medium Risk）
3.10.3 CANBusPacket Sensitivity Sniffing
Test CaseID
CM1E-CAN-03
Safety objectives
CSG-05
Test case description
The tool records bus data, and the default data in the audit bus should not contain sensitive information
Execution steps
1) Connect Propulsion CAN bus, obtain the default transmission data of the bus, load DBC, and display the message name
2) According toDBC message definition check, as shown below, it mainly displays status information, with no sensitive information
Vcu3PropulsionCANFDFr01 (ID: 0x70):
Data Load (Hex): 57 82 BC 09 00 07 D0 00 ... This data may contain information related to vehicle propulsion control, such as torque or power status.
Vcu3PropulsionCANFDFr06 (ID: 0x51):
Data Load (Hex): 00 00 00 01 66 20 33 40 ...This frame may transmit vehicle status or control parameters.
The default communication data on the bus should not contain sensitive data
Test results
through
3.10.4 CANSending sensitive data over the CAN bus
Test CaseID
CM1E-CAN-04
Safety objectives
CSG-05
Test case description
DetectionDBCfile, identify sensitive instructions and send them, without triggering exceptions
Execution steps
1）ConnectPropulsion CANbus, load the bus'sDBCdefinition, analyzeDBCmessage and signal definitions
2) After analysisCAN bus messages, there is currently no clear indication of sensitive information directly related to the power system (such as engine control, transmission, throttle, etc.). However, some message names may contain indirect diagnostic and control signals related to power. For example:
Bcm3PropulsionCanFDSecFr02 (0x55)、Bcm3PropulsionCanFDSecFr03 (0x100) and other series signals:
In these signal names,“Propulsion”usually refers to matters related to the vehicle's propulsion or power system, which may involve power transmission, torque control, and so on.
Becm5PropulsionCANFDFr01 (0x35)、Becm5PropulsionCANFDFr02 (0x40) and other series signals:
These signals are also related to the propulsion system, and the signalsIDare different, possibly transmitting different power control parameters such as speed, acceleration, power distribution, etc.
Hvcm3PropulsionCANFDFr01 (0x110)、Hvcm3PropulsionCANFDSecFr02 (0x120) and other series signals:
“Hvcm”may be an abbreviation for High Voltage Control Module（High Voltage Control Module）, and such signals may be related to the power control of electric vehicles, especially the high voltage battery system.
Iem3PropulsionCANFDFr01 (0x330)、Iem3PropulsionCANFDFr02 (0x50) and other series signals:
“Iem”may refer to the motor control module (Inverter or Electric Motor), and these signals may be used to convey information such as motor status, torque control, and drive system status.
4) In summary,Hvcm3PropulsionCANFDFr01 (0x110) is a sensitive signal related to voltage and current, attempting to construct for transmission
5) ConfigurationHvcm3PropulsionCANFDFr01 (0x110)Each signal is sent with random variations (the corresponding bits will change according to the definition of the signal)
6) By sending random changes to this frame 10,000 times, there was no sensitive data leakage returned, no errors or busoff, and the current values were stable
7) Synchronous Monitoring Flexray data, with no information leakage and triggering
Expected result
Sending sensitive instructions should not trigger exceptions (functional responses, sensitive information replies, etc.)
Test results
through
Attachment
3.10.5 CANBusProtocol Layer Fault Injection
Test CaseID
CM1E-CAN-05
Safety objectives
CSG-05
Test case description
Testing passed usingpython-CANlibrary to simulateCANmessage loss, testing the robustness and error handling capability of the bus
Execution steps
1) Write a script to simulate sending messages with a loss probability of30%.
2) Connectsocket-CAN interface, send data, data sent successfully repeated
3) The upper computer in parallel confirmed that the data was successfully sent, and no errors occurred, with no abnormal situations such as the busbusoff.
Expected result
Testing passed usingpython-CANlibrary to simulateCANmessage loss, testing the robustness and error handling capability of the system, and nobusoffand other abnormal situations should occur
Test results
through
3.10.6 CANBusPhysical Layer Fault Injection
Test CaseID
CM1E-CAN-06
Safety objectives
CSG-05
Test case description
Tool detection, simulating faults on theCANphysical layer through tools.For example:CAN_H\CAN_Lshort circuit, etc.
Execution steps
1) Connection of the upper computer diagnostic instrumentCANbus, randomly sending data packets
2）ConnectECU'sCAN_H andCAN_Ltogether
3) It can be seen that the bus communication is paused after the short circuit, and data packets cannot be sent or received
4）After the short circuit connection ends,CANthe bus resumes normal transmission
Expected result
Simulate fault injection onCANphysical layer through tools, during the short circuit the bus does not send packets, and after the short circuit ends, the bus continues to work normally without being affected.
Test results
through
3.10.7CANBusElectrical Layer Fault Injection
Test CaseID
CM1E-CAN-07
Safety objectives
CSG-05
Test case description
Tool detection, simulating faults on theCANelectrical layer through tools, such as: high and low levels, etc.
Execution steps
1) Use12V voltage to perform electrical layer fault injection, and observe the bus data transmission after the electrical layer fault injection through the CAN bus diagnostic tool.
2) Connect the positive terminal of the power supply to the bus CAN-H, and the negative terminal to the bus CAN-L, the bus stops transmitting
3）When the electrical injection is stopped, the bus immediately resumes normal transmission
4) Connect the positive terminal of the power supply to the bus CAN-L, and the negative terminal to the bus CAN-H, the bus stops transmitting
5）When the electrical injection stops, the bus immediately resumes normal transmission
Expected result
Simulate fault injection onCANelectrical layer through tools, the bus should not be affected or be able to immediately restore communication after electrical fault injection
Test results
through
3.11 Security Log
3.11.1 CAN DIDLog Access Permission Test
Test CaseID
CM1E-LOG-001
Safety objectives
CSG-10
Test case description
Try to obtainECUlog information through the script to test for the existence of permission checks or restrictions
Execution steps
1）ConnectPropulsion CANbus, retrieveECUlogs through the script
2) Through parallelzlg upper computer for packet detection, confirm that the packet can be sent toECU
3) Through script scanning, it was found that the bus does not supportDID log retrieval, and it may also be that theCAN bus is just a router and does not provide log services, so this test case passes
Expected result
Obtain sensitiveECUlog information through scripts, there should be permission verification or other restrictions
Test results
through
3.11.2 Flexray DID Log Access Permission Test
Test CaseID
CM1E-LOG-002
Safety objectives
CSG-10
Test case description
According to Geely'sMCUsensitivityDIDdefinition, test whether there are permission checks or restrictions
Execution steps
According to Geely'sMCUdefinition of sensitive logs, they areMCUdiagnostic event log test (C00B),MCUsecurity access log test (C00A),MCUsecure boot log test (C00C)
Useflexraybus toaccess theMCUdiagnostic event log test (C00B) and combine it with a secondary confirmation of gateway Ethernet access, resulting in a negative responseNRC33, with a security check present
Access the MCU diagnostic event log test (C00A) using the FlexRay bus and combine it with secondary confirmation via gateway Ethernet, resulting in a negative response NRC33, indicating a security check
Access the MCU diagnostic event log test (C00C) using the FlexRay bus and combine it with a secondary confirmation of gateway Ethernet access, resulting in a negative response NRC33, indicating a security check
In summary,MCUhas security checks for obtaining sensitive logs, so this test case passes
Expected result
According to Geely'sMCUsensitiveDIDdefinition,there shouldbe permission verification or restrictions
Test results
through
3.12 SecOC
3.12.1 SecOCKeyHardware Link Extraction Test
Test CaseID
CM1E-SecOC-01
Test case description
Try to obtainSecOCsensitive data or logic during runtime through hardware reverse engineering, channel analysis, and other methods.
Execution steps
1) After analysisSecOCkeyis generally stored inHSMrunning, that is, analyzing theTC387'sHSM
3）exists inside the chip package and cannot be detected without disassembling the chipHSMcommunication
4) Attempt to analyze the communication pins of the circuit board TC387 GPIO to see if it can provide the encryption and decryption process discovered using a logic analyzer during communication
5) Obtain the CAN datasheet to get the GND pin, and then measure the GND pin of MCU TC387.
6) Logic analyzer connection GND, other CHANNEL channel connection to other MCU leads pin for enumeration
7）The signal was not captured in the logical analysis, possibly because the exposed pins do not involve the processing and transmission of relevant information without disassembling the chip.
Expected result
Unable to analyzeSecOC's sensitive data or operational logic
Test whether it can be obtained from the firmwareSecOCkey
Execution steps
1）To extract the SecOC key file from the firmware, reverse analysis of the firmware is required.First, load the MCU firmware into IDA, and attempt to reverse the MCU firmware. Before reversing, confirm the chip model and architecture information:
According to the silk screen on the chip, the chip model isTricore architecture, the chip model isTC387QP, after loading the firmware usingIDA, wait forIDA to complete preprocessing, then select the device type:
However, fromIDAsupported models, I did not seeTC387series, so I temporarily choseTC1766to try loading:
The entire loading process takes about fifteen minutes.
2）After the loading is complete, confirm whether the cross-references are available. If the cross-references are available, it indicates that the firmware has been successfully loaded:
2-1) However, further analysis revealed that the system cannot recognize all code segments, and string references cannot be recognized properly. Therefore, it is determined thatIDA’s default loading address does not meet the requirements of the current chip version. Further analysis ofIDA loadingAURIX shows that we need to defineTC387QP series memory architecture information, such as the definition ofTC1797:
2-2) According to the chip manual andIDA's format, increase support forTC3xxseries chips as much as possible:
After adding the memory mapping, useIDAto reload the firmware, and then select our newly addedTC-3xx:
3）However, since the entire firmware lacks a symbol table, it is necessary to find a way to repair the basic symbol table before better analyzing the meaning based on context.
3-1) PreparationTircore development environment, call as manyAPI functions as possible based on the examples provided by the official documentation:
3-2）After writing the code, try to compile the code to generate the firmware:
3-3) Use IDA to load the compiled firmware and save the idb files of the firmware to be analyzed and the manually compiled firmware.
3-4）Attempt to use function similarity matching algorithms to identify functions without symbol tables, the comparison results are not ideal, and the identified functions consist only of digits:
3-5) Try to findTircoreintegrationautosardevelopment tools, attempt to manually compileautosarsymbol information firmware, but found thatautosarcompilation environment requires a subscription to use:
Therefore, this approach cannot continue.
3-6) We attempt to connect the large model to the decompilation tool, allowing the large model to automatically identify the function's purpose.
WithAI's help, it is possible to successfully obtain the meanings of the vast majority of code snippets.
However, throughout the analysis process, no suspectedSecOC keydata segments were observed.
7）When conducting the above analysis, we looked at the chip architecture diagram and the chip manual. According to the instructions in the chip manual, this chip has a built-inHSMmodule. Based on historical experience,SecOC keymaybe stored inHSM.
Expected result
Unable to retrieveSecOCkey
Expected result
through
3.12.3 SecOCKey Bus Extraction Operation
Test CaseID
CM1E-SecOC-03
Test case description
ThroughUDSmethod, attempt to extractSecOCkey
Execution steps
1) According toAUTOSAR SecOC documentation, theoretically its MAC generation logic is relatively difficult to break. First, the data used for MAC generation includes the complete freshness value, ID and the original data, but the final identity information of the received or sent message is composed of the truncated freshness value and the truncated MAC value, as follows;
The freshness value extraction part only includes the lower bits of the message counter and the lower bits of the reset, as follows:
Without knowingTrip Counter、Reset Counterit is almost impossible to perform a forward crack onSecOC.
However, the synchronization messages on the bus are all in plaintext, which completely exposes the two counters mentioned above. Next, it only requires extracting theSecOCrelated keys, and the entire in-vehicle board-end secure communication will be compromised.
2）In 2021, a certain Japanese car was reported to be able to extract the SecOC key through the UDS via the CAN bus, and the main idea of this case can be summarized as:
Plain Text Switch from the default session to the programming session via UDS SID 0x10;
Authenticate via UDS SID 0x27 (or 0x29);
Set the necessary keys, IV, etc. for AES through UDS SID 0x2E;
Use UDS SID 0x34, 0x36, 0x37 to download the FlsDriver of the upper computer to RAM, but this FlsDriver has been replaced by the attacker with shellcode;
Verify the shellcode through UDS SID 0x31 Routine Control, including CRC and MEP2C;
Control the FlsDriver to erase the target area through Routine Control, but in fact, it triggered the execution of shellcode; ultimately dumping the SecOC key.
3）Create ashellcodeforFlsDriver
3-1) Write the FlsDriver project to implement the functions for Flash read and Flash write, and compile it
3-2) Try to map the relationship between firmware internal memory addresses and functions by locating memory addresses
3) Obtain this part of the memory address and add it to the project. This part of the memory implements the mapping of memory addresses to functions triggered (the compiled Flsdriver is in the attachment), and triggers this part of the function through 0x31 Routine Control
4) Try to restore thePOC operation through the diagnostic tool, and complete the settings for the flashing steps
4) Send thisPOC, diagnostic replyNRC 11, indicatingthe VCUto be testedis a router, unable to diagnose this componentfor flashing, therefore this vulnerability cannot take effect on the VCUto be tested,andcannotextractSecOCkeys via the bus
Expected result
ThroughUDS, it is impossible to extractSecOCkeys through known vulnerabilities
Expected result
through
Attachment
4. Bus Safety Fuzz Testing
4.1.1 CANBus Fuzz Testing
Test CaseID
CM1E-FUZZ-01
Safety objectives
CSG-06
Test case description
By using random, invalid, or anomalous data toCANbus fuzz testing, observing the program's response, and analyzing potential information leaks,BusOffand other situations
Execution steps
1）Connectthe ECUto the CANdiagnostic tool and debug the connection
2) Write a script to randomly generate frameIDand data frames, the main core code logic is as follows, using therandom.randint(min_id, max_id)function
3) Send random packets throughsocketCANinterface, totaling40W+pieces
4) ParallelZLG U200diagnostic instrument software, confirm that the data packet is accurately delivered
5）During the process, it was found that the response to triggering a certain frame is displayed as the scanning script
TX：0x21B 6c 10
RX：0x004 00 04 00 00 00 00 00 00
6) Use the upper computer diagnostic instrument to send confirmation separately, with no response from the return packet, confirmed as a false alarm
7) After verification, there is nosensitive frame information exposed in the return, and there is no occurrence ofBus offand other situations
8) Full monitoring ECU's CAN2 bus, with no corresponding signal leakage or feedback
Expected result
ThroughCANfuzz testing, sensitive frame information will not be exposed, and situations likeBusOffwill not occur
Expected result
through
4.1.2 Flexray Bus Fuzz Testing
Test CaseID
CM1E-FUZZ-02
Safety objectives
CSG-06
Test case description
Generate a series of random or semi-randomFlexraybus data packets through a script and send them to the system to see if crashes occur or exhibit other unexpected results
Execution steps
1) WriteFlexrayfuzz testing scripts toFlexrayrandomly vary the size of each byte in the time slotIDandpayloadto generate corresponding fuzz testing data through this dimensional variation combination
2) Throughvector7610 device, send fuzz testing script data to confirm successful transmission to the device under test VCU, and monitor the bus data
3) Execute the script and confirm that the script's startup log has been executed
3) Continuously monitor the data packets sent and received on the Flexray bus, and monitor the power current situation
4) At the same time, connect to the CAN bus to monitor whether there will be Flexray bus information triggering CAN bus information
5) After 5 hours of testing, the current data was stable, the Flexray bus did not experience any crashes, and the parallel CAN bus did not trigger any sensitive information.
Expected result
Generate a series of random or semi-randomFlexraybus data packets through a script and send them to the system, without any crashes or other unexpected results
Test results
through
Attachment
4.1.3 LIN Bus Fuzz Testing
Test CaseID
CM1E-FUZZ-03
Safety objectives
CSG-06
Test case description
The script generates a series of random or semi-randomLINbus data packets and sends them to the system to see if crashes occur or exhibit other unexpected results
Execution steps
1) Write a fuzz testing script for LIN, which will randomly change the PID from 0x00 to 0x3F, vary the length of data from 0 to 8 bytes, and randomly change each byte of data from 0x00 to 0xFF, sending a total of 100,000+ data.
2) Switch the upper computer'sLINmode tomaster
3) Start the script and connect to the host computerAPI, and send through the host computer software
4) Randomly send1W+ frames, LIN bus data function is normal
5）During the fuzz testing process, the device did not experience any power loss.
Expected result
The script generates a series of random or semi-randomLINbus data packets and sends them to the system, which should not crash or exhibit any other unexpected results
Test results
through
AppendixA Version Update List
Version information
Author information
Content description
V1.0
Xu Derong, Huang Yilong, Linghu Jiaqi
Write test cases
V1.1
Xu Derong, Huang Yilong, Linghu Jiaqi
Modify and supplement the report content
V1.2
Xu Derong, Huang Yilong, Linghu Jiaqi
Retest of partially fixed content
AppendixB Description of Penetration Testing Risk Levels
The classification method for risk levels is described as follows:
Serious: It directly leads to system intrusion or data destruction, and once it occurs, it is a serious security incident.
Medium: It may lead to the leakage of important information, denial of service, or a high likelihood of system intrusion and control.
Light: Sensitive information leakage or minor security issues, generally will not lead to serious security incidents.
AppendixC CVSSScoring Standards
Metric grouping
Metric Name (Abbreviation)
Value range
Mandatory
Brief description
Foundation
Attack Vector(AV)
[N,A,L,P]
是
Attack Vector（Attack Vector）describes the maximum path through which the vulnerability can be exploited based on the relevant contextual scenario.
Attack Complexity(AC)
[L,H]
是
Attack Complexity describes the level of complexity for an attacker to exploit a vulnerability.
Permission Requirements(PR)
[N,L,H]
是
Privileges Required describes the special permissions that an attacker must have in order to exploit the vulnerability.
User Interaction(UI)
[N,R]
是
User Interaction (User Interaction) describes whether triggering the vulnerability requires the cooperation of other users besides the attacker.
Range(S)
[U,C]
是
范围（Scope）describes the impact on the scope of the test component after the vulnerability has been successfully exploited, whether it only affects the component itself or also impacts other components outside the vulnerable component.
Confidentiality Impact(C)
[H,L,N]
是
Confidentiality Impact (Confidentiality Impact) describes the impact on the confidentiality measures of information and systems in the tested component after a vulnerability is successfully exploited.
Impact on Integrity(I)
[H,L,N]
是
Integrity Impact (Integrity Impact) describes the impact on the integrity of information and systems in the tested component after the vulnerability is successfully exploited.
Availability Impact(A)
[H,L,N]
是
Availability Impact（可用性影响）describes the impact on the availability of the test component after the vulnerability is successfully exploited.
