차량 ECU 업데이트는 실제로 어떻게 진행될까? (Flashing 구조 이해하기)

차량 진단 통신 시리즈 04

이전 편 | UDS의 Diagnostic Session은 왜 필요할까?

리콜 공지를 받고 정비소를 찾아가면 정비사가 말합니다.
"ECU 소프트웨어 업데이트 하나 하면 됩니다. 30분이면 돼요."

그 30분 동안 차 안에서는 무슨 일이 벌어지는 걸까요?

지금까지 UDS, Security Access, Diagnostic Session을 배웠습니다.
이 세 가지가 모두 맞물리는 장면이 바로 ECU 플래싱(Flashing)입니다.

이번 편에서는 펌웨어가 ECU에 설치되는 전 과정을
처음부터 끝까지 단계별로 들여다봅니다.

플래싱이란 무엇인가

플래싱(Flashing)은 ECU의 플래시 메모리에 새로운 펌웨어를 기록하는 작업입니다. 스마트폰에 비유하면 OS 업데이트와 비슷하지만, 훨씬 낮은 레벨에서 직접 메모리에 데이터를 씁니다.

구분	스마트폰 OS 업데이트	ECU 플래싱
업데이트 방식	인터넷으로 패키지 다운로드 후 설치	진단기·OTA로 직접 플래시 메모리에 기록
실패 시 결과	재시도 가능, 최악의 경우 부팅 루프	ECU Brick — 차량 시동 불가, 견인 필요
업데이트 중 중단	대부분 복구 가능	메모리 손상, 최악의 경우 ECU 교체 필요
진행 시간	수 분 ~ 수십 분	수 분 ~ 1시간 (ECU 용량, 통신 속도에 따라 다름)
보안 요건	Google·Apple 서명 검증	OEM 코드 서명 + Security Access + Secure Boot

ECU 플래싱이 실패하면 단순한 불편이 아닙니다. 브레이크나 에어백 ECU가 Brick 상태가 되면 차량을 아예 운행할 수 없습니다. 그래서 플래싱은 단계마다 검증하고, 실패 시 복구할 수 있는 구조(Dual Bank)를 갖추는 것이 중요합니다.

플래싱을 이해하려면 메모리 구조를 알아야 한다

ECU 플래시 메모리는 역할에 따라 여러 영역으로 나뉩니다. 어느 영역에 무엇을 쓰느냐에 따라 플래싱의 방식과 위험도가 달라집니다.

ECU 플래시 메모리 구조 (일반적인 예시)

Boot Software (Bootloader) 절대 소거 불가 영역 — 플래싱 자체를 관장

Application Software (Bank A) 현재 실행 중인 펌웨어

Application Software (Bank B) Dual Bank: 새 펌웨어 수신 영역

Calibration Data 차량별 파라미터 (소거 주의)

NVM / Application Data DTC, 주행 이력, 적응값

Bootloader 영역은 플래싱 작업 자체를 관장하는 소프트웨어가 있는 곳입니다. 이 영역이 손상되면 새 펌웨어를 받을 수도 없게 됩니다. 그래서 Bootloader 영역은 일반 플래싱 작업으로 소거할 수 없도록 하드웨어 수준에서 보호하는 경우가 많습니다.

Bootloader — 플래싱을 가능하게 하는 작은 운영 환경

ECU는 일반 애플리케이션 소프트웨어만으로는 자기 자신을 업데이트할 수 없습니다. 실행 중인 코드가 자기 자신이 저장된 메모리를 지우는 것은 구조적으로 불가능하기 때문입니다.

그래서 Bootloader가 존재합니다. Bootloader는 ECU 업데이트를 수행하기 위한 별도의 작은 실행 환경입니다. Programming Session으로 전환되면 ECU는 Application 소프트웨어 대신 Bootloader를 실행 상태로 전환하고, Bootloader가 실제 플래싱 작업을 수행합니다.

Bootloader 역할	설명
통신 초기화	CAN, DoIP 등 진단 통신 스택을 초기화하고 테스터 요청을 수신
Flash 제어	메모리 소거(Erase)와 쓰기(Write) 직접 수행
무결성 검증	수신된 펌웨어의 CRC·서명 검증
복구 모드	플래싱 실패 시 이전 펌웨어로 복구(Dual Bank 활용)
Application 전환	플래싱 완료 후 Application 소프트웨어로 제어권 이전

Bootloader 자체도 업데이트가 필요할 수 있습니다. 하지만 Bootloader를 업데이트하는 것은 훨씬 더 위험한 작업입니다. Bootloader가 손상되면 ECU를 복구할 방법이 없기 때문에, 공장에서 특수 장비로만 가능하거나 아예 허용하지 않는 경우도 있습니다.

전체 플래싱 흐름 — 단계별로 보기

ECU 플래싱은 크게 사전 준비 → 메모리 소거 → 데이터 쓰기 → 무결성 검증 → 사후 처리의 5단계로 진행됩니다.

1

사전 준비 — 세션 전환 · Security Access · 사전 검사

