이 글의 질문 · Samsung 문서대로 빌드했는데 firmware와 kernel version과 size가 모두 다를 때 어떻게 변인을 통제할 것인가?
같은 기기인데 kernel version이 왜 중요한가
기존에는 WH3 version의 SM-R910 kernel source만 사용할 수 있었다. 이 version은 상당히 최신이고 대규모 update가 포함돼 있어, 실제로 flashing에 성공한 AVG 계열 firmware의 boot.img 안 kernel과 version과 size가 모두 달랐다.
같은 기기인데 커널 버전이 무슨 상관이냐고 물어볼 수 있지만, 삼성과 협업해서 하는 프로젝트가 아닌 만큼 커널의 크기가 다른 것이 플래싱 했을 때 파티션을 넘어가서 문제가 발생할지 확담을 할 수 없음.
안전한 방법을 사용하고 싶었음. 안전하고 테스트 할 때 결과를 확신할 수 있는 방법.
7월 23일 회의에서는 kernel version이 달라 어느 부분이 바꾸고자 하는 code인지 알 수 없다고 정리했다. 처음에는 firmware Image를 vmlinux로 되돌려 비교하려 했지만, 8월 12일에는 Image에서 vmlinux로 복원하는 것이 불가능하다는 결론에 도달했다.
Samsung에 source를 요청하다


내가 한 행동은 Samsung에 해당 kernel version을 학생 mail로 요청한 것이었다. 약 일주일 뒤 응답을 받았고, 안내받은 site에는 이전에 없던 AVG6 source file이 새로 올라와 있었다.
좀 놀라웠다. 한 사람의 요청으로 바로 웹 사이트에 개제를 해준다는 것이.
이제 AVG6 version으로 compile할 수 있었다.
같은 version, 같은 size


결과적으로 같은 version과 같은 size의 kernel을 얻었다.
- kernel size:
0x177C800
- 직접 compile한 data가 끝나는 위치:
0x177c27F
- firmware kernel data가 끝나는 위치:
0x177c8ff - 0x800 = 0x177c0ff
boot.img 앞에는 header가 있기 때문에 firmware 쪽 offset에서는
0x800을 빼서 비교했다.size와 version은 맞았지만 끝부분 byte 구조와 data가 끝나는 길이는 여전히 달랐다.
Samsung의 도움 없이 수정 위치 찾기
이 차이를 완전히 없애는 대신, 변인을 통제할 수 있는 방법을 다시 생각했다.
- 한 함수 또는 상수를 수정한다.
- 같은 환경에서 kernel을 다시 compile한다.
- 원본 build와 수정 build를 cmp 또는 binary diff한다.
- 바뀐 영역 주변을 firmware boot.img의 kernel에서 찾는다.
- 대응 위치를 직접 byte patch한다.
특정 kernel을 수정하고 compile하면 바뀐 부분이 존재할 것이다. 그 부분을 찾아 firmware boot.img의 대응 byte를 patch하면, Samsung build의 알 수 없는 후처리를 전부 재현하지 않고도 원하는 변경을 시도할 수 있었다.
삼성 도움을 빌려 커널 버전을 얻어서, 그리고 삼성의 도움 없이도 찾아서 바이트 패치로 해결할 수 있게 되었다.
그런데 실제 lsm6dsx.c를 수정해도 기대한 kernel 영역이 바뀌지 않았다. 이 실패가 다음 분석의 출발점이 됐다.