CASO Lab — Galaxy Watch 5 센서 샘플링 경로 역공학 및 펌웨어 테스트베드 구축

Summary — Galaxy Watch 5의 가속도계 ODR 변경을 목표로 부팅 이미지의 신뢰 경계와 센서 제어 경로를 역추적했습니다. upstream Linux IIO 드라이버의 직접 제어 가설을 기각하고 Samsung SSP–Sensor Hub 경로와 ODR 수정 후보 4곳을 식별했으며, USB test pad 미세 납땜과 JIG 제작을 통해 복구 가능한 유선 Odin 테스트베드를 구축해 수정 이미지의 전송까지 성공했습니다. 그러나 그다음 단계인 Samsung 부트 체인의 서명·무결성 검증에서 이미지가 거부되어 실제 부팅과 ODR 변화 검증까지는 도달하지 못했습니다.

01 · Project Overview

기간	2024.05 – 2025.01 (학부 연구 인턴)
소속	CASO Lab, 강원대학교
대상	Galaxy Watch 5 SM-R910 · LSM6DSO32 계열 가속도계 · Samsung SSP / Sensor Hub
본인 담당	부팅 이미지·AVB 분석 · matching kernel source 확보 · 커널 구성 검증 · Sensor Hub 정적 분석 · USB/Odin 테스트베드 제작 · 후속 실험
도구	Ghidra, mkbootimg/avbtool, menuconfig, ADB, netOdin/regular Odin, 회로도, 멀티미터
산출물	연구 슬라이드 · 실험 기록 (부록 링크)

Role & Scope

netOdin 순정 복구 절차와 regular Odin 유선 전송 실험 절차 설계·검증, soft-brick 복원

boot.img, vbmeta.img, AVB footer·descriptor·hash·signature 구조 분석

펌웨어와 공개 소스의 버전 불일치 발견 후 Samsung에 matching kernel source 요청

확보한 Samsung source/config의 menuconfig와 통제 빌드·실기기 정보를 교차검증해 센서 제어 경로 전환

Android 센서 정보·커널·Device Tree·회로도의 교차검증

Ghidra ARM/Thumb 기반 Sensor Hub firmware 정적 분석

USB test pad 납땜, DATA− 경로 진단, 대체 접점·JIG 기반 유선 Odin 환경 구축

주간 단위 결과 정리와 다음 가설·중단 기준 설계

02 · Problem & Goal

연구 질문은 단순했습니다. "Galaxy Watch 5의 가속도계 ODR을 실험 목적에 맞게 바꿀 수 있는가?" 그러나 공개 API의 polling 주기만으로는 센서 내부 ODR을 직접 통제할 수 없었고, 실제 제어 로직이 Android, Linux kernel, Samsung SSP, 별도 Sensor Hub firmware 중 어디에 있는지도 불명확했습니다.

코드 위치를 찾는 것만으로는 충분하지 않았습니다. 수정 이미지를 실기기에 적용하려면 boot.img 재구성, AVB/VBMeta와 vendor signing, non-A/B 기기의 복구 절차, netOdin/regular Odin 전송 경로, 내부 USB test pad까지 함께 해결해야 했습니다. 그래서 이 프로젝트를 제어 위치 탐색 → 안전한 수정 → 전달 → 부팅 → 측정의 다섯 단계 문제로 정의했습니다.

03 · Key Outcomes

성과	결과
① boot.img core 재구성 검증	AOSP 11/13 결과와 순정 core가 byte-identical · 차이는 signer(0x184F000)·AVB(0x1850000) tail
② generic driver 가설 기각	`CONFIG_IIO_ST_LSM6DSX` 비활성 · `CONFIG_SENSORS_SSP_LSM6DSL` 활성 → SSP/Sensor Hub로 피벗
③ AP–Sensor Hub 전달 구조 재구성	`set_acc_delay` → SSP/CIPC → AP2CHUB mailbox·공유 SRAM 정적 경로
④ ODR 패치 후보 식별	`FUN_0005f03c` · CTRL1_XL(0x10) · 호출 지점 4곳
⑤ 복구 가능한 유선 Odin 테스트베드	netOdin 순정 복구 baseline + DATA− 우회·JIG 기반 regular Odin 4선 전송 PASS

04 · Approach

05 · Technical Deep Dive

0. Recoverable Baseline

