게임 해킹을 막는 보안 전략

 

게임 해킹을 막는 보안 전략 

 

온라인 게임을 지켜라!

 

게임 해킹을 막는 보안 전략

 

이른바 ‘핵’을 사용하는 많은 유저들 때문에 게임 밸런스가 파괴되며 매크로 범람으로 인해 게임 서버 부하가 늘어나게 된다. 또한 늘어나는 게임 해킹 툴 탓에 상용 서비스가 늦어지고 ‘핵 천지’ 게임이라는 오명에서 벗어나기가 어렵다. 게임 서비스에 치명타를 주는 온라인 게임 해킹은 어떤 식으로 대응할 수 있을지 현재의 동향과 그 보안 전략을 통해 살펴보자.

 

온라인 게임 해킹/보안에 관한 글이 소개될 때는 항상 시작되는 서두가 있다. 우리나라의 온라인 게임은 양질로 급부상했으며, 아이템이나 게임머니들이 실제의 현금성 가치로 이어지면서 온라인 게임 분야에도 해킹 분야가 범람하고 있다는 사실을 환기하는 것이 그 내용이다.

 

이제 온라인 게임 해킹에 대한 인식은 충분하다

 

하지만 이제 이런 프롤로그를 작성할 시기는 지났다고 생각한다. 지금은 인식이 많이 넓어져 온라인 게임 해킹이라는 것에 대해 대부분 사람들이 인지하고 있으며 게임 개발자 치고 게임 핵에 당해 보지 않은 개발자가 거의 없다고 해도 과언이 아니다. 따라서 이젠 온라인 게임 해킹에 대한 콘텐츠를 구성할 때 게임 해킹에 대한 이해를 돕기 위해 그 개념을 풀어 설명하는 과정은 더 이상 필요 없다고 필자는 생각한다. 이제 온라인 게임 해킹도 웹 해킹이나 시스템 해킹처럼 그 분야와 목적성이 사람들 사이에서 뚜렷하게 밝혀져 있으며 이미 기반도 많이 닦여 있는 상황이다. 따라서 이제 개발자들은 온라인 게임 해킹에는 어떤 것이 있고 어떻게 이뤄지는가 등의 내용보다는 어떻게 대응해야 하고 어떤 처리 방법을 고려할 수 있을까에 더 주목하고 있는 편이다.

 

해킹 소개에는 대응 방법이 반드시 뒤따라야 한다

 

수많은 온라인 게임 해킹 소개에 있어서 필자가 가장 아쉬웠던 점은 콘텐츠 구성에 있어서 해킹 그 자체의 내용에만 중심을 두고 그 대응 방법은 거의 언급하지 않는다거나 아니면 결국에는 특정 솔루션의 홍보로 이어지는 내용이 많았다는 것이다.

모의해킹 업무를 오래도록 해온 사람들이 일차적으로 직시하고 있는 자세가 있다. ‘모의해킹의 목적은 해킹의 근본적인 차단에 있다’라는 것이다. 따라서 해킹을 통해 현재 시스템의 취약점을 발견했으면, 그에 대한 대응법도 당연히 거론해 주어야 하는 것이 보안 컨설턴트의 가장 기본적인 의무임은 당연하다. 그러나 온라인 게임 해킹은 그러한 해킹/보안 컨설팅의 기본적 절차가 무시되는 경우가 많으며 게임이 치트 당하는 그 모습에만 포인트를 두어 보여주는 사례가 적지 않다. 물론 이 방법은 사람들의 이목을 꽤나 쉽게 끄는 편이다. 일차적으로 게임 해킹이라는 해킹의 희귀 분야를 선보이고 있고 또 게임이 치트 당하는 모습은 벽을 타고 날아다닌다거나 총알이 무한대로 떨어지지 않는다거나 하는 누가 봐도 진기한 광경들이 많기 때문이다

하지만 필자는 이러한 형식의 PT는 별로 가치가 없다고 생각한다. 이미 수많은 게임 개발자들은 게임을 서비스하면서 다양한 핵을 경험해 보았다. 뿐만 아니라 게임 보안 컨설팅을 받거나 세미나에 참석하는 이유는 그런 해킹을 몰라서가 아니라 그런 해킹에 어떤 식으로 대응해야 하는지에 대한 노하우가 필요해서다. 필자가 생각하기에 그냥 단순히 게임 해킹 광경을 보여주는 식의 세미나는 초등학생이 인터넷에서 게임 핵을 검색해 나온 것을 튜토리얼 대로 따라해 보고 사람들 앞에서 실행해 보여주는 것과 다를 바 없다고 생각한다.

물론 몇 년 전까지는 그런 것을 보여주는 것 자체가 신기한 때도 있었다. 하지만 지금은 아니다. 이 해킹은 어떻게 차단하는지 그리고 우리 게임에선 어떤 로직이 필요한지가 더 관건인 세상이다. 따라서 온라인 게임 해킹도 제대로 된 PT의 수순을 밟고 컨설팅으로서의 가치를 발휘하려면 단순히 해킹 소개에만 그치는 것이 아니라 그에 대한 대응 방법도 반드시 뒤를 이어 제시되어야 한다.

 

증가 추세 1 - 가장 문제가 되는 치트 엔진

 

