iOS 탈옥 감지 구현 방법 정리 (Swift / UIKit)

iOS 탈옥 감지 구현 방법 정리 (Swift / UIKit)

iOS 앱에서 보안이 중요한 기능을 다루다 보면 탈옥(Jailbreak) 감지를 고려하게 되는 경우가 많다.

예를 들어 금융, 결제, 인증, 쿠폰, 포인트, 민감한 개인정보를 다루는 앱에서는 루팅 또는 탈옥 환경에서 앱 무결성이 깨질 가능성을 최소화해야 한다.

특히 iOS 탈옥 환경에서는 샌드박스 우회, 동적 라이브러리 주입, 파일 시스템 접근, 런타임 후킹 같은 기법이 가능해질 수 있기 때문에 앱 입장에서는 위험 신호를 조기에 감지하는 것이 중요하다.

이 글에서는 iOS 탈옥 감지의 기본 개념과 실제 앱에서 자주 사용하는 감지 방식, 그리고 오탐을 줄이기 위한 설계 방법까지 정리한다.

iOS 탈옥 감지란 무엇인가

iOS 탈옥 감지는 현재 앱이 실행 중인 기기가 정상적인 iOS 보안 모델을 우회한 상태인지 확인하려는 시도라고 볼 수 있다.

대표적으로 다음과 같은 징후를 확인하는 방식이 많이 사용된다.

• 탈옥 도구 또는 앱의 흔적 파일 존재 여부
• 일반 앱이 접근하면 안 되는 경로에 쓰기가 가능한지 여부
• 탈옥 관련 URL scheme 호출 가능 여부
• 런타임에 의심스러운 동적 라이브러리가 로드되어 있는지 여부

다만 중요한 점은 탈옥 감지가 “100% 확정 판정”이 아니라 여러 신호를 조합해 위험도를 판단하는 방식에 가깝다는 것이다.

왜 탈옥 감지가 필요한가

탈옥 감지가 필요한 이유는 단순히 기기가 변조되었는지 확인하기 위해서만은 아니다. 실제로는 앱이 신뢰할 수 없는 환경에서 실행 중일 가능성을 빠르게 파악하고, 그에 맞는 대응을 하기 위해 필요하다.

• 민감 기능 접근 제한
• 결제 / 인증 / 포인트 사용 제한
• 추가 본인 확인 요구
• 서버 측 위험도 상승 처리
• 보안 로그 수집

즉, 탈옥 감지는 “앱 종료”만을 위한 기능이 아니라 보안 정책을 분기하기 위한 입력값이라고 보는 것이 더 현실적이다.

탈옥 감지만으로 충분하지 않은 이유

실무에서는 탈옥 감지 하나만으로 보안을 완성할 수는 없다. 파일 경로 기반 탐지는 우회될 수 있고, 일부 방식은 오탐이 발생할 수도 있기 때문이다.

그래서 보통 다음과 같이 계층적으로 설계한다.

• 앱 내부에서 기본 탈옥 징후 감지
• 안티 디버깅 / 런타임 무결성 점검
• 중요 요청은 서버에서 추가 검증
• App Attest / DeviceCheck 같은 Apple 무결성 기능과 병행

즉, 로컬 탐지는 첫 번째 방어선이고, 진짜 중요한 의사결정은 서버와 함께 내리는 구조가 더 안정적이다.

가장 많이 사용하는 탈옥 감지 방식

iOS 앱에서 자주 사용하는 탈옥 감지 방식은 대체로 다음 4가지다.

1. 탈옥 관련 파일 경로 확인

가장 많이 쓰는 방식은 알려진 탈옥 도구나 패키지 경로가 존재하는지 확인하는 것이다.

예를 들어 다음과 같은 경로를 확인할 수 있다.

/Applications/Cydia.app
/Library/MobileSubstrate/MobileSubstrate.dylib
/bin/bash
/usr/sbin/sshd
/etc/apt
/private/var/lib/apt/

이 방식은 구현이 단순하지만, 파일명을 숨기거나 우회한 환경에서는 놓칠 수 있다. 또 너무 많은 경로를 무분별하게 넣으면 오탐 관리가 어려워질 수 있다.

2. 샌드박스 외부 쓰기 가능 여부 확인

정상적인 iOS 앱은 시스템 보호 영역에 자유롭게 파일을 쓸 수 없다. 그래서 일반적으로 접근하면 안 되는 경로에 테스트 파일을 써보는 방식이 많이 사용된다.

예를 들어 /private/ 아래에 파일 쓰기를 시도했을 때 성공한다면 비정상 환경으로 볼 수 있는 신호가 된다.

