[소고] 게임 보안: 타이밍 전쟁

A Book On C란 책을 보면 C언어에서의 0의 의미에 대해서 설명하면서 시작을 합니다. 배열의 시작 인덱스 번호이기도 하고, 문자열의 끝을 나타내기도 하고, 거짓을 나타내기도 한다… 등등으로 말이죠. 이런 것처럼 게임보안에 있어서도 타이밍이란 참 다양한 의미로 사용되고 또 중요한 개념입니다. 오늘은 이 타이밍에 관한 내용에 대해서 좀 써볼까 합니다.

#0

일단 게임보안 제품이 영원히 한 수 접고 시작할 수 밖에 없는 타이밍이 있습니다. 바로 실행 타이밍입니다. 게임보안 제품의 제1공리가 다름아닌 ‘게임보안 제품은 절대로 해킹툴보다 먼저 실행될 수 없다’이기 때문입니다. 이런 전제를 뒤엎기 위해서 바다 건너 P모 제품은 게임 실행과 상관없이 메모리에 상주하기도 합니다. 하지만 이래봐야 운영체제가 실행된 다음에 실행될 뿐입니다. 운영체제 실행 전에 해킹툴이 실행된다면 어쩔 수 없습니다. 물론 그런 극단적인 — 뭐 사실 크게 극단적이지도 않습니다. — 예를 가정하지 않더라도 P모 제품의 전략이 안통하는 가장 큰 이유가 있습니다. 게임보안의 특수성이 그 이유죠. 일반적인 보안 제품은 사용자가 해커로부터 PC를 보호하기 위해서 보안 제품을 사용합니다. 하지만 게임보안에서는 사용자가 곧 해커가 돼 버립니다. 따라서 상주해 있다고 하더라도 사용자가 해킹툴을 사용할 목적으로 프로세스를 종료해 버리면 끝납니다. 아주 은밀하게 구동하겠다구요. 물론 가능합니다. 하지만 그 은밀함이 지나치다보면 옆동네 백신 친구들하고 싸움이 납니다. 화가난 백신 친구들이 우리를 white rootkit으로 분류하고는 마구 삭제해 버리죠. 어쨌든 백신 친구들하고 싸우면 안됩니다. 친하게 지내야죠 ㅋㅋ~

이런 이유로 게임 실행 전이란 그 영역은 게임보안 제품에게는 영원한 미지의 영역입니다. 마치 우리에게 빅뱅 시점이 영원히 풀지 못할 것처럼 보이는 미지의 영역인 것처럼 말입니다. XIGNCODE는 이런 제약에 보다 효과적으로 대응하기 위해서 대부분의 기술을 차단(blocking)의 관점보다는 탐지(detection)의 관점에서 개발합니다. 왜냐하면 일단 먼저 시작할 수 없기 때문에 차단은 언제나 결국은 실패할 수 밖에 없는 방법이거든요. 역사적인 관점에서 게임보안을 살펴보면 이것도 약간 트렌드가 있는데요. 아주 초장기는 백신에서 차용한 탐지의 관점에서, 그러다가 후킹이 발전하면서 차단의 관점으로, 그러다 해킹툴 진영의 후킹 기술도 덩달아 발전하면서 다시 탐지의 영역으로 돌아오는 형태가 되고 있습니다. 현재 모든 게임보안 제품에서 말하는 차단의 형태는 바보들을 막기위한 껍데기라고 생각하시면 됩니다. 그렇다고 차단 기술이 완전히 의미없진 않습니다. 해킹툴을 만드려고 하는 사람들의 대다수는 그런 바보들이거든요.

#1

다음으로 게임보안에서 주로 이야기되는 타이밍은 무한(INFINITE)입니다. 게임 보안에서 INFINITE는 금기시 되어야 하는 것 중에 하나입니다. INFINITE가 뭐냐구요? 특정 이벤트나 메시지가 올 때까지 한없이 대기를 한다는 것을 의미합니다. 프로그래밍을 배울 때 개발자들은 동기화 이슈를 만들지 않기 위해서 INFINITE를 써야 한다고 배웁니다. 하지만 게임보안에서 INFINITE는 구린 제품을 만드는 직행 티켓이죠.

예를 들면 이런 겁니다. 게임보안 제품이 아주 은밀하게 중요한 부분에서 특정 윈도우에 SendMessage를 했다고 생각해 봅시다. 어떤 윈도우인지는 모르겠지만 말입니다. 일반적인 경우라면 메시지가 리턴되겠죠. 해커가 그 사실을 알았다면 어떻게 할까요? 윈도우를 만들어서 SendMessage에 응답을 하지 않도록 만들어버립니다. 당연히 보안 제품은 바보가 돼 버립니다. SendMessage 뿐만 아니라 그 모든 이벤트에 대해서 절대로 무한 대기를 해서는 안됩니다. 이런 것들은 굉장히 쉽게 공격당할 수 있는 포인트거든요. 그래서 게임보안 제품은 대부분의 경우에 타임아웃을 설정합니다. 해당 타임아웃 넘어 응답이 없다면 그 다음 프로시저를 진행할 수 있도록 말이죠.

