2010.09.26 00:58

개요: 해킹의 취약한 유형의 프로토콜이 무엇인지,  안전한 프로토콜을 작성하기 위한 전략엔 어떤 것이 있는지 소개합니다.
필독: X
조건: 패킷의 개념 정도만 이해하시면 됩니다
난이도: 하 

 *틀린 부분은 지적해주시면 바로 수정하겠습니다(코딩오류, 오타 등).
게임 핵을 만든다고 개설된 커뮤니티들에서는 이러한 이름의 익스플로이팅을 자주 볼 수 있습니다:

미스핵
강화핵
데미지핵
etc..


 말인즉 데미지를 받아도 항상 0으로 받고, 강화나 인챈트 등을 하면 무조건 성공하며, 상대에게 주는 데미지를 마음대로 수정할 수 있다는 것입니다.

 이런 종류의 취약점은 전에 작성하였던 해킹 방지 프로그래밍 기법 1 에서 사용하였던 방법대로  변수에 대한 메모리 접근 보호를 클라이언트 측에서 수행하여 방어할 수도 있습니다.

 하지만 이 방법은 100퍼센트 안전한 방법이라고 말할 수 없습니다. 리버싱에 불가능은 없다고 가정하는 것이 좋습니다. 해커가 충분한 노력과 시간을 들인다면 개발자가 제작한 게임이나 기타 어플리케이션의 기계어 코드와 리소스를 가지고 거의 똑같거나 완벽하게 똑같은 프로그램을 직접 작성하는 것도 아예 불가능하지는 않습니다. 또 이런 극단적인 상황에서 아무리 메모리 해킹에 대한 방어를 철저히 한다고 해도 소용은 없을 것입니다.

 가장 확실한 방법은 프로토콜 자체의 취약점을 없애는 것입니다. 개발자가 정말로 신용할 수 있는 모든 정보는 서버에 있습니다. 클라이언트가 어떤 정보를 보내오든, 그것을 바로 신용해서는 절대로 안됩니다.

 위에서 언급한 익스플로이팅 중 '데미지핵'에 대한 간략한 시나리오를 세워보자면 다음과 같습니다.

 개발자는 클라이언트가 몬스터에게 데미지를 입으면 그 데미지를 클라이언트가 계산하여 서버에 보낸다. 그리고 서버는 클라이언트가 보낸 데미지 정보를 토대로 몬스터의 체력을 깎는 등의 연산을 수행하는 구조이다.

 해커는 보호되어있는 '데미지 계산 루틴'을 찾아 입맛에 맞게 수정한다, 혹은 패킷을 보내는 루틴을 후킹하여 데미지 부분의 정보만 수정한다.

 서버는 클라이언트에게서 도착한 데미지 정보를 신용하고, 해커가 공격했던 무☆적의 보스몹은 짧은 인생을 마감하게된다.

 이러한 익스플로이팅이 가능한 이유는 서버가 클라이언트가 보낸 정보를 그대로 신용한다는 점에 있습니다. 하지만 데미지 연산에는 (아마)랜덤한 상수가 포함되어있을 것이고, 그 랜덤한 상수를 포함하였을때 가장 데미지가 큰 경우'를 가지고 서버 측에서 데미지를 검증하는 방법이 이 프로토콜을 사용하였을 때 가장 바람직한 방법입니다만, 그것 역시 문제가 있습니다.

 '해커는 무조건 최대데미지를 서버에 보낸다' 라는 상황이 발생할 수 있습니다.

 결국 개발자는 이러한 프로토콜 자체를 뜯어고쳐야 할 필요가 있습니다. 근본적인 원인은 클라이언트가 데미지의 수치를 계산할 수 있다는 점에 있습니다. 클라이언트가 데미지를 계산할 수 없는 프로토콜을 제작한다면 아무리 뛰어난 리버서라도 서버 내부에서 연산되는 데미지의 수치를 바꿀 수는 없습니다. 

 다음과 같은 프로토콜에는 이러한 익스플로이팅이 불가능합니다.

