[Dreamhack] Grand Theft Auto Write-up

1. Grand Theft Auto

<문제 설명>

<문제 파일>

2. Explanation

 문제를 직관적으로 보았을 때 몇 가지를 유추해 볼 수 있다. can0 뒤에 오는 7E0과 7E8은 후에 오는 데이터를 보내는 주체로 해석할 수 있으며 뒤에 오는 16진수 데이터가 8자리 즉, 8바이트 이므로 [8]은 뒤의 데이터의 크기임을 유추해볼 수 있다.

 또한, F1 90이 공통적으로 7E0과 7E8의 시작 부분(앞 부분)에 위치 해 있으므로 직접적인 데이터라기 보다는 CAN 프로트콜의 구조적 의미를 지니고 있음을 유추할 수 있다. 

 

물론 앞서 서술된 내용은 정확한 정보가 아닌 그저 직관적인 유추에 불과하다.

---

can0는 CAN(Controller Area Network)의 인터페이스 ID이다. 예전에 CAN bus injection 내용을 학습할 때 리눅스 환경에서 candump를 확보하였는데 dump할 장치 이름을 나타낸다.

<첫번째 line인 Single Frame (Request)>

우선 첫번 째 line을 보면 7E0이라는 ID에서 8바이트 데이터를 전송하였다. 맨 앞 상위  4bit가 0이므로 이는 Single Frame이며 Single Frame의 구조에 맞추어 해석해본다. 후에 오는 4bit인 3을 통하여 3바이트 길이의 데이터를 보낸다는 것을 알 수 있다(0x03).

이제 전달한 데이터 실질적 데이터인 22 F1 90을 살펴본다.

22는 RDBI(Read Data By Identifier)로 UDS 프로토콜 ISO 14229의 SID(Service Identifier)이다. 이는 UDS 프로토콜에 정의되어 있으며 이를 통하여 차량에 대한 세부 데이터를 얻을 수 있다.

 

<F1 90>

F1 90은 문제의 참고자료 URL에서 검색해보면 VIN Data Identifier임을 알 수 있다.

차량의 ECU 내부에 차량 고유의 정보가 담긴 17바이트의 번호를 저장하는데 위는 이 VIN 번호를 요청하는 내용임을 알 수 있다.

---

<두번째 line인 First Frame(response)>

이제 candump의 두번 째 줄을 해석해본다.

첫 4비트가 1로 시작하므로 7바이트 이상의 데이터를 전달하는 다중 프레임 메세지 패킷(Multi-Frame message packet)이며 이 중에서 First Frame에 해당한다. (다중 프레임 메세지 패킷은 First Frame, Consecutive Frame, Flow Control Frame으로 구성)

 

ISO-TP에서의 Frame 유형

• Single Frame: 전송하려는 데이터 길이가 7바이트 이하일 때 사용
• First Frame: 8바이트 이상의 데이터 전송, 다중 프레임 메세지 패킷 전송 시 시작하는 프레임
• Consecutive Frame:  다중 프레임 메세지 패킷에서 First Frame 이후 데이터
• Flow Control Frame: 다중 프레임 메세지 패킷에서의 흐름 제어

First Frame의 상위 4비트는 항상 1이며 이후에 오는 12비트로 전달하는 데이터의 길이(Data Length)를 나타낸다. 여기서는 0 14로 20바이트임을 알 수 있다.

62는 앞서 요청한 22 SID에 대한 응답 SID이며 F1 90 즉, VIN에 대한 정보를 담고 있다는 것을 알고 있다.

따라서 실질적으로 VIN에 대한 정보는 57부터 시작한다(57 44 44).

---

<세 번째 line인 Flow Control Frame>

세 번째 줄은 전송 흐름을 제어하기 위한 Flow Control Frame으로 "계속해서 수신"하라는 의미로 해석할 수 있다.

맨 앞의 1바이트에 대한 정보는 다음과 같다.

 

• 0x30: Continue to Send
• 0x31: Wait
• 0x32: Overflow

---

<네 번째와 다섯 번째 line인 Consecutive Frame>

 

Consecutive Frame는 2로 시작하며 1은 시퀸스 번호이다. 21이후 나머지 바이트는 payload(VIN 정보)이다.

마찬가지로 다섯 번째 line도 Consecutive Frame이므로 2로 시작하며 2는 마찬가지로 시퀸스 번호이며 이후에 데이터들이 payload(VIN 정보)이다.

---

따라서 VIN정보가 담겨있는 payload를 종합해보면 

• 두번째 라인에서의 57 44 44
• 네번째 라인에서의 48 46 35 47 42 35 42
• 다섯번째 라인에서의 41 32 37 30 38 36 36

총 17바이트로 VIN의 길이와 일치한다.

57 44 44 48 46 35 47 42 35 42 41 32 37 30 38 36 36

위 데이터를 아스키 코드로 변환하면

<아스키 코드로 변환 결과>

WDDHF5GB5BA270866가 되며 다시 VIN 디코더를 사용하면

 

<VIN 정보로 차량 정보 확인 결과>

 

위와 같으며 따라서 flag는 DH{2011_Mercedes-Benz_E-Class}가 된다.

DH{2011_Mercedes-Benz_E-Class}

 

3. Reference

0x22

https://piembsystech.com/read-data-by-identifier-0x22-service-in-uds-protocol/

 

ISO-TP

https://blog.naver.com/PostView.naver?blogId=suresofttech&categoryNo=0&currentPage=1&logNo=222850407600&parentCategoryNo=0

 

문제에서의 참고자료 UDS 프로토콜

https://piembsystech.com/data-identifiers-did-of-uds-protocol-iso-14229/

 

VIN 디코더

https://www.vindecoder.net/vin-check/WDDHF5GB5BA270866