반응형

게임 보안: VIP 해킹툴 대처 방안 A to Z…
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaruhttp://www.jiniya.net

블로그가 진짜 말그대로 거의 개점 휴업 상태였네요. 바쁘다는 말을 별로 좋아하진 않는데 정말 바빴습니다. 제 머릿속에서 날 것 그대로 방출된 무수한 버그들, 겹겹이 겹친 CBT 일정, 그리고 각종 요구 사항, 이슈 사항, 거기에다 VIP 핵툴까지… 헉. 이런 것들에 파묻혀서 정말 숨도 못쉬다가 이제 조금 호흡을 가다듬고 있습니다. 후훗~ 간만에 XIGNCODE(라고 쓰고 싸인코드라고 읽습니다) 깔때기나 좀 댈겸 VIP 핵툴에 대한 이야기를 좀 해볼까 합니다. ㅋㅋ


가장 최근에 등장한 모 해킹툴 그룹의 GG 제스쳐.
해킹툴 제작자만 이런 사실을 안다는게 안타깝습니다 ㅋ~

VIP 핵툴이란 유료 핵툴이라고 생각하면 됩니다. 근데 그냥 유료 핵툴은 아니고 해킹툴 제작 그룹에서 퀄리티를 보장하는 해킹툴이라는 게 특징이죠. 즉 비싼 돈을 받는 대신에 QA를 해주는 핵툴이라고 생각하면 되겠습니다. 그래서 흔히들 보안 업체가 계약을 할 때에 최대 몇 시간 내에 대응을 해줄 것인지에 대한 보장을 하는데 이런 VIP 해킹툴도 사용자들에게 그런 조항을 달아 줍니다. 예를들면 72시간 동안 해킹툴이 다운될 경우에는 보너스 기간을 준다거나 하는 식이죠. 즉, 쉽게 생각하면 목숨걸로 핵툴 만드는 애들이 판매하는 핵툴이 VIP라고 생각하면 됩니다.

그러다보니 자연스럽게 VIP 핵툴의 경우 대응이 까다로운 점이 있습니다. 사실 대응이라고 하기도 좀 힘든 실정입니다. 대부분의 경우 VIP 핵툴은 게임 패치와 동시에 업데이트 돼서 거의 항상 오픈된 상태를 유지하기 때문입니다. 어쨌든 요번 글에서는 이런 VIP 해킹툴을 대응하면서 느꼈던 점, 팁(?!)들을 몇 가지 써볼까 합니다.

#0
테크닉, 기술. 사실 가장 중요한 요소입니다. 이게 안되면 이후에 진행하는 모든 것들이 애초에 불가능하기 때문입니다. 따라서 게임 보안 제품을 만든다면 반드시 해커보다는 똑똑한 개발자와 분석가를 뽑아야 합니다. 그게 안되면 싸움 자체가 성립이 안되기 때문입니다.

이 말이 의미하는 바는 이런 겁니다. 커널 모드 핵툴이 나왔는데 우리는 유저 모드 기술 밖에는 없을 때. 같은 레벨에서 싸우지 않고서는 답이 없는 경우가 존재합니다. DirectX 후킹만 알고 있는데 핵툴 제작자는 WDDM 후킹을 하고 있을 때, 함수 진입 부분 훅 체크만 하는데 함수 중간 부분을 후킹하는 기법일 때, 코드 오버라이트 방식의 훅만 생각하는데 예외 처리기를 통한 후킹 방식일 때, 등등… 즉, 일부 영역에서는 해당 테크닉을 모르고는 영원히 대응이 불가능한 지점이 생깁니다. 따라서 일정 수준 이상의 기술력을 갖추는 것은 필수 사항입니다.

#1
도구. 두 번째로 중요합니다. 보안 제품에 반드시 특정 싸움에 대해서는 종결 시킬 수 있는 이론적 근간이 있는 코드들이 있어야 한다는 것을 의미합니다. 논클라이언트 봇이나 바이패스 툴이 나왔을 때 해당 툴들을 사전에 차단은 하지 못하더라도 사후 대응은 가능한 이론적 근간은 있어야 한다는 겁니다. 그런 게 없으면 싸움을 이어 나갈 수가 없습니다. 이런게 없으면 그냥 단순하게 바이패스 등장, 끝이기 때문입니다.

