이 글의 질문 · 수정한 boot.img를 올리는 문제에서 왜 vbmeta의 구조까지 분석하게 되었는가?
boot.img는 혼자 검증되지 않았다
한 번만 읽히는 boot, dtbo와 같은 작은 파티션은 일반적으로 콘텐츠 전체를 메모리에 올린 뒤 hash를 계산한다. 계산된 값이 vbmeta가 가진 예상 hash와 다르면 Android가 load되지 않는다.
boot.img는 우리가 수정하려는 target이었다. 그런데 그 내용을 hash로 비교한다면, kernel을 정상적으로 수정했더라도 무결성 검사에서 막힐 수밖에 없었다.
발표자료에서 정리한 판단 근거
VBMeta struct
당시 정리는 다음과 같았다.
vbmeta는 암호학적 서명으로 사용자들의 안전한 부팅을 담당한다. VBMeta struct는 descriptors를 가지고 있다.
descriptor | 당시 확인한 역할 |
hash descriptor | boot처럼 전체를 메모리에 올릴 수 있는 파티션의 hash |
hashtree descriptor | system·vendor 같은 큰 파티션의 root hash, salt, offset |
chain partition descriptor | 특정 파티션의 검증 권한을 다른 key와 VBMeta struct에 위임 |
chain partition은 처음 생각한 것보다 중요했다. chained partition 끝에는 자체 VBMeta struct와 footer가 있을 수 있고, 상위 vbmeta에는 이를 검증할 public key가 저장된다. 이 구조라면 한 파티션의 update가 항상 top-level vbmeta 수정으로 이어지지는 않는다.
vbmeta 자체의 무결성
6월 11일 회의에서 분석 범위가 한 번 더 늘어났다.
- vbmeta.img를 IDA, Ghidra, avbtool.py로 분석
- avbtool.py 결과가 기대한 boot.img hash와 다름
- vbmeta.img 뒤쪽에서 공식 문서에 없는 부분 발견
- boot.img만이 아니라 vbmeta 자체의 authentication block과 signature 검사도 확인할 필요
즉, 처음 질문은 ‘boot.img hash를 어떻게 바꿀 것인가’였지만 곧 ‘vbmeta 자체는 무엇으로 서명되고 어떤 byte 범위가 digest에 들어가는가’로 바뀌었다.
이 시점의 두 갈래
- AVB 구조를 계속 분석해 정확한 digest와 signing logic을 찾는다.
- OEM unlock을 먼저 시도해 연구 의존성을 줄인다.
6월 24일에는 현재 vbmeta 연구가 다른 연구 결과에 지나치게 의존하고 있다고 판단했다.
현재 이 vbmeta를 먼저 하기에는 김아욱 교수님의 연구와의 dependency가 너무 큼. 따라서 먼저 OEM unlock을 실행해보고 dependency 없애기.
보안 구조를 이해하는 분석은 계속했지만, 프로젝트 전체가 그 한 지점에서 멈추지 않도록 다른 통로도 동시에 찾기 시작했다.