PANGOLIN 논문 리뷰 — LLM 기반 다국어 IoT 펌웨어 퍼징
USENIX Security 2026 PANGOLIN 논문 리뷰 — LLM 에이전트로 IoT 펌웨어의 숨겨진 API를 발굴해 68개의 0-day 취약점을 찾아낸 다국어 퍼징 시스템을 보안 입문자 시점에서 정리
PANGOLIN: Fuzzing Multilingual IoT Firmware with LLM-Driven Code Analysis
한 줄로 요약하면: AI(LLM)에게 IoT 기기 안의 코드를 읽혀서, 사람도 잘 못 찾는 "숨겨진 API"를 자동으로 찾아내고, 거기를 집중적으로 두드려 봤더니 68개의 새 보안 취약점이 한꺼번에 나왔다는 이야기.
0. 논문 제목 및 학회명
▪ 제목: PANGOLIN: Fuzzing Multilingual IoT Firmware with LLM-Driven Code Analysis
▪ 저자: Zhipeng Jia, Xiaokang Yin, Shuitao Gan, Chao Zhang 외 6명
▪ 소속: Information Engineering University, Tsinghua University 등 (중국)
▪ 학회: USENIX Security 2026 (Prepublication, paper #14) — 시스템 보안 분야에서 가장 권위 있다고 들은 학회 중 하나라고 한다.
▪ 분야: 시스템 보안 / IoT 보안 / 퍼지 테스팅 / LLM 응용
0-1. 이 논문을 고른 이유
▪ 솔직히 처음에는 "USENIX Security"라는 이름만 보고 멋있어 보여서 끌렸다. 그런데 읽다 보니 다루는 대상이 우리 집에 있는 공유기, 학교 와이파이 장비, 가게에 있는 IP 카메라 같은 진짜 일상 기기들이라 점점 더 흥미가 갔다.
▪ 요즘 어딜 가도 "AI를 어디에 쓰느냐"가 화두인데, 보안 분야에서 LLM(ChatGPT 같은 거대한 언어 모델)을 실제로 어떻게 활용하는지가 가장 궁금했다. 이 논문은 그 좋은 예시처럼 보였다.
▪ 보안 입문자로서 "단순 요약"만 하면 의미가 없다고 생각했다. 그래서 일부러 방법론이 다소 어렵게 느껴지는 논문을 골랐다. 어려운 걸 풀어 써 보는 게 진짜 공부라고 생각해서.
▪ 마지막으로, 이 논문은 2026년 발표 예정 인 따끈따끈한 논문이라 최신 흐름을 따라가 보기에도 좋아 보였다.
1. 기 — 연구 배경과 문제 정의
1-1. 일단 IoT가 뭔지부터
▪ IoT(Internet of Things, 사물 인터넷) 라는 말은 자주 들어봤지만, 정확히 뭐냐고 물으면 헷갈렸다. 이 논문을 읽으면서 정리한 내 나름의 이해: "네트워크에 연결돼서 뭔가를 주고받는 작은 기기들" 을 모두 IoT라고 부른다.
▪ 예를 들어 집에 있는 와이파이 공유기, 거실의 IP 카메라, 사무실의 NAS(Network Attached Storage, 네트워크 저장 장치) 같은 것들이 다 IoT 기기다.
▪ 이 기기들 안에는 작은 컴퓨터처럼 운영체제와 소프트웨어가 들어 있다. 이걸 펌웨어(firmware) 라고 부른다. PC의 윈도우/맥OS 같은 역할.
▪ 그리고 이 펌웨어 안에는 보통 작은 웹 서버가 들어 있어서, 우리가 브라우저로 192.168.0.1 같은 주소에 접속하면 설정 화면이 뜨는 거다. 알고 보면 단순히 "기기"가 아니라 작은 컴퓨터 + 작은 웹사이트가 함께 들어 있는 셈.
1-2. 그런데 이 펌웨어가 좀 특이하게 만들어져 있다고 한다
▪ 한 가지 언어로 짜인 게 아니라, 여러 언어가 섞여서 짜여 있다. 이걸 논문에서는 다국어(multilingual) 라고 부른다.
▪ 예를 들어, 속도가 중요한 부분은 C 언어로 컴파일된 바이너리(binary, 기계어 실행 파일) 가 처리하고, 설정 처리·요청 라우팅처럼 자주 바뀌는 부분은 Lua나 Python 같은 스크립트 언어가 처리한다.
▪ 더 놀라운 건, 이 둘이 서로 호출한다는 거다. Lua 스크립트가 C 바이너리 함수를 부르고, 그 C 함수가 또 다른 .so 파일(공유 라이브러리)의 함수를 부르는 식이다.
▪ 처음 이 부분을 읽었을 때 머리가 좀 복잡해졌다. 한 번의 요청이 무려 3개 언어, 3개 모듈을 거치는 경우도 있다고 한다.
1-3. 진짜 문제: "숨겨진 API"의 존재
▪ 웹 UI(사용자 화면)에서 보이는 버튼이나 메뉴는 사실 빙산의 일각이라고 한다. 백엔드(서버 코드 쪽)에는 UI에는 안 보이는데 코드에는 존재하는 API(Application Programming Interface, 요청 통로) 가 잔뜩 있다.
▪ 이걸 논문에서는 숨겨진 인터페이스(Hidden Interface) 라고 부른다. 처음 들었을 때 "왜 그런 게 있지?" 싶었는데, 생각해 보니 개발자들이 디버깅용·내부용·예전 버전 호환용으로 만들어 둔 통로가 그대로 남아 있는 경우가 많다고 한다.
▪ 그리고 이런 숨겨진 API는 보안 검증이 허술하다. 왜냐하면 "어차피 사용자가 직접 부를 일이 없을 텐데"라고 생각하고 만들었기 때문이다. 그런데 공격자는 정반대로 생각한다. "검증이 허술한 곳일수록 좋다".
▪ 이게 왜 무서운가? 공유기 하나가 뚫리면 그 공유기에 연결된 모든 기기가 위험해진다. 가정용 카메라가 뚫리면 영상이 유출될 수 있다. 회사 NAS가 뚫리면 회사 자료가 통째로 새어 나갈 수 있다. 우리가 매일 사용하는 와이파이 공유기 안에 그런 위험이 있다는 게 새삼 무섭게 느껴졌다.
1-4. 그런데 기존 도구들은 왜 이 문제를 못 풀었나?
▪ 기존에도 보안 도구들이 있다. 가장 유명한 게 AFL(American Fuzzy Lop) 라는 퍼저(fuzzer)인데, 이건 일반적인 프로그램에는 잘 작동하지만 IoT처럼 여러 언어가 섞인 환경에서는 잘 안 통한다고 한다.
▪ 또 다른 도구로 LABRADOR라는 게 있는데, 이건 IoT 펌웨어에 특화돼 있다. 하지만 두 가지 큰 문제가 있다.
▪ 문제 1: LABRADOR는 한 가지 언어만 분석한다. 그래서 Lua가 C를 부르는 흐름이 끊겨 보인다. 마치 지하철 환승 정보가 없는 노선도 같은 느낌.
▪ 문제 2: LABRADOR는 눈에 보이는 UI에서만 단서를 가져온다. 그래서 숨겨진 API는 시야에 들어오지 않는다. "안 보이니까 분석도 안 한다"는 거다.
▪ 게다가 LABRADOR는 평균 1,367분(약 22시간) 의 정적 분석 시간이 필요하다고 한다. 새 펌웨어가 나올 때마다 하루 가까이 걸린다면, 보안 분석가가 따라잡기 어렵다.
| 도구 이름 | 어떻게 접근하나 | 무엇이 부족한가 |
|---|---|---|
| AFL / AFL++ | 무작위에 가까운 입력을 마구 던지는 범용 퍼저 | IoT 다국어 백엔드는 분석 못 함 |
| FirmAFL / FirmAE | 펌웨어를 가상 환경에서 흉내(에뮬레이션)내며 분석 | 진짜 하드웨어가 필요한 펌웨어는 부팅 자체가 안 됨 |
| LABRADOR | IoT 웹 펌웨어 전용 정적 분석 + 퍼저 | 한 언어만 분석 + UI 시드만 사용 → 숨겨진 API 못 봄 |
| EAGLEYE | LLM(AI)을 일부 활용한 IoT 퍼저 | 다국어 호출 추적은 못 함 |
▪ 즉, 기존 도구들의 한계를 정리하면 "보지 못하는 영역이 너무 많다" 와 "보더라도 너무 느리다" 두 가지로 요약된다.
2. 승 — 핵심 아이디어와 방법론
2-1. 핵심 아이디어를 한 문장으로
▪ "AI(LLM)에게 펌웨어 코드를 통째로 읽혀서 숨겨진 API와 그 사용법을 자동으로 뽑아내고, AI가 거짓말한 부분은 기기 응답으로 다시 검증한다."
▪ 처음 읽었을 때 "그래서 ChatGPT를 보안 분석가처럼 쓰겠다는 거지?"라고 단순하게 이해했다. 좀 더 보니 그것보다 훨씬 정교한 시스템이었다.
▪ 시스템 이름은 PANGOLIN(천산갑). 비늘이 겹겹이 덮인 동물 이름인데, 아마 "여러 층을 파고든다"는 의미인 듯하다.
▪ PANGOLIN은 크게 세 가지 단계로 구성된다:
-
Entry Map 만들기 — 숨겨진 API를 모두 찾아 지도로 그리기
-
MCG(Multilingual Call Graph) 만들기 — 언어가 다른 함수들끼리의 호출 관계를 그래프로 그리기
-
응답 기반 피드백 — AI가 만든 정보가 맞는지 진짜 기기 응답으로 확인하기
2-2. 방법론 1 — Entry Map 만들기 (숨겨진 API 지도화)
▪ 목표: 펌웨어 안의 "이 URL로 요청이 오면 → 이 함수가 처리한다"라는 모든 연결을 찾아내는 것.
▪ 이걸 위해 먼저 코드를 정규화(normalization) 한다. 정규화라는 게 어려운 말 같지만, 쉽게 말해 "AI가 읽기 좋게 정리" 하는 거다.
▪ 바이너리 파일은 사람이 못 읽으니까, 역어셈블(disassemble) 이라는 과정을 거쳐 그나마 사람이 읽을 수 있는 의사코드(pseudocode) 로 바꾼다. 더 친절하게, 데이터 영역에 들어 있는 문자열도 의사코드 안에 직접 끼워 넣어서 AI가 한눈에 볼 수 있게 만든다.
▪ 스크립트(Lua/Python)는 함수 단위로 잘라내고, 그 함수가 사용하는 전역 변수와 패키지 정보도 함께 묶어 준다.
▪ 그다음, AI에게 3가지 종류의 API 등록 패턴을 학습시킨다. 개발자들이 어떻게 API를 등록하는지 패턴이 보통 셋 중 하나라는 거다:
-
Function Segment: 함수 안에서
register("/login", handler_login)같은 식으로 등록 -
Data Segment: 딕셔너리·테이블 같은 자료구조에 매핑이 저장됨
-
Filename Segment: 파일 이름 자체가 URI 역할 (예:
cgi-bin/login.cgi)
▪ 이 단계의 결과: 12개 기기에서 총 2,856개의 API 명세가 자동으로 만들어졌고, 그중 1,753개가 숨겨진 인터페이스와 연결되어 있었다. 절반이 넘는 API가 UI에서는 보이지 않는 것들이었다는 뜻이다. 이 숫자를 보고 "와, 정말 빙산의 일각이라는 비유가 맞구나" 싶었다.
2-3. 방법론 2 — MCG(다국어 호출 그래프) 만들기
▪ 호출 그래프(Call Graph)란? 프로그램 안에서 "어떤 함수가 어떤 함수를 부르는지" 화살표로 그린 그림이라고 생각하면 된다. 점(노드)은 함수, 선(간선)은 "A가 B를 부른다"라는 관계.
▪ 일반 호출 그래프는 같은 언어 안에서만 화살표를 그린다. 그런데 IoT 펌웨어는 Lua가 C를 부르고, C가 또 다른 .so 파일을 부르는 식이라, 일반 그래프로는 추적이 끊긴다.
▪ 그래서 이 논문에서는 MCG(Multilingual Call Graph, 다국어 호출 그래프) 라는 새 그래프를 만든다. 이름 그대로 언어가 다른 함수들끼리의 호출까지 다 화살표로 연결한다.
▪ 그런데 그렇게 다 그리면 그래프가 너무 커진다. 거의 펌웨어 전체 코드를 화살표로 잇는 셈이니까. AI에게 통째로 넘기면 못 따라간다.
▪ 그래서 등장하는 게 역방향 가지치기(Reverse Pruning) 라는 기법이다. 처음에는 이 단어가 좀 어렵게 느껴졌는데, 풀어 보면 단순하다:
-
sink(싱크): 위험한 동작이 일어나는 지점. 예를 들어
system()이나popen()같은 함수. 이런 데로 사용자 입력이 그대로 들어가면 명령어 주입(command injection) 같은 취약점이 생긴다. -
역방향: sink에서 거꾸로 따라간다. "이 위험한 함수까지 도달하려면 어떤 길을 거쳐야 하지?"를 묻고 그 길만 남긴다.
▪ 비유하자면 "강 하구(sink)에서 수원지(source)로 거슬러 올라가는 지도" 만 그리는 거다. 모든 길이 아니라 위험한 곳으로 가는 길만.
▪ 처음에는 "왜 거꾸로 가지?"가 잘 이해가 안 됐다. 한참 생각해 보니 답이 보였다. 사용자 입력은 종류가 무한하지만 위험한 함수는 한정돼 있다. 그러니 한정된 쪽(sink)에서 출발하는 게 훨씬 효율적이다.
▪ 이렇게 가지친 MCG를 AI에게 넘기면, AI가 각 API의 매개변수 이름·타입·제약조건을 자동으로 뽑아 준다. 사람 분석가가 며칠 걸려서 할 일을 AI가 분 단위로 해 주는 셈이다.
예시 — 요청 하나가 3개 언어를 거쳐 취약점에 이르는 흐름
POST /rpc {"method":"call","params":["plugins","ginfo",{"name":"Payload"}]}
│
└─ Lua oui-rpc.lua : "method"="call" 분기
└─ C 바이너리 glc : params[0], params[1] 로 .so 파일/함수 결정
└─ C 바이너리 plugins.so :: ginfo()
: "name" 값을 system() 에 그대로 전달
→ command injection (명령어 주입) 취약점
▪ 이 그림이 논문에서 가장 어렵게 느껴진 부분이다. 한 번에 이해가 안 돼서 여러 번 다시 봤다. 핵심은 "기존 도구는 이 화살표 어딘가에서 끊어진다" 는 점이다. PANGOLIN은 끝까지 따라간다.
2-4. 방법론 3 — 응답 피드백 (AI가 거짓말하면 어떻게 잡지?)
▪ 사실 이 부분이 개인적으로 가장 인상 깊었다. AI를 써 본 사람은 알겠지만, AI는 그럴듯한 거짓말을 잘한다. 이걸 전문 용어로 환각(hallucination) 이라고 부른다.
▪ 보안 분석에 AI를 쓸 때 환각은 진짜 골칫거리다. AI가 "이 API에는 username, password, csrf_token이라는 세 매개변수가 있어요"라고 알려 줬는데, 사실은 csrf_token이 없는 거짓 정보였다면? 그걸로 퍼지를 돌려 봤자 의미 없는 요청만 잔뜩 쌓인다.
▪ 그래서 PANGOLIN이 쓰는 영리한 방법: 퍼지를 돌리면서 진짜 기기가 어떻게 응답하는지를 본다. 응답 코드(200, 400, 500), 응답 본문, 응답 시간 등을 모두 분석한다.
▪ 그리고 그 응답을 다시 AI에게 보여 준다. "네가 만든 명세대로 요청을 보냈더니 기기가 이렇게 응답했어. 이 응답 패턴을 보면 명세 어디가 틀린 것 같아?"라고 묻는 식이다.
▪ AI가 명세를 다듬으면 다시 퍼지를 돌린다. 이렇게 1회차 → 응답 분석 → 2회차 로 반복하면서 정확도가 올라간다. AI 스스로 자기 거짓말을 줄여 가는 셈이다.
▪ 그리고 퍼지를 돌릴 때도 세 가지 전략을 쓴다:
-
노드 우선순위(Node Priority): 취약 가능성이 높아 보이는 API부터 집중 테스트.
-
변이 전략(Mutation Strategy): 매개변수가 정수면 큰 수·음수·0을, 문자열이면 특수문자·매우 긴 문자열을 넣어 보는 식으로 타입에 맞게 변형.
-
에너지 할당(Energy Assignment): 더 많은 새 코드 경로를 발견한 입력에 테스트 자원을 더 배정.
3. 전 — 실험과 결과, 그리고 한계
3-1. 실험 환경
▪ PANGOLIN은 에뮬레이션이 아니라 진짜 기기에서 돌렸다. 이게 의외로 큰 의미가 있다. 가상 환경에서는 잘 돌지만 진짜 기기에서는 안 되는 경우가 많기 때문.
▪ 테스트한 기기는 8개 제조사의 12개 IoT 기기. 브랜드 이름을 보면 Cisco, Huawei, Xiaomi, Linksys, TP-LINK, Netgear, GL-iNet, Ruijie, HIKSEMI… 거의 다 우리가 쇼핑몰에서 한 번쯤 본 적 있는 브랜드들이다.
3-2. 결과를 숫자로 보면
| 무엇을 | 얼마나 |
|---|---|
| 발견한 새 취약점(0-day) | 68개 |
| 공식 ID(CVE / CNVD)가 매겨진 것 | 31개 |
| 가장 심각한 취약점의 CVSS 점수 | 10.0 만점 (CNVD-2025-14455, CNVD-2025-18467) |
| 추출한 전체 API 인터페이스 | 2,856개 |
| 그중 숨겨진 인터페이스 | 1,793개 |
▪ 처음에 68개라는 숫자를 봤을 때 그냥 숫자로만 받아들였다. 그런데 그게 전부 0-day, 즉 아직 패치되지 않은 새 취약점이라는 걸 알고 나니 좀 다르게 느껴졌다. 한 논문이 한 번에 68개의 새 보안 구멍을 찾아낸 거다.
▪ 발견된 취약점 종류도 다양했다:
-
Command Injection(명령어 주입): 공격자가 보낸 문자열이 시스템 명령으로 실행되는 가장 위험한 종류.
-
XSS(Cross-Site Scripting, 크로스 사이트 스크립팅): 공격자의 스크립트가 다른 사용자 화면에서 실행되는 것.
-
Information Leak(정보 유출): 비밀이 새는 것.
-
DoS(Denial of Service, 서비스 거부): 기기를 마비시키는 것.
-
Arbitrary File Upload/Download(임의 파일 업·다운로드): 공격자가 원하는 파일을 올리거나 가져가는 것.
3-3. 기존 도구들과 비교하면 얼마나 더 잘했나?
▪ vs LABRADOR (기존 SOTA = State of the Art, 최첨단 기술)
-
발견한 취약점: PANGOLIN 68개 vs LABRADOR 23개 → 약 2.96배
-
정적 분석 시간: PANGOLIN 약 72분 vs LABRADOR 약 1,367분 → 약 19배 빠름
-
LABRADOR가 놓친 45개 취약점은 전부 숨겨진 인터페이스 에 있었다. 즉, "안 보이는 곳에 진짜 보물이 있었다"는 게 숫자로 증명된 셈.
▪ vs EAGLEYE (LLM 기반 경쟁 도구)
-
숨겨진 인터페이스 발굴: PANGOLIN 1,793개 vs EAGLEYE 일부 기기에서 0개
-
숨겨진 인터페이스에서 찾은 취약점: PANGOLIN 45개 vs EAGLEYE 4개
▪ 처음 이 비교를 봤을 때 "정말 큰 차이네"라고 생각했다. 같은 LLM을 쓰는 도구 사이에서도 차이가 이 정도라는 건, 결국 LLM을 어떻게 쓰느냐가 더 중요하다는 뜻으로 보였다.
3-4. 어느 부분이 진짜 중요했나? (Ablation 분석)
▪ Ablation(어블레이션, 컴포넌트 하나씩 빼 보는 실험)이라는 단어를 이 논문에서 처음 봤다. 풀어 쓰면 "세 가지 단계 중 하나를 빼 보면 결과가 얼마나 떨어지는지" 실험이다.
| 어떤 변형이냐 | 발견한 취약점 | 잃은 수 | 결론 |
|---|---|---|---|
| PANGOLIN 전체 | 68 | — | 기준선 |
| Entry Map 빼면 | 23 | -45 | 숨겨진 API 발굴이 진짜 핵심 |
| MCG 빼면 | 24 | -44 | 다국어 호출 분석도 진짜 핵심 |
| 시퀀스 인식 빼면 | 60 | -8 | 복합 취약점에 일부 기여 |
| 응답 피드백 빼면 | 49~60 | -8~-25 | 명세 정제에 의미 있게 기여 |
▪ 이 표가 의외로 많은 걸 말해 준다. Entry Map만 빼도 취약점이 68개에서 23개로 떨어진다. 즉 "어떻게 보느냐"보다 "어디를 보느냐" 가 훨씬 중요했다는 뜻이다. 이 점이 좀 충격이었다.
3-5. AI 모델을 바꿔도 결과가 같을까?
▪ 저자들은 DeepSeek-V3, GPT-4.1-nano, Claude-3.5-Haiku 세 가지 LLM으로 같은 실험을 돌려 봤다.
▪ 결과: 생성된 명세 수는 약간 다르지만 최종 발견 취약점은 모두 68개로 동일.
▪ 이게 의미하는 바는 명확하다. "어떤 AI를 쓰느냐"가 아니라 "AI에게 무엇을 보여 주고 어떻게 검증하느냐"가 진짜 시스템의 핵심이라는 거다. AI는 도구일 뿐이고, 시스템 설계가 결과를 만든다.
3-6. 한계점 — 저자들도 인정한 것들
▪ 버퍼 오버플로(Buffer Overflow)를 일부 못 잡는다: 버퍼 오버플로는 메모리를 넘쳐흐르게 만드는 공격인데, 부 모듈에서 발생하면 전체 서비스가 안 죽어서 PANGOLIN이 감지를 못 한다.
▪ 여러 번 재부팅되면 사람이 손봐 줘야 한다: 기기가 여러 번 다시 시작되면 PANGOLIN이 자동으로 다시 연결을 못 한다. 공장 초기화(factory reset)를 사람이 직접 해 줘야 함.
▪ 난독화·암호화된 펌웨어는 약함: 어떤 제조사들은 분석을 어렵게 하려고 코드를 일부러 꼬아 놓는다(난독화). 그러면 AI도 잘 못 읽는다.
▪ 아주 큰 펌웨어는 검증 안 됨: 이번에 쓴 12개 기기는 대부분 가정용·중소기업용이었다. 데이터센터급 대형 펌웨어에서도 잘 돌아갈지는 미지수.
3-7. 결과 정리
▪ PANGOLIN은 단순히 "더 좋은 보안 도구"가 아니라, 그동안 아무도 안 보던 영역(숨겨진 API)을 처음으로 대규모 자동 탐색한 연구다.
▪ 핵심은 세 가지 합작: AI에게 코드를 읽힌다 + 언어 경계를 넘는 호출까지 추적한다 + AI의 거짓말을 기기 응답으로 검증한다.
▪ 그리고 이게 이미 진짜 제품들에서 68개의 실제 취약점을 만들어 냈다. 학술 논문이지만 산업적 영향도 엄청나다.
4. 결 — 느낀 점과 앞으로 해볼 것
4-1. 이 논문을 통해 새로 배운 보안 개념들
▪ 퍼징(Fuzzing): 일부러 이상한 입력을 잔뜩 던져 결함을 찾는 기법. 처음에는 "그냥 랜덤 아닌가?"라고 생각했는데, 실제로는 "코드 구조를 알고 영리하게 두드려 보는 기법" 이라는 걸 알게 됐다.
▪ 숨겨진 인터페이스(Hidden Interface): UI에는 없지만 코드에는 있는 API. "안 보이니 안전하다"는 직관이 얼마나 위험한지 진짜로 와닿았다.
▪ 호출 그래프(Call Graph): 함수들이 서로 부르는 관계를 그린 그림. 이걸 거꾸로 따라간다는 발상이 신선했다.
▪ sink-to-source 역추적: 위험한 결과 지점(sink)에서 사용자 입력(source)으로 거꾸로 따라가는 분석 방식. 처음엔 어색했는데, 한정된 곳에서 출발하는 게 더 효율적이라는 걸 알고 납득됐다.
▪ AI 환각(hallucination): AI가 그럴듯한 거짓을 만들어내는 현상. 보안에 AI를 쓸 때 가장 큰 위험인데, "응답으로 자체 검증"이라는 방법이 흥미로웠다.
▪ 0-day vs n-day: 공식 패치가 아직 안 된 취약점이 0-day, 패치가 있는데 사용자가 안 깐 경우가 n-day. 0-day가 훨씬 위험하다.
▪ CVE / CNVD: 공개 취약점에 부여되는 식별자. CVE는 미국 중심, CNVD는 중국. 식별자가 매겨졌다는 건 공인된 취약점이라는 뜻.
▪ CVSS 점수: 취약점의 심각도를 0~10점으로 매긴 점수. 10점이 최악. 이 논문에서 발견한 것 중 두 개가 만점이다.
4-2. 가장 인상 깊었던 점
▪ AI를 "코드 요약기"가 아니라 "보안 추론 에이전트"로 쓴 발상이 신선했다. ChatGPT한테 "이거 요약해 줘"라고 묻는 수준이 아니라, "이 코드에서 위험한 길을 찾아 줘, 그리고 그 길을 매개변수까지 자동으로 설계해 줘" 라고 시키는 식이다.
▪ "도구 성능을 올려서 더 많이 찾았다"가 아니라 "기존 도구가 아예 못 보던 영역을 열었다" 는 관점이 인상적이었다. 같은 자리에서 더 잘하려는 게 아니라, 새 자리를 만들어 낸 연구 라는 느낌.
▪ Ablation에서 Entry Map 하나만 빼도 결과가 반토막 나는 걸 보고, "무엇을 보느냐가 어떻게 보느냐보다 중요할 수 있다" 는 교훈을 얻었다. 보안뿐 아니라 다른 분야에도 적용될 수 있는 통찰 같다.
4-3. 어렵게 느껴졌던 점 (솔직히)
▪ 다국어 호출 추적이 머릿속에서 잘 안 그려졌다. Lua가 C를 부르고, 그 C가 또 다른 .so의 함수를 부르는 흐름을 처음 봤을 때 좀 멍해졌다. Figure 3을 세 번쯤 다시 봤다.
▪ 역방향 가지치기의 직관이 처음에는 안 와닿았다. "왜 거꾸로 가?"라는 의문이 한참 남아 있다가, "사용자 입력은 무한, sink는 유한"이라는 걸 깨닫고 풀렸다.
▪ 정적 분석 / 동적 분석 / 퍼지 / 심볼릭 실행 같은 보안 분석의 큰 갈래가 한꺼번에 나와서 헷갈렸다. 각각이 뭔지 따로 정리해 봐야겠다는 숙제가 생겼다.
▪ 솔직히 논문 전체 흐름을 처음부터 따라가는 게 쉽지 않았다. 한 번에 다 이해하려 하지 말고, 섹션별로 끊어서 여러 번 읽는 게 도움이 됐다.
4-4. 우리 일상과의 연결
▪ 발견된 취약점 기기들(Linksys, TP-LINK, Netgear, Xiaomi 공유기 등)은 우리 집과 학교, 카페에서 매일 보는 것들이다. "논문 속 보안"이 아니라 "내 책상 위 보안" 의 이야기였다.
▪ 그래서 새로 생긴 실생활 습관: 공유기를 살 때 펌웨어 업데이트 정책을 확인하기. 어떤 회사는 1~2년 지나면 업데이트를 안 해 준다. 그런 기기는 이런 논문에서 발견된 취약점이 영원히 남아 있을 수 있다.
▪ 또 하나: 공유기 관리자 페이지를 외부에서 접속 못 하게 막아 두기. 평소 같으면 "귀찮은데" 했을 텐데, 이 논문 읽고 나서는 마음가짐이 좀 달라졌다.
4-5. 앞으로 해볼 것
(1) 더 읽어볼 논문 / 자료
▪ LABRADOR, EAGLEYE 원논문 — PANGOLIN이 비교 대상으로 쓴 도구들. 이걸 봐야 PANGOLIN이 정말 얼마나 발전한 건지 더 잘 이해할 수 있을 것 같다.
▪ AFL / AFL++ 관련 자료 — 퍼지 기법의 기초부터 차근차근.
▪ FirmAFL, FirmAE — 펌웨어 에뮬레이션 기반 분석. 에뮬레이션 쪽이 왜 한계가 있는지 직접 확인해 보고 싶다.
▪ OWASP IoT Top 10 — IoT 보안 위협의 표준 분류. 보안 입문자가 가장 먼저 봐야 할 자료라고 들었다.
▪ LLM4Vuln, LLM4Fuzz 계열 — LLM을 보안에 응용한 다른 시도들. 트렌드를 한 번에 보고 싶다.
(2) 비슷한 문제를 다른 분야에 적용해 본다면
▪ 클라우드 API 게이트웨이의 숨겨진 엔드포인트에도 같은 접근이 통할까? AWS, GCP 같은 곳에 분명 비슷한 숨은 통로가 있을 것 같다.
▪ 모바일 앱의 딥링크(deep link)와 인텐트(intent) 도 사용자가 직접 호출하지 않는 숨겨진 표면이다. 안드로이드 앱에 PANGOLIN식 접근을 옮겨 보면 어떨까?
▪ 자동차 ECU(Electronic Control Unit) 도 점점 다국어 펌웨어가 되어 가고 있다고 들었다. 거기까지 확장한다면 자율주행 보안 연구의 큰 줄기가 될 수도.
(3) 직접 해 보고 싶은 작은 실험
▪ 오픈소스 펌웨어 OpenWrt (가정용 공유기에 자주 쓰는 오픈 펌웨어)를 다운받아, ChatGPT나 Claude에게 일부 코드를 넣고 "이 코드의 API 진입점이 어디야?" 라고 물어보는 실험. PANGOLIN 1단계의 가장 단순한 흉내.
▪ 응답 피드백 루프의 미니 버전: 임의 API에 무작위 요청을 보내고, 응답 코드별로 입력 형태를 좁혀 가는 작은 파이썬 스크립트. 직접 만들면서 왜 이런 피드백이 중요한지 체감하고 싶다.
▪ Burp Suite나 OWASP ZAP 같은 웹 보안 도구를 만져 보면서, 일반적인 웹 보안 분석은 어떻게 하는지 감을 잡기.
(4) 만약 내가 연구나 프로젝트로 발전시킨다면
▪ "LLM 환각 검증 라이브러리" 만들기 — 여러 IoT 펌웨어 응답 패턴을 모아서 "이런 응답이 오면 명세가 틀린 것"이라는 규칙을 학습시키는 작은 라이브러리. PANGOLIN의 2회차 정제 속도를 더 올리는 방향.
▪ 난독화 펌웨어 전처리 파이프라인 — 이 논문이 인정한 한계 중 하나. 난독화를 풀어 주는(deobfuscation) 단계를 앞에 붙이면 적용 범위가 훨씬 넓어질 것 같다.
▪ 분야 확장 — 모바일 / 차량 / 산업 제어 시스템(ICS, Industrial Control System)의 다국어 펌웨어로 같은 접근을 옮기기. 특히 ICS는 한 번 뚫리면 사람 목숨까지 위험할 수 있어서 사회적 가치가 크다.
▪ 가장 흥미로운 방향은 "AI 보안 분석가 협업 UI" 를 만드는 것. PANGOLIN처럼 완전 자동도 좋지만, 사람 분석가와 AI가 같이 토론하면서 펌웨어를 들여다보는 도구가 있으면 어떨까? 그게 보안 연구의 다음 방향이 아닐까 싶다.
5. 참고문헌
▪ [1] Z. Jia et al., PANGOLIN: Fuzzing Multilingual IoT Firmware with LLM-Driven Code Analysis, USENIX Security 2026 (Prepublication, paper #14). — 본 리뷰의 대상 논문.
▪ [2] LABRADOR — 본 논문에서 비교 대상(baseline)으로 사용된 IoT 웹 펌웨어 퍼저.
▪ [3] EAGLEYE — 본 논문에서 비교 대상으로 사용된 LLM 기반 IoT 퍼저.
▪ [4] AFL / AFL++ — 커버리지 기반 퍼지의 대표 도구. 퍼지 입문 자료로 자주 언급.
▪ [5] FirmAFL, FirmAE — 펌웨어 에뮬레이션 기반 퍼지 연구.
▪ [6] OWASP IoT Top 10 — IoT 보안 위협 분류 표준. 입문자가 먼저 보면 좋은 자료.