AI 인프라를 설계하다 보면 가끔 숨이 턱 막힐 때가 있습니다.
화려한 LLM 모델 파라미터 숫자놀음에 취해, 정작 그 코드가 돌아가는 하드웨어(Hardware)의 밑바닥을 잊어버린 개발자들을 볼 때죠.
"라이브러리 import만 하면 되는 거 아닌가요?"라고 묻는 주니어들에게 이 글을 바칩니다.
오늘은 독일 뮌헨의 보안 연구팀 'Neodyme'이 4K 드론인 Potensic Atom 2를 해부한 기록을 가져왔습니다.
추상적인 소프트웨어 이야기가 아닙니다.
인두기와 핫에어, 그리고 데이터시트(Datasheet) 한 장을 들고 펌웨어와 싸우는 진짜 엔지니어들의 이야기입니다.
목표: 펌웨어를 확보하라
보안 취약점을 찾으려면 일단 펌웨어(Firmware)가 있어야 합니다.
소스코드를 봐야 버그를 찾든 백도어를 심든 할 테니까요.
보통 세 가지 방법이 있습니다.
첫째, 제조사 웹사이트에서 OTA 업데이트 파일을 받는다.
가장 깔끔해 보이죠?
하지만 Atom 2의 경우, 유효한 시리얼 넘버가 필요했고 파일 자체가 암호화되어 있었습니다.
복호화 로직을 모르면 그저 쓰레기 데이터일 뿐입니다. 여기서 시간 낭비하면 ROI(투자 대비 수익)가 안 나옵니다.
둘째, JTAG나 UART 같은 디버깅 포트를 찾는다.
보드 어딘가에 숨겨진 핀을 찾아 연결하는 겁니다.
하지만 제조사들도 바보가 아닙니다.
양산 버전에서는 이 포트를 제거하거나 막아버리는 게 업계 표준(De Facto Standard)입니다. Atom 2 역시 닫혀 있었죠.
결국 남은 건 하나뿐입니다.
"물리적으로 칩을 떼어내서 데이터를 긁어낸다."
NAND 플래시 메모리를 보드에서 분리해 리더기에 물리는 방식입니다.
가장 무식해 보이지만, 암호화 키가 TPM 같은 별도 보안 칩에 있지 않다면 가장 확실한 방법입니다.
하드웨어 정찰: 적을 알아야 한다
무턱대고 인두기를 들이대면 보드 다 태워 먹습니다.
먼저 칩 구성을 파악해야 합니다. RF 실드(Shield)를 뜯어내고 마킹을 읽습니다.
SoC (System on Chip)
'23AP10'이라고 적혀 있군요.
검색해보니 HiSilicon의 SD3403V100 대체품으로 추정됩니다. 카메라 제어용 칩셋입니다.
RAM
삼성전자나 하이닉스 같은 벤더의 표준 규격을 따릅니다. 데이터시트는 구글링하면 1초 만에 나옵니다.
NAND Flash
오늘의 타겟입니다.
Macronix사의 MX35UF4GE4AD 모델.
데이터시트를 확인해보니 1.8V 전압을 쓰고, SPI(Serial Peripheral Interface) 프로토콜로 통신합니다.
여기서 중요한 포인트.
개발자라면 "SPI 통신이네" 하고 넘어가면 안 됩니다.
핀 맵(Pin Map)을 외워야 합니다.
CS#(Chip Select), SI(Input), SO(Output), SCLK(Clock).
이 4개의 라인이 생명줄입니다.
물리적 전쟁: 에폭시와의 사투
칩을 식별했으니 떼어내야 합니다.
문제는 제조사가 칩을 고정하기 위해 에폭시(Epoxy)나 언더필(Underfill) 처리를 해놨다는 겁니다.
단순히 충격 방지용일 수도 있지만, 우리 같은 리버스 엔지니어링을 방해하려는 의도도 다분합니다.
핫에어(Hot Air)로 열을 가하면서 날카로운 칼로 에폭시를 긁어내야 합니다.
이 과정에서 주변의 깨알 같은 저항(Resistor)들이 같이 떨어져 나갈 확률? 매우 높습니다.
실제로 Neodyme 팀도 저항 몇 개를 날려 먹었고 보드는 사망했습니다.
하지만 괜찮습니다.
"드론 두세 대 더 사면 그만"이라는 마인드.
이게 바로 엔지니어링의 TCO(총 소유 비용) 관점입니다. 시간 낭비하느니 하드웨어를 교체하는 게 싸게 먹힙니다.
데이터 추출: 최후의 납땜
떼어낸 8핀 WSON 패키지 칩을 어떻게 읽을까요?
전용 소켓이 있으면 좋겠지만, 규격이 안 맞으면 답이 없습니다.
결국 고전적인 방법을 씁니다.
현미경을 보면서 머리카락보다 얇은 구리선을 칩의 핀에 직접 납땜합니다.
그리고 SPI 리더기에 연결합니다.
SI, SO 데이터 라인을 통해 0과 1의 비트스트림이 넘어오는 순간, 펌웨어 덤프(Dump)가 완료됩니다.
마무리하며
이 모든 과정은 화려한 AI 모델 학습이나 클라우드 아키텍처와는 거리가 멉니다.
하지만 누군가가 이 '지저분한' 하드웨어 레벨의 데이터를 퍼 올리지 않으면, 그 어떤 상위 레벨의 혁신도 불가능합니다.
서버실에서 에어컨 바람 쐬며 터미널만 두드리는 게 개발의 전부가 아닙니다.
가끔은 내 코드가 물리적으로 어디에 저장되고, 어떤 전압을 타고 흐르는지 고민해 보십시오.
그게 진짜 엔지니어의 'Deep Dive'입니다.
다음 편에서는 이렇게 획득한 덤프 데이터에서 어떻게 파일 시스템을 복구하고 취약점을 찾아내는지 이야기해 보겠습니다.
