[소고] 사설 서버 대응 전략

어느 분야나 난제 혹은 미제 같은 문제들이 항상 있기 마련이다. 이런 문제들은 새롭게 도메인에 접근하는 이들에게는 자신의 존재감을 증명할 수 있는 새로운 기회로 다가가기도 하고, 기존에 그 분야에 일하는 종사자들에게는 혹 같은 느낌이기도 하고, 실제로 피해를 당하는 입장에서는 골치 덩어리이기도 하다.

게임 보안 분야에서는 사설 서버 혹은 무료 서버라고 불리는 것들도 이런 문제 중에 하나다. 현재까지 해당 문제에 대해서 이렇다 할만한 뚜렷한 대응책도 존재하지 않고, 문제가 발생해 버리면 사실상 통제하기도 힘든 상태다. 그렇다고 사설 서버 문제가 심각하지 않은 것도 아니다. 일부 유명 게임의 경우에는 사설 서버가 웬만한 정식 게임 서비스보다 규모가 더 큰 경우도 심심찮게 존재한다.

사설 서버란 정식으로 인가 받지 않은 사람 또는 회사가 게임을 불법적으로 서비스하는 행위를 말한다. 사설 서버는 어찌 보면 온라인 게임이란 서비스와 그 유래를 같이 한다고 볼 수 있다. 온라인 게임의 초창기에 유행했던 사설 서버 중에 하나로 프리 배틀넷이 있다. 초창기 배틀넷은 스타크래프트란 게임을 구매한 사용자들끼리 인터넷을 통해서 같이 게임을 즐길 수 있도록 만들어주는 중계 서버 역할을 했다. 배틀넷에 접속하기 위해서는 게임을 구매한 내역에 해당하는 시디키라는 것이 있어야 한다. 시디키가 없다면 불법 복제로 간주되어 배틀넷 서버에 접속할 수가 없다. 불법 복제가 만연하던 시절, 불법 복제 사용자들의 배틀넷 욕구를 채워준 것이 프리 배틀넷이다. 프리 배틀넷은 스타크래프 제작사인 블리자드가 운영하는 것이 아닌 개인이 임의로 서버를 구축해서 운영하는 사설 서버였기 때문에 불법 복제 시디로 게임을 하는 사용자도 접속할 수 있었다.

초창기 사설 서버는 프리 배틀넷과 마찬가지로 이윤 창출 보다는 개인의 호기심과 참을 수 없는 무한 공유 정신에 그 기반을 두고 있다. 그렇기에 이윤과는 무관한 경우가 많았고 운영 또한 영세하게 이루어지는 경우가 많았다. 하지만 요즘의 사설 서버는 이런 초창기 목적과는 많이 달라졌다. 대부분 영리를 목적으로 유료로 운영하는 경우가 많고, 규모 또한 경우에 따라서는 무척 크기도 하다. 게임사 입장에서는 당연히 정식 서비스로 유입되어야 하는 트래픽을 사설 서버에게 뺏기는 셈이 되기 때문에 상당한 피해를 본다고 할 수 있다. 프리 배틀넷의 경우에도 영세한 규모이긴 하지만 블리자드 입장에서는 시디 구매로 이어져야 할 수요가 프리 배틀넷의 존재 때문에 연결되지 않았기 때문에 일정부분 피해를 입었다고 할 수 있다.

그렇다면 이렇게 게임사의 골치를 썩이는 사설 서버는 도대체 왜 생겨나는 것일까? 자본주의 사회에서 벌어지는 모든 나쁜 문제들이 그렇겠지만 이 또한 그 근본적인 원인에는 ‘돈’이 있다. 불법적으로 손쉽게 돈을 벌려고 하는 사설 서버 운영자, 그들에게 바이너리 파일이나 소스 코드를 유출시켜 부당한 이윤을 취득하고 싶어하는 게임 퍼블리셔나 게임 개발사의 관계자, 정식 서비스의 비싼 컨텐츠 사용료를 감당하지 못하기에 보다 저렴한 비용으로 컨텐츠를 체험해 보고 싶어하는 사용자 들의 이해관계가 복잡하게 얽혀서 사설 서버 생태계는 유지된다.

