1. 개요

어플의 통신을 프락시로 잡아 변조할 수 있는 것은 어플의 통신상 정보를 변조하거나 조작할 수 있으므로 방어해야 하는 부분 중 하나이다. 하지만 어플의 패킷이 BurpsuitFiddler로 잡히는 것을 대수롭지 않게 처리하는 곳이 많다. 오늘은 SSL Pinning의 방법 중 가장 간단한 인증서 설치를 이용한 SSL Pinning우회를 알아보도록 하겠습니다.

 

2. 준비

Fiddler 혹은 Burpsuit, Nox player

 

3. 방법

FiddlerBurpsuit 인터넷을 통해서 쉽게 다운로드할 수 있습니다. 그럼 순차적으로 Burpsuit, Fiddler의 프락시 설정을 순차적으로 설명하겠습니다.

 

1) Burpsuit

Burpsuit실행 후 프락시를 설정할 IP주소를 설정하여 줍니다. Proxy>Options에서 설정 값 클릭 후 왼쪽의 edit를 클릭하여 변경할 수 있습니다.

Specific address를 선택하여 프락시로 사용할 IP를 선택하여 줍니다. 여기에서 사용되는 특정 주소는 본인의 IP를 사용하는 경우가 대부분입니다.

 

여기까지가 PC에서 설정해 주어야 할 부분입니다.

 

SSL Pinning을 위해서는 WIFI환경을 필요로 하는데 이유는 디바이스의 프락시를 디바이스 내의 WIFI에서 직접 설정할 수 있으며 PC에 연결된 공유기를 통해 프락시 설정이 가능하기 때문입니다. 이는 iPhone에서도 과정이 흡사하니 참고 바랍니다..

 

단말기 내의 설정>WIFI>네트워크 수정에 보면 고급 옵션이 존재합니다.

프락시를 수동으로 선택하면 위와 비슷한 화면이 나타나게 됩니다.

이곳에 호스트와 포트를 Burpsuit에 설정해 주신 값과 동일하게 설정하여 주시면 됩니다.

 

여기까지 하면 프락시가 잡히는 것을 확인할 수 있지만 SSL/TLS연결의 경우는 잡더라도 해석이 불가능한 경우가 있습니다. 이를 위해 인증서를 설치하여 주는 과정을 거칩니다.

 

인터넷을 이용해 https://burp로 이동하면 위와 같은 화면이 나타나는데 오른쪽 위의 CA Certificate를 누르면 인증서를 다운로드하게 됩니다.

 

다운이 안 될 경우는 컴퓨터를 프락시에 연결하여 동일한 주소로 이동하면 같은 창을 확인할 수 있습니다.

처음 다운로드할 경우 위와 같이 확장자 명이 .der로 되어 있습니다. 이것을 .cer로 고쳐주어 디바이스에 넣거나 디바이스에서 다운로드하였을 경우는 파일 관리자에서 확장자를 바꾸어 주면 됩니다.

설정>보안>자격증명 저장소>SD카드에서 설치를 선택합니다.

인증서를 넣어둔 폴더에 가서 인증서를 선택하여 줍니다.(이미 확장자는 .cer로 바꾼 후입니다.)

인증서 이름을 입력한 후 확인을 누르면 인증서 설치가 끝납니다. 주의할 점은 만약 디바이스 잠금(비밀번호 잠금, 패턴 잠금 등)이 설정되어 있지 않으면 인증서 설치가 불가합니다.

 

2) Fiddler

FiddlerBurpsuit와 방법이 대부분 동일하지만 프락시 설정과 인증서 다운로드하는 방법이 다르므로 두 가지만 알려주도록 하겠습니다.

 

Tools>Options>HTTPS를 선택하면 Capture HTTPS CONNECTsDecrypt HTTPS traffic을 체크해 줍니다.

Connections탭에서 Fiddler listens on port를 설정해 줍니다. 대부분 8888을 많이 해줍니다.

이렇게 하면 모든 준비가 끝나지만 여기에서 단말기에 설정해주는 IP값이 다릅니다.