개발자는 클라이언트가 몬스터에게 데미지를 주었다는 사실만 서버에 알린다.

서버는 그 정보를 받아 들고 데미지를 알☆맞★게 계산하여 몬스터의 데미지를 깎아 내리고 데미지가 얼마인지 클라이언트에게 통보해줍니다.

 물론 모든 데미지의 수치를 서버가 계산해야 된다는 점에서 서버의 부하가 늘어나는 것은 어쩔 수 없습니다. 하지만 그러한 부하도 서버의 설계만 잘 해놓았다면 쉽게 줄일 수 있습니다.

 일반적으로 데미지를 계산할 때 필요한 상수는 쉽게 바뀌지 않습니다. 일단 클라이언트가 착용한 장비의 영향을 받을 것이고, 간혹 소지품의 영향을 받는 경우도 있을 것이고, 마법같은 시스템이 있다면 그것의 영향 역시 받을 수 있습니다.

 부하를 줄일 전략을 세워보자면 이렇습니다.

 데미지에 필요한 상수를 그 상수에 영향을 끼치는 요소(장비, 마법 등의 효과로 인하여)가 바뀔때마다 미리 계산해두고 랜덤한 상수의 범위를 계산해둡니다. 장비나 마법등에 의해 상태가 바뀌는 경우는 그렇게 많지 않습니다.

 하지만 이 두가지 정보만 계산해 두면 서버는 데미지를 아래와 같은 아주 단순한 방법으로 구할 수 있습니다.

Dmg  = 계산된고정상수 + rand() % 랜덤상수의최대값
 이정도 연산에서 생기는 부하가 아깝지는 않을 것입니다. 이제 개발자의 서버에서는 절대로 '데미지핵'과 같은 익스플로이팅이 불가능합니다.




 2편에서는 아마도 시간 계산에 관련된 익스플로이팅(공격속도, 스킬 쿨타임이나 '스피드핵' 유틸리티 등)에 관하여 포스팅하게 될 것 같습니다.
 졸리네요 바이바이 ><
Posted by 라이에
2010.09.25 15:41

개요: 메모리 해킹이 일반적으로 어떻게 이루어지는지, 또 그에대한 대처책을 소개합니다. 난이도는 '하'이므로 간단한 방법 위주로 설명합니다.

필독: 치트엔진을 사용한 핀볼 해킹 예시 1

조건: C언어 사용 가능 혹은 다른 언어로의 프로그래밍에 능숙

난이도: 하

 

 *틀린 부분은 지적해주시면 바로 수정하겠습니다(코딩오류, 오타 등).

 

 

 '치트엔진을 사용한 핀볼 해킹 예시 1 문서'를 읽었다는 가정하에 진행합니다.

 어플리케이션 (특히 게임) 개발자로서 위와 같은 간단한 방법으로 내 프로그램 내의 변수를 수정할 수 있다는 것은 상당히 위협적입니다.

 실제로 온라인 게임을 작성하는 개발자들도 위와같은 방식의 해킹 기법을 간과하고 프로그램을 작성하는 경우가 많아 안타깝습니다. 약간의 지식만 있어도 게임가드, 핵실드 등의 비싼 보안 솔루션을 사용하지 않아도 될텐데 말입니다.

 실제로 이런 방법을 사용해 게임 내의 체력과 딜레이 등의 정보를 수정하여 쉽게 해킹이 가능했던 온라인 게임들이 수 개월만에 서비스를 종료하게 된 사례도 있습니다.

 

 개발자 입장에서 구현 단계에서부터 설명하겠습니다.

 당신은 바람의나라와 같은 방식으로 진행되는(4방향으로 1칸씩 움직이는 시스템에 주목) 온라인 RPG 게임을 제작하는 개발자라고 가정합니다.

 지금은 개발 초기단계입니다. 당신은 클라이언트가 서버에 접속해 로그인 후에 맵 상에 돌아다니는 잉여 몬스터를 때릴 수 있도록 서버와 클라이언트 간의 프로토콜을 구현하였습니다. 구현된 프로토콜은 다음과 같습니다.

