Honda Civics와 악의적 발레파킹

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으로 질의할 수 있다”는 생각으로 코드 문서를 줄이고, 대신 기능적 실행 절차 문서에 집중하는 것을 봄
어느 시점에든 프로젝트의 모든 문서가 코드와 최신 상태로 맞아 있을 가능성은 정말 낮음
대체로 이 방향에 동의하지만, 전제는 어디까지나 코드가 잘 설계되어 있다는 부분임

문서보다는 단위 테스트를 문서처럼 보는 편이 좋음
테스트는 의도된 사용법과 흥미로운 경계 사례를 보여줄 수 있고, 계속 실행되어 통과하고 있으니 최신 상태라는 것도 알 수 있음
더 많은 테스트를 추가할 때 과소평가되는 큰 장점임
개발자가 어떤 동작 방식이나 경계 사례를 물어볼 것 같다면, 다시 추론하게 만들기보다 질문의 답을 바로 증명해 볼 수 있는 테스트가 있을 만한 가치가 있음