Fiddler 앱 내의 우측 상단에 보면 사진과 같은 게 보일 텐데 위에 마우스 포인터를 올려주면 설정할 IP값이 보입니다. 또한 PC 내부에서 CMDipconfig명령어를 통해 IP값을 알아내는 방법도 있습니다.

 

이후 WIFI를 설정해주는 방법은 동일합니다. 후에 인증서를 다운로드하는 것이 다릅니다.

http://ipv4.fiddler:8888 페이지

http://www.telerik.com/fiddler/add-ons

이 페이지에서 Certificate Maker plugin(CertMaker for iOS and Android)를 다운로드하여서 설치해 줍니다. Fiddler를 재시작해주고 디바이스의 프락시 설정을 모두 마친 뒤에 http://ipv4.fiddler:8888에 접속하여 FiddlerRoot certificate를 다운로드하여 줍니다.

이후의 인증서 설치 과정은Burpsuit와 같습니다.

1. 개요

Android 핸드폰을 점검하며 View 조작과 앱을 사용한 루팅 우회, 간단한 파일 바꾸기,, 간단한 Smali파일 변조 등 여러 가지 방법으로 점검을 해보았을 것입니다.

하지만 알기만 한다면 Android iOS에서 가장 많은 활용도를 보여주는 도구는 단연 Frida일 것입니다.

물론 제가 다 아는 것은 아니지만 아는 부분에 관해 풀어놓아 작은 도움이나마 되기 위해 시작해 보겠습니다.

 

2. 준비

Frida, Frida-server, 약간의 java혹은 C언어 다루는 능력? 다른 언어라도 쓸 수 있다면 형태를 맞추어 사용하셔도 무방합니다. Pyrhon 2.7 버전과 ADB툴도 필요합니다.

 

3. 방법

우선 FridaFrida-server를 다운로드하여주셔야 합니다.

여기에서 주의할 점은 Frida버전과 Frida-server버전 그리고 32bit 혹은 64bit를 맞추어 다운로드해야 합니다.

 

후선 FridaCMD창에서 pip install frida 명령으로 최신 버전을 다운로드할 수 있습니다.

 

 

저는 먼저 다운로드하여 놓았기 때문에 저렇게 뜨지만 처음 받는 화면은 조금 다를 겁니다.

여기에서 주의해야 할 부분은 아래 부분의 버전입니다. 보시는 바와 같이 버전은 12.7.16입니다. 이를 생각하고 이제 frida-server를 받아야 합니다..

 

https://github.com/frida/frida/releases

위의 링크로 들어가면 fridafrida에 관련된 여러 툴을 보실 수 있습니다. 여기에서 주의해야 할 부분은 본인이 사용하고 있는 디바이스가 32bit 혹은 64bit인지와 설치할 운영체제가 어떤 것 인지입니다. 또한 arm을 사용하는지 여부를 통해 본인의 OS에 깔린 Frida와 버전을 맞추어 깔아 주시면 됩니다.

 

정리 : frida 버전, OS 종류, 단말기 비트, arm 여부

 

 

Ctrl+F를 누르고 frida-server를 찾아주시면 목록으로 쉽게 오실 수 있습니다. 위의 frida버전과 사용하는 단말기인 NOX와 대조하여 저에게 필요한 것은 frida-server-12.7.16-android-arm.xz로 확인하였습니다.

 

이제 파일을 다운로드하여 주시고 압축을 풀어 줍니다.

 

 

위와 같이 다운로드하여 압축을 풀었지만 사용하세 편하도록 frida-server만 남기고 이름을 변경해 주었습니다.

 

Android는 리눅스 환경이고 이를 실행시켜주기 위해 frida의 확장자가 없어도 상관이 없으므로 이름을 변경하여 사용하게 편하게 만들어 주었습니다.

 

이제 ADB를 통해 /data/local/tmp로 옮겨 주어야 합니다.

 

(ADB 연결 방법은 일전에 알려주었으니 생략하도록 하겠습니다.)

 

새로운 CMD를 열고 frida-server의 위치로 가서 ADB를 통해 넣어주시거나 아니면 frida-server가 위치한 폴더에서 (shift + 우클릭)을 하면 목록에 powershell창 열기 혹은 명령어 창 열기가 생기는데 이것을 눌러 바로 CMD혹은 powershell을 열 수도 있습니다.

 