3. 탈옥 관련 URL scheme 확인

예전부터 많이 쓰던 방식으로, 예를 들어 cydia:// 같은 URL scheme이 열리는지를 확인하는 방법이 있다.

다만 이 방식은 단독 신호로 신뢰하기보다 보조 신호로만 쓰는 편이 안전하다. 또 canOpenURL를 사용하려면 Info.plist에 관련 scheme 설정이 필요할 수 있다.

4. 의심스러운 동적 라이브러리 로드 여부 확인

조금 더 고급 탐지로는 런타임에 로드된 image 목록을 보면서 MobileSubstrate, Substitute, Frida 관련 흔적을 찾는 방식이 있다.

이 방식은 런타임 변조 감지 측면에서는 유용하지만, 환경에 따라 오탐 가능성이 있어 단독 판정 기준으로 쓰기보다는 다른 신호와 함께 사용하는 편이 좋다.

기본 탈옥 감지 코드 예시

아래 코드는 UIKit / Swift 프로젝트에서 자주 사용하는 기본 패턴을 정리한 예시다.

import UIKit

final class JailbreakDetector {

    static let shared = JailbreakDetector()

    private init() {}

    private let suspiciousPaths: [String] = [
        "/Applications/Cydia.app",
        "/Library/MobileSubstrate/MobileSubstrate.dylib",
        "/bin/bash",
        "/usr/sbin/sshd",
        "/etc/apt",
        "/private/var/lib/apt/",
        "/private/var/stash",
        "/private/var/mobile/Library/SBSettings/Themes",
        "/private/jailbreak.txt"
    ]

    func isJailbroken() -> Bool {
        #if targetEnvironment(simulator)
        return false
        #else
        return hasSuspiciousFiles()
            || canWriteOutsideSandbox()
            || canOpenSuspiciousURL()
            || hasInjectedDynamicLibraries()
        #endif
    }

    private func hasSuspiciousFiles() -> Bool {
        suspiciousPaths.contains { path in
            FileManager.default.fileExists(atPath: path)
        }
    }

    private func canWriteOutsideSandbox() -> Bool {
        let testPath = "/private/jailbreak_test_\(UUID().uuidString).txt"

        do {
            try "Jailbreak Test".write(toFile: testPath, atomically: true, encoding: .utf8)
            try? FileManager.default.removeItem(atPath: testPath)
            return true
        } catch {
            return false
        }
    }

    private func canOpenSuspiciousURL() -> Bool {
        guard let url = URL(string: "cydia://package/com.example.package") else {
            return false
        }
        return UIApplication.shared.canOpenURL(url)
    }

    private func hasInjectedDynamicLibraries() -> Bool {
        let suspiciousLibraryNames = [
            "MobileSubstrate",
            "SubstrateLoader",
            "Substitute",
            "FridaGadget",
            "frida"
        ]

        for index in 0..<_dyld_image_count() {
            guard let imageName = _dyld_get_image_name(index) else { continue }
            let name = String(cString: imageName).lowercased()

            if suspiciousLibraryNames.contains(where: { name.contains($0.lowercased()) }) {
                return true
            }
        }

        return false
    }
}

이 구현은 여러 신호를 조합하는 방식이라 단일 체크보다 실무에서 더 자주 사용되는 형태에 가깝다.

사용 예시

앱 시작 시점이나 민감한 화면 진입 시점에 다음처럼 사용할 수 있다.

let isJailbroken = JailbreakDetector.shared.isJailbroken()

if isJailbroken {
    print("탈옥 의심 환경 감지")
}

다만 앱 실행 직후 무조건 종료하는 방식보다는 보안 정책에 따라 대응을 나누는 편이 더 현실적이다.

오탐을 줄이기 위한 설계 방법

탈옥 감지에서 가장 중요한 실무 포인트 중 하나가 바로 오탐 방지다. 특히 내부 테스트 기기, 개발용 빌드, 특정 MDM 환경, 보안 솔루션 간섭 등으로 예상치 못한 결과가 나오는 경우가 있다.

오탐을 줄이기 위해 보통 다음 원칙을 많이 사용한다.

• 하나의 신호만으로 즉시 차단하지 않기
• 여러 탐지 결과를 점수화해서 판단하기
• Debug / Internal 빌드는 정책을 다르게 두기
• 탐지 결과를 로깅해 실제 케이스를 수집하기
• 민감 기능만 제한하고 앱 전체 차단은 신중하게 적용하기

예를 들어 파일 경로 1개만 발견됐다고 곧바로 차단하기보다, 파일 흔적 + 샌드박스 쓰기 성공 + 의심 라이브러리 로드 같은 복합 신호일 때만 강하게 제한하는 방식이 더 안전하다.