그렇다면 무료 사설서버야 그렇겠지만 유로로 운영하는 사설 서버는 어떻게 유지되는 것일까? 게이머 입장에서는 어차피 굳이 비용을 지불해야 한다면 합법적인 서비스를 이용하는 편이 마음도 편할 테니 말이다. 여기에도 정말 다양한 이유가 있다.

첫째는 가격이다. 유료로 운영한다고는 하지만 정식 서비스 보다는 훨씬 저렴한 비용으로 즐길 수 있는 경우가 대부분이다. 이는 사설 서버의 경우에는 정식 서비스만큼 충분한 수의 운영 인력을 유지할 필요도 없고, 정식 서비스의 인기에 편승해서 운영하는 것이기 때문에 별도로 마케팅 비용을 지출할 필요도 없다. 그리고 가장 중요한 문제이지만 사설 서버 운영자는 게임 컨텐츠 개발에 투입되는 비용 중 단돈 1원도 지불하지 않았기 때문에 정식 서비스보다는 훨씬 저렴하게 운영해도 유지가 되는 것이다.

둘째는 접근 가능한 컨텐츠의 범위다. 정식 서비스에서는 제공하지 않은 게임 마스터가 사용할 수 있는 아이템을 사용해 볼 수 있다거나, 정식 서비스에서는 절대로 불가능한 터무니 없는 능력치의 아이템이나 이동 불가능한 지역과 갈은 컨텐츠를 사용해 볼 수 있다. 심지어는 드물긴 하지만 사설 서버가 정식 서비스보다 더 빠르게 신규 컨텐츠를 제공하는 경우도 있다. 말이 안 되는 것 같은데, 이게 가능한 이유는 게임사에서 대규모 패치를 하기 전에는 일반적으로 일정 기간 전부터 관련 컨텐츠 파일을 조금씩 클라이언트에 미리 전달하는 경우가 있기에 가능하다. 이렇게 미리 전송된 클라이언트 정보를 분석해서 사설 서버에서 컨텐츠를 먼저 오픈해 버리는 것이다.

끝으로 대다수 경우는 아니지만 정식 서비스보다 더 나은 운영 품질을 사설 서버가 제공하기에 그곳에서 게임하는 사용자들도 존재한다. 정식 서비스의 경우에는 아무래도 규모가 크다 보니 소규모 커뮤니티와 같은 친밀감은 느끼기가 힘들다. 하지만 사설 서버는 상대적으로 사용자가 적기 때문에 운영자와 유대감을 형성하기가 훨씬 더 쉽다는 측면이 있다.

사설 서버의 탄생 배경에 따른 대응 전략

사설 서버가 무엇인지 그리고 그 생태계가 어떻게 구성되는지에 대해서 살펴 보았다. 지금부터는 기술적으로 사설 서버가 만들어지는 경로에 대해서 살펴보도록 하자. 이 내용을 이해하는 것은 무척 중요한 문제인데, 왜냐하면 생성 경로에 따라서 대응 전략도 달라져야 하기 때문이다. 사설 서버는 크게 세가지 정도의 경로를 통해서 만들어진다.

첫째는 서버 바이너리 파일이 유출되는 경우다. 여기에도 세부적으로 유출되는 여러 가지 요인이 있다. 게임 개발사나 게임 운영사의 관계자가 유출시키는 경우, 바이너리 파일이 담겨 있는 서버가 해킹 당해서 해커에 의해 탈취되는 경우, 심지어는 게임 서버 자체가 물리적으로 도난 또는 교체되는 경우도 있다.