더불어서 알려진 범용 핵툴 기법에 대해서는 해당 접근 루트를 완전히 차단할 정도로 완전한 도구가 필요합니다. 특정 API를 후킹할 때 우리가 해당 API를 체크하면 더 이상 해당 API를 후킹하면서 우리 코드를 우회할 방법은 없어야 한다는 것, 특정 게임 함수를 불법 호출할 때 해당 게임 함수를 보호하면 더 이상 불법 호출을 하면서 우리 코드를 우회할 방법은 없어야 한다는 것을 의미합니다. 그런데 이 정도로 완성도 높은 코드들을 만들기는 쉽지 않습니다. 하지만 이런 코드들 없이는 절대로 싸움을 끝낼 수가 없습니다. 반드시 어느 지점까지 몰아갔을 때에는 해커들을 막다른 골목으로 인도할 수 있는 도구가 있어야 싸움을 끝낼 수 있습니다.

#2
이런 기본기가 갖추어진 다음 진짜 중요한 것은 업데이트 입니다. 핵툴은 제작이 끝나는 순간 바로 배포합니다. 몇몇 운영체제에서 크래시가 나는 것은 중요하지도 않습니다. 선배포 후에 테스트를 진행한다고 보면 되겠습니다. 이렇게만 해도 일부 핵툴이 동작하는 사용자들은 환호하면서 그들에게 돈을 지불하고도 칭찬을 아끼지도 않죠.

하지만 보안 제품은 상황이 다릅니다. 모든 PC에서 정상 동작을 해야 하며, 다른 제품들과 충돌 테스트도 거쳐야 하고, 내부 QA에서 게임사 QA, 또는 게임사에 따라서는 게임사의 자체 보안팀의 QA를 거쳐야 합니다. 이러한 복잡한 단계를 거치더라도 최소한 해킹툴과 속도전을 할 수 있을 정도의 업데이트 속도는 갖추어야 합니다. 보안 제품 한 번 업데이트로 해킹툴을 하루 다운(down) 시킨다면 적어도 매일 업데이트가 이루어져야 한다는 겁니다. 대응을 해보면 알겠지만 사실 추가 업데이트 없이 하루를 다운시키는 것도 거의 불가능할 정도로 긴 시간입니다.

물론 이런 업데이트 주기를 가지기 위해서는 보안 제품을 개발하는 쪽에서도 많은 부분을 신경 써야 합니다. 우선은 코드가 아닌 데이터만 교체함으로써 핵툴을 차단할 수 있는 구조를 많이 만들어 두어야 합니다. 데이터 교체는 빌드를 새로 하는 것보다는 훨씬 문제가 덜 발생하기 때문이죠. 또한 검증할 것도 적어지기 때문에 QA 시간도 단축됩니다. 더불어 절대로 핵툴이 새로 나왔다고 그걸 분석하고 있어서는 안됩니다. 나오는 즉시 일단 막고 봐야 합니다. 그 후에 분석해도 늦지 않습니다. QA 시간을 고려해서 최대한 빨리 대응할 수 있도록 해주어야 한다는 의미입니다.

속도전입니다. 핵툴이 새롭게 업데이트 되자 마자 바로 문제가 발생한다는 인식을 해킹툴 사용자와 해킹툴 제작 그룹에 인지시켜 주어야 합니다. 이런 인식이 없으면 마치 깨진 유리창 이론처럼 우후죽순 유사 해킹툴들이 등장합니다.

