"프리미엄 무료, 무한 재화" — 검색 한 번이면 나오는 내 게임
개발한 게임의 이름 뒤에 "MOD APK"를 붙여 검색해 본 적이 있으신가요? 유료 잠금 해제, 인앱결제 우회, 무한 재화, 광고 제거 버전이 제3자 APK 배포 사이트에 버젓이 올라와 있다면, 누군가 게임의 APK를 분해·변조해 재배포했을 가능성이 높습니다.
MOD APK는 모바일 게임의 매출과 서비스 수명에 직접적인 악영향을 미치는 주요 위협입니다. 유료 콘텐츠가 무료로 풀리고 IAP(인앱결제) 검증이 무력화될 뿐 아니라, 변조된 클라이언트는 멀티플레이의 공정성을 심각하게 훼손합니다. 더욱이 악성코드가 삽입된 채 유포되면 게임 보안성에 대한 유저 신뢰 하락과 평판 피해로 이어질 수 있습니다.
이번 글에서는 MOD APK가 실제로 어떤 과정을 거쳐 제작되는지, 흔한 방어 방식이 왜 우회될 수 있는지, 그리고 이를 효과적으로 억제하기 위한 전략은 무엇인지 살펴봅니다.
MOD APK는 어떻게 만들어지나 — 동작 원리
APK는 본질적으로 코드·리소스가 압축된(ZIP) 아카이브입니다. 따라서 변조는 대체로 디컴파일 → 분석 → 수정 → 재서명 → 재배포의 정형 절차를 따릅니다.
디컴파일(apktool/jadx/Il2CppDumper) ──> 로직 수정(결제 우회·갓모드·검사 무력화) ──> 재패키징·재서명(공격자 키) ──> 제3자 유포
1) 디컴파일 및 역분석 공격자는 APK 압축을 풀고 전용 도구로 내부를 분석합니다.
- Java/Kotlin·Mono 로직은
apktool로 smali 바이트코드를 추출하거나jadx로 Java 유사 코드로 복원합니다. - 유니티 IL2CPP 빌드는 핵심 로직이 네이티브
libil2cpp.so로 컴파일되지만, 타입·메서드 정보가 담긴global-metadata.dat이 동봉됩니다. 공격자는Il2CppDumper류로 이 메타데이터를 추출해 함수 구조와 오프셋을 상당 부분 복원합니다.
2) 로직 수정 및 패치 분석 결과를 바탕으로 목적에 맞춰 코드를 변조합니다.
- 결제 검증 우회: "결제 성공"을 항상 반환하도록 분기를 수정해 유료 아이템을 무료로 획득.
- 무한 재화·갓모드: 주요 스탯 값을 고정하거나 데미지 연산 로직을 패치.
- 방어 로직 무력화: 광고 출력, 라이선스 확인, 서명 검사 함수를 찾아 NOP 처리로 우회.
smali는 명령어를 직접 수정하고, IL2CPP 기반은 .so를 직접 패치하거나 global-metadata.dat을 조작합니다.
3) 재패키징 및 재서명 수정한 파일을 다시 APK(zip)로 묶고 정렬(zipalign)한 뒤, 공격자 임의의 키로 재서명합니다. 안드로이드는 모든 APK에 서명을 요구하므로 변조 앱 실행에는 이 과정이 필수입니다. 이때 원본 개발자의 공식 서명은 유실되고 다른 서명으로 대체되며, 이는 방어자에게 변조를 탐지하는 매우 중요한 단서가 됩니다.
4) 재배포 완성된 변조 파일은 제3자 APK 사이트, 블랙마켓 커뮤니티, 텔레그램 등에 "MOD" 이름표를 달고 유포됩니다.
여기서 두 가지 시사점을 얻습니다. 첫째, IL2CPP는 분석 난이도를 높이지만 그것만으로 완전한 방패가 되긴 어렵습니다. 둘째, 변조 앱 실행에는 대개 재서명이 수반되므로, 원본과 서명이 달라진다는 점이 가장 강력한 변조 탐지 신호 중 하나입니다.
흔히 시도하는 방어 전략과 그 한계
1) 서명 검증 (올바른 방향이나 검증 위치의 한계)
런타임에 "현재 앱이 공식 인증서로 서명됐는가"를 확인하면 재서명된 MOD를 잡을 수 있는 유효한 접근입니다. 그러나 이 로직이 Java/smali 계층(관리 코드)에 있으면, 공격자가 해당 메서드를 찾아 항상 정상 판정(true)을 반환하도록 손쉽게 패치합니다. 검증이 공격자와 같은 코드 계층에 노출되면 무력화 위험이 큰 구조적 한계입니다.
2) DEX·리소스 체크섬 (무결성 검증) 설치된 주요 파일의 해시를 런타임에 비교해 변조를 탐지합니다. 원리상 강력하지만, 무결성 검사 로직 자체가 관리 코드에 노출되면 위변조될 여지가 있고, 기준 원본 해시를 클라이언트 내부에 안전하게 숨기는 방법이 관건입니다.
3) Google Play Integrity API (서버 기반 어테스테이션) 구글이 기기·앱 설치 출처·라이선스의 정당성을 서버 측에서 증명하는 강력한 방식입니다. 임의 스토어·웹에서 설치된 MOD는 정상 판정을 받지 못하므로 신뢰도가 높습니다. 다만 Play 배포·네트워크 연결을 전제로 하므로, 오프라인이나 타 스토어 배포처럼 네트워크 의존성이 없는 구간은 단독으로 모두 커버하기 어렵습니다.
4) IL2CPP 빌드 (단순 난독화 효과) 스크립트 로직을 네이티브로 변환해 분석 진입장벽을 높입니다. 큰 도움이 되지만, 앞서 봤듯 메타데이터 덤프로 상당 수준 구조 파악이 가능해 단독 방어로는 부족합니다.
요약하면, 단편적 검사들은 옳은 방향이지만 검증 로직이 관리 코드에 노출되면 역분석으로 패치되기 쉽고, 단일 신호(서명만·무결성만)에 의존하면 우회 경로가 생깁니다.
Native 계층에서 변조와 재배포를 효과적으로 막는 법
강력한 방어의 원칙은 일관됩니다 — 핵심 검증 로직을 공격자가 분석·수정하기 어려운 Native 계층으로 옮기고, 다각적 탐지 신호를 결합하는 것.
(1) 서명·무결성 검증을 Native C++ 계층에서 수행 앱 서명 정합성과 설치 파일 원본 일치 여부를 네이티브 계층에서 확인합니다. Java·smali의 검사보다 역분석·변조 난이도가 크게 높아집니다. 재서명·리소스 패치된 MOD는 네이티브 검증에서 서명 불일치·해시 변경으로 적발됩니다.
(2) 빌드 변조·메타데이터 조작 행위 직접 탐지
.so 패치나 global-metadata.dat 변조처럼 IL2CPP를 타깃으로 하는 전형적 공격 흔적을 시스템 레벨에서 직접 점검합니다. IL2CPP 보호를 무력화하려는 메타데이터 변조 시도 자체를 탐지 신호로 활용합니다.
(3) 다중 신호 결합 및 정책적 대응 앱 서명, 무결성 체크, 재패키징 흔적, 실행 환경(에뮬레이터/루팅)을 복합적으로 교차 검증해 우회 경로를 최소화합니다. 탐지 시 후속 동작(강제 종료, 기능 제한, 모니터링 로그 전송)은 운영 정책에 맞게 설정합니다.
OZero Security는 이 원칙을 바탕으로 MOD APK·빌드 변조 탐지 모듈을 Native C++ 계층에 구현해 제공합니다. 클라이언트 단에서 재서명·파일 변조·메타데이터 조작을 탐지하고, 라이브 서비스 단계에서는 Pro Add-on의 텔레메트리로 서버 측에서 비정상 클라이언트를 식별·대응합니다. 또한 Plus Add-on의 앱별 Native Variant를 적용하면 빌드되는 프로젝트마다 보안 로직의 바이너리 구조가 달라, 한 게임에서 분석된 우회 패턴이 다른 게임에 곧바로 적용되는 것을 방지합니다.
요약 및 정리
- MOD APK는 대체로 디컴파일 → 코드/로직 수정 → 재서명 → 재배포의 정형 절차로 만들어지며, IL2CPP 환경에서도 메타데이터 추출로 변조가 이뤄질 수 있습니다.
- 대부분의 변조 앱은 설치를 위해 재서명을 거치므로, 서명·파일 무결성 검증이 가장 강력한 1차 탐지 신호입니다.
- 단, 이 검증 로직이 Java/C# 관리 코드에 있으면 상대적으로 쉽게 역분석·우회될 위험이 있습니다.
- 핵심 전략은 Native 계층의 서명·무결성 검증 + 메타데이터 변조 탐지 + 다중 신호 교차 검증이며, Play Integrity나 서버 텔레메트리와 연계하면 방어력이 더 강해집니다.
검색창의 "내 게임 MOD APK"를 줄이는 일은 단일 보안 로직 하나로 완성되지 않습니다. 변조의 전체 과정을 이해하고, 코드의 여러 계층에 복합적인 허들을 세우는 것이 중요합니다.