2.1 Game Hack

게임 메모리 핵 프로그램은 메모리에 접근하여 데이터를 변조하는 방식으로 동작한다. 온라인 게임 내의 모든 데이터는 메모리에 상주한다. 따라서 만약 메모리의 주소를 알고 있다면 그 값을 수정하여 게임 내에서 사용되는 주요 데이터를 임의대로 변경하는 것이 가능해진다. 게임의 메모리에 접근하는 방법으로는 게임 프로세스 내부에 DLL을 주입하는 방법과 외부의 다른 프로세스에서 조작하는 방법이 있다. 핵 프로그램은 이와 같은 방법으로 메모리에 접근한 뒤 다음 두 가지 방식으로 동작한다. 첫 번째로 핵 프로그램을 메인 메모리에 상주시킨 다음 게임으로부터 불러오는 데이터를 수정하고 적재하는 방식이 있다. 두 번째로 메인 메모리에 적재된 데이터를 삭제하고 변조된 값을 적재시키는 방식이 있다. 메모리 핵을 사용하면 체력, 재화, 공격력과 같은 데이터나 게임의 원본 코드를 변조하여 게임을 플레이하는 것이 가능하다. 제안하는 시스템의 실험에서는 게임 에디터 프로그램 중 가장 대표적인 Cheat Engine을 사용한 DLL 주입 방식으로 메인 메모리의 데이터를 변조하여 실험에 사용하였다.

2.2 BlockChain

기존 핵 침입 탐지 시스템의 중앙 집중으로 인한 과부하 문제와 블록을 무수히 쌓음으로써 보안성과 무결성이 보장되어 블록체인을 사용하였다. 블록체인(BlockChain)은 분산 컴퓨팅 기술 기반의 데이터 위변조 방지 기술이다. 블록체인은 P2P(Peer to Peer) 네트워크를 통해서 관리되는 분산 데이터베이스의 한 형태로, 거래 정보를 담은 장부를 중앙 서버 한 곳에 저장하는 것이 아닌 블록체인 네트워크에 연결된 여러 컴퓨터에 저장 및 보관하는 기술이다. 블록체인의 특징은 보안성, 거래 과정의 신속성과 투명성, 무결성 등이 있다.

블록체인을 통한 거래 방법은 거래 요청이 발생하면 거래 정보가 담긴 블록이 생성된다. 생성된 블록은 네트워크상의 모든 참여자에게 전달되고 참여자들은 거래 정보의 유효성을 상호 검증한다. 참여자 과반수의 데이터와 일치하는 거래 내용은 정상 장부로 확인되어 이전 블록에 연결되고, 사본이 만들어져 각 사용자의 컴퓨터에 분산 저장된다. 이러한 과정을 거치고 나면 거래가 완료된다^[3].

2.3 Online-based Multiplay Game

제안하는 게임 핵 탐지 시스템 실험을 위한 환경을 구성하기 위해 Unity 엔진과 Photon Cloud를 사용하였다. Unity 엔진은 게임 엔진 시장 점유율 1위에 달하는 만큼 많은 게임에 적용되고 있어 실제 사용되고 있는 대부분의 온라인 게임과 같은 환경을 구현할 수 있다^[4]. Photon Cloud는 게임 서비스를 위한 SaaS(Software as a Service)이다. 해당 SaaS를 이용하면 별도의 게임 서버 관리가 필요 없다는 장점이 있다^[5].

3.1 Experiment Environment

본 논문에서는 블록체인 시스템을 FPS 게임에 적용하여 실험하였다. 해당 블록체인 시스템은 블록체인(BlockChain)과 침입 탐지 시스템인 Intrusion Detection System(IDS)을 합쳐서 BC-IDS라고 정의하였으며 각 사용자의 블록체인 통신 프로세스는 BC라고 정의하였다. 본 시스템의 구조는 게임 데이터와 다른 사용자와 통신하고 투표 값에 따라 의사 결정권을 가지고 있는 프로세스, 전송받은 블록을 PoS 검증을 통해 결괏값을 전송하는 프로세스가 포함된다. 실험에 사용할 게임은 게임 내 변숫값에 대한 모니터링이 목적이므로 간단한 오픈소스 FPS를 사용하였다^[6]． 해당 게임은 Photon Cloud가 적용되어 있으며, 메인 메뉴에서 게임룸 생성 또는 타 플레이어가 생성한 룸 참가를 선택하여 게임을 진행할 수 있다.