adb push <frida-server의 위치+/frida-server> /data/local/tmp

(: adb push C:\frida-server /data/local/tmp)

 

위의 명령어로 frida-server를 단말기 내부로 옮겨줍니다. (NOXADB가 붙지 않는다면 개발자 모드를 열고 USB 디버깅을 허가하여 주시면 됩니다. 또한 기존 실제 단말기가 위와 같이 했는데도 안 된다 하면 핸드폰 연결 종류를 충전이 아닌 사진 전송이나 파일 전송으로 바꾸어 주면 연결이 가능합니다.)

 

 

frida-server를 옮긴 폴더로 가서 chmod로 권한을 변경하여주고 ./frida-server &으로 frida-server를 실행해줍니다.

이제 frida를 사용할 준비가 끝났습니다.

 

frida가 잘 붙었는지와 frida-server가 정상적으로 작동하는지 확인하는 방법은 OS에서 frida-ps -U로 현재 단말기에서 구동 중인 process를 확인해보면 확인 가능합니다.

 

 

위와 같이 process가 확인이 된다면 frida를 사용할 준비가 된 것입니다.

 

frida의 활용은 앞으로 글을 통해 알려드리도록 하겠습니다.

 

 

1. 서론

앞서 올려드린 Smali파일 변조에서 디컴파일 부분과 SU파일 탐지에 관한 우회 방법을 설명해 드렸습니다.

 

하지만 어플을 개발하는 기술이 발전해 가면서 루팅을 탐지하는 방법도 바뀌어 갔습니다.

 

요즘은 대부분 디바이스 스캔을 하여 루팅을 탐지한 후 어플 변조 여부를 판단하여 어플이 실행되는 과정을 거칩니다.(전부 그런 것은 아닙니다.)

 

오늘 포스팅 할 내용은 SU파일 탐지가 아닌 루팅 스캔을 우회하고 어플 위변조 스캔을 우회하는 방법을 소개해 드리겠습니다.

 

2. 도구

앞에 올려드린 SU 탐지 우회의 환경과 같습니다.

 

3. 방법

말씀드리기에 앞서 어플을 디컴파일하는 과정과 이후의 과정은 동일한 과정을 반복하므로 생략하고 notepad++을 통한 코드 수정 부분만 포스틍하겠습니다.

 

디컴파일하고 난 후 ADB명령어를 어플 실행과 동시에 입력하여 실행중인 Activity의 위치를 알아냅니다.

 

실행시킬 명령어 : adb shell "dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'"

 

위의 명령어를 통해 현재 루팅을 탐지하고 있는 Activity를 찾을 수 있습니다.

 

어플의 루팅 탐지 방법은 어플을 개발하는 회사가 어떤 방식을 채택하냐 와 어떤 보안업체와 협업을 하는가에 따라 달자지지만 저는 제가 아는 부분에서 포스팅을 하는 것이니 이해해 주시기 바랍니다.

 

실행중인 Activitynotepad++로 확인하면 Main Activity인 경우들이 많지만 이들 중 Main Activity에서 직접 탐지하는 경우와 다른 하위 Activity로 연동하여 탐지하는 경우가 존재합니다.

 

Smali코드는 처음 보는 분들은 이해하기 어려우실 수도 있습니다. 하지만 아래의 방법만 따라하신다면 굳이 엄청 잘 알지 않더라도 우회가 충분히 가능합니다.

 

main Activity에서 직접 탐지하는 경우 main Activity에 탐지 코드가 남는 것은 당연할 것입니다. 하지만 이것을 찾는 것은 쉬운 일이 아닙니다. 저는 난독화 되어 알아보기 어려운 메소드의 경우에는 구획을 나누어 진행을 하고 메소드 명이 노출되어 있는 경우에는 직접 rooting, Changed, protect 등의 메소드와 실행 코드를 찾아 코드 변경을 진행합니다.

 

