Raining_93

 
이전의 웨이브(Wavve) 분석과 다운로드 받는 것까지 진행해 보았다.
 
그때 내 폰에 있던 OTT 계정이 Wavve, 쿠팡플레이, Netflix 이렇게 3개였는데,
 
Wavve가 되었으니 다른 OTT도 같은 방식으로 될까?라는 생각이 들었다.
 
또, 쿠팡플레이는 HBO 오리지널 콘텐츠를 국내 독점으로 제공하고 있다.
 
해외 대형 스튜디오의 콘텐츠를 독점으로 들여왔다면,
 
그만큼 콘텐츠 보호에도 더 신경을 썼을 것이라는 생각이 들었다.
 
그래서 이번에는 쿠팡플레이를 분석해 보았다.
 
이번에는 Wavve를 한 번 분석해 봤기 때문에 조금 더 구체적으로 가설을 세워봤다.
 
1. 쿠팡플레이도 당연히 DRM이 적용되어 있을 것이다.
2. 다만 Wavve와는 DRM 종류나 적용 방식이 다를 수 있다.
3. 그래도 결국 복호화된 원본을 보여주는 구간은 존재할 것이다.
 
먼저 분석에 들어가기 전에 찾아보니,
 
쿠팡플레이 역시 DRM이 적용되어 있었고, 보안 레벨에 따라 볼 수 있는 화질이 달라진다는 것이다.
 
즉, Wavve에서 분석했던 것과 똑같이 기기와 환경의 보안 수준이 높을수록 더 좋은 화질을 열어주는 구조인 것이다.
 
여기까지는 예상했던 대로였다.
 
그래서 본격적으로 분석을 하기 위해, 로그인 과정과 패킷을 살펴보았다.
 
그런데 분석을 진행하던 중 아래와 같이 Access Denied 화면이 뜨면서 로그인과 접속이 모두 차단되었다.
 
Access Denied로 로그인과 접속이 차단되었다.
 

 
예상하기로는, 분석하면서 로그인을 여러 번 반복하고 요청을 계속 보내다 보니
 
서버 쪽에서 이를 봇이나 크롤링 같은 비정상 접근으로 판단하고 일시적으로 차단한 것 같다.
 
웹이 막혔으니 어쩔 수 없이 분석 환경을 모바일로 옮겼다.
 
그런데 루팅된 폰에서 앱을 실행하니 이번에는 다음과 같이 탐지 알림이 발생하였다.
 

 
알림 문구를 보면 "보안상의 문제로 루팅된 기기에서는 앱을 실행할 수 없다" 라고 나온다.
 
즉, 쿠팡플레이는 앱 실행 단계에서 루팅 여부를 확인하고, 루팅된 기기라면 아예 실행 자체를 막고 있는 것이다.
 
그래서 해당 탐지 로직을 찾아서 우회하였고, 그 결과 아래와 같이 정상적으로 로그인 화면을 볼 수 있었다.
 

 
 
웹에서는 서버 차단, 모바일에서는 루팅 탐지까지,
 
영상을 보기도 전에 벌써 두 번이나 막힌 셈이다.
 
그렇게 로그인을 한 후 다시 분석을 이어갔다.
 
영상을 하나 재생한 후, 당연하게도 녹화나 캡처를 시도하면 아래와 같이 검은색 화면으로 스크린샷이 찍힌다.
 

 
화면에서는 영상이 잘 재생되고 있는데, 캡처를 하면 검은 화면만 남는다.
 
이렇게 해서 처음에 세웠던 가설 중 1번과 3번은 확인이 되었다.
 
1. 쿠팡플레이도 당연히 DRM이 적용되어 있을 것이다.
→ 캡처 시 검은색 화면이 찍히는 것으로 확인
 
3. 그래도 결국 복호화된 원본을 보여주는 구간은 존재할 것이다.
→ 영상이 정상적으로 재생된다는 것 자체가, 어딘가에서 복호화가 이루어지고 있다는 뜻
 
남은 것은 2번이다.
 
이제 2번에 대한 결론을 내기 위해서는 쿠팡플레이가 실제로 어떤 DRM을,
 
어떤 레벨로 적용하고 있는지 직접 확인해야 한다.
 
결과적으로는 2번도 Wavve와 크게 다르지 않았다.
 
막상 분석해 보니 DRM 자체의 구조나 적용 방식은 Wavve와 거의 같았다.
 

 
위의 사진은 1920x1080의 영상인것을 확인할 수 있다.
 
아래의 그림은 다운로드 받은 영상이다.
 

이번 추석 때 1시간 정도 시간이 남아서 진짜 오랜만에 PC방에 갔다.

보통은 그냥 평소에 하던 게임을 바로 시작했겠지만, 사람이 너무 많아 요즘 사람들은 어떤 게임을 할까?

하면서 주변을 살펴보았다.

대부분, 명절인 만큼 친구들끼리 롤을 대부분 많이 하였다.

그러다가 간혹 그냥 PC방에서 영화나 드라마를 보는 사람도 많이 있어서

속으로, 굳이 왜 PC방에서 돈 주고 영화나 드라마를 볼까?라는 생각을 했다.

그리고 PC방 바탕화면을 보니 OTT를 볼 수 있는 사이트가 존재하였다.

그래서 그냥 아무생각없이 해당 링크를 통해서 들어가 보니 정말 많은 영상들이 존재했다.

그중에서 각 OTT 회사에서만 볼 수 있는 영상들도 다 같이 볼 수 있도록 되어있었다.

그래서 또 여기서 생각을 해보았다.

이런 불법 사이트들이나 해당 사이트들은 어떻게 OTT 영상들을 스트리밍 할 수 있을까?라는 궁금증이 생겼다.

그래서 현재 내 폰에 OTT 계정이 있는것이, Wavve, Netflix, 쿠팡플레이 이렇게 존재하였고

그 중 Wavve를 자주 즐겨보던 사람이었기 때문에 Wavve를 분석해 보았다.

분석하기 전 그냥 내가 알고 있는 지식을 동원해서 맞는지 모르겠지만 크게 아래의 3가지 가설을 세워봤다.

1. 분명 OTT 영상들은 DRM이 적용되어 있을 것이다.

2. OTT 영상들 중에서도 DRM의 레벨이 다를 것이다.

3. DRM이 적용되어 있다 하더라도 언젠가는 원본(복호화)을 획득할 수 있을 것이다.

이렇게 가설을 세워보았다.

그래서 1번 가설을 증명하기 위해 Wavve에 적용되어 있는 DRM을 찾아보았다.

찾아보니, Wavve에서 당연히 DRM이 적용되어 있었고, 그 단계가 3단계로 나뉘어있다는 것이다.

여기서 왜 2번 가설이 레벨이 다를 것으로 생각을 했었을까?

대부분 난독화 및 암호화, DRM을 분석을 몇 번 해보면 어떤 것은 쉽게 풀리고 어떤것은 시간이 많이 소요된다.

즉, 해당 데이터가 중요한 데이터이면 암호화든 난독화든 DRM이든 가장 강력한 레벨로 적용한다.

따라서, 분석하기 전 2번처럼 생각을 했던 것이다.

이러면 1~2번에 대한 가설에 대한 답이 나왔다.

이제 3번에 대해서 답을 내기 위해서는 분석을 해야 한다.

DRM은 언젠가는 암호화 KEY로 복호화한 후 원본을 사용자에게 보여준다.

따라서, 그 구간만 잘 분석을 하면 원본을 얻을 수 있지 않을까? 해서 분석을 진행하였다.

해당 블로그에 있는 글을 보면 대부분 중간 내용이 없다.

어떤 것을 분석했고, 그 과정이 어떤지에 대한 내용이 없다.

즉, 중간이 없다는 것이다.

그 이유는 한 번씩 언급을 했었지만 악용 가능성이 존재하기 때문에 중간 내용인 

분석 내용은 작성하지 않는 것이다.

추천 영상 중 아무것이나 클릭한 후 화질을 보면

HD와 SD, 모바일 화질 이렇게 3개가 존재한다.

그리고 Wavve에서 재생을 한 후 녹화나 캡처를 진행하려고 하면 아래와 같이 검은색 바탕이 뜬다.

또 다운로드도 할 수 없다.

하지만 분석한 결과, 아래와 같이 FHD 영상을 다운로드할 수 있었다.

먼저 아래와 같이 로그인을 해준다.

이미 로그인을 한 후이기 때문에 위의 계속하기 버튼으로 다음 화면으로 넘어가준다.

그리고 영상 주소와 전체 영상을 다운로드할 것인지, 혹은 몇초만 다운로드 받을것인지 선택해 준다.

또한 자만이 있는 경우 자막 포함을 선택해 주고 전체 영상을 클릭해 주자.

그 후, 아래와 같이 다운로드 받을 폴더를 선택한 다음 다운로드 시작 버튼을 눌러준다.

그리면 아래와 같이 다운로드가 진행된다.

그리고 다운로드가 다되면 아래와 같이 다운로드 완료 표시가 뜬다.

마지막으로 다운로드 받은 파일의 정보 확인하면 다음과 같다.

이렇게 파일로도 다운로드 받을 수가 있었다.

이전에는 모바일에서 DRM을 분석을 해보았다면 이번에는 PC에 적용되는 DRM을 분석해 보자.

이번 포스팅은 분석 과정과 기술적인 내용이 포함되어 있어 조금 내용이 많을 수가 있다.

국내에서 PC 문서 DRM으로 유명한 솔루션 업체는 2개가 있다.

대부분 파수(Fasoo)와 마크애니(MarkAny)를 사용한다.

일단 분석을 하기 위해서는 DRM이 적용된 파일이 있어야 한다.

따라서, 현재 분석할 PC에 적용된 DRM 솔루션은 Fasoo이므로 파수에 대해서 분석을 진행 보았다.

먼저 어떻게 DRM이 적용될까???라는 생각을 했다.

Fasoo 솔루션이 설치된 PC에서 파일이나 문서를 저장하게 된다면 처음에는 아래와 같이 자물쇠 모양이 없다.

하지만 몇 초 있다가 보면 아래와 같이 자물쇠 모양이 생긴다.

즉, 처음에는 평문으로 문서가 저장이 되다가 Fasoo Agent가 파일이 닫힌 시점,

즉 문서 파일 핸들이 닫히는 순간 원본을 암호화한다.

DRM이 적용된 파일을 보면 아래와 같이 Fasoo에 의해 암호화가 되었다는 것을 확인할 수 있다.

어떻게 DRM이 적용될까???라는 질문에 대한 답은 아래처럼 간단하게 답을 할 수 있다.

그냥 DRM은 파일을 암호화하는 것이다.

그렇다면 암호화/복호화가 된다는 것은 Key가 무조건 대칭키일 수밖에 없다.

그리고 대부분의 대칭키이면 AES 계열이다.

그럼 DRM을 적용한 즉, 암호화 때 사용한 Key만 획득하면

모든 DRM이 적용된 문서를 복호화해서 원본을 획득할 수 있지 않을까?

라는 생각으로 분석을 진행하였다.

한참 분석을 진행하다가 문득 다음과 같은 생각이 들었다.

회사에 수많은 PC가 있을것이고, 거기서 수 많은 문서들이 DRM이 적용이 될 텐데,

여기서 암호화 Key가 하나일까?

그렇다면 해당 Key만 획득하면 회사의 모든 PC에 적용된 DRM 문서를 복호화할 수 있다고???

위의 가정이 크게 문제가 되지 않지만 이렇게 되면 사실상 큰일이다.

왜냐하면 Key 하나만 유출됐을 뿐인데 회사 내 모든 PC에 적용된 DRM 파일을 복호화할 수 있다는 말이다.

결국 위의 궁금증을 해결하기 위해서는 실제로 암호화에 쓰인 Key를 눈으로 확인하고 비교해봐야 한다.

두 파일의 Key를 뽑아서 비교해 보면 끝나는 문제다.

같으면 "회사에 Key 하나", 다르면 "파일마다 Key가 따로"인 것이다.

그런데 우리가 원하는 암호화 Key를 비교하기 위해서는  그 Key가 도대체 어디서 만들어지고,

어디를 지나가는지부터 알아야 한다.

그래야 후킹을 하던 뭘 하던 Key가 어떻게 만들어지고, 그 암호화 Key가 뭔지를 알 수 있기 때문이다.

그래서 순서를 이렇게 잡았다.

① 암/복호화가 어디서 일어나는가??

② 1번에서 위치를 확인했다면 해당 Key를 확인한다.

③ 두 개의 Key를 비교한다.

①번에서 위치를 크게 아래와 같이 2가지로 나눌 수 있다.

커널단과 유저단이다.

커널에서 만약 복호화가 된다면 DRM이 적용된 문서는 커널에서 복호화가 된 데이터를 받는다.

따라서, 암/복호화 Key는 커널에 존재하고 그 과정도 커널에서 진행한다.

