REA Reverse — 코딩 에이전트로 소프트웨어 동작 분석하기

AI 요약

REA는 코딩 에이전트에 프로그램 분석 도구를 연결해 실행 중인 코드나 네이티브 바이너리를 살펴보게 합니다. 설치 안내는 에이전트에 npx rea-agents@latest setup 실행을 요청하고, 설치 계획을 먼저 승인한 뒤 설치를 확인하도록 구성했습니다. 페이지는 리버스 엔지니어링의 목적을 프로그램 동작을 알아내 기능을 설명하거나 수정하고 다시 구현하는 일로 소개합니다.

공룡 게임에서 가속 규칙 찾기

첫 사례는 Chrome 공룡 게임입니다. 게임 속도가 빨라지는 이유를 알아내려면 시작 속도와 증가량, 증가가 멈추는 조건을 확인해야 합니다. REA가 브라우저에서 실제로 실행되는 index.js를 가져오면 에이전트는 업데이트 함수와 속도 설정을 살펴봅니다. 예시에서 속도는 6으로 시작하고, 충돌이 없을 때마다 업데이트 한 번에 0.001씩 증가하며, 13에 도달하면 더는 올라가지 않습니다.

작성자는 원본 게임의 업데이트 함수를 통제된 브라우저 환경에서 실행해 규칙을 확인했습니다. 장애물과 자동 실행 예약을 끈 뒤 업데이트를 4,000회 수행하면 속도는 10.0이었고, 10,000회 뒤에는 13.0이었습니다. 새 미니 게임은 이 속도 규칙을 따릅니다. 그림 그리기와 점프, 충돌 처리는 교육용으로 따로 구현했습니다. 원본 분석 결과와 새 구현의 동작을 나란히 확인하는 구성입니다.

계산기의 퍼센트 버튼 재구성

두 번째 사례는 Windows Calculator입니다. 200 + 10%가 220이 되는 이유를 설명하려면 %가 어떤 수를 기준으로 계산되는지 알아야 합니다. 분석 결과 덧셈에서는 현재 값에 이전 값을 곱한 뒤 100으로 나눕니다. 따라서 200과 10을 입력하면 10%를 200의 10%인 20으로 계산해 220을 만듭니다.

곱셈과 나눗셈에서는 규칙이 다릅니다. 현재 값만 100으로 나눠 10%를 0.1로 바꿉니다. 그러면 200 × 10%는 200 × 0.1, 즉 20이 됩니다. 페이지에는 실제 코드 분기와 함께 디스어셈블 결과도 나옵니다. 예시에서는 곱셈·나눗셈 버튼 식별자를 비교하고, 0x64가 100임을 확인해 퍼센트 계산 경로를 추적합니다.

지원 범위와 분석 방식

페이지는 브라우저 연결을 통한 웹 프로그램 분석과 네이티브 바이너리 분석을 안내합니다. 네이티브 분석에서는 실행 파일과 라이브러리의 함수, 문자열, 참조 관계, 호출 관계를 살펴봅니다. 사용자는 에이전트에 알고 싶은 동작을 지정하고, 분석 결과를 바탕으로 새 구현을 만들거나 원본과 비교하는 검사를 요청합니다.

Hacker News 반응

• @mb7733 — 코딩 에이전트에 설치를 맡기는 방식까지 왔군요. curl | bash 다음 단계의 설치를 달성했습니다!
  • @Neywiny — 공정하게 말하면, 바로 아래에 직접 실행할 명령도 적혀 있습니다. 그래도 그렇긴 하네요.
  • @t-writescode — 다음 > 다음 > 다음 > 완료와 curl | bash의 안전성에는 큰 차이가 있습니다. 외부에서 동적으로 받아 실행하는 코드는 실행할 때마다 달라질 수 있지만, 설치 파일은 한 번 내려받아 검토하고 나면 10년 뒤에도 같은 파일인지 확인할 수 있습니다.