권장하는 점수 기반 판정 방식

실무에서는 단순 Bool보다 점수 기반 접근이 더 유연할 때가 많다. 예를 들어 다음처럼 설계할 수 있다.

• 의심 파일 발견: 1점
• 샌드박스 외부 쓰기 성공: 3점
• 의심 라이브러리 로드: 3점
• URL scheme 응답: 1점

그리고 총점이 일정 기준 이상일 때만 고위험 환경으로 처리하는 식이다.

이 방식은 운영 중 실제 데이터에 맞춰 기준을 조정하기 쉽다는 장점이 있다.

중요 기능은 서버와 함께 막는 것이 좋다

탈옥 감지는 모두 클라이언트에서 동작하기 때문에 우회 가능성을 완전히 없애기는 어렵다. 그래서 정말 중요한 기능은 서버와 함께 판단하는 구성이 좋다.

예를 들어 다음처럼 설계할 수 있다.

• 앱은 탈옥 의심 신호를 수집
• 서버로 위험 플래그 전달
• 서버는 App Attest / DeviceCheck / 계정 이상 징후와 함께 종합 판단
• 고위험 요청만 차단 또는 추가 인증 요구

이 구조는 단순 로컬 차단보다 우회에 강하고 운영 정책도 유연하다.

App Attest / DeviceCheck와 함께 쓰는 이유

Apple은 DeviceCheck와 App Attest를 통해 앱 인스턴스의 정당성과 무결성 검증을 지원한다.

이 기능들은 탈옥 감지 자체를 대체하는 것은 아니지만, 서버가 “이 요청이 신뢰 가능한 앱 인스턴스에서 왔는지”를 판단하는 데 도움이 된다.

즉, 실무에서는 보통 이렇게 역할을 나눈다.

• 탈옥 감지: 기기 / 런타임 환경 이상 징후 탐지
• App Attest: 앱 인스턴스 무결성 및 서버 검증 강화
• DeviceCheck: 기기 상태 및 서버 정책 연계

보안이 중요한 서비스일수록 이 조합이 더 현실적이다.

Info.plist에서 주의할 점

만약 URL scheme 기반 탐지를 사용한다면 canOpenURL 호출을 위해 Info.plist 설정이 필요할 수 있다.

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>cydia</string>
</array>

다만 URL scheme 탐지는 보조 신호 정도로만 두는 편이 좋고, 핵심 판단은 다른 탐지와 함께 조합하는 것이 안전하다.

실무에서 자주 하는 실수

1. 파일 경로 탐지만으로 끝내는 경우

가장 구현이 쉽지만 우회도 쉽다. 반드시 다른 런타임 신호와 함께 보는 편이 좋다.

2. 단일 신호로 즉시 앱 종료하는 경우

오탐이 발생했을 때 사용자 영향이 너무 커질 수 있다. 민감 기능 제한, 추가 인증, 서버 플래그 전달 같은 단계적 대응이 더 현실적이다.

3. 시뮬레이터 예외 처리를 하지 않는 경우

개발 환경에서는 정상 테스트가 어려워질 수 있다. 보통 simulator는 탈옥 판정에서 제외한다.

4. 로그 없이 차단만 하는 경우

실제 운영에서는 어떤 신호가 오탐을 만드는지 알아야 한다. 탐지 결과와 원인을 로깅해야 정책을 다듬기 쉽다.

추천하는 운영 정책

실무에서는 보통 다음처럼 운영하면 안정적이다.

1. 앱 시작 시 기본 탈옥 탐지 수행
2. 민감 기능 진입 시 재검사
3. 탐지 결과를 점수화
4. 고위험이면 서버 플래그 전달
5. 결제 / 인증 / 포인트 기능만 제한 또는 추가 인증 요구
6. 운영 로그를 바탕으로 탐지 기준 조정

이 방식은 보안성과 사용자 경험을 모두 고려하기 좋다.

정리

• iOS 탈옥 감지는 여러 징후를 조합해 위험 환경을 탐지하는 방식에 가깝다.
• 대표적인 신호는 의심 파일, 샌드박스 외부 쓰기, URL scheme, 동적 라이브러리 로드 여부다.
• 단일 신호만으로 판정하지 말고 복합 신호 기반으로 판단하는 것이 좋다.
• 오탐 방지를 위해 점수화와 로그 수집이 중요하다.
• 중요 기능은 App Attest / DeviceCheck / 서버 정책과 함께 계층적으로 보호하는 것이 현실적이다.