이 글의 질문 · Galaxy Watch5를 반복해서 분석하고 복구할 수 있는 testbed로 어떻게 만들 것인가?
발표자료에서 정리한 판단 근거
펌웨어 안의 파일부터 구분하기
플래싱은 파티션을 이미지로 덮는 과정이다. 그래서 netOdin에 올리는 BL, AP, CSC 파일을 풀고, 어떤 이미지가 어느 단계에서 사용되는지 먼저 구분했다.
영역 | 확인한 파일 | 당시 정리한 역할 |
Boot loader | sboot.bin, vbmeta.img, tzsw.img, tzar.img | secure bootloader, Verified Boot metadata, TrustZone |
Android Processor | boot.img, dtbo.img, recovery.img, super.img | kernel·ramdisk, Device Tree overlay, recovery, dynamic partitions |
CSC | optics.img, prism.img, cache.img | 지역·통신사별 설정과 사용자화 |
sboot.bin은 secure bootloader였고, boot.img는 kernel과 초기 ramdisk를 포함하는 핵심 이미지였다. vbmeta.img에는 boot.img, system.img 등 다른 파티션을 확인하기 위한 검증 데이터가 들어 있었다.
이때 이미 한 가지 문제가 보였다.
이 vbmeta 때문에 우리의 target인 변형된 커널이 올라갈 수가 없음 — 추후 다룸.
ADB 연결 시행착오
아이폰과 Galaxy Watch5가 호환되지 않아 기기를 시작할 수 없었다. NOX 앱으로 연결을 시도했지만 Galaxy Wearable 버전 문제로 실패했다. 이후 핸드폰 없이도 초기 설정이 가능하다는 영상을 확인했고, 마침내 ADB 연결에 성공했다.
ADB 연결 뒤에는 장치가 실제로 가진 파티션과 block 위치를 확인했다.
- Galaxy Watch5는 A/B 기기가 아니었다.
- boot, dtbo, vbmeta는 bootloader가 직접 읽기 때문에 물리 파티션으로 남아 있었다.
- mmcblk0p*는 block special file, 즉 각 파티션에 대응하는 장치 파일이었다.
- dd로 파티션을 복사할 수 있지만 root 권한이 전제였다.
장치에서 확인한 정보는 다음 분석의 기준이 되었다.
heartbl:/ $ uname -r 4.19.151-24717481-abR910XXU1AVG5 heartbl:/ $ getprop ro.build.version.release 11
firmware 파일과 실제 기기의 kernel version, Android version, build fingerprint를 대조할 수 있게 된 것이다.
netOdin과 recovery 범위 확인
netOdin은 Odin의 wireless 버전이었다. USB 포트가 외부로 노출되지 않은 Gear·Watch 계열 장치를 flashing할 때 사용됐다.
이미 flashing에 성공한 다른 Galaxy Watch5와 내 기기를 비교했고, hardware는 동일하지만 software version이 다르다는 것을 확인했다. 순정 firmware를 다시 올려 정상 동작하는 선례도 확인했다.
이 단계에서 testbed의 의미는 단순히 ADB가 연결되는 상태가 아니었다.
다음 질문
기기를 분석 가능한 상태로 만들고 나니 질문이 구체적으로 바뀌었다.
- boot.img에서 kernel과 ramdisk를 어떻게 분리할 것인가?
- 같은 인자로 다시 패키징하면 원본과 같은 boot.img가 만들어지는가?
- 수정한 boot.img가 vbmeta 검증을 통과할 수 있는가?