ADB 파티션 열거로 대상 기기가 non-A/B 구조임을 확인했습니다. 대체 슬롯 롤백을 전제로 할 수 없었기 때문에, 수정 실험에 앞서 XDA에서 확보한 순정 펌웨어와 netOdin으로 1차 복구 절차를 먼저 검증했습니다. 이후 boot.img·vbmeta.img 조합 실험에서 발생한 soft-brick 상태도 netOdin으로 순정 복원했습니다. 뒤에서 구축한 regular Odin 유선 경로는 이 초기 복구 baseline과 구분했습니다.

1. boot.img 재구성 경로를 검증하고 Samsung signer·AVB 신뢰 경계를 특정

가속도계 샘플링 속도를 바꾸려면 수정한 커널을 실제 기기에 올려야 했습니다. 초기에는 제어 코드가 공개 커널 드라이버에 있다고 판단했기 때문에, 수정한 Image를 순정 ramdisk·DTB와 결합해 플래싱할 boot.img 재구성 경로가 먼저 필요했습니다.

기능을 바꾸기 전에 재구성 과정부터 검증

본격적인 코드 수정에 앞서, 아무것도 바꾸지 않은 이미지를 분해한 뒤 다시 조립하는 기준 실험을 진행했습니다. 이 결과가 원본과 같아야 이후의 차이나 부팅 실패를 제 코드 수정의 영향으로 판단할 수 있기 때문입니다.

하지만 초기 재구성본은 원본과 파일 앞부분부터 달랐습니다. 바로 패치를 진행하지 않고 도구 버전·offset·입력값 문제를 각각 가설로 두고 원인을 분리했습니다. 최초 차이인 41번째 byte는 legacy 재구성 경로를 재검증하게 만든 이상 징후였으며, 뒤에서 확인한 vendor tail 자체와는 별개의 문제였습니다.

통제 실험으로 원인 분리

확인할 질문	검증 방법과 관찰	내린 판단
`mkbootimg` 버전 문제인가?	AOSP 11·13 출력이 모두 25,489,408 bytes이며 서로 byte-identical	도구 버전은 원인이 아님
표준 `boot.img` core를 재현할 수 있는가?	순정 이미지의 앞 25,489,408 bytes와 재구성본이 byte-identical	core 재구성은 성공
실제 차이는 어디에 있는가?	순정 tail의 `0x184F000`에서 signer, `0x1850000`에서 AVB 구조 확인	남은 장벽은 Samsung-specific signing·AVB metadata

따라서, 통제 실험 이후 , 문제는 “이미지를 다시 만들 수 있는가”가 아니라, “수정된 이미지를 Samsung bootloader가 신뢰하도록 만들 수 있는가”로 바뀌었습니다.

순정 이미지에만 존재하는 SEANDROIDENFORCESignerVer03 영역과 AVB header·authentication·auxiliary·footer를 분리했습니다. boot descriptor digest를 다시 계산하는 것만으로는 충분하지 않았고, 최종 RSA signature가 bootloader가 신뢰하는 키로 이어져야 했습니다. 개인 키로 self-signed 이미지를 만드는 것은 가능하지만, 그 키가 기기에 등록·허용되지 않으면 정식으로 신뢰받는 이미지가 되지 않는다는 경계를 확인했습니다.

실기기에서는 전송과 부팅 검증을 분리

이후 netOdin에서 boot.tar 패키징, boot·vbmeta·hash 조합, OEM Unlock 전후를 나눠 시험했습니다. 패키징 문제를 해결한 뒤에도 Secure Fail: BOOT, 전송 후 soft-brick, Odin mode가 관찰됐고 순정 firmware로 복구했습니다. OEM Unlock만으로 해당 검증 경계가 해제되지는 않았습니다.

부팅 신뢰 경계와 별개로, 이제는 실제 제품이 어느 센서 제어 코드를 빌드·실행하는가를 확인해야 했습니다. 다음 단계에서는 matching source와 binary diff를 이용해 수정 위치를 추적했습니다.

2. 최소 바이트 패치의 한계를 확인하고 Samsung SSP로 전환

matching source로 비교 기준을 확보

펌웨어의 kernel version과 당시 공개된 Samsung source가 일치하지 않아 동일 조건 비교가 어려웠습니다. Samsung Open Source Team에 SM-R910의 matching source를 요청했고, 추가 공개된 AVG6 source로 순정 kernel과 같은 0x177C800 크기의 이미지를 빌드했습니다.