게임 보안에 있어서의 로직을 설명하기에 앞서 현재 게임 핵의 동향을 먼저 살펴볼 필요가 있다. 메모리 핵이나 패킷 핵, 조준 핵(Aimbot) 등에 대한 분류는 이제 인터넷에 많이 공개되어 있으므로 그 분류를 다시 섭렵하는 것은 서론에서 얘기한 것처럼 시대에 뒤떨어진 브리핑이 될 것이다. 그러므로 그런 핵들이 요즘은 어떤 동향으로 흘러가고 있는지를 파악할 수 있도록 증가 추세와 감소 추세에 대해 살펴보자. 먼저 누구나 가장 많이 증가하고 있다고 입을 모을 만한 핵으로 치트 엔진(Cheat Engine)을 들 수 있다.

 

<화면1> 게임 해킹 툴의 완성작이라고 할 수 있는 치트 엔진

치트 엔진은 예전의 티서치(T-Search)라는 메모리 에디터의 업그레이드판이라고 생각할 수 있다(물론 개발자는 다르다). 치트 엔진의 개발자는 다크바이트(Dark Byte)라는 네덜란드 태생의 시스템 개발자이다. 치트 엔진은 그 훌륭한 기능도 기능이지만, 아무래도 가장 큰 심각성은 소스가 오픈되어 있다는 것에 있다. 초반에는 빌드한 바이너리만 공개했으나 게임 보안 솔루션과의 잦은 차단 패치로 인해 전 세계 해커들과 함께 우회 방법을 논의할 수 있도록 소스를 공개한 것으로 보인다. 그리고 그 효과는 컸다. 오픈소스 이후에 수백 종 이상의 게임 보안 솔루션 바이패스 버전이 등장했으며 게임 보안 솔루션의 패치 속도보다 더 빠른 업그레이드 속도를 보여주고 있다.

필자가 게임 보안 솔루션 개발 업무를 하고 있었을 때 동료들과 하던 얘기가 있었다. “우리는 몇 명이서 막고 있는데 치트 엔진은 전 세계에서 뚫고 있다.” 그만큼 치트 엔진은 오픈소스라는 강점에 힘입어 여러 해커들의 아이디어가 모여 만들어진 게임 해킹의 완성작이라고 표현할 수 있다. 치트 엔진은 현재 온라인 게임 핵들 가운데 가장 심각하다. 이는 주로 로컬 메모리에 대한 의존도가 높은 캐주얼 게임에 많이 악용되고 있다.

 

증가 추세 2 - 하드웨어 매크로

 

다음으로 증가 추세가 뚜렷한 것은 하드웨어 매크로이다. 하드웨어 매크로 역시 게임 보안 솔루션들이 잦은 매크로 차단 패치를 수행하자 그것을 피하기 위해 매크로 아이디어를 USB 장치로 옮겨 개발한 핵이다. 본래 게임 해킹 문화 초창기에도 하드웨어 매크로는 존재했으나 가격이 비싸고, 또 소프트웨어에서 API로 구현한 것보다는 크리티컬한 움직임이 가능하지 않았던 탓에 대중적이지는 않았다.

하지만 장비의 단가가 저렴해지고 하드웨어 매크로 개발에 대한 연구가 더욱 심층적으로 이뤄지면서 현재는 소프트웨어에서 구현한 매크로보다 더 훌륭하게 자동 사냥을 할 수 있도록 만들어지고 있다. 더욱 심각한 것은 이런 부류들이 인터넷 쇼핑몰에서 버젓이 정식 상품으로 판매되고 있다는 것이다. 이런 것들을 대응할 때, 매크로 세팅을 위해 애플리케이션이 있는 경우는 그 바이너리를 시그니처로 차단하기도 하지만, 심각한 경우에는 어떠한 프로그램도 없이 키보드나 마우스처럼 USB를 컴퓨터에 꽂기만 하면 바로 동작하는 것도 있다.

 

MMORPG가 조금만 인기를 끌고 동시접속자수가 늘어나 아이템의 상품가치가 높아지면 그 게임에 대한 하드웨어 매크로는 거의 100% 등장한다고 생각하면 된다.

<화면2> 하드웨어 매크로

증가 추세 3 - 논 클라이언트

 

논 클라이언트는 게임을 설치 및 실행하지 않고도 게임을 할 수 있는 핵을 말한다. <화면 3>과 같은 UI를 가진 프로그램을 하나 실행하면, 이 프로그램이 실제 게임 서버에 접속해 로그인도 하고 자동 사냥까지 해주는 등의 황당한 핵이다. 게임 클라이언트에 아무리 보안 코드를 집어넣어도 게임 클라이언트 자체가 가동되지 않으므로 무용지물이 되어 버리는, 게임 개발자들의 전의를 상실케 하는 핵이다. 심지어는 자동 사냥 방지 시스템으로 만든 GM의 질문에 자동으로 응답까지 해주기도 한다.

논 클라이언트는 소스가 없는 상태에서 이론적으로는 절대 개발이 불가능하지만, 실제로는 게임 클라이언트의 바이너리를 뜯어 붙이는 코드 시뮬레이트 기법이나 네트워크 프로토콜을 분석해 패킷 구조를 실제 게임 클라이언트와 똑같이 구성해 주는 방식으로 개발되고 있다(혹은 서버 바이너리가 유출되면 100% 개발된다). 여담으로 나오는 얘기인데, 논 클라이언트는 현재 매우 많은 게임을 대상으로 등장해 있는 상황인데, 실제로 그 핵 툴을 다 입수해 보면 인터페이스는 거의 일치하는 편이다. 즉 논 클라이언트를 만드는 해킹 개발 집단은 동일 그룹이라는 소문이 있다.

 

