Raining_93

이전에 포스팅 한 6. 인터파크 티켓팅 매크로에서 스포츠도 매크로로 예매를 할 수 있냐는

질문이 너무 많았다.

인터파크 티켓팅 매크로를 만든 이유 이전 포스팅에서도 언급하였지만 

얼마나 만들기 쉬운지, 누구나 만들 수 있는지? 왜 이렇게 불법 매크로까지 판매하는지

궁금하여 만들어 본 것이다.

하지만 당해보신 분들은 아시겠지만, 정말로 내가 원하는 공연이나, 정말 직관하고 싶은 스포츠 경기나

이런 경우 열심히 티켓팅을 해봐도 매크로를 절대로 이길 수 없다.

스포츠 경기 티켓은 중고나라에서 얼마나 팔리는지 보았는데 프로 야구 경기는

거의 2배나 가까운 금액에 거래가 되고 있었다.

인터파크 스포츠 티켓팅 매크로는 분석해 보지를 않아서, 잘 모르겠지만 원리는 비슷할 것 같았다.

따라서 이전 포스팅에서는 UI나 이런 것들에 신경 써서 만들어 보았지만,

이번에 포스팅할 스포츠 티켓팅은 확인용으로만 UI 없이 만들어 보았다.

위와 같이 처음 보는 대기열은 1071명이다.

물론 변수가 존재하겠지만  이전에는 2159명이 대기열이 존재했는데 내가 티켓팅을 할 차례가 올 때까지

정확히 28분 39초가 걸렸다.

대략 30분 정도를 대기해야 한다.

분석해 본 결과, 이전에 포스팅한 내용과 큰 차이가 없었고,

이전에 분석한 내용을 토대로 어렵지 않게 스포츠 경기 매크로도 만들 수 있었다.

위의 영상처럼 천명이 넘는 대기열을 우회하여 바로 예매창으로 접속할 수 있다.

또한 보안 문자 우회도 자동으로 입력하게 만들었다.

결제까지 자동화한다면 대략 10초도 안 걸릴 것 같다.

좌석 선택 및 결제까지 자동으로 만들지 않은 이유는 이전 포스팅에서도 언급했듯이,

왜 이렇게 불법 매크로가 판을 치고 있는지 얼마나 만들기 힘들어서 티켓 가격을 저렇게 비싸게 파는지

궁금하여 만들어 보았기 때문이다.

이렇게 매크로를 만들어보면서 어느 부분이 핵심인지 알게 되었고,

해당 부분을 보완한다면 이런 매크로를 잡아 깨끗한 티켓팅 문화를 만들 수 있을 것 같다.

회사에서 사이드 업무로 모드앱을 자주 분석한다.

모드앱 분석 업무는 크게 2가지로 나눌 수 있다.

1. 모바일 보안 솔루션을 어떻게 우회했는지

2. 어떤 게임 함수를 후킹했는지

이렇게 크게 2가지로 나눈다.

이번에도 모드앱을 분석을 완료하고 나서, 분석한 내용을 바탕으로 패치된 버전이 업로드가 되었다.

하지만 게임이 패치되고 나서 얼마 지나지 않아 패치된 버전의 모드앱이 또 올라왔다.

그러고 생각을 해보았다.

"아니 패치된 지 24시간도 지나지 않았는데 벌써 모드앱이 나온다고?"

"모드앱 만들기가 쉬운가?"

라는 생각이 문득 들었다.

따라서 모드앱을 직접 만들어 봐야겠다고 생각을 하였다.

그 이유는 모드앱을 분석할 때도 모드앱 구조나 분석을 조금 더 쉽게 할 수 있지 않을까?

라는 생각이 가장 컸다.

그래서 평소 대중교통이나 자기 전에 잠깐 하는 Royal Match라는 게임을 모딩 해보았다.

Royal Match라는 게임은1억 명 넘게 다운로드 한 유명한 퍼즐 게임이다.

2023년 1~10월까지 퍼즐 게임 매출 및 매출 성장에서 1위를 달성한 게임이다.

"이렇게 인기가 있는 게임이면 분명 모드 앱이 나와 있을 건데?"

라는 생각에 검색을 해보니 역시 모드앱이 존재하였다.

하지만 대부분 무료로 풀리고 있었다.

모드앱 시장에서는 크게 유료와 무료로 나뉘는데