하지만 유저단, 즉 프로그램 안에서 복호화가 진행된다면 암/복호화 Key는 프로그램 메모리 단에 존재한다는 것이다.

따라서 이때 Key를 추출하면 된다.

자, 간단한 예시를 들어보자.

예를 들자면 잠긴 상자를 열어주는 열쇠집이 있다고 하자.

나는 잠긴 상자(DRM이 적용된 파일)를 들고 해당 열쇠집을 방문했다.

열쇠공이 해당 잠긴 상자를 들고

작업실(커널)에서 상자를 열면, 나는 대기실에서 열린 내용물만 받는다.

열쇠는 작업실 밖으로 안 나오니 어떤 열쇠인지 나는 알 수가 없다.

반대로 열쇠공이 내 눈앞에서 상자를 열면, 어떻게 생겼고 어떤 열쇠인지도 확인할 수 있다.

어쨌든 이 둘 중 어느 쪽인지부터 가려야 했다.

그래서 복호화는 도대체 어디서 일어나는가?

"커널이냐, 프로그램 안이냐"를 가르려면,

먼저 파일을 읽는다는 게 컴퓨터 안에서 실제로 어떤 경로를 타는지부터 알아야 한다.

파일 하나를 열 때는 프로그램에서 아래와 같이 두 단계가 발생한다.

열기(Open), 읽기(READ)

당연한 소리다.

파일을 열어야지 읽을 수 있다.

하지만, 이때 사용되는 함수를 살펴야 한다.

그래야지 Key가 어디서 사용이 되고, Key가 뭔지를 알 수 있기 때문이다.

파일을 Open 할 때는 CreateFileW라는 함수를 사용한다.

HANDLE h = CreateFileW(
    L"C:\\report.txt",      // 어떤 파일을
    GENERIC_READ,           // "읽기만 할게요" (읽을 권한 요청)
    FILE_SHARE_READ,        // 남들도 같이 읽는 건 허용
    NULL,
    OPEN_EXISTING,          // 이미 있는 파일을 열겠다 (새로 안 만듦)
    FILE_ATTRIBUTE_NORMAL,
    NULL
);

CreateFileW는 대출 창구에 가서 "이 책 좀 볼게요" 하고 대출증(핸들)을 받는 행위라고 생각하면 된다.

즉, 아직 내용은 한 글자도 안 읽었습니다. 통로만 뚫린 상태이다.

그다음은 이제 ReadFile로 파일을 읽어야 한다.

char buffer[100];
DWORD bytesRead;
ReadFile(
    h,              // 아까 받은 대출증(핸들)
    buffer,         // 여기다 내용을 담아줘
    100,            // 100바이트만
    &bytesRead,     // 실제로 몇 바이트 읽었는지 알려줘
    NULL
);

이제 위의 ReadFile은 여러 층을 거쳐서 커널까지 내려간다.

 [DRM 파일]
      │  ① ReadFile() 호출
     ▼
 kernel32.dll               ← 프로그램이 제일 먼저 부름. (유저모드, 맨 위 계단)
      │  ② 내부적으로 NtReadFile() 호출
     ▼
 ntdll.dll의 NtReadFile     ← 유저모드의 "마지막 단계"
      │  ③ syscall 명령으로 커널에 진입 (여기서 유저모드 끝)

 ══════════════ 유저모드 / 커널 경계 ══════════════

그래서 ①, ②, ③에 각각 후킹을 걸어보았다.

결과는 다음과 같았다.

①: kernel32!ReadFile -> 원본

②: ntdll.dll!NtReadFile -> 원본

③ syscall -> 암호화

이것으로 복호화는 커널단이 아니라 프로그램(유저모드)에서 일어난다는 것을 알 수 있다.

DRM이 설정된 파일이나 문서가 실행될 때 FASOO 에이전트에 의해 FASOO에서 개발한 DLL 파일이 인젝션 된다.

따라서 어떤 DLL에서 어떤 함수에서 Key를 관리하고, 암/복호화를 담당하고 있는지를 찾는다면?

끝이다.

그래서 FASOO에서 사용하는 모든 DLL을 분석해서 몇 가지 가능성이 있는 DLL을 추렸다.

분석한 결과 암/복호화 과정을 수행하는 DLL과 함수를 찾을 수 있었다.

여기서 파일에 적용한 DRM의 암호화 Key를 획득할 수 있었다.

이제 DRM이 적용된 파일 2개를 비교하여 Key가 같으면

"회사에 Key 하나", 다르면 "파일마다 Key가 따로"인 것에 대한 질문에 답이 나온다.

따라서 아래와 같이 DRM이 적용된 2개의 파일에 대해서 DRM Key를 추출해보니 Key가 서로 달랐다.

이것으로 파일마다 DRM을 적용하는 암/복호화 Key가 다르다는 것을 알 수 있었다.

이제 해당 Key를 가지고 파일을 복호화를 해주면, DRM이 적용된 파일도  아래와 같이 복호화를 할 수 있다.

 
집 앞에 큰 GS 마트에서 결제를 하려고 하니 우리동네GS 애플리케이션을 통해 결제를 하면
 
특정 제품을 할인해 주는 이벤트를 하고 있었다.
 
그래서 처음으로 우리동네GS를 설치하였다.
 
그 후, 직업병인지는 모르겠지만, 해당 애플리케이션은 어떻게 구성되어 있나? 싶어서 
 
패킷을 한번 캡쳐해서 보려고 Burp로 패킷을 보려고 했지만 아무 패킷이 잡히지 않았다.
 
그래서 APK를 아래와 같이 다운로드 후 추출하여 살펴보았다.

 
그리고 습관적으로 lib 폴더를 보았다.
 

 
여기서 libflutter.so 파일을 보고,
 
왜 Burp에서 패킷이 안 잡혔는지 바로 이해가 되었다.
 
그럼 자, Flutter가 뭘까?
 
Flutter는 구글이 개발한 오픈소스 멀티플랫폼 앱 개발 프레임워크이다.
 
하나의 코드(Dart 언어 사용)로 안드로이드, iOS, 웹, 데스크톱 애플리케이션을
 
동시에 만들 수 있는 것이 가장 큰 특징이다.
 
따라서 하나의 코드를 제대로 잘 만들어 놓으면 위의 플랫폼 모두 하나의 코드로
 
동시에 만들 수 있다는 것이다.
 
그럼 다시 돌아와서,
 
모바일 보안 점검에서 가장 기본이 되는 작업은 애플리케이션과 서버 사이의
 
HTTPS 트래픽을 평문으로 살펴보는 것이다.
 
하지만, Flutter로 작성된 앱은 이 두 가지 방법 모두 통하지 않는다. 
 
그 이유는 크게 2가지가 있다.
 
Flutter 자체가 시스템에서 설정한 프록시를 무시하기 때문이고
 
Flutter는 OS의 신뢰 저장소를 쓰지 않고 자체 CA 목록을 정적으로 내장하기 때문에
 
일반적으로는 Burp로 바로 패킷을 캡처할 수 없다.
 
일단 애플리케이션은 사용자가 WIFI 설정에서 프록시로 IP:PORT로 지정하면
 
안드로이드 OS는 그 값을 자바 프레임워크 계층에 아래와 같이 조회가 가능하도록 설정한다.

시스템 프로퍼티 http.proxyHost / http.proxyPort
java.net.ProxySelector.getDefault() 가 이 값으로 채워짐
ConnectivityManager.getDefaultProxy() 로도 조회 가능

 
자바단이기 때문에 이 설정은 커널이 패킷을 강제적으로 프록시로 보내는 것이 아니다.
 
자바단은 클라이언트단 위쪽 레벨이기 때문이다.
 
따라서 단지 "프록시 설정이 이렇게 되어 있다"라고 알려줄 뿐이고,
 
실제로는 그 프록시로 요청을 보낼지는 각 HTTP/HTTPS 라이브러리의 코드가 결정한다.
 

  [일반 앱]
  
  Retrofit / OkHttp / HttpURLConnection / ....
        │  (내부적으로)
        ▼
  ProxySelector.getDefault()  ← 안드로이드가 시스템 프록시 값으로 채워둠
        │  "프록시 = IP:PROT 이네"
        ▼
  그 프록시로 연결하고  CONNECT api.example.com:443  을 전송
        │
        ▼
  Burp 도착

 
즉 일반 애플리케이션이 프록시 설정으로 쉽게 패킷이 잡히는 이유는
 
OS가 강제해서가 아니라, 그 앱이 쓰는 HTTP 라이브러리가 "시스템 프록시를 조회하는 코드"를
 
내장하고 있기 때문이다.
 
그럼 왜 Flutter는 왜 그 코드를 실행하지 않는가????
 
Flutter는 안드로이드 자바 계층을 아예 거치지 않는다. 
 
Dart 코드에서 package:http를 쓰든 package:dio 를 쓰든,
 
무조건 dart:io의 HttpClient로 모이고, 이것은 Flutter 엔진(C++) 안에서 동작한다.
 
여기서 dart:io의 HttpClient에 일반적인 애플리케이션에서 조회한 시스템 프록시를 읽는 코드가 없으므로, 
 
위에서 어떤 패키지를 써도 프록시를 안 탄다.
 
즉 시스템 프록시가 "무시" 되는 것이 아니라 사실 애초에 조회 대상도 아니고 조회할 기능이 없는 것이다.
 

 [Flutter 앱]
  Dart 코드 (dio / http)
        │
        ▼
  dart:io  HttpClient.findProxy   ← 기본값 "DIRECT"
        │  (프록시 조회 코드가 아예 없음)
        ▼
  DNS로 얻은 진짜 서버 IP 로 곧장 connect()
        │
        ▼
  Burp 안 거침 (진짜 서버로 바로 감)

 
그럼 Flutter는 왜 이렇게 설계되었을까??
 
바로 원소스로 크로스 플랫폼에 설치하기 위해서이다.
 
시스템 프록시는 안드로이드 자바 프레임워크(java.net ,ProxySelector, ConnectivityManager, ....)이다.
 
Flutter는 크로스 플랫폼과 성능을 위해 이 자바 세계를 일부러 우회하고 자체 I/O 스택(Dart VM + 엔진)으로
 
동작한다.
 
그래서 안드로이드에만 있는 프록시 배관과 연결되는 다리(bridge)가 처음부터 없었던 것이다.
 
이제 또 2번째 문제가 있다.
 
Flutter는 시스템 CA 인증서를 신뢰하지 않는다.
 
안드로이드에서는 신뢰 저장소가 2개가 있다.
 
시스템 저장소와 사용자 저장소다.

안드로이드 7(API 24)+ 부터는 앱이 network_security_config로 명시하지 않는 한
 
사용자 CA를 기본 신뢰하지 않기 때문에 대부분
 
시스템 저장소로 우리가 흔히 아는 /system/etc/security/cacerts 경로에 인증서를 넣는 이유다.
 
이렇듯 자바 계열 애플리케이션의 TLS는 ART(자바 런타임)의 X509TrustManager 가 담당하며,
 
서버 인증서 체인을 검증한다.

[일반 앱]  

서버 인증서 → ART X509TrustManager 
			→ 안드로이드 시스템+사용자 CA 저장소와 대조 Burp CA를 사용자 저장소에 설치 
            		→ Burp가 서명한 가짜 인증서가 "신뢰됨" → 통과

 
그래서 SSL 피닝을 우회할 때 한 번씩 보이는 것이 X509TrustManager 이다.
 
어쨌든 안드로이드 저장소와 인증서를 검증하는 메소드를 조작/설정하는 선에서 해결된다. 
 
Flutter/Dart의 TLS는 libflutter.so 에 정적 링크된 BoringSSL 이 수행한다
 
그리고 이 BoringSSL이 신뢰하는 루트 CA 목록은
 
안드로이드 시스템/사용자 저장소가 아니라,
 
Dart SDK/Flutter 엔진에 컴파일 타임에 박아 넣은 Mozilla NSS 루트 CA 번들이다.
 

[Flutter 앱]  

서버 인증서 → libflutter.so 내부 BoringSSL
              → libflutter.so 에 *내장된* Mozilla 루트 목록과 대조 Burp CA를 안드로이드 저장소에 설치
              		→ Flutter는 그 저장소를 *읽지 않음* → 무의미
  
 Burp가 서명한 인증서 = 내장 루트에 없는 CA → 체인 검증 실패 → 반환값 0 → 핸드셰이크 중단

 
즉 Burp CA를 안드로이드에 아무리 잘 설치해도 소용없다. 
 
Flutter의 신뢰 목록은 애플리케이션 바이너리 안에 있고,
 
그 목록은 OS 저장소와 완전히 분리되어 있기 때문이다.
 
따라서 일반 애플리케이션에서 패킷을 잡던 방법이 먹히지 않았던 것이다.
 

 
그래서 Flutter로 만들어진 애플리케이션의 패킷을 분석하기 위해서는 libflutter.so 파일을 분석하여
 