3.2 Online Game Used in the Experiment

실험에 사용한 게임은 그림 1과 같으며 플레이어의 기본 체력은 100, 공격력은 50으로 설정하고, 총기를 사용하여 상대를 공격할 수 있다. 적 플레이어가 자신의 플레이어 객체에 공격을 가하면 데미지를 입게 되고 데미지를 입은 플레이어의 이름과 변경 전의 체력 값, 변경 이후의 체력 값에 대한 데이터가 BC-IDS로 전달된다.

그림 1. 실험에 사용한 온라인 게임

Fig. 1. Online Game Used in the Experiment

실험 게임 코드에서 새 스크립트인 procNetworkMgr을 추가하였다. 이는 BC-IDS와의 통신을 위한 스크립트로 BC-IDS의 접속을 받기 위한 ServerStart() 함수와 게임 데이터를 발신하는 SendMsg() 함수, 핵이 탐지되면 게임을 강제 종료시킬 수 있도록 Disconnect_Check() 함수로 구성되어 있다. 또한, 게임 내 스크립트 중 playerController에 코드를 추가하였다.

그림 2, 3과 표 1, 2는 실험에 사용한 클래스의 순서도와　클래스 내 메서드의 코드 예시이다.

그림 2. procNetworkMgr 클래스의 순서도

Fig. 2. Flow Chart for proNetworkMgr Class

우선 playerController 클래스의 Start 콜백함수에 procNetworkMgr 클래스를 인스턴트화 하고 ServerStart() 메서드를 호출하였다. 또한, 스레드를 통해 Disconnect_Check() 메서드를 호출하였다.

Update 콜백함수에서는 실제 게임 환경과 같게 하려면 특정 키가 입력되었을 때 플레이어가 HP를 회복할 수 있도록 하였으며 스레드로 동작 중인 Disconnect_Check() 메서드가 핵 탐지와 함께 값을 반환하였는지 확인하는 구문도 추가하였다. 핵이 탐지되어 게임 종료 플래그 값이 변경되면 ExitGame() 메서드를 호출하여 게임을 종료시킨다.

클래스 내 플레이어의 데미지를 계산하는 TakeDamage 함수의 RPC 함수에 플레이어의 ID, 이전 체력 값, 현재 체력 값을 procNetworkMgr 인스턴스의 SendMsg 메서드를 통해 BC-IDS로 전달하도록 작성하였다. 이때 RPC란 Remote Procedure Call 의 약어이며 Photon에서는 RPC가 적용된 함수들은 다른 사용자들에게도 해당 함수가 호출될 수 있도록 해준다. 어느 플레이어가 데미지를 입게 되면 타 사용자들의 환경에서도 같은 값의 변화가 일어나야 하므로 이에 RPC가 사용되며 플레이어의 체력 연산 또한 이곳에서 이루어진다. 같은 방법으로 체력을 회복하는 Heal() 메서드와 RPC 메서드를 추가로 작성해주었다.

그림 3. PlayerController 클래스의 순서도

Fig. 3. Flow Chart for PlayerController Class

3.3 BC-IDS

동작 방식은 <그림 4>와　같다. 게임을 실행하고 Photon Cloud 내에 게임방을 개설하게 되면 플레이어들이 게임방에 입장한다. 게임을 시작하면 게임 프로세스는 BC-IDS와의 접속을 시도한다. 연결이 성공적으로 이루어졌을 경우 실제 게임이 진행된다. 우선 클라이언트가 공격당했다면 게임 이벤트가 발생하여 프로세스가 동작한다. 동작 방식의 순서는 다음과 같고 자연스러운 설명을 위해 공격당한 BC를 중심 BC로　정의하였다.

1. 게임 프로세스가 TCP 통신을 이용하여 실시간으로 손실 없이 특정 게임 데이터를 BC에 전송하고 전송받은 BC는 중심 BC가 된다.