똑똑한 신입 게임보안 개발자들은 이런 이야기를 하곤 합니다. “그건 게임보안 제품이 게임과 별개로 동작하니깐 그런거죠. 게임이랑 한몸이 돼서 돌아가면 그렇게 하지는 못할것 같은데요. 그러면 게임도 같이 멈출테니까요?!?!”라고 말입니다. 정말 똑똑한 개발자군요. 우리 회사에 지원했다면 바로 채용했을 겁니다. 게임보안에서 가장 중요하게 생각하는 점을 제대로 짚긴 했습니다만 여기에도 맹점이 있습니다. 렌더링 스레드에 은밀하게 보안 코드가 추가되면 가장 좋긴 합니다. 하지만 다른 100만 가지의 문제를 야기 시키기도 합니다. 바로 랙이죠. 해커가 응답을 지연시키는 행위를 막을 순 있겠지만 정상적인 천만가지 상황에서도 렌더링 스레드가 지연돼서 화면이 프리징되는 문제가 만들어집니다. 그래서 렌더링 스레드에는 아주 섬세하고 조심스럽게 작성된 코드 외에는 추가하지 않는 것이 좋습니다.

#2

음. 다음으로는 또 활성화 타이밍이 있습니다. 해킹툴이 실행된 시점이 아닌 게임 내에서 실제로 활성화되는 시점을 의미하는 말입니다. 요즘 출시되는 대부분의 해킹툴은 실행 시점과 활성화 시점이 같은 경우는 거의 없습니다. 왜냐구요? 보안 제품을 우회하기 위해서입니다. 고전적인 게임보안 제품들은 게임 런칭 시점 외에는 따로 해킹툴 검사를 수행하지 않았습니다. 그래서 해커들은 해당 보안 제품이 스캔한 다음 자신의 해킹툴 코드를 활성화 되도록 만들었습니다. 그러면 스캔이 이미 지나갔기 때문에 예전 방식으로도 손쉽게 보안 제품을 우회할 수 있기 때문이죠.

게임보안 개발자들도 가만 있진 않았겠죠? 주기적으로 검사를 하도록 만들었습니다. 그랬더니 이번에 해커들은 어떻게 했을까요? 주기적으로 코드를 복원시킵니다. 즉, 초기 회피 타임과 주기를 알고 있다면 자신이 변조한 코드를 그 주기에 맞춰서 원본으로 돌려놓고 보안 제품 스캔이 끝나면 다시 코드를 변조하는 형태로 만들었다는 말입니다. 그 다음은요? 당연히 보안 제품 개발자들은 주기를 랜덤하게 해서 측정할 수 없도록 만들었답니다. 그래도 여전히 이 활성화 타이밍은 굉장히 중요한 부분입니다. 왜냐하면 검사 방식에 따라서는 비용이 너무 높아서 주기적으로 검사 하기는 힘든 것들도 있거든요.

물론 해커들만 이런 방법을 사용하는 것은 아닙니다. 사용자들도 이런 활성화 타이밍을 사용하는데요. 흔히 인젝션 딜레이라고 말하는 방법들이죠. DLL 인젝션 형태로 구동되는 해킹툴들은 언제 인젝션 하느냐에 따라서 해당 해킹툴이 탐지되기도 하고 안 되기도 합니다. 이런 취약성이 있을 때 쓸 수 있는 방법입니다. 예전에는 매뉴얼 인젝션 기능을 사용해서 게이머가 직접 판단해서 넣는 형태로 조작을 했습니다. 한 해킹툴 사용자가 탐지되지 않는 시점을 찾으면 커뮤니티에 방법을 공유합니다. 언제 게임이 뜨고 머가 나오고 3초 정도 있다가 넣으니까 되더라. 이 추상적인 문구를 토대로 그 글을 본 멍청이들이 모두 따라 해봅니다. 하지만 쉽진 않죠. 이런 백성들을 불쌍히 여긴 해킹툴 제작자가 버전업된 인젝터를 만들기에 이르렀는데요. 바로 인젝션 딜레이를 밀리초 단위로 지정할 수 있게 만든 것이죠. 그 이후로 커뮤니티에는 온갖 추상적인 이야기들은 사라지고 그 밀리초만 공유하게 되었다는 슬픈 이야기가 전해지고 있답니다. 하앍~

#3

또 다른 걸로는 게이머들이 많이 사용하는 용어이긴 한데 ‘알타’라는 말이 있습니다. 알집 타이밍의 준말인데요. 알집을 동시에 여러 개를 실행하는 것을 의미합니다. 알타50, 알타100등이 있는데요. 게임 실행 시점에 알집을 50개, 100개를 동시에 실행 시켜서 게임보안 제품이 알집을 검사하느라 해킹툴을 늦게 발견되도록 만드는 방법입니다. 대단하죠? 이토록 게임 해킹에 대한 사용자들의 욕망은 강렬합니다. 알타랑은 원리가 좀 다르긴 한데 자매품으로 Fraps 타이밍도 있답니다. ㅋㅋ~

