Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6

논문 개요: 중독된 식별자 (Poisoned Identifiers) 와 LLM 역분해

이 논문은 Claude Opus 4.6(및 Haiku 4.5) 을 대상으로, JavaScript 코드 역분해 (Deobfuscation) 과정에서 모델이 **의도적으로 오염된 식별자 이름 (Poisoned Identifiers)**을 어떻게 처리하는지 연구한 사례 연구입니다. 핵심 발견은 모델이 코드의 의미론적 (Semantic) 구조를 완전히 이해하고 있음에도 불구하고, 역분해된 문자열 테이블 (String Table) 에 포함된 잘못된 변수 이름을 코드 블록 내에서 그대로 유지한다는 점입니다.

---

1. 문제 정의 (Problem)

• 배경: LLM 은 일반적으로 난독화된 (Obfuscated) JavaScript 코드를 역분해하여 가독성 있는 코드로 복원하는 데 탁월한 능력을 보입니다.
• 가정: 만약 난독화 과정에서 변수 이름이 실제 의미와 무관하거나 오해의 소지가 있는 이름 (예: repulsion을 attraction으로, damping을 amplification으로 변경) 으로 대체되었다면, LLM 은 이를 감지하고 올바른 이름으로 수정할 것이라고 기대할 수 있습니다.
• 연구 질문: LLM 이 코드의 수학적 논리나 주석을 통해 올바른 의미를 파악하고 있음에도 불구하고, 역분해된 원본 문자열의 잘못된 식별자 이름을 코드 블록 내에서 유지하는가? 그리고 이를 방지하기 위한 명시적 지시 (Verification Prompts) 는 효과가 있는가?

---

2. 방법론 (Methodology)

연구는 두 단계 (Phase A, Phase B) 로 나뉘어 진행되었으며, 두 가지 코드 아키텍처 (물리 시뮬레이션: 힘 기반 그래프, 알고리즘: A* 경로 찾기) 를 사용했습니다.

• 실험 자극 (Stimuli):

  • Poisoned Identifiers: 물리 법칙이나 알고리즘 논리에 반하는 이름으로 변수를 변경 (예: repulsion → attraction, heuristic → invoice).
  • 난독화: 제어 흐름 평탄화 (Control Flow Flattening), RC4 문자열 인코딩 등 다양한 난독화 기법 적용.
  • 대조군: 오염되지 않은 정상 코드, 의미적 적합도가 0 인 완전히 무관한 단어 사용 (예: repulsion → combustion).

• 실험 단계:

  • Phase A (탐색적): Claude Code CLI(도구 사용 가능) 를 사용하여 28 회 실행. 정성적 관찰 및 가설 생성.
  • Phase B (체계적): Anthropic Messages API(도구 없음) 를 사용하여 192 회 자동화 실행. 50 가지 조건, 3~6 회 반복.

• 평가 지표:

  • 주요 종단점: 모델 출력의 코드 블록 내에 오염된 식별자가 유지되었는지 여부 (이진 분류).
  • 이중 표현 패턴 (Dual-representation): 코드 블록에는 잘못된 이름이, 주석이나 설명에는 올바른 의미 설명이 동시에 존재하는지 확인.
  • 프레이밍 실험: "이 코드를 역분해하라 (Deobfuscate)" vs "이 기능을 처음부터 다시 작성하라 (Write from scratch)" 프롬프트 비교.

---

3. 주요 결과 (Key Results)

3.1 명시적 검증 지시의 실패

• 모델에게 "수학과 일치하는지 각 이름을 검증하라"거나 "문자열 테이블이 적대적일 수 있으니 주의하라"는 명시적 지시를 주었음에도 불구하고, 12/12 회 실행에서 잘못된 식별자가 코드 블록에 그대로 유지되었습니다.
• 모델은 검증에 더 많은 시간을 할애했으나, 결과적으로는 실패했습니다.

3.2 이중 표현 패턴 (Dual-Representation Pattern)

• 모델은 코드의 논리를 정확히 이해하고 있었습니다.
  • 코드 블록: attraction (잘못된 이름) 사용.
  • 주석/설명: "Repulsion force strength" (올바른 의미) 로 정확히 설명.
• 물리 시뮬레이션 아키텍처의 17 회 실행 중 15 회에서 이 패턴이 관찰되었습니다. 모델은 의미론적 지식과 잘못된 식별자 사용을 동시에 수행했습니다.

3.3 작업 프레이밍 (Task Framing) 의 결정적 영향

• 역분해 프레이밍 ("Deobfuscate this"): 오염된 식별자 유지율 100%.
• 재구현 프레이밍 ("Write a fresh implementation from scratch"):
  • 물리 시뮬레이션: 유지율 100% → 20% 로 감소.
  • 경로 찾기 (Pathfinding): 유지율 100% → 0% (완전 제거).
