반응형

치트 엔진으로 게임에서 수정하고 싶은 값의 주소를 찾아도 게임을 다시 실행시키면 그 주소가 변경되어 처음부터 다시 진행해야만 하는 경우가 있다.(포인터 등으로 해결 불가) 예를 들어 도스박스로 고전 게임을 실행시키는 경우 값의 주소가 변경될 뿐만 아니라 그 값을 기록하는 명령이 다른 여러 주소에 접근하기 때문에 쉽게 에디터를 만들 수가 없다.

 

※ 참고:

2023.01.01 - [Reverse Engineering] - Cheat Engine AOB Injection with DosBox - 치트 엔진 코드 인젝션 도스박스

 

Rick Dangerous 2 게임을 실행하고 번개를 사용해 수치를 변화 시킨다.

 

번개 수치가 저장된 주소를 파악한다.

 

어떤 명령이 번개 수치를 변화 시키는지 확인한다.

 

번개 수치를 변경하는 명령이 접근하는 다른 주소들을 확인한다. 도스박스에서는 굉장히 많은 주소에 접근한다. 그래서 그 명령을 함부로 수정할 수 없다.

 

 

번개 수치 변경 명령을 메모리 뷰어에서 확인하고 AOB Injection을 준비한다.

 

어셈블리 코드를 작성하고 주소 리스트 창에 저장한다.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
[ENABLE]
 
aobscanmodule(INJECT,DOSBox.exe,66 89 34 18 8B 5C 24 14) // should be unique
alloc(newmem,$1000)
globalalloc(editor, 4) // Thunder 주소 저장을 위한 4 바이트 메모리 할당
 
label(code)
label(return)
 
newmem:
  cmp [eax+ebx+61], 'JOHN' // [Thunder 주소+61]에 'JOHN' 문자열이 있다
  jne code          // Thunder 값이 저장된 장소가 아니면 원래 코드 실행
  push edx          // eax+ebx 값을 저장하기 위해 edx 사용
  xor edx, edx      // edx 초기화
  mov edx, eax
  add edx, ebx
  mov [editor], edx // editor 심볼에 Thunder 주소 저장
  mov [eax+ebx], si // 원래 코드 실행
  mov ebx, [esp+14]
  pop edx           // 원래 edx 값 복구
  jmp return
 
code: // 원래 코드
  mov [eax+ebx],si
  mov ebx,[esp+14]
  jmp return
 
INJECT:
  jmp newmem
  nop 3
return:
registersymbol(INJECT)
 
[DISABLE]
 
INJECT:
  db 66 89 34 18 8B 5C 24 14
 
unregistersymbol(INJECT)
dealloc(newmem)
dealloc(editor)         // 6바이트 메모리 해제
 

 

 

번개 수치 주소를 생성한다.

주소 리스트 창에서 위와 같이 번개 수치가 저장된 주소를 스크립트의 [심볼(editor)+offset] 방식으로 생성한다. 아래 폭탄과 생명도 동일한 방법으로 진행한다.

 

 

폭탄 수치 주소를 생성한다.

 

생명 수치 주소를 생성한다.

 

위에서 작업한 내용이 주소 리스트 창에 저장되었다. 스크립트를 실행하고 번개를 한 번 사용하면 각각의 수치들이 정확히 반영된다.

 

도스박스와 게임을 다시 실행하면 모든 주소가 변경되어 엉뚱한 값이 대입 된다.

 

 

다시 스크립트를 실행하고 번개를 한 번 사용하면 모든 값들이 제대로 반영된다.

 

치트 테이블을 저장하면 언제든 다시 스크립트와 모든 수치를 간단히 수정할 수 있다.

 

반응형
Posted by J-sean
:
반응형

치트 엔진으로 삽입한(inject) 코드를 enable/disable 하기 위해 Cheat Table Framework code 사용할 수 있다. 하지만 자세히 보지 않으면 원치 않는 결과를 얻게 되므로 조심해야 한다.

 

치트 엔진 튜토리얼을 실행하고 Step 7: Code Injection 까지 진행한다.

 

Health 메모리를 찾는다.

 

Health 메모리에 쓰기를 시도하는 코드를 찾는다.

 

