IOS 가 어떻게 앱 을 안전하게 보강 하 는 지 간단히 말 하 다

tweak 의존 방지
일반적으로 우 리 는 app 을 분석 해 야 한다.처음에 껍질 을 깨 뜨리 는 것 이 었 다.
$ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /path/to/XXX.app/XXX
그리고 복호화 한 바 이 너 리 파일 을 hopper 와 같은 컴 파일 러 에 던 져 처리 합 니 다.껍질 이 깨 지지 않 은 바 이 너 리 파일 을 hopper 에 버 리 고 역 컴 파일 한 내용 은 읽 을 수 없습니다(애플 에 의 해 암호 화 되 었 습 니 다).그 러 니까 껍질 을 깨 는 게 앱 을 분석 하 는 첫걸음 이 야.이 단계 에 대한 방 비 는 두 가지 방식 이 있다.
1.바 이 너 리 파일 헤더 의 세그먼트 제한
Xcode 에서 build setting 옵션 을 설정 합 니 다.
-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null
'Other Linker Flags'에 추가 합 니 다.이전에 이것 을 추 가 했 기 때 문 이 라 고 생각 하지 않 았 는데 인터넷 에서 모든 해결 방안 을 검색 했다.예 를 들 어 이 SO Post 가 효과 가 없 을 때 나 는 이 설정 의 원인 이라는 것 을 알 게 되 었 다)
2.setuid 와 setgid
Apple 은 이 두 함수 의 app 을 호출 하지 않 습 니 다.기호 표를 보면 서 바 이 너 리 실행 파일 에 이 두 함수 가 포함 되 어 있 는 지 여 부 를 판단 할 수 있 기 때 문 입 니 다.
탈옥 장치 에 맞 춤 형 tweak 이 있 는 지 검사 합 니 다.
일반적으로 탈옥 휴대 전화 에 서 는 TheOS 를 이용 해 tweak 형식의 프로젝트 를 만 듭 니 다.그리고 우리 가 분석 하고 자 하 는 클래스 에 대해 제공 하 는 logify.pl 명령 으로 생 성 된 mk 파일 을 사용 하여 이러한 모든 방법의 입 참 과 출 참 을 인쇄 합 니 다.이것 은 앱 의 운행 방식 을 분석 하 는 데 큰 도움 이 된다.물론,우 리 는 스스로 어떤 종류의 mk 를 만 들 고 특정한 함 수 를 hook 하여 우리 가 원 하 는 방식 으로 실행 할 수 있 습 니 다.예 를 들 어 인증서 바 인 딩 을 한 app 에 대해 만약 에 프레임 워 크 가 AFNetWorking 이 라면 우 리 는 mk 파일,hook AFSecurity Policy 류 의 다음 방법 을 만 들 수 있 습 니 다.

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain

이 방법 을 YES 로 영원히 되 돌려 주면 대부분의 응용 프로그램 이 만 든 인증서 바 인 딩 도 효력 을 잃 게 됩 니 다.TheOS 의 tweak 모델 을 사용 해 보면 이런 방식 이 상당히 간단 하고 빠르다 는 것 을 알 수 있 을 것 이다.
이 단계 에 대한 예방 은 프로젝트 의 main 함수 에 판단 을 추가 할 수 있 습 니 다.먼저 읽 기/Library/Mobile Substrate/DynamicLibraries 아래 의 모든 plist 파일 의 내용 을 읽 고 어떤 plist 가 당신 의 app 의 bundle id 를 포함 하고 있 는 지 확인 할 수 있 습 니 다.그렇다면 누군가가 tweak 를 이용 하여 당신 의 app 을 공격 하고 싶 어 하 는 지 판단 할 수 있 습 니 다.이 럴 때 는 앱 을 crash 에 떨 어 뜨리 거나 특정 기능 을 제한 하 는 등 대응 할 수 있다.
구체 적 인 원 리 는 참고 자료 4 를 볼 수 있 습 니 다.쉽게 말 하면 MobileSubstrate 는 app 이 메모리 에 불 러 올 때/Library/Mobile Substrate/DynamicLibraries 아래 에 불 러 올 트 윅 이 있 는 지 확인 하고 있 으 면 불 러 옵 니 다.있 는 지 없 는 지 어떻게 판단 합 니까?plist 안에 있 는 bundle ID 로 판단 한 겁 니 다.
코드 참조 아래