XIGNCODE는 이런 방법에 대응하기 위한 다양한 기법들을 사용합니다. 기본적으로 거의 모든 검사 항목에 캐시를 사용합니다. 동일한 오브젝트를 두 번 검사할 필요는 없잖아요. 또 알집과 같이 알려진 프로그램에 대해서는 아주 빠르게 검사할 수 있도록 화이트 목록을 저장해 두는 방법도 사용하죠. 그리고 지능적으로 해킹툴 같아 보이는 것들부터 먼저 검사하도록 만드는 방법을 사용하기도 한답니다. 결국 뭐 알타는 XIGNCODE에게는 무용지물이라는 말이죠.

#4

해커와 게임보안 개발자 사이의 신경전적인 타이밍도 존재합니다. 바로 릴리즈 타이밍이죠. 새로 제작된 핵툴을 배포하는 시점과 그 핵툴을 차단하는 업데이트를 적용하는 시점을 의미합니다. 이런데 신경전이 있냐구요? 네 엄청나게 있습니다. 그런데 이것도 사실 게임보안 개발자가 천만배는 불리합니다. 왜냐하면 지난 글에서도 보았듯이 게임보안 제품 업데이트는 수많은 인력의 엄청난 시간과 노력을 필요로 하기 때문입니다.

그런 신경전을 거는 녀석들은 어떤 녀석들인지 알아볼까요? 여러분이 게임보안 개발자라면 언제 해킹툴이 새로 나오면 제일 짜증날까요? 네. 맞습니다. 짝짝짝 ㅋㅋ~ 불금이죠. 불타는 금요일 밤인데 이 녀석들이 업데이트를 하면 참 뷁스럽지 않겠습니까? 더 얄미운 녀석들은 해킹툴 사이트에 보라고 이렇게 공지를 한답니다. 참고로 해외 해킹툴입니다. 우리는 해킹툴을 이미 다 만들었는데, 한국시간으로 금요일 밤에 업데이트 하겠다. 핡~ 혈압이~ ㅠㅜ~ 이 바닥이 이렇습니다.

멍청하게 당하고만 있을수는 없지요. XIGNCODE 개발팀에서는 진단 루틴을 하나만 만들지 않고 한번에 여러 개를 만든답니다. 그리고 지난 번에 알려준 것처럼 시스템과 시간에 따라서 다르게 액티베이션되도록 만듭니다. 불금이 왔습니다. 해커는 신나게 릴리즈를 하죠. 어떻게 될까요? 네. 사용자들 원성이 자자하군요. 해커는 멘붕 시츄에이션에 봉착합니다. 자기 PC에서는 되는 것도 같거든요. 이런 불일치가 많아지면 많아질수록 해커는 쉽게 포기합니다.

신경전 이야기를 하니 예전 생각이 나는군요. XIGNCODE 역사상 이름이 가장 많이 거론된 해커가 한 명 있습니다. 얼마나 유명했냐면 개발팀 화이트보드에 그녀석 아바타 사진과 함께 WANTED가 붙기도 했죠. 걔 말고 그런 것이 붙었던 사람은 없었습니다. XIGNCODE 1.0시절 초창기 바이패스를 제작했던 녀석인데, 지금까지 그 녀석이 제작한 바이패스가 이론적으론 가장 완벽한 모델입니다. 그래서 우리는 아주 골치가 아팠죠. 그 녀석을 막기 위해서는 게임 서버에 있는 XIGNCODE 코드를 업데이트해야 했었거든요. XIGNCODE는 게임 서버가 구동 중인 상태에서도 업데이트가 가능하도록 설계는 돼 있지만 게임사에서 그렇게 하는 것을 별로 좋아라하지는 않습니다. 우리가 할 수 있는 업데이트는 일주일에 딱 한 번 정기 점검인 경우가 많았죠. 우리는 그 한 번의 샷을 최대한 활용하기 위해서 월화수목금토일 코드가 다르게 적용되도록 만들었답니다. 9-10개월 정도 지루한 공방이 이어졌지요. 그러다 세번째 버전인 XIGNCODE3가 나오면서 지금은 커뮤니티에서 자취를 감추었답니다. 다소 비극적인 결말이군요. SEH 하이재킹과 후킹을 참 잘하던 친구였는데. 적이었지만 실력은 인정해주고 싶은 친구였답니다. 부디 영원히 착하게 살아가길 ㅋㅋ~

#5

전쟁에서 이기기 위해서 가장 중요한 것은 정보고, 그 다음으로 중요한 것은 타이밍입니다. 게임보안에서도 마찬가지입니다. 정보와 타이밍이 참 중요합니다. 같은 값이면 이런 것들을 잘 이해하고 있는 사람들이 만드는 솔루션을 쓰는 게 좋겠다고 저는 생각하는데 말입니다. ㅋㅋ~