수정 byte를 diff로 찾으려 한 초기 전략

초기에는 AP의 Linux IIO 드라이버가 센서 레지스터를 직접 제어한다고 보았습니다. 공개 소스에서 13·26·52·104·208·416 Hz ODR table과 probe → WHO_AM_I 확인 → st_lsm6dsx_set_odr() → regmap_update_bits() 흐름을 확인했기 때문에, 이 코드를 수정하면 샘플링 속도를 바꿀 수 있다고 가정했습니다.

전체 kernel을 교체하기보다 필요한 byte만 패치하기 위해 원본 소스 빌드 A → 한 지점만 수정한 빌드 A′의 차이를 추출하고, 실제 firmware kernel B에서 주변 byte pattern을 찾아 대응 위치를 패치하려 했습니다. 이 0x177C800 비교는 Sensor Hub가 아니라 Linux kernel 이미지 분석입니다.

반복 빌드 차이에서 코드 포함 여부를 의심

하지만 수정 전 반복 빌드끼리도 build·version 문자열과 여러 section이 함께 달라졌습니다. whole-binary diff만으로는 목표 코드 변경만 나타내는 안정적인 byte 지문을 격리할 수 없었고, 실제 firmware kernel B의 패치 위치도 확정하지 않았습니다.

여기서 질문을 “어느 byte를 바꿀 것인가?”에서 “처음 수정한 generic driver가 실제 제품 빌드에 포함되는가?”로 전환했습니다.

확보한 Samsung source/config에서 구성 상태를 확인

확인 항목	확보한 source/config	판단
`CONFIG_IIO_ST_LSM6DSX`	`[=n]`	확보한 구성에서는 generic IIO core가 비활성
generic LSM6DSX I2C·SPI	모두 `[=n]`	해당 구성에서는 관련 probe·callback이 빌드되지 않음
`CONFIG_SENSORS_SSP_LSM6DSL`	`[=y]`	Samsung SSP 계층은 built-in
`CONFIG_SENSORS_SSP_ACCELEROMETER_32GSENSOR`	`[=y]`	32G 가속도계 역시 SSP 경로의 제어 대상 후보

후속 통제 빌드로 판단을 재확인

menuconfig에서 generic IIO·I2C·SPI가 n, Samsung SSP 관련 구성이 y임을 확인했습니다. 이 설정을 발견한 뒤, 코드가 빌드에 포함될 때 목표 변경이 binary에 어떻게 나타나는지 확인하기 위해 generic 드라이버를 강제로 포함한 통제 빌드를 만들고 ODR 상수 하나를 눈에 띄는 시험값으로 바꿨습니다. 이 실험은 비활성 경로를 처음 발견한 계기가 아니라, menuconfig 해석과 diff 방법을 사후에 확인한 실험입니다.

generic driver 가설 반증과 Samsung SSP 전환

위: 확보한 Samsung source/config의 menuconfig에서 generic IIO·I2C·SPI는 n, Samsung SSP는 y임을 확인했습니다. 화면 상단이 Linux/x86로 표시되므로 이 화면만을 실기기 stock config의 직접 증거로 사용하지 않고, 아래 통제 빌드와 실기기 센서 정보·SM-R910 회로도로 교차검증했습니다.

통제 빌드에서 확인한 것

generic 드라이버를 강제로 포함한 변경 전·후 vmlinux를 비교하자, 수정한 ODR 값에 대응하는 byte 차이가 나타났습니다. 즉 코드가 빌드에 포함되면 해당 변경을 binary diff로 검출할 수 있음을 확인했습니다. 반면 일반 설정으로 빌드한 vmlinux에서는 같은 pattern이 나타나지 않았습니다.

따라서 처음 추적한 generic IIO 경로는 패치 대상에서 제외하고, source/config에서 활성화되어 있으며 실기기 센서 정보·SM-R910 회로도와도 일치하는 Samsung SSP 경로로 분석 대상을 옮겼습니다. generic 드라이버 분석은 ODR 값이 register 값으로 변환되는 방식과 read-modify-write 흐름을 이해하는 참고 모델로 남겼습니다.

SSP/Sensor Hub로 분석 대상을 전환