내부 인증서 검증 함수를 직접 우회하는 수밖에 없다.
 
그렇게 분석을 마치면 아래와 같이 Flutter로 만들어진 애플리케이션도
 
Burp로 패킷을 캡처할 수 있다.
 

이번에는 코레일 매크로를 만들어보았다.

버스 말고도 기차로도 많이 이동하기 때문에 고속버스 매크로를 만드는 김에 코레일(기차)도 분석을 해보았다.

그리고 분석을 하면서

"아 이왕 만드는 김에 고속 버스 + 코레일을 합쳐서 하나의 애플리케이션을 만들어서 편하게 쓰자"

해서 나만의 취소표 구하는 매크로 앱인 "표의 민족" 애플리케이션을 만들었다.

처음 시작하면 다음과 같다.

고속버스는 이전 포스팅에서 봤으니 이번에는 기차 (코레일)에 대해서 살펴보자.

버스 예매와 크게 다르지 않다.

먼저 이것도 당연히 로그인 부터 먼저 해준다.

그 후 아래와 같이 결제할 카드를 등록해 준다.

결제할 카드를 등록했다면 아래와 같이 출발지와 도착지를 선택한 후 가는 날을 선택해 준다.

위의 그럼처럼 다 매진이다.

이유는 10월 8일이 휴일 전날이기 때문에 이렇게 차표가 매진인 것이다.

여기서 내가 취소표를 구하고 싶은 기차를 선택하여 추가한다.

그냥 나 혼자 사용하기 위해서 최대 2개로 제한하였다.

이렇게 설정하고 시작버튼을 눌러준다.

그럼 아래와 같이 자동 예매가 실행되게 된다.

그럼 아래처럼 취소표가 잡힌다.

아래의 그림은 하나의 예시로 그냥 빈자리가 있는 것을 설정한 모습이다.

서울에 사는 사람은 명절에 고향에 내려가기가 너무 힘들다.

이번에도 곧 있을 추석을 맞이하여 기차표를 구하기 위해서 무려 5시 30분에 일어나서 

회사 컴퓨터로 7시가 되자마자 바로 예매 버튼을 클릭했다.

하지만...

하.. 진짜 말이 안된다.

이렇게 된 이상 취소표라도 구해야 한다.

따라서, 일단 기차 KTX 매크로를 만들기 전

버스라도 일단 구해야 하지 하는 마음에 고속버스 예매 애플리케이션인

고속버스 티머니 애플리케이션을 빠르게 분석하였다.

분석한 후 다음과 같이 나만의 취소표 매크로를 만들었다.

먼저 로그인 부분이다.

로그인을 바로 진행해 주자.

그다음 결제할 카드를 등록해 준다.

만약 다른 카드를 추가하고 싶다면 + 새 카드 추가를 클릭해서 아래와 같이 카드를 등록해 주면 된다.

이렇게 카드를 등록해 주었다면, 이제 출발지와 도착지

그리고 출발할 시간을 입력하자.

위와 같이 왕복으로 설정을 하면 한 번에 결제를 진행할 수 있다.

그리고 자리를 선택을 할 수 있게 설정했다.

나는 항상 버스를 탈 때 우등, 창가 혹은 1인석에만 앉기 때문에 해당 설정이 꼭 필요했다.

그다음 이렇게 마지막으로 확인한 후 시작을 눌러서 취소표를 구해준다.

최근에 게임 애플리케이션을 분석하다 보니 게임 광고가 엄청나게 뜬다.

그중에서 또 하나 분석을 안 해본 게임 애플리케이션이 있어서 분석해보았다.

우르르 용병단이라는 게임인데, 해당 게임은 LIAPP으로 보호되어 있다.

LIAPP은 앞에서 많이 분석을 했었다.

당근, 블라인드 등 여러 번 LIAPP이 적용된 애플리케이션을 분석을 해보았지만

게임에 적용되어 있는 경우는 처음이라 분석을 진행해 보았다.

역시나 LIAPP 알림 창이 뜬다.

any-hacking-tools라는 알림이 발생하였다.

이것은 앞 서 분석한 내용(당근, 블라인드 애플리케이션)을 토대로 우회하면 다음과 같은 알림 창을 볼 수 있다.

LIAPP을 분석하면서 처음 보는 알림이었다.

Android Republic이란 조금만 검색해 보면 알겠지만 모드(MOD) 애플리케이션을 판매 및 공유하는 사이트이다.

모딩된 애플리케이션을 다운로드하지도 않았는데도, 저런 알림이 발생한다.

따라서, 게임에 적용된 LIAPP의 so 파일이 뭔지 살펴본 결과,

libxxwfvxwt.so이라는 so 파일이라는 것을 발견하였다.

그래서 바로, RainDropELF로 아래와 같이 덤프 하여 IDA로 디컴파일 한 결과, 에러 없이 잘 덤프가 되었다.

그 후 이제는 게임 애플리케이션에서는 dump.cs가 중요하다.

이전에는 libil2cpp.so와 global-metadata.dat를 덤프를 해야 했는데 이렇게 하기 너무 귀찮았다.

따라서, RainDropELF를 업데이트하여 그냥 바로 아래와 같이 dump.cs가 추출되게 만들었다.

덤프한 dump.cs를 열어보면 덤프가 잘되었다.

해당 dump.cs를 분석한 후 캐릭터의 속도를 아래와 같이 후킹 해보았다.

아래는 정상적으로 캐릭터가 정상적으로 움직였을 때의 속도이다.

하지만 아래는 속도를 모딩 했을 때의 모습이다.

분석용으로 진행한것이라 튜토리얼에서만 진행을 하였고 더 이상은 진행하지 않았다.

운빨존많겜 게임을 분석한 이유에 또 게임 몇 번 검색했다고 알고리즘에 여러 게임이 뜬다.

그 중 드래곤 슬레이어 키우기이라는 게임 애플리케이션도 광고로 나오길래 이것도 분석을 진행해 보았다.

이것도 역시 게임을 실행하면 아래와 같이 탐지 로직에 의해 알림이 발생한다.

해당 문구는 DoveRunner에서 만든 모바일 보안 솔루션에 의해 탐지된 로직이다.

DoveRunner는 이전의 잉카엔트웍스라는 회사의 AppSealing이라는 브랜드이다.

당시 이 솔루션은 매우 친숙한(?) 존재였는데,

그 이유는 보안 모듈의 이름이 항상 일정했기 때문이다.

libcovault-appsec.so

기존의 AppSealing은 위와 같이 고정된 파일명을 사용해 왔다. 

이에 잉카엔트웍스는 새로운 세대의 보안 엔진인 DoveRunner를 런칭하며 전략을 수정했다. 

일단 RainDropELF로 libil2cpp.so와 global-metadata.dat를 덤프 한다.

그런 다음 dump.cs를 추출한다.

이 작업은 이전의 38.운빨존많겜 게임분석을 참고하면 된다.

똑같이 작업을 했다.

dump.cs는 아래와 같이 잘 나온다.

그렇게 dump.cs를 분석하다 보면 몬스터를 잡고 난 후 획득 하는 골드를 원하는 만큼 증가시킬 수 있다.

일단 정상적인 플레이를 할 때를 보면 다음과 같다.

이렇게 랜덤 하게 83, 85, 91 ... 이런 식으로 몬스터를 잡을 때마다 획득하는 골드량이 다르다.

하지만 dump.cs를 분석한 결과 이 획득한 골드량을 원하는 만큼 아래와 같이 증가시킬 수 있다.

이렇게 83원이 아니라 7,660,093원씩 획득할 수 있다.

공격력 레벨도 110으로 되어있지만 계속해서 거의 무한대로 증가시킬 수 있다.

뭐 이 게임을 안 할 거라서 더 이상은 진행하지는 않았다.

오랜만에 뭔가에 푹 빠져서 분석하고 싶은 마음이 들었다.

"뭐를 한번 해볼까" 하고 생각해봤다.

그러다 떠오른 게, 예전에 했을 땐 제일 힘들었는데 시간이 지나서 돌아보니 제일 재미있고 흥미로웠던 일

게임 모드앱을 분석하는 일이었다.

그래서 이번엔 오랜만에 게임 앱을 한번 분석해보기로 했다.

대상은 운빨존많겜

하도 광고가 많이 나와서 골랐다.

다른 이유는 없다.

먼저 스토어에서 게임을 다운로드 받았다. 

받았을 때 앱 버전은 2.0.2였다.

분석을 하려면 먼저 APK 파일을 추출해야 한다.

방법은 두 가지인데, 아래와 같이 검색해서 APK 자체를 받거나

스토어에서 설치한 앱을 아래와 같이 PC로 직접 추출하면 된다.

나는 후자로 했다.

해당 게임은 APKS(split APK) 형태라서, 추출하면 아래처럼 여러 개로 쪼개진 APK가 나온다.

본격적인 분석에 앞서, 이 게임이 어떻게 만들어졌는지부터 봐야 한다. 

그러려면 라이브러리를 살펴보면 된다.

split_config.arm64_v8a.apk의 lib 폴더를 열어보면 libil2cpp.so 파일이 보인다.

이게 보이면 C#으로 만든 Unity 게임이라는 뜻이다.

Unity는 C#으로 게임 로직을 짜는데, 크게 두 갈래다.

Mono 방식

C# 코드를 .NET IL(중간 언어)로 컴파일한 뒤 런타임에서 해석/JIT 실행한다.

이 경우 게임 로직이 Assembly-CSharp.dll 같은 DLL에 들어가서

거의 원본 수준의 C# 코드를 복원할 수 있다.

즉 분석·변조 난이도가 꽤 낮다.

IL2CPP(IL To C++) 방식

C# → IL → C++로 변환 → 네이티브 머신코드로 AOT 컴파일한다.

모든 게임 로직이 네이티브 바이너리로 들어가는데, 안드로이드에선 그게 바로 libil2cpp.so다.

iOS에선 실행 바이너리 자체에  통합된다.

IL2CPP의 핵심은 메타데이터가 따로 분리된다는 점이다.

메서드 이름·클래스 구조 같은 정보가 global-metadata.dat에 담긴다.

보통 assets/bin/Data/Managed/Metadata/에 위치한다.

그래서 IL2CPP 게임은 libil2cpp.so +  global-metadata.dat 둘을 같이 봐야 의미 있는 분석이 된다.

요즘 상용 모바일 게임은 대부분 이쪽이고, 가끔 Unreal으로 작성된 게임이 존재한다.

그리고 역시나 분석을 막으려고 보안 솔루션(난독화·메타데이터 암호화)까지 되어있는 경우가 많다.

그리고 이 게임이 딱 그랬다.

먼저 APK 안에 있는 libil2cpp.so와 global-metadata.dat를 그대로 꺼내서

Il2CppDumper dump.cs를 뽑아보기로 했다.

libil2cpp.so를 고르고, 이어서 global-metadata.dat를 선택해주니 다음과 같이

This file may be protected. 라는 에러가 떴다. 

즉 이 앱엔 모바일 보안 솔루션이 적용돼서 이 데이터들을 보호하고 있다는 뜻이다.

그러니 원본의 libil2cpp.so와 global-metadata.dat를 구해야만 게임 로직을 볼 수 있다.

이때 필요한 게 Frida다.

모바일 분석은 대부분 Frida로 한다.

그런데 두 파일을 동적으로 뽑으려고 Frida를 실행하면 바로 종료된다. 

전형적인 Frida 탐지다.

이걸 우회하려면, 먼저 이 앱이 어떤 보안 솔루션을 쓰는지부터 알아야 한다.

그래서 습관적으로 패킷을 봤다.

제일 먼저 발생하는 패킷이 http://adam.cdn.toastoven.net 이건 예전에도 분석했던 

NHN Cloud의 AppGuard라는 모바일 보안 솔루션이다.

예전에 한 번 다뤄봤던 덕분에, libloader.so가 AppGuard의 핵심 so 파일이라는 걸 바로 알 수 있었다.

그래서 libil2cpp.so가 어떻게 보호되는지 보려고 libloader.so를 IDA로 디컴파일했더니 역시 에러가 났다. 

libloader.so도 보호(패킹)돼 있다는 뜻이다

제대로 보려면 libloader.so도 원본을 구해야 한다. 

그래서 RainDropELF로 메모리에서 덤프했다.

덤프한 파일을 APK에 있던 원본 so와 비교해보면, 심볼 개수가 거의 6배 이상 차이가 난다.

RainDropELF로 덤프한 libloader.so를 분석한 결과, Frida 탐지 로직을 파악할 수 있었다.

그리고 이걸 우회해서, 아래처럼 open 함수를 후킹하는 간단한 Frida 스크립트를 무사히 실행할 수 있었다. 