유료 모드앱인 경우 대부분 모바일 보안 솔루션이 탑재된 게임이었으며, 우회 작업까지 한 모드앱이었다.

즉, 조금 더 시간이 걸렸기 때문에 돈을 받고 판매를 하는 것 아닐까?라는 생각이 들었다.

하지만 Royal Match라는 게임은 대부분 무료로 풀리고 있었으며

"아 Royal Match 게임은 모바일 보안 솔루션이 올라가 있지 않겠구나" 라는 생각이 들었다.

그러고 나서 보니 정말로 모바일 보안 솔루션이 탑재가 되어 있지 않았다.

따라서 쉽게 모딩이 가능했다.

물론 게임 함수도 후킹 되는 마당에 모바일 보안 솔루션이 탑재되어 있더라도 이는 쉽게 우회가 가능하다.

이미 시장에 풀려 있던 모드앱을 다운로드 받아보면 메뉴가 총 4개가 존재한다.

챕터를 바로 Clear 할 수 있는 Auto Clear

게임을 시작하기 위해서는 Heart가 필요한데 Heart의 소모 없이 무한으로 게임을 시작할 수 있는

Unlimited Heart 등이 존재하였다.

하지만 퍼즐 게임 특성상 퍼즐을 이동시킬 때마다 줄어드는 이동 횟수를 모딩 하는 것은 없었다.

따라서 이동 횟수를 모딩을 하고 싶어 Unlimited Moves라는 메뉴를 아래와 같이 만들어봤다.

위의 Unlimited Moves를 적용하면 아래와 같이 이동 횟수가 9999로 증가된 상태로 게임을 시작할 수 있다.

이렇게 모드앱을 직접 만들어 보니

"아.. 이래서 패치가 되더라도 그렇게나 빨리 다시 모드앱이 나올 수가 있구나.."

라는 생각이 제일 많이 들었다.

최근 우리 회사의 모바일 보안 솔루션 팀에서 흥미로운 업무 지원 요청을 받았다.

한 고객사의 게임에서 모드앱(해킹앱)이 발생했으며, 이를 분석해 달라는 요청이 왔다.

특히, 해당 모드앱은 LDPlayer, GameGuardian, Magisk, Hide the Magisk Manager APP 등

다양한 기능과 프레임 워크들을 사용하였다.

당연히 위의 환경으로 설정하게 되면 단말기 또는 Emulator는 루팅된 환경이 된다.

게임 앱 같은 경우 서비스 정책상 Emulator를 차단하게 되면 큰 단점으로 이어질 수 있기 때문에

대부분 허용해 준다.

하지만 여기서 가장 큰 문제점은 우리 회사에서 제공하는 보안 솔루션에서

최신 Magisk 27.0 버전을 탐지하지 못하고 있었다.

따라서 최신 Magisk 27.0 버전을 탐지할 수 있는 방법과 Magisk의 기능 중 하나인 DenyList와

루팅 탐지를 우회하는 각종 모듈들을 탐지할 수 있는 방법에 대한 좋은 주제로 분석을 진행하게 되었다.

Magisk는 전 세계적으로 사용하고 있는 루팅 툴이다.

그러면 그만큼 패치가 자주 일어나고, 우회 - 탐지 - 우회 - 탐지가 반복적으로 발생한다.

따라서 Root cause인 Magisk 자체를 탐지하면 해결될 것 같았다.

이런 생각으로 분석을 진행하였다.

자세한 로직과 원리는 공개하지 못하지만,

최신 Magisk 27.0, Magisk, Hide Magisk Manager, DenyList, 루팅 탐지를 우회하는 각종 모듈 등을 

적용하여도 탐지할 수 있는 방법을 발견하게 되었다.

결과는 다음과 같다.

기본 Magisk 탐지인 com.topjohnwu.magisk를 탐지하는 경우이다.

이는 대부분의 모바일 보안 솔루션에서 탐지를 한다.

해당 방법은 우리 회사에서 만든 보안 솔루션에서도 탐지를 한다.

하지만 문제는 다음과 같이 Hide the Magisk Manager APP의 기능으로 Magisk 패키지명을

랜덤으로 숨겨 버린 후, DenyList에 해당 앱을 추가하면 모바일 보안 솔루션에서 탐지를 하지 못하였다.

