이 글의 질문 · 공식 AOSP 도구로 계산한 digest가 Samsung firmware의 값과 왜 일치하지 않았는가?
도구의 결과가 기대와 달랐다
vbmeta.img를 avbtool.py로 읽으면 descriptor와 digest를 확인할 수 있다. 하지만 실제 boot.img를 hash한 결과는 기대한 값과 맞지 않았다.
6월 11일 회의 기록:
- avbtool.py로 나온 결과가 원하는 결과와 다름
- vbmeta.img 뒷부분에 정식 문서에 없는 부분 발견
- 특정 hash function이 무엇인지 알아내야 함
- authentication block에서 어느 부분이 digest 입력인지 확인해야 함
처음에는 ‘Samsung이 다른 hash function을 쓰는가?’라고 생각했다. 그러나 hash algorithm 이름만 찾는다고 끝나는 문제가 아니었다. 같은 SHA 계열 함수라도 어느 byte 범위를 어떤 순서로 넣고, padding과 header를 어떻게 다루는지가 다르면 결과는 달라진다.
발표자료에서 정리한 판단 근거
digest를 다시 만들었지만 일치하지 않음
6월 17일에는 vbmeta 무결성 digest를 만드는 tool을 분석하고 직접 값을 만들었다. 결과는 여전히 일치하지 않았다.
공식 document는 너무 high 하고 PPT상 정리는 너무 low함. 적당한 도식화가 필요.
이 말은 단순히 설명 그림이 필요하다는 뜻만은 아니었다. 실제 byte range를 놓치지 않으면서도 hash descriptor, authentication block, auxiliary block, signature의 관계를 한 번에 볼 수 있는 구조가 필요했다.
확인할 대상 | 남은 질문 |
boot hash | 원본 boot.img 전체가 입력인가, 별도 padding 또는 metadata가 포함되는가? |
VBMeta digest | header·authentication block·auxiliary block 중 어느 범위가 입력인가? |
trailing bytes | 공식 AVB 구조 밖의 Samsung data인가, 정렬을 위한 영역인가? |
chain partition | 단일 partition 위임인가, Samsung의 더 큰 chain 구조인가? |
직접 flashing으로 반응 확인하기
6월 24일 회의에서는 분석만으로 결론을 내리지 않고 다음 실험을 제안했다.
- repacked file이 다른 이유가 offset인지, ramdisk나 kernel인지 분리한다.
- 차이가 있는 부분을 code와 diff로 좁힌다.
- repacked file을 직접 flashing해서 장치의 reaction을 확인한다.
- chain partition의 의미가 전체 계획을 바꾸는지 확인한다.
이후 7월 23일 기록에는 모든 hash function을 알아냄이라고 남겼다. 하지만 동시에 kernel version 차이와 netOdin flashing error가 새로운 병목으로 등장했다.
AVB 분석은 의미가 있었지만, 분석만으로 실제 modified image를 장치에 전달할 수는 없었다. 다음 선택은 flashing 경로 자체를 바꾸는 것이었다.