▲

GN⁺: LLM4Decompile - LLM을 활용한 바이너리 코드 디컴파일 기술

(github.com/albertan017)
2P by neo 4달전 | favorite | 댓글 1개
  • 대규모 언어 모델을 이용한 리버스 엔지니어링

1. LLM4Decompile 및 Decompile-Eval 소개

  • 우리의 목표는 최초의 디컴파일 전용 오픈 소스 LLM을 생성 및 출시하고, 재컴파일 가능성 및 재실행 가능성에 초점을 맞춘 최초의 디컴파일 벤치마크를 구축하여 그 기능을 평가하는 것
  • AnghaBench에서 수집한 백만 개의 C 코드 샘플을 GCC를 사용하여 어셈블리 코드로 컴파일하고, 이를 통해 40억 토큰의 어셈블리-소스 쌍 데이터셋을 구성함.
  • 이 데이터셋을 사용하여 선도적인 코드 LLM인 DeepSeek-Coder 모델을 미세조정하고, HumanEval 질문과 테스트 샘플을 기반으로 평가 벤치마크인 Decompile-Eval을 구축함.
  • 평가는 디컴파일된 코드가 성공적으로 재컴파일될 수 있는지, 테스트 케이스의 모든 단언을 통과할 수 있는지의 두 가지 관점에서 이루어짐.

2. 평가 결과

메트릭

  • 재컴파일 가능성과 재실행 가능성은 디컴파일 과정의 효과를 검증하는 중요한 지표임.
  • 디컴파일된 코드가 재컴파일될 수 있다면, 구문적 무결성의 강력한 증거를 제공함.
  • 구문만으로는 원래 프로그램과 의미적으로 동일하다는 것을 보장하지 않으므로, 재실행 가능성은 의미적 정확성을 평가하는 중요한 척도임.
  • 재컴파일 가능성과 재실행 가능성은 구문 복구와 의미 보존을 나타내며, 이는 사용 가능하고 견고한 디컴파일에 필수적임.

3. 모델 사용 방법

  • LLM4Decompile은 13억에서 330억 개의 파라미터를 가진 모델을 포함하며, 이 모델들은 Hugging Face에서 사용할 수 있음.
  • 모델 예시: llm4decompile-1.3b, llm4decompile-6.7b, llm4decompile-33b, llm4decompile-6.7b-nsp, llm4decompile-6.7b-uo
  • NSP 모델은 어셈블리 코드로 훈련되었으며, 평균 재실행 가능성은 약 0.17임.
  • UO 모델은 최적화 수준(O0~O3)에 대한 사전 지식 없이 훈련되었으며, 평균 재실행 가능성은 약 0.21임.
  • 모델 사용 예시: C 코드를 바이너리로 컴파일하고, 바이너리를 어셈블리 지시사항으로 디스어셈블하며, LLM4Decompile을 사용하여 어셈블리 지시사항을 C로 번역함.

4. Decompile-Eval 사용 방법

  • 데이터는 llm4decompile/decompile-eval/decompile-eval.json에 JSON 리스트 형식으로 저장되어 있음.
  • 단일 GPU와 단일 프로세스에서 평가를 실행하는 방법과 TGI(10배 빠른 속도, 다중 GPU 및 멀티 프로세스 지원)를 사용하는 방법이 제공됨.

5. 진행 중

  • LLM4Binary: 어셈블리 코드와 C 코드로 모델을 사전 훈련하기 위해 더 큰 데이터셋을 포함할 계획임.
  • Decompiler-ALL: 더 많은 언어/플랫폼 및 설정을 지원하기 위한 계획임(예: 여러 함수 디컴파일).

6. 라이선스

  • MIT 라이선스

GN⁺의 의견

  • LLM4Decompile은 기존의 바이너리 디컴파일 방식에 비해 혁신적인 접근 방식을 제시하며, 특히 대규모 언어 모델을 활용하여 더 정확하고 효율적인 디컴파일을 가능하게 함.
  • 이 기술은 소프트웨어 보안 분야에서 매우 유용할 수 있으며, 악성 코드 분석이나 레거시 시스템의 유지보수에 도움을 줄 수 있음.
  • 디컴파일된 코드의 재실행 가능성이 완벽하지 않다는 점은 이 기술이 아직 개선의 여지가 있음을 시사함. 실제 환경에서의 정확도와 효율성을 높이기 위한 추가 연구가 필요함.
  • 유사한 기능을 제공하는 기존의 도구로는 Ghidra나 IDA Pro와 같은 상용 및 오픈소스 디컴파일러가 있으나, LLM4Decompile은 머신러닝을 기반으로 한 새로운 접근 방식을 제공함.
  • 이 기술을 도입할 때는 훈련 데이터의 질과 범위, 모델의 정확도, 실행 속도 등을 고려해야 하며, 선택함으로써 얻을 수 있는 이점은 높은 정확도와 유연성이지만, 대규모 모델의 복잡성과 컴퓨팅 자원의 요구량이 단점으로 작용할 수 있음.
