디스어셈블리 없이 9S12HY64 펌웨어의 정적 데이터 수정하기
MC9S12HY64 마이크로컨트롤러 기반 자동차 계기판의 표시기능을 변경하는 것은 I²C 트래픽 분석과 SREC 펌웨어 파일 패치를 통해 가능하다. 이 방법은 코드를 완전히 디스어셈블링할 필요 없이, Ghidra를 활용해 정적 데이터 내 서명을 식별하는 데 집중한다. 목표는 문자 A를 P로, M을 D로 교체하면서 숫자 아티팩트를 제거하는 것이다.
하드웨어 분석 및 프로토콜
9S12HY64 마이크로컨트롤러는 외부 드라이버 없이 6핀 인터페이스를 통해 디스플레이에 연결된다. 회로 추적과 사양서를 통해 I²C 프로토콜임이 확인된다. Saleae 로직 분석기를 사용해 변속기 선택 모드 전체에서 MCU와 디스플레이 간의 트래픽을 캡처한다.
트래픽 요약 표에서는 잠재적인 서명으로 사용될 수 있는 변화하는 바이트를 확인할 수 있다:
- 모드 A1: 5A C9 9A 8D...
- 모드 M1: 5A C9 9A 8D... (첫 번째 바이트의 변형)
빨간색 강조된 바이트는 펌웨어 내 검색 대상이며, 2차원 배열 형태의 정적 메시지 페이로드를 나타내는 것으로 가정된다.
펌웨어 내 서명 찾기
Ghidra를 사용해 HCS12 디스어셈블리 없이 헥스 검색을 수행한다. 서명 0x5A, 0xC9, 0x9A, 0x8D는 특정 메모리 영역을 지목한다. 메시지 형식은 디스플레이 바이트 번호 + 데이터이다.
트래픽과 메모리 매핑:
- 첫 번째 바이트는 세그먼트(A/M)를 식별한다.
- 이후 바이트들은 문자 패턴을 정의한다.
새로운 계기판 펌웨어에서 P와 D에 대한 메시지를 추출한 결과:
- P: 1바이트 교체
- D: 2바이트 보정
메시지 비교:
| 모드 | 원본 메시지 | 목표 메시지 |
|------|------------------|----------------|
| A1 | 5A C9 9A 8D... | 5A XX XX 8D... (P) |
| M1 | 5A C9 9A 8D... | 5A YY ZZ 8D... (D) |
SREC 파일 패치
SREC 구조: 헤더, 주소, 데이터, 체크섬. 바이트 변경 시 체크섬(KS) 재계산이 필요하다.
KS 계산을 위한 파이썬 스크립트:
# 예시 스크립트 (GitHub에서 수정)
def calc_srec_checksum(line):
# 바이트 합산 후 역전
s = sum(bytes.fromhex(line[1:-1])) # S와 KS 제외
return format((~s + 1) & 0xFF, '02X')
변경 사항:
- P: 한 줄의 첫 번째 바이트 수정
- D: 두 줄의 첫 번째 및 두 번째 바이트 조정
KS 재계산 후, 부분적 교체가 이루어지지만 숫자 아티팩트가 남아 있다.
숫자 아티팩트 제거
숫자(1–5)는 다음과 같은 방식으로 생성된다: 00번째 바이트 + 12번째 바이트의 니블(기준 0x80 + 값). 숫자 서명을 펌웨어 내에서 검색하고, '4'에 해당하는 데이터를 0으로 설정(1, 2, 3은 유지).
- 형식: 바이트 번호 – 데이터
- 수정된 줄에 대해 KS 재계산
최종 펌웨어는 숫자 없이 완전한 P/D 에뮬레이션을 제공한다.
핵심 포인트
- I²C 트래픽 스니핑은 코드 분석 없이 정적 데이터를 찾는 데 가능하게 한다.
- Ghidra 헥스 검색은 HCS12과 같은 미지 아키텍처에서도 효과적으로 작동한다.
- SREC 패치는 유효성을 위해 정확한 체크섬 처리가 필수다.
- 방법은 시리얼 프로토콜을 사용하는 다른 임베디드 시스템에도 확장 가능하다.
- 수정된 코드 실행을 피함으로써 위험도를 낮춘다.
— Editorial Team
아직 댓글이 없습니다.