#3
시스템 가변성. 이 싸움을 잘 살펴보면 해킹툴 그룹은 아주 소수이며 그것을 사용하는 사람은 절대 다수라는 점을 알 수 있습니다. 따라서 이 싸움에서 이기기 위한 영리한 생각 중에 하나는 시스템 가변성을 두는 것입니다. 즉 우리가 만든 보안 제품이 해킹툴 제작자의 PC와 다른 사람들의 PC에서 다르게 동작한다면 해킹툴 제작자 입장에서는 굉장히 골치 아픈 문제가 될 수 있다는 겁니다. 해커가 자기 PC에서 되는 것 같아서 배포했는데 사용자들은 모두 동작하지 않는다고 아우성을 치는 상황을 만들 수 있다는 것이죠. 이런 상황이 몇 번 연출되면 해킹툴 제작자 입장에서는 클레임에 골치 아파서라도 그냥 GG치게 됩니다.

#4
느린 탐지. 아주 간단하지만 의외로 굉장히 효과적인 방법입니다. 해킹툴 배포 시간을 늦추고 싶다면 해당 해킹툴 탐지 시간을 늦추는 단순한 행위로도 효과를 볼 수 있다는 말입니다. 물론 아무리 길어지더라도 해킹툴 사용자 입장에서는 핵툴을 이용한 효용이 없는 시간 정도여야겠지요. 예를 들어 FPS 게임이라면 핵툴을 가동하고 게임을 실행하고 방을 찾아 들어가서 이제 한 번 시작해볼까 할 때에 탐지하는 것을 말합니다. 그런데 보통은 빠른 탐지가 좋은 줄 알고 게임 구동 시에 알려진 핵툴에 대해서는 바로 탐지해 버립니다. 이게 문제입니다.

이 방법이 효과적인 이유는 해킹툴 제작자의 테스트 시간을 늘린다는 점과 굉장히 피로하게 만든다는 점입니다. 게임을 구동해서 방에까지 들어가야 뭔가 결과를 알 수 있기 때문이죠. 즉, 자신이 수정한 것이 우회됐는지를 확인하기까지 시간이 늘어난다는 점입니다. 더불어 탐지 시간이 가변적이라면 더 효과적입니다. 해킹툴 제작자 입장에서는 얼마 정도를 테스트해야 하는지를 알기가 힘들어지기 때문입니다.

#5
복잡한 내부 IPC 구조. 여러분이 반드시 숨겨야 하는 것은 어떤 기준으로 해킹툴을 탐지 했냐는 겁니다. 따라서 탐지하는 부분과 사용자에게 핵툴이 탐지 됐다고 보고하는 부분 사이에는 거리가 있어야 합니다. 절대로 탐지 했다고 바로 그것을 보고하는 멍청한 짓을 해서는 안됩니다. 왜냐하면 해커들은 당연히 탐지 지점부터 우리를 추적해 오기 때문입니다. 그 사이에 엄청 복잡한 단계의 IPC 통로를 만들어 두세요. 그 IPC 메커니즘이 일정 수준 이상 복잡해지면 어느 순간부터는 해커들이 우리 코드를 분석해 패치하기 보다는 그냥 자기 코드를 고치는 것이 빠르다는 생각을 하게 됩니다.

#6
VIP 핵툴의 경우 절대로 진단 루틴이 제너레이터를 통해서 우회할 수 있는 수준이어서는 안됩니다. 해킹툴 개발자가 코드를 보고 어디를 고쳐야 할지 생각하고 다시 컴파일을 강요할 수준은 되어야 합니다. 이런 게 되지 않으면 업데이트 한 트럭이 주어져도 전혀 효과가 없습니다. 무조건 우리가 업데이트를 한 번 할 때에는 해킹툴 개발자도 적어도 컴파일을 새로할 정도는 되는 진단 루틴을 추가해야 합니다. 물론 해커가 고민을 많이 해야 알 수 있는 루틴이라면 더 좋습니다.

#7
구구절절 설명했지만 솔직히 정말 복잡하고 골치 아프고 신경쓰기 싫은 문제들입니다. 그럴 땐 그냥 웰비아닷컴의 XIGNCODE를 사용하시면 됩니다. 합리적인 가격에 우수한 게임 보안 서비스를 제공한답니다. 어쨌든 게임 보안하면 XIGNCODE, XIGNCODE하면 게임 보안 딱 답 나오잖아요 ㅋㅋㅋ~



Read more: http://www.jiniya.net/wp/archives/5657#ixzz3NCQoiPvb