▲
neo 4달전  [-]
Hacker News 의견

  • "재실행 가능성" 결과에 대한 의견:

    • 재실행 가능성은 의미론적 정확성을 측정하는 중요한 방법임. 디컴파일된 결과물을 다시 컴파일하고 테스트 케이스를 실행하여 프로그램 로직과 동작이 보존되었는지 평가함. 재컴파일 가능성과 재실행 가능성은 문법 복구와 의미 보존을 나타내며, 이는 사용 가능하고 견고한 디컴파일에 필수적임.

  • 디컴파일된 결과의 신뢰성에 대한 질문:

    • 디컴파일된 결과가 신뢰할 수 있는지에 대한 진지한 질문임. 재컴파일로 인해 다른 기계 코드가 생성될 수 있으며, 특히 코드의 핵심 부분일 수 있는 새로운 구조물을 식별하기 어려울 수 있음. 생성적으로 실행할 때 LLM이 특정 섹션에 대한 신뢰도를 보고하는 방법이 있는지 궁금함. 인간의 확인이 필요할 것으로 보임.

  • LLM 미세조정에 대한 우수한 사용 사례:

    • 공개된 C 코드에서 입력/출력 쌍의 대규모 데이터셋을 쉽게 생성할 수 있기 때문에 LLM 미세조정에 대한 훌륭한 사용 사례임.

  • 개발자 기반 디컴파일 모듈 훈련에 대한 관심:

    • 특정 개발자가 작업한 애플리케이션을 기반으로 디컴파일 모듈을 훈련할 수 있는지 여부가 흥미로움. 예를 들어, Super Mario 64와 Zelda 64는 완전히 디컴파일되었으며, 다른 N64 게임들도 진행 중임. 이러한 개발자가 작업한 다른 게임을 더 쉽게 디컴파일할 수 있는지 궁금함.

  • 디컴파일러의 이상적인 사용 사례와 데이터셋 생성에 대한 관심:

    • 이상적인 디컴파일러는 독점 소스 코드를 제거할 것임. 공개적으로 사용 가능한 C 코드의 풍부함으로 인해 ASM과 소스 코드의 쌍으로 이루어진 데이터셋을 쉽게 만들 수 있음.

  • 개인이 진행 중인 LLM 기반 디컴파일러 프로젝트에 대한 소개:

    • Python 바이트코드를 위한 LLM 기반 디컴파일러를 개발 중임. 이 연구 방향에 대해 일하는 사람들이 많지 않지만, 긴 주의 컨텍스트가 가능해지면서 흥미로울 수 있다고 생각함. 협력할 팀을 알고 있다면 협력에 관심이 있음.

  • AI 기반 접근법과 비교 없는 벤치마크에 대한 우려:

    • 다양한 접근법을 보는 것은 멋지지만, IDA Pro와 같은 비 AI 기반 접근법과의 비교 없이는 벤치마크가 의미 없을 수 있음. 이 모델이 보안 논문의 메트릭에서 어떻게 성능을 보이는지 보는 것이 흥미로울 것임.

  • 재컴파일 가능성과 재실행 가능성 점수의 큰 차이에 대한 관심:

    • GTP4는 재컴파일 가능성(문법적으로 정확함)에서 8x%를 달성했지만, 재실행 가능성(개념적으로 정확함)에서는 형편없는 1x%를 기록함으로써, 그것의 과도한 모방 능력을 다시 한번 보여줌.

  • LLM이 아닌 다른 디컴파일러와의 비교에 대한 궁금증:

    • IDA, Binja 등과 같은 비 LLM 디컴파일러와의 비교는 어떻게 되는지 궁금함. 다른 LLM과의 비교만 보임.

  • 6b 모델이 33b 모델보다 우수한 성능을 보인 것에 대한 호기심:

    • 6b 모델이 33b 모델보다 더 나은 성능을 보이는 것이 흥미로움. 33b 모델이 더 많은 훈련 데이터가 필요한 것인지 궁금함. 33b 모델은 약 100만 개의 C 프로그램으로 사전 훈련되었지만, DeepSeek-Coder는 2조 개의 토큰으로 훈련되었으며, 이는 몇 단계 더 많은 데이터임.
답변달기