그 이유로는 첫 번째 같은 경우는 com.topjohnwu.magisk이라는 정해진 패키지명으로 설치가 되기 때문에

패턴으로 쉽게 탐지가 가능하지만,

위의 두 번째 같은 경우에는 Random Package Name로 설치가 되어 패턴으로는 알 수 없기 때문이다.

하지만 분석 끝에 탐지할 수 있는 방법을 발견하였고

아래와 같이 Random Package Name으로 설치된 Magisk를 탐지할 수 있었다.

끝으로 보안 업무를 주로 할 때 오펜시브(공격적) 경향이 강했다. (사실 오펜시브가 더 재밌었다.)

보안 취약점을 찾고 이를 악용해 시스템을 테스트하는 것이 주된 역할이었다.

하지만 이번 업무는 이전과는 달리 디펜시브(방어적) 측면에서 생각해야 하는 업무였다.

주 업무가 아닌 업무 지원 역할로이었기 때문에 처음에는 사실 힘들었다.

하지만, 지금 생각해 보면 새로운 경험을 쌓는 좋은 기회였던 것 같다.

거의 3주 동안 퇴근 후 주말 밤낮없이 분석을 진행했던 것 같다.

다른 접근 방식을 배울 수 있었고, 보안의 다양한 측면을 이해하는 데 큰 도움이 되었다.

앞으로도 이러한 경험을 바탕으로 조금 더 성장할 수 있을 것 같다.

탐지 로직은 더 추가할 예정이다.

어느덧 모의 해킹 직무를 맡은 지 약 3년이 넘게 흘렀다.

지난 세월을 되돌아보면 정말 많은 일들이 있었다.

특히 기억에 남는 것은 모바일 애플리케이션 진단 업무를 처음 맡았을 때의 경험이었다.

당시에는 진단 방법에 대해 감을 잡기가 어려웠다.

내가 가지고 있는 모바일 분석 스킬은

대학원 시절 보안 관련 과목 프로젝트에서 Frida를 사용해본 경험이 전부였다.

그때도 남이 작성한 Frida Script를 실행만 할 줄 알았지, 직접 작성하거나 구조를 이해하지 못했다.

그저 남이 작성한 Script를 복사하고 실행하는 수준이었다.

졸업 후 모의해킹 회사에 입사하면서 처음으로 모바일 보안 솔루션이라는 존재를 처음 알게 되었다.

운이 좋게도 입사한 회사에서 모바일 진단 프로젝트를 많이 진행했고,

모바일 분석에 관심이 많은 분이 계셨다.

그분 덕분에 처음보다 많이 성장했지만,

여전히 모바일 보안 솔루션을 완벽히 분석하고 우회하기는 쉽지 않다.

아직도 이해가 안 되는 부분과 부족한 점이 많다고 생각한다.

여기서부터는 정말 개인적인 생각이지만

모의 해킹 직무를 맡으면서 이런 저런 사람들을 많이 만났는데

모바일 애플리케이션 진단을 제대로 할 수 있는 사람은 드물었다.

웹 모의해킹은 어느 정도 가능한 사람이 많지만, 모바일 진단까지 수행할 수 있는 사람은 많이 없었다.

사실 모바일 보안 솔루션은 시간만 충분하다면 대부분 우회가 가능하다.

하지만 모의 해킹 직무는 일정이 항상 정해져 있다.

모바일 애플리케이션 한 개를 진단하는 데 주어지는 시간은 짧게는 3일, 길게는 5일이다.

이 짧은 시간 동안 환경 설정, 모바일 보안 솔루션 우회, 애플리케이션 진단, 보고서 작성까지 해야 한다.

그러다 보니 모바일 보안 솔루션 우회에 시간을 많이 빼앗겨 서비스 진단에 깊게 집중하기 어렵다.

그때부터 이런 고민이 들었다.

"모바일 보안 솔루션 우회에 시간을 쓰지 않고, 해당 서비스 진단에만 집중할 수는 없을까?"

그렇게 퇴근 후 약 10개월간 혼자 공부하고 연구하며

대부분의 국내 모바일 보안 솔루션을 우회 없이 진단할 수 있는 방법을 발견했다.

아직까지 계속 연구와 개발이 진행중이며, 1차 테스트로 개발이 완료 되었다.

각각의 보안 솔루션 탐지 로직을 분석하고 우회하는 방식이 아니라,