static __inline__ __attribute__((always_inline)) int anti_tweak()
{
    uint8_t lmb[] = {'S', 'u', 'b', 's', 't', 'r', 'a', 't', 'e', '/', 'D', 'y', 'n', 'a', 'm', 'i', 'c', 0, };
    NSString *dir = [NSString stringWithFormat:@"/%@/%@%s%@", @"Library", @"Mobile", lmb, @"Libraries"];
    NSArray *dirFiles = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil];
    NSArray *plistFiles = [dirFiles filteredArrayUsingPredicate:
                           [NSPredicate predicateWithFormat:
                            [NSString stringWithFormat:@"%@ %@%@ '.%@%@'",@"self", @"EN", @"DSWITH", @"pli", @"st"]]];
    int cnt = 0;
    for (NSString *file in plistFiles) {
        NSString *filePath = [dir stringByAppendingPathComponent:file];
        NSString *fileContent = [NSString stringWithContentsOfFile:filePath encoding:NSUTF8StringEncoding error:nil];
        if (fileContent && [fileContent rangeOfString:[[NSBundle mainBundle] bundleIdentifier]].location != NSNotFound) {
            cnt ++;
        }
    }
    //        app   tweak   ，  0     
    return cnt;
}

가방
보통 app 을 풀 면 가방 을 잡 습 니 다.이렇게 되면 우리 의 app 모든 인터페이스,인터페이스 데 이 터 는 역방향 인원 의 눈앞 에 노출 된다.이 럴 때 http 스냅 백 을 제한 할 수 있 습 니 다.NSURLSessionConfiguration 의 connection ProxyDictionary 를 빈 사전 으로 설정 하 는 것 은 간단 합 니 다.이 속성 은 세 션 을 제어 할 수 있 는 프 록 시 입 니 다.공식 문서,즉 참고 자료 5 를 참조 할 수 있 습 니 다.다음은 AFNetWorking 에 대한 사용 방법 입 니 다.

//    AFHTTPSessionManager，      
- (instancetype)initWithServerHost:(PDLServerHost*)serverHost {
#ifdef DEBUG
    // debug             
    self = [super initWithBaseURL:serverHost.baseURL];
#else
//      ephemeralSessionConfiguration session         cookie       
    NSURLSessionConfiguration *conf = [NSURLSessionConfiguration ephemeralSessionConfiguration];
    conf.connectionProxyDictionary = @{};
    self = [super initWithBaseURL:serverHost.baseURL sessionConfiguration:conf];
#endif
    return self;
}

그러나 OC 방법 은 훅 에 쉽게 걸 리 기 때문에 가방 을 잡 는 것 을 피 하 는 것 은 불가능 하기 때문에 개인 적 으로 가장 좋 은 방법 은 요청 매개 변 수 를 암호 화 하 는 것 이 라 고 생각 합 니 다(비대 칭 암호 화,예 를 들 어 RSA).
하 드 인 코딩 을 헷 갈 리 게 하 는 명문 문자열
깨 진 바 이 너 리 파일 에 대해 역방향 분석 자 는 코드 를 분석 하 는 데 중요 한 단 서 를 가지 고 있다.즉,하 드 코딩 된 명문 문자열 이다.예 를 들 어 앱 이 캡 처 되 었 고 일부 데이터 요청 인터페이스 도 발견 되 었 습 니 다.그러면 간단 합 니 다.역방향 인원 은 특징 이 뚜렷 한 문자열 을 호퍼 에 직접 복사 하여 검색 할 수 있 습 니 다.이 문자열 이 인 용 된 곳 을 보면 해당 하 는 논리 코드 를 빨리 찾 을 수 있 습 니 다.
이 단계 에 대한 예방 은 하 드 코딩 의 명문 을 암호 화하 거나 혼동 하 는 것 이다.UAObfuscated String 을 사용 할 수 있 는 오픈 소스 코드 가 있 습 니 다.그러나 이 오픈 소스 혼동 코드 가 쓴 문자열 은 상당히 길 고 암호 화 를 지원 하지 않 습 니 다.최근 에 저 는 컴 파일 하 는 동안 모든 코드 의 명문 문자열 을 암호 화하 고 app 이 실 행 될 때 문자열 을 복호화 할 수 있 는 도 구 를 썼 습 니 다.이 도구 의 특징 은 다음 과 같다.
1.간단 합 니 다.개발 자 는 명문 문자열 을 하 드 코딩 할 수 있 고 모든 암호 화 는 컴 파일 이 시 작 될 때 자동 으로 처 리 됩 니 다.
2.암호 화 또는 혼동 방식 을 사용자 정의 할 수 있 습 니 다.(app 운행 효율 에 영향 을 주지 않 기 위해 간단 하고 빠 른 암호 화 또는 혼동 방식 을 제공 해 야 합 니 다)복호화 난이 도 를 높 일 수 있 습 니 다.
Swift 개발 사용
Swift 는 현재 비교적 새로운 iOS 언어 를 개발 하고 있 습 니 다.Swift 는 아직 안정 적 이지 않 기 때문에 탈옥 소스 커 뮤 니 티 에서 이것 에 대한 지원 도 실시 간 으로 이 루어 지지 않 습 니 다.예 를 들 어 class-dump 도 구 는 현재 Swift 가 함 유 된 바 이 너 리 파일 을 지원 하지 않 습 니 다.TheOS 도 최근 에 야 Swift 를 지원 하기 시 작 했 지만 메 인 분기 에 추가 되 지 않 았 습 니 다(Features 참조).그래서 현재 로 서 는 적어도 Swift 가 순수 OC 프로젝트 보다 안전 할 것 으로 보인다.물론 Swift 가 안정 되 고 탈옥 개원 커 뮤 니 티 의 지원 이 이 뤄 지면 서 이 같은 장점 은 뚜렷 하지 않 을 것 으로 보인다.
정적 내 연 C 함수 사용
OC 언어의 동태 성 으로 인해 OC 의 코드 는 가장 쉽게 풀 리 고 분석 된다.보안 상 C 언어 로 작 성 된 함 수 를 추천 합 니 다.그러나 C 언어의 함수 도 hook 에 걸 릴 수 있 습 니 다.주로 세 가지 방식 이 있 습 니 다.
1.페 이 스 북 오픈 소스 fishhook 사용
2.MobileSubstrate 가 제공 하 는 hook C 언어 함 수 를 사용 하 는 방법

