Borgwarner CM1EPenetration Testing Report

Number:IC-XXX

Version:V1.2

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

Test component name

Software version

Borgwarner CM1E

SOC: /

MCU: cm1e_23N5_app_filled_merged_exclusive_asw.s19

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

Name

Job description

Qualification

Xu Derong

Security testing

CISP

Huang Yilong

Security testing

CISP

Linghu Jiaqi

Security testing

/

Vulnerability harm

Quantity

High-risk vulnerability

0

Medium-risk vulnerability

2

Low-risk vulnerability

3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:H（5.5 Medium）

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:N（2.5Low Risk）

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

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

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

1）Connectflexray 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

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

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

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

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

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

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:

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

CVSS

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N（3.3 Low Risk）

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

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

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