모든 모바일 보안 솔루션 탐지 로직의 공통적인 특징을 분석해 일반화된 우회 방법을 찾아냈다.

이를 통해 정해진 기간 내에 빠르고 정확하게 서비스 진단에 집중할 수 있는 환경을 만들었다.

크게 보면 루팅 우회와 Frida 우회라는 두 가지 방법이다.

진단 중 우회가 덜 된 부분이나 예상치 못한 탐지 로직이 발견되면 즉시 추가 우회를 진행하였다.

이렇게 별다른 작업 없이 모바일 애플리케이션을 진단할 수 있다.

이를 통해 분석 시간을 크게 단축하고, 서비스 진단에만 집중할 수 있는 환경을 만들었다.

아래는 당근이라는 애플리케이션에서 루팅된 단말기에서 frida -U -f  com.towneers.www 명령어로

Frida를 실행 시킨 모습이다.

한 번쯤 보고 싶은 영화, 콘서트, 뮤지컬 등을 보기 위해 설레는 마음으로

예매 날짜가 다가오기만을 기다린 경험이 있을 것이다.

예매를 남들보다 빠르게 하기 위해 타임시커, 네이비즘 등 티켓팅 사이트의 서버 시간까지 확인하며

예매 시간이 딱! 됐을 때 남들보다 빨리 클릭했겠지?라는 생각에 창이 열리기만을 기다리다가

창이 열리는 순간  아래의 대기열을 마주 본 적이 있을 것이다.

만약, 위의 대기열을 보지 못하더라도 접속하자마자 판매가 다 완료된 경우도 종종 있다.

이유는 바로 아래의 불법 매크로 때문이다.

대략 10초도 안 되는 시간에 매진되는 공연 티켓을 항상 좋은 VIP 좌석을 선점하여 밑의 기사처럼 

원래 티켓 가격의 2배, 3배 비싼 가격에 판매하는 경우가 참 많다.

우리가 정말 자주 사용하는 네이버 중고나라에서도 이렇게 티켓을 파는 경우를 볼 수 있다.

위의 티켓의 가격을 보자.

장당 200만원, 1열 2연석이면 400만원을 주고 공연을 관람해야 한다.

제일 앞줄은 장당 250만원, 2연석 500만원이다.

그래서 원래 티켓 가격이 얼마인지 알아보았는데 원래의 VIP석 가격이 187,000원이다.

참.. 개인적으로 이건 해도 너무하다고 생각이 들었다.

그렇게나 인기가 많은가? 싶어 해당 사이트에 가서 예매하기를 클릭해 보니 아직까지 대기열이 존재했다.

자리가 모두 매진되었지만 지금까지 대기열이 존재하는 이유는

아마 취소하는 티켓을 예매하려는 취케팅을 하려는 사람들이나

매크로가 동작하고 있을 것으로 추측을 해볼 수 있다.

개인적인 생각으로는 티켓 가격을 올려서 파는 건 이해할 수 있다.

그 시간에 대신 티켓을 예매한 것이고, 그 사람의 시간과 노력이 든 것이니

가격을 기본 가격보단 조금 높여서 팔 수는 있다고 생각은 한다. 

하지만 장당 200만원, 250만원이면 이건 해도 너무 하다고 생각이 들었다.

그래서 요즘 티켓팅 매크로 문제들이 수면 위로 떠오르기 시작했고 사회적인 이슈가 된 것 같다.

사실 오래전부터 문제는 되어 왔지만 요즘 조금 더 이슈화가 많이 되고 있는 것 같다.

얼마나 만들기 쉬운지, 누구나 만들 수 있는지? 왜 이렇게 불법 매크로까지 판매하는지 궁금하여

매크로 티켓팅 프로그램을 만들어보았다.

선정 기준은 매크로를 만드는데 필요한 난이도 등 아무 상관없이 단순하게

위에서 설명한 것처럼 장당 200백만원, 250만원하는 임영웅 서울 콘서트를 검색하니

인터파크 티켓에서 진행하고 있었고 따라서 인터파크 티켓 매크로를 만들어 보았다.

위의 티켓팅 매크로의 과정은 다음과 같다.

1. 계정 입력

2. 로그인

3. 공연 코드 입력

4. 관람일, 회차 입력

5. 예매 시간 입력

6. 대기열 우회

7. 보안 문자 우회