간혹 난독화를 하진 않았지만 실제 실행 코드가 아닌 더미코드를 집어 넣어놓은 경우도 존재합니다. 이러한 경우에 찾는 방법은 APK 파일을 동적 분석을 동해 알아내거나 코드를 읽어 찾아야 하지만 지금은 쉬운 방법을 설명드리고 차차 난이도를 높여가며 포스팅 해보도록하겠습니다. (저도 아직 공부해야할 부분이 많습니다.ㅠㅠ)

 

여기에서 어떤 부분을 어떻게 고치는 것인지 궁금해 하는 분들이 많으리라 생각됩니다.

의외로 코드를 변경하는 것은 매우 간단합니다.

 

if문에 따르는 eqz, nez ne, eq, l, g, t, e를 보신 적이 있으실 것이라 생각합니다.

앞에 말씀드린 것은 만약 같다면, 같지 않다면, 작다면, 크다면, 시작수를 포함하지 않고(미안, 초과), 시작수를 포함하고(이상, 이하)의 개념입니다. 아래에 간단하게 정리해 드리겠습니다.

 

eqz, eq => 같다, nez, ne => 같지 않다, lt => 미만, le => 이하, ge => 이상, gt =>초과

 

위의 방식은 매우 간단합니다.

 

만약 검증 코드를 찾은 부분의 if문이 ge(이상)로 탐지를 한다면 기존에 탐지하던 부분과 반대로 탐지하게 해야 루팅이 정상적인 동작으로 통과될 것이므로 lt(미만)로 고쳐주면 됩니다.

 

분명 다른 방법도 있습니다. 하지만 저로써는 이 방법이 가장 쉬웠습니다.

 

이러한 방식으로 코드를 변경해주고 저장하여 리컴파일 후 설치하여 실행시키는 과정을 방복하면 됩니다.

 

만약 루팅이 우회되었다면 표시되는 Alert창이 변경되거나 어플 변조에 관한 경고문이 발생될 것입니다.

 

어플이 변조되었다는 경고문을 보거나 루팅 우회가 된 것을 확인하셨다면 앞에 말씀드린 ADB코드를 다시 실행하여 어플변조 탐지코드를 찾아 변경해주시면 됩니다.

 

방법은 루팅 탐지코드 우회와 같은 방법으로 진행 해주시면 손쉽게 따라하실 수 있습니다.

 

만약 하위 Activity에서 탐지코드사 실행되는 경우는 메소드의 실행 경로와 동적분석을 통한 실행 경로를 찾아 주셔야하는데 이 부분은 올리디버거나 IDA, ,drozer 등 여러 어플를 활용하여 할 수 있습니다.

 

위의 방법은 나중에 따로 포스팅 해 드리도록 하겠습니다. 

 

※뽀나쓰※

뽀나쓰로 Android 어플의 위변조 테스트에 관해 말씀드리려고 합니다.

Android 어플의 위변조 테스트는 정~~~~~~~말 간!단!합니다.

필요한 어플은 HxD가 끝입니다.

HxD를 이용해 APK파일을 연 후 가운데 부분의 Hex값을 바꾸어 테스트하면 됩니다.

이 방법이 좀 싫거나 걸리시는 분은 앞에 Smali변조하여 리컴파일하여 앱이 정상적으로 설치 및 실행된다면 위변조 탐지를 하고 있지 않은 것입니다.

이방법으로 테스트 하면되고 이렇게 취약이라고 쓰는 것이 애매하다 생각한다면 Smali변조를 통해 루팅 우회가 성공했다면 덤으로 위변조 탐지로 하지않고 있는 앱이라는 것이 증명된것입니다. (smali파일을 변조하여 루팅을 우회했지만 정상적인 실행과 더불어 루팅 우회까지 성공한 경우이기 때문입니다.)

정말 간단한 방법이니 만약 확인해 보신다면 정말 쉽다고 느끼실 것입니다. (IOS 어플도 바이너리파일만 Hex값 바꾸어 넣는식으로 확인합니다.)

단! 어플의 마지막 부분의 0000000000으로 표기된  Hex값을 바꾸어 넣는 것은 검증범위 밖에 어플에 영향을 주지 않는부분일 수 있습니다.

1. 서론

Android 어플 진단에서 빠질 수 없는 부분이 smali파일 변조입니다.