반응형
반응형

게임 보안: 0을 향한 질주…
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaruhttp://www.jiniya.net


우리도 항상 제로의 영역을 꿈꾼답니다 ㅋ~

게임은 가장 하드코어한 프로그램 중에 하나죠. 사람들이 하드웨어를 업그레이드하는 주된 원인이기도 합니다. 이런 게임과 동시에 실행돼야 하는 게임 보안 프로그램의 가장 큰 어려움 중에 하나는 게임에 영향을 주지 않아야 한다는 겁니다. 백신 검사를 시켜놓고 게임을 실행해 보세요. 게임이 얼마나 느려지는지 보시면 이 말의 의미를 금방 체감하실 수 있습니다. 게임 보안 프로그래머는 보안 프로그램이 존재 하지만 없는 것처럼 만들기 위해서 상당히 많은 공을 들여야 합니다.

#0
XIGNCODE는 가장 공격적인 탐지 루틴을 사용하는 거의 유일한(?!) 게임 보안 제품입니다. 이러한 공격적인 방법을 사용하는 것은 해킹툴 억제력을 높이고 싸움에서 이길 수 있는 유일한 방법이기 때문입니다. 물론 그런다고 해킹툴이 100% 없어지는 것은 아니라는 점은 참고해 두시구요. 상대적으로 좀 더 우수한 해킹툴 제어 품질을 유지할 수 있다는 거겠죠 ㅋㅋㅋ~


AMD 2.7GHz 싱글 코어에서의 XIGNCODE CPU 점유율

공격적인 방법이란 달리 말하면 더 많은 연산을 의미하고, 더 많은 연산이란 더 많은 CPU 자원을 의미합니다. 하지만 게임과 동시에 실행되는 게임 보안 제품의 경우는 솔루션의 특성상 CPU 자원을 굉장히 아낄 수 밖에 없습니다. 그래서 우리는 공격적인 방법을 사용하돼 가급적 게임 구동 중에는 CPU 점유율을 거의 제로에 가깝게 유지하려고 애를 씁니다. “0%니까 어 그럼 CPU를 사용하지 않는다는 건가?”라고 생각하면 오산입니다. 0.0001%, 0.00001%씩 사용한다는 말이거든요. 그 1앞에 있는 0을 한없이 늘리기 위한 노력을 불출주야 쉬지 않고 노력 한다는 의미죠.

일반적으로 싱글코어에서 실행되는 게임에 있어서 2% 이상의 순간 CPU 점유율을 게임 보안 제품이 가져가면 민감한 사용자들이 순간 랙을 체감합니다. 3% 이상의 순간 점유율을 가져가면 조금 둔한 사용자가 끊김을 체감하고, 5% 이상의 점유율을 가져가면 모든 사용자가 랙을 호소합니다. 최소 사양 기준으로 말이죠.

그래서 어떤 경우에도 순간적으로 CPU 점유율을 과도하게 사용하지 않아야 합니다. 이게 말로만 들으면 굉장히 쉽습니다. 아, 그냥 CPU를 덜 사용하면 되겠구나라고 말이죠. 하지만 사실 윈도우 환경에서 스레드 별로 CPU 쿼터를 지정하는 방법이 공식적으로는 존재하지 않기 때문에 정확하게 게임 보안 제품이 가져가는 CPU 점유율을 제한하는 일은 생각처럼 그리 쉽진 않습니다.

윈도우 스케줄러가 아닌 선점형 스케줄러를 직접 구현하는 것이 가능하다면 문제가 조금 간단한데 윈도우 환경에서 유저모드에서 그런 스케줄러를 구현하기가 쉽지는 않습니다. 파이버가 비선점형으로 구현된 것만 봐도 알 수 있죠. 물론 커널 스케줄러를 대체하는 방법이 있긴 한데 이는 문서화된 방법도 아닐 뿐더러 시스템 전체적으로 굉장히 리스크가 큰 방법이라 상용 제품에 사용하기엔 힘든 실정입니다.