사실 Frida 탐지·우회 기법에 대해선 따로 자세히 분석한 글을 올리고 싶은데,

여러 가지 이유로 자세한 분석 내용은 생략한다.

이제 원래 목적인 게임을 분석하려면 원본 libil2cpp.so와 global-metadata.dat가 필요하다.

이것도 똑같이 RainDropELF로  덤프했다

그러면 위의 그림처럼 덤프 파일 2개가 나온다.

이걸 다시 Il2CppDumper에 넣어주면

이번엔 통과해서 dump.cs가 나온다. 

dump.cs가 뭐냐면,

Il2CppDumper가 libil2cpp.so + global-metadata.dat를 교차 파싱해서,

게임 전체 코드 구조를 C# 의사코드(pseudo-code) 형태로 복원한 텍스트 파일이라고 보면 된다.

메서드 이름·클래스·필드 같은 메타데이터는 global-metadata.dat에

실제 실행 코드는 libil2cpp.so에 들어있는데

이 둘을 합쳐 "원래 C# 코드가 어떤 구조였는지"를 재구성해준다.

그래서 C#으로 개발된 게임 애플리케이션을 분석하기 위해서는 dump.cs 파일 확보가 필수이다.

이제, dump.cs가 나왔다는 건, 이제 게임 함수들의 이름과 오프셋이 손에 들어왔다는 뜻이다.

여기서부터는 dump.cs를 보고 원하는 함수를 골라 Frida로 후킹하면,

공격자 입장에서 게임 안에서 하고 싶은 걸 거의 마음대로 할 수 있게 된다.

예를 들어 인게임 재화 같은 값을 다루는 함수를 찾아 후킹해주면,

원래대로라면 찔끔찔끔 모아야 할 값을 한순간에 바꿔버릴 수 있다.

아래를 보자.

이건 그냥 게임을 실행했을 때의 모습이고, 

이건 dump.cs로 분석한 내용을 Frida로 후킹했을 때의 모습이다.

이렇게 공격자 입장에서 게임 안에서 하고 싶은 걸 거의 마음대로 할 수 있게 된다.

정리하면 이번 분석의 흐름은 이랬다.

APK 추출 → IL2CPP 확인 → 그냥 덤프했더니 "protected" → Frida도 탐지돼서 즉시 종료 → 

패킷으로 AppGuard 식별 → libloader.so까지 보호돼 있어서 RainDropELF로 원본 덤프 → Frida 탐지 우회 → 

원본 libil2cpp.so + global-metadata.dat 덤프 → dump.cs → 후킹으로 게임 값 변조.

뭐 분석에는 순서는 없지만, 앞으로 게임 애플리케이션을 분석하시는분이 계시다면 참고하면 좋을것 같아.

분석 흐름을 위와 같이 정리해봤다.

웹 모의해킹을 진행하다 보면 웹 페이지와 클라이언트 간에 오가는 웹 패킷을 캡처하고 분석하는 과정이 필수적이다.
 
취약점을 찾아내기 위해서는 이 패킷들을 가로채어 파라미터를 변조하거나 로직을 우회해 봐야 한다.
 
이를 위해 Fiddler(피들러)나 Burp Suite(버프 스위트)와 같은 프록시(Proxy) 도구를 자연스럽게 사용한다.
 
따라서 Fiddler나 Burp Suite를 켜고 프록시 세팅을 마친 뒤 점검할 웹 페이지에 접속하는 순간,
 
모니터 우측 하단에 익숙하고도 불길한 아이콘이 나타난다.

 
국내 금융 및 공공기관 서비스를 이용하기 위해 필수적으로 설치해야 하는 보안 프로그램,
 
바로 AhnLab Safe Transaction(AST)이다.
 
대표적으로 아래와 같이 한국투자증권과 KB국민은행 홈페이지에 접속하면
 
아래와 같이 AST가 실행되는것을 볼 수 있다.
 

 
이 녀석이 보이면 일단 하던 행동을 멈추고 Burp나 Fiddler가 종료가 되는지 계속 본다.
 
그러다가 아래의 알림창과 종료가 된다면?

 
깊은 한숨과 함께 다른 방법이 있는지 우회하는 방법이 있는지 찾아 본다.
 
일반 사용자들 사이에서도 AST는 원성이 자자하다.
 
은행 업무를 보려고 잠깐 설치했을 뿐인데,
 
웹 브라우저를 닫아도 백그라운드에 좀비처럼 살아남아 PC 리소스를 야금야금 갉아먹는다.
 
퇴근 후 고사양 게임이나 무거운 툴을 돌릴 때 컴퓨터가 알 수 없는 이유로 버벅거려 작업 관리자를 열어보면,
 
어김없이 AST 관련 프로세스가 CPU와 램을 점유하고 있다.
 
오죽하면 인터넷에 'AST 강제 종료', 'Ahnlab Safe Transaction 삭제 방법'
 
같은 글들이 항상 검색어 상단에 있을까.
 
그런데 일반 사용자들만 불편한 게 아니다.
 
모의해커나 보안 분석가 입장에서는 분석의 시작조차 막아버리는 벽이다.
 
앞서 말한 프록시(Proxy) 툴을 이용한 패킷 조작은 물론이고,
 
디버거(Debugger) 부착, 메모리 접근 같은 동적 분석 과정은 보안 점검에 있어 필수 요소다.
 
하지만 AST는 안티 디버깅(Anti-Debugging), 프로세스 보호, 후킹 차단(Anti-Hooking) 등
 
다양한 보안 기법이 PC 최하단(커널 및 드라이버 레벨)에서 아주 치밀하게 적용되어 있다.
 
분석을 위해 x64dbg 같은 디버거를 붙이려 하거나,
 
분석 도구를 실행하는 순간 냅다 "보안 위협이 감지되었습니다"를 띄우며 프로세스를 가차 없이 죽여버린다.
 
그래서 이번 글에서는 업무나 개인 연구 목적으로  AST를 분석해 보고 이를 어떻게 우회할 수 있는지 해봤다.
 

자세한 내용은 공개하기가 어렵지만, 아래의 Python 코드를 이용해서 AST를 무력화 및 우회를 하였다.

 
그 후 다시 AST를 실행하는 웹 사이트에 접속한 후 Burp를 실행하면 잘 실행된다.
 

명절이나 주말마다 KTX, SRT 표 구하는 건 그야말로 전쟁이다.

컴퓨터 앞에 앉아 시계를 보며  '새로고침'을 누르는 동안,

황금 시간대 표는 단 1초 만에 매진된다.

이유는 간단하다.

수십, 수백 번의 클릭을 0.1초 만에 대신해 주는 '매크로(Macro)' 프로그램 때문이다.

최근 이 매크로는 단순한 '개인의 꼼수'를 넘어 심각한 사회적 범죄이자 문제로 대두되고 있다.

매크로 암표, 단순 새치기가 아닌 '범죄'다

과거에는 매크로로 표를 구해서 중고나라나 당근마켓에 웃돈(프리미엄)을 얹어 파는 행위가

단순 경범죄(20만 원 이하 벌금) 정도로 취급받았다.

하지만 상황이 심각해지자 철도운영사와 경찰청이 칼을 빼들었다.

• 6,400만 건의 불법 접속 시도 (연합뉴스, 2025.02.20): SR(수서고속철도)은 설 승차권 예매 기간에 불법 매크로를 돌린 9명을 경찰에 수사 의뢰했다. 이 중 한 명은 혼자서 무려 3,100만 건의 접속을 시도하며 서버를 마비시켰다.

  

• 매크로 조직적 이용자 검찰 송치 (노컷뉴스, 2025.10.03): 경찰청은 매크로 프로그램을 이용해 명절 기차표를 싹쓸이한 피의자 6명을 불구속 송치했다.

몇 만 원 치킨값 벌어보려다 전과자가 되고 벌금을 물어내야 할 수도 있다는 뜻이다.

그렇다면 이같은 매크로 프로그램은 도대체 얼마나 대단한 고도의 기술일까?

결론부터 말하자면, 크게 어렵지 않다.

조금만 분석할 수 있는 능력만 있으면 누구나 쉽게 만들 수 있는 난이도이다.

크게 매크로 로직은 정말 허무할 정도로 단순하다.

1. 사이트에 접속해서 로그인을 한다.
2. 출발역, 도착역, 시간을 설정한다.
3. '조회하기' 버튼을 기계처럼 계속 누른다.
4. 화면에 '예약하기' (빈자리) 이미지가 뜨면 0.001초의 망설임도 없이 클릭한다.

이게 끝이다.

사람이 마우스를 쥐고 눈으로 화면이 바뀐 걸 확인한 뒤 클릭하는 반응속도는 아무리 빨라도 0.2~0.3초다.

하지만 컴퓨터(매크로)는 코드가 실행되는 즉시 누른다.

애초에 인간이 이길 수 없는 싸움인 것이다.

위 코드처럼 만드는 것 자체는 너무나 쉽다.

구글링 몇 번이면 GitHub에 널려 있는 게 기차 예매 매크로 소스코드이다.

하지만 Github나 공유되고 있는 소스코드는 예전 코드이기 때문에 대부분 동작하지 않기 때문에

직접 분석해 분석한 내용으로 아래의 예매 웹 사이트로 만들어 보았다.

이처럼 쉽게 만들수가 있었다.

예매가 된다면 내 폰으로 알림을 오게 만들 수도 있고, 혹은, 웹 사이트가 아닌 모바일 앱으로 만든다면?

그냥 일하면서, 혹은 자면서 설정만 해놓고 예매가 될때까지 기다리면 되는것이다.

약 거의 2년전에 당근에 적용된 LIAPP 솔루션을 분석하고 우회했던 글을 작성했었다.(참고)

이번에는 직장인들의 필수 애플리케이션인 블라인드(Blind)를 한번 살펴보았다.

살짝 살펴보니 블라인드도 당근과 똑같이 LIAPP이라는 모바일 애플리케이션 보안 솔루션을 사용하고 있었다.

그런데 막상 테스트 단말기에서 분석을 시작해 보니... 당근보다는 조금 더 빡센(?) 느낌이었다.

원래 테스트 환경에 처음 설치하고 애플리케이션 을 실행하면, 대부분 잘 실행이 되는데

블라인드는 아래와 같이 냅다 "디버거 탐지 / any-hacking-tools " 라는 탐지 문구가 발생하였다.

뭐 딱히 해킹 툴이라고 부를 만한 걸 헤비하게 설치한 건 없었다.

기껏해야 기본적으로 세팅해 두는 분석용 환경 정도다.

그런데 다짜고짜 저런 문구가 발생하면서 튕기길래, "어? 이건 또 뭐지?" 하고 호기심이 생겨

본격적으로 분석을 시작했다.

생각보다 방어 로직이 촘촘하게 엮여 있었는데

분석 결과, 지금까지 모바일 애플리케이션을 분석하면서 처음 본 탐지 로직이 존재하였다.

진짜 난생 처음보는 탐지 로직이었다.

원인과 로직을 파악했으니 해결은 크게 어렵지 않았다.

그렇게 짜증나고 신기하던 any-hacking-tools 팝업이 사라지고,

아주 깔끔하게 블라인드 애플리케이션의 초기 로그인 화면까지 진입하는 데 성공했다.

같은 LIAPP 솔루션을 사용하더라도, 당근 애플리케이션을 분석할 때와

블라인드 애플리케이션을 분석할 때의 난이도나 탐지 민감도가 확실히 달랐다.

아마, 블라인드 애플리케이션 특성상 약간 보안에 신경을 쓴것 같다?? 라는 느낌을 받았다.

애플리케이션 서비스의 성격(익명성이 극도로 중요한 블라인드)에 따라 개발사에서

보안 솔루션의 탐지 옵션을 훨씬 더 타이트하게(빡세게) 설정해 두었거나,

더 상위 버전의 모듈을 적용한 것으로 보인다.

새로운 탐지 로직을 구경할 수 있어서 꽤 흥미로운 분석이었다.

모바일 애플리케이션을 분석하다 보면 종종 이런 생각이 들 때가 있다.

“이거 내가 애플리케이션을 분석하는 건지, 모바일 보안 솔루션을 분석하는 건지 모르겠네…”

최근 출시되는 애플리케이션들은 대부분 모바일 보안 솔루션이 기본으로 탑재되어 있다.

모바일 보안 솔루션들은 분석이나 해킹 시도를 막기 위해 치밀하게 설계되어 있다.

덕분에 보안 업계에서 일하는 우리 같은 사람들은 애플리케이션 본연의 로직을 분석하는 것보다

오히려 모바일 보안 솔루션을 우회하는 데 더 많은 시간을 쏟고 있는 것이 현실이다.

모의해커나 보안 분석가 입장에서 애플리케이션을 깊이 있게 점검하려면

기본적으로 루팅(Rooting) 된 단말기와 Frida 같은 동적 분석 도구가 필수적이다.