smali파일 변조에는 여러 가지 방법도 있고 종류도 가지가지지만 간단한 몇 가지 방법들이 있습니다.

여기에서 다룰 주제는 루팅 탐지 우회이므로 SU파일 탐지 우회만을 다루도록 하겠습니다.

smali파일 말고도 xml파일도 있는데 간단한 용어 정리를 하고 넘어가도록 하겠습니다.

 

smali : smali‘An assembler/disassembler for Android's dex format’의 약자인데, DEX 바이너리를 사람이 읽을 수 있도록 쉽게 표현한 것입니다. C와 어셈블리어의 관계와 같다고 생각하면 됩니다.

 

xml : XML(Extensible Markup Language)W3C에서 개발된, 다른 특수한 목적을 갖는 마크업 언어를 만드는 경우에 사용하도록 권장하는 다목적 마크업 언어이다.

 

xml에 대한 자세한 성명을 아래의 링크를 들어가시면 확인할 수 있습니다.

링크 : https://ko.wikipedia.org/wiki/XML

 

2. 준비

기본적인 진단 환경(NOX, ADB, apk easy tool, notepad++이 설치된 환경), Astro어플, Android 파일 관리자

 

3. 방법

SU파일 탐지하는 방법으로는 여러 가지가 있겠지만 앞서 이를 진단할 수 있는 환경을 만들어 주는 것도 중요합니다.

 

우선 진단할 어플을 Nox에 설치해줍니다.(notepad++로 보기 전까지의 과정은 APKAPK 파일을 전달받은 상황에서의 진단이라서 생략할 수 있습니다.)

 

그런 후 루팅 탐지를 하는지 여부를 확인하기 위해 실행시켜줍니다.

 

