UDS를 통한 Flash Backup & Restore 근거 자료

OVERVIEW

시스템 구조와 리프로그래밍 흐름

Tester → CAN·ISO-TP → BswCom → BswDcm → RTE → ECU Abstraction → MCAL → PFlash·DFlash

Programming Session · DiagnosticSessionControl(0x10) → SecurityAccess(0x27) → Erase·Backup · RoutineControl(0x31) → RequestDownload(0x34) → TransferData(0x36) → RequestTransferExit(0x37) → SHA-256 확인 → ECUReset(0x11)

당시 구현 범위

• Application Primary를 Backup 영역으로 복사
• Primary Erase 후 신규 SW Binary 기록
• valid pattern 확인과 SHA-256 비교 분기 구현 — 기록 순서 결함은 이후 정적 리뷰에서 발견
• 검사 실패 시 Backup을 Primary로 복구
• TransferData의 Block Sequence 처리 분기 구현 — 오류 입력 시험의 공개 근거는 제한적

아래는 교육 당시 구현과 기록의 정리입니다. 이후 발견한 길이 상한·권한 검사 누락과 valid pattern 기록 순서 문제는 CODE REVIEW에 구분했습니다. 개선안은 적용·빌드·ECU 검증하지 않았으며, 정상 경로의 동작 기록이 모든 실패 조건에서의 안전성을 뜻하지 않습니다.

MEMORY MAP

AURIX TC234LP Bootloader의 PFlash·DFlash 구획과 Backup·Restore 방향을 실제 링커 주소로 정리했습니다.

영역 정의

근거

#define INTTAB     0x80026000
#define RESET      0x80000020
#define IFXTRAPTAB (INTTAB + 0x1800)

memory pflash_app_valid {
    size = 32;
    map cached(dest_offset=0x8017FFE0, size=32);
}

memory pflash_app_backup {
    size = 512k;
    map cached(dest_offset=0x80180000, size=512k);
}

Bootloader 링크 설정에서 Application과 Backup은 reserved rom으로 선언되어 Bootloader 코드가 해당 영역에 배치되지 않습니다. SHA-256은 이 프로젝트에서 Binary 변경 여부를 판단하는 무결성 검사로 사용했습니다.

UDS SEQUENCE

UDS 7개 서비스의 대표 호출 흐름과 Backup·Restore 분기를 요약했습니다. 전체 오류 처리의 완전성이나 안전성을 입증하는 시퀀스는 아닙니다.

서비스 순서

RoutineControl 실제 정의

#define RID_CheckProgrammingDependencies 0x0001u
#define RID_EraseMemory                  0x0002u
#define RCOR_EraseMemory_App             0xF001u

31 01 00 02 F0 01
|  |  |-----| |---|
SID   RID       RCOR

BswDcm
→ Rte_Call_BswDcm_rEcuAbsFls_erasePflashBlock()
→ REoiEcuAbs_pEcuAbsFls_erasePflashBlock()
→ EA_erasePflashBlock()

설계 의도와 당시 구현의 차이: SHA-256 불일치 시 EA_AppRestore()를 호출하는 복구 분기는 구현했지만, RequestTransferExit에서 해시 검증 전에 valid pattern을 기록했습니다. 검증 성공 후에만 valid pattern을 기록하도록 바꾸는 것은 미적용 개선안입니다. 이 자료는 불일치·전원 중단 상황에서 신규 Application 부팅이 항상 차단된다고 주장하지 않습니다.

TEST RESULTS

각 시험의 판정과 근거 유형을 별도 열로 표시했습니다. 아래 결과는 교육 당시 기록을 정리한 것으로, 현재 환경에서 새로 실행한 시험 결과가 아닙니다.

기록상 PASS는 당시 실행·재검증 기록에 통과 결과가 서술된 항목입니다. 현재 재시험이나 독립 검증을 뜻하지 않으며, 원본 로그가 공개되지 않은 경우도 근거 유형에 표시합니다. 정적 확인은 코드·설계 기록만 확인한 것으로 실행 시험 통과가 아닙니다. 근거 부족은 수행 서술은 있으나 판정을 뒷받침할 자료가 부족한 경우, 실행 미확인은 실행 여부부터 확인할 수 없는 경우입니다. 기록 부재를 미실행으로 단정하지 않습니다.

정리한 시험 시나리오

• 정상 UDS 다운로드 및 TransferExit 완료
• Block Sequence 불일치와 전송 중단 처리 — 실행 근거 부족 또는 정적 확인
• 변조 Binary의 SHA-256 불일치 판정
• Application 무효 시 Backup Restore 수행
• Reset 이후 실행 경로 — Restore 후 정상 진입의 별도 실행 근거 부족

테스트 케이스·결과

근거 범위

TRACE32 · RESTORE

SID 0x31 RoutineControl 처리 중 발생한 CAN 응답 중단을 Trace32의 함수 Breakpoint, Register·Variable View와 DMI Trap 정보로 추적했습니다. copyBuf, A5, DEADD가 동일한 비정렬 주소 0x7000240D를 가리키는 것을 확인해 FlsLoader_Write() source buffer의 4바이트 정렬 위반을 원인으로 특정했습니다.

