REAP: 리버스 엔지니어링 에이전트(REA)에서 바로 사용 가능한 55개의 리버스 엔지니어링 프롬프트 저장소 (≠ REA 공식)

읽을거리&정보공유
, , , , ,
1

핵심 요약

  • REAP(REA Investigation Prompts)는 리버스 엔지니어링 도구 REA를 연결한 코딩 에이전트에 붙여 넣어 쓰도록 만든 프롬프트 55개를 README 파일 하나에 17개 분야로 정리한 저장소입니다. REA 개발팀이 아니라 보안 연구자 Joas A Santos가 만들었습니다.
  • 대부분의 프롬프트는 기능 하나로 범위를 좁히고 결론마다 파일, 함수, 주소 같은 근거를 요구합니다. 확인된 사실과 추론(inference), 확인하지 못한 부분의 구분은 13개 정도, 정적 분석 우선은 7개 프롬프트에만 명시되어 있습니다.
  • 55개 중 6개는 madewithrea.com 프롬프트 갤러리와 문구가 같습니다. README는 이 갤러리를 공식 갤러리로 소개하지만, madewithrea.com은 스스로 REA 프로젝트와 관계없는 커뮤니티 디렉터리라고 밝히고 있습니다.
  • REA 자체에도 가이드 프롬프트 6개와, 결론마다 관찰, 추론, unknown을 구분하게 하는 에이전트 스킬이 들어 있습니다. REAP는 여기에 더해 펌웨어, 커널 드라이버, 게임의 WASM(WebAssembly) 이식, 안티치트와 크래킹 연구까지 대상별 프롬프트를 둡니다.
  • 안티치트, DMA(Direct Memory Access) 치트, 소프트웨어 크래킹을 다루는 12~14절은 REA 프로젝트가 지원하지 않는다고 밝힌 용도와 일부 겹치므로, 자신이 소유하거나 분석을 허가받은 대상에만 써야 합니다.

REAP: REA 에이전트에 붙여 넣는 리버스 엔지니어링 조사 프롬프트 55개
REAP: REA 에이전트에 붙여 넣는 리버스 엔지니어링 조사 프롬프트 55개1536×1024 230 KB

REAP 소개

코딩 에이전트에 리버스 엔지니어링(reverse engineering) 도구를 연결해도, 에이전트가 돌려주는 답의 질은 질문을 어떻게 쓰는지에 따라 달라집니다. REA(Reverse Engineer Anything) (:pytorch::kr: REA: Ghidra와 IDA 같은 분석 도구를 하나의 MCP로 묶어 코딩 에이전트에 연결하는 리버스 엔지니어링 도구)는 Ghidra, IDA, Hopper 같은 분석 도구를 하나의 MCP 서버로 묶어 에이전트에 연결하는 프로젝트입니다. REA는 설정 과정에서 에이전트에 조사 워크플로 스킬도 함께 설치해, 결론마다 관찰, 추론, unknown을 구분하고 근거 ID를 인용하게 합니다. 다만 무엇을 조사할지와 어떤 결과물을 받을지는 사용자가 질문으로 정해야 합니다. REAP 저자는 앱 전체를 설명해 달라는 넓은 질문은 얕은 지도만 돌려주고, 기능 하나를 좁혀 물어야 호출 경로와 주소까지 나온다고 설명합니다. 이번에 소개하는 REAP(REA Investigation Prompts)는 이런 질문을 분석 대상별로 미리 써 둔 프롬프트 모음입니다.

REAP의 프롬프트는 복사해서 <angle brackets>로 표시된 자리만 바꿔 쓰는 템플릿 형태입니다. 예를 들어 기능 하나를 설명하게 하는 프롬프트는 <FEATURE>와 <PATH TO APPLICATION> 자리에 기능 이름과 앱 경로를 넣으면 됩니다. 대부분의 프롬프트는 결론마다 근거를 요구하고, 일부는 사실과 추론의 구분이나 정적 분석(static analysis) 우선도 함께 요구합니다. 절반가량은 CLONE_SPEC.md, 파일 형식 리더, 이식 계획 같은 구체적인 산출물을 요청하는 문장으로 끝납니다. 같은 요구를 매번 다시 쓰지 않아도 된다는 점이 REAP를 쓰는 실질적인 이유입니다.

