rokefoke

1. 서론

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

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

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

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

2. 도구

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

3. 방법

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

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

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

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

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

실행중인 Activity를 notepad++로 확인하면 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 파일을 전달받은 상황에서의 진단이라서 생략할 수 있습니다.)

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

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

물론 다른 파일 백업 어플도 존재하지만 저 같은 경우는 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에서 하는 반면에 몇몇의 어플의 탐지는 백신을 통해서 하는 경우도 대부분입니다.

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

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

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

루팅 탐지를 우회시키는 방법 중 SU 탐지 우회는 Ctrl+F로 SU를 찾으면 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 파일을 리컴파일 해주고 루팅된 단말기에 설치하여 루팅 우회 여부를 확인한다.

1. 서론

진단 환경 구성을 말씀드려 보려고 합니다..

가장 먼저 시작하고 갔어야 하는 부분이었는데 지금에야 생각나서 올립니다.

환경 구성은 따로 없습니다만 각각의 툴들을 연결하기 편하고 더 빠르게 진단하기 위해서 준비해 놓는다면 부드럽게 진단하실 수 있을 것입니다.

저의 경우에는 쓰는 빈도가 많은 툴은 있지만 대부분 비슷하게 많이 쓰는 것 같습니다.

2. 필요 도구 및 프로그램

NOX(단말기 구성도 가능하지만 SSL Pinning과 같은 부분은 에뮬레이터가 편함),

ADB, 파이썬 2.7 버전, Astro(저는 이게 좋았습니다.),

APK easy tool (물론 dex2jar같은 툴들도 존재합니다.),

notepad++(smali파일 분석 시 가독성이 좋습니다.),

frida, frida-server, fridump

(도구 사용 방법은 순차적으로 글을 써서 올려드리겠습니다.)

3. 디바이스 구성 방법

Nox는 처음 설치하면 Android 5.1.1 버전의 가상 환경으로 만들어져 있습니다. Multi-drive를 이용해서 다수의 가상 환경을 만드는 것도 가능하며 Android 7 버전까지 만들 수 있습니다.

위 사진에서 많이 쓰게 될 부분은 root 켜기입니다. Android 진단에서 루팅이 된 단말기를 탐지하지 못하는 것은 많은 위협을 받을 수 있다는 말과 같습니다.

사용하는 부분은 루팅 우회를 시도할 경우 많이 쓰입니다.

최근의 어플은 서버와 통신을 통해 정보를 받아오는 경우가 많습니다.

이런 경우 IMEI와 번호가 설정되어 있지 않다면 접속할 수 없는 경우도 많습니다.

설명 링크: https://namu.wiki/w/IMEI

여기까지 구성을 하셨다면 환경설정을 들어가셔서 개발자 모드를 해제해주셔야 합니다.

빌드번호는 빠르게 연타 마구 눌러주시면 개발자 모드가 열렸다는 문구를 볼 수 있습니다.

위의 사진에 개발자 옵션이 열린 것이 보입니다.

개발자 옵션에서 USB 디버깅을 체크해 주시면 이제 설정 부분의 준비가 된 것입니다.

4. 윈도우 구성

윈도우 구성은 진단을 하기 위해 기본적은 환경설정을 해 놓아야 할 부분이 많습니다.

디바이스 연결 시 가장 많이 쓰이는 툴은 adb입니다. adb를 사용하기 위해 안드로이드 SDK를 설치해야 합니다. (adb 이외에도 많은 툴이 존재합니다.)

안드로이드 SDK는 현재 https://developer.android.com/studio에서 설치하실 수 있습니다.

또한 이를 사용하기 위해서는 JDK를 다운로드해야 하는데 https://library1008.tistory.com/19로 가시면 다운로드하는 방법이 자세하게 쓰여 있습니다.

이 툴을 설치했다면 이제 환경변수라는 것을 설정해주어야 합니다.

내 컴퓨터를 우 클릭하여 속성을 들어갑니다.

위와 같이 나오면 고급 시스템 설정을 들어간 후 환경설정으로 들어가 줍니다.

환경변수를 들어가면 위의 사진과 같이 뜨는데 아래의 목록에서 path를 찾아서 들어가면 됩니다.

위와 같이 떴다면 이제 환경변수를 새로 만들기로 추가해 줄 것인데 추가해줄 목록은 아래와 같습니다.

sdk : C:\Users\<윈도우 유저 명>\AppData\Local\Android\android-s아\platform-tools;

Python :　C:\Python27; C;\Python\Scripts;

자바는 path내에 추가해줄 부분과 path처럼 기본 환경변수로 새로 만들어 주어야 하는 것이 있습니다.

JAVA :　 1) JAVA_HOME : C:\Program Files\Java\jdk-<버전>;

2) Path :　%JAVA_HOME%\bin;

위와 같이 설정해 주시면서 JDK, Python2.7(3점대 버전이 깔려있으면 동작하지 않는 경우도 있음), Android SDK를 설치해줍니다.

이와 같이 다 설치해주시고 환경설정이 끝나셨다면 이제 제대로 깔렸는지 확인해 보면 됩니다.

crtl+r을 누르고 cmd창을 연 다음 adb, java -version을 넣어주면 제대로 설치된 것인지 확인이 가능합니다.

위와 같이 뜬다면 잘 설치해준 것입니다.

나머지는 설치 링크를 알려주겠습니다.

간단한 설치 파일로 구성되어 있으므로 어렵지 않게 설치하실 수 있을 것입니다.