Trace32 디버깅 흐름

1. 1. 증상SID 0x31 RoutineControl의 RCOR_EraseMemory_App 처리에서 EA_AppToBackup() 호출 이후 ECU의 CAN 응답이 중단됐습니다.
2. 2. 함수 BreakpointBreak.Set EA_AppToBackup 후 함수 진입과 FlsLoader_Write() 인수를 추적했습니다.
3. 3. Source address 확인Variable View의 copyBuf와 Register A5가 모두 0x7000240D를 가리키는 것을 확인했습니다.
4. 4. Alignment Trap 확인DMI에서 ALN Error와 DEADD = 0x7000240D를 확인해 오류 주소를 교차 검증했습니다.
5. 5. Trap Vector 포착Break.Set 0x80027800++0xFF /Program /Onchip 적용 후 BTV = 0x80027800, PC = 0x80027840 상태를 확인했습니다.
6. 6. 원인static uint8 copyBuf[]의 실제 배치가 Flash Loader의 4바이트 source buffer 정렬 조건을 충족하지 못한 것으로 특정했습니다.
7. 7. 수정·재검증uint32 backing array와 uint8* view를 적용한 뒤 Application→Backup→Application 양방향 Write·Read와 SHA-256 판정을 다시 수행했습니다.

실제 디버깅 근거

아래 화면은 실제 프로젝트 수행 중 CANoe와 Trace32에서 수집했습니다. UDS 요청·응답, 함수 인수, Register, Variable View와 DMI 상태를 함께 비교해 Memory Alignment Error의 발생 주소와 원인을 확인했습니다.

UDS 응답 흐름

DiagnosticSessionControl(0x10), SecurityAccess(0x27), RoutineControl(0x31)의 요청·응답과 중단 구간을 확인했습니다.

Source address 추적

copyBuf 시작 주소와 A5, Trace32 오류 표시가 0x7000240D로 일치했습니다.

DMI Trap 분석

ALN Error와 DEADD = 0x7000240D를 확인해 정렬 위반 주소를 교차 검증했습니다.

Trap Vector Breakpoint

BTV = 0x80027800, PC = 0x80027840을 확인해 Trap Vector 범위 진입을 직접 포착했습니다.

정렬 수정 전후 코드

수정 전

static uint8 copyBuf[MEMORY_COPY_CHUNK_SIZE];

memcpy(copyBuf,
       (const void *)(MEMORY_ADDRESS_APPLICATION + offset),
       copySize);

*errorResult = (uint8)FlsLoader_Write(
    MEMORY_ADDRESS_BACKUP + offset,
    copySize,
    copyBuf);

수정 후 핵심

static uint32 copyBufAligned[
    MEMORY_COPY_CHUNK_SIZE / sizeof(uint32)
];
uint8 *copyBuf = (uint8 *)copyBufAligned;

/* uint32 backing storage: 4-byte alignment
 * uint8* view: byte-wise memcpy compatibility */

Backup·Restore 재검증

정렬 수정 후 Application Primary→Backup(EA_AppToBackup())과 Backup→Application Primary(EA_AppRestore()) 양방향 Flash Write·Read, UDS 응답 흐름과 SHA-256 판정을 다시 확인했습니다.

CODE REVIEW

기능 동작으로 끝내지 않고 완성된 C/H를 다시 읽어 입력 경계와 검증 순서를 점검했습니다. 아래는 스스로 찾아 문서화한 결함입니다.

• Critical · TransferData 길이 상한 미강제 — RequestDownload가 광고한 블록 길이는 514바이트지만 transferData()는 diagDataLengthRx < 3만 거부합니다. ISO-TP First Frame은 12bit 길이 필드로 최대 4,095바이트를 선언할 수 있어, 재조립 경로가 이를 그대로 넘기면 514바이트 버퍼에 최대 3,579바이트를 넘겨 쓸 수 있습니다.
• 신뢰 경계 · valid pattern 기록 순서 — RequestTransferExit에서 SHA-256 검증 전에 valid pattern을 기록합니다. 검증에 성공한 뒤에 기록하도록 순서를 바꿔야 합니다.
• ISO-TP 재조립 — 실제 DLC, First Frame 전체 길이, Consecutive Frame 순번과 누적 길이 경계 검사가 없습니다.
• 권한 검사 · EraseMemory — 정확한 요청 길이, Programming Session, SecurityAccess, physical request를 확인하지 않고 Primary를 삭제합니다.
• 보안 방식 — 고정 Seed/Key와 고정 키 접두어 SHA-256을 사용합니다. 보호된 키 기반 HMAC 또는 전자서명 검토가 필요합니다.

이 항목들은 게시된 소스를 정적으로 검토해 확인한 것이며, 개선안을 실제로 구현·빌드·ECU에서 검증한 결과가 아닙니다. 교육 당시 snapshot은 무결성 비교를 위해 수정하지 않고 보존했습니다.