<화면3> 논 클라이언트

증가 추세 4 - 게임 보안 솔루션 공격

 

다음으로는 게임 보안 솔루션을 직접 공격하는 사례들이다. 예전에는 솔루션을 직접 공격하기보다는 솔루션이 적용된 몸체에서 솔루션을 호출하는 부분을 걷어내고 보안 모듈이 아예 뜨지 않게 하는 쪽으로 핵이 개발되거나 아니면 보안 솔루션이 감지하지 못하는 기법을 알아내어 해킹하는 쪽이 대세였다. 하지만 최근에는 웬만한 메모리 크래킹은 보안 모듈에서 거의 일임하고 있으므로 보안 홀이 거의 없어진 상황이라 아예 보안 모듈 자체를 무력화시키는 방법을 많이 사용하고 있다. 즉 분석의 대상이 게임 클라이언트에서 보안 솔루션으로 옮겨가고 있다. 게임 보안 솔루션은 주요 기술을 커널 단에서 사용하고 있으므로 이를 우회하기 위해 게임 핵도 커널 레벨로 내려가서 코드를 가동시키고 있다.

 

<화면4> 게임 보안 솔루션 무력화

감소하는 ring3의 해킹 툴

다음으로는 감소 추세의 핵들을 알아 보자. 앞서 간단히 거론되었던 TSearch는 치트 엔진의 기세에 밀릴 뿐 아니라 게임 보안 솔루션에 거의 완벽히 차단되고 있기 때문에 요즈음 그 입지를 잃어가고 있다. 마찬가지로 TMK(Trainer Maker Kit)로 제작한 메모리 치팅 툴 역시 OpenProcess/WriteProcessMemory가 그 제작의 원리이므로 이 역시 현재에는 거의 쓰이고 있지 않다. 유저 레벨에서 send/recv를 후킹하는 원리인 WPE도 마찬가지이다.

그리고 mouse_event()나 PostMessage() 등을 이용한 매크로도 감소 추세이다. 이처럼 과거에 API로 쉽게 구현할 수 있던 핵들은 모조리 감소되는 모습이다. 게임 보안 솔루션이 ring3에서는 나름 보호 대책이 되고 있다는 반증이기도 하다. 하지만 그 대신에 앞서 언급했다시피 해킹 툴은 대부분 커널 레벨로 내려가고 있으며 구현 수준 역시 높아지고 있다. 전체적으로 게임 해킹 툴이 유저 레벨에서 커널 레벨로 변환하는 시점이라 생각할 수 있다.

 

 

<화면5> 요즘은 거의 사용되고 있지 않은 WPE

 

게임 보안 솔루션과 게임 로직 보호는 서로 다른 영역

 

지금까지 현재의 게임 핵 증감 추세를 통해 그 동향을 살펴봤다. 온라인 게임 해킹 보안이라고 하면 뭉뚱그려서 생각할 수도 있겠지만, 이쪽 분야는 엄연히 안티 크래킹(Anti-Cracking)의 성격이 기본적인 형태를 지니고 있다. 따라서 별도의 솔루션이 필요하며 그 솔루션의 역할을 현재는 보안회사에서 책임지고 있다.

예를 들어 메모리를 보호하기 위해 API Hooking을 한다던가, ring0에서의 컨트롤을 위해 커널 드라이버를 설치한다던가 하는 것이 그것이다. 게임 회사에서는 이러한 것에 관여할 필요가 없다. 굳이 이해할 필요도 없고 필요할 때마다 보안회사의 라이브러리를 이용한다던가 엔진을 구매해 사용하면 된다(게임 개발하기에도 바쁜데 이러한 것까지 일일이 신경 써야 한다면 게임 개발자들은 영원히 잠을 못 잘지도 모른다).

대신에 게임을 개발하는 입장에서는 보안 솔루션으로 처리해 주지 못하는 내부 보안 로직이 필수적이다. 예를 들어 패킷을 암호화한다던가 시퀀스 넘버링을 체크하는 것이다. 그리고 메모리 몇 바이트를 고쳐서 캐릭터의 능력치가 엄청나게 성장하는 취약점 등을 보강하기 위한 노력도 이것에 포함된다. 혹은 매크로 차단을 위해 게임 내부 기획 이벤트 등도 거론될 수 있다. 따라서 두 영역은 엄연히 서로 다른 영역이며 보안 처리도 대응 방법도 완전히 별개의 내용이다. 괜히 치트 엔진을 차단하기 위해 치트 엔진의 시그니처를 게임 바이너리에 넣어 놓고 주기적 스캔을 하는 루틴을 개발하는 게임회사도 있곤 한데, 그런 것은 무의미한 작업이다(치트 엔진이 스텔스 모드를 사용하면 유저 레벨에서는 치트 엔진의 존재를 감지할 수도 없기 때문).

