kgc2014 one daylearnunitycryptography-f

111
하루 만에 배우는 유니티 암호화 프로그램 신승민 Qubit Security CEO

Upload: seungmin-shin

Post on 08-Jul-2015

1.732 views

Category:

Education


3 download

DESCRIPTION

하룻만에 배우는 유니티 암호화 프로그램

TRANSCRIPT

하루 만에 배우는유니티 암호화 프로그램

신승민

Qubit Security

CEO

CTO at WindySoft

• 10 years of online pc / unity game

Lecturer at Gachon Univ.

• 4 years of cryptography in game

Speaker

• 4th times at KGC since 2010

• 1st time at Gstar 2013

• 1st Time at NDC 2014

Used to make games

• Katamari Damacy Online PC game

Forcus on Game Security

• PC / Android

About me

차 례

1. 모바일 게임 해킹

2. 암호 알고리즘

3. 이론에서 현실로

- 카톡 vs 텔레그램

- 안전한 패스워드

4. 유니티를 이용하여 적용하기

5. 퍼블리셔의 요구사항

치트 앱(Cheat App)

핵심만 듣고 바로 적용해 보는

암호화 알고리즘

암호화에 사용한 도구와 서적

Bouncy Castle Crypto++ 5.6.2

사용한 암호화 알고리즘

• Algorithm: AES• CipherMode: CBC• Padding: PKCS7• Hash: SHA-3, SHA-2, md5

• Encoding: Base64

AES 암호 알고리즘은

• NIST 2000년 10월 2일 최종 선정 발표

• 키 길이: 128, 192, 256 bits• 블록 사이즈: 128 bit

Twofish, Serpent, MARS, RC6, Rijndael

SHA-3 해시 함수는

• NIST 2012년 10월 2일 최종 선정 발표

• 결과 값: 224, 256, 384, 512 bits

BLAKE, Grøstl, JH, Skein, Keccak

Kerckhoffs's principle

“A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.”

.Net Framework 4.5http://goo.gl/zA99Ju

System.Security.CryptographySymmetricAlgorithm Class

System.Security.Cryptography.AesSystem.Security.Cryptography.DESSystem.Security.Cryptography.RC2System.Security.Cryptography.RijndaelSystem.Security.Cryptography.TripleDES

.Net Framework 4.5http://goo.gl/MwWb58

System.Security.CryptographySymmetricAlgorithm Class

System.Security.Cryptography.Aes

CipherMode EnumerationMembers

CBC

.Net Framework 4.5http://goo.gl/7uzuBW

System.Security.CryptographySymmetricAlgorithm Class

System.Security.Cryptography.Aes

PaddingMode EnumerationMembers

PKCS7

.Net Framework 4.5http://goo.gl/zA99Ju

System.Security.CryptographyHashAlgorithm Class

System.Security.Cryptography.KeyedHashAlgorithmSystem.Security.Cryptography.MD5System.Security.Cryptography.RIPEMD160System.Security.Cryptography.SHA1System.Security.Cryptography.SHA256System.Security.Cryptography.SHA384System.Security.Cryptography.SHA512

http://sha3.codeplex.com

이론이 실제 사용될까요?

카카오톡 vs 텔레그램https://www.bpak.org

KakaoTalk vs Telegram

박세준’s Blog

1. 현재 카카오톡 메시지 전달 통신 구조

Hybrid Cryptosystem

• 클라이언트 – 서버 – 클라이언트 통신

• Handshake

– RSA 비대칭키 암호화

– AES 대칭키 공유

• 메시지 암호화– AES 알고리즘

카카오톡 프로토콜 문제점

• 클라이언트에서 암호화되어

• 서버로 전송된 메시지는 서버단에서 복호화된 뒤 저장

• 메시지 수신자 클라이언트에게 전송할 때 그 클라이언트와약속한 key를 이용하여 암호화해서 전송한다.

• 여기서 사실 메시지가 서버에 복호화되서 저장되느냐,

암호화된 채로 저장되느냐는 큰 차이가 없다

“서버에서 복호화 가능한 상태라는 것이 중요하다.”

End-to-End Encryption

• 서버가 해독할 수 없도록 하는 방식을 도입해야 하는데

여기서 등장하는 개념이 End-to-End Encryption

• 중간에서 메시지를 보관 및 릴레이 해주는 중계 서버가 필요하다. 이 때 그 서버를 믿을 수 없을 경우에 택하는 방식이다.