질문은 “generic 드라이버의 어느 함수를 바꿀까?”에서 “활성화된 SSP가 센서 register를 직접 쓰는가, 아니면 별도의 Sensor Hub에 명령을 전달하는가?”로 바뀌었습니다. 다음 3번에서는 실기기 센서 정보·SM-R910 회로도·SSP/CIPC 코드·Device Tree를 교차검증하며 이 전달 경로를 추적했습니다.

3. AP에서 Sensor Hub까지 명령 전달 구조를 크로스레이어로 재구성

분석 대상을 먼저 교차검증

하나의 드라이버 이름만 믿지 않고 운영체제 출력·소스·빌드 설정·회로도를 대조해 실제 타깃을 좁혔습니다.

근거 층위	확인한 내용	판단
Android sensor list·`dumpsys`	LSM6DSO/32G 계열 문자열	운영체제에 노출된 실제 센서 후보
Samsung sensor source	chip ID와 SSP 가속도계 코드	generic IIO가 아닌 SSP 제어 가능성
kernel configuration	Samsung SSP 센서 구성 활성	다른 실기기·회로도 근거와 함께 SSP 경로를 지지
SM-R910 schematic	LSM6DSO32 계열 부품과 Sensor Hub의 SPI 연결	소프트웨어 후보와 실장 하드웨어 일치

SSP 명령을 AP2CHUB 채널까지 추적

커널 소스에서 set_acc_delay() 요청을 send_instruction()·ssp_send_command()·do_transfer()를 거쳐 contexthub_ipc_write()까지 따라갔습니다. 마지막에는 cipc_write_data()가 CIPC_REG_DATA_AP2CHUB 채널의 data_ch->buf에 명령을 복사했습니다. 여기까지가 AP 측에서 함수 단위로 확인한 전달 경로입니다.

contexthub_ipc_write()에서 요청 buffer가 CIPC_REG_DATA_AP2CHUB로 전달되는 지점

CIPC 버퍼에서 MMIO mailbox·공유 SRAM까지 역추적

data_ch->buf의 실제 위치를 찾기 위해 CIPC_USER_MEMCPY를 따라가자 cipc_func_memcpy()가 전송 방향에 따라 memcpy_toio()와 memcpy_fromio()를 호출했습니다. 대상이 일반 메모리 버퍼가 아니라 MMIO로 매핑된 영역이라는 단서였고, 질문을 “명령이 어느 버퍼에 복사되는가?”에서 “그 MMIO base는 어디서 초기화되는가?”로 전환했습니다.

cipc_get_base()에서 시작해 cipc_set_info()·cipc_set_map()·cipc_init()을 역추적한 결과, CIPC map은 chub->sram과 chub->mailbox를 인자로 초기화됐습니다. 이어 contexthub_dt_init()이 get_iomem(pdev, "mailbox")와 get_iomem(pdev, "sram")으로 두 자원을 가져오는 지점을 확인했습니다.

Device Tree에서 실제 MMIO 자원을 대응

pdev의 platform driver와 of_match_table을 따라 samsung,exynos-nanohub 노드를 식별했습니다. 실제 DTB를 DTS로 decompile한 뒤 해당 노드의 reg 항목과 reg-names 순서를 대조해, mailbox와 공유 SRAM이 Device Tree에 정의된 named MMIO resource임을 확인했습니다.

Device Tree 자원을 mailbox·SRAM으로 매핑하는 코드 원본

get_iomem()으로 Device Tree resource를 chub->mailbox와 chub->sram에 대응시킨 지점

samsung,exynos-nanohub 노드의 reg와 reg-names를 대조해 mailbox·공유 SRAM MMIO 영역을 대응한 원본

판단: AP의 delay 요청은 SSP/CIPC를 거쳐 공유 SRAM에 복사되고 mailbox 경계까지 전달됩니다. 이 결론은 AP 측 커널·Device Tree에서 정적으로 재구성한 범위이며, Hub 내부 수신 handler와 ODR setter의 직접 연결은 확인하지 못했습니다.

여기까지 AP 측 전달 경계를 확인했습니다. 다음 질문은 Hub가 명령을 받은 뒤 실제 ODR register를 어느 코드에서 갱신하는가였습니다. 이를 확인하기 위해 다음 4번에서 Sensor Hub firmware로 분석 대상을 옮겼습니다.

AFTER · SSP 명령을 Sensor Hub 경계까지 추적

generic IIO를 제외한 뒤 남은 질문은 SSP가 센서 register를 직접 쓰는지, Sensor Hub에 명령을 넘기는지였습니다.