따라서 그러한 것들은 그냥 게임 보안 솔루션에 맡겨버리면 된다. 그리고 내부 로직 강화에 더욱 신경 써야 한다. 요약하면 게임 보안 솔루션은 시스템 프로그래밍, 안티 리버싱 프로그래밍의 성격이라 말할 수 있고, 게임 로직 보호는 안정된 네트워크 프로그래밍이나 메모리 사용의 지능화 정도로 구분할 수 있다. 게임 해킹이 해킹 트렌드에 있어 어엿한 하나의 해킹 파트가 된 요즈음은 하나의 영역만 설명하기에도 내용이 아주 방대해진 편이다. 따라서 이 글에서는 게임 보안 솔루션에 대한 내용은 생략하고 게임 개발자를 위한 내부 로직 보강을 위주로 언급하도록 하겠다.

 

무결성 검사

 

게임 EXE 바이너리와 DLL 파일은 해커들의 주공격 대상이다. 가장 많이 당하는 해킹은 역시 EXE나 DLL의 코드 섹션을 변조하는 행위이다. 따라서 개발자가 게임의 질서를 위해 범위를 정해 놓은 수치를 해커들이 마음대로 변경해 게임을 엉망으로 만드는 행위를 방지해야 한다. 여기서 쓰이는 것이 CRC 검사나 체크섬 등의 무결성 검사이다. 코드 변조 그 자체를 막을 수는 없으니, 대신에 변조하면 감지하겠다는 개념이다. 다만 무결성 검사는 간단한 체크섬으로 구현하거나 CRC32 알고리즘을 이용하는데, 웬만한 무결성 검사는 해커들에게 우회가 가능하다. 예를 들어 <화면 6>과 같은 코드가 있다.

 

 

<화면6> CRC 검사 루틴

0x4022A9 번지를 보면 call 문이 보이고 push 문이 위에 2개 등장하므로 인자 2개인 함수를 사용한다는 것을 알 수 있다. 그리고 그 함수가 끝난 뒤 ebx의 번지에 있는 값을 eax에 넣는데 이것을 sprintf로 기록하고 있다. 저 call 문이 CRC 값을 구하는 함수이고 결과 값은 포인터로 전달되며 그 번지가 ebx에 들어오는 것이다. 즉 그 루틴은 <리스트 1>과 같다.

 

<리스트 1> CRC 검사 루틴의 디컴파일

DWORD dwCrc = 0; GetCRC(szFileName, &dwCRC); sprintf(szTemp, "%X", dwCRC);

 

따라서 dwCRC에 해당하는 값을 조작하면 <리스트 1>의 CRC 검사는 무력화된다. ebx나 eax를 조작할 수도 있고, 저 루틴 자체를 점프시켜 뛰어넘을 수도 있다. 해커들은 이러한 방법들을 즐겨 이용한다.

이 외에도 CRC 연산 이후에 나온 값을 오리지널 값으로 동일하게 맞춰 준다던지, CRC 검사 영역을 코드 섹션이 아닌 다른 영역으로 속여서 그곳에는 정상 EXE를 덤프 떠 놓은 파일을 올려놓고 그 엉뚱한 영역을 검사하게 만드는 우회 기법도 있다. 게임 클라이언트의 코드를 변조하면 무결성 검사에 걸러져 버리므로, 먼저 무결성 검사 루틴부터 무력화시키는 작업을 하는 것이다. 게임 로직에서 직접 무결성 검사를 하는 것도 그렇고, 게임 보안 솔루션에서 해주는 것도 비슷하게 우회된다. 따라서 무결성 검사 루틴 자체는 쉽게 우회되지 않도록 강력하게 코딩해야 하며 많은 고민이 필요한 부분이다.

따라서 정교한 무결성 검사 기능을 구현하는 방법은 사실 한두 번의 노력으로 가능한 것이 아니다. 항상 새로운 해킹 툴이 등장하면 코드 섹션을 변조해야만 이러한 행위가 가능한지부터 소스를 통해 체크해 보고 무결성 검사 기능이 무력화 당했는지도 확인해 보아야 한다. 그리고 우회 당한 것이 맞다면 어떤 식으로 바이패스된 건지 그 구체적인 동작부터 체크해 봐야 대응 코드를 작성하는 데 더 큰 도움이 된다. 그래서 게임 회사에서는 게임 개발자가 직접 소스를 비교하며 리버스 엔지니어링을 하던지 리버싱 가능한 인력이 있는 내부 보안팀을 통해 분석하기도 한다.

 

패킷 암호화/시퀀스

 

더 이상 강조하면 이제 지겹다고 생각할 만큼 필수적인 요건이다. 예전에는 암호화를 하지 않은 패킷이 네트워크 상에 그대로 전송되는 경우가 많았지만, 몹 공격 패킷, 캐릭터 이동 패킷, 퀘스트 완료 패킷 등이 분석되어 이것이 자동 사냥 등으로 악용되는 경우가 빈번하게 발생했다. 따라서 패킷 암호화와 시퀀스 넘버링은 이제 개발자들 사이에서 필수적인 부분이 되었다. 암호화는 하면서도 시퀀스 넘버링 체크는 하지 않는 게임도 의외로 많은데, 시퀀스 체크를 생략하면 이는 패킷 리플라이 공격으로 이어진다.