바이너리 유출을 원천적으로 차단할 수 있는 방법은 없다. 인재의 경우는 각종 보안 장치들을 강화해서 절대 그런 일이 없도록 만들겠다는 의지를 불태울 수 있겠지만 미봉책에 불과할 뿐이다. 왜냐하면 누군가는 반드시 파일에 접근해서 작업할 수 있는 높은 권한을 가질 수 밖에 없기 때문이다. 그런 사람이 나쁜 마음을 먹는다면 얼마든지 사고는 벌어질 수 있다. 따라서 사람을 거쳐서 유출되는 것을 원천적으로 차단한다는 것은 불가능에 가깝다. 서버 머신의 물리적인 도난도 자연재해와 마찬가지로 벌어진다면 그걸 피할 방법은 사실상 없다. 그나마 대응할 수 있는 영역이 해킹을 해서 파일을 탈취하는 행위다. 이 경우는 각종 보안 시스템을 강화해서 일정 수준 이상의 보안 수준을 유지함으로써 어느 정도 대비를 할 수 있다.

바이너리 파일 유출의 경우 사전에 방지할 수 있는 근본적인 방법은 없기 때문에 파일 유출이 벌어지더라도 의미가 없도록 만드는 사후 대응 전략이 보다 효과적이다. 인가되지 않은 곳에서 바이너리 파일을 들고 가서 서버를 켜더라도 정상적으로 동작하지 않도록 만드는 것이다. 이런 전략의 하나로는 게임 서버에 대한 인증 서버를 두는 방법이 많이 사용된다. 게임 서버가 별도의 인증 서버의 인증을 통과해야만 동작하도록 만드는 것이다. 통상적으로 이러한 인증 서버를 마스터 서버라고 부른다. 마스터 서버가 단순한 온/오프 식의 인증 처리만 해서는 사실상 소용이 없다. 파일을 탈취할 정도라면 그 정도 인증은 손쉽게 무력화 시킬 수 있기 때문이다. 그보다는 좀 더 복잡한 대응이 필요하다. 일반적으로는 게임 서버 구동에 필요한 각종 데이터를 마스터 서버에 의존하도록 만드는 방법을 많이 사용한다. 해당 데이터는 마스터 서버와의 인증이 되는 순간 마스터 서버로부터 전송을 받고 파일로 기록은 하지 않는 형태로 구성해야 한다. 그래야 실질적으로 바이너리 파일 유출에 대한 통제를 할 수 있다. 물론 이 경우에도 마스터 서버가 가지고 있는 데이터 셋이나 마스터 서버의 바이너리가 똑같이 다 유출된다면 막을 방법은 없다. 하지만 마스터 서버의 경우 서버간 통신만 발생하기 때문에 서버 자체를 게임 개발사에서 보유할 수 있다는 점 때문에 유출의 위험성이 일반 게임 서버 보다는 훨씬 낮다는 정도로 생각하는 것이 좋겠다.

두 번째 유출 경로는 소스 코드가 유출되는 경우다. 이 경우도 바이너리 유출과 마찬가지로 사람을 통해서 유출되는 경우가 있을 수 있고, 해커에 의해 탈취 당하는 경우가 있을 수 있다. 소스 코드 유출이기 때문에 앞선 바이너리 유출 보다는 상황이 더 심각하지만 안타깝게도 앞선 바이너리 유출과 마찬가지로 원천적인 차단 방법은 존재하지 않는다. 이 경우에 할 수 있는 사후 대응은 서버의 구조를 확 변경하는 작업이지만 이 또한 쉽지 않다. 사전에 예방할 수 있는 방법으로는 소스 코드를 분산 배치 시키는 방법을 들 수 있다. 해커가 소스 코드를 탈취하더라도 게임 서버의 전체 코드가 아닌 일부 코드가 되도록 만드는 것이다.

마지막 생성 경로는 말 그대로 해커들의 리버싱을 통해서 만들어지는 경우를 들 수 있다. 클라이언트와 해당 클라이언트가 정식 서버와 통신하는 내용을 토대로 상상에 나래를 펼쳐서 서버를 바닥부터 직접 제작하는 것이다. 이렇게 무식하게 만드는 경우가 있을까 싶지만 오래된 게임들의 경우는 상당 시간 동안 분석이 진행되기 때문에 이렇게 직접적으로 모두 제작한 사설 서버가 나오기도 한다. 이런 서버는 게임 서버의 상태가 불안정하다는 점과 정식 게임 서버는 윈도우 기반인데 사설 서버는 리눅스 기반으로 만들어지는 경우와 같이 정식 게임 서버와는 전혀 다른 플랫폼으로 제작되는 경우가 있다는 점이 특징이다.

사설 서버와 보안 코드

현대적인 게임 제작에는 천문학적인 금액이 투입되는 만큼 보안에도 철저하게 신경을 쓰는 추세로 바뀌고 있다. 다양한 보안 장벽을 통해서 물리적인 보안에 대해서 강화를 해 나가는 동시에 게임 프로그램 자체의 보안에도 많은 신경을 쓴다. 그러다 보니 자연스럽게 외부 보안 코드를 사용하기도 하고, 내부 개발팀에서 제작한 보안 코드를 사용하기도 한다. 그러다 보면 게임 프로그래머 입장에서는 자연스럽게 왜 그런 코드들을 통해서 사설 서버에 대응할 수 없는지 궁금증이 생긴다. 여기에는 기존 보안 코드 체계가 가진 구조적인 특징에 기인한다고 할 수 있다. 사설 서버가 만들어지는 자세한 과정을 통해서 왜 기존 보안 코드 체계가 사설 서버에 대응력을 가지지 못하는지에 대해서 알아보도록 하자.

<그림 1>에는 일반적인 온라인 게임 구조가 나와 있다. 게임 클라이언트가 있고, 네트워크를 통해서 게임 서버에 접속해서 게임을 하는 구조의 많은 게임들이 <그림 1>과 같은 구조로 동작한다. 요즘은 여기에다 별도로 추가적으로 외부 보안 솔루션 코드나 게임사에서 개발한 자체 보안 코드를 추가하는 작업을 한다. 그렇게 하면 <그림 2>와 같은 구조로 게임 구성이 변경된다. 기존의 게임 클라이언트/서버에 각각 보안 코드와 인터페이싱하는 부분이 추가되어 있다.

게임 클라이언트에 추가된 보안 코드는 각종 해킹툴 탐지, 게임 클라이언트의 무결성 검증, 정상적인 게임 서버와 통신을 하는지에 대한 체크 등을 수행한다. 게임 서버에 탑재된 보안 코드는 게임 서버가 정상적인 게임 클라이언트와 통신을 하고 있는지에 대한 인증을 수행한다. 각각의 코드를 통해서 우리는 게임 클라이언트와 서버 모두에서 양쪽을 검증할 수 있는 체계를 갖출 수 있다.

<그림 3>에는 <그림 2>와 같은 상황에서 해커가 게임 클라이언트를 공격하면 어떤 일이 벌어지는지를 보여준다. 해커는 게임 클라이언트 파일을 언팩하고 보안 코드와 연동된 부위를 제거하는 작업을 진행해서 게임 클라이언트에 포함된 보안 장치들을 무력화 시킨다. 이렇게 할 경우 게임 클라이언트가 구동하더라도 보안 코드는 아예 실행되지 않는다. 앞서도 언급한 것처럼 서버 쪽에 보안 코드가 있다면 그를 통해서 클라이언트의 무결성을 검증할 수 있다는 가능성은 있기 때문에 <그림 3>의 단계에서는 아직까지 어떻게든 대응 해볼 수 있는 상태다.

<그림 4>는 <그림 3>과는 반대로 해커가 게임 서버 쪽을 공격한 예가 나와 있다. 게임 서버를 유출 시키거나 게임 프로토콜을 리버싱해서 직접 만든 서버를 운영하는 것이다. 이 경우에도 클라이언트 쪽에는 보안 코드가 있기 때문에 이를 통해서 합법적인 게임 서버로의 접근인지에 대한 유효성을 간접적으로 검증할 수 있다.