REAP 저장소에는 코드가 없고 README.md 파일 하나만 있습니다. 설치 확인부터 장기 조사까지 0~16절의 17개 분야에 54개, 마지막의 범용 프롬프트(Wildcard prompt) 1개를 더해 모두 55개입니다. 저자인 Joas A Santos는 GitHub 프로필에 레드팀 리드와 정보보안 연구자 경력을 적고 있습니다. 저장소는 2026년 10월 19일에 만들어졌고 2026년 10월 21일(UTC) 기준으로 커밋이 5개뿐이며, 각 프롬프트를 실제로 실행한 결과나 예시 출력은 저장소에 없습니다.

REAP vs. REA 내장 프롬프트와 madewithrea 갤러리

REA용 프롬프트는 REAP 말고도 두 곳에서 구할 수 있습니다. 하나는 REA가 MCP의 프롬프트(prompts) 기능으로 직접 제공하는 가이드 프롬프트 6개이고, 다른 하나는 madewithrea.com의 프롬프트 갤러리입니다. 세 자료의 차이는 다음과 같습니다:

항목 REAP REA 내장 가이드 프롬프트 madewithrea.com 갤러리
제작 주체 보안 연구자 Joas A Santos REA 프로젝트 REA 프로젝트와 관계없는 커뮤니티 디렉터리 운영자
형태 README에 실린 복사용 텍스트 MCP 클라이언트의 프롬프트 목록 빈칸을 채워 복사하는 웹 페이지
개수 55개 (17개 분야) 6개 15개
다루는 범위 기능 추적, 복제, 게임, WASM 이식, 펌웨어, Android, 커널, 취약점, 안티치트, DMA, 크래킹 연구 기능 조사, 버전 비교, 재구현 검증, 크래시 추적, 미확인 항목 감사, 프로세스 캡처 설계 기능 추적과 재구현, 버전 비교, Android와 macOS 앱, 파일 형식과 프로토콜, 데이터 처리 검토
세션 연동 없음 (자리 표시를 직접 치환) 현재 세션의 문서, 함수 주소, Evidence ID를 자동 완성으로 제안 없음

REA의 내장 프롬프트는 렌더링될 때마다 현재 버전의 REA 도구 이름으로 시작점을 안내하고, 관찰한 사실과 추론, unknown을 구분하라고 요구합니다. 설정 때 함께 설치되는 REA 스킬도 펌웨어, APK, WASM 같은 대상 종류별로 쓸 도구를 안내합니다. REAP는 이 중 verify_reconstruction, compare_application_versions, audit_residual_unknowns 세 이름을 프롬프트 안에 직접 적고 "if available"라는 단서를 붙였습니다. REA 프로젝트는 빠르게 바뀌고 새 릴리스가 잦다고 스스로 안내하므로, 고정된 텍스트에 적힌 이름은 버전이 바뀌면 맞지 않을 수 있습니다.

REAP의 55개 중 6개는 madewithrea.com 갤러리의 프롬프트와 문구가 같습니다. 낯선 앱의 첫 지도, 버튼에서 결과까지의 추적, 규칙 복원과 재구현, 파일 형식 분석, 웹 기능 관찰, 데이터 처리 검토가 여기에 해당합니다. 1절의 첫 연습 과제도 REA 홈페이지의 첫 조사 안내에 나오는 Notes 예제 질문과 거의 같습니다. REAP README는 madewithrea.com을 "Official prompt gallery" 로 소개합니다. 하지만 madewithrea.com은 페이지 하단에서 자신을 "Community directory, not affiliated with the REA project" 라고 밝히고 있습니다. 따라서 REAP와 madewithrea.com 갤러리 모두 REA 개발팀이 검토한 자료가 아닙니다.

에이전트에게 조사 방법을 알려 주는 다른 방식으로는 MCP 도구 대신 스킬 파일 하나로 명령줄 도구를 쓰게 하는 LeanREA (:pytorch::kr: LeanREA: REA의 MCP 도구 207개 대신 8KB 스킬 파일 하나로 리버스 엔지니어링을 안내하는 에이전트 스킬 (≠ REA 공식 경량판))도 있습니다. REAP는 REA를 그대로 쓰면서 질문만 바꾸는 쪽이라, REA 설치가 전제입니다.

REAP를 사용하면 좋을 사용자

REAP는 REA를 이미 설치했지만 질문을 어떻게 써야 할지 정하지 못한 사용자에게 출발점이 됩니다. REA 내장 프롬프트는 대상 종류를 가리지 않는 범용 절차이고, madewithrea.com 갤러리에는 펌웨어 이미지, 커널 드라이버, 게임의 WASM 이식을 위한 프롬프트가 없습니다. 그래서 이런 대상에 맞춰 사용자가 붙여 넣을 템플릿은 셋 중 REAP에만 있습니다. 근거를 요구하고 사실과 추론을 나누게 하는 형식 자체는 다른 분석 MCP 서버용 질문을 쓸 때도 참고할 수 있습니다.

