게임핵의 원리 (5) — Anti Cheat
이전 포스트
들어가며
앞선 게임핵의 원리 시리즈에서 살펴보았듯이, 게임핵은 게임 자원(예: 메모리, 파일)을 읽고, 쓰거나 게임 프로세스 내에서 코드를 실행하는 것을 목적으로 하는 프로그램입니다. 이러한 행위는 게임 개발자 및 일반 이용자들에게 위협으로 작용할 수 있습니다. 안티 치트(Anti Cheat)는 게임핵으로 인한 위협을 방지하고, 위협에 대응하기 위해 등장한 보안 솔루션입니다.
게임핵의 원리 시리즈의 마지막이 될 이번 포스트에서는 게임핵과 안티 치트라는 창과 방패의 발전에 대해 알아보겠습니다.
시스템 권한
핵과 안티 치트의 승패는 누가 더 높은 시스템 권한을 가지고 있는지에 달려 있습니다. 시스템 권한의 계층을 의미하는 보호 링(Protection Ring)은 x86에서 아래와 같은 구조를 가집니다.
각 링의 권한에 따라 시스템에 접근할 수 있는 범위가 결정됩니다. 안티 치트가 높은 권한을 가질수록 넓은 범위에서 핵을 탐지할 수 있고, 핵이 높은 권한을 가질수록 안티 치트의 감시를 쉽게 벗어날 수 있습니다. 이런 이유로 핵과 안티 치트의 공방 구도는 더 높은 시스템 권한을 차지하기 위한 싸움으로 볼 수 있습니다.
Ring 3에서 Ring 0으로 갈수록 더 높은 권한을 가지게 됩니다. 하지만 실제 현대 운영체제에서 드라이버 및 시스템 서비스를 위한 Ring 2, Ring 1 권한은 관리와 설계의 복잡성으로 인해 거의 사용하지 않고, 시스템 관련 작업은 일반적으로 Ring 0에서 모두 처리하고 있습니다. 따라서, 시스템 권한의 계층은 크게 Ring 3(이용자 모드), Ring 0(커널 모드)으로 나눌 수 있습니다.
핵과 안티 치트는 서로에 대응하는 방식으로 발전하였으며, 이는 가장 낮은 권한인 Ring 3에서 시작되었습니다.
Ring 3: 이용자 모드
초기의 핵은 주로 Windows의 이용자 모드 Win API 라이브러리 함수로 구현되었습니다. 해당 API는 시스템 호출(System Call)을 통한 게임 자원 접근을 지원하고, 커널을 통해 복잡한 시스템 관련 처리를 수행하기 때문에 일반 개발자가 편리하게 사용할 수 있다는 장점이 있습니다.
⚔️메모리 접근
Windows가 제공하는 메모리 API를 사용하면 핵 프로세스가 게임 프로세스 메모리에 접근할 수 있습니다. 대표적으로 사용하는 API는 프로세스의 메모리 주소값을 읽고 쓰는 것을 지원하는 ReadProcessMemory(), WriteProcessMemory()입니다. 핵 이용자는 이와 같은 API를 직접 사용하여 핵을 제작하거나, 범용적으로 메모리에 접근할 수 있는 메모리 에디터(예: Cheat Engine)를 제작하였습니다.
핵 또는 메모리 에디터를 제작함으로써 핵 이용자는 게임 내 요소의 점수/수치를 나타내는 메모리를 조작할 수 있었습니다. 이와 같은 핵은 게임의 외부에서 동작하기 때문에 ‘External’ Hack이라고 부릅니다.
🛡️핵툴 탐지
다양한 핵이 등장함에 따라, 안티 치트는 게임에 유해한 영향을 주는 것으로 의심되는 핵툴(예: Cheat Engine) 및 디버거(예: OllyDbg, x64dbg)를 탐지하기 시작했습니다. 안치 치트는 고유한 정보(예: 창 캡션, 프로세스 이름, 문자열, 시그니쳐)를 Blocklist 기반으로 탐지하는 방식을 사용했지만, 이는 이용자 모드에서 핵을 통해 충분히 우회할 수 있다는 한계가 있었습니다. 오픈 소스 프로그램인 Cheat Engine을 커스텀하게 개조한 UCE(Undetected Cheat Engine)를 제작하여 안티 치트 탐지를 우회한 사례가 대표적입니다.
⚔️DLL 인젝션
안티 치트가 핵툴을 탐지하자, 핵은 게임 후킹의 필요성을 느끼고 DLL 인젝션(DLL Injection)을 시작했습니다.
DLL(Dynamic Link Library)은 여러 프로그램이 공유할 수 있는 코드 라이브러리로, 프로세스의 실행에 따라 로드됩니다. DLL 인젝션은 치트 기능을 담은 악의적인 DLL(핵 DLL)을 게임 프로세스에 주입하는 기법으로, CreateRemoteThread()와 LoadLibrary()를 사용하여 구현할 수 있습니다. 인젝션된 핵 DLL은 게임 프로세스 내에 잠입하여 게임 메모리 내에서 핵 코드를 실행하기 때문에, 인젝션을 이용한 핵은 'Internal' Hack이라고 부릅니다.
게임과 함께 동작하기 때문에 핵툴 탐지로 쉽게 탐지할 수 있는 External Hack과 달리, 안티 치트가 실행되기 전에 게임에 인젝션을 성공한 Internal Hack은 외부에서 흔적을 찾을 수 없어 탐지 난이도가 높습니다. 외부 프로세스만을 탐지하는 안티 치트로는 게임 내부에서 게임의 일부분인 것처럼 존재하는 핵 DLL을 탐지하지 못하는 경우도 있습니다. 또한, Internal Hack은 게임 프로세스 내에서 동작하기 때문에 게임 제어(예: 게임 함수 호출)를 쉽게 수행할 수 있다는 장점이 있습니다.
⚔️코드 인젝션
핵이 게임 내부에서 코드를 실행하는 또 다른 기법으로는 코드 인젝션(Code Injection)이 있습니다. 코드 인젝션은 기계어 코드를 프로세스에 인젝션하여 임의 코드를 실행시키는 기법으로, CreateRemoteThread()를 사용하여 구현합니다.
코드 인젝션을 사용한 핵은 DLL 파일 및 모듈 단위가 아닌 작은 기계어 코드 조각으로 실행되기 때문에 DLL 인젝션보다 탐지하기 어렵습니다. 하지만, 작은 코드 단위로 인젝션된다는 특징으로 인해 개발 측면의 불편함 역시 존재합니다. 이러한 이유로, 코드 인젝션과 DLL 인젝션의 장점을 모두 활용할 수 있는 수동 매핑 DLL 인젝션이 등장했습니다.
⚔️수동 매핑 DLL 인젝션
수동 매핑 DLL 인젝션(Manual Mapping DLL Injection)은 LoadLibrary()를 그대로 구현한 기법입니다. LoadLibrary()는 Windows PE 로더의 DLL 로딩 과정을 모방하여 구현할 수 있습니다. 해당 과정은 아래와 같습니다.
DLL을 섹션별로 대상 프로세스 메모리에 매핑
DLL의 Import Directory를 분석하여 IAT 구성
재배치(Relocation) 및 쓰레드 원격 생성(CreateRemoteThread) 수행
이때, CreateRemoteThread()를 코드 인젝션처럼 사용함으로써, 결과적으로 LoadLibrary() 없이 DLL 인젝션을 구현할 수 있습니다.
인젝션된 DLL은 수동으로 매핑되었기 때문에 코드 인젝션과 유사한 형태로 실행되고, 그 덕분에 프로세스의 모듈로 인식되지 않아 안티 치트의 탐지를 피할 수 있습니다. 수동 매핑 DLL 인젝션은 코드 인젝션과 DLL 인젝션의 장점을 모두 갖춘 특징 덕분에 현재까지도 자주 사용되고 있습니다.
🛡️인젝션 탐지
DLL 인젝션을 통해 핵이 기존의 안티 치트를 우회하고 게임 프로세스에 영향을 줄 수 있게 되며, 안티 치트는 DLL 인젝션 탐지를 시도하였습니다. 하지만 DLL 인젝션으로 작동하는 정상적인 애플리케이션(예: 녹화 애플리케이션)으로 인한 오탐(False Positive)이 존재하여 핵을 정확하게 탐지하기는 어려웠습니다.
안티 치트는 인젝션 핵 탐지를 위해, 인젝션의 핵심인 쓰레드 생성을 탐지하는 쪽으로 발전했습니다. 게임 프로세스 내 생성된 쓰레드를 검사하여 정상 쓰레드 여부를 확인하는 방식을 사용한 결과, 쓰레드 생성이 수반되는 DLL 인젝션 및 코드 인젝션을 모두 탐지할 수 있었습니다. 하지만 해당 탐지 방법은 쓰레드를 새로 생성하지 않고 기존 쓰레드 흐름을 하이재킹하여 인젝션할 DLL의 코드를 실행시키는 방식으로 우회할 수 있다는 한계를 가집니다.
⚔️게임 코드 변조
게임 내 수치(예: 자산, 점수)를 변조하는 것만이 핵의 목적은 아닙니다. 핵은 인라인 후킹을 통해 게임의 코드를 변조하기도 합니다. 코드 패치를 통해 게임의 로직을 변경한다면, 단순한 수치를 변경하는 것 이상의 기능을 가진 다양한 핵을 구현할 수 있습니다.
🛡️무결성 검사
안티 치트는 코드 변조를 탐지하기 위해 게임 프로세스 메모리를 대상으로 하는 무결성 검사를 도입하였습니다. 일반적으로 검사는 게임 코드가 존재하는 메모리 영역(예 : .text 섹션) 전체의 해시값을 주기적으로 구하고 정상적인 해시값과 일치하는지 확인하는 방식으로 이루어집니다. 해당 방법을 이용하면, 핵이 게임 코드를 변조할 경우 발생하는 해시값의 변화를 통해 코드 변조를 탐지할 수 있습니다.
⚔️무결성 검사 우회
코드 무결성 검사는 코드 영역의 Opcode가 일반적인 환경에서 변하지 않는다는 특성에 기반한 보호 기법입니다. 따라서, 코드 영역과 다르게 자주 변화하는 데이터 영역의 변조를 탐지하기 어렵다는 한계가 있습니다. 또한, 게임 프로세스 내에서 무결성 검사를 수행하는 경우라면, 공격자는 무결성 검사 루틴을 분석하고 핵을 통해 루틴 자체를 패치함으로써 무결성 검사를 우회할 수 있습니다.
게임에 무결성 검사가 존재하더라도, 무결성 검사가 적용되지 않은 모듈 및 코드를 악용하여 후킹을 구현함으로써 검사를 우회할 수 있습니다. 게임 코드가 모듈의 함수를 동적 링킹(Dynamic Linking)하여 사용한다면, 핵은 해당 함수를 후킹함으로써 게임 코드가 함수를 호출할 때 게임의 흐름을 제어할 수 있습니다.
⚔️디버거
안티 치트의 무결성 검사로 인해 코드 변조가 어려워지자, 디버깅을 통해 코드를 변조하지 않고 게임 실행을 제어하는 핵이 등장했습니다. 브레이크포인트 중 x86/amd64 아키텍처 CPU가 제공하는 디버그 레지스터(Debug Register)를 통해 사용할 수 있는 하드웨어 브레이크포인트(Hardware Breakpoint)를 이용하면 코드 변조 없이 디버거를 구현할 수 있습니다.
디버거를 통해 변조할 게임 코드 또는 데이터에 브레이크포인트를 설정하면, 예외 발생 시 예외 제어권을 핵으로 넘기고 게임을 제어함으로써 코드 변조 없이도 핵을 구현할 수 있습니다. 비슷한 방식으로 메모리 브레이크포인트(Memory Breakpoint)를 이용하면, 메모리 보호 속성을 특정 속성(예: 접근 시 예외가 발생하는 PAGE_GUARD, PAGE_NOACCESS)으로 변경하여 예외를 발생시키고 게임을 제어할 수 있습니다.
🛡️안티 디버깅
대부분의 안티 치트는 안티 디버깅 기능을 탑재하고 있습니다. 과거에는 안티 디버깅 기법이 소프트웨어 브레이크포인트 및 Windows API 디버거 위주로 적용되었기 때문에 안티 치트로 하드웨어/메모리 브레이크포인트를 탐지하지 못했습니다. 하지만, 안티 치트로 디버그 레지스터의 변경을 탐지하거나 디버그 레지스터를 선점함으로써 하드웨어 브레이크포인트를 탐지할 수 있게 되었고, 그로 인해 현재는 하드웨어 브레이크포인트를 사용하려면 안티 치트를 우회해야 합니다.
🛡️메모리 섹션 재매핑
메모리 섹션 재매핑(Remapping)은 페이지의 보호 속성을 변경하는 VirtualProtect()를 막기 위한 기법으로, 페이지를 언매핑(Unmapping)하고 SEC_NO_CHANGE 속성을 가진 섹션으로 재매핑(Remapping)하여 페이지의 속성 변경을 제한합니다.
SEC_NO_CHANGE 속성은 문서화되지 않은(Undocumented) 속성으로, 해당 속성을 적용하면 페이지 보호 속성의 변경이 제한됩니다. 보호 속성 변경을 제한할 경우, 쓰기 속성이 없는 코드 영역에 쓰기 속성을 부여할 수 없게 되므로 코드 변조를 제한할 수 있습니다. 하지만 핵이 해당 기법을 역으로 사용할 경우, 언매핑 및 SEC_NO_CHANGE 속성이 없는 섹션으로의 재매핑을 거침으로써 페이지 보호 속성 변경이 가능하다는 한계가 있습니다.
다양한 기법들이 등장과 함께 경쟁적으로 발전한 핵과 안티 치트는 Ring 0에서 그 경쟁을 이어갔습니다.
Ring 0: 커널 모드
🛡️프로세스 보호
Ring 3에서 핵은 일반적으로OpenProcess()를 통해 게임 프로세스를 열고 핸들을 얻어 메모리에 접근합니다. Ring 3의 핵을 막기 위해 등장한 Ring 0의 안티 치트는 핵의 동작을 고려하여, 메모리 접근을 제한하는 방식으로 게임 프로세스를 보호하였습니다.
프로세스를 보호하는 대표적인 방법은 SSDT 후킹을 통해 시스템 호출을 감시하거나 프로세스 핸들의 권한을 제한하는 것입니다. 32비트 Windows에서는 주로 SSDT 후킹을 사용하지만, 64비트 Windows에서는 패치 가드(Patch Guard, Kernel Patch Protection)로 인해 SSDT 후킹이 제한되기 때문에 주로 ObRegisterCallbacks()을 이용하여 핸들의 권한을 제한합니다.
게임 프로세스 보호가 적용될 경우, 메모리에 대한 핸들을 획득할 수 없으므로 핵의 동작이 제한됩니다.
동작이 제한된 핵은, 안티 치트를 우회하기 위한 또 다른 방법들을 찾았습니다.
⚔️커널 모드 핵툴
초기 커널 모드 핵은 주로 치트 엔진이 제공하는 커널 드라이버를 사용했습니다. 치트 엔진의 커널 드라이버를 이용하면, 커널 단에서 게임 프로세스의 메모리를 읽고 씀으로써 안티 치트의 보호를 우회할 수 있었습니다. 또한 치트 엔진이 제공하는 또 다른 기능인 커널 모드 디버거(Kernel Mode Debugger)를 이용하면, 안티 치트의 영향을 받지 않고 게임을 디버깅할 수도 있었습니다.
⚔️안티 루트킷
이외에도 아래와 같이 커널 악성코드 분석에 사용되는 안티 루트킷(Anti-Rootkit, 예: PC Hunter(xuetr), WKE)을 통해 안티 치트의 커널 후킹을 스캔하고, 언훅 또는 콜백 삭제를 통해 안티 치트 보호를 해제하기도 하였습니다.
⚔️커널 드라이버 제작
핵 개발자들은 프로세스 메모리를 읽고 쓰는 기능을 포함하는 커널 드라이버를 직접 개발하여 사용하기도 합니다. 핵이 읽고 쓸 메모리 주소 및 값을 자신의 커널 드라이버에 요청하면, 드라이버가 해당 주소에 값을 쓰거나 메모리를 읽어 반환하는 구조가 가장 일반적이었으며, 이를 통해 프로세스를 보호하는 안티 치트의 영향 없이 핵을 사용할 수 있었습니다.
하지만, x64 Windows는 드라이버 서명 적용(Driver Signature Enforcement)으로 인해 디지털 서명이 없는 신뢰하지 않는 커널 드라이버의 로딩이 제한됩니다. 이로 인해, 핵은 드라이버 서명 없이 로딩할 수 있는 테스트 모드 기능을 통해 핵의 커널 드라이버를 로딩시켜 사용하게 되었습니다.
🛡️커널 드라이버 탐지
커널 드라이버를 사용하는 핵으로 인해, 안티 치트 또한 커널 드라이버를 탐지하기 시작했습니다. 게임에 유해한 것으로 널리 알려진 드라이버(예: 치트 엔진의 커널 드라이버) 로딩을 탐지하는 것이 기본 방식이었으며, 신뢰하지 않는 드라이버의 로딩 및 테스트 모드 활성화 여부를 탐지하여 핵 개발자가 개발한 커널 드라이버 로딩을 제한하기도 하였습니다.
⚔️커널 드라이버 익스플로잇
핵은 커널 드라이버 로딩이 제한되자 커널 드라이버 익스플로잇(Kernel Driver Exploit)을 시도하였습니다. 서명이 되어 있지만 취약한 커널 드라이버(예: Virtual Box, CPU-Z, Capcom 구버전)를 로딩시킨 후, 해당 드라이버를 익스플로잇하여 커널 메모리를 조작하거나 코드를 실행시키는 방식이 대표적입니다. 이를 통해 서명 검사를 통과하고 정상적으로 커널의 권한을 획득할 수 있었으며, 일부 취약한 드라이버에 존재하는 임의 메모리 주소 읽기/쓰기 기능을 이용할 수도 있었습니다.
⚔️DKOM
DKOM(Direct Kernel Object Manipulation)은 커널에 존재하는 객체를 조작하는 기법입니다. 핵은 익스플로잇으로 얻은 커널 권한을 통해 DKOM을 수행하고 게임 프로세스에 접근할 수 있습니다. DKOM을 이용한 객체 대표적인 조작 방법으로는 게임 프로세스 핸들 오브젝트의 접근 권한(Granted Access)을 조작하여 프로세스를 열거나, 물리 메모리 관련 오브젝트를 조작해 물리 메모리(Physical Memory)로 게임 메모리에 접근하는 방법이 있으며, 이외에도 드라이버 서명 검사 모듈(Ci.dll)을 임시로 패치하여 서명되지 않은 드라이버를 로딩시키는 방법이 있습니다.
⚔️유출된 드라이버 서명 인증서 사용
불법으로 거래되거나 유출된 드라이버 서명 인증서를 핵 개발자가 직접 사용하는 경우도 있습니다. 획득한 인증서로 서명한 커널 드라이버를 통해, 핵은 익스플로잇 및 DKOM을 수행하지 않고 커널 드라이버를 로딩하여 커널 권한을 획득할 수 있습니다.
많은 공격 기법이 등장했지만 안티 치트 역시 다양한 방법의 공격에 계속해서 대응해나갔습니다. 현재 핵과 안티 치트의 공방은 커널 모드보다 상위 권한인 Ring -1(하이퍼바이저)에서 이어지고 있습니다.
하이퍼바이저 (Ring -1)
하이퍼바이저(Hypvervisor, Virtual Machine Monitor, Virtualizer)는 호스트 머신에서 여러 운영체제의 가상화를 구현할 수 있는 가상화(Virtualization) 플랫폼입니다. 하이퍼바이저는 Intel VT-x 또는 AMD-v 하드웨어 가상화 기술을 사용하여 구현할 수 있습니다.
하이퍼바이저는 커널 모드(Ring 0)보다 권한이 더 높은 Ring -1에서 동작하기 때문에 커널 모드의 영향을 받지 않습니다. 하이퍼바이저는 메모리 페이지를 제어할 수 있는 EPT(Extended Page Table)를 통해 커널에 처리되는 메모리 읽기 및 쓰기를 모니터링할 수 있습니다. 이는 안티 치트 커널 드라이버가 메모리를 감시하더라도, 그 감시를 더 높은 권한에서 다시 모니터링해서 동작을 변경하고 우회할 수 있다는 것을 의미합니다. 이외에도 게임 프로세스의 EPT를 제어하여 핵을 구현한 사례도 있었습니다.
⚔️DBVM
2008년 공개된 DBVM(Dark Byte Virtual Machine)은 치트 엔진에서 제공하는 하이퍼바이저로 구현된 경량 가상 머신입니다. 하이퍼바이저는 커널보다 높은 권한에서 작동하기 때문에 DBVM에서 제공하는 대부분의 기능을 통해 위에서 언급한 대부분의 안티 치트 기법을 우회할 수 있습니다. 이에 핵 개발자들은 DBVM 기능(예: 커널단 메모리 읽고 쓰기, 게임 프로세스 디버깅)을 활용하여 더 높은 권한에서 핵을 구현하였습니다.
🛡️DBVM 탐지
DBVM으로 큰 피해를 본 안티 치트는 DBVM 탐지를 시도했습니다. DBVM은 하이퍼바이저 호출 명령어인 vmcall을 통해 DBVM 명령을 사용합니다. DBVM 명령 사용을 위해서는 비밀번호가 필요하지만, 기본 비밀번호가 지정되어 있어 비밀번호를 직접 변경하지 않는 한 누구나 DBVM의 하이퍼바이저 기능을 사용할 수 있습니다. 따라서 안티 치트는 DBVM이 로딩되어 있다고 가정하고, DBVM의 명령을 사용하여 결과(예: 성공, 실패)를 확인함으로써 DBVM의 동작 여부를 탐지하였습니다.
⚔️하이퍼바이저 핵
과거에는 하이퍼바이저와 관련된 자료가 부족하여 핵 개발자들이 사용하기 복잡한 하이퍼바이저를 직접 개발하는데 어려움이 있었습니다. 하지만 Intel VT-x 하이퍼바이저를 쉽게 개발할 수 있는 라이브러리(HyperPlatform)가 공개됨에 따라 하이퍼바이저를 직접 제작한 핵이 등장했습니다. 해당 플랫폼을 이용하여 핵 개발자들은 하이퍼바이저 디버거, EPT를 사용한 메모리 변조 및 핵을 비교적 쉽게 제작할 수 있었습니다.
🛡️하이퍼바이저 탐지
일반적으로 게스트 OS에서는 타임스탬프 카운터를 측정하는 명령어인 rdtsc를 사용하여 가상화 처리로 인해 발생하는 시간 차이를 확인함으로써 에뮬레이션을 탐지합니다. 하지만 해당 명령어 또한 하이퍼바이저에서 제어할 수 있기 때문에 마찬가지로 우회 가능성이 존재합니다.
⚔️핵 vs 🛡️안티 치트
핵과 안티 치트의 공방은 계속되고 있지만, 이 공방은 근본적으로 안티 치트가 불리한 입장입니다.
⚔️하나의 취약점을 발굴하는 핵 vs 🛡️모든 위협을 고려하는 안티 치트
이는 보안의 문제와 닮아 있습니다. 보안을 지키는 관점에서는 모든 공격 벡터를 고려하고 막아야 하지만, 공격자 관점에서는 취약한 어느 한 곳이라도 찾기만 하면 보안을 우회할 수 있습니다. 핵과 안티 치트도 마찬가지입니다. 안티 치트 개발자는 핵으로 유도될 수 있는 모든 위협을 고려하여 개발을 해야 하는 반면, 핵 개발자는 안티 치트가 고려하지 못한 부분을 하나라도 찾으면 공방에서 승리할 수 있기 때문에 핵이 유리한 측면이 있습니다.
⚔️다양한 수단을 고려하는 핵 vs 🛡️가용성을 보장해야 하는 안티 치트
위에서 이야기를 하였듯, 핵과 안티 치트의 승패는 누가 더 높은 시스템 권한을 가지고 있는지에 달려 있습니다. 따라서 안티 치트도 핵과 같거나 더 높은 권한(예: 하이퍼바이저, UEFI)을 사용함으로써 핵을 막으면 쉽게 문제를 해결할 수 있습니다. 하지만, 이 방법에는 현실적인 한계가 존재합니다.
안티 치트가 먼저 하이퍼바이저를 사용해서 핵을 막을 수 있다면 좋겠지만, 현실에서는 가용성(Availability) 문제가 발생합니다. 여러 환경의 이용자를 모두 고려하기 어렵고, 버그가 발생하면 시스템이 종료될 수 있기 때문에 하드웨어 및 운영체제 환경에 따라 하이퍼바이저의 호환성과 구현에 차이가 존재합니다.
또한, 하이퍼바이저 모드의 안정성은 커널 모드보다 더 낮기 때문에 게임 이용 중 문제가 발생할 가능성이 높습니다. 하이퍼바이저 모드 안티 치트의 사용으로 인해 게임이 정지 또는 종료된다면, 이는 이용자의 편의성을 침해하여 결과적으로 게임에 부정적인 영향을 줄 수 있습니다. 이런 이유로, 안티 치트에 게임의 정지 및 종료는 이용자의 이용자의 가용성, 편의성을 침해하게 될 것이고 결과적으로 게임에 안좋은 영향을 줄 수 있습니다. 이런 이유로 안티 치트에 높은 권한을 부여할 때는 신중할 필요가 있습니다. 이용자가 불편하지 않도록 여러 요소를 고려하여 게임의 가용성을 보장해야 하는 안티 치트와 달리, 핵은 게임의 가용성을 보장하지 않아도 괜찮습니다. 따라서, 핵은 시스템 권한을 획득하기 위해서 다양한 수단을 가리지 않고, 그로 인해 가용성을 보장해야 하는 안티 치트는 불리한 입장에 놓이게 됩니다.
안티 치트는 오탐(False Positive)으로 인한 문제도 고려해야 합니다. 안티 치트에서 오탐은 정상적인 애플리케이션을 핵이라고 탐지하는 상황을 의미합니다. 안티 치트가 보수적인 방법을 사용하여 핵을 탐지하더라도, 오탐이 발생하여 게임이 정지 또는 종료된다면 이는 정상적인 서비스 이용자의 피해로 이어집니다. 따라서, 안티 치트는 오탐으로 인한 문제를 방지하면서 핵을 탐지해야 하는 어려운 숙제를 가지고 있습니다.
⚔️불법을 저지르는 핵 vs 🛡️법을 준수해야 하는 안티 치트
법적인 관점에서도 법을 준수해야 하는 안티 치트가 불리합니다. 예를 들어, 안티 치트가 핵 방지를 위해 시스템을 스캔해서 파일을 전송할 때, 해당 파일이 이용자의 개인정보를 담고 있다면 법적인 문제로 이어질 수 있습니다. 안티 치트 개발자는 이와 같은 법적 문제 상황 역시 고려하여 개발을 해야 하기 때문에 시스템에 제한적으로 접근할 수 밖에 없습니다. 또한, 법적 제약으로 인해 핵을 엄격하게 제한하기도 어렵습니다. 반면 핵은 그 자체가 불법이며, 실행되는 시스템이 핵 자신의 소유이기 때문에 시스템의 모든 곳에 접근하는 것이 문제가 되지 않습니다. 따라서 법을 준수해야 하는 안티 치트가 더 불리한 입장입니다.
마치며
지금까지 핵과 안티 치트의 발전을 알아보았습니다. 살펴본 바와 같이, 안티 치트는 여러 이유로 핵으로부터 불리할 수 밖에 없는 한계를 가지고 있습니다. 지금 이 순간까지도 전장에서 핵과 맞서고 있는 안티 치트 개발자들에게 경의를 표하고 핵의 근절을 기원하며 게임핵 시리즈를 마무리하겠습니다.
Reference
About Theori Security Assessment
티오리 Security Assessment 팀은 실제 해커들의 오펜시브 보안 감사 서비스를 통해 고객의 서비스와 인프라스트럭처를 안전하게 함으로써 비즈니스를 보호합니다. 특히, 더욱 안전한 세상을 위해 난제급 사이버보안 문제들을 해결하는 것을 즐기며, 오펜시브 사이버보안의 리더로서, 공격자보다 한발 앞서 대응하고 불가능하다고 여겨지는 문제를 기술중심적으로 해결합니다.