• 서버가 알지 못하는 key를 각 클라이언트들이 공유를 하고그걸 이용해서 자신들의 메시지를 암호화해서 전송하면

• 서버 입장에서는 암호화된 무의미한 데이터만 보고 저장할수 있을 뿐 딱히 할 수 있는 게 없다.

“누군가 이 자료를 빼가거나 달라고 요청해서 내주어도그게 서비스 운영자 입장에서 할 수 있는 전부라는 것이다.”

2. End-to-End Encryption

End-to-End Encryption

• 중요한 것은 각 클라이언트가 서로만이 알고 있는 비밀키를가지고 암호화를 한다는 점이다.

질문?

“다 좋은데.. 서버가 알 수 없도록 클라이언트간에 비밀키를어떻게 공유하지?”

“서버는 모르게 하면서”

3. Diffie-Hellman Key Exchange

DH 설명

모든 절차에 앞서 우선 Alice와 Bob은 비밀키 생성에 필요한파라미터인 p와 g를 공유한다. 그리고 Alice와 Bob 각각 비밀값인 a와 b를 선택한다.

1. Alice가 A (= ga mod p)를 계산하여 Bob에게 전송

2. Bob이 B (= gb mod p)를 계산하여 Alice에게 전송

3. Alice가 Bob에게 받은 B를 이용하여 s (= Ba mod p)를 계산

4. Bob이 Alice에게 받은 A를 이용하여 s (= Ab mod p)를 계산

5. 끝!

http://goo.gl/H4BXx5

4. Non-PFS 시스템에서의 문제

Perfect Forward Secrecy

• 클라이언트와 서버 사이에 통신할 때 쓰였던 서버 비밀키(private key)가 유출되었다고 가정해보자.

• 엄청난 대사고가 아닐 수 없다.

5. DH를 이용한 E2EE/PFS 시스템

DH를 이용한 E2EE/PFS 시스템

“서버 검열을 통해서든지, 네트워크 스니핑을 통해서든지

클라이언트/서버간의 통신 내용을 열람 할 수 있어도

할 수 있는 것이나 알 수 있는 것이 없다.”

• 먼저 각 클라이언트가 DH key exchange에 사용할g, p 파라미터를 교환한 뒤

• DH를 이용하여 공유(shared) 비밀키를 만든다.

• 여기까지 성공적으로 마쳤다면, 클라이언트는 서버가 알지못하는 비밀키를 가지고 있으니 이것으로 메시지들을 암호화하여 주고 받으면 된다.

Telegram - Encryption

• http://goo.gl/TvYyDG

• All chats are encrypted with the new MTProto protocol

created by Nicolai Durov, regardless of type.

• This is based on 256-bit symmetric AES encryption,

RSA 2048 encryption and Diffie–Hellman secure key

exchange.

MTProto encryption

• Note 1: Each plaintext message to be encrypted in MTProto always

contains the following data to be checked upon decryption in order

to make the system robust against known problems with the

components:

– server salt (64-Bit)

– session id

– message sequence number

– message length

– time

• Note 2: See additional comments on our use of IGE, SHA-1 and

modified encrypt-and-mac.

Q: Do you use IGE? IGE is broken!

• Yes, we use IGE, but it is not broken in our

implementation.

• IGE, just as the ubiquitous CBC, is vulnerable to

blockwise-adaptive CPA. But adaptive attacks are only

a threat for as long as the same key can be used in

several messages (not so in MTProto).

Q: Are you doing Encrypt-then-MAC,

MAC-then-Encrypt or Mac-and-Encrypt?

• Our scheme is closer to MAC-and-Encrypt with an

essential modification. Namely, the encryption key and

iv are hash-dependent.

– We use SHA1 for integrity check

– The SHA1 in question is for raw unencrypted data.

– The message key is SHA1-dependent.

– Note that the AES key and iv depend on that SHA1.

• The resulting data-dependent variable key denies all

common attacks.

Q:

Why do you use SHA-1 in the place of a MAC?

• Technically speaking, in our implementation SHA-1 can

be seen as a specific case of a MAC (but not HMAC),

since it is also used as an encryption key.

• We use it, because it is faster, especially when you

need to send photos or large videos (Telegram

supports videos and files up to 1Gb in size). And since

this means still requiring at least 2128 operations

(instead of 2256 with, say, SHA-2) to even begin trying to

break this scheme, the trade-off is quite fair.

Q: What’s this ‘Encryption Key’ thing?

• When a secret chat is created, the participating devices

exchange encryption keys using the so called Diffie-

Hellman key exchange.