예를 들어 한방 핵이나 퀘스트 완료 해킹 같은 것이 그것이다. 공격 패킷을 캡처링해서 계속 서버로 전송함으로써 한 번에 수십 수백 번 이상 공격한 것과 같은 효과를 낼 수 있다. 또 퀘스트가 완료되면 게임 서버로 퀘스트 완료 패킷이 날아가고, 게임 서버에서는 경험치 증가와 렙업 등을 처리하는데, 만약 퀘스트 완료 패킷도 캡처링하여 재사용이 가능하다면 해커들은 퀘스트 완료 패킷을 계속 서버로 전송할 것이다. 그러면 퀘스트를 완료하지 않았음에도 불구하고 계속해서 경험치가 늘어나게 된다(이 부분은 다음 파트인 서버 중심 설계 쪽에서 부연 설명한다).

따라서 통신을 할 때마다 서버와 클라이언트에서 각각 시퀀스 넘버를 부여해 서버에서 받은 패킷이 방금 클라이언트에서 만들어진 패킷인지 아니면 그전에 캡처링해 둔 예전 패킷이었는지 반드시 체크해야 한다. 하지만 시퀀스도 역시 평범한 숫자로 기록하면 무력화가 가능하므로 CRC 체크섬도 반드시 병행해야 한다.

서버 중심 설계

 

게임 설계를 할 때 반드시 숙지해야 할 사항은 ‘클라이언트는 절대로 믿지 않는다’이다. 클라이언트에서 전달된 패킷은 반드시 서버에서 정밀한 검증을 통해 다시 한 번 체크해 주어야 한다. 초창기에 네트워크 설계를 할 때는 서버 개발자와 클라이언트 개발자는 서로 약속된 패킷 이외의 값은 오지 않을 거라 생각하고 개발을 시작했다. 하지만 알 수 없는 패킷이 날아와 데이터를 마구 망가뜨렸고 급기야는 서버가 다운되는 현상까지 발생했다.

서버 다운 외에도 심각한 문제가 있는데, 클라이언트가 현재 어떤 기술이나 아이템을 사용할 수 없는 조건인데도 그런 기술을 사용할 수 있다는 것이다. 대표적인 것이 스킬 핵이다. 예를 들어 ‘아리랑’이라는 스킬이 있고 이 스킬은 마법사만이 사용할 수 있으며 렙이 20 이상이어야 한다는 조건이 있다고 가정하자.

그런데 렙이 20도 되지 않는 전사 캐릭터가 아리랑 스킬을 사용한다는 게임 해킹의 보고를 받게 된 것이다. 이유가 무엇일까? 게임 개발자가 이런 데이터의 범위를 검증하는 코드를 클라이언트에 남겨둔 치명적인 실수를 했기 때문이다. 해커들은 클라이언트의 그 코드를 점프해 해당 스킬을 날리거나, 아니면 미리 캡처해 둔 스킬 패킷을 계속 서버로 전송하는 방식을 이용한 것이다.

이런 해킹을 막기 위해 서버에서의 현재 클라이언트 각종 상황에 대한 점검 조건은 필수적이다. 서버는 아리랑 스킬을 받았을 때 클라이언트의 각종 조건을 면밀하게 검토해 본 후 패킷이 날아올 수 없는 상황에서 전송된 것이라면 이를 거부해야 한다. 이것이 바로 게임 서버 개발의 기본이다. 물론 쉽지 않은 작업이며 캐주얼 게임 은 경우는 퍼포먼스를 위해 어쩔 수 없이 클라이언트에 이런 코드를 많이 넣을 수밖에 없는 것이 현실이다. 하지만 그래도 해킹을 최소화시키기 위해 중요한 값들이나 주요 검증 코드는 반드시 서버에서 수행해 주어야 하며, 특히 MMORPG 같은 경우는 그런 자세가 더욱 필수적이다. 이런 규칙을 지키지 않고 게임 개발을 하게 되면 게임 핵이 많이 발생하게 된다.

그리고 치트 엔진이 범람하는 게임들은 대부분 클라이언트에 주요 코드가 많이 부가되어 이런 취약점이 있는 게임이라고 보면 된다. 서버 사이드로 개발되면 치트 엔진 같은 것을 사용해도 내 PC에서 보이는 값만 바뀔 뿐, 서버가 가지고 있는 실 데이터는 그대로이므로 해킹 자체가 무의미하다. 예를 들어 리니지 같은 게임은 철저히 서버 사이드 단에서 개발되었기 때문에 웬만한 데이터는 다 서버가 가지고 있고 클라이언트는 거의 UI만 존재하는 편이다. 즉 몸뚱아리만 덩그러니 있는 상태로 본다 해도 아주 틀린 얘기는 아니다. 따라서 리니지에는 치트 엔진 같은 메모리 해킹 툴이 거의 사용되지 않는 편이다.

 

<화면7>암호화되지 않은 패킷이 해커에게 분석되어 개발된 핵

물론 이렇게 개발한다고 해서 모든 해킹이 다 근절되는 것은 아니지만, 치트 엔진이나 메모리 번지로 장난치는 해킹 행위는 상당수 예방할 수 있다. 따라서 클라이언트를 믿지 말고 게임 서버에서 각종 데이터를 검증할 수 있는 시스템이 되어야 하며, 게임 중에는 언제나 임의의 패킷이 올 수 있다는 가정에 대비해야 한다.

 

