SSL 핀닝 우회 프록시를 통한: 애플리케이션 테스트

```html

프록시를 설정하고 장치를 연결했지만 애플리케이션이 트래픽을 표시하지 않거나 오류로 종료됩니다. 문제는 SSL Pinning일 가능성이 높습니다. 이는 개발자가 HTTPS 요청의 가로채기를 방지하기 위해 애플리케이션에 의도적으로 내장하는 보안 메커니즘입니다. 이는 경쟁 애플리케이션의 행동을 분석하거나 광고 통합을 테스트하거나 마켓플레이스 API를 연구하는 모든 사람에게 골칫거리가 됩니다.

이 가이드에서는 SSL Pinning이 무엇인지, 왜 프록시와의 작업을 방해하는지, 그리고 이를 우회하는 방법을 단계별로 설명합니다. 불필요한 이론 없이 진행하겠습니다.

SSL Pinning이란 무엇이며 애플리케이션에 왜 내장되는가

SSL Pinning(또는 Certificate Pinning)은 모바일 애플리케이션이 특정 SSL 인증서 또는 서버의 공개 키를 미리 "내장"하는 보안 메커니즘입니다. 연결할 때마다 애플리케이션은 서버의 인증서가 내장된 것과 일치하는지 확인합니다. 일치하지 않으면 연결이 끊어집니다.

일반적인 HTTPS 구조에서는 브라우저나 애플리케이션이 신뢰할 수 있는 인증 기관(CA)에 의해 서명된 모든 인증서를 신뢰합니다. Charles Proxy나 mitmproxy와 같은 프록시 도구는 이러한 점을 이용하여 자신의 인증서를 삽입하고 트래픽을 해독하여 전달합니다. 사용자는 모든 데이터 교환을 명확하게 볼 수 있습니다.

SSL Pinning은 이 구조를 깨뜨립니다. 애플리케이션은 프록시 도구의 인증서를 인식하고, 그것이 서버의 "원래" 인증서와 일치하지 않음을 이해하여 작동을 거부합니다. 그래서 SSL handshake failed, Certificate verification failed와 같은 오류가 발생하거나 애플리케이션에서 빈 화면이 표시됩니다.

개발자들이 SSL Pinning을 도입하는 이유는 여러 가지가 있습니다:

Man-in-the-Middle(MITM) 공격으로부터 보호
API의 리버스 엔지니어링 방지
봇 및 자동화된 요청으로부터 보호
내부 수익화 및 광고 통합 로직 숨기기

SSL Pinning을 적극적으로 사용하는 애플리케이션에는 은행 애플리케이션, 마켓플레이스(Wildberries, Ozon), 광고 SDK(Facebook, TikTok), 결제 시스템 및 대형 전자상거래 플랫폼이 포함됩니다. 이러한 이유로 SSL Pinning을 우회하는 것은 마케팅 전문가, 중재자 및 경쟁 분석 전문가에게 매우 중요합니다.

애플리케이션에 SSL Pinning이 있을 경우 프록시가 작동하지 않는 이유

전화기에서 프록시를 설정할 때(예: Wi-Fi 설정을 통해) 모든 HTTP 및 HTTPS 트래픽이 프록시 서버를 통해 전달됩니다. HTTP의 경우 문제없이 작동하지만 — 트래픽이 이미 공개되어 있기 때문입니다. 그러나 HTTPS의 경우 프록시 도구는 자신의 인증서를 사용하여 서버로 "자신을 나타내야" 합니다.

여기서 충돌이 발생합니다. 일반 애플리케이션은 프록시 도구의 루트 인증서를 장치의 시스템 저장소에 설치하면 이 인증서를 수용합니다. 그러나 SSL Pinning이 있는 애플리케이션은 시스템 저장소를 무시하고 자신의 "내장된" 인증서만 확인합니다.

실제 사례:

Charles Proxy를 연결하고 iPhone에 루트 인증서를 설치한 후 마켓플레이스 애플리케이션을 실행하면 오류가 발생하거나 빈 화면이 나타납니다. Charles의 로그에는 빈 내용이나 SSL 오류가 기록됩니다. 이것이 SSL Pinning이 작동하는 전형적인 모습입니다.

중요한 점은 문제의 원인이 프록시 서버(거주지, 모바일 또는 데이터 센터)에 있지 않다는 것입니다. 프록시는 여기서 트래픽을 라우팅하는 중간 노드 역할을 합니다. 문제는 인증서를 변경한 애플리케이션 자체에 있습니다. 따라서 해결책은 프록시 서버가 아닌 애플리케이션이나 장치 수준에서 찾아야 합니다.

SSL Pinning에는 여러 유형이 있으며, 우회 난이도가 다릅니다:

Pinning 유형	검사되는 항목	우회 난이도
Certificate Pinning	서버의 전체 인증서	중간
Public Key Pinning	인증서의 공개 키	높음
Hash Pinning	인증서 또는 키의 해시	높음
Network Security Config	Android의 구성 파일(XML)	낮음–중간

트래픽 가로채기 도구: Charles, mitmproxy, Burp Suite

SSL Pinning을 우회하기 전에 트래픽 가로채기 도구를 선택해야 합니다. 모든 도구는 동일한 원리로 작동합니다: 로컬 프록시 서버를 설정하여 장치의 트래픽이 통과하게 합니다. 차이점은 편리함, 기능 및 가격에 있습니다.

Charles Proxy

기술적인 배경이 없는 마케팅 전문가와 테스터들 사이에서 가장 인기 있는 도구입니다. 그래픽 인터페이스가 있으며 Windows와 macOS에서 작동합니다. 모든 요청과 응답을 편리한 트리 형태로 볼 수 있으며, 도메인별로 필터링하고 요청을 실시간으로 수정할 수 있습니다. 유료이지만 무료 체험 기간이 있습니다. 마켓플레이스 API 및 광고 SDK 분석에 적합합니다.

mitmproxy

오픈 소스의 무료 도구입니다. 명령줄을 통해 작동하지만 웹 인터페이스(mitmweb)가 있습니다. 매우 유연하며, 트래픽을 자동으로 수정하는 스크립트를 지원합니다. 분석을 자동화하거나 테스트 파이프라인에 가로채기를 통합하려는 사람들에게 적합합니다. Charles보다 설정이 약간 더 복잡합니다.

Burp Suite

보안 테스트를 위한 전문 도구입니다. 기본 기능을 갖춘 무료 Community 버전이 있습니다. 요청을 상세히 분석하고 쿠키 및 세션을 다루는 데 특히 유용합니다. 경쟁 API 분석 및 광고 통합 연구에 적극적으로 사용됩니다. 인터페이스는 Charles보다 복잡하지만 기능은 더 다양합니다.

도구	인터페이스	가격	대상
Charles Proxy	GUI (편리함)	유료 (~$50)	마케팅 전문가, 분석가
mitmproxy	CLI + 웹 UI	무료	기술 전문가
Burp Suite	GUI (복잡함)	무료 / 프로	보안 테스터

마케팅 전문가나 중재자가 광고 요청 분석, 마켓플레이스 API 연구, 애플리케이션 트래픽 모니터링 등의 작업을 수행할 때 Charles Proxy가 최적의 선택이 될 것입니다. 자동화가 필요하거나 GUI 없이 작업하려면 mitmproxy를 사용하세요.

SSL Pinning 우회 방법: 간단한 것부터 고급까지

SSL Pinning을 우회하는 방법은 여러 가지가 있으며, 난이도, 장치 요구 사항 및 신뢰성에 따라 다릅니다. 각 방법을 간단한 것부터 강력한 것까지 살펴보겠습니다.

방법 1: 시스템 저장소에 인증서 설치하기 (Android 전용)

가장 간단한 방법이지만 시스템 인증서 저장소를 사용하는 애플리케이션에만 적용됩니다. Android 7.0 이전에는 사용자 인증서가 시스템 인증서와 동일하게 수용되었습니다. Android 7.0부터는 애플리케이션이 기본적으로 사용자 CA를 무시합니다. 애플리케이션이 network_security_config.xml에서 사용자 인증서를 명시적으로 허용하는 경우 이 방법이 작동합니다. 그러나 대부분의 현대 애플리케이션에서는 SSL Pinning이 적용되어 도움이 되지 않습니다.

방법 2: Frida — 애플리케이션 동적 패치

Frida는 애플리케이션을 동적으로 도구화하는 도구입니다. 애플리케이션 내부의 함수 호출을 "실시간"으로 가로채고 그 동작을 변경할 수 있습니다. SSL Pinning을 우회하기 위한 준비된 스크립트가 있으며, APK를 수정하지 않고 인증서 검사를 비활성화합니다. Android에서는 루트 권한이 필요하고 iOS에서는 탈옥이 필요합니다. 가장 신뢰할 수 있고 범용적인 방법입니다.

방법 3: APK 패치하기 (Android)

apktool을 사용하여 APK 파일을 디컴파일하고, SSL Pinning 코드를 삭제하거나 수정한 후 애플리케이션을 다시 빌드하고 서명합니다. 루트 권한이 필요하지 않지만 smali 코드 작업에 대한 기술적 지식이 필요합니다. Network Security Config를 통해 간단하게 Pinning을 구현한 애플리케이션에 잘 작동합니다. 네이티브 코드(C/C++)가 있는 애플리케이션에서는 훨씬 더 복잡합니다.

방법 4: Objection — 초보자를 위한 Frida 래퍼

Objection은 Frida 기반의 도구로, 보다 간단한 명령줄 인터페이스를 제공합니다. SSL Pinning을 한 번의 명령으로 우회하는 내장 명령이 포함되어 있습니다: android sslpinning disable. Frida 스크립트를 수동으로 작성하는 데 관심이 없는 사람들에게 적합합니다. 루트 권한이나 탈옥이 필요합니다.

방법 5: 루트가 있는 에뮬레이터 사용하기

실제 장치 대신 루트 권한이 활성화된 Android 에뮬레이터(예: Genymotion 또는 Android Studio의 기본 AVD)를 사용할 수 있습니다. 이를 통해 시스템 인증서를 설치하고 Frida를 실행할 수 있으며, 실제 전화기를 "브릭"할 위험이 없습니다. 작업 환경에서 정기적으로 테스트하기에 편리한 옵션입니다.

Android에서 SSL Pinning을 단계별로 우회하기

가장 실용적인 시나리오를 살펴보겠습니다: 루트가 있는 Android 장치 또는 에뮬레이터, Objection + Frida 도구, Charles Proxy 또는 mitmproxy 프록시 도구.

필요한 것:

루트가 있는 Android 장치 또는 Genymotion 에뮬레이터
Python 3가 설치된 컴퓨터
Android용 Frida-server (GitHub에서 다운로드)
Objection (pip를 통해 설치)
컴퓨터에 Charles Proxy 또는 mitmproxy
ADB (Android Debug Bridge)

1단계: 컴퓨터에서 프록시 도구 설정하기

Charles Proxy 또는 mitmproxy를 실행합니다. 기본적으로 이들은 포트 8888(Charles) 또는 8080(mitmproxy)을 수신합니다. 장치에서 프록시를 설정할 때 필요한 컴퓨터의 IP 주소를 기억해 두세요.

2단계: Android 장치에서 프록시 설정하기

Wi-Fi 설정으로 이동 → 네트워크 선택 → "변경" 클릭 → "고급 옵션" → 프록시: 수동. 컴퓨터의 IP와 도구의 포트를 입력합니다. 이제 장치의 모든 트래픽이 프록시를 통해 전달됩니다.

3단계: 프록시 도구의 인증서 설치하기

장치의 브라우저를 열고 chls.pro/ssl (Charles의 경우) 또는 mitm.it (mitmproxy의 경우)로 이동합니다. 인증서를 다운로드하고 설치합니다. 루트가 있는 Android에서는 인증서를 시스템 저장소로 이동해야 합니다 — 이는 일부 애플리케이션에 필요합니다.

4단계: 장치에서 Frida-server 실행하기

GitHub에서 필요한 버전의 frida-server를 다운로드합니다 (버전은 컴퓨터의 Frida 버전과 일치해야 합니다). ADB를 통해 파일을 장치에 업로드합니다:

adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "su -c /data/local/tmp/frida-server &"

5단계: Objection을 통해 연결하고 SSL Pinning 비활성화하기

컴퓨터에서 pip를 통해 Objection을 설치하고 애플리케이션의 패키지 이름을 지정하여 실행합니다:

pip install objection
objection -g com.example.app explore

연결 후 Objection 콘솔에서 SSL Pinning 비활성화 명령을 실행합니다:

android sslpinning disable

이후 애플리케이션을 열고 상호작용을 시작합니다. 트래픽이 Charles 또는 mitmproxy에서 해독된 형태로 나타납니다.

6단계: Network Security Config가 있는 애플리케이션의 경우

애플리케이션이 network_security_config.xml을 사용하는 경우, apktool을 통해 APK를 디컴파일하고 이 파일을 찾아 사용자 인증서에 대한 권한을 추가한 후 APK를 다시 빌드하고 서명합니다. 이는 루트 권한 없이 작동하지만 애플리케이션의 서명 검사를 비활성화해야 합니다.

iOS에서 SSL Pinning을 단계별로 우회하기

iOS에서는 상황이 더 복잡합니다: 대부분의 방법에는 탈옥이 필요합니다. 탈옥이 없으면 가능성이 제한됩니다. 두 가지 옵션을 살펴보겠습니다.

옵션 A: 탈옥이 있는 경우 (iOS 14-16, checkra1n / palera1n)

1단계: 프록시 설정하기

iPhone에서 설정 → Wi-Fi → 네트워크 → 프록시 설정 → 수동으로 이동합니다. 컴퓨터의 IP와 Charles/mitmproxy의 포트를 입력합니다.

2단계: 인증서 설치하기

Safari를 열고 chls.pro/ssl로 이동합니다. 설정 → 일반 → VPN 및 장치 관리에서 프로필을 설치합니다. 그런 다음 설정 → 일반 → 인증서 신뢰에서 활성화합니다.

3단계: Cydia/Sileo를 통해 SSL Kill Switch 2 설치하기

SSL Kill Switch 2는 탈옥된 iOS용 트윅으로, 모든 애플리케이션에 대해 SSL Pinning을 전역적으로 비활성화합니다. Cydia 또는 Sileo에서 찾아 설치한 후 장치를 재부팅합니다. 이후 대부분의 애플리케이션이 인증서를 확인하지 않게 되며, Charles에서 트래픽을 볼 수 있습니다.

4단계: 대안 — iOS에서 Frida + Objection 사용하기

Android와 유사하게: Cydia를 통해 frida-server를 설치하고, 컴퓨터에서 Objection을 통해 연결한 후 ios sslpinning disable를 실행합니다. 이 방법은 더 유연하며 SSL Kill Switch 2가 적용되지 않는 애플리케이션에서도 작동합니다.

옵션 B: 탈옥 없이 (제한된 가능성)

탈옥 없이 iOS에서 SSL Pinning을 우회하는 것은 훨씬 더 어렵습니다. 한 가지 옵션은 탈옥 없이 iOS용 SSL Proxying 기능이 있는 Proxyman 도구를 사용하는 것입니다. Proxyman은 장치에 특별한 프로필을 설치하고 VPN 인터페이스를 사용하여 트래픽을 가로챕니다. 많은 애플리케이션에서 작동하지만 모든 애플리케이션에서 작동하지는 않습니다.

또 다른 옵션은 Xcode에서 iOS 시뮬레이터를 사용하는 것입니다. 시뮬레이터는 OS 수준에서 SSL Pinning이 없으며, 많은 애플리케이션을 실행할 수 있습니다(시뮬레이터를 지원하는 경우). 그러나 이는 테스트에만 적합하며 프로덕션 애플리케이션 분석에는 적합하지 않습니다.

모바일 애플리케이션 테스트를 위한 프록시 유형 선택하기

SSL Pinning을 우회한 후 애플리케이션의 트래픽이 프록시 도구(Charles, mitmproxy)를 통해 전달됩니다. 그러나 특정 작업을 수행하기 위해 외부 프록시 서버를 통해 트래픽을 라우팅해야 할 수도 있습니다. 예를 들어 애플리케이션이 다른 지역이나 다른 IP 주소를 "보도록" 하기 위해서입니다. 여기서 올바른 프록시 유형을 선택하는 것이 중요합니다.

주거용 프록시

주거용 프록시는 실제 가정 사용자의 IP 주소를 사용합니다. 모바일 애플리케이션, 특히 광고 SDK 및 마켓플레이스는 데이터 센터의 주소보다 이러한 IP를 훨씬 더 신뢰합니다. 애플리케이션의 지역에 따른 행동을 분석하는 경우 주거용 프록시가 가장 "깨끗한" 그림을 제공하여 실제 사용자에 가까운 결과를 얻을 수 있습니다.

모바일 프록시

모바일 프록시는 실제 모바일 네트워크(3G/4G/5G)를 통해 작동합니다. 이는 모바일 애플리케이션 테스트 시 특히 중요합니다: 모바일 네트워크의 IP는 Facebook Ads SDK, TikTok 및 기타 광고 플랫폼에서 가장 높은 신뢰도를 가집니다. 애플리케이션의 광고 요청을 분석하거나 모바일 환경에서 SDK의 행동을 테스트하려는 경우 모바일 프록시가 최적의 선택입니다.

데이터 센터 프록시

데이터 센터 프록시는 속도가 중요하고 "자연스러움"이 덜 중요한 작업에 적합합니다: 예를 들어 공개 API의 대량 파싱이나 성능 테스트를 위해서입니다. 광고 SDK 및 보호된 애플리케이션 분석에는 덜 선호됩니다. 왜냐하면 쉽게 사기 방지 시스템에 의해 인식되기 때문입니다.

프록시 유형	애플리케이션의 신뢰도	속도	최고의 시나리오
주거용	높음	중간	지역별 분석, 마켓플레이스
모바일	최대	중간	광고 SDK, Facebook, TikTok
데이터 센터	낮음	높음	공개 API 파싱, 부하 테스트

실제 시나리오: 중재, 전자상거래, 마케팅

마케팅 전문가와 중재자들이 SSL Pinning을 우회하는 이유를 살펴보겠습니다.

시나리오 1: Facebook 및 TikTok 광고 SDK 분석

Facebook Ads 및 TikTok Ads와 함께 작업하는 중재자들은 종종 SDK가 서버에 전달하는 데이터, 어떤 이벤트가 기록되는지, 어떻게 속성 요청이 형성되는지, 어떤 매개변수가 캠페인 최적화에 영향을 미치는지 이해하고 싶어합니다. SSL Pinning을 우회하지 않으면 이는 불가능합니다 — 두 SDK 모두 Certificate Pinning을 사용합니다.

Frida/Objection을 통해 우회한 후 Charles에서 모든 SDK 이벤트(설치, 구매, 등록 등)를 볼 수 있으며, 추적이 올바르게 설정되었는지 확인할 수 있습니다. 이는 CAPI(Conversions API) 설정 및 이벤트 중복 검증 시 특히 중요합니다.

시나리오 2: Wildberries 및 Ozon의 가격 모니터링

Wildberries 및 Ozon 애플리케이션은 API를 보호하기 위해 SSL Pinning을 사용합니다. 모바일 애플리케이션(웹 버전이 아닌)을 통해 경쟁자의 가격을 모니터링하려는 판매자들은 이 보호 장치에 직면하게 됩니다. SSL Pinning을 우회한 후 API 요청 구조를 분석하고 가격, 재고 및 상품 평점에 대한 데이터를 얻기 위해 어떤 엔드포인트가 사용되는지 이해할 수 있습니다.

중요: 얻은 데이터는 개인 분석에만 사용해야 합니다. API 요청 재생을 통한 자동화된 파싱은 플랫폼의 이용 약관을 위반합니다.

시나리오 3: 다양한 지역의 광고 크리에이티브 테스트

Facebook Ads 및 TikTok Ads에서 다양한 지역의 광고를 테스트하는 마케팅 전문가들은 특정 국가의 IP를 통해 연결할 때 애플리케이션이 어떻게 작동하는지 보고 싶어합니다. SSL Pinning 우회 + 필요한 지역의 주거용 프록시 조합을 통해 해당 지역의 사용자에게 어떤 콘텐츠와 가격이 표시되는지 확인할 수 있습니다.

시나리오 4: 자체 애플리케이션 QA 테스트

자체 모바일 애플리케이션을 개발하거나 개발 팀과 협력하는 경우, SSL Pinning을 우회하여 트래픽을 가로채는 것은 QA의 표준 관행입니다. 이를 통해 요청의 정확성을 확인하고 데이터 유출을 찾아내며, 출시 전에 실제 조건에서 분석 및 광고 SDK의 작동을 검증할 수 있습니다.

시나리오 5: 모바일 게임 및 애플리케이션의 경쟁 분석

모바일 게임 마케팅 전문가들은 경쟁자의 수익화 분석을 위해 트래픽을 가로채는 방법을 사용합니다: 어떤 오퍼가 표시되는지, 인게임 구매 시스템은 어떻게 작동하는지, 어떤 광고 네트워크가 사용되는지. 이는 더 효과적인 UA(User Acquisition) 및 수익화 전략을 구축하는 데 도움이 됩니다.

테스트 전에 설정을 확인하는 체크리스트

트래픽 가로채기를 시작하기 전에 모든 것이 올바르게 설정되었는지 확인하십시오. 전체 체크리스트는 다음과 같습니다:

✅ 설정 체크리스트

프록시 도구(Charles/mitmproxy)가 컴퓨터에서 실행 중이며 필요한 포트를 수신하고 있습니다.
컴퓨터와 장치가 동일한 Wi-Fi 네트워크에 있습니다.
장치의 Wi-Fi 설정에서 올바른 컴퓨터 IP와 프록시 포트가 지정되어 있습니다.
프록시 도구의 루트 인증서가 장치에 설치되어 있습니다.
Android: 인증서가 시스템 저장소로 이동되었습니다(루트가 있는 경우).
iOS: 인증서가 "인증서 신뢰" 섹션에서 활성화되었습니다.
Frida-server가 장치에서 실행 중입니다(Frida/Objection을 사용하는 경우).
컴퓨터의 Frida 버전이 장치의 frida-server 버전과 일치합니다.
Objection이 애플리케이션 프로세스에 성공적으로 연결되었습니다.
android sslpinning disable 명령이 오류 없이 실행되었습니다.
애플리케이션 작업 중 Charles/mitmproxy에 기록이 나타납니다.
HTTPS 요청이 해독됩니다(SSL 오류가 표시되지 않습니다).

자주 발생하는 문제 및 해결책

문제	원인	해결책
Charles에서 트래픽이 나타나지 않음	잘못된 IP/포트 프록시	컴퓨터의 IP와 포트를 확인하세요.
Charles에서 SSL 오류	인증서가 설치되지 않았거나 활성화되지 않음	인증서를 재설치하고 활성화하세요.
Frida가 연결되지 않음	frida/frida-server 버전 불일치	버전을 동기화하세요.
Objection이 Pinning을 비활성화하지 않음	Pinning이 있는 네이티브 코드(C/C++)	커스텀 Frida 스크립트를 사용하세요.
우회 후 애플리케이션이 크래시됨	애플리케이션이 무결성을 검사함	Objection을 통해 루트 감지 또한 비활성화하세요.

결론

SSL Pinning은 강력한 보안이지만 극복할 수 없는 것은 아닙니다. 마케팅 전문가나 중재자의 대부분의 실용적인 작업에는 Android 에뮬레이터 + Frida/Objection + Charles Proxy 조합이 충분합니다. iOS에서는 탈옥이 있는 경우 SSL Kill Switch 2를 사용하거나 탈옥 없이 Proxyman을 사용할 수 있습니다. 중요한 것은 올바른 체인을 설정하는 것입니다: 컴퓨터의 프록시 도구 → 그를 통한 트래픽 → 장치에서 Pinning 우회.

타사 애플리케이션에서 SSL Pinning을 우회하는 것은 개인 분석 및 연구를 위해서만 허용됩니다. 자동화된 파싱 및 API 요청 재생은 대부분의 플랫폼의 이용 약관을 위반합니다.

모바일 애플리케이션의 트래픽을 다양한 지역에서 분석하거나 특정 국가의 광고 SDK 행동을 테스트하려는 경우, SSL Pinning 우회뿐만 아니라 품질 좋은 프록시 서버도 필요합니다. 광고 플랫폼(Facebook Ads, TikTok Ads) 및 마켓플레이스와 작업할 때는 모바일 프록시를 사용하는 것이 좋습니다 — 이들은 사기 방지 시스템에서 가장 높은 신뢰도를 가지며 실제 모바일 환경을 정확하게 에뮬레이트할 수 있습니다.