좌석 선택 및 결제까지 자동으로 만들지 않은 이유는

왜 이렇게 불법 매크로가 판을 치고 있는지

얼마나 만들기 힘들어서 티켓 가격을 저렇게 비싸게 파는지

궁금하여 만들어 보았기 때문에 더 이상은 의미가 없어 진행하지 않았다.

사실 위의 단계까지만 하더라도 90% 자동화를 한 것이나 다름이 없다.

위의 티켓팅 매크로를 만들면서 얻은 정보와 분석한 결과를 토대로

다른 웹 사이트 티켓팅 매크로도 하나씩 만들어 볼 예정이며

이를 방지할 수 있는 기술이나 기법이 있는지 연구해볼 생각이다.

현재 댓글로 인터파크 스포츠와 관련한 문의가 너무 많아

따로 인터파크 스포츠 티케팅 내용 포스팅 하였습니다.

9. 인터파크 스포츠 티켓팅 매크로

다음으로 추가한 기능은 Memory Dump 기능이다.

모바일 애플리케이션을 분석하다가 보면 내가 원하는 Native Library(.so) 파일이나

메모리에서 원하는 파일을 덤프를 해야할 때가 있다.

예를 들어 모바일 보안 솔루션에서는 애플리케이션을 실행한 후 맵핑 정보에서 delete하는 경우가 있다.

다음 그림을 보자.

해당 파일은 분석해봐야 정확히 deleted된 파일이 so 파일인지, Dex 파일인지는 알 수 있겠지만

위의 그림처럼 실행시 마다 매번 이름을 변경되는 파일이 있다.

많이들 사용하고 있는 frida를 이용할 시 해당 파일을 덤프하기 위해서는

먼저 루팅 우회, 프리다 우회, 변경되는 문자열를 표현하는 정규식 등을 우회 및 설정 해야지만

해당 파일을 덤프할 수 있다.

이런 과정을 조금 더 빠르게 수행하기 위해서 Memory Dump 기능를 추가하였다.

Memory Dump 화면 구성은 다음과 같다.

Home 탭에서 Memory Dump 버튼을 클릭하면 다음과 같이 현재 연결되어 있는 단말기에서

실행되는 모든 애플리케이션을 보여준다.

여기서 분석하고자 하는 애플리케이션을 클릭하면 아래와 같이

메모리 맵핑 정보를 보기 편하게 자동으로 파싱하여 볼 수 있다.

그 후 검색을 통해서 맵핑 정보를 빠르게 검색할 수 있고, 덤프할 맵핑 정보를 클릭 시

덤프할 offset도 자동으로 입력해준다.

그 후 Dump 버튼을 클릭하면 /data/local/tmp에 분석하는 애플리케이션의 이름으로 된 폴더가 생성되며

생성된 폴더안에 덤프된 파일이 존재한다.

방금 설명한 내용이 아래의 과정이다.

끝으로 개인 연구 및 개발 목적이지

포스팅 내용 중 보이는 애플리케이션에 대한 악의적인 목적은 전혀 없다.

다음으로는 모바일을 분석하던 도중 제일 첫 번째로 하는 것은

분석하고자 하는 APK 파일을 Decompile 하여 DEX 파일을 분석하는 것이다.

하지만 요즘 대부분의 모바일 보안 솔루션은 서비스하는 애플리케이션의 DEX를

동적으로 로딩을 하거나 암호화된 파일을 런타임 중에 암호화된 DEX를 복호화를 하기 때문에

APK 파일을 Decompile 툴을 이용해서 분석을 할 때 보이지 않아 한계가 존재한다.

따라서 APK를 정적으로 분석할때 가장 먼저 하는 것이 AndroidManifest 파일을 먼저 분석하고

애플리케이션이 어떻게 동작하는지 이해를 해야한다.

AndroidManifest 파일에 대해서 조금 짧게 설명하자면 다음과 같다.

AndroidManifest 파일에는 앱의 기본 설정 및 특성을 정의하는 중요한 파일이다.

따라서 AndroidManifest 파일에는 앱의 구성 요소, 권한, 서비스, 액티비티, 리시버 등과

관련된 정보가 포함되어 있다.

이런 정보를 가지고 분석하고자 하는 애플리케이션의 동작을 이해하는 것이다.