#1
뭐 천천히 실행하면 되는 걸 가지고 왜 그렇게 호들갑을 떠냐구요. 맞습니다. 하지만 여기엔 다른 쪽에서 우리를 압박하는 요소가 있습니다. 바로 마의 시간입니다. CPU 점유율을 낮추기 위해서 탐지 코드가 무한대로 느려져서는 안 된다는 것을 의미하는 말이죠. 게임 특성에 따라 다르긴 하지만 통상적으로 게임 보안에서 3분과 5분은 굉장히 의미있는 탐지 시간입니다.

3분 내 탐지가 이루어지면 유료 핵툴인 경우에는 제작자가 핵툴이 패치 됐다는 공지를 올리고 핵툴에 대한 업데이트를 진행합니다. 아주 악성 사용자들의 경우에도 이 시간 내에 탐지가 이루어지면 해킹툴 사용을 보류하는 경향이 높습니다.

5분 언저리에서 진단이 되거나 이 시간보다 진단이 지연되게 되면 해킹툴 제작자는 패치 됐다는 공지를 하지 않습니다. 사용자들은 이를 하나의 페널티로 인식하지요. 공격적인 사용자의 경우에는 지속적으로 해킹툴을 사용합니다. 5분 내에 탐지되지만 게임 핵툴을 사용하는 사용자가 계속 존재하기 때문에 게이머들은 지속적으로 게임 내에서 해킹툴 사용자를 마주치게 되고 해킹툴이 많다는 인상을 받게 됩니다.

즉, 마의 시간이란 아무리 늦어도 3분 내에는 해킹툴이 차단이 되어야 하고, 아주 최악의 경우에도 5분 내에는 사용자가 지속적으로 게임 플레이를 할 수 없도록 만들어야 한다는 것을 의미합니다. 이렇게 만들기 위해서는 당.연.한 이야기겠지만 CPU를 쓸 수 밖에는 없죠. 따라서 CPU 자원과 해킹툴 탐지 속도가 사이의 최적값을 찾는 것이 중요합니다. 그래야 CPU 자원을 최소한으로 사용하면서도 탐지 속도도 일정 수준 이상으로 끌어 올릴 수 있거든요.

#2
이런 이유로 XIGNCODE는 조금은 특이한 디스패칭 전략을 사용합니다. 우리 전략의 핵심은 시점입니다. 우리는 크게 이 시점을 네 가지 기준으로 분류합니다. 첫 번째는 게임이 시작하는 S 시점입니다. 게임의 각종 데이터가 로딩되기를 사용자가 기다리는 시점이죠. 다음으로는 시점은 게임이 시작돼서 사용자가 게임을 즐기는 P 시점이 있습니다. 또 게임을 사용자가 즐기다 게임을 일시 중단한 상태로 다른 작업을 수행하는 L 시점이 있습니다. 윈도우 환경이라면 게임이 액티브 프로세스가 아닌 시점을 의미하겠지요. 끝으로 해킹툴이 탐지된 X 시점이 있습니다. 똑똑한 분들이라면 버얼써 눈치채셨겠지만 이렇게 시점을 구분한 이유는 동일한 루틴도 어떤 시점에 실행되느냐에 따라서 CPU 자원 소모량을 다르게 만들기 위함입니다.

S 시점은 게임 데이터를 로딩하기 위해서 사용자가 어차피 기다리는 시점이기 때문에 이 시점에 스케줄링 되는 루틴들은 모든 CPU 자원을 활용하는 형태로 구동됩니다. P 시점은 사용자가 실제로 게임을 즐기는 시점이기 때문에 최소한의 CPU를 사용할 수 있도록 스케줄링 됩니다. 또한 뒤에서 살펴보겠지만 점감 프리미엄을 받도록 설계돼 있습니다.

