치트 엔진으로 삽입한(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)로 큰 차이가 발생했다. 이렇게 코드가 바뀌었지만 내용은 같기때문에 별 문제가 없을것 같지만 명령어 크기가 바뀌는 바람에 그 다음 명령어 영역까지 침범한 것은 큰 문제이다. (그래서 프로그램이 오류로 종료되어 버리는 것이다)
스크립트의 복구 내용을 살펴보면 원래 어셈블리어 코드 그대로 사용했음을 확인할 수 있다. 그런데 그 어셈블리어 코드가 원래 옵코드와 오퍼랜드로 복구되지 않는것이 문제이다.
원래 코드의 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 옵코드로 복구되지만 기계어로 번역된 결과의 길이가 같아 다른 명령어를 침범하지 않고 실행에도 문제가 없다.
