Kgc2014 one daylearnunitycryptography-f

하루 만에 배우는
유니티 암호화 프로그램
신승민
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. 퍼블리셔의 요구사항

핵심만 듣고 바로 적용해 보는
암호화 알고리즘

암호화에 사용한 도구와 서적
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.5
http://goo.gl/zA99Ju
System.Security.Cryptography
SymmetricAlgorithm Class
System.Security.Cryptography.Aes
System.Security.Cryptography.DES
System.Security.Cryptography.RC2
System.Security.Cryptography.Rijndael
System.Security.Cryptography.TripleDES

.Net Framework 4.5
http://goo.gl/MwWb58
CipherMode Enumeration
Members
CBC

Original Encrypted using ECB mode Modes other than ECB
result in pseudo-randomness
http://goo.gl/tQrusw
CipherMode

.Net Framework 4.5
http://goo.gl/7uzuBW
PaddingMode Enumeration
Members
PKCS7

.Net Framework 4.5
http://goo.gl/zA99Ju
HashAlgorithm Class
System.Security.Cryptography.KeyedHashAlgorithm
System.Security.Cryptography.MD5
System.Security.Cryptography.RIPEMD160
System.Security.Cryptography.SHA1
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를 각 클라이언트들이 공유를 하고
그걸 이용해서 자신들의 메시지를 암호화해서 전송하면
• 서버 입장에서는 암호화된 무의미한 데이터만 보고 저장할
수 있을 뿐 딱히 할 수 있는 게 없다.
“누군가 이 자료를 빼가거나 달라고 요청해서 내주어도
그게 서비스 운영자 입장에서 할 수 있는 전부라는 것이다.”

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. 끝!

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라운드”

.Net Framework 4.5
http://goo.gl/BIPVBu
ECDiffieHellman Class
ECDiffieHellmanCng Class

이론이 실제 사용될까요?
안전한 패스워드 저장
http://goo.gl/dwUlOy

키 스트레칭 Key Stretching

Adaptive Key Derivation
PBKDF2
DIGEST = PBKDF2(PRF, Password, Salt, c, DLen)
PRF: 난수(HMAC)
Password: 패스워드
Salt: 솔트
c: 원하는 iteration 반복 수
DLen: 원하는 다이제스트 길이
* NIST 승인된 알고리즘, 미국 정부 시스템에서 사용됨

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

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

.Net Framework 4.5
http://goo.gl/vSCYt1
Rfc2898DeriveBytes Class
Properties
IterationCount
Salt

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 code
public 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;
}

Script 암호화

Source code: PluginAes.cs
public 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

public class Plugin : MonoBehaviour
{
void Start() { StartCoroutine(Log()); }
IEnumerator Log()
{
Debug.Log("Script Loaded");
yield return new WaitForSeconds(1f);
StartCoroutine(Log());
}
}

메모리 암호화

메모리 해킹 w/ CheatEngine

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 code
private 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 key
form.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”)에 저장하지 않습니다.
저장 시 안전한 암호 알고리즘으로 암호화 합니다.
• 자동 로그인을 위해 모바일 기기상에 저장되는 인증정보
(토큰)는 다른 기기에서 재사용을 방지하기 위해 기기정보
와 함께 안전한 암호 알고리즘을 사용하여 암호화한 후에
저장합니다.
(복호화 후 인증정보의 유효성을 기기정보를 통해 확인 가능)

• 불필요한 디버그 로그와 메시지는 릴리즈 시 삭제합니다.
• 퍼블리셔와 연동된 모바일게임은 사용자 프로필이미지(URL
포함), 사용자닉네임, 친구목록 등 퍼블리셔 API 를 통해
수집되는 사용자 정보에 대해 별도 서버로 전송 또는 저장
하지 않아야 합니다. 만약, 서버에 저장할 경우 별도의 “정보
보안관리약정서”를 체결해야 하며 관련 보안요구사항 이행
점검을 받아야 합니다.

• 게임화면에서 보여지는 변수(Variable for Display)와 실제
게임에 적용되는 중요변수(능력지수, 아이템 수, 점수 등)는
분리하여 관리합니다. 또한 게임에 적용되는 변수 값은
저장 시 인코딩하여 저장합니다.
변수 = 인코딩함수(값)
값을 사용(Display)할 때“디코딩함수(변수)”을 사용하여 원본
값을 얻습니다.

• 게임서버에서 중요 변수의 값 검증을 통해 비정상적인 값이
전송되었을 때 무시하거나 초기화합니다.
• 게임실행 시 알려진 메모리 치트어플을 탐지합니다. 알려진
치트어플을 서버로 전송 받을 때는 반드시 암호화된 스트링
으로 전달받습니다.

2. 파일 정보 관리
• 개인정보, 인증정보는 파일로 저장하지 않습니다. 자동로그
인 기능과 같은 인증정보 저장이 필요한 경우 반드시 안전
한 암호 알고리즘으로 암호화합니다.
• 암호화된 인증정보는 다른 기기에서 재사용이 불가능해야
합니다. 기기정보와 함께 암호화하여 다른 기기에서의 재사
용 여부를 확인해야 합니다.
• 게임에 사용되는 중요정보(세이브파일, 아이템가격, 아이템
속성 등)는 안전한 암호 알고리즘으로 암호화해야 합니다.

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

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

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

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

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

4. 난독화
• 변수 이름과 같이 중요 정보가 노출되는 것을 방지하기 위
해서 Proguard 와 같은 난독화 도구를 사용하여 소스코드
를 난독화 합니다. (Android Only):
• Eclipse 프로젝트에 있는 default.properties 파일에
proguard.config=proguard.cfg 한줄을 추가하면 적용 가능
• http://developer.android.com/tools/help/proguard.html

우리는 혼자일까요?
우리를 도와주는 도구들

Qubit Security
http://www.plura.io
Server Protect

Crypto Obfuscator
Code Obfuscator

Proguard
http://goo.gl/lzLBV7
Code Obfuscator

LOCKIN Company
https://liapp.lockincomp.com
Code Obfuscator

INKA Entworks
https://www.appsealing.com
Memory Protect

AppSealing 서비스 사용을 위한 리소스 AppSealing 제공 기능
개발용 PC 1대
적용 시간 1시간
$595 (65만원)
Game
Cheating
Prevention
Anti-memory Cheating
(메모리 검색 방지)
치팅 앱 동작 감지
Anti-VM Cheating VM 동작 차단
Static
Analysis
Prevention
Binary Code Encryption SO파일 소스 암호화
Unity3D DLL Encryption DLL 소스 암호화
Memory
Analysis
Prevention
Anti-Memory Dump 메모리 덤프 방지
Anti-Debugging 디버깅 attach 방지
APK
Modification
Prevention
dex / SO / DLL files
Integrity 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는 소모)
30
Points
10
Points
5
Points
$49/Point
$1,470 USD
$100/Point
$1,000 USD
$119/Point
$595 USD

Bytecode Lab
http://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

Kgc2014 one daylearnunitycryptography-f

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Kgc2014 one daylearnunitycryptography-f

Similar to Kgc2014 one daylearnunitycryptography-f (20)

More from Seungmin Shin

More from Seungmin Shin (6)

Kgc2014 one daylearnunitycryptography-f