하지만, 애플리케이션 개발사들과 보안 솔루션 업체들도 이를 너무나 잘 알고 있다.

과거 2024년, [14. 모바일 솔루션 우회 (토스)] 포스팅을 통해 보안 솔루션을 직접적으로 건드리지 않고도

애플리케이션 분석이 가능한 사례를 소개했었다.

당시 금융권 최고 수준의 보안을 자랑하는 토스(Toss)를 대상으로 성공적인 테스트를 마쳤고,

서비스 점검 본연의 업무에 집중할 수 있는 발판을 마련했었다.

시간이 흘러 2026년 현재,

모바일 보안 솔루션들은 2년 전과는 비교할 수 없을 정도로 진화했다.

단순히 특정 파일(Su 바이너리 등)의 존재 여부나 패키지명을 검사하던 수준을 넘어섰다.

무결성 검증, 메모리 변조에 대한 실시간 감시, 탐지 로직의 난독화,

그리고 Frida와 같은 후킹 툴의 탐지 기법들이 대거 적용되었다.

잘 작동하던 나의 분석 환경도 2026년 최신 업데이트를 거친 애플리케이션들 앞에서는

다시 "비정상적인 환경이 감지되었습니다"라는 알림을 다시 볼수 있었다.

이것이 업데이트된 토스의 모바일 보안 솔루션을 다시 들여다보게 된 계기이다.

또 다시 솔루션과 직접 맞붙어 시간을 낭비할 수는 없었다.

결과는 어땠을까?

일반적으로 루팅 된 단말기에서 2026년 최신 버전의 토스를 실행하면

여전히 아래와 같이 경고 알림이 뜨면서 즉시 종료된다.

하지만 2026년의 강화된 보안 로직에 맞춰 새롭게 업데이트한 환경에서 실행한 결과,

루팅된 단말기임에도 불구하고 토스 애플리케이션이 정상적으로 실행되는 것을 확인할 수 있었다.

단순히 루팅된 환경에서 애플리케이션이 실행되는 것을 넘어,

복잡하고 강력해진 탐지 로직에도 아래와 같이,

Frida 역시 정상적으로 실행되어 원활한 후킹 작업을 통해 분석이 가능한 것을 확인했다.

Friad를 실행할때 Spwan 방식이든, Attach 방식이든 입맛에 맞게 실행하면 된다.

아래는 Attach 방식으로 붙었을때의 모습을 보여준다.

또한, 아래와 같이 패킷 캡쳐도 볼 수 있다.

이렇게 암호화 된 값도 평문으로 볼 수 있다.

해당 프로젝트는 앞으로도 계속될 것이고,

국내 애플리케이션뿐 아니라 해외 애플리케이션도 동일한 환경을 적용해 보며

분석 환경을 더욱 정교하게 고도화할 예정이다.

궁극적인 목표는 보안 솔루션을 무력화하는 것 자체가 아니다.

분석에 방해되는 요소를 최소화하여

진짜 점검해야 할 '서비스와 애플리케이션의 취약점'에 더 집중할 수 있는 안정적이고 효율적인 도구를 만드는 것이다.

최근 YES24 eBook DRM 구조를 분석하면서 전자책(eBook) 플랫폼의 보안 메커니즘에 대해

살펴볼 기회가 있었다.

DRM이 콘텐츠 자체를 암호화하여 직접적으로 보호한다면,

이러한 DRM 로직이 동작하는 '애플리케이션 자체'를 보호하는 첫 번째 관문이 바로 모바일 보안 솔루션이다.

DRM 복호화 원리나 내부 비즈니스 로직을 분석하려면 필수적으로

애플리케이션에 적용된 보안 솔루션을 우회해야만 분석을 진행할 수 있다.

그래서 이번에는 국내 대표적인 독서 플랫폼인 밀리의 서재를 타깃으로 삼아,

애플리케이션에 적용된 보안 솔루션을 분석해 보았다.

확인 결과, 밀리의 서재에는 NHN AppGuard가 적용되어 있었다.

본격적인 분석을 위해 현재 기준으로 최신 Frida 버전인 17.7.3으로 테스트를 해보았다.

역시나 모바일 보안 솔루션답게 Frida를 즉시 탐지해 애플리케이션이 강제 종료되었다.

NHN AppGuard의 핵심 방어 로직 중 하나는 강력한 안티 디버깅과 네이티브 라이브러리(.so) 보호이다. 

이를 분석하기 위해서는 NHN AppGuard에서 개발한 모바일 보안 솔루션의 .so 파일을 추출해야 한다.

따라서 APK 파일을 다운로드하고. so 파일을 살펴보았다.

lib 폴더에 존재하는 so 파일 중 libloader.so가 NHN AppGuard에서 개발한 모바일 보안 솔루션의 라이브러리다.

따라서 분석을 진행하기 위해 IDA Pro를 활용하여 디컴파일을 진행하였다.

IDA로 libloader.so 파일을 디컴파일 하니 위의 그림처럼 에러가 발생하였다.

따라서, 동적으로 libloader.so 파일을 덤프 해야 했다.

왼쪽 그림이 그냥 so 파일을 디컴파일한 모습이고, 오른쪽이 동적으로 덤프 한 so 파일이다.

함수의 심볼의 차이가 거의 9배나 차이가 난다.

동적으로 덤프 한 so 파일을 하나하나 뜯어보며,

AppGuard가 어느 시점에 실행한 디바이스의 환경을 검증하고 Frida 탐지 로직이 실행되는지 분석을 시작했다.

분석 결과, 크게 루트 권한 탐지, 무결성 검증, Proxt 탐지 그리고 동적 분석 도구의 Frida 탐지 등

여러 단계의 탐지 로직이 엄청나게 얽혀 있는 것을 확인할 수 있었다.

결과적으로 아래와 같이 NHN AppGuard의 탐지 로직을 우회하고,

밀리의 서재 애플리케이션에 성공적으로 Frida를 연결할 수 있었다.

하지만 더 분석을 진행하고 싶었지만 밀리의 서재의 DRM을 분석하기 위해서는 구독을 해야 한다.

계정 공유 가능하신 분 주시면 감사하겠습니다

계정을 공유받을 수 있다면 밀리의 서재의 DRM도 분석을 진행해봐야겠다.

※ 주의 본 포스팅은 보안 연구 및 모의해킹 역량 강화를 위한 학습 목적으로만 작성되었습니다. 실제 서비스에 대한 무단 우회 배포, 저작권 침해 및 악의적인 해킹 시도는 명백한 불법이며 법적 처벌을 받을 수 있습니다. 기술적 원리 이해를 위한 참고 자료로만 활용해 주시기 바랍니다.

예전에 블로그에 13. 휴대폰 번호로 이름과 주소 찾기 라는 글을 쓴 적이 있다.

그 글에서 소개한 내용은 간단하다.

• 휴대폰 번호 하나만 알고 있어도
• 그 사람의 이름과 집 주소까지 바로 조회되는 구조가 실제 서비스에 존재했고
• 이걸 5년 전(대략 2020년도)에 발견해서 제보까지 했지만, 지금까지도 조치가 되지 않았다.

당시 글에서도 적었듯이, 이름·주소 정도는 "별 거 아닌 정보"로 생각할 수 있다.

하지만 지금 쿠팡, 넷마블에서 해킹된 이름과 주소가 유출 됬는데 왜 이렇게 난리인걸까?

조금만 상상해 보면:

• 피싱·보이스피싱 시 실명+주소 기반 정교한 공격,
• 실제 집 주소를 노린 스토킹·침입 범죄,
• 스미싱과 스팸의 정확도 상승

지금 현재 쿠팡 개인저보 유출사고가 터지고 나서 계속 언급되는것이 바로 보이스피싱, 스미싱 피해 주의다.

이전에 발견된 취약점도 이번 쿠팡에서 개인정보가 유출된것처럼 이름, 집 주소까지 다 조회가 되는 취약점이다.

하지만 이전에 발견된 취약점은 "휴대폰 번호 하나"에서 시작될 수 있는 구조다.

사실 개인적으로 이게 더 위험하다고 생각한다.

휴대폰 번호? 그냥 무작위로 넣으면 그만이다.

또, 더 위험한 건 이게 어떤 최첨단 제로데이 해킹이 아니라는 점이다.

1. 옛날에 만들어 놓고 관리도 안 하는 레거시 시스템

2. 과도한 권한을 가진 조회 인터페이스

3. 접근 통제와 모니터링 부재가 합쳐진, 아주 전형적인 패턴이다.

그리고 몇 년이 지나, 이번 쿠팡과 넷마블에서 터진 대형 해킹 사고를 보면서

나는 똑같은 패턴을 다시 보고 있다는 느낌을 강하게 받았다.

이번 쿠팡 사건을 조금만 살펴보자.

최근 쿠팡에서는 3,370만 건대 규모의 고객 계정 정보가 유출되는 대형 사고가 발생했다.

핵심 포인트만 정리하면:

1. 인증 담당자에게 발급된 액세스 토큰 서명키가 있었다.
2. 이 서명키는 토큰의 진위를 검증하는 '도장' 역할을 한다.
   • 토큰이 일회용 출입증이라면,
   • 서명키는 그 출입증에 찍는 공인 도장에 가깝다.
3. 그런데 이 서명키를
   • 담당자가 퇴사한 뒤에도 갱신·폐기하지 않고 방치
   • 결과적으로 내부 인물이 이 키를 악용해 서버가 신뢰하는 토큰을 임의로 생성
   • 고객 마이페이지·주문 정보 등에 접근해 수천만 건의 정보를 탈취한 것으로 분석되고 있다.

여기서 중요한 건 "해커가 그 비싼 방화벽, 보안 솔루션 등을 뚫고 들어온 사건"이라기보다

"퇴사자에게 발급됐던 인증키를 회수·갱신하지 않은 조직 내부 관리 실패"에 가깝다는 점이다.

즉, 보안 솔루션이 약해서가 아니라, 기본적인 권한·키 관리 프로세스를 지키지 않은 문제다.

• 토큰 서명키의 유효 기간은 통상 5~10년 등 길게 잡기도 한다는 답변이 나왔지만
• 그건 어디까지나 적절한 로테이션·폐기 절차가 존재한다는 전제 하에서나 의미가 있다.

넷마블 해킹 사건을 보자.

넷마블 역시 최근 PC 게임 포털 해킹으로 인해 약 611만 명의 고객·임직원 정보가 유출된 사실을 공개했다.

여기서 눈여겨볼 부분은 유출된 데이터의 연도 범위다.

• 1차 발표:
  • 포털 회원·임직원 등 611만여 건의 정보 유출 공지.
• 2차 발표:
  • 추가로 8,048건의 개인정보 유출이 확인되었고,
  • 여기에는
    • 2003~2004년 고객센터 문의자 정보,
    • 2003~2006년 온라인 입사지원자 정보,
    • 2001~2005년 및 2011~2021년 B2B 사업 제안 담당자 정보,
    • 취업박람회 부스 방문자의 연락처 등이 포함되어 있었다.
    • 일부에는 주민등록번호와 같은 고유식별정보도 포함되어 있었다.

즉, 이건 단지 "한 번 사고 났다"의 문제가 아니라,

• 20년 가까이 된 과거 데이터가 여전히 삭제되지 않고, 접근 가능한 시스템 안에 살아 있었다라는 것이다.

이제 다시 예전에 쓴 취약점 글과 이어서 생각해보자.

• 레거시 구조
  • 오래전에 만들어진 것으로 보이는,
  • 휴대폰 번호 → 개인 실명·주소를 바로 조회할 수 있는 과도한 기능.
• 권한·인증 관리의 부재
  • 이 조회 기능에 접근하기 위한 인증·권한 통제가 사실상 부실하거나,
  • 특정 조건을 우회하면 누구나 조회 가능한 상태로 보였다.
• 데이터 최소화 원칙 위반
  • “서비스 제공에 정말 필요한 범위를 넘어선 정보 접근”이 가능했다.
• 제보 이후에도 수년째 미조치
  • 5년 전에 발견해서 제보까지 했는데, 지금 봐도 여전히 구조 자체가 유지되고 있는 것으로 보인다는 점

이 구조를 쿠팡·넷마블 해킹 사건에 그대로 대입해 보면 아래와 같이 겹친다.

• 쿠팡:
  • 퇴사자의 서명키를 회수·갱신하지 않고 방치
  • → 내부자가 악용할 수 있는 "디지털 만능 열쇠"가 그대로 남아 있었다.
• 넷마블:
  • 2000년대 초반부터 쌓인 고객센터/입사지원/행사 방문자 데이터가
  • 삭제·파기되지 않고 레거시 포털 내부에 누적되어 있었다.
• 내 사례:
  • 오래전 설계된 것으로 보이는 휴대폰 번호 기반 조회 시스템이
  • 제보 이후에도 여전히 수정·폐기되지 않고 살아 있는 상태.