반면 검증된 조사 절차가 필요한 팀에게는 REAP보다 REA 내장 가이드 프롬프트가 더 적절한 출발점입니다. REAP는 만들어진 지 며칠 되지 않았고 프롬프트를 실행한 결과도 공개하지 않았습니다. 도구 이름도 텍스트에 고정되어 있습니다. 또한 자신이 소유하지 않은 소프트웨어의 안티치트나 라이선스 검사를 분석하려는 용도라면 REAP의 12~14절은 적절한 선택지가 아닙니다. REA 프로젝트는 면책 고지(DISCLAIMER.md)에서 DRM(Digital Rights Management), 라이선스 검사, 안티치트 우회와 게임 치트 개발을 지원하지 않는다고 밝히고 있습니다. 이런 요청은 이슈와 토론에서 답 없이 닫는다고도 적었습니다.

REAP 프롬프트의 작성 원칙

REAP는 README 끝에 프롬프트를 이렇게 쓴 이유를 6가지로 정리해 두었습니다. 이 원칙은 madewithrea.com의 조사 프롬프트 작성 안내에 있는 다섯 가지 습관과 대부분 겹칩니다. 여기에 정적 분석 우선과 범위 명시가 더해져 있습니다:

  1. 프롬프트 하나에 기능 하나: 앱 전체를 묻는 넓은 질문 대신 기능 하나를 물어야 호출 경로와 주소가 담긴 답이 나온다는 원칙입니다.
  2. 근거 요구: 결론마다 파일, 함수, 주소를 인용하게 합니다. 저자는 이렇게 하면 에이전트가 그럴듯한 설명을 지어내는 것을 막을 수 있다고 설명합니다.
  3. 사실, 추론, 미확인의 구분: 답을 세 갈래로 나누게 해서 가설이 사실처럼 섞이지 않게 합니다. 저자는 README에 모든 프롬프트가 이 구분을 요구한다고 적었지만, 실제로 명시한 프롬프트는 55개 중 13개 정도입니다(REA 스킬은 에이전트에게 같은 구분을 항상 지시합니다).
  4. 정적 분석 우선: 실행 시점 관찰이 필요해질 때까지 "do not execute the application"이라고 적어 대상을 실행하지 않게 합니다. 이 요구를 명시한 프롬프트는 7개입니다.
  5. 산출물로 끝내기: 명세서, 리더 스크립트, 이식 계획, 최소 재구현처럼 구체적인 결과물을 요구합니다. 저자는 결과물이 있어야 에이전트가 자기 주장을 스스로 확인하게 된다고 설명합니다.
  6. 범위 명시: "내가 소유한 실험 장비", "오프라인 싱글플레이어", "문서화만 하고 우회하지 않음"처럼 조사 범위를 프롬프트에 적어 둡니다.

아래는 2절의 기능 설명 프롬프트로, 위 원칙이 한 프롬프트 안에 어떻게 들어가는지 보여 줍니다:

Use REA to investigate how <FEATURE> works in <PATH TO APPLICATION>.

Identify the entry point, the functions involved, the data flow, the
dependencies and the observable effects.

For every conclusion, present evidence: file, function, address or relevant
snippet. Separate confirmed facts, inferences and points that remain unknown.

Do not execute the application in this step.

근거를 요구하는 것은 프롬프트 수준의 장치이므로, 에이전트가 제시한 근거가 실제 바이트와 맞는지는 따로 확인해야 합니다. 에이전트의 주장을 결정론적 도구로 판정하는 Reverify 같은 프로젝트가 이 단계를 다룹니다.

REAP의 분야별 구성

REAP의 17개 분야와 각 분야의 프롬프트가 요청하는 대표 산출물은 다음과 같습니다(README 순서):