• After the secure end-to-end connection has been

established, we generate a picture that visualizes the

encryption key for your chat.

• You can then compare this image with the one your

friend has — if the two images are the same, you can be

sure that the secret chat is secure and no man-in-the-

middle attack can possibly succeed.

Replay attacks

• Replay attacks are denied because each plaintext to be

encrypted contains the server salt and the unique

message id and sequence number.

Man-in-the-middle attacks

• Telegram has two modes of communication — ordinary

chats using client-server encryption and Secret Chats

using end-to-end encryption that are protected against

MiTM attacks.

• Client-Server communication is protected from MiTM-

attacks during DH key generation by means of a server

RSA public key embedded into client software. After

that, if both clients trust the server software, the Secret

Chats between them are protected by the server from

MiTM attacks.

Man-in-the-middle attacks

• The interface offers a way of

comparing Secret Chat keys for

users who do not trust the server.

• Visualizations of the key are

presented in the form of

identicons.

• By comparing key visualizations

users can make sure no MiTM

attack had taken place.

‘security through obscurity’ 전략

• 텔레그램 같은 경우,

• 내부적으로 자체 개발한 암호화 알고리즘을 사용하므로공격하기가 더 까다롭다.

“암호화 알고리즘이 아니라 프로토콜의 안정성에 있다.

그리고 그것은 MTProto 의 안정성에 의존한다.”

블록 암호의 선택

• “먼저 AES를 사용하고 다음으로 Serpent 나 Twofish 를

중복하여 암호화하는 방식이 바람직하다. 또한 각 암호화

블록마다 독립적인 키를 사용하는 것이 좋다 .“

• AES, ”128비트 키 16라운드, 192비트 키 20라운드,

256비트 키 28라운드 같이 라운드 증가시켜 사용하라!”

• AES, ”128비트 키 10라운드, 192비트 키 12라운드,

256비트 키 14라운드”

AES-Twofish-Serpent

.Net Framework 4.5http://goo.gl/BIPVBu

System.Security.CryptographyECDiffieHellman Class

ECDiffieHellmanCng Class

이론이 실제 사용될까요?

안전한 패스워드 저장http://goo.gl/dwUlOy

해시 Hash

솔팅 Salting

키 스트레칭 Key Stretching

Adaptive Key Derivation

PBKDF2DIGEST = PBKDF2(PRF, Password, Salt, c, DLen)

PRF: 난수(HMAC)

Password: 패스워드Salt: 솔트c: 원하는 iteration 반복 수DLen: 원하는 다이제스트 길이* NIST 승인된 알고리즘, 미국 정부 시스템에서 사용됨

Adaptive Key Derivation

bcrypt패스워드 저장 목적으로 설계Niels Provos & David Mazieres* OpenBSD 사용됨

Adaptive Key Derivation

scryptDIGEST = scrypt(Password, Salt, N, r, p, DLen)

Password: 패스워드Salt: 솔트N: CPU 비용r: 메모리 비용p: 병렬화(parallelization)DLen: 원하는 다이제스트 길이* Tarsnap에서 사용됨

.Net Framework 4.5http://goo.gl/vSCYt1

System.Security.CryptographyRfc2898DeriveBytes Class

PropertiesIterationCountSalt

Java Library for PBKDF2

http://goo.gl/TkBH6o

Java Library for PBKDF2

http://goo.gl/zdHD1E

참고 사이트

• “How to generate secure password hash :

MD5, SHA, PBKDF2, BCrypt examples”• http://goo.gl/EVw1xY

게임으로 돌아가 적용해 볼까요?

PlayerPrefs 암호화

Source codepublic static void SetString

(string _key, string _value, byte[] _secret, byte[] initVec)

{

Aes myAes = Aes.Create();

myAes.Key = _secret;

myAes.IV = initVec;

myAes.Mode = CipherMode.CBC;

myAes.Padding = PaddingMode.PKCS7;

}

Build & Run

regedt32

게임으로 돌아가 적용해 볼까요?

Script 암호화

스크립트 암호화 구조

Source code: PluginAes.cspublic class Plugin : MonoBehaviour

{

void Start() { StartCoroutine(Log()); }

IEnumerator Log()

{

Debug.Log("Script Loaded");

yield return new WaitForSeconds(1f);

StartCoroutine(Log());

}

}

데이터 암호화 Script

• Openssl

• AES-128-CBC

PluginAes

public class Plugin : MonoBehaviour

{

void Start() { StartCoroutine(Log()); }

IEnumerator Log()

{

Debug.Log("Script Loaded");

yield return new WaitForSeconds(1f);

StartCoroutine(Log());

}

}

게임으로 돌아가 적용해 볼까요?

메모리 암호화

메모리 해킹 w/ CheatEngine

치트 앱(Cheat App)

Protect code• Here is covert a number to AES encryption, this way the

score, or any other value that you need to save, never exist

as a number in the memory, it exist as a AES encryption.

• Going back to encryption topic, unless Unity code file is

encrypted, hacker can look up how your hash is generated,

write a script of his own and search for the value he needs.

Protect codeprivate string getKey_url = "https://ssl.qubitsec.com/mm/getKey.jsp";

internal bool isDisposed = false;

IEnumerator Start ()

{

var form = new WWWForm();

// User Id

form.AddField( "id", "3" );

var downloadKey = new WWW( getKey_url, form );

yield return downloadKey;

string str = downloadKey.text;

str = str.Trim();

string [] result = str.Split(',');

string gainedKey = GetString(result[0]);

SHA256 mySHA256 = SHA256Managed.Create();

MD5 md5Hash = new MD5CryptoServiceProvider();

byte[] _secret =

mySHA256.ComputeHash(System.Text.Encoding.UTF8.G

etBytes(gainedKey));

Aes myAes = Aes.Create();

myAes.Key = _secret;

myAes.IV = initVec;

myAes.Mode = CipherMode.CBC;

myAes.Padding = PaddingMode.PKCS7;

}

Erase keyform.data.Initialize();

downloadKey.Dispose();

str = System.String.Empty;

gainedKey = System.String.Empty;

Array.Clear(result, 0, result.Length );

Array.Clear(bytes, 0, bytes.Length );

Array.Clear(key, 0, key.Length );

Array.Clear(iv, 0, iv.Length );

Array.Clear(decrypted, 0, decrypted.Length );

Problem of securing the post• Since your application is encrypted, things are a lot easier.

All you need to do is send to server your score and

checksum hash, chesum hash is generated by using ...

Problem of securing the post• Client side

• Server side

키 서버

실제로 이것을 요구할까요?

퍼블리셔의 요구 사항

1. 메모리 정보 관리

• 인증정보를 포함한 개인정보가 모바일 기기에 저장될 때

안전한 암호알고리즘(SEED, AES 등)을 사용하여 암호화한

후에 저장합니다.

• 개인정보저장서버(DB)는 이름, 전화번호와 같은 개인정보저장 시 안전한 암호 알고리즘을 사용하여 암호화하여 저장하고, 패스워드와 같은 인증정보는 단방향 해쉬알고리즘(SHA256 이상)을 사용하여 저장합니다.

• 인증정보를 포함한 개인정보가 네트워크를 통해 전송되어야 할 경우 보안서버(SSL)를 사용하여 전송합니다.

단, 보안서버(SSL)를 사용하지 않을 경우 재사용 방지를

위해 일회성난수와 함께 안전한 암호 알고리즘을 사용하여

암호화한 후 전송합니다.

• 자동 로그인을 위해 저장되는 인증정보(토큰)는 사용자가

접근 가능한 위치(ex. “/mnt/sdcard”)에 저장하지 않습니다.

저장 시 안전한 암호 알고리즘으로 암호화 합니다.

• 자동 로그인을 위해 모바일 기기상에 저장되는 인증정보

(토큰)는 다른 기기에서 재사용을 방지하기 위해 기기정보

와 함께 안전한 암호 알고리즘을 사용하여 암호화한 후에

저장합니다.

(복호화 후 인증정보의 유효성을 기기정보를 통해 확인 가능)

1. 메모리 정보 관리

1. 메모리 정보 관리

• 불필요한 디버그 로그와 메시지는 릴리즈 시 삭제합니다.

• 퍼블리셔와 연동된 모바일게임은 사용자 프로필이미지(URL 포함), 사용자닉네임, 친구목록 등 퍼블리셔 API 를 통해

수집되는 사용자 정보에 대해 별도 서버로 전송 또는 저장

하지 않아야 합니다. 만약, 서버에 저장할 경우 별도의 “정보

보안관리약정서”를 체결해야 하며 관련 보안요구사항 이행

점검을 받아야 합니다.

1. 메모리 정보 관리

• 게임화면에서 보여지는 변수(Variable for Display)와 실제게임에 적용되는 중요변수(능력지수, 아이템 수, 점수 등)는분리하여 관리합니다. 또한 게임에 적용되는 변수 값은

저장 시 인코딩하여 저장합니다.

변수 = 인코딩함수(값)

값을 사용(Display)할 때“디코딩함수(변수)”을 사용하여 원본

값을 얻습니다.

1. 메모리 정보 관리

• 게임서버에서 중요 변수의 값 검증을 통해 비정상적인 값이전송되었을 때 무시하거나 초기화합니다.

• 게임실행 시 알려진 메모리 치트어플을 탐지합니다. 알려진치트어플을 서버로 전송 받을 때는 반드시 암호화된 스트링으로 전달받습니다.

2. 파일 정보 관리

• 개인정보, 인증정보는 파일로 저장하지 않습니다. 자동로그인 기능과 같은 인증정보 저장이 필요한 경우 반드시 안전한 암호 알고리즘으로 암호화합니다.

• 암호화된 인증정보는 다른 기기에서 재사용이 불가능해야합니다. 기기정보와 함께 암호화하여 다른 기기에서의 재사용 여부를 확인해야 합니다.

• 게임에 사용되는 중요정보(세이브파일, 아이템가격, 아이템속성 등)는 안전한 암호 알고리즘으로 암호화해야 합니다.

2. 파일 정보 관리

• 캐쉬파일에 중요정보가 남지 않도록 사용 후 캐쉬를 삭제해야 합니다.

3. 통신 정보 관리

• 게임에 민감한 데이터(점수, 보상, 사용자 정보 등)는 전송시 안전한 암호 알고리즘으로 암호화 합니다. SSL 을 함께사용할 경우 비교적 약한 암호방식(XOR, Shift)을 사용해도무방하며 데이터 무결성 검증을 위해 원본데이터의 해쉬값도 함께 포함하여 암호화하는 것이 좋습니다.

3. 통신 정보 관리

• HTTP 통신에 SSL 을 적용합니다. SSL(Secure Socket Layer)를 이용하여 데이터를 전송하면, 인터넷 구간에서 스니핑에의해 패킷이 탈취 되더라도 패킷의 내용을 해석할 수 없기때문에 보안적으로 안전합니다. 하지만, SSL 의 버전이 낮거나 설정이 올바르지 않으면 보안상 취약할 수 있습니다.

3. 통신 정보 관리

• 재전송 공격을 방지하기 위해 전송 데이터에 시퀀스(Sequence Number)와 같은 임의의 값을 포함한 뒤 암호화합니다. 서버는 암호화한 데이터를 복호화한 뒤 시퀀스를확인하여 중복 데이터 전송인지 확인한 뒤 결과를 반영합니다.

3. 통신 정보 관리

• 패킷을 암호화 하지 않고 패킷의 일부 데이터의 해쉬값을함께 전송하여 데이터 변조를 탐지할 수 있습니다. (단, 패킷재전송을 차단하기 위해 시퀀스(Sequence Number)를 함께해쉬해야함)

4. 난독화

• 변수 이름과 같이 중요 정보가 노출되는 것을 방지하기 위해서 Proguard 와 같은 난독화 도구를 사용하여 소스코드를 난독화 합니다. (Android Only):

• Eclipse 프로젝트에 있는 default.properties 파일에proguard.config=proguard.cfg 한줄을 추가하면 적용 가능

• http://developer.android.com/tools/help/proguard.html

우리는 혼자일까요?

우리를 도와주는 도구들

Qubit Securityhttp://www.plura.io

Server Protect

Crypto Obfuscator

Code Obfuscator

Code Obfuscator

Proguardhttp://goo.gl/lzLBV7

Code Obfuscator

LOCKIN Companyhttps://liapp.lockincomp.com

Code Obfuscator

INKA Entworkshttps://www.appsealing.com

Memory Protect

AppSealing 서비스 사용을 위한 리소스 AppSealing 제공 기능

개발용 PC 1대

적용 시간 1시간

$595 (65만원)

GameCheatingPrevention

Anti-memory Cheating(메모리 검색 방지)

치팅 앱 동작 감지

Anti-VM Cheating VM 동작 차단

StaticAnalysisPrevention

Binary Code Encryption SO파일 소스 암호화

Unity3D DLL Encryption DLL 소스 암호화

MemoryAnalysisPrevention

Anti-Memory Dump 메모리 덤프 방지

Anti-Debugging 디버깅 attach 방지

APKModificationPrevention

dex / SO / DLL filesIntegrity Verification

파일 위변조 검사

APK Integrity Verification APK 위변조 검사

APK Decompile Protection APK 디컴파일 방지

Option 1 Option 2 Option 3

First Launch(초기 게임 런칭시 추천)

Ongoing Maintenance(라이브 서비스에 추천)

Occasional Updates(Startup 기업에 추천)

1 point를 사용하여 1회 AppSealing 보안 적용

Point는 활성화하면 30일 동안 사용이 가능 (30일이 지나면 잔여 Point는 소모)

30Points

10Points

5Points

$49/Point

$1,470 USD

$100/Point

$1,000 USD

$119/Point

$595 USD

Bytecode Labhttp://www.bytecodelab.com

PaaS

TOAST Cloud

김동훈

Lead Manager / NHN Entertainment

Toward Art, Science & Technology

TOAST Cloud는 NHN Entertainment가 오랜 기간 축적한 노하우를기반으로 인프라/플랫폼을 제공하는 클라우드 서비스 입니다.

TOAST Cloud ?

OpenStack을 기반으로 하는 클라우드 인프라 서비스로서 서버,

네트워크, 스토리지 등의 가상자원을 원하는 즉시 사용할 수 있습니다.

클라우드 인프라 Infra Service

상품 설명

Compute/Network 가상 서버/가상사설 네트워크 생성

Block Storage VM인스턴스에 붙여 쓸 수 있는 블록 레벨 스토리지

Object Storage Rest 기반의 대용량 스토리지 서비스

Load Balancer 대규모 트래픽 부하 분산 서비스

공인 IP 외부에서 접속 가능한 공인 IP 제공

Monitoring 인프라 리소스 모니터링

초기 IT 투자비, 부대 운용비용이 절감됩니다.

트래픽 감소 및 증가에 따라 실시간으로 scale-in/out 대응이 가능합니다.

IT 인프라를 탄력적 운용하여 시간, 인력, 비용이 감소합니다.

서비스 효과

서비스 구성

서비스 운영을 위한 게임 분석지표, 유입채널 트래킹, 캠페인실행, 오류/크래쉬

모니터링 기능을 제공하는 분석과 운영이 결합된 Analytics 플랫폼입니다.

분석 & 마케팅 Analytics Service

상품 설명

App Analytics 대쉬보드, 실시간 모니터링 지표, 이용자/매출/게임 상세 분석, 커스텀 이벤트 분석 제공.

유입 채널별 이용자 트래킹 및 LTV에 기반한 ROI제공.

캠페인 목적에 따른 이용자 타겟팅과 캠페인 실행 기능 제공.

예약, 반복, 타케팅이 가능한 푸쉬 기능 제공.

Log & Crash Search 앱 오류 로그 수집, 저장, 조회 및 크래쉬 발생 원인 정보 제공 서비스.

실시간 로그 검색, 통계, 트랜드, 실시간 모니터링, 크래쉬 로그 이슈조회 지원

Cross Promotion 크로스 프로모션 서비스

서비스 성공률을 향상시킬 수 있습니다.

서비스 효과

서비스 구성

게임 개발을 위한 게임 솔루션과 개발/안정성/성능/서비스를 위한

공통 솔루션을 제공합니다.

게임 & 공통 서비스 Common Service

상품 설명

게임 솔루션 Leaderboard 대규모 트래픽에서 안정적으로 동작하는 실시간 랭킹 서비스.

일간, 주간, 월간, 전체 랭킹 업데이트, 랭킹 관리

(추가, 조회, 어뷰즈 사용자 삭제) 기능 제공

Game Server 게임 서버 & 실시간 멀티플레이 네트워크 엔진 , 룸/로비 기능, HTTP,

RUDP 지원. 서버에서 로직 구현 지원(인증, 해킹, 저장)

공통 솔루션 Launching 클라이언트 런칭 관리 서비스.

클라이언트 구동시 서버정보, 공지, 알림 등의 설정 기능 제공

IAP 단일 인터페이스로 마켓별 결제 연동 제공.

다양한 SDK(Android, iOS, Unity)로 손쉬운 연동방식 제공

서버측 결제검증 기능으로 결제 보안성 강화

Hacking Protection 모바일 게임/유료앱 해킹 방지 보안 서비스.

메모리 치팅 대응, 디컴파일, 리패키징, 에뮬레이터, 루팅, 파일조작,

스피드핵 탐지 및 차단

게임/서비스를 보다 신속하고 효율적으로 런칭할 수 있습니다.

서비스 효과

서비스 구성

강연하여서 행복합니다.

함께하여 주셔서 감사합니다.http://goo.gl/d5rs0R