세 사건 모두 “악의적인 초고도화된 해킹 기법”보다 "방치된 것들"이 문제의 뿌리였다.

• 권한을 부여할 땐 쉽게 주고,
• 회수·축소·폐기는 뒤로 밀린다.
• 데이터는 한 번 모으면 "혹시 나중에 쓸 수도 있으니까"라는 이유로 계속 쌓인다.

단순히 이번에 발생한 해킹 사건과 이전의 발견한 취약점의 회사를 비난하는것이 아니라

다시 한번 보안에 대해서 생각해보는 계기가 되었으면 하는 바램이다.

금융권 애플리케이션들을 집중적으로 분석하던 시기가 있었다.

그때만 해도 대부분의 애플리케이션은 루팅 우회 + SSL Pinning 우회만 해주면,

프록시를 통해 패킷 캡처가 무리 없이 가능했다.

그런데 유독 한 녀석만 끝까지 말을 안 듣는 애플리케이션이 있었다.

바로 카카오뱅크였다.

위의 방법처럼 늘 하던 대로 프록시를 설정하고, 카카오뱅크 애플리케이션을 실행해서 패킷을 캡처해보려 했다.

그런데 애플리케이션을 켜자마자 아래와 같은 네트워크 오류 알림이 뜨면서 통신이 진행되지 않았다.

그래서 처음엔 이렇게 생각했다.

"아, 여기도 SSL Pinning이 빡세게 걸려 있나 보다."

그래서 평소처럼 SSL Pinning을 우회하고 다시 시도했는데

똑같은 네트워크 오류만 반복될 뿐, 패킷은 단 한 건도 잡히지 않았다

“혹시 내가 프록시 설정을 잘못한 건가?” 하는 의심이 들어서

검증용으로 다른 앱, 예를 들어 네이버 애플리케이션을 실행해 프록시 동작 여부를 확인해봤다.

결과는 아주 멀쩡했다.

위의 그림처럼 네이버 애플리케이션에서는 요청/응답 패킷이 잘 캡처되었다.

즉, 프록시 설정 문제도 아니고

루팅/SSL Pinning 우회도 이미 되어 있는데

카카오뱅크 애플리케이션에서만 패킷이 안 잡힌다는 결론이 나왔다.

이쯤 되니 자연스럽게 이런 생각이 들었다.

“아, 이건 그냥 SSL Pinning 수준에서 막은 게 아니구나."

그래서 아래와 같이 생각을 하였다.

"기존의 패킷 캡처 자체를 차단하는 로직 혹은 다른 방법으로 되어 있겠구나"

이 이슈를 팀에서 같은 업무를 맡고 있는 동료에게 공유했고,

그 팀원 분이 감사하게도 접근 방향성을 하나 짚어 주었다.

그 조언을 바탕으로,

기존에 쓰던 방식이 아닌 다른 흐름으로 프록시를 구성해보았다.

그렇게 세팅을 바꾼 뒤 다시 카카오뱅크 애플리케이션을 실행해보니 

아래와 같이 더 이상 네트워크 오류 팝업이 뜨지 않고

아래 그림과 같이 HTTP(S) 패킷이 정상적으로 캡처되기 시작했다.

새로운 방식으로 프록시를 구성하자,

애플리케이션 내에서 발생하는 요청/응답이 서버와의 통신 구간까지 포함해서

문제없이 전부 캡처되는 것을 확인할 수 있었다.

이렇게 다른 단계에서도 서버와의 통신에서도 문제없이 패킷이 잘 캡처된것을 볼 수 있다.

한 번쯤 겪어봤을 것이다.

동네 중고거래 앱 당근마켓에서 마음에 드는 물건을 발견했는데,

글이 올라온 지 몇 초 만에 '예약중'으로 바뀌거나 사라진 적.

또 어떤 날은, 지역마다 똑같은 물건 글이 반복되어 올라오는 걸 본 적도 있을 것이다.

이런 현상은 대부분 매크로, 다중 계정, 그리고 다중 앱 악용이 원인이다.

그래서 예전에 내가 분석했던 인터파크 티켓팅 매크로 실험과 같이 알아보려고 한다.

당근으로 피해를 본 사람이라면 위의 사진을 한 번씩은 보았을 것이다.

첫 번째, 사진은 PC 화면에서는 수십 개의 당근창이 띄워져 있고,

각기 다른 지역에 로그인된 여러 계정이 동시에 로그인 중이다.

하지만 PC로 작업을 하기 위해서는 많은 제약이 있다.

이것을 보완하기 위해 모바일로 옮겨간 다중 애플리케이션으로 위의 두 번째 사진이다.

모바일에서는 동일한 당근 앱이 여러 개 복제되어 있고, 각 앱마다 서로 다른 계정으로 로그인해 거래를 진행한다.

이것도 티켓팅 못지않게 정말 큰 문제라고 생각한다.

예를 들어, 계정을 빌려주거나 대량으로 생성한 계정이 사기 거래에 쓰이면, 

피해가 개인에게 돌아가고 플랫폼은 책임 문제에 휘말릴 수 있다.

또 다수 계정 + 자동화는 인기 매물을 빠르게 선점하거나 반복해서 올려 노출을 차지할 수 있다.

정상 이용자는 ‘진짜 매물’에 접근하기 어려워지고 가격 형평성도 깨질 수도 있다고 생각한다.

즉, 정리하자면 이 구조는 단순히 편의 기능이 아니라, 시장 교란과 사기 거래의 핵심 도구가 될 가능성이 높다.

하지만 이런 문제가 있음에도 위의 설정이 되어 있는 휴대폰 단말기를 판매하기도 한다.

그래서 얼마나 쉽게 이렇게 당근 애플리케이션을 우회하고 위와 같이 다수의 계정으로 로그인을 할 수 있는지

테스트를 해보았다.

테스트한 결과, 핵심은 딱 3가지이다.

루팅 우회 + GPS 변조 + 다중 애플리케이션

이 세 가지만 통과하면 누구나 한 기기에서 여러 당근 계정을 동시에 운영할 수 있다.

원래 당근은 비정상적인 단말기에서는 아래와 같이 알림이 발생한다.

당근은 기본적으로 루팅된 단말기에서 실행을 탐지한다. 

보안을 위해 “비정상적인 단말기입니다”라는 알림이 뜨며, 앱이 즉시 종료된다. 

하지만 놀랍게도, 조금만 검색해 보면 일반인도 손쉽게 우회 방법을 찾을 수 있다. 

결과적으로, 시스템 보안이 완전히 풀린 루팅 단말기에서도 정상 로그인과 거래가 가능해진다.

그런 다음 2번째 요소인 위치 즉, GPS 변조이다.

당근은 사용자의 GPS를 기준으로 “우리 동네”를 설정하지만, 이 역시 간단히 우회할 수 있다.

예를 들어, 서울에 있으면서도 GPS 조작 앱을 통해 부산, 대구, 제주로 위치를 바꾸면,

마치 그 지역 주민처럼 인증이 통과된다.

즉, ‘내 근처 거래’라는 핵심 가치가 완전히 무너진다.

이것도 정말 조금만 찾아보더라도 GPS를 변조해 주는 방법이 널리고 널렸다.

현재 서울에 살고 있지만 GPS 변조로 아무 곳이나 설정해 주면 아래와 같이 설정한 위치로 동네 인증을 할 수 있다.

이것으로 이제 루팅 우회 + GPS 변조가 되었다.

이제 마지막 요소인 다중 애플리케이션이다.

이것도 조금만 찾아보면 진짜 쉽게 찾을 수 있다.

각 앱에 다른 계정으로 로그인한 뒤, 루팅 우회 + GPS 변조를 적용하면

하나의 휴대폰이 여러 사람인 척 활동하게 된다.

결국, 하나의 단말기로도 ‘서울 1계정, 부산 1계정, 대구 1계정, 광주 1계정’ 이런 식으로 지역별 계정이 

모두 동시에 거래 중일 수 있다.

이렇게 3개의 핵심 요소를 설정해 준다면 하나의 단말기에 당근 애플리케이션을 여러 개 설치한 후

각각의 계정에 GPS 변조로 위치를 설정해 주면 위의 사진에서 본 것처럼 매크로나 다중 계정을 사용할 수 있다.

더 나아가, API를 분석하여 전국에 있는 매물을 검색기로 만들어 판매하는 업체들도 생겨나고 있다.

API를 분석해 전국 매물 검색 자동화 프로그램을 제작하여 이것을 구독형식으로 판매를 하고 있다.

예를 들어 “전국 모든 지역의 ‘아이폰 15 프로’ 매물을 실시간으로 감시”하는 식이다.

이 정도면 사실상 ‘개인 거래’가 아니라 자동화된 중개 시스템이라고 해도 과언이 아니다.

이렇듯 매크로나 다중 계정 문제는 이제는 정말 단순한 문제가 아니다.

지역 기반 커뮤니티의 신뢰를 갉아먹고, 개인의 피해와 플랫폼 전체의 비용으로 연결된다.

기술, 운영적 대응을 마련해야 하지만 이것도 정말 쉽지 않다.

아무리 플랫폼에서 해당 방법을 보완한 다고 해도 또 이런 수요가 있는 이상 또 우회가 되기 마련이다.

기존의 iOS 14 버전에서 테스트를 하다가 오래된 버전이기도 하고 해당 단말기가 너무 느려서

16.0.2 버전의 iOS를 새롭게 구했다.

따라서 16.0.2 버전대에서 탈옥하는 과정을 정리해보려고한다.

매번 안드로이드에만 정신이 팔려 iOS는 잘 몰랐는데 정말 많이 생겼다.

트롤 스토어(TrollStore), 도파민(Dopamine), Palera1n, Zebra 등 정말 많이 생겼다.

정리하는 김에 하나씩 알아보려고 한다.

iOS 15부터 SSV 도입으로 rootless 탈옥이라는 개념이 등장하게 되었다.

여기서 SSV란 Signed System Volume의 약자로 시스템 파티션의 무경설을 강력히 보호하는 메커니즘이다.

이로 인해 전통적인 방식으로 탈옥하는 방식(rootfs)을 덮어쓰는 방식으로 탈옥하는 것이 어려워졌다.

따라서 그 대안으로 rootless 탈옥이 탄생한 것이다.

Rootless 탈옥은 시스템을 변경하지 않기 때문에 SSV을 우회할 수 있는 것이다.

그 방식을 사용한 프로젝트가 대표적으로 도파민(Dopamine), Palera1n이다.

그럼 차이점을 알아봐야 한다.

가장 큰 차이는 Semi-Untethered이다.

탈옥에는 3가지 버전이 있다.

• Tethered
  • 재부팅마다 PC 연결·특수 툴로 부팅 절차를 거쳐야 한다. (부팅을 정상적으로 못함)
• Untethered
  • 한 번 탈옥하면 재부팅해도 영구적으로 유지된다(부팅 체인에 영구적 수정이 존재).
• Semi-Untethered (중간형)
  • 재부팅 시 탈옥 상태는 풀리지만, 기기 내 앱/스크립트로 간단히 재적용(주로 앱 실행으로) 할 수 있다.
  • PC가 필요 없거나 최소한의 조작만 필요하다.

즉, 재부팅 후 재적용이 필요 없다는 것이다.

그래서 Dopamine를 많이 사용하는 이유이다.

따라서 Dopamine를 설치해 보자.

하지만, 아이폰은 기본적으로 서명된 애플리케이션만 설치가 가능하기 때문에 ipa는 일반적으로 설치를 하지 못한다.

그래서 트롤 스토어(TrollStore)가 필요한 이유이다.

트롤 스토어(TrollStore)는 탈옥 없이(시스템 변경 없이)

특정 IPA를 영구 설치(permanent sideload) 하게 해주는 툴이다.

트롤 스토어를 설치하기 위해 TrollInstallerX로 설치를 설치해야 한다.

먼저 위의 TrollInstallerX를 설치하기 위해서는 Sideloadly로 설치를 해야 한다.

Sideloadly 설치는 자신의 환경에 맞게 설치해 주면 된다.

그 후 아래의 TrollInstallerX.ipa를 다운로드하고 해당 단말기에 설치해 준다.

그러면 Done이라는 문구와 함께 아래의 TrollInstallerX가 설치된다.

실행을 하면 개발자 모드를 설정을 해야지만 설치가 된다고 한다.

따라서 개발자 모드를 셋팅 -> 개인정보 보호 및 보안에서 개발자 모드를 활성화한 후 재부팅을 해준다.

그러면 아래와 같이 실행이 가능하며 Install TrollStore을 클릭하면 설치가 된다.

위의 Dopamine 공식 페이지에서 ipa를 다운로드 받아서 설치해 줘도 되지만 사파리에서 아래의 주소로 접속하면

더 편하게 설치를 할 수 있다.

