Honda Civics와 악의적 발레파킹

 (juniperspring.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2021년형 Honda Civic 헤드유닛은 USB 업데이트 경로에서 공개 AOSP 테스트 키로 서명된 업데이트를 받아들일 수 있어, 물리 접근자가 임의 코드를 실행할 수 있음
  • Honda의 업데이트는 Android recovery를 통해 적용되며, recovery 바이너리가 수정됐어도 verify_file 서명 검증 로직은 기본 AOSP와 일치함
  • 공개 AOSP 테스트 키로 서명하고 USB 드라이브 형식을 맞추면 su와 setuid 없이도 원하는 코드를 설치할 수 있으며, 이를 EvilValet 공격으로 부름
  • 새 도구 ota-builder 는 헤드유닛이 받아들이는 업데이트 파일 준비를 쉽게 하며, apk-rebuilder 는 업데이트 파일을 역공학에 필요한 출력 트리로 변환함
  • 프로젝트는 조사 작업 대부분을 마쳤지만 저장소는 중단되지 않았으며, 버전 정보·툴체인·커스텀 테마·AIDL 매핑 개선에 기여가 필요함

프로젝트 업데이트 배경

  • 3년 전 2021년형 Honda Civic의 헤드유닛을 이해하고 역공학하기 위한 초기 작업이 공개됐으며, 이번 업데이트는 그 이후의 진행 상황을 정리함
  • 초기 반응은 매우 고무적이었고, 가장 큰 진전은 업데이트 프로세스를 파악하는 과정에서 나옴

왕국의 열쇠

  • Honda는 USB를 통한 헤드유닛 업데이트를 지원하며, 최종적으로 USB 드라이브 안의 서명된 AOSP 업데이트 파일이 Android recovery를 통해 준비되고 적용됨
  • Honda 고유 검사는 여러 개 존재하지만, res/keys에 공개적으로 알려진 AOSP 테스트 키가 남아 있었고 수정된 recovery 바이너리의 verify_file 서명 로직도 기본 AOSP와 일치함
  • USB 드라이브를 적절히 포맷하고 공개 AOSP 테스트 키로 서명하면, 기존 루트 접근 없이도 헤드유닛에 원하는 내용을 설치할 수 있음
    • su에 setuid를 설정하는 방식의 일반적인 루트 접근이 필요하지 않음
    • 헤드유닛에 전원이 있고 공격자가 가장 앞쪽 USB 포트에 물리적으로 접근할 수 있으면, 업데이트 경로를 통해 헤드유닛에서 임의 코드 실행이 가능함
  • 이 공격은 호텔 방에 물리 접근하는 evil maid attack과 유사하지만, 차량 실내에 접근해야 하므로 EvilValet으로 부름
    • 예시 시나리오에서 호텔 발레파킹 담당자가 USB로 업데이트를 설치하면, 차량이 반환된 뒤 운전자는 헤드유닛 변경 사실을 알지 못함
  • 이 글은 기술 상세 문서가 아니며, 자세한 내용은 Display Audio Update Files 문서에서 확인할 수 있음
  • 새 도구 ota-builder 는 헤드유닛이 받아들이는 업데이트 파일을 쉽게 준비할 수 있게 함
    • 초기 단계지만, 예를 들어 setuid가 설정된 su 바이리를 설치하는 업데이트 파일을 만드는 작업은 사소해졌음
  • 모든 업데이트가 공개 AOSP 테스트 키로 서명됐다고 볼 강한 이유가 있지만, 가능한 모든 공식 업데이트 파일과 모든 헤드유닛 변형 파일시스템에 접근한 것은 아님
    • 확인된 헤드유닛에는 res/keys에 AOSP 테스트 키가 있었지만, HondaHack 설치 이력이 있어 키스토어에 키가 주입됐을 가능성도 있음
    • 공개적으로 이용 가능한 EU 소프트웨어 업데이트 파일 MRC_EU_SW_v12_4.zip은 테스트 키로 서명됐으며, 공개 포럼에서 내려받은 뒤 수정하지 않은 파일임
    • 모든 업데이트가 AOSP 테스트 키로 서명됐을 가능성이 매우 높지만, 이 가설을 뒷받침하거나 반박할 기여가 필요함

도구 구축

  • 업데이트 프로세스 외에 가장 유용한 작업은 apk-rebuilder 개발이었음
  • apk-rebuilder는 인터넷에서 구한 Honda Civic 업데이트 파일을 입력으로 받아, 역공학자가 수동으로 해야 할 작업을 자동화한 깨끗한 출력 파일 트리를 생성함
    • 리소스 해석을 수행함
    • .smali 코드 재구성을 수행함
    • APK 파일 재패키징을 수행함
    • 램디스크 추출을 수행함
    • 그 외 작업도 수행함
  • 실제 Honda 소스 코드를 공개할 수 없기 때문에, apk-rebuilder는 공개 저장소가 호스팅하지 않는 업데이트 파일을 입력받아 Honda .smali 코드와 이미지 자산 등을 출력하는 함수 역할을 함
  • 생성된 출력물은 명확한 디렉터리 구조를 따르며, 민감한 파일 자체를 업로드하지 않고도 문서에서 참조할 수 있음

남은 작업과 기여 요청

  • 알려진 버전

    • 업데이트 프로세스는 취약하며 버전 번호에 크게 의존함
    • 버전 번호는 스푸핑할 수 있으므로 서명되지 않은 코드를 실행하는 능력을 제한하지 않음
    • 업데이트 파일을 만들려면 헤드유닛이 기대하는 버전을 알아야 함
    • 사용 중인 빌드와 일치하지 않는 헤드유닛 소프트웨어 변경은 예기치 않은 동작과 recovery loop로 이어질 수 있음
    • 10세대 Honda Civic을 운전하고 기술에 익숙한 사용자는 저장소의 Known Versions, Display Audio Software 섹션에 기여할 수 있음
    • 특히 과감한 사용자는 ota-builder 코드를 읽고 업데이트 플래시를 시도할 수 있지만, 헤드유닛이 기준 장치와 다르면 recovery loop에 빠지고 장치가 소프트브릭될 수 있음

  • 툴체인

    • 로컬 머신에는 실험적이고 작업 중인 툴체인이 존재함
    • 이 툴체인은 후보 .c 코드를 받아 원래 벤더 바이너리와 같은 컴파일러 버전과 빌드 플래그로 ARMv7용으로 컴파일함
    • 업데이트 프로세스를 이해하는 작업에서 이 툴체인은 필수적이었음
    • 현재 형태는 Docker를 많이 사용하지만 지저분하고 특정 워크플로에 크게 맞춰져 있으며, 깨끗한 구현을 공개하고자 함

  • 커스텀 테마

    • apk-renderer를 vibe-coding하던 중 커스텀 테마를 일부 탐색함
    • 커스텀 테마는 Mitsubishi의 AOSP framework 포크 안에 있고, 헤드유닛 앱은 하드코딩된 리소스 ID를 기대하도록 축소돼 있어 배포가 어려울 가능성이 큼
    • 커스텀 테마를 배포하려면 벤더 framework를 외과적으로 수정하고 이를 자동화하는 도구를 작성해야 할 가능성이 큼
    • 이 작업은 간단하지 않고 노력할 가치가 크지 않을 수 있지만, 기여자는 환영됨

  • aidl-rebuilder 개선

    • .smali 파일을 파싱해 헤드유닛의 모든 AIDL 인터페이스를 생성하고 매핑하는 도구 작업이 시작됐음
    • 도구는 작동하지만 정확성을 충분히 검토하지 못했음
    • 이 작업은 가상 속도계 같은 커스텀 앱 가능성을 열어줌

문서화와 LLM에 대한 생각

  • 참조 문서보다 도구화에 더 큰 비중을 둠
  • 신뢰할 수 있고 결정적인 도구가 헤드유닛 코드를 더 이해하기 쉬운 형태로 매핑하면, 사용자는 LLM으로 그 형태를 질의해 구체적인 질문에 답할 수 있음
  • 헤드유닛 코드가 진실의 원천이므로, 실제 코드와 어긋날 수 있는 참조 문서를 유지하는 부담을 줄일 수 있음
  • ADB로 헤드유닛에 연결하는 사용자 가이드는 여전히 유용함
  • Java 코드 자체를 LLM이 사용할 수 있는 상황에서 Java 코드 동작을 별도 문서로 유지하는 일은 유지보수 부담이 됨

마무리

  • 헤드유닛에 대해 의도했던 조사 작업은 대부분 완료됨
  • 계속 매달릴 수 있는 프로젝트지만, 앞으로는 다른 프로젝트로 전환할 가능성이 큼
  • 저장소는 중단된 상태가 아니며, PR은 언제나 환영됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 10세대 Honda Civic 업데이트는 Honda가 특수 포맷 USB 드라이브로 배포하며, 사실상 Android 4.2.2rc1 시절 복구 패키지에 Honda가 버전 검사만 추가한 형태임
    이 버전 검사는 속일 수 있고, 패키지는 공개된 AOSP 테스트 키로 서명되어 있어서 앞 USB 포트에 물리 접근만 있으면 임의 패키지를 서명해 플래시하고 헤드유닛에서 임의 코드 실행이 가능함
    root/su는 필요 없고, 2021 Civic에서 끝까지 실행해 봤으며 공식 EU 업데이트 파일도 AOSP 테스트 키 서명을 쓰는 것을 별도로 확인함
    • AOSP는 Android Open Source Project의 약자임
    • 같은 연식의 Acura 헤드유닛도 Android 4.x 기반이라 분석해 보려 했지만, 업데이트 파일을 구하는 단계에서 막혔는데 어떻게 업데이트 파일을 얻었는지 궁금함
    • 다른 차들의 인포테인먼트 시스템도 AOSP 기반인 경우가 꽤 있음. Hyundai 업데이트를 내려받아 봤을 때도 사실상 Android 이미지였던 기억이 남
  • 도로 위 대부분의 차는 인포테인먼트와 온보드 전자장치 보안이 형편없는 편이고, 요즘 차에 들어간 마이크·카메라·GNSS 수신기·와이파이·블루투스 때문에 이동식 감시 플랫폼처럼 변해 감
    2026년 3월 호주 정부 Information Security Manual에는 정부 기기를 차량 인포테인먼트에 연결하지 말고, 연결 차량 안이나 근처에서 민감한 자료를 보거나 민감한 대화를 하지 말라는 통제가 추가됨
    https://www.cyber.gov.au/business-government/asds-cyber-secu...
    • NC가 민감도 체계에서 가장 낮은 등급 아닌가?
    • 이건 괜찮다고 봄. 자동차 라디오이지 핵심 시스템은 아님
      이런 공격에 취약할 수 있는 사람들은 업무를 수행할 절차와 신뢰 장비가 따로 있고, 미국 경찰 기관도 OnStar가 나온 이후 렌터카에 대해 비슷한 규칙을 두고 있었음
      일반인에게 위험한 텔레매틱스 정보 대부분은 어차피 판매되고 있음
  • 한쪽에서는 우리 생활 속 대부분의 기기에서 계속 줄어드는 하드웨어 소유권에 맞서 싸우면서, 막상 더 열린 기기가 나오면 또 공격하는 분위기가 됨
    기술에서의 위협 모델은 늘 공격자가 기기에 물리 접근권과 시간을 갖고 있으면 끝이라는 전제였음
    • 일반 대중이 수정할 수 있게 열린 것도 아니지 않나? 제조사는 방향을 정해야 함. 완전히 열어서 필요한 사람이 스스로 강화하고 절충점을 알 수 있게 하든지, 완전히 닫고 안전하게 만들든지 해야 함
      지금처럼 차가 운전 내내 사용자를 감시하는 사생활 침해 장치이면서, 조금만 관심 있는 사람에게도 그 데이터를 내주는 불안전한 장치인 중간 상태가 최악임
    • 최근 BitLocker 취약점에서도 비슷한 상황을 볼 수 있음. 이제 잠금 해제가 가능해진 보관 하드웨어 때문에 새 사건이 해결되거나 사람들이 수감될지 궁금함
      압수될 수 있다면 데이터를 로컬에 보관하지 않는 편이 낫고, 법에 따라 잠금 해제를 강제당할 수도 있지만 미국에서는 비밀번호 제공을 거부해도 안전해야 함
      기술적으로는 Google과 Apple이 물리 보안을 크게 개선했고, GrapheneOS는 그 기반 위에서 공격 표면을 줄이고 좋은 기능을 더해 한 단계 더 나아감. 특히 자동 재부팅이 널리 채택되면서 휴대폰에서는 “물리 접근이면 끝”이라는 결론을 수정할 수 있음
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • 그렇다고 로컬 기기 보안을 포기해도 된다는 뜻은 아님. 물리 기기에도 로그인 보안이 있고, 어쩌면 전체 디스크 암호화도 쓰고 있을 것임
      충분히 고도화되고 집요한 공격자가 물리 접근으로 어떤 기기든 장악할 수 있다고 해서, 아무나 쉽게 하도록 만들어도 된다는 뜻은 아님
  • Honda가 여기서는 다른 자동차 제조사보다 훨씬 합리적으로 보임
    차에 물리 접근할 수 있는 악의적 발렛이라면 헤드유닛을 해킹하느라 시간을 낭비하지 않고, 그냥 차 어딘가에 도청 장치를 숨길 것임
    게다가 Civic 운전자가 정보기관의 표적이 될 일도 없다고 봄
    • 농담인지 모르겠지만 꽤 말이 안 됨. Honda가 의도적으로 이렇게 만들었을 가능성도 낮음
      헤드유닛에는 보통 동기화 후 남은 연락처 SQLite 데이터베이스, 위치 기록, 원격측정이나 로그 파일에 남은 과거 데이터 같은 이력 정보가 들어 있음
      또 헤드유닛은 차량 내부 버스에 접근할 수 있는 경우가 많고, Gateway 모듈 같은 방화벽이 있더라도 대체로 약함. Honda에서 헤드라이트와 같은 CAN 버스를 통해 암호 자료 없이 잠금 해제와 시동 허가가 가능했던 유명한 사례처럼, 인포테인먼트는 단순 추적 장치보다 훨씬 강력할 수 있음
      게다가 헤드유닛에 코드를 심거나 이미 있는 데이터를 빼내는 쪽이 별도 추적기를 붙이는 것보다 흔적을 훨씬 덜 남김
    • 비꼬는 말이면 괜찮지만, 아니라면 왜 Civic 운전자가 정보기관 표적이 될 수 없다는 건지 모르겠음
      Civic은 가장 흔한 차 중 하나라 배경에 묻히기 좋고, 과학자·엔지니어·언론인·변호사 같은 “평범해 보이는” 사람들도 Honda Civic을 많이 탈 수 있음
      차 안에 숨긴 도청 장치는 발견될 수 있지만, 차량 펌웨어 안에 직접 설치한 것은 찾힐 가능성이 더 낮음
    • 기밀 접근권이 있는 지루한 과학자나 엔지니어가 평범한 Civic을 타고 출근하지 않는다고 생각하는 건가?
  • 제품 관리자가 펌웨어를 회사 내부 서명 서비스로 서명했다고 자랑스럽게 말하는 걸 들은 적이 있음. 그 자체는 좋음
    하지만 실제로 묻던 질문은 내부 의무사항과 관련해 펌웨어가 서명됐는지였지, 펌웨어 업데이트 절차가 서명을 검증하는지가 아니었고, 실제로는 전혀 검증하지 않았음
    • 비슷한 “해결책”을 본 적이 있음. 서명 알고리즘을 업데이트 패키지에서 직접 실행하고 있었음
      “그렇지 않으면 서명 알고리즘을 어떻게 업데이트하냐”는 식이었고, 최악인 점은 한때는 올바르게 되어 있었다는 것임
      보안팀이 “포스트 양자 안전” 서명을 요구하면서 서명 방식이 바뀌었고, 그 과정에서 회귀 버그로 들어간 것이었음
    • BobbyTables2라는 이름이면 이메일 PGP 서명을 검증하는 올바른 방식부터 바로 떠올릴 줄 알았음
  • 보안과 기기를 장기적으로 유용하게 유지하는 것 사이에는 선이 있다고 봄. 악의적 메이드식 공격으로 차에 도청 악성코드를 설치할 위협은 낮아 보임
    하지만 이 차들이 10년 이상 지나 만지작거릴 의향이 있는 사람들에게 넘어가면, 소프트웨어를 열고 커스터마이즈할 수 있는 능력은 훌륭한 장점이 될 것임
    유용한 개조를 만드는 커뮤니티가 생기고 기기 수명이 늘어나면 좋겠음. 최종 사용자가 순정 헤드유닛을 뜯어내고 Honda 장치보다 보안과 공학 품질이 더 나쁠 가능성이 큰 Aliexpress식 “Android 태블릿” 유닛을 넣는 것보다 훨씬 나아 보임
  • 이건 소유자에게서 시스템을 잠그려는 생각조차 하지 않았다는 좋은 신호일 수도 있음
    • 차 안에 잠깐 들어온 아무에게나 root 접근을 허용하는 건 좋지 않음. 사무실에 항상 켜져 있고 셸이 열린 노트북을 두는 것과 비슷함
      업데이트를 기본적으로 모두 신뢰하지 않을 거라면, 실제 소유자가 업데이트를 승인할 수 있는 메커니즘을 제공했어야 함
    • 해커 친화라기보다는 무능의 결과일 가능성이 큼
      정말 의도였다면 특수 키가 필요한 잠금 해제 가능 부트로더나, 접근하기 어려운 스위치 같은 방식이 있었을 것임
  • 차를 바퀴 달린 거대한 컴퓨터로 만든 게 나쁜 일이었을지도 모름. 더 연구가 필요함
  • 나머지 보안이 얼마나 괜찮은지 궁금함. 헤드유닛은 아마 CAN 게이트웨이에 연결되어 있을 텐데, 텔레매틱스로 호출할 수 있는지, CarPlay/Android Auto를 악용해 집으로 통신하게 만드는 새로운 방법이 있을지도 모름
    • 차에 물리 접근이 있고 집으로 통신하고 싶다면, 바닥 매트 밑에 GPS 추적기를 두는 걸 추천함
      Honda Civic 한 세대에만 되는 방식보다 더 많은 브랜드에서 통하고, 설치도 아마 더 빠름
  • 점점 더 많은 프로젝트가 “잘 설계된 코드는 LLM으로 질의할 수 있다”는 생각으로 코드 문서를 줄이고, 대신 기능적 실행 절차 문서에 집중하는 것을 봄
    어느 시점에든 프로젝트의 모든 문서가 코드와 최신 상태로 맞아 있을 가능성은 정말 낮음
    대체로 이 방향에 동의하지만, 전제는 어디까지나 코드가 잘 설계되어 있다는 부분임
    • 문서보다는 단위 테스트를 문서처럼 보는 편이 좋음
      테스트는 의도된 사용법과 흥미로운 경계 사례를 보여줄 수 있고, 계속 실행되어 통과하고 있으니 최신 상태라는 것도 알 수 있음
      더 많은 테스트를 추가할 때 과소평가되는 큰 장점임
      개발자가 어떤 동작 방식이나 경계 사례를 물어볼 것 같다면, 다시 추론하게 만들기보다 질문의 답을 바로 증명해 볼 수 있는 테스트가 있을 만한 가치가 있음
답변달기