'분류 전체보기'에 해당되는 글 544건

https://joondong.tistory.com/6

CAN 프로토콜도 다른 통신 프로토콜과 마찬가지로 여러가지 전송 옵션을 규정하고 있습니다. 따라서 CAN 컨트롤러가 송수신을 시작하기 전에 어떻게 송수신할 지 미리 설정해 두어야 합니다.

전송 옵션은 CAN_MCR과 CAN_BTR에서 설정할 수 있습니다. 이 두 레지스터에 대한 설명은 CAN 레퍼런스 매뉴얼에 나와있지만 좀 더 전체적인 관점에서 이해할 수 있도록 레지스터의 비트필드의 기능을 간단히 설명한 다음에 CAN 프로토콜, 제가 알고있는 것을 약간 섞어서 다시 설명해 보겠습니다.

• BRP (Baud rate prescaler)
  : CAN 컨트롤러에 공급되는 PCLK를 분주하여 타임 퀀텀 주기를 설정합니다.
• TS1/2 (Time segment 1/2)
  : 비트 세그먼트1/2에 배정할 타임 퀀텀의 개수를 정의합니다. 즉, 비트 세그먼트1/2의 주기를 결정합니다.
• SJW (Resynchronization jump width)
  : CAN 컨트롤러는 비트 세그먼트1의 주기를 늘리고 비트 세그먼트2의 길이를 줄이는 방식으로 재동기화를 수행하는데, 이때 늘리고 줄일 시간의 길이를 타임 퀀텀 단위로 정의하는 필드입니다.

• SYNC_SEG
  : 각 비트의 하강 엣지가 이 SYNC_SEG 안에 들어 있는지의 여부로 동기를 판정합니다. (무조건 1 타임 퀀텀, 설정 불가, 나머지 세그먼트는 설정 가능)
• PROP_SEG
  : 네트워크의 물리적 지연시간을 보정하기 위해 사용됩니다. 1~8 타임 퀀텀
• PHASE_SEG 1
  : 위상 오류(위상차)를 보정하기 위해 사용됩니다. (1~8 타임 퀀텀)
• PHASE_SEG 2
  : 위상 오류(위상차)를 보정하기 위해 사용됩니다. (PHASE_SEG 1의 최대값(8) + 정보처리시간(<= 2타임 퀀텀))

제가 사용한 설정은 48MHz MCU 속도에서 아래 두개 입니다.

※ 저는 위상이라는 개념을 어떤 동일한 신호에 대해 어떤 개체가 인식하는 신호의 발생 시점이라고 이해하고 있습니다. 따라서 위상차란 두개 이상의 개체가 인식하는 어떤 신호의 시작 시점의 차이라고 알고 있습니다. 여기서 개체는 회로에서 어떤 부품이 될 수도 있고, 회로에서의 어떤 위치도 될 수 있습니다. 만약 틀렸다면 지적 부탁드립니다.

※ 그리고 주의할 점은 1비트는 어떤 세그먼트를 길게하든 짧게하든 최소 8타임 퀀텀에서 최대 25타임 퀀텀으로 구성되어야 합니다. 처음에 뭣도모르고 PHASE_SEG1/2를 1타임 퀀텀으로 해서 테스트해봤는데 통신이 되지 않았습니다. 타임 퀀텀과 세그먼트는 오실로스코프로 관찰할 수 없었지만, PHASE_SEG1/2를 1타임 퀀텀으로 설정하여 1비트가 3타임 퀀텀인 상태에서 위상차가 발생하면 SJW(최소 1타임 퀀텀)만큼 늘리거나 줄이게 되는데, 최소값인 1타임 퀀텀 조차도 3타임 퀀텀에 비해 너무 길어서 그런게 아닌가 추측해봅니다. 즉, 오차를 조정했는데 너무 많이 조정해서 또 다른 오차가 발생하게 되는 것입니다.

STM32 CAN 컨트롤러에서 세그먼트들은 1비트에서 다음과 같이 할당됩니다.