함수 호출을 AP2CHUB data channel까지 추적한 뒤, I/O copy 구현과 MMIO base 초기화, Device Tree 자원을 연결했습니다. 그 결과 AP의 delay 요청이 SSP와 CIPC를 거쳐 공유 SRAM에 기록되는 정적 경로를 확인하고 다음 분석 대상을 Sensor Hub firmware로 옮겼습니다. Hub 수신 handler와 ODR setter의 직접 연결은 다음 단계의 미확인 경계로 남겼습니다.

4. Sensor Hub 펌웨어에서 ODR 수정 후보 지점 식별

Sensor Hub 소스 트리에는 바이너리 배열 형태의 펌웨어 헤더가 여러 개 존재했습니다. 빌드 설정의 CONFIG_SENSORS_SSP_HEART를 기준으로 대상 이미지를 좁힌 뒤, binwalk로 구조를 식별하지 못하자 Ghidra의 ARM Cortex/Thumb 분석으로 전환했습니다.

후보 firmware header 목록

header 내부에 포함된 firmware byte array

슬라이드의 왼쪽 설명 영역은 제거하고 원본 화면만 재배치했습니다. 여러 header 중 실제 선택 후보는 빌드 설정과 ssp_firmware.c의 조건부 포함 관계로 좁혔습니다.

성공 판정 정의 : polling rate와 ODR 분리

Android의 polling rate는 소프트웨어가 데이터를 요청·보고받는 주기이고, ODR은 센서가 내부에서 데이터를 생성하는 주기입니다. 따라서 API 지연값 변경만으로 ODR 변경을 판정하지 않았으며, 레지스터 설정과 이벤트 타임스탬프 변화가 함께 확인되어야 성공으로 정의했습니다.

문자열에서 레지스터까지 후보를 좁힌 과정

문자열 XL_ODR_SET을 출발점으로 XRef와 호출 관계를 추적해 FUN_0005f03c를 찾았습니다. 이 함수는 LSM6DSO32의 CTRL1_XL 레지스터 주소 0x10을 읽고, 인자의 하위 4비트를 ODR 필드에 반영하는 read-modify-write 후보로 분석했습니다.

FUN_0005f03c(0x87) 호출과 register 갱신 후보

CTRL1_XL의 ODR field와 값 대조

코드의 0x10을 데이터시트의 CTRL1_XL 주소와 대조해 ODR field를 갱신하는 read-modify-write 후보로 해석했습니다.

데이터시트 기준 0x14의 하위 값 4 → 104Hz

0x87의 하위 값 7 → 833Hz

0x00 → power-down

네 개의 호출 지점에서 이 상수들이 전달되는 것을 확인해 유력한 patch point 후보를 선별했습니다.

XL_ODR_SET 문자열의 XRef에서 setter 후보와 호출 관계를 좁힌 화면. 이 결과는 정적 patch 후보이며 런타임 실행 증거는 아닙니다.

Cross-layer Synthesis

AP 측에서 확인한 전달 경로와 Hub 측 register 갱신 후보를 하나의 구조로 합쳤습니다.

확인한 함수 단위 경로

AP 측 · set_acc_delay → change_sensor_delay → send_instruction → ssp_send_command → do_transfer → sensorhub_comms_write → contexthub_ipc_write → cipc_write_data → AP2CHUB mailbox/SRAM

Sensor Hub 측 · FUN_0005f03c → register read-modify-write → SPI → sensor register

미확인 구간 · CIPC payload가 어떤 펌웨어 수신 handler를 거쳐 ODR 함수 호출로 이어지는지

실선은 소스·device tree·펌웨어에서 각각 정적으로 추적한 구간입니다. 점선은 구조상 연결 후보지만 메시지 형식과 수신 handler의 직접 호출 관계를 끝까지 검증하지 못했습니다. 최종 구조 판단은 AP가 IPC와 공유 메모리를 통해 Sensor Hub에 명령을 전달하고, Sensor Hub가 SPI로 센서를 제어한다는 수준으로 한정했습니다.

5. 복구를 전제로 한 유선 Odin 테스트베드 구축

선행 핀맵을 실물 보드와 기능 결과로 교차검증