2. 중심 BC가 게임 데이터를 해시화하여 블록을 생성한 후 블록 또한 해시화한다.

3. 중심 BC가 생성된 블록을 타 사용자들의 BC에서 브로드캐스트를 이용하여 전송한다.

4. 타 사용자들의 BC는 자신이 기존에 가지고 있던 블록체인을 불러와 수신받은 블록과 비교하여 검증한다. 실험에서는 블록 해시값과 체력 해시값을 비교하였다.

5. 검증 통과 여부를 중심 BC에 재전송한다.

6. 중심 BC에서 참과 거짓의 개수를 연산하여 해당 데이터가 정상적인 데이터인지 조작된 데이터인지를 판단한다.

그림 4. BCーIDS 구상도

Fig. 4. Configuration BC-IDS

반환 값에 따른 동작 방식은 <표 3>과 같다. 중심 BC가 타 사용자들의 BC에 블록을 브로드캐스트하는 과정은 신속한 전송을 위해 UDP 통신으로 전송한다. 중심　BC와 타 BC 둘 중 하나라도 거짓이라면 UDP 통신사용으로 인한 데이터 손실이 발생했거나 타 BC가 공격당한 것이므로 악성 블록을 정상적인 BC를 이용하여 복원한다. 복원한 블록을 다시 검증하기는 어려움으로 TCP 통신을 이용해 데이터 손실 없이 복원한다.

구체적인 구현 방식은 다음과 같다. 우선 BC-IDS는 Receiver_ send와 Receiver 두 파일로 이루어져 있다. Receiver_send는 receiver 메서드를 통해 BC-IDS가 클라이언트로서 게임과 TCP 연결을 수행하고 gamedata 함수를 호출한다. gamedata 함수에서는 게임으로부터 수신받은 데이터의 블록화 과정을 거치게 되는데 이전 체력과 현재 체력은 해시화하여 저장하게 된다. 또한, PoS 검증 결과를 받기 위해 PoS 전용 소켓을 생성하여 스레드로 호출하는 tcpthread 함수의 인자 값으로 전달해주게 된다. tcpthread 함수에서는 타 BC-IDS들로부터 수신받은 값들을 voteResult 함수를 통해 투표를 진행하게 된다. 이 함수는 투표 결과로 Genesis, All true, false (kill) 중의 하나가 결정되고 pos_socket을 통한 전송과 콘솔에도 출력된다. 이 외에 결과에서는 restoreBlock이 호출된다.

TCP Receiver는 receiver 메서드를 통해 다른 BC-IDS로부터 블록을 수신받게 된다. 수신받은 블록은 PoS 메서드를 통해 리스트화 작업이 수행되고 첫 번째로 수신받은 블록은 CreateBlockChain 메서드를 호출하여 JSON 파일에 저장이 이루어진다. 다음은 JSON 파일에 블록이 저장되는 형식이다.

이후에 수신받으면 JSON 파일을 읽어와 check 함수를 통해 이전 블록과 수신한 블록이 같은지 검증을 거치게 된다. 이때 검증은 이전 블록 내 현재 체력 값과 현재 블록 내 이전 체력 값을 비교하게 된다. 수신한 블록이 첫 블록이거나 check 함수를 통한 검증 결과가 동일이면 addBlockChain 함수를 실행하여 JSON 파일에 블록을 추가하는 작업이 이루어진다. 마지막으로 connectionRestore 함수를 통해 50,000번 포트에 타 BC-IDS로 클라이언트로서 TCP 통신 연결하여 검증 결과를 수신받게 된다. 수신 결과는 'All True', 'TrueBlock', 'Genesis', 'restore' 4가지이다. All True와 Genesis는 각각 검증 결과 모두 True인 경우와 Genesis인 경우이므로 해당 사항을 문자열로 출력한다. TrueBlock인 경우에는 타 BC-IDS의 블록 복구가 필요한 상황이므로 블록을 읽어와 전달해주게 된다. restore는 타 BC-IDS로부터 블록을 수신받는 경우인데 자신의 BC-IDS의 블록 복구가 필요한 상황이므로 restoreBlockChain 함수를 통해 복구를 진행한다. 표 4는 실험에 사용한 블록체인의 구조이다.

