반응형

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

 

※ 참고:

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
:
반응형

도스박스에서 실행한 고전 게임을 치트해 보자. 코드 인젝션으로 번개와 폭탄을 무한대로 사용할 수 있게 한다.

 

도스박스를 실행한다.

 

Rick Dangerous 2를 실행한다.

 

Rick Dangerous II.zip
0.19MB

 

게임이 시작되면 번개를 사용한다.

 

번개 숫자가 변하면 번개가 저장된 메모리를 찾을 수 있다. (Value Type은 2Bytes로 설정해야 한다)

 

 

번개 메모리 주소에서 Find out what writes to this address를 실행한다.

 

다시 번개를 한 번 쏘면 어떤 코드가 번개 메모리 주소를 사용하는지 찾을 수 있다. Show disassembler 버튼을 클릭한다.

 

Memory Viewer에 어셈블리 코드가 표시된다.

 

Tools - Auto Assemble을 클릭한다.

 

 

Auto Assemble 창이 뜨면 Template - AOB Injection을 클릭한다.

 

번개 메모리에 6(번개 최대치)을 저장하는 코드를 newmem영역에 작성한다.

 

File - Assign to current cheat table을 클릭한다.

 

Cheat Table Address List에 스크립트가 추가되었다. Active 체크박스를 클릭해 활성화 한다.

 

 

게임에 오류가 발생한다. 왜 그럴까?

 

다시 Memory Viewer를 확인해 보자. 새로운 코드가 생성된 곳으로 점프하는 명령어가 잘 들어가 있다.

 

새로운 코드도 잘 들어가 있다. 이유를 알 수가 없다.

 

처음부터 다시 해 보자. 게임을 시작하고 번개가 저장된 메모리 주소를 찾는다.

 

 

어떤 코드가 번개가 저장된 메모리 주소를 사용하는지 찾은 후 이번엔 Find out what addresses this code accesses를 실행한다. 이 코드가 어떤 메모리 주소에 접근하는지 찾아준다. 예상대로라면 번개 메모리 주소만을 접근해야 한다.

 

게임에 오류가 발생한 이유를 찾았다. 우리가 찾은 코드는 번개 저장 메모리뿐만 아니라 다른 메모리에도 엄청나게 많은 접근을 하고 있었던 것이다. 이 모든 메모리에 6을 덮어 썼으니 오류가 나지 않을 수 없었다. 어떻게 해야 번개 메모리에만 6을 저장할 수 있을까?

 

다시 Memory Viewer로 돌아와서 메모리 덤프창에서 우클릭 - Goto address를 클릭한다.

 

번개가 저장된 메모리 주소를 입력하고 OK를 클릭한다.

 

 

번개가 저장된 메모리(04 00)가 표시된다. (그 옆의 06 00은 폭탄이 저장된 메모리이고 다시 그 옆의 06 00은 생명이 저장된 메모리이다) 주변을 살펴보자. 00, 09, FF등 별 특이한 값은 보이지 않지만 0A590B31~0A590B34에 JOHN이라는 이름이 기록되있다. 우리가 찾은 코드가 접근하는 다른 메모리 근처엔 없을거 같은 특이한 값이다. (JOHN 이외의 다른 이름들은 높은 점수를 기록한 사람들의 이름이 저장된 HALL OF FAME에 나오는 이름들이다. JOHN은.. 모르겠다)

 

이번엔 JOHN이라는 값을 이용해 번개 저장 메모리 주소를 구분하고 번개와 폭탄을 모두 6으로 덮어쓰는 코드를 작성한다. JOHN은 번개 메모리 주소에서 offset이 0x61이다. 또 번개 메모리 주소 바로 옆, offset 0x02에 폭탄 갯수가 저장되어 있다.

 

코드를 실행하면 번개를 사용할때마다 폭탄과 번개가 6으로 세팅된다.

 

반응형
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
: