어플리케이션 보안

어플리케이션 보안은 보안 개발 관행부터 출시 후 게임 컨텐츠 보호까지 모든 것을 아우르는 넓은 주제입니다. 이 매뉴얼에서는 여러 영역을 다루고, Defold 엔진, 도구, 서비스를 사용할 때의 어플리케이션 보안 맥락에서 이를 설명합니다.

• 지식재산 보호
• 안티 치트 솔루션
• 보안 네트워크 통신
• 서드파티 소프트웨어 사용
• 클라우드 빌드 서버 사용
• 다운로드 가능한 컨텐츠

도용으로부터 지식재산 보호하기

대부분의 개발자가 걱정하는 문제 중 하나는 자신의 창작물을 도용으로부터 보호하는 방법입니다. 법적 관점에서 저작권, 특허, 상표는 비디오 게임 지식재산의 서로 다른 측면을 보호하는 데 사용할 수 있습니다. 저작권은 소유자에게 창작물을 배포할 독점적 권리를 부여하고, 특허는 발명품을 보호하며, 상표는 이름, 심볼, 로고를 보호합니다.

게임의 창작물을 보호하기 위해 기술적인 예방 조치를 취하는 것도 바람직할 수 있습니다. 하지만 게임이 플레이어의 손에 들어간 뒤에는 에셋을 추출할 방법을 찾는 것이 가능하다는 점을 기억해야 합니다. 이는 게임 어플리케이션과 파일을 리버스 엔지니어링해서도 가능하지만, 텍스쳐와 모델이 GPU로 전송될 때 또는 다른 에셋이 메모리에 로드될 때 도구를 사용해 추출하는 방식으로도 가능합니다.

이런 이유로, 사용자가 게임의 에셋을 추출하려고 마음먹었다면 결국 그렇게 할 수 있다는 것이 우리의 일반적인 입장입니다.

개발자는 에셋 추출을 더 어렵게 만들기 위해 자체 보호 기능을 추가할 수는 있지만, 불가능하게 만들 수는 없습니다. 일반적으로 여기에는 게임 에셋을 보호하고 숨기기 위한 다양한 암호화와 난독화 방법이 포함됩니다.

소스 코드 난독화

소스 코드 난독화 적용은 프로그램의 출력 결과에는 영향을 주지 않으면서, 사람이 소스 코드를 이해하기 어렵도록 의도적으로 만드는 자동화 프로세스입니다. 목적은 보통 도용을 막는 것이지만, 치팅을 더 어렵게 만드는 데도 있습니다.

Defold에서는 빌드 전 단계로 또는 Defold 빌드 프로세스에 통합된 부분으로 소스 코드 난독화를 적용할 수 있습니다. 빌드 전 난독화에서는 Defold 빌드 프로세스를 시작하기 전에 난독화 도구를 사용해 소스 코드를 난독화합니다.

반면 빌드 시점 난독화는 Lua builder plugin을 사용해 빌드 프로세스에 통합됩니다. Lua builder plugin은 원본 소스 코드를 입력으로 받아 난독화된 소스 코드 버전을 출력으로 반환합니다. 빌드 시점 난독화의 한 예는 GitHub에서 제공되는 Prometheus Lua obfuscator를 기반으로 한 Prometheus extension에 나와 있습니다. 아래는 Prometheus를 사용해 코드 조각을 공격적으로 난독화하는 예시입니다. 이런 종류의 강한 난독화는 Lua 코드의 런타임 성능에 영향을 준다는 점에 유의하세요.

예시:

function init(self)
 print("hello")
 test.greet("Bob")
end

난독화된 출력:

local v={"+qdW","ZK0tEKf=";"XP/IX3+="}for o,J in ipairs({{1;3};{1,1},{2,3}})do while J[1]<J[2]do v[J[1]],v[J[2]],J[1],J[2]=v[J[2]],v[J[1]],J[1]+1,J[2]-1 end end local function J(o)return v[o+45816]end do local o={["/"]=9;["8"]=48;["9"]=1;q=38,o=62;V=33;y=43,d=61,B=50,L=54;v=2;["0"]=21,n=31;p=63;R=5;N=3;i=10;e=35;C=7;l=56;a=47,J=58;m=59;["2"]=36;z=11;M=12;Z=26;O=18;["5"]=20;s=8,["4"]=30,P=55;w=4;U=29;Q=28;r=24,h=41;G=45;c=19;W=34,k=57;T=14,t=44,S=0;f=60;F=42,E=27;u=40;X=25,j=17;["3"]=23,b=13;["1"]=53;Y=32,A=22,K=6,["+"]=16,["6"]=46;["7"]=51;I=37;D=52;H=15,x=49,g=39}local J=type local x=string.sub local d=v local l=string.len local W=string.char local L=table.insert local w=table.concat local h=math.floor for v=1,#d,1 do local X=d[v]if J(X)=="string"then local J=l(X)local H={}local S=1 local k=0 local K=0 while S<=J do local v=x(X,S,S)local d=o[v]if d then k=k+d*64^(3-K)K=K+1 if K==4 then K=0 local o=h(k/65536)local v=h((k%65536)/256)local J=k%256 L(H,W(o,v,J))k=0 end elseif v=="="then L(H,W(h(k/65536)))if S>=J or x(X,S+1,S+1)~="="then L(H,W(h((k%65536)/256)))end break end S=S+1 end d[v]=w(H)end end end local function o(o)test[J(-45815)](o)end function init(v)print(J(-45813))o(J(-45814))end

리소스 암호화

Defold 빌드 프로세스 중에는 게임 리소스가 처리되어 Defold 엔진이 런타임에서 사용하기에 적합한 포멧으로 변환됩니다. 텍스쳐는 Basis Universal 포멧으로 컴파일되고, 컬렉션, 게임 오브젝트, 컴포넌트는 사람이 읽을 수 있는 텍스트 표현에서 대응되는 바이너리 형식으로 변환되며, Lua 소스 코드는 처리되어 바이트코드로 컴파일됩니다. 사운드 파일 같은 다른 에셋은 그대로 사용됩니다.

이 프로세스가 완료되면 에셋이 하나씩 게임 아카이브에 추가됩니다. 게임 아카이브는 큰 바이너리 파일이며, 아카이브 안에서 각 리소스가 위치한 곳은 아카이브 인덱스 파일에 저장됩니다. 포멧은 여기에 문서화되어 있습니다.

Lua 소스 파일은 아카이브에 추가되기 전에 선택적으로 암호화되기도 합니다. Defold에서 제공하는 기본 암호화는 게임 아카이브를 바이너리 파일 뷰어 도구로 검사할 때 코드 안의 문자열이 바로 보이지 않게 하는 데 사용되는 간단한 블록 암호입니다. Defold 소스 코드는 GitHub에서 공개되어 있고 암호 키도 소스 코드에 보이므로, 이를 암호학적으로 안전한 것으로 간주해서는 안 됩니다.

Resource encryption plugin을 구현하면 Lua 소스 파일에 커스텀 암호화를 추가할 수 있습니다. Resource encryption plugin은 빌드 프로세스의 일부로 리소스를 암호화하는 빌드 시점 부분과, 게임 아카이브에서 리소스를 읽을 때 이를 복호화하는 런타임 부분으로 구성됩니다. 자체 암호화의 시작점으로 사용할 수 있는 기본 Resource Encryption plugin은 GitHub에서 제공됩니다.

프로젝트 설정값 인코딩

game.project 파일은 어플리케이션 번들에 그대로 포함됩니다. 때로는 공개 API 액세스 키나 이와 비슷한 값처럼 민감하지만 반드시 비공개 성격은 아닐 수도 있는 값을 저장하고 싶을 수 있습니다. 이런 값의 보안을 강화하려면 값을 game.project에 저장하는 대신 어플리케이션 바이너리에 포함하면서도 sys.get_config_string() 및 유사한 함수 같은 Defold API 함수에서 계속 액세스할 수 있게 만들 수 있습니다. 이를 위해 game.project에 네이티브 익스텐션을 추가하고, Defold API 함수로 config 값을 가져올 때 자체 override를 제공하도록 DM_DECLARE_CONFIGFILE_EXTENSION 매크로를 사용할 수 있습니다. 시작점으로 사용할 수 있는 예제 프로젝트는 GitHub에서 제공됩니다.

치터로부터 게임 보호하기

비디오 게임에서의 치팅은 게임 산업 자체만큼 오래전부터 존재했습니다. 예전에는 인기 비디오 게임 잡지에서 치트 코드가 공유되었고, 초기 가정용 컴퓨터용으로 특수 치트 카트리지가 판매되기도 했습니다. 산업과 게임이 발전하면서 치터와 그들의 방법도 함께 발전했습니다. 게임에서 가장 흔한 치팅 방식은 다음과 같습니다.

• 커스텀 로직을 주입하기 위한 게임 컨텐츠 재패키징
• 게임이 정상보다 빠르거나 느리게 실행되도록 만드는 speed hack
• 자동 조준과 봇을 위한 자동화 및 시각 분석
• 점수, 목숨, 탄약 등을 수정하기 위한 코드 및 메모리 인젝션

치터로부터 보호하는 것은 어렵고, 거의 불가능에 가깝습니다. 게임이 원격 서버에서 실행되고 사용자의 기기로 직접 스트리밍되는 클라우드 게이밍조차 치터로부터 완전히 자유롭지는 않습니다.

Defold는 엔진이나 도구에서 안티 치트 솔루션을 제공하지 않으며, 대신 이러한 작업은 게임용 안티 치트 솔루션 제공을 전문으로 하는 여러 회사 중 하나에 맡겨야 합니다.

네트워크 통신 보호하기

Defold 소켓 및 HTTP 통신은 보안 소켓 연결을 지원합니다. 서버를 인증하고, 클라이언트에서 서버로 또는 그 반대로 전송되는 동안 교환 데이터의 프라이버시와 무결성을 보호하기 위해 모든 서버 통신에는 보안 연결을 사용하는 것이 좋습니다. Defold는 TLS 및 SSL 프로토콜의 널리 사용되고 널리 채택된 오픈 소스 구현인 Mbed TLS를 사용합니다. Mbed TLS는 ARM과 그 기술 파트너들이 개발합니다.

SSL 인증서 검증

네트워크 통신에 대한 중간자 공격을 방지하기 위해, 서버와 연결을 협상하는 SSL handshake 중 인증서 체인을 검증할 수 있습니다. Defold의 네트워크 클라이언트에 공개 키 목록을 제공하면 됩니다. 네트워크 통신을 보호하는 방법에 대한 자세한 내용은 network 매뉴얼의 SSL verification 섹션을 읽어보세요.

서드파티 소프트웨어 사용 시 보안

게임을 만들기 위해 서드파티 라이브러리나 네이티브 익스텐션을 사용할 필요는 없지만, 개발 속도를 높이기 위해 공식 Asset Portal의 에셋을 사용하는 것은 개발자들 사이에서 매우 흔한 관행이 되었습니다. Asset Portal에는 서드파티 SDK 통합부터 화면 관리자, UI 라이브러리, 카메라 등 다양한 에셋이 많이 있습니다.

Asset Portal의 어떤 에셋도 Defold Foundation의 검토를 받지 않았으며, Asset Portal을 통해 얻은 에셋 사용으로 인해 컴퓨터 시스템이나 기타 기기에 발생하는 손상 또는 데이터 손실에 대해 우리는 책임지지 않습니다. 자세한 세부 약관은 Terms and Conditions에서 읽을 수 있습니다.

에셋은 사용하기 전에 검토하는 것을 권장합니다. 프로젝트에 사용하기에 적합하다고 판단한 뒤에는 알아차리지 못한 사이에 에셋이 변경되지 않도록 해당 에셋을 fork하거나 복사본을 만드는 것이 좋습니다.

클라우드 빌드 서버 사용 시 보안

Defold 클라우드 빌드 서버, 일명 extender 서버는 개발자가 엔진 자체를 다시 빌드하지 않고도 Defold 엔진에 새 기능을 추가할 수 있도록 만들어졌습니다. 네이티브 코드가 포함된 Defold 프로젝트가 처음 빌드될 때 네이티브 코드와 관련 리소스가 클라우드 빌드 서버로 전송되고, 그곳에서 Defold 엔진의 커스텀 버전이 생성되어 개발자에게 다시 전송됩니다. 커스텀 어플리케이션 메니페스트를 사용해 엔진에서 사용하지 않는 컴포넌트를 제거하는 프로젝트를 빌드할 때도 같은 프로세스가 적용됩니다.

클라우드 빌드 서버는 AWS에서 호스팅되며 보안 모범 사례에 따라 생성됩니다. 하지만 Defold Foundation은 클라우드 빌드 서버가 사용자의 요구사항을 충족하거나, 결함이 없거나, 바이러스가 없거나, 안전하거나, 오류가 없거나, 서버 사용이 중단되지 않거나 안전하다는 것을 보장하지 않습니다. 자세한 세부 약관은 Terms and Conditions에서 읽을 수 있습니다.

빌드 서버의 보안과 가용성이 우려된다면 자체 프라이빗 빌드 서버를 설정하는 것을 권장합니다. 자체 서버를 설정하는 방법은 GitHub에 있는 extender 저장소의 main readme file에서 찾을 수 있습니다.

다운로드 가능한 컨텐츠 보호하기

Defold Live Update 시스템을 사용하면 개발자가 나중에 다운로드하고 사용할 컨텐츠를 메인 게임 번들에서 제외할 수 있습니다. 일반적인 사용 사례는 플레이어가 게임을 진행함에 따라 추가 레벨, 맵, 월드를 다운로드하는 것입니다.

제외된 컨텐츠가 다운로드되고 게임에서 사용할 준비가 되면, 사용 전에 엔진이 해당 컨텐츠를 검증합니다. 검증은 여러 검사로 구성됩니다.

• 바이너리 포멧이 올바른가?
• 다운로드한 컨텐츠가 현재 실행 중인 엔진 버전에서 지원되는가?
• 다운로드한 컨텐츠가 완전하며 누락된 파일이 없는가?

이 프로세스에 대한 자세한 내용은 Live Update 매뉴얼에서 읽을 수 있습니다.