리버싱 과제 보고서에서 AI 티를 걷어내고 증거 중심으로 다시 쓰기

메신저 분석 리버싱 과제를 하면서 가장 오래 걸린 건 분석 결과를 보고서로 옮기는 일이었다. AI로 만든 초안은 문장은 매끄러웠지만, 실제로 확인한 것과 추측을 구분하지 못했고 학생 보고서라기보다 홍보 문구처럼 보였다. 결국 문장을 꾸미는 대신 증거 없는 주장을 지우고 다시 썼다. 과제용으로 허가된 대상만 분석했으며 실제 메시지·키·계정·프로토콜 값은 이 글에 싣지 않는다.

리버싱 과제 보고서를 AI 문장 대신 증거 중심으로 다시 쓴 과정 대표 이미지

도구를 열기 전에 프로그램 구조부터 봤다

대상은 Windows 데스크톱 클라이언트였다. 먼저 MFC 애플리케이션의 메시지 처리 구조, PE 파일의 섹션과 import, 네트워크 통신 흐름을 정리했다. 배경을 모른 채 문자열과 패킷만 보면 눈에 띄는 값을 의미 있는 증거로 착각하기 쉽다.

Microsoft Learn MFC 데스크톱 애플리케이션 문서

보고서 첫 장에는 분석 도구 목록보다 “무엇을 확인하려는가”를 적었다. 정적 분석에서는 함수와 문자열·import 관계를 보고, 동적 분석에서는 실제 실행 경로와 통신 시점을 확인한다. 한 도구의 결과를 다른 도구가 보완하도록 역할을 정했다.

ARM Windows와 x86 분석 환경을 억지로 섞지 않았다

메인 컴퓨터는 ARM 맥이고 Parallels의 Windows도 ARM64다. x86 프로그램 자체는 에뮬레이션으로 실행되지만 동적 후킹 도구가 프로세스 구조를 기대한 방식으로 읽지 못하는 경우가 있었다. 정적 분석과 문서 작업은 맥에서, x86 동적 분석은 별도 x86 Windows PC에서 진행했다.

Hex-Rays IDA 공식 문서

이 환경 차이를 실패처럼 숨기지 않고 보고서의 분석 조건에 적었다. 어떤 캡처가 어느 컴퓨터와 아키텍처에서 나온 것인지 표시하니, 같은 절차가 다른 환경에서 재현되지 않을 때 원인을 설명할 수 있었다.

패킷 캡처는 보이는 값을 전부 공개하는 일이 아니다

Wireshark 공식 User’s Guide

통신 흐름을 설명하기 위해 Wireshark 캡처를 사용했지만 원본 화면을 그대로 붙이지 않았다. 계정 식별자, 실제 메시지, 토큰·키처럼 과제 설명에 불필요한 값은 가리고, 패킷 방향·길이·시점처럼 주장에 필요한 부분만 남겼다. 캡션에는 “이 화면이 무엇을 증명하는가”를 한 문장으로 적었다.

PE 구조는 추측을 줄이는 기준이 됐다

문자열 주소가 어느 섹션에 있는지, import가 실제로 존재하는지, 디스어셈블 결과가 파일 오프셋과 가상주소 중 무엇을 쓰는지 공식 PE 문서와 대조했다. “아마 암호화 함수일 것이다”처럼 이름만 보고 쓴 문장은 호출 관계나 실행 캡처가 없으면 삭제했다.

AI 티를 걷어낸 실제 기준

초안에는 “플랫폼 독립성과 범용성을 증명한다”, “최종 평가의 핵심 메시지 복원 증명” 같은 문장이 있었다. 거창하지만 무엇을 했는지 알 수 없는 표현이었다. 아래 규칙으로 통째로 다시 썼다.

• “분석했다” 뒤에는 파일·함수·패킷·캡처 중 하나의 근거를 붙인다.
• 정적 분석에서 추정한 것과 실행으로 확인한 것을 구분한다.
• 실패한 시도와 환경 제약도 삭제하지 않는다.
• 캡처 번호와 본문 주장이 서로 연결되지 않으면 둘 중 하나를 뺀다.
• “완벽히”, “범용적”, “증명했다” 같은 표현은 범위가 맞는지 다시 본다.

주장-증거 표를 먼저 만들었다

주장	필요한 증거	상태
특정 함수가 해당 흐름에서 호출됨	정적 호출 관계 + 동적 breakpoint	둘 다 있으면 확인
특정 시점에 통신 발생	프로세스 동작 + 패킷 시간	상관관계로 표현
보호 기능을 우회함	전후 실행 결과	없으면 주장 삭제

표를 만들고 나니 분량이 줄어도 보고서는 더 단단해졌다. 사람이 쓴 것처럼 보이게 만드는 가장 확실한 방법은 말투를 일부러 흐트러뜨리는 게 아니라, 실제로 확인한 과정과 한계를 구체적으로 쓰는 것이었다.

공식 자료

• Microsoft MFC Desktop Applications
• Hex-Rays IDA Docs
• Wireshark User’s Guide
• Microsoft PE Format

최종 보고서 목차도 분석 순서대로 바꿨다

1. 범위와 윤리: 허가된 대상·제외한 데이터·재현 환경
2. 분석 질문: 무엇을 확인하려 했는지
3. 정적 분석: 파일 정보, import, 함수 관계, 추정
4. 동적 분석: breakpoint, 실행 경로, 패킷 시점
5. 증거 연결: 캡처 번호와 주장 대응
6. 한계: 아키텍처·도구·재현 범위

도구별로 장을 나누면 IDA에서 본 것과 Wireshark에서 본 것이 따로 놀았다. 질문별로 정적·동적 증거를 묶으니 “그래서 이 캡처가 무슨 뜻인가”가 더 잘 보였다.

캡처 검수 체크리스트

• 창 제목과 시간대가 분석 환경 설명과 맞는가
• 주소·함수명·패킷 번호가 본문 인용과 일치하는가
• 계정, 메시지, 키, 토큰이 가려졌는가
• 강조 박스가 원본 값을 가리거나 왜곡하지 않는가
• 캡션만 읽어도 캡처의 증명 범위를 알 수 있는가

AI 초안은 문장 연결에는 도움이 됐지만 실제 캡처 번호와 환경을 대신 확인해주지는 않았다. 마지막 검수는 PDF로 렌더링한 뒤 모든 페이지를 눈으로 넘기며 했다.

같이 읽기

ARM 맥과 x86 Windows 사이에서 실제 동적 분석이 막힌 이유는 ARM 맥에서 x86 Windows 리버싱 환경 꾸리기에 더 자세히 적었다.