27. CRC, 데이터 변조 검사
본문 바로가기
Reversing & Cheat Engine

27. CRC, 데이터 변조 검사

by boosting 2024. 3. 12.
728x90

데이터 변조가 있는지 검사를 해야 하는 이유

프로그램에선 수많은 데이터와 정보를 처리하고 이 데이터들을 다른 프로그램들과 주고받곤 합니다.

그런데 어떤 사람이 악의를 가지고 데이터의 정보를 바꿔치기 해서 보낸다면?

이를 인지하지 못하면 시간이 지날수록 피해가 누적되서 모두에게 피해가 갈 것입니다.

그래서 이 데이터의 정보가 정확한지 체크하는 방법이 필요하게 됩니다.

 

그래서 CRC라는 개념이 있다

CRC라 하면 Cyclic Redundancy Check의 약자로서 데이터의 정합성을 체크하는 방법입니다.

주로 데이터를 송수신할 때 사용되어지며, 원본 데이터가 훼손이 없다는 것을 증명하기 위해

사용됩니다.

 

이 CRC에 들어가는 것은 Bit 연산자로 검증하는 계산식이 들어가게 되는데요.

이것을 너무 길게 풀이하면 글이 너무 길어질 거 같기도 하고 잘 정리된 글들이

워낙 많기 때문에 간단하게만 짚고 넘어가려고 합니다.

 

계산 방법은 다음과 같습니다.

  • 1단계 : 데이터를 비트로 변환
    예를 들어 EB 0C 8B 4B라는 데이터가 있을 때 이를 먼저 2진법으로 변환해줍니다.
  • 2단계 : Polynomial을 비트로 변환
    위에서 말했던 계산식을 의미하며 지수 형태의 식입니다. 
  • 3단계 : Bitwise xor 계산
    데이터와 Polynomial을 비트로 변환했던 것을 xor 계산합니다.
    계산을 쭉 해보면 결국 CRC의 계산은 원래의 데이터를 전부 0으로 만들어주면서
    진행을 해 나가고, 맨 마지막에 덧붙여준 다른 값이 생깁니다.
    그것을 이 CRC의 Hash라고 부릅니다.
  • 4단계 : 데이터 송신
    CRC 계산이 끝났으면 원래의 데이터에다가 계산이 끝난 Hash를 덧붙여서 보냅니다.
    그러면 수신하는 측에서 이 데이터를 위와 동일한 계산식으로 다시 계산을 수행합니다.
    송신상 문제가 없었다면 결괏값은 0000 0000으로 되고 이는 데이터 변조가 없음을 뜻하고
    계산 방식은 같은데 나머지가 나왔다가 다시 0이 나왔다가 반복한다고 해서 Cyclic 이 붙었습니다.

 

그렇다면 온라인 게임에서 어떻게 사용하나

상당수 온라인 게임에서 CRC를 목격할 수 있습니다.

이 CRC라는 게 내부에서 자체적으로 검사를 하는 경우도 있고 외부 프로그램을 이용하여

밖에서 검사를 하는 경우도 있습니다. 외부에서 검사하는 대표적인 게임 보안 프로그램은

넥슨에서 만든 Nexon Game Security, NGS가 있습니다.

 

내부적으로 검사를 하는 방식은 Cheat Engine의 Find out accesses를 이용하면

이 CRC 함수가 검사할 데이터를 읽어가야 하기 때문에 그 읽는 순간에 걸리기 때문에

생각보다 취약하기도 합니다. 거기에 이 CRC 함수가 도는 주기라는 것이 있는데

이 주기가 생각보다 길면 또 문제가 생깁니다. 바로 해커들이 이 주기를 이용하는 거죠.

그 주기를 보고 CRC 함수가 돌 때쯤 변조해놓았던 메모리들을 원래대로 돌려버리고

그 주기가 지나고 난 뒤에 다시 적용하는 식으로 이미 공격을 당한 전례가 있습니다..

 

그렇게 되면 CRC 도는 주기를 엄청 짧게 설정할 수밖에 없는데 이렇게 되면 또

거지 같은 문제가 발생하는 이유가 함수가 과도하게 실행된다는 것은 곧 프로그램

과부하에 직접적인 문제가 됩니다. 옛날에 게임하시다가 갑자기 버벅거린다던가

느려진다던가 이런 경험을 하신 적이 있으실 겁니다.

 

그냥 단순히 컴퓨터의 문제일 수도 있었겠지만 저렇게 CRC 주기의 문제로

일어나는 렉이었을 수도 있다는 얘기죠.. 즉 변조를 막는다라는 취지는 좋은데

유저들이 이 렉을 감수하고 게임을 해야 하는 불편함이 생겨버립니다.

 

결국 이러한 문제들로 인해 요즘 추세는 외부 보안 프로그램에서 게임 클라이언트

메모리 변조를 감지하는 방식을 하는 걸로 알고 있습니다. 외부로 돌려버리면 우선

저 도는 주기를 정확하게 파악을 할 수가 없게 되고 Find out accesses 같은 단순

디버깅으로도 나오지 않는 것도 한몫합니다.

 

물론 이렇게 해도 그 외부 프로그램이 분석당하면 똑같이 답이 없는 건 맞지만

적어도 비교적 리버싱 실력이 약한 해커들은 대부분 차단을 할 수 있다는 점과

외부에서 검사를 하게 되니 게임 클라이언트 자체는 렉을 크게 안 먹는 것으로

유저들에게 그런 불편한 경험을 제공할 필요가 없어지는 게 장점이겠죠.

 

간단하게 게임 안에서의 CRC는 어떻게 생겼는지 보고 마무리 하겠습니다.

이 CRC Bypassing에 대한 정확한 답은 드릴 수가 없기 때문에... 이 부분은

양해해주시면 감사하겠습니다.

 

내부 CRC

아무래도 제 기억에 내부 CRC를 확인할 수 있는 게임은 MapleStory가 아닐까 합니다.

 

MapleStory

 

이런 식으로 MapleStory.exe+1000 이 부분에다가 Find out accesses를 건 상황입니다.

 

MapleStory

 

문제는 이런식으로 내부 CRC는 하나의 함수로 방어를 할 수가 없습니다.

하나의 함수로만 방어를 할 경우 그 CRC 함수 하나만 조지면 바로 변조가 가능한 건데

1번 CRC가 전체 메모리를 방어한다 하면 2번 CRC가 1번 CRC가 변조 됐는지 검사하고
3번 CRC가 2번 CRC가 변조 됐는지 검사하면서 전체 메모리도 한 번씩 보고....
대충 이런 식의 구조로 돌아간다는 거죠. 렉이 안 걸리려야 안 걸릴 수가 없는 구조겠죠...

 

요즘은 워낙 컴퓨터가 좋아지고 게임사 측에서도 최적화는 계속할 테니까 큰 체감을

못할 수도 있겠습니다만.. 어쨌든 요런 방식이 내부 CRC입니다.

 

외부 CRC

 

BlackCipher64.aes

 

대표적인 게 NGS라 했으니 NGS의 실질적인 영역인 BlackCipher64.aes에서 메모리 CRC가 있습니다.

메모리 부분을 안 건든다고 해도 분석을 하려면 결국 일부분은 Bypassing을 해야 가능하겠죠...

 

오늘은 CRC가 무엇이고 어떻게 돌아가며 어디에 있는지 정도만 알아봤습니다.

이전 글들에서 간단한 게임 치트라고 한 게 엄청 편하게 앉아서 분석하는 거고 보안이 이렇게 달리면

노가다의 양은 배가 되겠죠. 

728x90