Cheat Engine(CE)는 로컬 메모리 수정 도구입니다. 핵심은 매우 단순합니다. 실행 중인 프로세스의 로컬 메모리 데이터를 스캔해 위치를 찾고, 값을 강제로 바꾸는 것입니다. 게임 치트(“메모리 수정”)로 유명하지만, 앱/웹의 비즈니스 로직 취약점을 찾는 데도 활용할 수 있습니다.

CE는 공식 사이트에서 설치하면 됩니다. 이 글에서는 임의의 게임을 테스트 대상으로 삼아, CE의 핵심 기능(검색/수정)을 따라가며 최종적으로 취약점 탐지 사고방식으로 연결해 보겠습니다.

1. 환경 준비와 프로세스 Attach

CE를 쓰기 위한 전제는 프로세스에 붙는 것(Attach) 입니다. 메모리는 실행 중인 프로세스에 종속되기 때문입니다.

1.1 대상 프로세스 찾기

CE 좌상단의 돋보기 아이콘(프로세스 선택)을 눌러 실행 중 프로세스 목록에서 대상을 고릅니다.

1.2 에뮬레이터 프로세스의 특수성

모바일 게임/앱은 PC에서 안드로이드 에뮬레이터로 테스트하는 경우가 많습니다(예: 레이덴). 목록에서 보통 headless라는 이름이 포함된 프로세스를 찾으면 됩니다(앞에 접두어는 에뮬레이터마다 다를 수 있음). 선택 후 Open으로 Attach합니다.

2. 데이터 타입과 검색 모드

입문 핵심은 한 문장입니다. 원하는 값을 검색해 찾고, 수정한다.

우측 드롭다운에서 데이터 타입을 선택합니다.

  • 4 Bytes: 기본. 대부분의 수량/골드/상태 값은 정수라서 초반 90%는 이것으로 해결됩니다.
  • 8 Bytes: 매우 큰 수
  • Float/Double: 좌표, 비율 등
  • String: 텍스트 검색 등

2.2 검색 전략(정확/범위)

  • 정확한 값
  • 보다 큼/작음
  • 두 값 사이

등 다양한 필터가 있습니다.

3. 값이 알려진 경우: “1은 1이 아닐 수 있다”

예를 들어 10을 검색하면 수십만 개가 나올 수 있습니다. 그중 진짜 목표는 극소수입니다.

3.2 게임 메모리에서 ‘1’은 너무 흔하다

게임에서 어떤 상태가 1로 보이면 4바이트에서 1을 검색할 수 있습니다. 하지만 결과가 수백만 개 나오는 일이 흔합니다.

1은 “활성/ON” 같은 상태로 너무 많이 쓰이기 때문입니다.

3.3 큰 바다에서 걸러내기

해결법: 값을 변화시키고, 다시 스캔으로 필터링합니다.

  1. 게임에서 1을 2로 변화시키기
  2. CE에서 2로 “다시 스캔”(재검색이 아니라 필터)
  3. 2,000개 → 17개처럼 급감
  4. 그런데 6으로 만들었는데 리스트가 비어버리는 경우도 있습니다.

    이는 “화면의 1”이 메모리에서 1이 아닐 수 있음을 의미합니다.

4. 초기값을 모를 때: 변화 기반 필터링

HP 바, 모델 크기 같은 값은 숫자로 보이지 않습니다. 이때는 “초기값 알 수 없음”으로 시작합니다.

4.1 수억 개 주소

초기값을 모르면 CE는 엄청난 양의 메모리 주소를 가져옵니다. 답은 변화 규칙을 찾는 것입니다.

4.2 증가/감소 추적

값이 커졌다고 확신하면 “값이 증가함” 필터로 다시 스캔을 반복해 범위를 줄입니다.

4.3 “변화 없음”의 강력함

상태를 유지한 채 “변화 없음”으로 다시 스캔하면, 항상 변하는 잡음 데이터(시간, 프레임, 네트워크 하트비트 등)를 대량 제거할 수 있습니다.

5. 이분법과 메모리 잠금(Freeze)

필터링 후에도 2,000개가 남는 경우, 동일한 변화가 다양한 연쇄 반응을 일으키기 때문입니다. 이때 최후의 무기는 잠금(Freeze) 입니다.

  1. 남은 주소를 아래 “수정 대상 영역”으로 옮깁니다.
  2. 절반을 잠금(체크)합니다.
  3. 게임에서 값을 바꿔봅니다.
    • 변화가 없다면: 잠근 절반에 핵심 값이 있음
    • 변화한다면: 잠근 절반은 버리고 남은 절반에 핵심 값이 있음
  4. 절반씩 계속 좁혀 1~2개까지 줄입니다.

6. 메모리 수정에서 비즈니스 로직 취약점으로

“내 PC 화면에서만 값이 바뀌면 무슨 의미가 있나?”라는 질문이 나옵니다. 핵심은 클라이언트가 서버에 보내기 직전의 파라미터가 로컬 메모리에 평문으로 존재한다는 점입니다.

6.1 사례 1: 구매 수량 음수로 우회

상점 구매 요청에

  • 아이템 ID
  • 구매 수량

이 들어간다고 합시다. 구매 수량을 메모리에서 3 → -3으로 바꿔 전송하면, 서버가 음수 검증을 하지 않은 경우 “-3개 구매”가 되어 금액이 증가하는 등 심각한 문제가 생길 수 있습니다.

6.2 사례 2: 숨겨진 직업 ID로 권한 없는 생성

클라이언트 UI가 숨겨둔 직업이라도, 메모리의 직업 ID를 규칙에 맞게 바꿔 전송할 수 있습니다. 서버가 UI만 믿고 권한 검증을 하지 않으면, 숨겨진 직업을 생성하는 “월권”이 가능해집니다.

6.3 왜 프록시로 패킷 수정이 아니라 CE인가

게임/앱은 HTTP가 아니라 TCP/UDP를 쓰거나, 패킷이 강하게 암호화되어 프록시로 수정이 어렵습니다. 하지만 암호화되기 전에는 로컬 메모리에서 평문입니다. CE는 “암호화 전에” 값을 바꿔버리는 방식입니다.

6.4 사례 3: 암호화된 라이브 앱에서의 월권 방송

라이브 앱에서 “내 방 ID”를 메모리에서 다른 사람 ID로 바꿔 전송하면, 서버가 권한 검증(요청자 UID가 해당 방을 열 권한이 있는지)을 빼먹은 경우, 다른 사람 방에서 방송을 시작하는 취약점이 발생할 수 있습니다.

7. 결론

CE의 핵심은 두 가지입니다.

  1. 원하는 값을 찾는다
  2. 그 값을 바꾼다

도구는 단순하지만, 얼마나 깊게 찌를지는 실습과 숙련도에 달려 있습니다.