L 시점의 경우에는 조금 애매합니다. L 시점이 됐다고 바로 모든 CPU 자원 소모가 들어가는 작업을 수행한다면 바로 다시 게임으로 돌아오는 경우에 랙을 체감할 수 있기 때문이죠. 떠난 시간이 일정 수준을 넘어서면 모든 검사 루틴들이 시작 시점과 동일하게 CPU 자원을 많이 소모하는 형태로 동작합니다. 다른 프로세스에게는 미안한 일이지만 어쨌든 게임 플레이라는 입장에서 봤을 때에 페널티가 발생하지는 않기 때문이죠. 마지막으로 X 시점입니다. 이 시점은 우리가 똥을 싸질러도 되는 시점이지요. 가장 아름다운 순간입니다. 크래시 따위도 전혀 무섭지 않은 무적 상태랍니다 ㅋㅋ~

#3
XIGNCODE는 랙을 줄이기 위해서 사회공학적인 기법들이 사용하기도 합니다. 바로 검사 루틴들의 스케줄링 정책입니다. XIGNCODE의 모든 검사 루틴들은 기본적으로 리타르단도 방식으로 스케줄링됩니다. 리타르단도가 뭐냐구요? 점점 느려진다는 말이죠. 왜 점점 느려지게 만들었을까요? 정상 사용자들에게 최대한 피해를 주지 않기 위해서 입니다.

일반적으로 해킹툴 사용자의 경우 게임 시작과 동시에 해킹툴을 사용하는 경향이 매우 높고, 모든 해킹툴 탐지의 80%는 20% 악성 사용자에게서 발생하는 경향이 있습니다. 신기하지만 2080 법칙은 어디에나 통용되는 것 같아요. 어쨌든 사회공학적으로 착하게 플레이를 하는 사용자들은 지속적으로 착하게 플레이할 가능성이 높다는 거죠. 그래서 XIGNCODE의 모든 검사 루틴은 점감 효과를 받도록 스케줄링됩니다. 게임 시작 후에 일정 시간이 지나면 거의 모든 검사 루틴들이 마치 죽은듯이 동작한다는 의미입니다. 물론 그렇게 되더라도 앞서 말한 3분내 탐지는 가능할 정도 수준으로 동작은 해야겠지요.

윈도우 사용자라면 윈도우를 사용하면 할수록 빨라진다는 느낌을 받았을 겁니다. 또 어떤 프로그램을 설치해서 처음 실행했을 때 보다는 자주 실행했을 때 그 프로그램의 수행 속도가 더 빨라지는 현상도 느꼈을 텐데요. 운영체제에서 이런 것들을 가능하게 해주는 캐싱 시스템이 존재하기 때문입니다. 대단한 건 아니고 여러분이 자주 요청했던 리소스를 미리 캐싱해놨다가 사용자가 요청하는 시점에 니가 이걸 요청할 줄 알았다하고는 바로 내주는 것이죠. 이 시스템이 재미난 건 대부분의 사용자가 쓰는 프로그램을 반복적으로 사용하기 때문에 굉장히 히트율이 높다는 겁니다. XIGNCODE 개발팀에는 최근에 이런 점에 착안해서 스케줄링 정책에 이런 캐싱 시스템을 도입하려고 하고 있습니다. 즉, 여러분이 게임을 지속적으로 착하게 플레이 하면 할수록 보안 제품으로 인한 성능 페널티는 점점 더 없어지고, 여러분이 해킹툴을 사용하고 뻘짓을 하면 할 수록 여러분의 시스템을 박박 긁는 것이죠.


xigncode

안타깝게도 여기에 은탄환(Silver Bullet)은 없습니다.

물론 그렇다고 너무 아쉬워할 필요는 없습니다.

최상급 수제 에픽 탄환인 XIGNCODE가 있잖아요.

딜이 안 될 때에는 탄환을 먼저 체크해 보세요. 미터기는 저희가 찢어 드리겠습니다.

뉴요커 냥꾼이는 앵벌 할 때에도 에픽 탄환을 쓴다는 점. 꼭 기억하세요 ㅋ~



Read more: http://www.jiniya.net/wp/archives/7777#ixzz3NCPhnabQ

반응형
반응형

게임 보안 솔루션 그놈이 그놈 아닌가요?
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaruhttp://www.jiniya.net

게임보안 제품 이거 쓰나 저거 쓰나 그놈이 그놈 아닌가요?
어차피 100% 막지도 못하잖아요.

