GPG 1권 온라인 게임을 위한 프로토콜 입니다. 주로 보안쪽 개념이 들어있습니다.

1. Game
Programing
Gems
[1.11] 온라인 게임을 위한 프로토콜
2015 – 07 – 02 NHN NEXT 남세현

2. 대부분의 암호화 기술은
“신뢰된 송신자와 신뢰된 수신자가
신뢰되지 않은 네트워크망을 통해 정보를 주고 받을때”를 고려함.
근데 온라인 게임에서는
수신자 (서버) 는 신뢰됨.
허나 송신자는 신뢰 안됨. 
더 큰 문제는, 해커들이 리버스 엔지니어링으로
클라이언트 프로그램을 뒤집어 까볼 수 있다는거임.

3. 100% 안전한 길은 없다
완벽하게 지키는 방법은 없다 – Prof. SM9
대신
공격하기 어렵게, 귀찮게 만들 순 있다!
( 공격 성공률을 낮춰 피해를 없게 만들고
공격이 들어오는걸 확인하면
그 사람을 ‘운영’적으로 조지는게
제일 확실한 방법. 뭐.. 고소 한다던가. )

4. 단어 정의
패킷
◦ 알죠? 찡긋^^
헤더
◦ 알죠? 찡긋^^
페이로드 (= 바디)
◦ 알죠? 찡긋^^

5. 수비 1. 페이로드 조작 막기
대부분의 해커들의 공격 방법
1. 패킷 조금 수정해서 보냄.
2. 무슨 일이 발생하는지 봄.
3. 오호!
이것을 막는 방법 중 하나는 CheckSum
◦ 알죠? 찡긋^^

6. 수비 1. 페이로드 조작 막기
CheckSum
◦ 전체 바이트의 값들을 더한 값(SUM)
에이 이건 뚫기가 너무 쉽잖아?
◦ 저 Sum 값을 해싱해서 보내기. MD5같은거

7. 수비 1. 페이로드 조작 막기
CheckSum
약점
1. 리버스 엔지니어링
◦ 어떻게 CheckSum 만들었는지 코드가 다 보임.
2. 유효한 패킷 하나를 잡아내고,
그걸 계속 보낼 수 있음 - 패킷 리플레이

8. 수비 2. 패킷 리플레이
Packet Replay
평화로운 N 모 회사.
오늘도 활기차게 출근한 변태 남 모 군은
클라이언트 공격 부분을 구현했습니다.
If( 지난 공격한지 (1/공격속도)초 보다 넘었으면)
◦ { 서버에 공격 명령 패킷을 날림 }
그리고 서버에서는 공격 명령 패킷이 올 때마다
공격 퓩 퓩 퓩 땅땅땅빵!

9. 수비 2. 패킷 리플레이
Packet Replay
평화로운 N 모 회사.
오늘도 활기차게 출근한 변태 남 모 군은
클라이언트 공격 부분을 구현했습니다.
If( 지난 공격한지 (1/공격속도)초 보다 넘었으면)
◦ { 서버에 공격 명령 패킷을 날림 }
그리고 서버에서는 공격 명령 패킷이 올 때마다 공격 퓩 퓩 퓩 땅땅땅빵!
해커가 공격 패킷을 1초에 10번 날리면?
X됨. 에이~ 요즘에 그런 서버 가 어디있어?
아직도 있다고 함. 알콜코더님 트윗에서 봄

10. 수비 2. 패킷 리플레이
가장 기본적인 수비 방법
◦ 서버에 똑같은 로직 넣어서 처리하기.
◦ (아직 쿨탐 안끝났으면 패킷 무시)
근데 문제가 있음
◦ 네트워크 문제로 패킷이 뭉쳐서 오면?
◦ 정상 패킷을 비정상으로 오인할 수 있음.

11. 수비 2. 패킷 리플레이
더 나은 수비 방법
◦난수 생성기
패킷 안에 난수를 넣어서 보냄.
아래 둘은 같은 종류의 패킷이지만, 난수가 다름
공격 : X가 Y를 Z만큼 쾅!
난수 : 1155
공격 : X가 Y를 Z만큼 쾅!
난수 : 3421

12. 수비 2. 패킷 리플레이
순서
1. 보낼 패킷 하나를 만듬.
2. 난수 생성기에서 만든 난수를
패킷에 넣음. 난수 만들기 귀찮으면 1씩 증가시켜도 됨. ㅎㅎ
3. 난수 생성기는 다음 난수를 만듬.
서버도 난수 생성기를 똑같이 만듬.
똑같이 난수 만들면서,
와야 할 난수가 제대로 왔는지 확인함.

13. 수비 2. 패킷 리플레이
역시 약점이 있다
1. 시드(Seed) 동기화 문제
◦ 시드를 고정시키면 해커가 금방 찾아냄.
◦ 서버에서 난수를 결정해서 보내주자.
2. 난수 머신 동기화 문제
◦ 패킷이 드랍되면?
◦ 서버에서 판단해서 계산. 정말 드랍때문인
지 판단.
◦ 아니면 TCP 쓰세요 님들아

14. 수비 2. 패킷 리플레이
3. Rand()는 너무 약해요.
◦ 수 많은 질 좋은 Random 함수가 있음.
구글링 ㄱㄱ
4. 하지만.. 역시나 리버스 엔지니어링에
취약함.
◦ 워쩔 수 없어.
◦ 그래서 돈을 많이 벌려면 리버스 엔지니어링을 배우세요.

15. 수비 N. 추가적인 기법
아이디어
해커에게 혼란을 주기 위해서는
동일한 페이로드(바디)를 가진 두 패킷을
다른 모양처럼 보이게 만들어야 한다.
구현
난수 만든거 있죠?
그걸로 클라에서 XOR 연산을 시키자.
서버에서는 복구하고.

16. 수비 N. 추가적인 기법
물론
해커가 눈치 챌 수 있다.
1. 패킷 크기가 똑같아서
◦ -> 똑같은 종류의 패킷이라도 패킷 뒤에 의미없는
더미 데이터 붙여서 문제 해결 가능.
◦ ->->근데 별로 비추. 패킷 크기 증가 == 비용 증가
2. 리버스 엔지니어링을 통해서

17. 수비 N. 추가적인 기법
물론
해커가 눈치 챌 수 있다.
하지만 그건 크게 중요하지 않다.
핵심은 ‘해커가 혼란스럽게 하기’ 이다.
다시 말하지만, “완벽한 수비”는 없다

18. 본질적인 한계
본질적인 한계
◦ 코드 자체가 클라이언트 프로그램에 들어있다.
역시나, 아이디어는 똑같다. 혼란스럽게 하자.
◦ 코드 자체가 클라이언트 프로그램에 있지만,
◦ 그거 분석하기 어렵게 만들자. – 코드 암호화, 심볼 제거 등
◦ 혹시 해커가 분석했으면?
◦ 채용해라.
아니면 핵심 코드들은 서버에서 돌리도록 하자.
◦ (사실 굉장히 당연한 부분)

19. 결론
치팅을 아예 불가능하게 만드는 것?
◦ 너무 소모적이며 불가능할 수도 있다.
그러므로,
치팅에 드는 노력을 최대한 크게
(엄두를 내지 못할 정도로)
하는 것을 목표로 삼는 것이 현실적이다.
요약 : 못막아. 근데 귀찮게 해봐.