🧩

14. Sensor Hub firmware에서 LSM6DSO의 ODR 설정을 찾다

단계
Firmware
상태
완료
순서
14
시기
2025.01–02
요약
firmware 추출과 Ghidra 분석으로 register 0x10, ODR 상수와 관련 함수 호출을 좁혔다.
🧠
질문 — AP에서 CHANGE_DELAY 명령을 보내는 경로를 찾았다면, Sensor Hub firmware 안에서는 실제 ODR register를 어디서 설정하는가?

분석 대상을 kernel에서 firmware로 옮겼다

공개 LSM6DSX IIO driver는 Galaxy Watch5의 실제 제어 경로가 아니었다. sysfs 명령은 SSP와 CIPC를 거쳐 CHUB로 전달됐다. 그렇다면 sampling rate를 실제로 적용하는 코드는 Sensor Hub firmware 안에 있어야 했다.
Samsung kernel source의 drivers/sensorhub/slsi/firmware 쪽에는 firmware binary가 header file 형태로 들어 있었다. build할 때 제품과 revision에 맞는 header가 선택되어 image에 포함되는 구조였다.

firmware를 꺼냈다

관련 header 다섯 개를 확인하고 byte array를 binary로 복원했다. binwalk로 바로 구조가 나오기를 기대했지만 유효한 file system이나 알려진 container가 잡히지 않았다. 그래서 Ghidra에서 raw binary로 열고 ARM Thumb code로 분석했다.
명령어가 2 byte 단위로 보였고, Thumb mode로 해석해야 함수 흐름이 맞았다.

string이 기준점이 됐다

symbol이 없는 binary에서 처음부터 모든 함수를 읽는 것은 비효율적이었다. 먼저 남아 있는 string을 찾았다.
XL ODR SET XL FS SET
LSM6DSO의 accelerometer control register와 datasheet를 대조했다. ODR와 full-scale 설정이 들어가는 핵심 register는 CTRL1_XL (0x10)이었다.

ODR write까지 따라간 경로

원문에서 정리한 흐름은 다음과 같다.
FUN_0005f5a4(void) → FUN_0000b150(2) → FUN_0005f03c(0x87)
FUN_0005f03c는 전달받은 값을 register에 적용하는 함수로 보였다. 반대로 sensor를 멈추는 경로에서는 다음 호출을 확인했다.
FUN_0005f2b0(void) → ODR value 0

상수로 동작을 나눴다

분석 과정에서 반복해서 나타난 값은 0, 0x14, 0x87이었다. lower four bits와 upper bits가 각각 full-scale·ODR 설정에 쓰이는 방식을 datasheet와 대조했다.
당시 추적한 의미
0x00
ODR off / power-down 경로
0x14
XL 설정 과정에서 사용되는 값
0x87
FUN_0005f03c에 전달되는 ODR 관련 설정값

발표자료에서 다시 연결한 분석 화면

Sensor Hub firmware 추출·Ghidra 분석·LSM6DSO string 추적 (슬라이드 1–10)
Sensor Hub firmware 추출·Ghidra 분석·LSM6DSO string 추적 (슬라이드 1–10)
CTRL1_XL write와 ODR 상수 추적 (슬라이드 11–18)
CTRL1_XL write와 ODR 상수 추적 (슬라이드 11–18)

확실한 것과 아직 확실하지 않은 것

확인한 것

  • Sensor Hub firmware binary를 source header에서 분리할 수 있었다.
  • Ghidra에서 Thumb code로 정상적인 함수 흐름을 볼 수 있었다.
  • LSM6DSO의 ODR·FS 관련 string과 CTRL1_XL write 경로를 찾았다.
  • sensor start와 stop에서 서로 다른 ODR 값이 들어가는 흐름을 확인했다.

남은 것

  • AP2CHUB packet의 CIPC_READ_DATA가 firmware의 어느 dispatcher와 정확히 연결되는지
  • mailbox interrupt에서 해당 sensor command handler까지의 전체 call graph
  • 값을 수정한 firmware가 Samsung boot chain을 통과하도록 다시 넣는 방법

software shell 우회도 확인했다

Samsung SMT와 SMT Shell을 설치해 system shell을 얻는 방법도 시도했다. shell 자체는 얻었지만 /sys/class/sensors/ssp_sensor 접근에서는 같은 오류가 발생했다.
셸을 따긴 했으나, 이 권한으로도 같은 오류 발생
분명히 system 권한 맞는데 왜 그러지 → SElinux때문인가?
결국 runtime에서 우회해 쓰는 길도 SELinux에 막혔다. 이제 분석한 firmware를 실제로 flash해 보는 hardware 경로가 필요했다.