CAN RX를 사용한 이유는 앞서 설명했듯이 CAN TX에 따라 달라지는 CAN Low, CAN High 신호가 AND 게이트를 거쳐 CAN 컨트롤러와 연결된 CAN RX로 출력되면, CAN 컨트롤러가 이 신호로 버스의 상태를 모니터링하기 때문입니다. 위의 예에서 RXD는 Logic High 1비트를 출력한 후 Logic Low로 전환하고 있습니다. CAN 컨트롤러는 CAN RX 기준으로 하강 엣지(리세시브->도미넌트)가 SYNC_SEG 안에 있는지의 여부로 동기를 판정합니다. ‘전송’ 파트에서 자세히 설명하겠지만, 버스상의 어떤 노드도 신호를 보내고 있지 않은 상태(리세시브)에서 어떤 노드가 데이터 프레임을 전송하면 전송을 시작한다는 의미로 SOF 신호를 보내게 되는데 이 SOF 신호는 도미넌트 신호 입니다. 이때 CAN RX에서 하강 엣지를 탐지하게 되고 버스상의 모든 노드는 SOF 신호에 SYNC_SEG를 맞춥니다. 이때는 버스상의 모든 노드가 동기화된 상태입니다. (참고로 버스 프리 상태에서는 비트를 세그먼트로 나누어 동기를 잡지 않습니다.) 하지만 SPI 통신처럼 동기를 잡아주는 클록이 따로 없고, 신호선의 길이와 노드들의 상대적인 위치 때문에 오차가 누적되어 하강 엣지가 SYNC_SEG 밖에서 탐지되는 상황이 발생합니다. 이때 하강 엣지가 비트 세그먼트2에서 탐지되면 비트 세그먼트2의 타임 퀀텀 개수에서 SJW에서 설정한 타임 퀀텀의 개수를 빼주어 비트 세그먼트2의 주기를 줄이고, 하강 엣지가 비트 세그먼트1에서 탐지되면 비트 세그먼트1의 타임 퀀텀 개수에서 SJW에서 설정한 타임 퀀텀의 개수를 더하여 비트 세그먼트1의 주기를 늘리는 방식으로 오차를 조정합니다.

참고로 STM32 레퍼런스 매뉴얼(RM0091 837페이지)에선 비트를 판정하는 유효한 엣지를 다음과 같이 정의하고 있습니다.

A valid edge is defined as the first transition in a bit time from dominant to recessive bus level provided the controller itself does not send a recessive bit.

 

‘컨트롤러가 리세시브 비트를 보내고 있지 않다면, 유효한 엣지는 1비트 타임 안에서 도미넌트부터 리세시브 버스 레벨까지의 첫번째 전환으로 정의된다.’ 정도로 해석될 수 있는데요. 이렇게 되면 비트를 판정하는 엣지가 상승 엣지가 되어버립니다. 하지만 어떤 CAN 문서를 찾아봐도 상승 엣지에서 비트를 판정한다는 내용을 찾을 수 없었습니다. 따라서 dominant와 recessive의 위치가 바뀌어야 할 것 같습니다. 아마 레퍼런스 매뉴얼 작성자의 실수라고 생각되지만 다른 의견이 있으면 말씀해주세요.

AUTOSAR CAN 통신 스택 : AUTOS.. : 네이버블로그 (naver.com)

[그림 1] 현대오트론 mobilgene의 Import Network Design 방법(출처: 현대오트론)

[그림 2] 현대오트론 mobilgene의 CAN 통신 예시(출처: 현대오트론)

[그림 3] AUTOSAR에서 정의하는 모듈 계층

[그림 4] CAN 통신 스택의 세 가지 기능

 

[그림 8] PduR 모듈

[그림 9] PduR을 기준으로 상위는 Bus나 Controller에 의존성이 없지만,

하위부터는 특정 Bus나 Controller에 의존성을 갖게 됩니다.

[그림 10] CanIf 모듈

[그림 11] CAN 메시지 송신 시 모듈 간 호출되는 API 및 Callback 함수 정리

[AUTOSAR 시리즈] mobilgene C.. : 네이버블로그 (naver.com)

https://www.kisa.or.kr/post/fileDownload?menuSeq=2060205&postSeq=14&attachSeq=2&lang_type=KO&usg=AOvVaw0c1uUx1y2njSHclyVd9ral 

CSMS

Hyundai Head Unit Hacking · random hacks (xakcop.com)

In the previous post I have shown how to crack the official firmware for Hyundai Tucson 2020 and reverse engineer it. At the end I was thinking that I can simply modify the update package, zip it again with the same password and push it to the car. But it turned out it is not that simple. The update package is signed with an RSA key which corresponds to the daudio.x509.pem certificate and this signature is checked during the update. This is part of the Android OTA update process which is being used for updating the firmware of the entire unit (not just the car navigation). Unlike the RSA key for Ioniq 2021, this key cannot be found online (at least I haven’t found it). How can we get access to the head unit in this case? I was thinking either of these two options:

• find an exploitable bug in one of the applications
• find an exploitable bug in the Linux kernel; the head unit is running Linux 3.1.10, so this looked feasible

I had no luck with both of them. Fortunately, I found some new information which allowed me to root the head unit.

New findings

First and foremost, I realized that Hyundai is shipping the same firmware to a variety of cars. My car had the so called “Standard-class Gen5 navigation” which looks like this:

They call it “navigation” but it is basically the firmware of the entire head unit. The same firmware is shipped on different Hyundai, KIA and Genesis models manufactured in the 2018-2021 time frame.

The head unit is running on Telechips TCC893X SoC and its SDK has been leaked on the internet. There is a secret recovery mechanism which is triggered by holding the POWER button (left knob) and the MAP button upon start:

I tried it on my Hyundai Tucson 2020 and I got this nice error on the car screen:

Apparently the recovery mechanism is looking for some encrypted files on the USB drive. A simple grep for these strings leads to the lk.rom file from the update package which I have been ignoring until now. Let’s load it in Ghidra and see what’s going on.

Reversing lk.rom