void MSHookFunction(void* function, void* replacement, void** p_original);

3.mach 사용override,mach 에 대하 여override 와 fishhook 의 차 이 는 machoverride 와 fishhook 의 차이
위의 이 세 가지 방식 은 hook C 함 수 를 사용 할 수 있 기 때문이다.hook 에 의 해 해결 되 지 않 으 려 면 정적 내 연 함 수 를 사용 해 야 합 니 다.그러면 hook 의 함수 에 의 해 통 일 된 입구 가 없어 야 합 니 다.역방향 인원 이 풀 려 면 이 함수 의 논 리 를 이해 할 수 밖 에 없습니다.
block 사용
엄 밀 히 말 하면 block 을 사용 하 는 것 은 안전성 을 크게 향상 시 키 지 못 합 니 다.역방향 인원 이 이 block 을 사용 하 는 방법 을 찾 으 면 보통 그 근처에 block 내 코드 의 논리 가 있 기 때 문 입 니 다.
그러나 개인 적 으로 block 을 사용 하 는 안전성 은 oc 방법 을 직접 사용 하 는 것 보다 높다 고 생각 합 니 다.제 역방향 분석 app 의 경험 에서 block 을 사용 하 는 방법 에 대해 저 는 아직 어떻게 hook 하 는 지 모 르 겠 습 니 다.따라서 내 축 C 함수,블록,블록 형식 파 라 메 터 를 조합 할 수 있다 면 안전성 이 어느 정도 향상 되 었 을 것 입 니 다.
코드 혼동
코드 가 헷 갈 리 는 방식 은 몇 가지 가 있 습 니 다.
쓸모없는 논리 에 영향 을 주지 않 는 코드 세 션 을 추가 하여 역방향 인원 을 헷 갈 리 게 합 니 다.
관건 적 인 클래스,방법 에 대해 실제 의도 와 무관 한 이름 으로 명명 하 다.
개인 적 으로 가장 좋 은 암호 화 혼동 도 구 는 ios-class-guard 라 고 생각 하지만 현재 이 프로젝트 는 유지 보수 가 중단 되 었 습 니 다.하지만 이런 방식 의 혼동 이 야 말로 최종 적 인 방안 이 라 고 생각 합 니 다.
기타 방법
예 를 들 어 ptrace 반전 시험 등(하지만 이미 쉽게 돌아 갈 수 있다 고 합 니 다)

// see http://iphonedevwiki.net/index.php/Crack_prevention for detail
static force_inline void disable_gdb() {
#ifndef DEBUG
    typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#ifndef PT_DENY_ATTACH
#define PT_DENY_ATTACH 31
#endif
    // this trick can be worked around,
    // see http://stackoverflow.com/questions/7034321/implementing-the-pt-deny-attach-anti-piracy-code
    void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
    ptrace_ptr_t ptrace_ptr = dlsym(handle, [@"".p.t.r.a.c.e UTF8String]);
    ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
    dlclose(handle);
#endif
}

주의 사항
OC 의 실행 시 특성 과 mach-o 바 이 너 리 파일 의 구 조 를 알 아 보고 기 존의 도 구 를 통 해 hook 방법 이 간단 하 다 는 것 을 알 게 될 것 입 니 다.위 에서 제 가 안전성 을 향상 시 키 는 몇 가지 방안 을 언급 했 지만 모든 방식 은 역방향 인원 의 역방향 난이 도 를 증가 시 켰 을 뿐 app 을 단단 하 게 만 들 수 없습니다.하지만 일정한 조 치 를 취 하 는 것 은 어떤 조치 도 취하 지 않 는 것 보다 안전 할 것 이다.
이상 은 IOS 가 app 에 대해 어떻게 안전 보강 을 하 는 지 에 대한 상세 한 내용 입 니 다.IOS 가 app 에 대해 어떻게 안전 보강 을 하 는 지 에 관 한 자 료 는 저희 의 다른 관련 글 에 관심 을 가 져 주 십시오!