4.1 Normal Operation

본 논문에서 제작한 BC-IDS가 정상적으로 동작하는지 확인하기 위하여 3대의 컴퓨터를 사용하였고 모두 같은 네트워크상에서 실험하였다. 각 3대의 컴퓨터는 게임과 BC-IDS에 포함된 Receiver_Send 프로세스와 Receiver 프로세스를 동작시킨다. 본 게임은 BC-IDS가 동작하면 실행되도록 제작하였기 때문에 BC-IDS를 실행한 후 게임을 실행하면 아래 그림 5와 같이 동작한다.

그림 5. 게임 & BC-IDS 실행

Fig. 5. Running Games & BC-IDS

4.1.1 Genesis Block

게임이 실행되고 처음으로 이벤트가 발생하였을 경우 BC-IDS에서는 Genesis 블록을 생성한다. 해당 블록은 index와 prevHash는 초기화되어 사용자마다 같은 값을 같게 되고 이벤트가 발생한 시간, 현재 체력, 블록의 해시값을 포함한다. 만약 게임에서 2,955의 이름을 가진 사용자가 체력이 100에서 50으로 떨어지는 이벤트가 처음으로 발생하였을 경우 Receiver_Send 프로세스에서 체력들을 해시값으로 변환하고 index는 0, prevHash는 아무런 값이 입력되지 않고 블록이 생성된다. 생성된 블록은 Receiver 프로세스로 전송되며 전송된 블록은 해시값이 맞는지 확인하고 맞으면 Genesis라는 값을 Receiver_Send 프로세스로 전송한다. Receiver_Send는 게임을 이용 중인 모든 사용자 중 51%가 넘는 사용자가 Genesis라는 값을 전송해오면 해당 블록은 문제가 없다고 판단하여 Receiver 프로세스에 블록을 저장해도 된다고 신호를 준다. 신호를 받은 Receiver 프로세스는 블록을 블록체인에 저장한다. 아래 그림 6은 PoS 검증 절차이다.

그림 6. PoS 검증 알고리즘

Fig. 6. PoS Verification Algorithm

4.1.2 Etc Block

전체적인 구조는 위 Genesis Block을 생성할 때 비슷하지만 프로세스별 함수가 하는 동작들이 세부적으로 추가가 된다. 먼저 블록 생성 부분은 prevHash에는 전 블록의 해시값, index는 전 블록의 1이 더해진 값이 저장되고 이 외의 내용은 같다. 다음으로 Compare Block 함수는 전송받은 블록과 블록체인에서 마지막 블록을 가져와 두 블록을 대조한다. 아래 그림 7에 자세한 코드가 첨부되어 있다.

그림 7. 블록 비교 함수

Fig. 7. Compare Block Function

4.2 Abnormal Operation

만약 위와 같이 정상적인 동작하던 도중 공격자가 Cheat Engine과 같은 공격 도구를 이용하여 2,955의 이름을 가진 사용자가 게임을 공격하여 체력이 100에서 50이 되어야 하지만 500에서 450이 되었을 경우 BC-IDS에서 블록을 생성하긴 하지만 Compare Block 함수에서 검증되어 공격당했다는 False 신호를 보낸다. Blockchain에는 기존 체력인 100이 해시값으로 변한 값이 저장되어 있다. 우선 Compare Block 함수에서 공격당하여 기존 체력을 500으로 변환한 해시값과 100에 해당하는 해시값이 비교하게 되므로 일차적으로 감지하게 되고 만약 감지하지 못했다고 하면 현재 체력도 비교하여 감지한다.

감지당하게 되면 해당 BC-IDS만의 통신오류인지 블록이 공격당했는지 판별하기 위해 해당 신호를 2,955 사용자에게 전송하게 되고 2,955 사용자의 BC-IDS는 받은 신호를 개표하여 블록이 공격받았다는 것을 판별한다. 이렇게 판별된 직후 BC-IDS는 게임에 공격을 받았다는 신호를 전송하여 즉시 게임을 종료시킨다.