외부 XDA 핀맵과 회로 자료는 후보를 만드는 출발점으로 사용했습니다. 실물 보드의 남은 트레이스와 당시 멀티미터 측정 기록을 함께 대조해 5V / N.C / D+ / D− / GND 후보 배열과 연결할 네 선을 좁혔습니다. 최종 배선의 유효성은 regular Odin의 장치 인식과 PASS 결과로 기능 검증했습니다.

선행 회로 자료에서 확인한 VBUS·USB DM/DP·GND 신호 관계

선행 보드 레이아웃에서 확인한 test point 후보 위치

USB 테스트 패드 라벨 지도

실물 PCB의 5V / N.C / D+ / D− / GND 후보 배열. 선행 핀맵과 보드 자료는 가설로 사용하고, 당시 측정 기록과 최종 Odin 통신 결과로 배선의 유효성을 확인했습니다.

멀티미터·트레이스 교차검증 · 외부 핀맵을 가설로 두고 실물 트레이스와 멀티미터 측정으로 전원·데이터 후보를 비교했습니다. 계측기 화면과 수치 원시 로그는 남아 있지 않아 정량값은 기재하지 않았으며, 이후 regular Odin 통신 성공으로 최종 4선 배선의 유효성을 확인했습니다.

판단의 핵심: 문서상의 후보를 그대로 정답으로 두지 않고, 실물 트레이스·멀티미터 측정·기기의 실제 통신 반응을 단계별로 대조했습니다.

1차 납땜 실패를 공정 개선과 대체 경로로 전환

0.8 mm 연습 PCB로 사전 훈련한 뒤 실제 test pad에 1차 납땜을 시도했습니다. 납이 패드에 충분히 젖지 않았고 제거 과정의 열과 힘으로 미세 금도금 패드·트레이스가 박리됐습니다. 이를 단순한 손기술 실패로 두지 않고 표면 준비, flux, 인두 온도, 접촉 시간, 기계적 힘, 기판·선 고정으로 변수를 분해해 다시 연습했습니다.

남아 있는 트레이스와 멀티미터 측정을 바탕으로 손상 구간을 USB DATA−로 판단하고 대체 접점을 선택했습니다. 이후 선이 패드를 다시 잡아당기지 않도록 본체·커버·USB 케이블의 하중을 분리하는 JIG로 연결을 안정화했습니다.

연습 PCB → 1차 패드 손상 → 대체 접점·하중 분리 JIG → 4선 연결. 사진은 실제 제작·실패·재구성 기록입니다.

실제 납땜에 앞서, 커버를 열면 무선 충전이 끊겨 반복 연구가 불가능해지는 문제도 해결했습니다. WPC 수신 IC CPS4019와 커버 접점의 관계를 추적하고 단선 구리선으로 접점을 브리지해 커버가 열린 상태에서도 충전 가능한 환경을 확보했습니다.

물리 전송 성공과 부팅 검증 실패를 분리

완성한 4선 유선 경로로 USB Download Mode에 진입했고, regular Odin에서 순정 boot.tar 전송 PASS와 succeed 1 / failed 0을 확인했습니다. 이어 Sensor Hub firmware 수정, 문자열 수정, 임의 1-byte 수정 이미지를 각각 시도했지만 모두 부팅 단계에서 거부됐습니다.

따라서 대체 접점·JIG·USB 전송 경로는 성공, 수정 이미지의 부팅 허용은 미해결로 결과를 분리했습니다. regular Odin은 AVB를 우회하거나 복구 자체를 수행한 결과가 아니라, 안정적인 유선 전송·쓰기 경로를 확보한 성과입니다. soft-brick 복구는 앞서 검증한 netOdin 순정 복구 baseline이 담당했습니다.

장치 검증 순서

유선 경로 → Download Mode → 순정 이미지 Odin PASS → 수정 이미지 경고·복구 화면. 물리 전송과 부팅 무결성 검증을 같은 성공으로 묶지 않은 검증 순서

Appendix · Runtime Alternate Path — SMT Shell

수정 이미지가 부팅 단계에서 거부되자, 펌웨어를 교체하지 않고 런타임에서 센서 설정에 접근할 수 있는지 검증했습니다. XDA에 공개된 SMT Shell 절차를 재현해 셸이 Android system UID인 uid=1000(system)으로 동작함을 확인했지만, 목표 sysfs 읽기 접근은 Permission denied로 실패했습니다. 이는 root 획득이나 새로운 취약점 발견을 의미하지 않으며, system UID만으로는 해당 인터페이스를 제어할 수 없다는 결과입니다. SELinux/MAC은 가능한 원인이지만 감사 로그와 정책 추적이 없어 확정하지 않았습니다.