APK easy tool :　https://forum.xda-developers.com/android/software-hacking/tool-apk-easy-tool-v1-02-windows-gui-t3333960

notepad++ :

https://notepad-plus-plus.org/downloads/v7.7.1/

Astro 어플 :

플레이 스토어에서 설치 가능

5. Frida

Frida의 경우 사용법도 다양하며 앞으로 여러 번 언급할 예정이기에 따로 글을 써서 설명할 예정입니다.

6. 후기

기본적인 환경 구성을 모르는 분들이 많은 관계로 이렇게 글을 올려봅니다.

누구든 처음 시작은 잘 모를 수 있지만 열심히 해서 보안 전문가가 됩시다!

1. 준비 도구

APK easy tool, astro 어플, ADB, 안드로이드 파일 관리자

2. 서론

일반적인 어플은 개발과정을 거치면서 개발자들의 부주의나 실수로 인해 testtest 하려 만들었던 activiti를 남겨놓는 경우가 많습니다.(개발자를 폄하하는 건 절대 아닙니다. 고생이 많은 것은 일하면서 많이 느낍니다.)

이런 경우 일반적으로 apk파일을 제공하지 않을 경우 추출하여 디컴파일을 거치면 드러나는 경우가 많습니다.(꼭 디컴파일하지 않고 찾는 방법도 존재)

3. 수행방법

우선 테스트하고자 하는 어플을 깔아 줍니다.(play store에 있다는 가정)

플레이 스토어의 어플을 astro어플을 이용하여 백업해주면 sdcard/backup 디렉터리에 apk파일이 남겨집니다.

이를 파일 관리자를 이용하여 mnt/shared/app 디렉터리에 옮겨줍니다.

그러면 윈도우의 C:\Users\<사용자 ID>\Nox_shared에 백업된 apk파일이 옮겨집니다.

만약 adb를 이용하여 앱을 추출한다면 adb pull을 이용하여 백업된 apk파일을 윈도우로 옮겨올 수 있습니다.

apk파일을 추출했다면 APK easy tool을 이용해 apk파일을 디컴파일 해줍니다. 여기에서 디컴파일을 하는 이유는 apk파일의 개발과정의 불필요한 파일을 찾아본 후 바로 smali파일 테스트를 하거나 manifest.xml파일 등을 점검하기 위해 바로 디컴파일 하는 것입니다.

또한 클래스 파일을 전부 점검하기 위해서는 디컴파일 하는 것을 추천합니다.

위와 같이 툴을 이용해 apk파일을 선택한 후 디컴파일 해줍니다. (APK easy tool사용법은 구글에도 많습니다.)

디컴파일이 완료되었다면 프로그램 하단의 Decompiled APK directory를 들어가면 디컴파일된 apk폴더를 확인할 수 있습니다.

이 폴더에 test와 같은 파일명을 검색해 주시면 됩니다.(다른 test삼아 썼을 것 같은 문구도 상관없습니다.)

여기까지 말씀드리면 ‘이게 무슨 취약점 점검이야!!!!’ 하시는!!!!’ 분들이 가끔 계신데 물론 어려운 방법으로 뚫는 것도 중요하고 그런 방법을 많이 쓰지만 이렇게 쉽게 뚫리는 것이 더 위험한 법입니다.

무튼! 이렇게 찾아서 파일명에 test와 같이 시범 삼아 만든 activity가 있다면 지금부터는 이 activity가 실제로 작동하는가를 알아보는 것이 중요합니다.

activity의 동작 여부를 확인하는 것에 있어 명령어는 am명령어를 쓰면 쉽게 알아볼 수 있습니다.

그에 앞서 am 명령어 즉 activity manager에 대해 간단한 사용법을 설명하겠습니다.

1) 많이 쓰는 am 명령어

- am start -a android.intent.action.MAIN -n 패키지명/액티비티 경로명

- am startservice -n 패키지명/서비스경로명

- adb shell am broadcast -a "브로드캐스트명"

위의 명령어를 통해 서비스 확인과 activity 실행 및 broadcast 테스트도 진행할 수 있습니다.

am 명령어는 adb를 설치하여 사용하실 수 있습니다.

2) 액티비티 실행하는 방법

adb shell am start -a android.intent.action.MAIN -n 패키지명/액티비티 경로명

하지만 여기에서 중요한 것은 위의 명령어를 줄여 사용할 수도 있습니다.

adb shell am start -n 패키지명/액티비티 경로명

이렇게 사용할 수도 있습니다.

3) 서비스 실행하는 방법

adb shell am startservice -n 패키지명/서비스 경로명

4) broadcast 테스트하기

adb shell am broadcast -a "브로드캐스트명"

5) 점검

adb shell am start -n 패키지명/액티비티 경로명

위의 명령어를 사용하여 어플 에뮬레이터 혹은 단말기에서 액티비티를 하나씩 실행시켜보시면 됩니다.

점검 중 test 액티비티나 불필요한 액티비티를 찾아 실행할 수 있다면 그것은 취약점으로 간주됩니다.

이유는 불필요한 액티비티에 보안 적용을 하지 않은 생태에서 provider노출이나 그에 따른 불완전한 퍼미션 적용이 이루어진 상태라면 공격자에 의해 정보를 갈취당할 가능성이 존재하기 때문에 이는 취약점으로 간주될 수 있습니다.

하지만 보안 적용을 모두 한 상태에서라도 저런 불필요한 페이지를 굳이 남겨놓을 필요는 없을 것입니다.