두 번째로 좋은 포인트는 바로 아래의 모습처럼 모바일 보안 솔루션에서 알려주는 탐지 문구이다.

다음 예시를 보자.

이름만 들어도 대부분이 알만한 애플리케이션을 루팅 된 단말기에서 실행하면 다음과 같은 문구를 볼 수 있다.

(물론 아래의 문구는 다른 단어로 대체한 것이다.)

따라서 많은 모의 해커들이 애플리케이션을 분석할 때 이런 탐지 문구가 보인다면

Decompile 툴을 이용하여 탐지 문구를 찾아서 해당 포인트부터 분석을 시작할 것이다.

이렇게 노출된다면 해당 애플리케이션을 분석하는 것은 시간문제이다.

따라서 많은 보안 솔루션들은 위의 탐지 로직의 문자열을 Decompile 툴에서 문자열 검색을 못하도록

난독화를 진행한다던지 암호화된 파일을 런타임 중 복호화하여 로딩하는

Dynamic Dex Loading 기법을 사용해 Decompile 툴에서 노출이 되지 않게 조치를 하고 있다.

아래의 예시가 암호화된 DEX 파일의 일부이다.

이는 한 모바일 보안 솔루션에서 Dynamic Dex Loading 기법으로 사용하고 있는 암호화된 DEX 파일이다.

이렇게 암호화된 것을 확인할 수 있다.

하지만 이를 런타임 중 확인을 해보면 다음과 같이 복호화 과정을 통해 원본의 파일을 얻을 수 있다.

또 다른 모바일 보안 솔루션에서는 assets 폴더 아래에 암호화된 파일을 활용하여 애플리케이션을 실행한다.

하지만 위의 작업을 통해 원본의 파일을 획득하기 위해 조금이라도 고민을 해보면 정말 귀찮은 작업이다.

모바일 보안 솔루션 마다 적용되어 있는 기법도 다르고, 실컷 분석하고 있는데

애플리케이션이 업데이트가 된다던지.. 정말 많은 노력과 시간이 필요하다.

따라서 이런 과정을 쉽게 하기 위해 해당 애플리케이션에서 실행하고 있는 모든 DEX를 빠르게 덤프하여

 Java단을 분석하고자 Utility 탭에 Dex Dump라는 버튼을 만들었다.

물론 그 유명한 Frida를 사용하면 되지만 Frida를 사용하여 DEX 파일을 덤프 할 시

대부분의 모바일 보안 솔루션에서는 이를 탐지하고 탐지 문구와 함께 분석하고 있는 애플리케이션을

종료시킬 것이다.

따라서 Frida는 사용하지 않고 해당 기능을 구현해 보았다.

DEX 파일을 덤프 하기 위해 Dex Dump를 클릭하면 현재 앱에서 동작하고 있는 애플리케이션을

다음과 같이 보여준다.

이렇게 현재 실행 중인 애플리케이션 목록을 확인한 후 분석하고자 하는 애플리케이션의

PID값을 입력한 후 Dump 버튼을 클릭하면 모든 DEX가 덤프 된다.

하지만, 모든 DEX를 덤프 하기 때문에 시간이 조금 걸리는 건지어디서 시간이 걸리는지

작성한 코드를 다시 살펴봐야 하지만 일단은 기능적인 측면에서는 잘 동작한다.

위에 보이는 모든 애플리케이션에서 잘 작동하였고 결과는 아래처럼 패키지명 아래에 저장된다.

끝으로 개인 연구 및 개발 목적이지

포스팅 내용 중 보이는 애플리케이션에 대한 악의적인 목적은 전혀 없다

먼저, 안드로이드에서 의미하는 System Property은 시스템의 설정값이라고 생각하면 된다.

즉, 시스템 속성(System Property)은 안드로이드 시스템의 설정과 관련된 정보를 포함하는 값이다.

이러한 속성은 안드로이드 운영 체제의 동작을 제어하고 구성하는 데 사용된다.

따라서 안드로이드 애플리케이션을 분석하다 보면 System Property를 수정해야 하는 경우가 생긴다.

만약 System Property를 수정해야하는 경우가 존재할 때 접두사가

ro. 또는 persist.로 되어 있는 속성을 수정할 것이다.

ro.으로 시작하는 것에 대해서 짧게 설명하면 다음과 같다.

이 접두사로 되어 있는 속성은 읽기 전용임을 나타낸다.