<그림 3>에 나와 있는 클라이언트 측의 공격이나 <그림 4>에 나와 있는 서버 쪽의 공격이 단편적으로 벌어지는 경우에는 여전히 반대쪽의 보안 코드가 있기 때문에 무엇을 해볼 수 있는 여지가 있다. 진짜 무서운 일은 이 둘이 결합했을 때 벌어진다. <그림 5>에는 이렇게 클라이언트와 서버 쪽을 모두 공격해서 둘 다 교체한 상태를 보여준다. 말 그대로 클라이언트, 서버 모두 변조된 상태고, 둘 모두에서 보안 코드는 제거되었다. 이런 구조적인 특징 때문에 이 상황에서 보안 코드가 할 수 있는 일은 아무것도 없다. 이건 사실 클라이언트, 서버의 공격이라고 하기 보다는 아예 또 다른 게임이 하나 더 만들어진 것과 같은 상황이라고 할 수 있다. 안타깝지만 불편한 진실은 현실 세계에서 통용되는 대다수의 사설 서버가 <그림 5>와 같은 구조로 동작한다는 점이다.

사설 서버 대응의 가장 본질적인 어려움은 <그림 5>와 같은 단계가 일단 되고 나면 해당 상황까지 해커가 만든 결과물을 제어하는 일이 사실상 통제 불가능한 상황에 도달한다는 점에 있다. 이게 무슨 말이냐 하면 <그림 5>의 단계에 이르면 그 어떤 방법으로도 이미 유포된 사설 서버를 제어할 수 없다는 의미다. 게임에 보안 코드를 강화하고 추가적인 바이너리 패치를 하고, 서버 구조를 변경하여도 이미 사설 서버용으로 배포된 과거의 클라이언트와 서버는 여전히 동작 가능하기 때문이다. 최근 인터넷에서 논란이 되고 있는 ‘잊혀질 권리’라는 것이 사설 서버에는 존재하지 않는 셈이다. 법적 대응을 제외하고 과거 버전으로 운영되는 사설 서버에 대응할 방법은 전혀 없다.

사설 서버 문제를 제대로 바라보기 위해서는 우리가 무엇을 도난 당하고 있는지에 대해서 냉철하게 생각할 필요가 있다. 과연 우리는 무엇을 도난 당한 것일까? 서버 코드, 게임 서버 머신, 프로토콜 설계, 클라이언트의 동작 구조, 클라이언트 소스 코드 이런 것들일까? 안타깝지만 본질은 그곳에 있지 않다. 사설 서버 운영자가 저런 것들을 모두 들고 있다고 해서 사용자들이 거기에 비용을 지불하는 것은 아니기 때문이다. 게임사에서 도난 당한 진짜 보물은 게임 사용자들이 비용을 지불하는 본질, 바로 게임 컨텐츠에 있다.

문제의 본질이 컨텐츠에 있다는 것이 어떻게 보면 사설 서버 대응의 새로운 가능성을 제시해 준다. 온라인 게임은 운영이 지속되는 동안 컨텐츠 또한 지속적으로 업데이트된다. <그림 5>와 같은 단계가 되면 과거 버전까지의 컨텐츠는 모두 도난 당한 것이라고 생각할 수 있지만 앞으로 만들 컨텐츠까지 도난 당한 것은 아니다. 따라서 우리가 충분히 신경 쓴다면 앞으로 생산할 컨텐츠는 사설 서버로부터 보호할 수 있다. 사설 서버 대응의 초점은 바로 신규 컨텐츠 보호에 맞추어야 한다.

플랫폼으로서의 보안

아이러니하게도 보안의 관점에서 보자면 사설 서버에 대한 대응은 클라이언트 측면에서 먼저 이루어져야 한다. 앞서도 살펴본 것과 같이 클라이언트 측의 보안 코드가 너무 쉽게 제거된다는 것에서 모든 문제가 출발하기 때문이다. 일반적으로 클라이언트 보안 코드의 무결성은 게임 서버에 의존하는 경우가 많다. 하지만 사설 서버의 경우에는 게임 서버가 독립적으로 제작되기 때문에 이러한 방식이 통하지 않는다. 따라서 클라이언트 자체적으로 게임과 분리가 어렵도록 만드는 작업을 먼저 해야 한다.