파일 암호화

 

요즈음은 리버스 엔지니어링 기술이 무척 발달해서 EXE나 DLL 파일의 경우 파일 암호화(프로텍팅/패킹)를 하지 않으면 치명적이다. 상당수의 게임 개발자들이 이 부분을 간과하며 그냥 넘어가는 경우가 많다. 물론 파일 암호화를 통해 모든 해킹을 예방할 수 있는 것은 아니지만 이는 기본적으로 처리해야 될 일차적인 과제라고 생각하며 수행하기를 권한다. 개발자들이 생각하기에 바이너리 암호화 툴을 이용해 패킹을 해도 어차피 메모리에 풀리면 다 보이니 마찬가지라고 생각하며 패킹하지 않는 경우도 있다, 물론 메모리 상에서 풀리는 것은 맞다. 하지만 메모리 상에서 변조하는 것 외에 파일을 미리 고쳐 놓고 실행하는 해킹도 매우 많으므로 그 부분에 대응하기 위한 파일 암호화는 필수적이다.

파일 암호화 작업을 거치면 해당 파일을 완벽히 언패킹하지 않는 한, 파일 상에서 고친 후 실행하는 해킹은 100% 막을 수 있다. S급 리버스 엔지니어들에게는 빌드 상태 그대로의 깔끔한 바이너리는 소스 수준으로 컨버팅할 수 있는 능력이 있다. 따라서 빌드 상태 그대로 배포해 중국 등에 나가게 되면 S급 해커들에게는 소스를 준 것과 별반 차이가 없어진다. 믿겨지지 않겠지만 사실이다. 당해본 사람들은 알고 있다.

 

<화면8> 현존 최강의 프로텍터로 알려져 있는 Themida

 

매크로 방지

 

매크로는 게임 개발사가 대응하기에 가장 어려운 해킹이 아닐까 싶다. 소프트웨어적으로 구현하는 매크로는 개발 로직 자체가 검증 루틴이나 패킷 처리 지침으로 해결하는 것이 불가능하다. 따라서 기본적으로는 게임 보안 솔루션에 의지하되, 게임 로직으로는 게임 내부의 매크로 동향을 파악해 기획적으로 대응 방법을 강구하는 방향으로 진행하는 편이 일반적이다. 대표적인 것이 오토플레이 신고제이다. 사실 매크로를 사용하고 있는 유저들은 조금만 살펴봐도 티가 크게 나는 편이다. 따라서 이 방법은 게임 내부에서 유저들이 직접 신고하는 시스템을 구축하는 형태이다. 현재 여러 게임에서 사용하고 있으며 나름 효과가 있는 것으로 알려져 있다.

 

<화면9> 클린패드

 

그리고 매크로가 사람 없이 계속 플레이된다는 점에 착안해, 무언가 수동으로 입력받는 화면을 내보이는 시스템이다. 던전 앤 파이터의 클린패드 같은 것이 그 좋은 예이다. 그 외에도 매크로 차단 기획을 위한 많은 아이디어가 있다. 예를 들어 사냥터 중간에 절대 건드리면 안 되는 몹을 하나씩 배치한다든가(매크로 이용자는 그 몹을 건드리게 되어 죽음에 이르게 된다), 오토 이용자로 100% 확정될 경우에 가지고 있는 아이템을 한 번에 모두 떨어뜨리도록 만들어 버리는 아이디어도 생각할 수 있다.

 

스피드 핵

 

스피드 핵은 현존하는 대부분의 형태가 타이머 API를 후킹한다는 점에 착안해 게임 보안 솔루션이 그 부분을 체크함으로써 나름 효과적으로 방어가 이뤄지고 있다. 하지만 게임 보안 솔루션을 통째로 걷어내는 해킹도 많이 존재하고 있으므로 근원적으로는 게임 서버와 클라이언트의 시간 동기화로 걷어내야 하는 작업이 필수적이다. 게임 서버는 10초밖에 시간이 흐르지 않았는데 클라이언트에선 1분 이상 흘렀다면 그 경우는 스피드핵 사용 말고는 그 이유가 없으므로 과감히 클라이언트의 접속을 해제시켜야 한다.

 

문자열 암호화

 

문자열은 상수 영역에 그대로 남기 때문에 메모리 상에서 쉽게 보이게 된다. 그리고 디버거나 디스어셈블러로 뜯어보았을 때 문자열이 사용되는 위치까지 친절히 알려주므로 이것이 곧 해킹의 일차적인 근간이 되곤 한다. 따라서 중요 문자열은 반드시 암호화하는 작업이 필요하다. 대부분의 게임 개발자들은 코드 가독성이 떨어지고 일일이 다 암호화하기가 귀찮기 때문에 이 부분을 간과하고 그냥 넘어가곤 하는데 문자열 암호화로 인한 안티 리버싱 효과는 매우 크다는 것을 염두에 둬야 한다.

 

DLL의 익스포트 함수 보호

 