업체 분들을 만나면 이런 이야기를 많이 하십니다. 네. 맞습니다. 그 어떤 솔루션도 해킹을 100% 막지는 못합니다. 하지만 100% 막지 못한다고 해서 다 그놈이 그놈인 건 아니랍니다.

일반적으로 많은 분들이 게임 보안 솔루션하면 게임 해킹을 100% 차단하기 위한 솔루션이라고 생각을 합니다. 하지만 이건 정말 아주 많이 잘못된 생각입니다. 왜냐하면 어떠한 보안도 100%가 있을 수는 없거든요. 이 세상에 그렇게 많은 경찰과 군인이 있지만 범죄와 테러가 끊임없이 발생하는 것과 똑같은 원리입니다.

게임 보안 솔루션이 하는 일은 100% 차단하는 것이 아닌 게임 내에서 유통되는 해킹툴의 수치를 관리하는 일에 가깝습니다. 게임 보안 솔루션이 없을 때에는 착한 사용자가 게임 내에서 아주 손쉽게 모든 지역에서 해킹툴을 사용하는 게이머를 만났다면, 게임 보안 솔루션을 적용한 후에는 그 빈도를 좀 낮춰서 가끔 만나도록 만들어 주는 역할을 하는 것이죠.

일종에 당뇨병 환자의 당 수치를 관리하는 것과 비슷한 일입니다. 당뇨병을 완치할 순 없지만 당 수치를 잘 관리한다면 생존에는 문제가 없습니다. 당 수치를 관리하는 것에는 여러가지 방법이 있죠. 식이요법도 있고, 당뇨약을 시간에 맞춰서 복용하는 방법도 있습니다. 자동으로 인슐린을 투입해주는 인슐린 펌프도 있죠. 모든 방법이 당뇨병을 완치하진 못하지만 심각한 당뇨 환자라면 인슐린 펌프가 제일 편한 방법입니다.

게임 보안 솔루션도 마찬가지입니다. 많은 솔루션이 존재하지만 100% 모든 해킹툴을 차단하는 솔루션은 단 하나도 없습니다. 하지만 그 솔루션들의 해킹툴 수집 능력, 신규 핵킹툴 출현 억제력, 해킹툴 출현 시 대응 속도에는 식이요법과 인슐린 펌프만큼이나 큰 차이가 있습니다. 이제 게임 보안 솔루션의 기능이 동일하다고 성능도 동일하다는 생각은 과감하게 옆집 멍멍이에게 주도록 합시다.

반도의 흔한 게이머의 합.성.짤.


반도의 흔한 게임 보안 솔루션의 네이버 테스트


반도의 흔한 게임 보안 솔루션 개발자 블로그 검색어 유입 순위






미디엄과 하드, 사소하지만 굉장히 큰 차이

해커들에게 가장 어려운 게임 보안 제품

해커들에게 가장 골치아픈 게임 보안 제품

해커들에게 가장 터프한 게임 보안 제품

그리고 게이머들이 탑재를 요구하는 게임 보안 제품

오늘도 XIGNCODE 개발팀은 그런 제품을 만들기 위해서 최선을 다한다는거, 아시죠? ㅋ~




Read more: http://www.jiniya.net/wp/archives/9191#ixzz3NCN2g7Rw

반응형
반응형

게임 보안: 타이밍 전쟁
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaruhttp://www.jiniya.net

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

내가 바로 그 유명한 알타. 하지만 XIGNCODE는 1000개를 띄워도 한번만 검사할 뿐이고~

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

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

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

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

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

XIGNCODE 개발팀 화이트보드에 붙은 그 녀석의 아바타~

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

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

보안 제품 하나 바꿨을 뿐인데 핵툴 커뮤니티 소문 참 빠르네요. 왜일까요?


XIGNCODE는 해킹툴 제작자를 집으로 돌려보내는 유일한 솔루션이기 때문이지요.

 0  0 

 

 

 




Read more: http://www.jiniya.net/wp/archives/6006#ixzz3NCKSjmxX

반응형

+ Recent posts