3. * 2005년 WOW가 인생을 바꿔놓음
* WOW 오리지널 풀파밍
* 전투사령관 캐릭터 둘
그 이외 게임 업계 활동
* China GDC 2010 발표: “How to Support an Action-Heavy MMORPG from Angle of Server Architecture”
* Game Developer Magazine 2012. 5월호 특집 게재: “Evolving MMORPG Combat”
* 2006~ Server Programmer, L3, NCSOFT
* 2007~ Gameplay Programmer, Server Architect, TERA, Bluehole
* 2012~ Professor, Game Track, NHN NEXT
5. Agenda
• 사설 서버란?
– 사설 서버의 영향
– 사설 서버가 생기는 경로
• 사설 서버 방지를 위한 노력과 방법
– 직접 탈취로부터
– 서버 에뮬레이터 제작으로부터
6. 강연 범위
• 강연 대상
– 온라인 게임 프로그래머 (서버, 플랫폼)
– 게임 서버 보안에 관심 있는 사람 (프로듀싱, 서비스)
• 다루지 않는 것
– 전반적인 서버 보안 방법 (DDOS, SQL Injection, …)
– Reverse engineering 방지 관련 테크닉
사설 게임 서버에 특화된 내용을 다룸
8. 사설 게임 서버란?
• 게임 서버를 ‘탈취’하거나 ‘제작’하여 (원작자 동의 없이) 서비스
– Private server, Gray shard, Free server, Server emulator [1], …
– 대부분의 경우 영리를 목적으로 함
• 주로 2가지 방법으로 생김
– 해커들이 직접 탈취한 것을 기반으로
• (예) AEGIS (Ragnarok Online) [2]
– 서버 에뮬레이터 제작을 통하여
• 실제 정식 서버를 흉내(모방) 내도록 제작
• (예) WOW MaNGOS [3]
9. 사설 서버의 악영향
• 직접적으로는 Profit-share 감소
• 간접적으로는 (더 무서운 것)
– 게임 자체에 대한 신뢰 하락
– 유저들이 존중(respect)받지 못한다는 느낌
• Nexon, Blizzard, Ncsoft의 사설 서버에 대한 소송 예
– 북미 1등(?) 메이플스토리 사설 서버인 OdinMS [4]
– WOW 부분유료화 형태의 사설 서버인 Scapegaming [5]
– 5만 사용자를 거느린 리니지2 사설 서버인 L2Extreme [6]
10. 왜 사설 서버를?
• 돈을 벌기 위해
– 꽤 많은 인력들이 사설 서버 구축을 위해 노력
– 생각보다 많은 사람들이 플레이 함 꽤 짭잘(?)
– CIS 관련 국가 및 중국 내륙
• (예) 한 때, 러시아 시장 1위는 리니지2 사설 서버 [7]
• 교육적인(?) 목적
– 서버 에뮬레이터 제작의 경우, 해커들의 도전 의식 자극 + 재미
– “게임 서버 프로그래밍 공부하기 정말 좋다”는 함정
11. 직접 적인 유출(leak)로부터 사설 서버가 생기는 경우
• 개발사에서 직접 유출되는 경우
– 대부분의 경우 트로이 목마를 통한 유출
• 개발실 소스코드 유출 괴담: “출근 해보니 전부 체크아웃 되어 있더라?”
• (예) 밸브의 하프라이프2 소스코드 유출 [8]
• 우리 나라의 몇몇 회사들도 이렇게 털린 경우가 많음 (카더라 통신)
• 퍼블리셔측에서 유출되는 경우
– 서비스 네트워크 또는 배포선에서의 탈취
• (예) 뮤 온라인의 해외 유출 [9]
– IDC 근무자에 의한 인위적인 서버 바이너리 탈취
12. 서버 에뮬레이터 제작을 통하여 생기는 경우
• 해커들은 미리 서버 에뮬레이터 제작을 준비
– 폐쇄형 커뮤니티(private IRC, phpBB 등)를 통해 정보 공유 및 수집
• 패킷 구조, 클라이언트 보안 메커니즘 등
– CBT와 동시에 클라이언트 입수 후, 해당기간 중 다양한 실험 및 공유
• 서버 프로그래머: “어?! 이상하다. 이런 패킷이 올 수가 없는데?”
• Non-Client Bot과 같이 만들어 짐
– 서버 에뮬레이터와 비슷한 시기에 (약간 먼저) 등장
• Non-client bot이 있다는 말은? 어딘가에서 서버 에뮬레이터가…
• 사실상 한 뿌리: 서버를 흉내 내느냐 클라를 흉내 내느냐의 차이
13. 오늘의 진짜 주제와 결론
• 100% 막는 방법은 없습니다
– (작정한) 인원에 대한 보안은 정말 어렵기 때문
– 클라이언트는 이미 적의 수중에 있기 때문
• 그래서, 이미 버린 몸(?)이니 포기?
– 어차피 털릴텐데 아무것도 안하기?
• 그렇지만, 노력대비(?) 효과를 볼 수 있는 방법들은 있음
– 오늘의 핵심 주제
15. 개발사에서의 직접 유출
• 트로이 목마(Trojan Horse)를 통한 유출이 대부분
– 개발 관련툴 크랙 버전에 심어서 토렌트 등으로 배포
• (예) V-Asst, I-Bld, A-CS, …
– 개발자의 컴퓨터에서 실행되는 순간
• 백도어 생성후 해커에게 리포팅
• 리포팅 받은 해커는 바로 털어가지 않고, 지속적으로 감시 및 백도어 강화
• Windows Domain Admin 권한을 갖는 컴퓨터에 설치되는 순간 게임 오버
– 계속 지켜보다가 (어느 정도 완성되면) 순식간에 털어감
16. HOW-TO
• 정품 개발 툴만 사용
– 검증되지 않은 프로그램 사용 금지
• 최신 소프트웨어로 업데이트
– 특히 OS의 경우, 구 버전의 취약점을 공략
• 보안에 자신 없으면
– 개발망을 인터넷으로부터 물리적으로 분리 (가장 확실)
• Source repository, Issue tracking system 등
17. 인원 보안 문제
• 그럼에도 불구하고, 내부 사람에 의해 털릴 수 있음
– 가장 무서운 적은 내부의 적
– 퇴사시 별 생각 없이 습관적으로 가져가는 경우도 있음
• 악의적인 의도가 아닌 경우: (열정이 넘쳐?) 집에 가져와서 일하는 경우
• HOW-TO
– 개발망 분리 후, 비인가 저장장치 사용 금지
– 회사에서의 작업물에 대한 교육(개념 주입) 필요
– 개발자들에게 잘해줘서 회사 떠나지 않게 하는 것 (가장 확실)
• 개발자 괴롭히면? 복수심에 싹 다 들고 제 3국가 가서 서비스 할 수도.. (농담)
18. 퍼블리셔측에서의 유출
• 배포선(release process) 또는 IDC에서 유출되는 경우
– 내부 인원에 의한 유출
• 운영 인원의 권한 최소화 및 2-way 인증 필요 (뻔한 이야기)
– 직접 해킹 당하는 경우
• 해킹 방어는 광범위한 영역 (본 강연 주제를 벗어남)
– 100% 유출 막는 것은 불가
• 서버 바이너리의 유출 여부를 아는 것이 중요
– 어떤 버전이 어디를 통해 유출 되었는지 아는 것이 필요
– 탈취된 서버가 정상적으로 동작하지 않도록 하는 장치 도입
19. HOW-TO: 기본적으로 해야 할 것
• 인가된 채널로만 배포
– 급한 patch라고 메일 등으로 전송 금지
• 서버 프로그램 유효 기간 설정 (Time-bomb)
– (예) 현재 실행 시각이 빌드 시점(__DATE__)로 부터 얼마 지났는지 체크
• Binary Fingerprint
– 인증된 머신 정보를 서버 바이너리에 삽입
• (예) .data 영역을 확보 해놓고, 배포시에 인가된 머신 MAC주소로 교체
– 서버 실행시 해당 영역 정보와 머신 정보 비교
20. HOW-TO: 서버 실행 여부를 통지 받기
• 서버 시작시 80번 포트로 서버 정보 보내기
– 버전, 인가된 머신 번호, 퍼블리셔 코드 등을 암호화해서 전송
– Outbound 80번 포트(http)를 막는 경우는 거의 없음
– 리포팅은 제 3지대(Amazon EC, GAP 등) 서버에서 받기
• 리포팅 받은 것을 주기적으로 모아서 메일로 통보 받으면 편함
{NX_KOR, VER, IP, MAC, …}
via HTTP/80
Reporting
e-mail
21. 이것저것 다 귀찮은 경우…
• 돈(?)으로 해결 할 수 있음
• 하드웨어 보안 모듈이 설치된 서버에 배포
– TPM[10]을 통한 디스크 암호화 등
• 라이선스 서버 솔루션 사용
– 인터넷을 통한 실시간 인증을 받아야 서버 실행이 가능
23. 서버 에뮬레이터의 경우
• 처음부터 보안에 신경을 써야 함
– 해커들은 최초의 외부 테스트(FGT, CBT)부터 클라이언트 분석
– 오픈 전에 서버 sandbox가 등장하는지 여부를 결정
• Sandbox?
– 월드 접속 및 이동만 되는 일종의 더미 서버로 해커들의 첫 번째 목표
– 서버-클라이언트간 핵심 동작 메커니즘이 분석 당했음을 의미
• 두 측면에서 공략
– 패킷 분석 및 클라이언트 역공학(reverse-engineering)
24. 클라이언트 역공학
• 동작 메커니즘 분석
– DLL injection등을 통해서 send/recv API 부분을 hooking
– 서버-클라이언트간 어떤 데이터를 어떻게 주고 받는지 파악
• 시간과 노력이 많이 들지만 암호화 관련 로직 우회 가능
• 게임 데이터 추출
– 아트 리소스 뿐만 아니라 게임에 필요한 각종 데이터시트 정보들
• (예) 스킬 공격력, 아이템 스탯 테이블 등
25. HOW-TO: Anti-Reverse Engineering
• 광범위한 주제
– 기초적인 것만 해도 해야 할 것이 많음 [11]
• 해커들의 속도를 따라잡기 힘든 부분
– 개발자가 일일이 적용하는 것은 비용대비 효과 측면에서 비추
• 클라이언트 바이너리 난독화 전문 툴 사용을 추천
– Themida (WinLicense) [12] 등 (의외로 싸다)
– 지속적으로 최신의 반-역공학 방법들이 업데이트 됨
26. HOW-TO: 꼭 필요한 데이터만 패키징
• 클라이언트에서 꼭 필요한 (client-only) 데이터만 넣기
– 의외로 서버에서만 필요한 데이터도 같이 넣는 경우가 많음
• (주로 귀차니즘 때문에) 통합 데이터시트로 하는 경우
– 배포 툴에서 패키징 자동화하는 것을 추천
• 데이터 항목에 서버/클라/공용 태그 넣기
• [참고] 서버 에뮬레이터 제작시 가장 더럽고(?) 귀찮은 부분
– 실 서버와 같은 데이터 값(밸런싱 정보 등)을 수집하여 입력하는 것
– 클라이언트에 해당 정보가 있다면, 손쉽게 추출해서 사용하게 됨
• (예) W모 게임의 경우, dbc파일 추출 후 그대로 읽어서 사용
27. 패킷 분석
• 서버-클라이언트간 패킷 수집(capture)
– 어떤 내용이 오가는지 알면, 서버/클라이언트 모두 흉내낼 수 있기 때문
– 암호화 하지 않는 경우 클라이언트 역공학을 시도할 필요도 없음
• 패킷 암호화
– 아무리 잘해도 언젠가는 파악당함 (클라이언트 역공학)
• 개발자가 덜 귀찮도록 하는 방식으로 관리하는 것이 핵심
• 패킷 내용들이 파악되어도 조금만 수정하면 시간을 또 벌 수 있도록
– 패킷 수집(감청)으로부터 최소한 유저들의 정보를 보호하기 위함
• Raw data 그대로 수집되면 위험한 것들 (ID, PIN, 메일주소, 채팅내용 등)
28. HOW-TO: 패킷 암호화시 주의할 점
• 직접 설계하거나 구현하지 말 것
– 이미 검증되고 리뷰 많이 받은 잘 만들어진 코드를 사용 [13]
• (예) AES256, RC4, …
• 아무리 독창적인(?) 암호화 알고리즘을 만들더라도 파악됨
• 결국, key를 잘 관리하는 것이 핵심
• 절대로 key를 클라이언트에 박지(?) 말 것
– 사실상 암호화 하지 않는 것과 같음
– Key는 세션을 맺을 때마다 무조건 새로 생성해서 교환해야 함
29. HOW-TO: 암호화 통신을 위한 Key 교환
• Diffie-Hellman Key Exchange [14]
– 세션 성립시마다 새로운 키로 암호화하기 위함
– 각종 공격(예: MITM)에 안전한 구현체를 사용할 것 (예: SRP)
ClientServer
소수 p, g
a b
crypto-key
ClientServer
감청 당해도
crypto-key
파악 불가
Transport
K = B^a mod pB = g^b mod p
a b
B A
A = g^a mod p K = A^b mod p
30. Secure Remote Password Protocol
• SRP [15]
– 스탠포드 대학에서 제작 (현재 버전은 SRP-6a)
– 인증 + 키 교환 + 패스워드 암호화를 한방에 해결!
– 인증에 사용되는 비밀 정보가 일부 털려도 안전
– 사전 공격 및 MITM 공격 등으로부터 안전
– 공인 인증 기관 (CA) 필요 없음
31. HOW-TO: 패킷 암호화시 주의할 점
• 패킷 전체를 스트림 방식으로 암호화
– (예) W모 게임처럼 패킷헤더만 암호화 하는 경우 raw data 노출됨
32. HOW-TO: 패킷 셔플링
• 패킷 번호 및 패킷 내용 순서 무작위 치환 (shuffle)
– 패치 때마다 패킷이 바뀌는 효과 해커들 입장에서는 상당히 귀찮음
– SVN revision 번호 또는 GIT tag hash를 key로 활용 가능
– 배포시 자동화 추천: pre-build event로 패킷 코드 생성(emit)할 때
33. 이런 노력에도 불구하고,
• 서버 에뮬레이터 제작을 100% 막기는 불가
– 어차피 클라이언트는 언젠가는 완전히(?) 분석 당함
– 어딘가에서 서버 에뮬레이터가 만들어지고 있는지 아는 것이 중요
• FACT
– 서버 에뮬레이터도 결국 (인터넷상의) 일반인 대상으로 서비스
• HTTP 포트(80)를 일부러 닫고 사용하는 유저는 없다는 점을 이용
– 클라이언트는 정식 배포본을 사용한다는 점을 이용
• 플레이어의 클라이언트가 어느 서버에 접속하는지를 직접 리포팅
• 대상 서버 IP가 127.0.0.1, 192.168.x.x 이런 종류라면 제작 중이라는 뜻
34. 접속 대상 서버 정보를 통지 받기
map-reduce & whois
사설 서버
사설 서버 유저
(클라이언트)
Random sampling report via HTTP
클라이언트가 특정 확률로 서버 정보 리포팅
정식 서버 정보는
걸러내고 리포팅
36. 마무리
• 100% 방지법은 없음
– 최소한의 노력은 하자: 언급한 방법들이 난이도 높은 일이 아님
– 어차피 털린다고 손 놓은 것과는 차이가 큼 (방충망이 유무의 차이)
• 관리의 측면으로 접근
– 지속적으로 모니터링 및 수정(자동화)을 통해서 시간을 벌기
– 내가 보안에 쓰는 노력보다 해커가 뚫는 노력이 더 큰 것 위주로 적용
• 숨기는 것 보다 찾는 것이 더 어려운 이치
• 실제로 상당히 효과적이었음
39. 뒷이야기
• 수년간 지켜본 입장에서의 개인적인(?) 느낌
• 서버 에뮬레이터 구현 능력
– 프로그래밍 실력?
– 러시아 친구들(잉여력까지 느껴짐) >> 중국 해커들 > 미국 해커들
• 실제 게임(실서버)의 흥망성쇠(?)와 상관 관계 있음
– 서버 에뮬 개발이 활발해지고 있는 추세 ∝ 실서버 사용자 수
– 개발이 중단되거나 관련 커뮤니티가 완전 죽은 경우
• 실서버 사용자 급감 상황
40. 서버 에뮬레이터 제작 커뮤니티
• 서버 에뮬레이터는 다양한 버전이 존재
– Sandbox 이후로 다양한 버전
– 수익금 기부(donation) 문제 등으로 커뮤니티 분열이 잦음
• 누군가 (몰래) 서비스, 핵심 멤버 탈퇴, 원 제작자로부터의 추적 등
– 누군가 기존 작업물을 가져다가(stealing) 새로운 프로젝트로 포장
• 비슷한 이유로 또 분열 반복