DLL의 익스포트 함수는 외부에서 읽어 들여야 하기 때문에 역시 스트링이 그대로 노출되어 있다. 예를 들어 어떤 게임에서는 AttackRange()라는 함수명이 그대로 노출되어 있었고 해커들은 그 함수를 공격해 공격의 범위를 마구 수정하곤 했다. 이 기능은 비주얼 스튜디오의 DEF 기능을 이용하면 쉽고 간단하게 암호화할 수 있다. 방법은 다음과 같다. <화면 11>처럼 소스 파일과 동일한 이름으로 .def 파일을 작성한다. EXPORT에 함수 이름을 넣고 @1 @2처럼 함수 개수대로 순번을 붙여준다. 그리고 빌드한 후 디펜던시 워커로 확인해 보면 DLL 이름이 N/A로 표기된 것을 알 수 있다. 이름이 외부에 공개되지 않으므로 해커들이 타깃을 잡기가 어렵게 된다.

 

<화면10> 스트링은 해커들에게 분석을 위한 소중한 힌트가 된다

 

그렇다면 이름이 보이지 않으니 GetProcAddress()를 할 때에는 어떻게 해야 하는지 그 방법이 궁금해진다. 그것 역시 간단하다. MAKELONG() 매크로 함수를 이용해 Ordinal로 얻어오면 끝이다. <리스트 2>를 살펴보면 충분히 이해할 수 있을 것이다.

 

게임 보안은 한두 번의 보안 조치로 해결되지 않는다

 

이곳에 언급된 내용은 하나의 가이드라인일 뿐이지, 게임 해킹 대응의 전부가 아니다. 누락된 해킹 기법이 여전히 많다. 지면적인 제약으로 거론된 내용의 풀 코드를 제공하지 못한 아쉬움도 있고 개론적인 설명에 그친 내용도 있었다.

 

<리스트 2> MAKELONG() 이용하기

typedef DWORD (*INITMYENGINE); typedef DWORD (*RUNENGINE); INITMYENGINE fnInitMyEngine; RUNENGINE fnRunEngine; HINSTANCE hDllsample = LoadLibrary(szDllPath); if (hDllSample) { fnInitMyEngine = (INITMYENGINE)GetProcAddress(hDllSample, (LPCSTR)MAKELONG(1, 0)); fnRunEngine = (RUNENGINE)GetProcAddress(hDllSample, (LPCSTR)MAKELONG(2, 0)); }

 

또한 게임 보안 솔루션의 영역은 거론하지 않았다. 게임 보안 영역은 시스템 프로그래밍과 네트워크 프로그래밍, 그리고 암호화 프로그래밍, 게임 프로그래밍, 리버스 엔지니어링 등 IT 기술의 각종 분야가 종합적으로 축약된 분야라고 생각된다.

 

<화면11> DEF 파일

따라서 현재의 그 방대한 기법에도 모자라 아직도 새로이 공개되고 있는 해킹 툴의 알고리즘을 보면 혀를 내두를 때가 많다. 따라서 한두 번의 컨설팅으로 모든 해킹이 다 근절된다는 생각을 버리고 사내의 보안 담당자와 협의해 해킹 툴을 끊임없이 입수 및 분석해 새로운 대응 방법을 생각해 나가야 한다. 또한 게임 보안 솔루션의 사용도 필수적이다. 전문 보안 업체와의 협업도 반드시 필요한 부분이라고 생각한다.

 

 

Interview “보안 솔루션 도입으로 정보보호 습관화해야” 시만텍코리아 시스템 엔지니어링 본부 윤광택 팀장   웹2.0 시대에 가장 두드러지는 보안 위협의 형태는 무엇인가? 이용자 참여를 강조하는 웹2.0 서비스들이 대부분 이용자들 간의 신뢰를 바탕으로 하고 있는 만큼 최근의 보안 위협은 이런 신뢰에 허를 찌르는 형태로 만들어지고 있다. 종전의 보안 위협이 이용자를 따라다니는 형태였다면 현재의 보안 위협은 사용자들이 안심하고 방문하는 웹서비스에 ‘그물'을 쳐놓고 이용자들의 개인 정보를 노리는 형태로 만들어지고 있다. 다시 말해 보안 위협의 형태는 이전과 크게 다르지 않지만 보안 위협이 경유하거나 감염시키는 경로에 큰 변화가 생긴 것이다.   내부자를 대상으로 하는 정보 보호의 필요성이 나날이 커지고 있는데…. 현실적으로 기업이 가진 모든 정보를 보호하는 것은 불가능하다. 따라서 일상적이면서 보편적인 데이터는 보안 제품의 관리에서 제외하고, 기밀정보로 등록된 데이터만 집중적으로 관리하는 메커니즘이 내부적인 정보 보호를 실현하는 가장 실질적인 수단으로 평가되고 있다. 실제로 핵심 데이터의 열람이나 이동을 철저히 감시함으로써 혹 있을지 모르는 대부분의 유출 시도를 막을 수 있다. 또한 이런 솔루션의 도움을 받아 구성원의 보안 의식을 점차 트레이닝하면 머지않아 보안의 습관화가 가능하다는 점에 우리는 주목해야 한다.   익스플로러 새 버전과 구글의 ‘크롬' 출시 등으로 보안적 대응이 요구되는 웹 브라우저의 수가 늘었는데…. 새로운 웹 브라우저가 이용자의 호응을 얻어 점유율을 높이면 그 브라우저를 타깃으로 하는 위협이 증가할 것이므로 보안 벤더의 입장에서는 대비해야 할 사항들이 크게 늘어난다. 하지만 어떤 웹 브라우저를 사용하든 유저들이 느끼는 보안 위협의 정도는 비슷할 것이다. 웹 브라우저의 종류가 늘어나더라도 대부분의 경우 하나의 브라우저를 주력으로 사용하게 될 것이므로 선택하지 않은 브라우저상의 보안 위협은 이용자와 무관하기 때문이다.   Mpack이나 피싱 툴킷과 같은 보안 위협 툴킷의 동향은 어떠한가? 바이러스와 같은 하나의 보안 위협을 탐지하면 수일 내에 동일한 패턴을 가진 새로운 변종 바이러스가 여러 개 출현하곤 한다. 그런 보안 위협을 분석해 보면 똑같은 디렉토리 구조와 개더링(gathering) 형태를 가져 특정한 툴킷에 의해 생산된 것임을 추측할 수 있다. 경우에 따라서는 우리나라에서만 활동하는 변종도 생성되고, 심지어는 특정 기업만을 타깃으로 만들어진 변종도 탐지되고 있다. 이런 툴킷으로 더 빠르고 더 최적화된 위협을 만들어 낼 수 있다는 점에서 툴킷은 위협적이다.

 