절 분야 프롬프트 수 대표 산출물
0 설치와 확인 1 설치 계획과 사용 가능한 도구 목록
1 시작하기 2 Notes 예제의 CSV 내보내기 경로, 낯선 앱의 지도
2 기능 추적 3 진입점에서 결과까지의 경로, 실행 가능한 최소 재구현
3 네이티브 바이너리 5 트리아지 맵(triage map), 파일 형식 리더, 프로토콜의 Python struct/proto 정의
4 소프트웨어와 기능 복제 4 CLONE_SPEC.md, 원본과 남은 차이 목록
5 게임 4 게임 규칙의 C 재구현, 엔진과 에셋 적재 흐름
6 게임의 WASM 이식 3 구성 요소별 이식 가능성 분류, 이식 계획
7 펌웨어와 임베디드 3 파티션과 메모리 맵, OTA(Over-the-Air) 업데이트 경로
8 Android 4 권한과 외부 노출 컴포넌트, JNI(Java Native Interface) 경계를 넘는 호출 추적
9 커널 3 IOCTL(I/O Control) 핸들러별 입력 검증과 위험 순위
10 취약점 연구 5 신뢰 경계 감사, 패치 비교(patch diffing), 크래시 원인 가설
11 Electron과 JavaScript 5 IPC(Inter-Process Communication) 채널 검토, 웹사이트 기능 재구현
12 안티치트와 보호 기법 연구 3 안티치트의 탐지 범위 지도, 내 소프트웨어의 보호 기법 평가
13 DMA와 하드웨어 기반 치트 연구(방어) 4 탐지 공백 분석, 하드닝 제안
14 소프트웨어 크래킹 연구 3 검증 알고리즘 문서화, crackme 풀이
15 버전 비교 1 기능, API, 권한 변경과 보안 수정 후보
16 장기 조사 1 INVESTIGATION.md 갱신

4절의 복제 프롬프트는 클린룸(clean-room) 방식을 전제로 합니다. REAP는 코드가 아니라 동작을 추출하고, 원본의 소스 코드, 에셋, 브랜딩, 라이선스 메커니즘은 복사하지 않는다는 원칙을 절 머리에 적어 두었습니다. 게임 절의 모드 프롬프트도 오프라인 싱글플레이어 게임으로 범위를 한정합니다.

12~14절은 README 첫머리의 경고와 각 절 머리의 안내로 범위를 제한합니다. REAP는 12절을 자신의 장비와 소프트웨어, 벤더의 버그 바운티, CTF(Capture The Flag) 대회, 학술 연구에만 쓰고 다른 플레이어의 실제 게임 세션은 대상으로 삼지 말라고 적었습니다. 13절은 자신이 소유한 장비나 오프라인 대상, 벤더의 허가를 받은 경우로, 14절은 보호 기법 연구, crackme와 CTF, 자기 소프트웨어의 하드닝으로 범위를 정했습니다. 그러나 이 안내는 프롬프트의 문구일 뿐이고, 앞에서 본 것처럼 REA 프로젝트는 안티치트와 라이선스 검사 우회를 지원 범위 밖으로 둡니다. 리버스 엔지니어링이 허용되는 범위는 국가와 소프트웨어 라이선스에 따라 다르므로, 이 절들을 쓰기 전에 대상에 대한 권리부터 확인해야 합니다.

REAP 설치와 사용

REAP는 설치할 것이 없고, REA만 준비되어 있으면 됩니다. REA는 다음 명령으로 설정합니다:

npx rea-agents@latest setup

REAP 0절의 프롬프트는 이 설치를 에이전트에게 맡기는 형태입니다. 설치 계획과 설정 변경 사항을 먼저 보여 주고 승인을 받은 뒤, 설치가 끝나면 연결을 확인하고 사용 가능한 도구와 워크플로 목록을 보여 달라고 요청합니다.

처음 쓸 때는 REAP가 시작점으로 권하는 범용 프롬프트에서 <FEATURE>와 <PATH TO APPLICATION>만 바꿔 붙여 넣으면 됩니다:

Use REA to understand how <FEATURE> works in <PATH TO APPLICATION>.

Check first which tools are actually available. Start with static analysis
and trace the feature down to the responsible functions.

Present evidence for each conclusion, separate facts from hypotheses, and
record the limitations. At the end, generate a behavioral specification and
propose tests to verify it.

이후에는 대상 종류에 맞는 절에서 프롬프트를 골라 같은 방식으로 자리 표시를 채웁니다. 중단한 조사를 이어 갈 때는 16절의 프롬프트가 지금까지의 근거와 메모를 검토해 아직 입증되지 않은 부분을 정리하고 INVESTIGATION.md에 다음 단계를 기록하게 합니다.

:books: REA 가이드 프롬프트 문서 (REA 프로젝트의 MCP 프롬프트 설명)

:github: REAP 프로젝트 GitHub 저장소

더 읽어보기



이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. :hugs:

:pytorch:파이토치 한국 사용자 모임:south_korea:에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일:love_letter:로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요! :smiley:

:wrapped_gift: 아래:down_right_arrow:쪽에 좋아요:+1:를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ :star_struck: