상세 컨텐츠

본문 제목

ios android 인앱결제 우회와 대응방안 관련

스마트기기개발관련

by AlrepondTech 2016. 4. 20. 18:24

본문

반응형
728x170

 

=================================

=================================

=================================

 

 

출처: http://blog.naver.com/largosoft/220477343486

 

안녕하세요.

라르고소프트 입니다~!

 

지난 포스팅에선 모바일게임 해킹의 종류와 그중 가장많은 사례가 있는 메모리 해킹에 대해서 알아봤습니다.

보안 솔루션이 발전하듯 해킹툴의 기술과 방식도 발전하니 지속적인 관심이 필요할것 같네요.

 

지난 포스팅

<1.국내 모바일게임에 자주일어나는 해킹/치트의 종류>

<2. 메모리 해킹/서치 툴과 보호방안>

 

오늘은 인앱결제 우회에 대한 이해와 대응방안에 대해 포스팅하겠습니다.

결제 해킹에는 치트툴을 이용한 결제 우회와 통신패킷을 복제, 변경 시키는 방식등이 있습니다.(실제 서비스에서는 더욱 다양한 인앱 해킹이 발생합니다.) 

 

1. 치트툴을 이용한 IAP 우회

1-1. Freedom

- 게임내의 결제 정보/카드정보 를 다른것으로 변경하여 실제 과금없이 아이템을 획득할수 있습니다.

- 조작이 매우 간단하며 많이 배포되고 있어 사용 빈도수가 매우 높습니다.

 

 

 

 

 

1-2. Lucky Patcher

- 다양한 조작이 가능한 해킹/치트툴입니다.

- 디바이스 내의 어플들을 검색 하고 치트를 통해 변경할수있는 메뉴를 보여줍니다.

- ​인앱 구매가 있는 경우 해당 메뉴를 변경하여 변조 앱으로 재 빌드 합니다.

- 이후 사용자는 변조된 앱을 재설치하여 사용하게 됩니다. ​

- Freedom보다는 어렵지만 다른 툴들 보다는 방식이 간단하고 기능이 강력하여 많이 배포되고 있습니다. 특히 신규 버전업데이트가 매우 빠른 편으로서 모니터링에 주의가 필요 합니다.

 

​==========================================================================================================================


 

2. 결제 과정을 변경하거나 인증을 우회하는 IAP 해킹

​- 다루기 쉬운 해킹 프로그램이외에도 통신패킷을 탈취/변경 하거나 APP내 과금 PID를 변경 하여 결제를 우회하기도 합니다.

2-1. 일반적인 결제구조

- APP에서 과금 요청후 마켓 서버에서 과금이 정상적으로 이루어 지면 아이템이 지급되는 방식입니다.

​- 과금 완료 패킷을 획득하거나 조작된 완료 패킷을 전송받아 실제 과금이 아닌 상황에서도 아이템을 지급받는 경우가 발생합니다.

​- 스마트폰 초기 개발시에 가장많이 발생하였으며 현재는 많은 개발자 분들이 기본적인 검증 과정을 넣어 막고있습니다.

 

 

2-2. 구매 인증이 추가된 결제 구조

- APP에서 과금요청을 하게되면 APP 마켓에서 과금에 따른 영수증을 발행하고 이를 APP에서 검증하는 방식입니다.

- APP내의 영수증 비교 검증 구간을 우회하게 리패키징 하거나 검증완료된 영수증을 지속적으로 게임에 전송하여 아이템을 불법 취득합니다.​

​- 간단한 툴을 사용한 불법 과금 방지는 되지만 해커의 리패키징이나 신규 해킹 툴의 우회에 뚫리는 경우가 존재 합니다.

 

 

 

 

=================================

=================================

=================================

 

 

 

 

반응형

 

 

 

728x90

 

 

 

 

 

3. 대응 방안

3-1. 개발사 서버와 마켓서버 간의 영수증 검증 도입

- 개발사 서버와 마켓서버간의 영수증 비교검증과정을 추가하여 영수증의 신뢰성을 높입니다.

 

 

 

 

 

 

3-2. 예시코드

아래의 코드들은 Google Play In-App Billing(IAB) 버전3를 이용하여 어떻게 요청을 만드는지를 보여주는 기초적인 내용들입니다.- 개발사의 서버 및 개발형태에 따라 구현 내용이 다르며 각 마켓의 결제관련 API가 지속적으로 업데이트되는 관계로 해당 내용들은 개발을 위한 참고용으로만 사용하시기 바랍니다.3-2-1. 클라이언트

어플리케이션에서 구매를 시작하기 위해서는 getBuyIntent 메소드를 호출해주면 됩니다.

1. 구매 요청

Bundle querySkus = new Bundle();
Bundle buyIntentBundle = mService.getBuyIntent(3, getPackageName(), sku, "inapp", "bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ");

사용되는 5개의 파라미터는 IAB API 버전을 의미하는 3과 어플리케이션의 패키지명그리고 생성한 Bundle, 구매하길 원하는 아이템의 product ID, purchase type (“inapp” or "subs") developerPayload 넘깁니다.구매 요청을 보낼  구매 요청을 식별할  있는 유니크한 문자열 토큰을 생성하여 developerPayload 담아 보내시기바랍니다.랜덤하게 생성된 토큰 형태의  문자열을 사용하면 Google Play로부터의 응답을 받을 때 orderId developerPayload문자열 값을 통해 응답 데이터가 진짜인지 확인할 수 있습니다이 토큰 값으로 이전에 요청에 내가 담아 보낸 값과 동일한지를 확인할 수 있습니다.또한 Payload 문자열은 서버에서 그대로 넘어 오기 때문에 이 값이 구매 직전과 직후에 변동이 있다면 구매 요청에 변조가 있었다고 판단 할 수 있습니다.실제 유효한 구매였는지를 확인하는 것만으로도 해킹의 대부분을 차단할  있습니다

.

구매 데이터는 응답 Intent안에INAPP_PURCHASE_DATA라는 이름의 키로 JSON 포맷 형태의 문자열로 저장되어있습니다.

 

2. 구매 응답 값(예시)

 

'{
   "orderId":"12999763169054705758.1371079406387615", // orderId : 주문번호   "packageName":"com.example.app", // packageName : 앱의 패키지명   "productId":"exampleSku", // productId : 상품 ID   "purchaseTime":1345678900000, // purchaseTime : 구매시각   "purchaseState":0, // purchaseState : 구매상태   "developerPayload":"bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ", // developerPayload   "purchaseToken":"rojeslcdyyiapnqcynkjyyjh" //토큰값 }'

 

3-2-2. 서버

1. 

서버 요청

https://www.googleapis.com/androidpublisher/v1.1/applications/packageName/inapp/productId/purchases/purchaseToken

 

 

2. php 샘플 코드

$sFileName = "token";
$sResult = json_decode(file_get_contents($sFileName),true);
 
$sUrl = "https://www.googleapis.com/androidpublisher/v1.1/";
$sUrl .= "applications/$_GET[packageName]/";
$sUrl .= "inapp/$_GET[productId]/";
$sUrl .= "purchases/$_GET[purchaseToken]/";
$sUrl .= "?access_token=$sResult[access_token]";
$rResult = file_get_contents("$sUrl");
if ($rResult == false or $rResult=="") {
           echo "에러";}
else {
           echo "정상";}

위와 같이 서버에서 구글 서버로 요청을 하게 되면 아래와 같은 응답 JSON 형태의 데이터가 나오게 됩니다.

 

3. 서버 요청 응답 값(예시)

{
 "kind": "androidpublisher#inappPurchase",
 "purchaseTime": "1394658352037",
 "purchaseState": 0,
 "consumptionState": 1,
 "developerPayload": "cb9e60a2-1714-434c-ba40-e144f89a7e9f"
}

 

끝으로 중요한 핵심은 Google이 제공하는 앱내 결제 체크 API를 사용하라는 것과 아이템의 실제 지급을 서버에서 처리 하여하 한다는 것입니다.developerPayload 의 경우 서버에서 3단계로 확인하며 최초에는 발급하여 서버에 저장만을 하고 두 번째에는 정상적으로 검증되었는지 여부를 저장합니다.마지막 상품 지급 요청에 대하여 developerPayload가 존재하고 검증까지 마친 상태인지를 확인하여 맞을 경우 다음 플로우로의 진행을 하게 됩니다만약에 developerPayload 가 발급 된 적이 없거나 검증결과가 기록되지 않았다면 불법적인 지급 요청으로 판단할 수 있습니다.또한 이러한 과정을 DB 기록해 두면 유저 CS가 발생시에 CS처리의 기준이 될 수 있습니다위의 방법을 기초로 하여 회사의 상황에 맞는 좀 더 복잡한 보안 요소나 대응 방법정책 등을 결정하여 개발하시면 됩니다.

 

참고 :

이미지 등 출처 :


이상 인앱결제 해킹,우회와 대응에 대한 간단한 개념을 정리해보았습니다.실제 개발 적용시에는 각 개발사의 상황에 맞추어 다양한 개발방식으로 인한 많은 어려움이 있을것으로 예상됩니다. 다만 매출과 직관적인 연관이 있는만큼 각종 도움말등을 통해 이를 해결하고 소중한 APP을 지키시길 바랍니다.

 

 

=================================

=================================

=================================

 

 

반응형
그리드형


관련글 더보기

댓글 영역