플래싱이 시작되기 전, 앞서 배운 세션 전환과 Security Access가 이루어집니다. 그 전에 ECU는 플래싱이 가능한 상태인지 확인합니다. 차량 속도, 배터리 전압, 현재 DTC 상태 등이 조건에 맞지 않으면 진입 자체를 거부합니다.

테스터 10 02 Programming Session 전환

ECU 50 02 ... 전환 완료

테스터 27 01 Security Access Seed 요청

ECU 67 01 [Seed] Seed 반환

테스터 27 02 [Key] Key 전송 → 인증 성공

2

메모리 소거 — RoutineControl (0x31)

새 펌웨어를 쓰기 전에 대상 메모리 영역을 지워야 합니다. 플래시 메모리는 쓰기 전에 반드시 소거(Erase)가 필요한 특성이 있습니다. 소거는 보통 섹터(Sector) 단위로 이루어지며, 몇 초에서 수십 초가 걸립니다. 이때 0x78 ResponsePending이 반복 전송됩니다.

테스터 31 01 FF 00 [주소] [크기] 메모리 소거 루틴 시작

ECU 7F 31 78 0x78: ResponsePending — 아직 소거 중

ECU 71 01 FF 00 소거 완료 응답

3

데이터 전송 — RequestDownload(0x34) + TransferData(0x36)

소거가 완료되면 본격적인 데이터 전송이 시작됩니다. RequestDownload로 전송 파라미터를 협상하고, TransferData로 펌웨어를 블록 단위로 쪼개어 전송합니다. 블록 번호(Block Sequence Counter)로 순서와 누락을 추적합니다.

테스터 34 00 44 [주소] [크기] 다운로드 시작 요청 (압축 없음, 주소, 전체 크기)

ECU 74 20 04 00 최대 블록 크기 1024바이트 허용

테스터 36 01 [1024 bytes data] 블록 1 전송

ECU 76 01 블록 1 수신 완료

테스터 36 02 [1024 bytes data] 블록 2 전송 ... 반복

테스터 37 전송 완료 (RequestTransferExit)

ECU 77 전송 종료 확인

4

무결성 검증 — RoutineControl (0x31) 체크섬

전송이 완료되면 ECU는 수신된 데이터의 체크섬(CRC)을 계산해 원본과 비교합니다. 전송 중 비트 오류나 데이터 손상이 있었다면 여기서 발견됩니다. 또한 디지털 서명 검증도 이 단계에서 수행됩니다 — OEM의 서명 없는 펌웨어라면 여기서 차단됩니다.

테스터 31 01 02 02 [주소] [크기] [예상 CRC] 체크섬 검증 루틴 실행 요청

ECU 71 01 02 02 00 검증 성공 (0x00: OK)

ECU 71 01 02 02 01 (실패 시) 체크섬 불일치 — 재전송 필요

5

사후 처리 — ECUReset · Secure Boot 검증

모든 검증이 통과되면 ECU를 재시작합니다. 재부팅 시 Secure Boot가 새로 설치된 펌웨어의 서명을 한 번 더 검증합니다. 이 최종 검증까지 통과해야 새 펌웨어로 정상 동작합니다.

테스터 11 01 ECUReset (Hard Reset)

ECU 51 01 리셋 진행 확인 → Secure Boot 시작

플래싱이 중단되면? — Dual Bank 구조

플래싱 도중 전원이 끊기거나 통신이 단절되면 어떻게 될까요? 만약 단일 메모리 구조라면 절반만 쓰인 상태에서 멈춰 ECU가 Brick이 됩니다.

이를 방지하는 것이 Dual Bank 구조입니다. 메모리를 두 파티션으로 나눠, 현재 실행 중인 Bank A에서 계속 정상 동작하면서 Bank B에 새 펌웨어를 씁니다. 모든 검증이 완료된 후에야 부팅 파티션을 Bank B로 전환합니다.

상황	단일 Bank	Dual Bank
플래싱 중 전원 차단	ECU Brick — 복구 불가	Bank A로 자동 복구, 재시도 가능
체크섬 검증 실패	잘못된 펌웨어로 부팅 시도	Bank A 유지, Bank B 폐기 후 재시도
Secure Boot 실패	부팅 불가	이전 Bank로 Fallback
메모리 용량	작게 필요	Application 영역 2배 필요

Dual Bank는 OTA 업데이트에서 특히 중요합니다. 정비소에서는 실패하면 즉시 재시도할 수 있지만, OTA는 차량이 주차된 상태에서 무인으로 진행됩니다. 중간에 실패해도 차량이 정상 동작 상태를 유지해야 합니다.

플래싱의 보안 체크포인트들

ECU 플래싱은 이 시리즈에서 다룬 모든 보안 요소가 맞물리는 지점입니다. 각 체크포인트가 어느 단계에서 무엇을 막는지 정리하면 이렇습니다.

• 🔒
  Programming Session 진입 조건 차량 정지, 배터리 전압 정상 등 물리적 조건을 먼저 확인합니다. 주행 중 플래싱을 원천 차단합니다.
