This is a bilingual snapshot page saved by the user at 2024-11-21 17:50 for https://app.immersivetranslate.com/word/, provided with bilingual support by Immersive Translate. Learn how to save?


Borgwarner CM1EPenetration Testing ReportV1.2


Borgwarner CM1EPenetration Testing Report


Number:IC-XXX


Version:V1.2


Catalog


1. Project Introduction3


1.1 Test Background3


1.2 Test Object4


1.3 Tester Information7


1.4 Test Results7


1.5 Terminology8


2. Introduction to Security Testing9


2.1 Test Reference Basis9


2.2 Test Process Description9


3. Information Security Penetration Testing10


3.1 Hardware Security10


3.2 Software Security21


3.3 Safe Start30


3.4 Security Upgrade33


3.5 FlexrayCommunication Security42


3.6 LINCommunication Security71


3.7 Data Storage77


3.8 Firmware Vulnerability Scanning88


3.9 CANBusUDSDecryption Test90


3.10 CAN/CANFDCommunication Security111


3.11 Security Log126

3.12 SecOC130


4. Bus Safety Fuzz Testing144


4.1.1 CANBus Fuzz Testing144


4.1.2 FlexrayBus Fuzz Testing149


4.1.3 LINBus Fuzz Testing152


AppendixA Version Update List153


AppendixB Explanation of Penetration Testing Risk Levels154


AppendixC CVSSScoring Standards154

2


1. Project Introduction


1.1 Test Background


Test object

Borgwarner CM1E


Test content


Test item


Test environment


Start time


End time


Hardware security testing


Test bench


September1st


11Month21Day


Software security testing


Test bench


September1st


11Month21Day


Safe Boot Test


Test bench


September1st


11Month21Day


Security upgrade testing


Test bench


September1st


11Month21Day


FlexrayCommunication Security Testing


Test bench


September1st


11Month21Day


LINCommunication Security Testing


Test bench


September1st


11Month21Day


Data storage testing


Test bench


September1st


11Month21Day


Firmware vulnerability scanning


Test bench


September1st


11Month21Day


CANFault Injection Testing


Test bench


September1st


11Month21Day

SecOC


Test bench


September1st


11Month21Day


Fuzz testing for information security


Test bench


September1st


11Month21Day


Test type


Security penetration testing


1.2 Test Object


1.2.1 Component Information


Test component name


Software version

Borgwarner CM1E

SOC: /

MCU: cm1e_23N5_app_filled_merged_exclusive_asw.s19


1.2.2 Main Testing Tools


Category


Testing tool


Purpose


Manufacturer


Version


hardware


JLINKProgramming Tool


Test Secure Boot/Flashing


GermanySEGGER Company

V9


Vehicle Ethernet converter


Convert the vehicle Ethernet to standardRJ45Ethernet


Pinnacle Intelligence Technology Co., Ltd

100BT1

ZLG USB CAN


Used for analysisCANLINprotocol


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. 155Uniform 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


2PCB boards do not have reservedDAP debugging interfaces by default. To facilitate testing, the debugging ports have been pre-soldered.


3However, 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


2STThe 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 aUART pin connection


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


2JTAGrelated 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


2TJA1145chip is a high-speedCANtransceiver, not aflashchip


3A1027isLinbus related chip


495260eis a clock generator


5VQ7050A 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


2JTAGrelated 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.


3DAPdebug 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 R2R0as 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 R2R0 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.


3In 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


3In 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 bootthe 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-modify4DModifyFF


VCU_ESS_20210709_signed_dev-modify56ModifiedFF


miniapp_v03_dev-modify19modifiedFF


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


Execution steps


1) ConnecttheCANoetool (VN7610) totheVCUunder test’sFlexraybus


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.

CVSS


CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H5.5 Medium


3.5.3 [Low-risk Vulnerability]FlexrayBus Malicious Message Injection Attack


Test CaseID

CM1E-Flexray-03


Safety objectives

CSG-05


Test case description


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

CVSS


CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:N/A:N2.5Low Risk)


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


Test results


through


3.5.6FlexraySafety DiagnosisDisconnectionSeedRandomness TestTest


Test CaseID

CM1E-Flexray-06


Safety objectives

CSG-06


Test case description


Test the security diagnosis of27through brute force traversal, attempting to obtainseedand testseedfor true randomness


Execution steps


1Connectflexray bus interface to the gateway device, and diagnostics and debugging of theflexray bus can be performed through the gateway


2) Through27 05obtainseed, as shown to obtain27service'sseed


3) Batch obtainseed, write to file


4) Usedieharderrandom number compliance scanning tool to scan the samples,diehardercore indicators passed (for details, refer to the attachment)


Expected result


Flexraybus has secure access control, andthe seedis truly random


Test results


through


Attachment


3.5.7FlexrayHard Reset(0x11)Function Enable Permission Verification


Test CaseID

CM1E-Flexray-07


Safety objectives

CSG-07


Test case description


Send hard reset(0x11)Function command to test for the existence of security checks or restrictions


Execution steps


1) UseCANoe7610toconnectwiththeFlexraybus ofthe ECU


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


Execution steps


1) UseCANoe7610toconnectwiththeFlexraybus ofthe ECU


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


Execution steps


1) UseCANoe7610toconnectwiththeFlexraybus ofthe ECU


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


Execution steps


1) UseCANoe7610toconnectwiththeFlexraybus ofthe ECU


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


Test results


through


3.6 LINCommunication Security


3.6.1 [Low Risk Vulnerability]LINBus PacketSensitivitySniffing


Test CaseID

CM1E-LIN-01


Safety objectives

CSG-07


Test case description


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:

id0x30

id0x01

id0x37

id0x1C

id0x38

id0x39

...


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 similarbroadcastmanner 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

CVSS


CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N3.3 Low Risk)


3.6.2 LIN BusDoSAttack


Test CaseID

CM1E-LIN-02


Safety objectives

CSG-07


Test case description


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 many