그렇다면 보안 코드와 게임은 왜 손쉽게 분리될까? 이는 소프트웨어 공학적으로 이야기하면 보안 코드와 게임 코드 사이에 결합도가 높지 않기 때문이다. 소프트웨어 공학적으로만 이야기하자면 좋은 구조인 셈이다. 하지만 이렇게 결합도가 낮다는 것은 해커 입장에서는 손쉽게 떼어낼 수 있다는 것을 의미한다. 이뿐이 아니다. 통상적으로 보안 코드가 외부 확장 모듈에 존재하는 경우가 많은데 이는 해커들의 작업을 더욱 쉽게 만든다.

이런 논의가 출발에는 대부분 보안 코드의 노출되는 API 종류를 늘리고 API가 게임과 인터페이싱 하는 형태를 복잡하게 만들어서 결합도를 높여야 한다는 의견이 나온다. 하지만 이는 크게 의미 없는 행위다. 왜냐하면 인터페이스 코드가 아무리 복잡해져도 여전히 보안 코드는 게임 구동에 필수적인 요소는 아니기 때문이다.

약간 생각을 바꿔서 이런 질문을 해보자. 왜 보안 코드는 손쉽게 제거할 수 있는데 운영체제 코드는 제거할 수 없을까? 보안 코드를 제거하듯이 게임에서 윈도우 관련 코드를 제거하고 리눅스에서 실행시킬 수는 없을까? 왜 보안 코드보다 윈도우 코드를 제거하는 일이 어려울까? 윈도우 코드도 모두 외부 확장 모듈에 존재하는데 말이다.

그건 바로 윈도우 코드와 보안 코드가 게임에 가지는 의미가 다르기 때문이다. 보안 코드는 없어도 게임이 실행되는데 아무런 영향이 없지만 윈도우 코드가 없으면 게임이 실행조차 될 수 없다는 의미다. 즉, 앞서 API를 복잡하게 만들자는 생각은 형식론적인 관점에서 결합도를 높이자는 이야기다. 하지만 이런 전략은 도움이 되지 않는다. 왜냐하면 아무리 형식론적인 관점에서 결합도를 높여봤자 내용적인 측면에서 여전히 보안 코드는 게임 구동을 위한 필수 요소는 아니라는 점에는 변함이 없기 때문이다. 형식적인 측면에서의 결합도를 높이는 작업이 아닌 내용적인 측면에서의 결합도를 높여야 한다.

보안 코드 자체가 게임에게 일종의 플랫폼으로 다가가야 한다. 게임이 실행되기 위해서는 반드시 필요한 서비스들이 있다. 파일을 읽고 쓰는 작업, 메모리를 할당하고 해제하는 작업, 외부 확정 모듈을 로드하고 언로드하는 작업, 그래픽 드라이버를 구동시키고 화면 제어를 하는 작업, 사운드 카드를 제어하는 작업 등등. 실제로 게임이 구동되기 위해서는 반드시 필요한 핵심 서비스들이 있다. 일반적으로 이러한 서비스는 운영체제에서 제공해 준다. 하지만 이제는 보안 코드에서 이러한 서비스들을 제공해 주도록 변경해야 한다. 설령 그것이 운영체제와 게임 사이에서 대리인 역할만 할지라도 말이다. 그렇게 내용적인 측면의 결합도가 높아져야 해커 입장에서 본질적으로 보안 코드를 제거하기가 어려워진다.

프로토콜 보호

게임 클라이언트와 보안 코드 사이의 내용적인 결합도를 일정수준 이상으로 높였다면 그 다음은 프로토콜을 손볼 차례다. 해커 입장에서 사설 서버를 제작하기 위해서는 반드시 게임 프로토콜을 전부 이해해야 하기 때문에 프로토콜은 매우 중요한 부분이다. 중요한 부분이지만 여기에도 대응하기가 쉽지 않은 부분이 있다. 바로 완성된 게임의 경우에는 게임 프로토콜을 손쉽게 변경할 수 없다는 점이다. 게임 서비스의 안정성과도 밀접한 연관이 있기 때문이다.