• 🔑
  Security Access 인증 시드-키 방식으로 인증된 진단기만 플래싱 서비스에 접근할 수 있습니다. 인증 실패 시 일정 시간 잠금됩니다.
• ✍️
  코드 서명 검증 (Secure Flash) OEM 개인키로 서명된 패키지만 받아들입니다. 체크섬 루틴과 서명 검증을 통해 변조 여부를 확인합니다.
• 🔁
  안티 롤백 (Anti-Rollback) 현재 버전보다 낮은 펌웨어의 설치를 차단합니다. 다운그레이드 공격으로 이전 취약점을 복원하는 것을 막습니다.
• 🚀
  Secure Boot 재검증 ECUReset 후 부팅 시 새로 설치된 펌웨어의 서명을 한 번 더 검증합니다. 플래싱 이후 변조가 발생했더라도 여기서 차단됩니다.

이 다섯 가지 체크포인트가 모두 동작해야 "안전한 플래싱"이라고 할 수 있습니다. 하나라도 빠지면 공격 경로가 생깁니다. OEM이 Tier-1에 요구하는 보안 요구사항의 상당 부분이 이 체크포인트들을 구현하고 검증하는 내용입니다.

현업에서는 실제로 이렇게 경험한다

블록 크기 협상이 성능에 큰 영향을 준다 — RequestDownload에서 협상하는 블록 크기가 전체 플래싱 시간을 결정합니다. CAN 기반(최대 4095바이트)보다 Ethernet/DoIP 기반이 훨씬 큰 블록을 전송할 수 있어 속도 차이가 납니다. 수백 MB 펌웨어를 CAN으로 플래싱하면 몇 시간이 걸릴 수도 있습니다.

ResponsePending(0x78) 처리가 빠지면 타임아웃이 발생한다 — 메모리 소거나 검증처럼 시간이 오래 걸리는 작업 중 ECU는 0x78을 주기적으로 보내 "아직 처리 중"임을 알려야 합니다. 진단 소프트웨어가 이 응답을 올바르게 처리하지 않으면 P2 타임아웃으로 오류가 발생합니다. 이 타이밍 구현이 현장에서 생각보다 자주 문제가 됩니다.

Calibration 데이터 보호가 까다롭다 — 펌웨어(Application)를 업데이트할 때 Calibration 데이터(차량별 파라미터)를 실수로 소거하면 차량이 비정상 동작합니다. 소거 루틴의 주소 범위를 정확히 지정해야 하고, 경우에 따라 Calibration을 먼저 백업하고 복원하는 절차가 필요합니다.

V&V에서 실패 시나리오 검증이 핵심이다 — 정상 플래싱 성공 테스트는 쉽습니다. 진짜 중요한 건 실패 케이스입니다. 체크섬 불일치 패키지를 보냈을 때 거부하는지, 서명 없는 펌웨어를 차단하는지, 플래싱 중 전원을 끊었을 때 Dual Bank로 복구되는지를 모두 검증해야 합니다.

마무리

ECU 플래싱은 UDS 진단 통신의 모든 요소가 하나로 맞물리는 작업입니다.
세션 전환, Security Access, 코드 서명, Dual Bank, Secure Boot —
이 다섯 가지가 순서대로 맞물려야 안전한 업데이트가 완성됩니다.

정비소에서의 "30분 업데이트" 뒤에는 이런 과정이 숨어있습니다. 그리고 이 과정 중 하나라도 허술하면, 정비소 방문이 공격자의 진입 기회가 될 수 있습니다.

다음 편에서는 이 모든 진단 요청이 ECU에 도달하기 전에 중간에서 걸러내는 Gateway ECU의 역할을 다룹니다.

핵심 요약

• 플래싱은 ECU 플래시 메모리에 새 펌웨어를 기록하는 작업 — 실패 시 ECU Brick 위험
• 5단계: 사전 준비(세션·SA) → 메모리 소거 → 데이터 전송 → 무결성 검증 → ECUReset
• 데이터 전송은 RequestDownload(0x34) → TransferData(0x36) → RequestTransferExit(0x37)
• Dual Bank로 플래싱 중 실패해도 이전 펌웨어로 자동 복구 가능
• 보안 체크포인트: Programming Session 조건 → Security Access → 코드 서명 → 안티 롤백 → Secure Boot
• ResponsePending(0x78)으로 긴 작업 중 타임아웃을 방지한다
• V&V에서 실패 케이스(변조 패키지 거부, Dual Bank 복구) 검증이 핵심이다

차량 진단 통신 시리즈

1

자동차 ECU는 정비소와 어떻게 대화할까? — UDS 진단 통신 쉽게 이해하기

2

자동차는 왜 진단 인증(Security Access)을 사용할까?

3

UDS의 Diagnostic Session은 왜 필요할까?

4

차량 ECU 업데이트는 실제로 어떻게 진행될까? — Flashing 구조 이해하기  ← 현재 글

5

Gateway ECU는 왜 진단 요청을 차단할까?

ECU플래싱 Flashing UDS RequestDownload TransferData DualBank SecureFlash ISO14229 차량보안기술 SecureBoot AntiRollback