LK stands for “little kernel”, a small open-source kernel which is used in many embedded platforms. The head unit is loading lk.rom at address 0x82000000. After setting the correct start address in Ghidra, we can easily identify printf functions which print a lot of useful debug info. Tracing the message "[DEBUG] U-Boot Recovery Button pushed .... \n" leads to:

Looks like the recovery mechanism is part of u-boot and its entry point is the function at 0x820589a8:

Using the debug message at line 14, we can easily infer that this function copies the u-boot code to 0x80000000 and starts it. PTR_DAT_82058a38 is the beginning address of u-boot and PTR_DAT_82058a3c is the end address:

Using these addresses, we can “extract” the u-boot code from lk.rom with the following command:

$ dd if=lk.rom skip=$((0x1055c)) count=$((0x57894-0x1055c)) bs=1 of=uboot.rom

And then analyze uboot.rom as a separate binary with start address 0x80000000 in Ghidra.

Reversing uboot.rom (part of lk.rom)

There are again many debug strings which help a lot to understand what’s going on. The recovery mechanism is looking for the following files on the USB drive:

• security_force/encrypt_lk.rom
• security_force/encrypt_boot.img
• security_force/encrypt_system.img
• security_force/encrypt_recovery.img
• security_force/encrypt_splash.img
• security_force/encrypt_partition.dat

There is also security_force/file_info which contains the name, size and CRC32 checksum for each of the above files. These files (with the exception of encrypt_partition.dat) correspond to the files we have found in the update package:

They must be encrypted with AES-128-CBC using key=”)1Zorxo^fAhGlh$#” and IV="aoAkfwk+#1.6G{dE”. Only system.ext4 must be converted to sparse image before the encryption.

Patching system.ext4

Assuming that we can flash whatever we want with the recovery mechanism, what would be the minimal patch for the official firmware which will give us some kind of access to the head unit? While looking for exploitable bugs in the stock applications, I found a hidden menu in the Engineering Mode which enables ADB:

The boolean flag mDispAdb can be switched by tapping 5 times in the bottom right corner of the 3rd page of “Module Info”. However, if ADB_HIDE_FEATURE is present this flag is ignored and visibility is always set to 8 which means GONE. The ADB_HIDE feature is set by default as we can see in system.ext4:

$ cat /tmp/car/etc/permissions/com.hkmc.software.engineermode.adb_hide.xml 
<permissions>
    <feature name="com.hkmc.software.engineermode.adb_hide" />
</permissions>

Well, let’s delete this feature, create a recovery package and push it to the car. Long story short, that worked! With this simple change we have successfully enabled ADB on Kia Stinger 2020 and connected to it over USB!

Getting root shell

Now when we have an ADB shell how to become root? Turns out there is a convenient setuid binary called “amossu” in the stock firmware:

$ ls -la bin/amossu
-rwsr-sr-x 1 root root 37216 Oct  6 08:29 bin/amossu

It simply does:

setgid(0);
setuid(0);
execv("/system/bin/sh",__argv);

Tooling

I have released a small tool and instructions how to create custom firmware for cars with Gen5 navigation. You can find it here. So far we have successfully verified the entire process on Kia Stringer 2020 (thanks to Ali Al-Rawi).

Final thoughts

I hope this hack will allow creating some interesting mods for Gen5 cars. For example, I’d love to see an app which records a video stream from the car’s camera and saves it on a USB stick. Of course, the ultimate goal remains running Doom on the head screen :)

If you have any comments or feedback, you can leave them on Github.

[컨퍼런스 후기] 2022 Sure Autom.. : 네이버블로그 (naver.com)

UNECE UNR.155 차량 사이버 보안 규제 대응을 위한 공격 시나리오 도출 - 한국자동차공학회논문집 - 한국자동차공학회 : 논문 - DBpia

Debugging and Verification Tool Chain (trace32.com)

한컴아카데미 IT융합 전문교육센터 (hancomacademy.com)

최근까지 사이버 위협의 대부분은 PC 기반 운영체제에서 실행되는 소프트웨어에 초점이 맞추어져 있지만 최근 들어 임베디드 장치를 대상으로 해킹 및 악성코드를 실행되는 공격 사례가 빠르게 증가하고 있습니다. 이러한 공격에 대비하기 위해서는 개발 단계 뿐만아니라 공격 당한 임베디드 장치를 분석하기 위한 방법이 필요합니다.
따라서 본 교육과정에서는 임베디드 장치의 공격 사례에 초점을 맞추어, 안전한 임베디드 장치의 개발 방법론과 임베디드 장치의 취약점 분석을 위한 역분석 기법을 실습 위주로 제공합니다.

* 필수 선수지식 : 어셈블리, 리버싱, 컴퓨터 아키텍처
* 실습환경

- USB 연결이 용이한 PC 환경 (Windows), VMWare, IDA Pro 7.5 설치

- 실습 대상 장치 : IPTime A3004NS-BCM(ARM), TP-Link TL-WR840N(MIPS) (1인당 1대)

한컴아카데미 IT융합 전문교육센터 (hancomacademy.com)