아래의 그림은 ro.debuggable이라는 속성값을 출력하는 모습이다.

즉, ro.로 시작하는 속성값은 속성을 읽을 수만 있고, 수정은 불가능하다.

아래의 그림을 보자.

위의 과정에서 setprop라는 명령어로 ro.debuggable를 수정하려고 했지만 수정할 수 없다.

다음은 persis.로 시작하는 속성값이 있다.

persist.으로 시작하는 속성은 영구적으로 저장되는 것을 나타낸다는 의미이다.

이 속성들은 장치가 재부팅되어도 유지되는 특성이 있다.

persist.로 이루어진 속성은 setprop라는 명령어로 값을 변경할 수 있지만 ro.로 시작하는 속성들은

읽기 전용이기 때문에 setprop 명령어로 값을 변경할 수 없다. 

따라서 System Property를 변경하기 위해서는 ro.로 시작하는 속성값들을 변경해주어야 한단 말이다.

하지만 이를 해결해 주는 툴이나 기술들은 많이 존재한다.

대표적으로 MagiskHidePropsConf 가 있다.

하지만 MagiskHidePropsConf를 사용하기 위해서는 Magisk 설치를 해야 한다.

Magisk 설치는 크게 어렵지는 않지만 Magisk를 설치한다면

루팅 탐지 등 모바일 보안 솔루션에 의해 탐지될 수 있다.

하지만 Magisk 없이 편하게 사용하고 싶어,

다음과 같이 Utility안에 System Property라는 버튼을 만들었다. 

Home 화면에서 System Property라는 버튼을 클릭하면 다음과 같이 현재 단말기에서의

System Property의 정보들을 먼저 확인할 수 있다.

그 후 변경하고 싶은 속성값을 위 검색란에 입력한 후 값을 변경한 후 저장을 클릭한다면

읽기 전용을 의미하는 ro.로 시작하는 속성값도 수정할 수 있다.

아래의 과정은 ro.debuggable에 대한 속성값을 변경하는 과정이다.

현재 Package 탭에 추가한 것은 2가지이다.

먼저 Packages List다.

Packages List는 현재 단말기에 설치된 패키지 리스트만 보여주는 창이다.

이는 분석하다가 Packges명을 빠르게 알아와야할때도 있고

어떤 애플리케이션이 설치되어있는지 확인이 필요할 때가 있다.

이때 빠르게 보기 위해서 만든 창이다.

두 번째는 Download APK이다.

분석을 하다가 APK를 단말기에서 추출해도 되지만 추출하다가 보면 잘 안 되는 경우도 있다.

잘 안되는 경우는 보통 단일 APK가 아닌 Bundle APK인 가능성이 매우 높아 이를 추출하는 과정과

다시 merge 과정에서 에러가 발생했을 가능성이 매우 높다.

위 작업을 하면 되긴 하지만.. 너무 귀찮은 작업이다.

위의 이유 때문에 단일로 APK 파일을 제공해 주는 사이트에서

APK를 다운로드 받아서 분석한 경험이 은근히 많이 있었다.

대표적으로 APK Pure, APK Combo 등의 사이트들이 있다.

따라서 분석하고자 하는 패키지 명을 입력하면 단일 APK를 다운로드 받는 APK Download 창을 만들었다.

위의 상황은 com.kakao.talk로 패키지명을 입력하였을 때 APK Combo와 APK Pure 사이트에서

입력한 패키지(com.kakao.talk)가 있는지 확인 한 후 존재한다면 APK Combo와 APK Pure 버튼과

입력창이 다시 활성화 된다.

그 후 원하는 APK Combo와 APK Pure에서 다운로드를 받으면 단일 APK를 다운로드 받을 수 있다.

다음 상황을 보자.

입력한 패키지 명은 com.elevenst.skpay이다.

이것도 첫 번째 상황과 마찬가지로 APK Combo와 APK Pure 사이트에서

입력한 패키지가 있는지 확인 확인 한다.

하지만 APK Combo 버튼 밖에 활성화되지 않았다.

이는 입력한 패키지 명에 대한 단일 APK가 APK Combo 사이트 밖에 없다는 의미이다.
따라서 APK Combo 버튼만 활성화된 것이다.

이렇게 하면 조금 더 쉽게 단일 APK를 다운로드 받을 수 있다.