아이폰 사파리에서 https://ellekit.space/dopamine/ 를 입력한 후 접속하자.

그리고 Download .ipa를 클릭해서 다운로드 받자.

그 후 다운로드를 클릭해서 공유 버튼을 클릭해서 방금 설치한 TrollStore로 열어주자.

이렇게 TrollStore를 클릭하고 Install을 클릭하면 아래와 같이 Dopamin이 설치된다.

그리고 이제 마지막으로 Dopamine을 열어서 탈옥을 선택한 후

Sileo나 Zebra 2개의 중 선택해서 설치해 주면 탈옥이 완료된다.

오랜만에 직접 개발한 환경에서 아직 테스트하지 못한 모바일 보안 솔루션이 뭐가 있을까 하다가

에버스핀(Everspin)이라는 업체에서 만든 Eversafe 라는 모바일 보안 솔루션을 발견했다.

모바일 보안 솔루션도 적용하는 Level이나 탐지 정책으로 탐지가 될 수도 안될 수도 있다.

그래서 금융권에서 Eversafe를 사용하고 있는 곳을 찾아봤더니

우리 은행에서 사용하는 우리WON뱅킹이라는 애플리케이션을 발견하였다.

아래의 그림은 위의 에버스핀의 공식 홈페이지에서 캡처해 온 사진이다.

이렇게 크게 총 5개의 기능을 설명하는데 설명에 의하면

Eversafe는 시간대별로 동작되는 보안 모듈(.so)이 달라져 보안 모듈이 한 번 분석되더라도

실행할 때마다 보안 모듈이 교체되어 처음부터 다시 분석을 해야 한다는 점이 인상 깊었다.

따라서 바로 테스트를 해보았다.

물론 아래와 같이 루팅 우회는 가볍게 통과 했다.

다음은 Frida 탐지도 잘 우회가 되었다.

먼저 해당 프로젝트를 시작한 계기는 다음과 같다.
 
회사 업무 중 모바일 게임 모드앱이 들어왔을 때 분석을 진행해야 했다.
 
처음에는 어떻게 분석을 시작하는지, 어떻게 접근해야 하는지 자세히 몰랐다.
 
이때 Unity, Unreal, Cocos2d-x 등을 알게 되었고, 해당 엔진으로 만들어진 모바일 게임을 분석하기 위해서는
 
Unity 기준으로는 2가지 파일이 필요했다.
 
바로 libil2cpp.so와 global-metadata.dat 파일이 필요했다.
 
즉, Unity 게임을 분석하려면 크게 위의 2가지의 파일만 있으면 된다
 
짧게, Unity 게임 구조에 대해서 알아보면 다음과 같다.
 
대표적인 특징은 C# 코드가 곧 네이티브 코드(.so)로 변환되며 그 결과로 libil2cpp.so라는 특이한 파일이 생긴다.
 
그리고 여기서 global-metadata.dat라는 별도의 메타데이터 파일이 사용된다.
 