만약 정상적인 루팅 탐지를 하고 있다면 지금부터 루팅 탐지 우회를 해봅시다. (물론,(물론 Noxroot 켜기를 체크한 상황이어야 합니다.)

 

물론 다른 파일 백업 어플도 존재하지만 저 같은 경우는 astro가 편해서 사용했습니다.

 

들어가면서 권한허용을 한 뒤 상단의 어플 탭을 눌러 들어가면 설치된 앱 들이 보일 것입니다.

 

그 중 진단하고자 하는 어플을 길게 누르면 왼쪽에 체크표시가 뜨고 우측 상단에 보면 점 세 개가 보일 텐데 그걸 누르면 백업 탭이 있습니다.

 

백업을 하고 나면 핸드폰 내에 백업 파일이 저장됩니다. 하지만 백업을 했다고 핸드폰 내에서 분석을 할 수 없으니 컴퓨터로 옮겨 줘야겠죠?

만약 단말기를 사용 중이라면 백업된 폴더에 가서 adb pull로 빼주시면 됩니다.

단말기의 백업파일 위치는 아래에 두겠습니다.

백업파일 위치 : /storage/emulated/legacy/backups/apps

위의 위치에 가면 백업 파일을 확일할 수 있습니다. adb를 이용하는 경우에는 바로 윈도우로 옮길 수 있지만 파일 관리자는 백업 파일을 옮겨주셔야 합니다.

 

파일관리자에서 해당 파일을 체크하고 옮길 디렉터리에서 붙이기를 하면 됩니다.

옮길 위치 : /mnt/shared/App

여기로 옮겨주시면 되는데 해당 디렉터리에 간 다음 Nox의 하단 좌측을 보면 점세개가 있습니다.

그 탬을 누르면 선택항목 이동이라는 탭을 누르면 해당 파일이 이동됩니다.

(여기에서의 실행환경은 Nox Android 5.1.1을 대상으로 하며 버전에 따라 다를 수 있습니다. 해당 업무는 꼭 root 켜기를 체크한 상태에서 진행해야 합니다.)

 

이렇게 하면 Nox의 백업파일이 윈도우로 옮겨집니다.

옮겨진 백업파일 위치 : C:\Users\<사용자 명>\Nox_share\AppShare

 

이전 글에서 말씀드린 바와 같이 옮겨진 백업 APK파일을 APK easy tool을 이용해 디컴파일 해주시면 됩니다. (디컴파일이 안되면 option/apktool에서 Don't decode resources.arsc를 체크해주시면 됩니다. 해당 설정은 리소스 파일을 디컴파일하지 않는다는 설정이고 해당 체크 시manifest.xml은 분석이 불가하니 참고하세요.)

 

여기에서부터 중요합니다.

 

여기부터는 루팅 체크를 어느 activity에서 하는지 확인하는 작업입니다.

 

우선 cmd 창을 켜고 abd연결을 해줍니다.

(앞에서 여러 번 adb연결을 설명했으니 참고하세요.)

그런 후 Nox에뮬레이터와 cmd창을 준비해 주시고 Nox 에뮬레이터에서 분석하려는 해당 어플을 실행하면서 아래의 명령어를 cmd창에서 실행해 주시면 됩니다.

 

실행시킬 명령어 : adb shell "dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'"

 

위의 명령어를 앱 실행과 동시에 실행시켜 주시면 현재 에뮬레이터에서 실행 중인 어플의 액티비티를 알 수 있습니다.

 

보통 어플의 Activity의 양이 어마어마하게 많은 반면에 이렇게 실행중인 Activity를 알 수 있다면 분석이 훨씬 수월할 수 있을 것입니다.

이렇게 현재 실행중인 어플의 액티비티의 위치를 알게 되었다면 notepad++로 분석하고 탐지하는 부분의 코드를 변경해 주시면 됩니다.

 

대부분의 SU 파일 탐지는 manifest.xml에서 하는 반면에 몇몇의 어플의 탐지는 백신을 통해서 하는 경우도 대부분입니다.

 

methodClass설명을 통해 말씀드리는 것도 중요하지만 실제 점검 방법에 치중을 두고 있으므로 생략하도록 하겠습니다.(앞으로 페이지를 추가하여 이론적인 설명을 할 예정입니다.)

 

찾는 방법은 여러 가지가 있지만 제가 애용하는 방법은 Ctrl+F입니다.

 

찾기에서 SU, Changed, Check 등과 같은 키워드를 찾아보시고 알맞은 부분을 찾아가 고쳐주기만 하면 됩니다.

 

루팅 탐지를 우회시키는 방법 중 SU 탐지 우회는 Ctrl+FSU를 찾으면 SU에 관한 탐지하는 코드를 찾을 수 있습니다.

 

대부분 이 코드를 이름을 바꾸어 저장하고 SU가 아닌 다른 파일을 탐지하게 함으로써 우회하는 방식을 사용합니다.

 

이러한 방식을 이용하면 쉽게 루팅을 우회시킬 수 있습니다.

 

이후 고친 코드를 저장해주고 APK easy tool을 활용해 리컴파일해줍니다.

 

코드를 무리하게 수정하면 어플의 코드가 비장상 적인 동작을 할 수 있으므로 문구를 탐지하는 부분만 수정하고 다른 부분은 최대한 건드리지 않는 것을 추천합니다.

 

또한 전에 APK 파일을 지정하여 디컴파일 하면서 자동으로 파일이 지정되었고 다른 APK파일을 디컴파일 하지 않았다면 바로 리컴파일 버튼을 눌러주면 바로 시행됩니다.

 

이후 리컴파일된 APK 파일을 루팅된 단말기에 설치하여 실행하면 루팅 우회 여부를 확인 할 수 있습니다.

 

만약 코드를 잘못 수정했거나 처음부터 다시 하고 싶다면 다시 디컴파일하면 바로 돌아옵니다. 

 

4. 요약

1) APK easy tool을 이용해 APK파일을 디컴파일한다.

2) 만약 나인패치 에러가 발생한다면 리소스 파일을 제외하고 디컴파일 해준다.

3) 앱을 실행시킴과 동시에 ADB코드를 실행시켜 루팅을 탐지하는 Activity를 찾아준다.

4) 해당 Activity와 Manifest.xml파일 내부에서 SU탐지 코드를 찾아 탐지하는 문구를 바꾸어 준다.

5) APK 파일을 리컴파일 해주고 루팅된 단말기에 설치하여 루팅 우회 여부를 확인한다.

+ Recent posts