모든 보안이 그렇겠지만 프로토콜이 노출되지 않도록 만드는 것은 불가능하다. 일단 프로토콜은 노출된다는 것을 전제에 두고 생각해야 한다. 따라서 프로토콜을 복잡하게 만들어서 절대 분석하지 못하도록 만들겠다는 전략보다는 프로토콜이 노출되더라도 손쉽고 안전하게 전체 구조를 변경할 수 있는 장치를 만드는 것이 더 좋은 전략이다. 여기에도 게임을 처음부터 새롭게 만든다면 프로토콜 설계를 그러한 방식으로 할 수 있겠지만 이미 만들어진 게임이라면 전체 구조를 변경할 수 있는 장치를 추가하는 것도 쉬운 일은 아니다. 이럴 때 쓸 수 있는 전략 중에 하나가 바이트 스트림 변형기를 이용하는 방법이다.

<그림 6>에는 기존 게임 클라이언트, 서버에 스트림 변형기가 추가된 구조를 보여준다. 게임 클라이언트와 서버가 직접 통신하던 전에 방식이 아니라 네트워크 어댑터라고 불리는 스트림 변형기를 통해서 통신을 진행한다. 이렇게 하면 기존의 프로토콜 코드는 손대지 않고서 네트워크를 통해서 전송되는 바이트의 형태만 변형해서 실제로 프로토콜이 변경된 것처럼 보여지게 만드는 작업을 할 수 있다.

<그림 6>에는 네트워크 어댑터를 통해서 통신이 진행되는 실질적인 과정이 나와 있다. 왼쪽이 클라이언트, 오른쪽이 서버인 경우에 클라이언트에서 서버로 전송하는 과정을 나타낸 그림이다. 왼쪽부터 살펴보면 프로토콜 레이어에서 내려온 바이트를 전송 큐에 넣은 것을 최종적으로 전송하기 전에 네트워크 어탭터를 통해서 바이트 스트림을 변형해서 전송한다. 마찬가지로 서버 쪽에서도 받은 데이터를 네트워크 어댑터를 통해서 바이트 변환을 복구한 다음 수신 큐에 데이터를 넣는 구조로 되어 있다. 이렇게 작성할 경우에 기존 프로토콜 코드는 건드리지 않고 실질적으로 네트워크를 통해서 전달되는 패킷의 구조를 다르게 변형시킬 수 있다. 더불어 해커가 네트워크 어댑터 코드를 분석했다고 하더라도 해당 어댑터 코드만 새롭게 변형해서 손쉽게 다른 구조로 변경할 수 있다는 장점이 있다.

<그림 7>의 네트워크 어댑터의 경우에는 기존 프로토콜 코드를 하나도 수정하지 않고 변형하는 형태이기 때문에 변형이 바이트 단위의 작업으로 제한된다. 결국 비트 연산 외에는 할 수 있는 작업이 없다. 비트 단위의 연산 또한 문맥을 고려하기 어렵기 때문에 궁극적으로 대칭적인 구조의 변형 작업밖에는 할 수 없다는 단점이 있다. 이런 단점을 극복하기 위해서는 결국 바이트 단위가 아닌 조금 더 큰 규모에서 변형을 가할 수 있어야 한다. 추가적인 개발 리소스 투입이 가능한 상황이라면 프로토콜을 이중화 시키는 방법 또한 생각해 볼 수 있다. 프로토콜 이중화란 기존 프로토콜을 새로운 형태의 프로토콜로 감싸는 작업을 하는 것을 말한다. 물론 신규 프로토콜은 일정 양의 데이터를 전송하는 기능을 하는 메타 프로토콜이기 때문에 복잡하게 구성할 필요는 없다.