즉, libil2cpp.so는 Unity에서 실제 게임 로직(C#의 함수) 및 게임에서의 행동 코드를 네이티브 코드로 변환된
 
.so 파일이라고 생각하면 된다.
 
이처럼 중요한 파일이기 때문에 모바일 보안 솔루션이 적용되어 있는 모바일 게임에서는
 
libil2cpp.so 파일을 암호화를 하여 보호하기 때문에 분석하기가 까다롭다.
 
그렇다면 global-metadata.dat 파일은??
 
Unity가 IL2CPP로 변환할 때, 클래스명, 함수명, 필드명 등의 모든 구조 정보를 따로 저장한 메타데이터 파일이다.
 
libil2cpp.so 파일을 IDA로 디컴파일 한 후 global-metadata.dat를 검색하면 이렇게 나온다.
 

 
그 후 global-metadata.dat를 호출하는 곳으로 가면 아래와 같이 global-metadata.dat를 사용하는 코드가 보인다.
 

 
이렇게 libil2cpp.so에서  global-metadata.dat 파일이 사용된다는 것을 알 수 있다.
 
위치는 아래의 그림과 같이 보통 /assets/bin/Data/Managed/Metadata/ 또는 /assets/bin/Data/ 안에 존재한다.
 

 
이런 이유로 Unity 모바일 게임을 분석하기 위해서는 libil2cpp.so, global-metadata.dat 파일이 존재해야지만
 
원본의 C# 코드를 복원하여 분석할 수 있다.
 
이렇게 2개의 파일이 Unity로 개발된 모바일 게임을 분석하기 위해 꼭 필요한 파일이기 때문에 해당 파일을
 
대부분의 모바일 보안 솔루션이 적용되어 있는 게임에서는 암호화를 진행한다.
 
따라서 복호화가 된 libil2cpp.so, global-metadata.dat를 얻기 위해서는
 
게임이 실행된 이후에 복호화된 위 2개의 파일을 덤프 하여 파일을 얻어와야 한다.
 
이를 위해 대부분 Frida를 사용해서 위 2가지 파일을 덤프 한다.
 
하지만 Frida를 사용하기 위해서는 루팅 된 환경에서 진행해야 한다.
 
이는 모바일 보안 솔루션에서 바로 차단을 한다.
 
Frida를 사용하지 못하니 Frida Gadget을 사용해 볼까?
 
이러면 또 무결성 탐지 로직을 우회해야 하고,
 
운이 좋게도 루팅 탐지 로직을 우회했다고 하더라도? Frida 탐지 로직도 우회해야 하고,
 
실컷 분석하다가 분석하는 애플리케이션이 업데이트가 된다면 또다시 처음부터 분석을 해야 하고...
 
이런 문제점을 생각하다 보니 Frida라는 하나의 분석 툴에 의지할 수는 없어
 
so 파일과 global-metadata.dat 파일을 덤프 하는 프로젝트를 시작한 계기가 된 것이다.
 
이전에는 so 파일을 Frida 없이 덤프 하는 방법을 알아보았다. (25. Native Library(.so) Dump without Frida)
 
이번 포스팅은 global-metadata.dat를 Frida 없이 덤프 하는 것을 알아보자.
 
테스트로는 LoadComplete에서 만든 레전드 오브 슬라임:방치형 RPG라는 게임으로 진행해 보았다.
 
해당 애플리케이션을 선택한 이유는 이리저리 웹 서핑을 하다가 해당 애플리케이션 광고를 보고
 
마침 해당 포스팅을 할 생각이어서 설치해 보았는데 목적에 딱 맞게

Unity로 개발되었고 global-metadata.dat가 암호화되어 있었다.

 
그래서 해당 애플리케이션을 테스트로 선택하게 되었다.
 
다른 이유는 없다.
 
레전드 오브 슬라임:방치형 RPG 게임에서는 LIAPP 이라는 모바일 보안 솔루션을 사용하고 있었다.
 

 
해당 애플리케이션은 다운로드를 하여 libil2cpp.so 파일과 global-metadata.dat를 열어보면 다음과 같다.

 
위의 so 파일을 보면 첫 시작이 7F 45 4C 46으로 ELF의 구조를 가지고 있다.
헤더가 일단 암호화되어 있지 않아 보여 바로 global-metadata.dat 파일을 살펴보았다.
 

 
위의 global-metadata.dat를 보면 4C 49 4B 45로 일반적인 global-metadata.dat의 헤더가 아니다.
 
정상적인 global-metadata.dat의 시작은 아래의 그림처럼 AF 1B B1 FA로 시작한다.

 
여기까지 정리해 보자면 다음과 같다.
 
더 분석을 해봐야지 정확하겠지만 레전드 오브 슬라임:방치형 RPG 게임(com.loadcomplete.slimeidle)은
 
libil2cpp.so 파일은 암호화가 되어 있지 않거나, 부분적으로 암호화가 되어있다.
 
global-metadata.dat 파일은 암호화가 되어있다.
 
이렇게 정리할 수 있다.
 
libil2cpp.so에서 ELF 파일 구조를 가지고 있다고 해도 .text 영역을 암호화를 했을 수도 있을 수 있기 때문이다.
 
또 어떤 보안 솔루션에서는 ELF 파일 헤더를 그냥 00으로 채워서 분석을 못하도록 하는 경우도 있다.
 
따라서, 2가지 파일 모두 암호화가 되어있다고 생각을 하고 분석을 진행하였다.
 
먼저 동적으로 libil2cpp.so 파일을 덤프 해야 한다.
 
이는 이전 포스팅을 참고하면 된다. (25. Native Library(.so) Dump without Frida)
 

 
위의 그림은 IDA로 동적으로 원본의 libil2cpp.so 파일과 동적으로 Dump한 libil2cpp.so 파일을 비교한 그림이다.
 
Dump한 so 파일에서는 323173개의 함수가 존재했고 Origin libil2cpp.so 파일에서는 322711개가 나왔다.
 
462개가 차이가 난다.
 
여기에 각종 탐지 로직이 존재할 수도 있다.
 
물론 정석적인 방법으로 분석을 하면 찾을 수 있겠지만 이는 원하는 방식이 아니다.
 
빠르게 분석을 하기 위해서 이런 프로젝트를 진행하고 있기 때문에 목적에 맞지 않아,
 
분석하는 글은 나중에 시간이 되면 포스팅을 할 예정이다.
 
이제 동적으로 얻은 so 파일은 획득하였고 이제 복호화된 global-metadata.dat 파일을 얻어와야 한다.
 
그래서 RainDropGlobal이라는 툴을 개발하였다.

 
해당 툴의 사용법은 ./RainDropGlobal "패키지명"을 입력하면 위의 그림처럼 동적으로
 
Frida 사용 없이 global-metadata.dat 파일을 덤프 할 수 있다.
 

 
위의 그림처럼 AF 1B B1 FA로 복호화된 global-metadata.dat 파일을 얻을 수 있다.
 
이제 제대로 덤프가 되었는지 제대로 된 파일로 덤프가 되었는지 확인하기 위해서 dump.cs를 확인해 보면
 

 
이렇게 잘 덤프가 되었다.
 

해당 프로젝트를 하게 된 계기는 당근과 LIVE스코어라는 애플리케이션을 분석할 때였다.

당근이라는 애플리케이션은 Liapp이라는 모바일 보안 솔루션이 적용되어 있었고

LIVE스코어라는 애플리케이션은 Appseaing이라는 모바일 보안 솔루션이 적용되어 있었다.

(Appseaing이라는 모바일 보안 솔루션을 개발한 회사는 잉카엔트웍스였지만

현재 DoveRunner로 사명을 변경했다고 한다.)

다시 본론으로 돌아와서 당근 애플리케이션을 분석했을때의 상황을 생각해 보면,

분석할 당시에는 모바일 보안 솔루션을 분석하는 경험이 많이 없었고

한참 공부하고 연구할 때였다.

Frida 사용도 잘 못할 때였다.

그렇게 아무 생각 없이 당근 APK 파일을 다운로드하고 lib 폴더에

Liapp에서 개발한 libwfcwxdz.so 파일을 그대로 

IDA로 분석을 진행하였다.

당근 이전에 모바일 분석을 할 때 대부분 이렇게 진행하였다. 

분석을 한참 하다가 보니, 뭔가 이상했다.

APK 파일에서 추출한 libwfcwxdz.so 파일이 뭔가 제대로 되어 있는 것 같지가 않았다.

IDA에서 변수나, 함수등 Trace를 하기 위해서 참조를 살펴보았지만

참조가 제대로 나오지도 않았으며 ELF 섹션도 엉터리였다.

아래의 사진을 보자.

해당 그림은 APK 파일에서 그대로 가져온 so 파일이다.

IDA에서 분석한 함수는 총 666개이다.

섹션 상황도 보자.

섹션도 엉망으로 되어 있다.

그래서 생각을 해보았다.

왜 이렇게 되어있을까?

정답은 질문처럼 간단했다.

모바일 보안 솔루션 업체에서 해당 so 파일을 암호화나 인코딩을 통해 정적분석을 하지 못하도록 하는 것이었다.

아래의 그림은 LIAPP 홈페이지에서 소개되는 특징 중 하나이다.

위의 방식처럼 모바일 보안 솔루션에서는 중요하다고 생각하는 바이너리나 파일을

난독화 및 암호화하여 분석을 방해하는 것이다.

하지만, 뭘 어떻게 암호화를 했던 난독화를 했던 뭘 했던지간에 어차피 실행을 하기 위해서는

복호화나 디코딩을 해야 할 것이라는 생각을 하였다.

대부분의 모바일 보안 솔루션은 실행하면서 복호화나 디코딩 함수를 통해 메모리에 로드한다.

이때 덤프를 한다면 100%의 원본은 획득하지 못하지만 분석에 필요한 so 파일을 얻을 수 있다고 생각하였다.

하지만 덤프를 하기 위해서는 Frida를 통해 덤프를 해야 하는데 제대로 된 분석을 하지 못해

Frida를 탐지하는 로직을 우회할 수 없었다.

두 번째 상황은 LIVE스코어라는 애플리케이션을 분석할 당시였다.

이때는 그래도 모바일 보안 솔루션 분석에 필요한 노하우도 어느 정도 생겼고,

분석하는 스킬도 많이 늘었다고 생각을 했었다.

그러고 나서 위의 애플리케이션을 다운로드하고 Frida를 통해 해당 so 파일을 덤프 하기 위해서

Frida를 실행해보았다.

당연히 Frida 탐지가 되어 애플리케이션을 종료가 되었다.

Frida 탐지가 되기 때문에 분석하기 어려워 이때까지 쌓은 노하우나 스킬을 모두 사용해 보았지만 우회할 수 없었다.

이때 해당 프로젝트를 해보아야겠다는 생각을 처음 한 순간이었다.

Frida를 사용하지 못하면? 정적 분석에 필요한 so 파일을 획득할 수 없구나,

따라서 Frida를 사용하지 않고 덤프를 할 수 있는 방법을 찾아봐야겠다고 생각했다.

그렇게 퇴근 후 이것저것 찾아보고 연구한 결과,

Frida 없이 so 파일을 덤프 할 수 있는 RainDropELF라는 툴을 개발하였다.

./RainDropELF "덤프 할 패키지명" "덤프 하고 싶은 so 파일"을 입력하면

/data/local/tmp에 덤프 된 so 파일을 얻을 수 있다.

Frida 탐지 로직을 우회를 한 후 so 파일을 덤프하고 IDA로 디컴파일을 하려고 할 때 아래와 같은 

Bad file structure or read error (line 5840). Continue? 라는 문구를 한 번쯤은 본 적이 있을 것이다.

File contains meaningless/illegal section declarations 해당 문구도 본 적이 있을 것이다.

이런 문제도 덤프 할 때 위의 문제를 해결되도록 개발하였다.

덤프 한 so 파일을 IDA로 열어보면 처음 666개 밖에 없었던 함수의 개수도 813개로 늘어났고

함수 심볼들도 잘 복구가 된 것을 볼 수 있다.

물론 섹션도 잘 복구가 되었다.

보통 한 달에 한두 번, 많을 때는 세 번까지,

직접 개발한 환경에서 모바일 보안 솔루션 우회 여부를 테스트를 해본다.

이유는 간단하다.

각 보안 솔루션은 국내외 수많은 고객사가 존재한다.

특히 금융권이나 공공기관 같이 민감한 데이터를 다루는 환경에서 주로 많이 사용한다. 

실제로 많은 기업들이 보안 솔루션을 도입한 후

외부 보안 컨설팅 업체를 통해 연간 단위 모의해킹 프로젝트를 진행한다.

이런 프로젝트에 투입 된다면 해당 인원이 가장 어려워하고 난감해야하는것은

내부망 진단, CS 진단, 모바일 애플리케이션 진단이다.

그 중, 모바일 애플리케이션 진단을 하기위해서는

당연히 해당 서비스에 적용되어 있는 보안 솔루션을 우회하는 시도도 필수이다.

이렇게 모바일 보안 솔루션 우회 과정을 지나 검수를 통해 보안 취약점을 발견하고

해당 취약점을 기반으로 보고서가 작성된다.

보고서를 받은 기관이나 기업은 내부적으로 조치를 취하고

이행점검을 진행해야 한다.

중요한 건 여기서 해당 솔루션 공급사에도 공유가 된다.

왜냐하면 대부분의 기업은 솔루션 자체를 직접 개발한 것이 아니기 때문에  

우회된 원인을 해결할 수 있는 주체는 결국 솔루션 업체이기 때문이다.

결과적으로 이 과정은 솔루션 업체에게 새로운 취약점에 대한 대응 로직을 추가하거나  

기존의 탐지 로직을 수정할 기회가 제공되는 것이다.

이런 구조 속에서 보안 솔루션은 빠르게 고도화가 진행된다.

우회 시도와 그에 따른 피드백이 반복되면서 자연스럽게 탐지 기술은 더 발견하기 힘들어지고

신규 취약점이나 루팅 툴, 해킹 툴등 에도 빠르게 대응할 수 있게 된다.

따라서 한 달에 적어도 2~3번 이상은 1차로 개발한 환경에서 

모바일 보안 솔루션이 적용되어 있는 여러 애플리케이션들을 실행해보는 이유이다.

그래서 이번에 테스트를 진행한 솔루션은 스틸리언이라는 회사에서 개발한하는 AppSuit이다.

해당 제품이 어디서 사용되고 있나 살펴봤더니, 물론 더 많이 존재하겠지만

당장 설치되어 있는 애플리케이션에서 찾아보니 키움증권의 MTS, '영웅문' 이라는

애플리케이션에 적용되어 있었다.

1차 개발이 완료된 환경에서 실행한 결과, 

다른 모바일 보안 솔루션과 다를 것 없이 애플리케이션이 정상적으로 실행된것을 볼 수 있다.

또한, Frida도 별다른 오류 없이 정상적으로 사용이 가능했다.  

즉, 탐지나 차단 로직에 탐지되어 종료가 되지 않았다는 것은,

1차로 개발 환경에서 자동으로 루팅 탐지 로직과 USB 디버깅 탐지 로직

그리고 Frida 탐지 로직을 우회가 자동으로 성공했다는 의미이다.

앞으로도 다양한 모바일 보안 솔루션을 테스트하여 2차, 3차 등 고도화를 계속 진행할 예정이다.

이번에 회사에서 새로 출시된 PC 게임을 보안 검수해야 하는 일이 생겼다.

매번 웹이나 모바일만 검수를 하다가 PC 게임을 제대로 검수하는것은 처음이었다.

출시가 얼마 안된 베타 버전이지만, 해당 게임에 대한 핵이 벌써 만들어졌다. 

그래서 한번도 제대로 분석을 해보지 않았지만 분석을 해야만 했다.

그래서 유심히 게임 핵 영상을 살펴보던 중 DLL Injection을 하는 모습을 보았다.

한번씩 DLL Injection이라고 들어는 봤지, 한번도 해본적도 없이 없었다.

따라서 이번에 좋은 기회일것 같아 제대로 찾아보고 약간의 기술적인 내용과 함께

DLL Injection을 쉽게 할 수 있는 툴을 개발해보았다.

DLL이란 도대체 뭘까?

DLL은 Dynamic Link Library의 약자이다.

쉽게 말하면, 공유해서 쓸 수 있는 라이브러리라고 생각하면 된다.

모바일에서는 so 파일이라고 생각하면 쉽다.

사운드와 관련된 함수를 사용하고 싶으면 사운드와 관련된 dll을 사용하면 되고

메세지 박스를 사용자에게 보여 주고 싶으면 해당 메세지 박스를 사용할 수 있는 dll을 불러와 사용하면된다.

그렇다면, DLL Injection이란?

DLL Injection이란, 내가 만든 DLL을 다른 프로그램(예: 게임)에 강제로 '끼워넣는'기술이다

이걸 통해 그 프로그램의 동작을 감시하거나, 조작하거나, 로그를 찍는 등의 작업이 가능하다.

예를 들어, FPS 게임이라면 총을 쏜 후에 재장전을 해야하는데 재장전 시간을 0초로 만들 수 있다는것이다.

실제로 어떻게 이루어지나?

실제로 DLL을 주입해보려면 간단하게 아래와 같은 단계를 진행하게 된다.

1. OpenProcess → 대상 게임 프로세스를 연다
2. VirtualAllocEx → 게임 메모리에 공간을 만든다 
3. WriteProcessMemory → DLL 경로를 그 공간에 쓴다 
4. GetProcAddress → LoadLibraryA()의 주소를 찾는다 
5. CreateRemoteThread → LoadLibrary를 실행시켜 DLL을 로드한다

위의 과정이 내가 Injection 하고 싶은 프로세스에 DLL을 Injection 하는 과정이다.

왜 이런 기술이 존재할까?

보안은 양날의 검과 같다.

아래의 정당한 용도와 악의적인 용도를 보자.

정당한 용도

• OBS 같은 방송 프로그램이 게임 화면을 캡처할 때
• 보안 프로그램이 키 입력을 감시할 때
• 디버거가 내부 함수 호출을 후킹할 때

악의적인 용도

• 게임 핵 (ESP, 오토에임)
• 악성코드 (키로거, 정보 유출)
• 백도어 삽입 등

이처럼 쓰임새는 다양하지만 목적에 따라 용도가 달라진다.

이렇게 짧지만 DLL Injection에 대해서 알아보았다.

이제 해당 과정과 개념을 가지고 편하게 DLL Injection을 할 수 있는 툴을 개발해보았다.

아래의 툴을 가지고 PC 게임을 분석한 후 게임 함수를 후킹할 수 있는 DLL을 만들어 Injection하면

우리가 흔히 아는 게임핵이 만들어지는것이다.

코인도 주식도 항상 가격이 오르락내리락 한다.

그런데 "어디쯤에서 사람들이 가장 많이 매수했을까?" 하는 궁금증이 생겼다.

그 해답이 바로 평균가라는 정보다.

예를 들어 어떤 종목의 현재 가격이 3만 원이라고 해보자.

이게 '머리'에 해당할 수도 있고, '어깨', '몸통', '무릎', '발' 같은 위치로 나눠서

현재 가격이 고점인지 저점인지 감을 잡는 데 참고할 수 있다.

처음엔 이 평균가 데이터가 단순히 앱에서 보여주는 숫자일 뿐이라고 생각했다.

그런데 문득 궁금해졌다.

"이 숫자는 어떻게 계산되는 거지?"

"서버에선 뭘 주고받길래 이런 데이터가 나오는 걸까?"

사실 이런 호기심은 나만의 투자 도우미 앱을 만들면서 시작됐다.

"어떤 기능을 넣으면 좋을까?" 고민하며 증권사 앱들을 둘러보다가,

이 평균가 기능이 꽤 유용해 보여서 직접 구현해보고 싶어진 것이다.

요즘 증권사 앱들에 들어가 보면 '평균가' 항목을 제공하는 곳도 있고,

아예 보여주지 않는 곳도 있다.

보통 이 '평균가'는 그 증권사를 통해 해당 종목을 매수한 사람들의 평균 단가를 의미한다.

예를 들어 삼성전자 주식의 현재가가 10만 원인데,

앱에서 평균가가 6만 5천 원으로 표시된다면?

대부분 싸게 샀고, 지금은 수익 중이라는 뜻이다.

재밌는 건 이 데이터를 단순 숫자가 아니라 시각적으로 보여주는 방식이다.

많은 앱이 사람의 신체 구조에 빗대어 다음과 같이 표현한다.

• 머리
• 어깨
• 몸통
• 무릎
• 발

예를 들어 평균가가 2만 원이고, 현재 가격이 1만 원으로 '발'에 해당된다면?

거의 저점으로 볼 수 있다.

이럴 경우, 매수 포인트로 판단할 수도 있는 것이다.

물론 이런 단순한 지표 외에도 기술적 분석은 반드시 병행되어야 한다.

그래서 이 기능을 나만의 투자 앱에 넣어보기로 마음먹고, 분석을 시작했다.

먼저 앱에서 이 평균가가 어떻게 서버에서 데이터가 전달 되는지 확인하려면,

서버와 어떤 데이터를 주고받는지를 파악해야 했다.

당연히 프록시 툴을 먼저 써봤지만,

패킷이 하나도 잡히지 않았다.

요즘 증권사 앱들은 보안과 속도를 위해

TCP 소켓 통신을 사용하며, 암호화까지 적용되어 있어서

일반적인 방법으로는 내용을 확인할 수 없었다.

결국 해당 앱을 뜯어보기로 했다.

당연히 증권사 앱답게 루팅 탐지, 디버깅 탐지, 피닝 탐지 등 엄청난 보안 로직들이 적용되어 있었다.

위의 탐지 로직 등을 우회하면 드디어 코드와 앱의 실행 과정을 분석할 수 있었다.

코드를 분석하면서 서버와 주고받는 구조를 추적 및 분석을 하였고,

마침내 평균가 요청 패킷 구조와 암호화 키, 응답 데이터 형식을 확인할 수 있었다.

예를 들어 삼성전자 종목 코드와 함께 평균가 요청을 보내면,

서버는 해당 종목에 대한 이용자 평균 매수 단가를 계산해 응답해준다.

응답값은 단순 평균뿐 아니라,

머리, 어깨, 몸통, 무릎, 발에 해당하는 구간별 가격까지 함께 포함되어 있었다.

아래 왼쪽 그림은 현재 삼성전자의 현재가와 전날과의 대비 등락을 보여주는 화면이다.

해당 종목을 클릭하면 오른쪽 그림처럼 현재 삼성전자의 평균 단가를 보여주는

그림을 출력하도록 기능을 추가하였다.