• @ethin — 제가 놓친 게 아니라면, 에이전트에게 로컬 시스템에 Ghidra를 포함한 리버스 엔지니어링 환경을 설치하라고 지시하는 것보다 이 도구가 정확히 무엇을 더 해주나요?
  • @tptacek — 사람마다 기술과 스크립트, 도구가 다릅니다. Ghidra를 작업 흐름의 중심에 두더라도, 적어도 지금은 Claude가 즉흥적으로 처리하는 것보다 더 많은 구성이 필요합니다. 6개월 뒤에도 그럴지는 모르겠네요.
  • @ambicapter — 이미 만들어져서 일을 해주는 도구라서요. 직접 구성하는 데 토큰을 쓸 수도 있지만, 기존 도구를 쓰는 편이 더 싸고 시간을 아낄 수 있습니다.
• @cedws — 에이전트에게 radare2를 주는 것보다 나은 점이 뭔가요?
  • @charcircuit — 제 에이전트는 보통 Capstone을 직접 설치하더군요.
• @Meleagris — 이걸 실행할 때 거부 응답을 받지 않는 사람들이 놀랍습니다. Anthropic이나 OpenAI 모델에 리버스 엔지니어링을 살짝만 언급해도 거부 반응이 민감하게 나옵니다. 여기서 쓰는 기술은 취약점을 찾는 데도 쓰일 수 있으니까요. 사람들이 사이버 보안 제한이 적은 모델을 쓰는 건가요, 아니면 로컬 모델인가요?
  • @marcelo-earth — Claude Code Opus 5.5에서는 한 번 거부됐지만, 제 경험상 Codex 6.1-Sol에서는 잘 작동했습니다.
  • @Scaevolus — 현재 모델은 리버스 엔지니어링과 디컴파일 자체를 차단하지 않습니다. Ghidra MCP 서버에 연결해 프로그램 흐름을 추적하고, 함수 이름을 정리하거나 질문에 답하게 하면 보통처럼 작동합니다. 버그를 찾아 달라고 하면 거부될 가능성이 더 높습니다.
• @echelon — 우리가 만드는 앱은 리버스 엔지니어링을 명시적으로 쓰지 않습니다. 디컴파일도 하지 않고 100% 클린룸 방식으로 개발합니다. 이런 규모의 프로젝트에서 REA를 쓰면 소송으로 이어질 가능성이 있습니다. 원본 Adobe 코드를 보지 않으며 Ghidra 사용도 금지했습니다. 개인용 앱이나 abandonware에는 훌륭할 수 있지만, 결과물을 공개한 뒤 디스커버리 과정에서 원본 독점 코드 디컴파일이 드러나면 곤란해질 수 있습니다.
  • @jasomill — 클린룸 방식은 보통 저작권 코드를 정당하게 접한 팀이 기능 명세를 만든 뒤, 별도 팀이 그 명세를 바탕으로 구현하는 경우를 가리키지 않나요? 바이너리만 배포되는 상용 프로그램에서 디스어셈블리 코드를 보는 일이 계약 위반이나 저작권 침해 소송으로 이어질 수 있는데, 이때 클린룸 방식이 어떻게 적용되는지 잘 모르겠습니다.
• @InvisibleUp — Touhou 4 디컴파일을 훑어봤는데, 제가 본 AI 디컴파일 결과보다 품질이 훨씬 낫습니다. 코드가 일치하고 변수 이름도 그럴듯하며 주석도 간결합니다. 한 달 만에 나온 결과입니다. 다만 파일 구조가 원래 개발자의 의도보다 AI가 쓰기 편한 방식에 맞춰져 보입니다. 월 200달러짜리 AI 구독만으로 누구나 그럴듯한 디컴파일과 PC 포트를 쏟아내면, 취미 자체가 사라질 수도 있다는 점이 걱정됩니다.
  • @mjr00 — 취미의 목적이 오래된 게임을 현대 하드웨어에서 실행하고 모드를 지원하는 데 있었는지, 아니면 Ghidra를 쓰며 직접 역공학하는 과정에 있었는지에 따라 다릅니다. PC98 Touhou 게임을 다시 빌드할 수 있다는 건 좋습니다. 직접 역공학을 즐기는 사람에게는 부정행위처럼 느껴질 수 있다는 점은 이해합니다. 그래도 AI가 피아노를 대신 연주한다고 피아노 연주가 사라지지는 않습니다. 역공학 자체를 좋아하는 사람은 계속할 겁니다.

원문: REA / 번역·요약: Trawling