“대규모 정보 유출 사고로 DRM 수요 증가세” 파수닷컴 안혜연 부사장   기업용 문서보안(DRM) 솔루션의 개념과 원리를 설명한다면? DRM(Digital Rights Management)은 콘텐츠나 파일의 사용을 통제하는 기술로 허가된 사용자가 허용된 권한 범위 내에서만 콘텐츠를 사용할 수 있게 하는 기술이다. 일반적으로 비즈니스 문서를 보안하는 DRM 솔루션은 Enterprise DRM을 의미하며, 이는 전자문서를 암호화해 불법 유출을 방지함으로써 기업의 핵심 정보자산의 지속적인 보안을 제공한다. 메커니즘적으로 볼 때 DRM은 디지털 콘텐츠를 사용하기 위해 반드시 저작권자가 배포하는 라이선스를 발급받아야 한다는 개념을 기술적으로 보장하는 시스템이다.   문서보안에 대한 우리 기업들의 인식은 어느 정도 수준인가? 고객 개인정보 유출로 곤욕을 치르고 있는 기업들이 증가하면서, 과거 해킹과 바이러스 차단에만 치중하던 보안 시장이 데이터 및 콘텐츠와 같은 핵심 정보 유출 차단에 역점을 두는 방향으로 보안의 중심이 변화하고 있다. 지난 9월 16일 한국소프트웨어진흥원이 내놓은 ‘기술 및 정보유출 증가로 기업 DRM 시장 급성장'이라는 보고서에 보면 내부자에 의한 개인정보 유출 및 산업스파이에 의한 산업기술 유출 사례가 증가하면서 DRM-Free 추세로 다소 위축되었던 DRM 시장이 다시금 뚜렷한 성장세를 보이고 있다고 분석했다.   웹이나 시스템 인프라의 발전이 DRM에 미치는 영향은 무엇인가? 인터넷 응용프로그램 기술이 발전하고 웹서비스의 형태가 다양해짐에 따라, 참여와 공유 개념으로 진화하고 있는 개방형 웹 환경은 불법 정보 유출의 대표적인 통로가 되고 있다. 이에 권한에 따라 사용자의 웹 브라우저 사용이 제한되며 웹 콘텐츠의 복사, 저장, 인쇄 등의 기능을 제어함으로써 기업의 소중한 정보를 보호하는 DRM 솔루션 시장 역시 동반 상승세를 이어가는 추세이다.   앞으로의 내부정보 유출 방지 시장을 전망한다면? 현재까지 국내 DRM 시장은 2007년 기준으로 6,429억 원을 형성하고 있으며 2008년에는 1조4,614억 원 규모로 성장할 것으로 추정되고 있다. 이는 연간 성장률이 127.3%를 상회하는 추세로 기업용 문서보안 솔루션인 Enterprise DRM 시장과 멀티미디어 콘텐츠 저작권 보호 솔루션 시장인 Consumer DRM 시장을 합친 결과이다. DRM을 중심으로 한 내부정보 유출방지 시장은 FTA와 관련해 저작권보호법, 산업기술유출방지법, 개인정보보호법 등이 강화되고 정비되는 추세에 따라 관련 수요도 함께 증가할 것으로 전망된다. 향후 DRM 시장은 보안 환경 진단에서부터 솔루션 구축, 유지보수서비스까지 통합되는 통합 보안시스템으로의 연동이 주요 이슈가 될 것으로 예상되며 이미 성숙 단계에 진입한 대기업 시장을 넘어 중견중소기업 시장에까지 DRM에 대한 수요가 증가할 것으로 예상된다. 전도영 기자 mir@imaso.co.kr

 

 

필자소개

 

강병탁 window31@empal.com , www.window31.com｜

 

온라인 게임 보안 솔루션인 nProtect GameGuard 엔진 개발을 다년간 해왔다. Anti-Debugging / Anti-Cracking / 리버스 엔지니어링 / 시스템 프로그래밍 등이 주 관심사이다. 현재는 넥슨에서 보안 프로그래밍과 악성코드 분석, 게임 해킹 방지 등에 대해 연구하고 있다.