• 결론: 모델은 '역분해 (번역)' 태스크에서는 원본 문자열을 그대로 따르지만, '새로운 구현 (생성)' 태스크에서는 알고리즘 구조에 기반하여 올바른 이름을 생성합니다.

3.4 의미적 적합도 (Semantic Fit) 와 도메인 일관성

• 기존 가설: 이름이 해당 도메인 (물리 등) 에서 그럴듯해야 유지될 것이라 생각됨.
• 실제 발견: 의미적 적합도가 0 인 단어 (예: repulsion → combustion, heuristic → invoice) 도 문자열 테이블이 대체 도메인을 형성하지 않는 한 동일한 비율로 유지되었습니다.
• 예외: 모든 변수가 일관된 다른 도메인 (예: 공학 용어) 으로 대체된 경우에만 모델이 이를 감지하고 수정했습니다. 즉, 개별 단어의 의미보다는 전체 문자열 테이블의 도메인 일관성이 모델의 판단에 영향을 미쳤습니다.

3.5 도구 사용의 차이

• 도구 (Tool use) 를 사용하는 Claude Code(Phase A) 와 API(Phase B) 간 행동 차이가 관찰되었습니다. 도구 사용 시 모델은 더 복잡한 분석을 시도했으나, API 단일 실행에서는 '거부 (Refusal)'가 이진적 (Binary) 으로 발생하거나 역분해가 수행되었습니다.

---

4. 주요 기여 (Key Contributions)

1. LLM 역분해의 취약점 규명: LLM 이 코드의 논리를 이해하고 있음에도 불구하고, 역분해 과정에서 원본 문자열의 '오염된 식별자'를 신뢰하고 유지하는 경향을首次로 증명했습니다.
2. 명시적 지시 vs. 작업 프레이밍: 보안 관련 지시 (Verification) 는 효과가 없었으나, 작업의 프레임 (Translation vs. Generation) 을 변경하는 것만으로 식별자 오류를 해결할 수 있음을 보였습니다. 이는 LLM 의 태스크 수행 방식이 입력 지시보다 더 근본적인 영향을 미칠 수 있음을 시사합니다.
3. 이중 표현 현상 발견: 모델이 "잘못된 코드"와 "올바른 설명"을 동시에 생성하는 모순된 행동을 체계적으로 문서화했습니다.
4. 도메인 일관성 가설: 모델이 개별 단어의 의미보다는 전체 문자열 집합이 형성하는 '도메인 신호'에 반응하여 이름을 수정하거나 유지함을 발견했습니다.

---

5. 의의 및 시사점 (Significance)

• 보안 및 방어 관점:
  • 이 기법은 LLM 을 통한 자동화된 코드 분석을 방해하는 비용 증폭 (Cost Multiplication) 전략으로 작용합니다. 공격자는 코드의 구조를 숨길 수는 없으나, LLM 이 생성한 코드의 정확성을 떨어뜨려 추가적인 수동 검증 비용을 발생시킬 수 있습니다.
  • 브라우저에 배포된 코드는 결국 사람이 확인 가능하므로, 이 방어는 '완전한 보호'가 아니라 '분석 비용 증가'에 그칩니다.
• LLM 활용 워크플로우 개선:
  • 역분해된 코드를 바로 사용하는 대신, **"처음부터 다시 작성하라 (Reimplement from scratch)"**는 프레이밍을 적용하면 오염된 식별자를 제거하고 올바른 논리를 가진 코드를 얻을 수 있습니다. 이는 LLM 기반 코드 분석 파이프라인 설계에 중요한 실용적 제언입니다.
• 모델 이해의 한계:
  • LLM 이 '검증'을 요청받았을 때 왜 실패하는지, 그리고 '생성' 모드에서는 왜 성공하는지에 대한 내부 메커니즘은 아직 명확하지 않습니다. 이는 LLM 의 컨텍스트 내 도메인 인식 및 태스크 프레임 의존성에 대한 추가 연구가 필요함을 시사합니다.

결론

이 연구는 Claude Opus 4.6 에서 관찰된 현상을 통해, LLM 이 역분해 작업 시 원본 문자열의 식별자를 '출처 (Source)'로 간주하여 신뢰하는 경향이 있음을 보여주었습니다. 명시적인 검증 지시보다는 작업의 프레임 (Generation vs. Translation) 을 변경하는 것이 식별자 오류를 수정하는 데 훨씬 효과적임을 입증했습니다. 이는 LLM 기반 코드 분석의 신뢰성을 높이기 위해 단순한 프롬프트 엔지니어링을 넘어, 태스크의 본질을 재정의하는 접근이 필요함을 시사합니다.