-> 클라이언트는 현재 자신의 장비와 몬스터의 방어력 등을 계산해 결과 총 데미지를 계산하고, 자신이 타격한 몬스터의 오브젝트 번호를 전송합니다.

 

<- 서버는 클라이언트가 보내준 정보를 그대로 받아 해당 오브젝트 번호의 몬스터에 해당 데미지를 주고, 이벤트를 발생시킵니다.

 현명한 개발자라면 이 프로토콜에 상당한 문제점이 있다는 것을 쉽게 눈치챕니다. 하지만 현업 게임 개발자는 실제로 프로토콜을 이런식으로 설계하는 경우가 허다합니다.

 이 프로토콜을 그대로 사용한다면 해커는 쉽게 다음과 같이 게임을 해킹할 수 있습니다.

 

1. 데미지에 영향을 주는 변수(장비 등)를 찾아 값을 수정해 서버에 전송되는 데미지를 증가시킬 수 있다.

 

2. 리버싱을 통해 몬스터가 아무리 멀리 떨어져 있어도 공격에 맞도록 한다. 서버는 오브젝트 번호만을 받아 유효성 검사 없이 무조건 처리하기 때문에 해커는 사정거리 제한 없이 몬스터에게 데미지를 줄 수 있다.

 *이 글은 프로토콜에 대하여 이야기 하는 것이 아니므로, 심화된 내용은 '게임 등의 어플리케이션 개발 시 바람직한 프로토콜 설계 1 문서'를 참고하여 주시기 바랍니다.

 

 '데미지에 영향을 주는 변수'에 포커스를 맞추어 봅시다.

 개발자는 데미지 계산 루틴을 다음과 같이 작성했습니다.

 int CalcDmg(~){

  int Calc = (User->무기->데미지 + DEFAULT_DMG) - Monster->방어력;

  return  Calc >= 0 ? Calc : 0 ;

 }

 데미지 변수에 대한 아무런 검사가 이루어지지 않는 상태입니다. 이상태에서 해커가 유저의 무기 데미지혹은 몬스터의 방어력을 수정하면 쉽게 데미지가 올라갈 것입니다. 가장 중요한 일은 스캔 혹은 메모리 수정을 어렵게 하거나 불가능하게 만드는 것입니다.

 이를 방지하기 위한 방법은 여러가지가 있습니다.

 

 1번째로 변수의 내용을 암호화해 스캔이 어렵도록 하는 방법이 있습니다. 해커는 반드시 수정할 변수를 찾아야 합니다. 찾는 과정을 어렵게 만들고, 찾은 후에도 값의 수정을 어렵도록 만드는 원리입니다.

 아래는 간단한 암호화를 적용한 뒤의 코드입니다.

 void InitWeapons(){

  int i;

  for(i=0; i < WEAPONNUM ; i++){

    무기[i].데미지 = 10 ^ 0x12345678; // xor을 이용한 간단한 암호화

  }

 }

 

 int CalcDmg(~){

  int Calc = ((User->무기->데미지 ^ 0x12345678) + DEFAULT_DMG) - Monster->방어력;

  return  Calc >= 0 ? Calc : 0 ;

 }

 

 이 방법을 사용하면 무기의 데미지가 암호화되었으므로 스캐닝 및 변수를 다루는 과정이 어려워지게 됩니다. 뉴비 해커들은 이 단계에서 포기합니다. 하지만 암호화 과정을 거쳤어도 스캐닝 자체는 가능하므로 암호화는 완벽한 방법이라고 볼 수는 없습니다.

 

 2번째 방법은 메모리 수정 자체를 감지하는 방법입니다. 해커는 반드시 변수에 값을 써 넣야아 하는 입장이기 때문에 이를 적절히 이용할 수 있습니다. 변수에 값을 써 넣는 시점에서 '체크섬'을 따로 저장해놓고, 읽는 시점에서 이와 메모리 내용을 비교하여 같지 않다면 해킹에 대한 시도로 보고 클라이언트를 종료한다면 도중에 프로그램 내의 루틴을 거치지 않고 수정된 메모리가 있는지 검사가 가능합니다.

 

 void InitWeapons(){

  int i;

  for(i=0; i < WEAPONNUM ; i++){

    무기[i].인덱스 = i;

    무기[i].데미지 = 10;

    무기체크섬데미지[i] = &무기[i].데미지 ^ 10 ^ 0x12345678; // 간단한 체크섬 값을 만들어놓는다.

  }

 }

 

 int CalcDmg(~){

  if ( (&User->무기->데미지 ^ User->무기->데미지 ^ 0x12345678)

       != 무기체크섬데미지[User->무기->인덱스]; ){

         MessageBoxA(0,"해킹하지마 바보녀석아!",~~);

         ExitProcess();

      }

  int Calc = ((User->무기->데미지) + DEFAULT_DMG) - Monster->방어력;

  return  Calc >= 0 ? Calc : 0 ;

 }

 

 이런 방법으로 메모리 수정 시도를 감지하는 경우에는 해커 입장에서 리버싱을 할 줄 모른다면 해킹을 포기해야합니다. 99%의 해킹 시도를 차단할 수 있습니다.

 하지만 스캔 과정에서 체크섬의 값이 '변수와 함께' 스캔되는 경우가 있습니다. 그러므로 이 방법도 완벽하다고 할 수는 없습니다.

 

 3번째로, 아예 스캔 자체가 되지 않도록 변수를 보호하는 루틴을 작성하는 방법이 있습니다. 변수에 대한 스캔은 찾으려는 변수가 해커의 입장에서 마음대로 바꿀 수 있거나, 변수가 바뀐 시점과 바뀐 내용을 알 수 있다는 가정 하에 가능해집니다.

 이번 방법은 변수가 바뀌지 않아도 계속 수정되게 함으로써 스캔이 불가능하도록 만듭니다. 별도의 스레드를 생성하여 시간마다 달라지는 키를 사용해 변수 내용을 계속하여 바꿔주기 때문에 변수 자체가 제대로 검색되지 않습니다.

 long LoopThread(void* tmp){

  while(1){

    EnterCriticalSection(~);

    int i;   무기데미지키 = GetTickCount();

    for(i=0; i < WEAPONNUM ; i++){

      무기[i].데미지 = 무기[i].데미지 ^ 무기데미지키;

    }

    LeaveCriticalSection(~);

    Sleep(1);

  }

 }

 

 

 void InitWeapons(){

  int i;

  무기데미지키 = GetTickCount(); // 시간마다 키를 다르게한다.

  for(i=0; i < WEAPONNUM ; i++){

    무기[i].인덱스 = i;

    무기[i].데미지 = 10 ^ 무기데미지키;

  }

  CreateThread(~,LoopThread,~);

 }

 

 

 int CalcDmg(~){

  EnterCriticalSection(~);

  int Calc = ((User->무기->데미지 ^ 무기데미지키) + DEFAULT_DMG) - Monster->방어력;

  LeaveCriticalSection(~);

  return  Calc >= 0 ? Calc : 0 ;

 }

 

 

 제가 소개해드린 방법 중 가장 완벽한 방법입니다. 변수 자체가 검색되지 않으니 리버서 입장에서 리버싱할 루틴을 찾기 난해하고, 검색이 안되니 변수 수정도 불가능합니다. 만약 변수를 찾았다고 해도 1ms를 주기로 암호화 key가 바뀌기 때문에 변수를 제대로 수정할 수 없고,  '변수 수정 감지'와 병행하여 사용한다면 더욱 강력한 메모리 해킹 방지 기법이 될것입니다.

 정말 뛰어난 리버서가 ThreadLoop() 스레드를 죽여버리지 않는다면 이 방법은 해커로부터 거의 안전합니다.

 

이번 글은 이쯤에서 마칠까 합니다.

 

 

 

 

 

 

 

 

 

 

 

 

어쩌다보니 블로그에 글을 쓰고있습니다..
-선린고에 재학중인 어느 한 블로거-

Posted by 라이에