uid=1000(system) 확인

목표 attribute 읽기 접근 거부

공개 SMT Shell 절차로 system UID를 확보했지만 목표 sysfs 읽기 접근은 거부됐습니다. root 권한이 아니며, 직접 원인은 확인하지 못했습니다.

06 · Results & Limitations

Key Results

mkbootimg core 재구성 성공과 Samsung-specific signer·AVB 신뢰 경계를 통제 실험으로 분리

Samsung에 matching kernel source를 직접 요청해 동일 조건에 가까운 비교 환경 확보

generic driver 가설을 반증하고 Samsung SSP/Sensor Hub를 실제 제어 경로로 특정

AP 측 SSP/CIPC에서 MMIO mailbox·공유 SRAM까지, Hub 측에서 SPI/ODR 구간까지 각각 재구성

Sensor Hub firmware에서 ODR setter·register·네 호출 지점과 후보 상수 식별

non-A/B 기기에서 순정 복구, 분해 상태 충전, USB/JIG·regular Odin 전송 환경 구축

Odin PASS와 수정 이미지 부팅 거부를 서로 다른 성공 단계로 분리

07 · Lessons Learned

첫 차이가 곧 원인은 아닙니다. 41번째 byte 차이를 계기로 legacy 재구성 경로를 점검했고, AOSP 방식으로 표준 core 재구성을 검증했습니다. 이후 core 뒤에 남은 순정 tail을 별도로 분석해 Samsung signer·AVB 영역을 분리했습니다.

소스가 존재하는 것과 실제 빌드·실행되는 것은 다릅니다. menuconfig, binary diff, 실기기 정보를 함께 봐야 실제 제어 경로를 찾을 수 있었습니다.

전송 성공과 실행 성공을 분리해야 합니다. Odin의 PASS는 전달 단계의 성공이며 부팅 체인의 성공이 아니었습니다.

폐쇄형 기기는 계층을 넘나드는 디버깅이 필요합니다. Android, kernel, IPC, firmware, secure boot, 회로를 하나의 검증 흐름으로 연결했습니다.

실패는 다음 가설을 좁히는 관찰값입니다. 복구 경로와 성공 조건을 먼저 정의해 soft-brick과 권한 거부도 다음 의사결정에 사용할 수 있게 했습니다.

08 · Tools & Technologies

Platform: Wear OS, Android 11, Linux kernel, Samsung Sensor Platform/SSP

Firmware & Reverse Engineering: Ghidra, ARM/Thumb, binwalk, Device Tree, MMIO, CIPC/mailbox, SPI

Android Boot Security: boot.img, AVB 2.0, VBMeta, mkbootimg, unpack_bootimg, avbtool

Binary Analysis: readelf, objcopy, cmp, GHex

Device & Hardware: ADB, netOdin, regular Odin, schematic 분석, 멀티미터, 미세 납땜, USB/JIG 제작

Research Practice: 통제 실험, binary diff, 근거 교차검증, 복구 우선 실험 설계

09 · Evidence & Appendix

사용한 원본 기록과 검증 근거

Research slide 5.27~ · 무변경 repack의 초기 41-byte 차이와 플래싱 전 분석 기록

AOSP tool · AOSP 11/13 비교, 순정 core와 repack의 byte-identical 확인, signer·AVB offset 분석

vbmeta.img analyze / Vbmeta.img analyze 2 · descriptor·authentication·auxiliary·trusted key 구조 분석

납땜 및 피드백 · Samsung source 요청·회신, kernel version 불일치와 matching build 기록

into the deep · menuconfig 검증, generic driver 가설 폐기, 센서 타깃 교차검증

sensorhub & mailbox · SSP/CIPC 호출, AP2CHUB mailbox·공유 SRAM 분석

sensorhub firmware analyze · 대상 firmware 선택, CTRL1_XL과 ODR setter·XRef 분석

OEM unlock · boot/vbmeta 조합, OEM Unlock 전후 Secure Fail·soft-brick·순정 복구

Soldering process · USB/JIG 제작, 패드 손상·DATA− 진단, Odin PASS, 수정 이미지 부팅 거부

SMT Shell 실험 기록 · 공개 절차 재현, uid=1000(system), 목표 sysfs Permission denied