쓰기 코드를 찾았으면 Show disassembler 버튼을 클릭한다.

 

 

Health 메모리에 저장된 값을 1 감소(sub) 시키는 코드가 선택된다.

 

Tools - Auto Assemble 을 클릭한다.

 

삽입할 코드를 enable/disable 할 수 있도록 Cheat Table framework code를 선택한다.

 

Code injection을 선택한다.

 

 

코드를 삽입하고 복구하는 기본 코드가 작성되었다. 코드를 수정하지 않았으므로 프로그램은 변경되지 않는다.

 

Assign to current cheat table을 선택한다.

 

Cheat Table Address List에 스크립트가 추가되었다.

 

Active 체크박스를 클릭해 enable 시킨다.

 

 

스크립트가 삽입된 주소로 점프하는 코드로 변경되었다.

 

다시 Active 체크박스를 클릭해 disable 시킨다.

 

변경된 점프 코드가 다시 원래 sub 코드로 복구되었다.

 

하지만 튜토리얼의 Hit me 버튼을 클릭하면 오류가 발생하고 프로그램이 종료되어 버린다.

 

 

왜 그럴까? 원래 코드와 복구된 코드를 다시 살펴보자.

위 Memory Viewer가 원래 코드고 아래 Memory Viewer가 복구된 코드다.

원래 코드나 복구된 코드나 ebx 레지스터에 저장된 메모리 주소에서 4A4 바이트 떨어진 곳에 저장된 값에서 1을 빼는 내용으로 동일하지만 자세히 보면 Opcode가 다른것을 확인할 수 있다. 원래 코드의 Opcode는 83이고 복구된 코드의 Opcode는 81이다. 두 번째 operand도 값은 1로 동일하지만 크기가 1바이트(01)와 4바이트(00000001)로 큰 차이가 발생했다. 이렇게 코드가 바뀌었지만 내용은 같기때문에 별 문제가 없을것 같지만 명령어 크기가 바뀌는 바람에 그 다음 명령어 영역까지 침범한 것은 큰 문제이다. (그래서 프로그램이 오류로 종료되어 버리는 것이다)

 

스크립트의 복구 내용을 살펴보면 원래 어셈블리어 코드 그대로 사용했음을 확인할 수 있다. 그런데 그 어셈블리어 코드가 원래 옵코드와 오퍼랜드로 복구되지 않는것이 문제이다.

 

인텔 소프트웨어 개발자 메뉴얼을 확인해 보자.

 

intel Software Developer’s Manual_Vol_2.pdf
11.06MB

 

sub 명령어는 여러가지 Opcode가 존재한다.

원래 코드의 83은 imm8(8비트 값)을 오퍼랜드로 사용하지만 복구된 코드의 81은 imm32(32비트 값)을 오퍼랜드로 사용한다. 복구할 스크립트의 sub 명령어를 기계어로 번역할때 Opcode를 81로 사용하기 때문에 sub dword ptr [ebx+000004A4], 01 이라는 어셈블리 명령어의 두 번째 오퍼랜드 01을 0x01로 1바이트 값이 아닌 0x00000001로 4바이트 값으로 번역하는 것이다. 치트엔진은 튜토리얼이 32비트 프로그램이므로 당연히 4바이트 값을 사용했을것이라 생각하는것 같다. 어쨌든 원래 코드로 복구시키지 못하므로 버그라고 봐야 할거같다.

 

 

해결 방법은 간단하다.

위 그림처럼 sub dword ptr [ebx+000004a4], 01 코드를 주석처리하고 그 아래 db 83 AB A4 04 00 00 01을 주석 해제한다. 어셈블리어로 작성한 코드를 기계어로 번역하지 않고 원래 있던 기계어를 다시 그대로 바이트 단위로 정의(db: define byte)하는 것이다.

 

아니면 위 그림처럼 dword(4바이트)를 byte(1바이트)로 바꿔도 된다.

 

r/m8, imm8 오퍼랜드를 사용하는 80 옵코드로 복구되지만 기계어로 번역된 결과의 길이가 같아 다른 명령어를 침범하지 않고 실행에도 문제가 없다.

 

반응형
Posted by J-sean
: