onsoim의 연구 일지

아까 설명했듯이 엑티비티가 실행되면

처음에 onCreate 메소드가 호출됩니다.

 

onCreate 메소드가 길어서 일부만 가져왔습니다.

코드를 보면

저장된 인스턴스 상태를 가져오며

엑티비티 메인으로 값을 설정하는 등의 초기 설정을 합니다.

 

---

그다음으로는 onStart 메소드가 호출되어야 합니다.

하지만 onStart 메소드는 보이지 않습니다.

 

아마도 super 클래스의 메소드를 오버라이드 하지 않고

그냥 상속받아서 사용하는 것 같다고 추측하고 있지만,

정확히는 잘 모르겠습니다.

 

이런건 개발을 해보면서 배워야 하는데,

안 해봐서 잘 모르겠습니다.

 

이럴 경우에는 다시 onStart 메소드로 돌아가서,

onCreate 메소드에서 어떤 함수들을 호출하는지 확인해봐야 합니다.

 

---

onCreate 메소드의 마지막 부분을 확인해 보면,

com/kozhevin/rootchecks/util/CheckTask 엑티비티에서

init 메소드를 호출하고 execute 메소드를 호출합니다.

 

---

CheckTask 엑티비티에서 init 메소드부터 확인해 보면

중간에 asyncTask를 호출하는 부분이 있습니다.

 

네, 비동기로 뭔가를 하는 것 같습니다.

어플리케이션에서는 엑티비티간의 전환은 보이지 않았으므로

백그라운드로 작업을 하는 것 같습니다.

 

---

같은 엑티비티 내에서

백그라운드 작업을 하는

doInBackground 메소드입니다.

 

쭉 읽다가 보면

결과값이 비어있는 경우

MeatGrinder 엑티비티의 getInstance 메소드와

isLibraryLoaded 메소드를 호출합니다.

 

---

MeatGrinder의 isLibraryLoaded 메소드에서는

native-lib이라는 이름의 라이브러리를

로드하는 것을 확인할 수 있으며,

여러 메소드를 native 하게 로드하는 것을 확인할 수 있습니다.

 

---

해당 라이브러리를 ida로 열어보면,

어플리케이션에서 루팅을 확인하는

키워드들이 보이는 것을 확인할 수 있습니다.

 

---

자 이제부터가 드디어 본 주제였던

루팅을 탐지하는 방법에 대하여 이야기해보겠습니다.

 

안드로이드에서 루팅을 하게 된다면, 크게

- 루팅 하는 과정에서
- 루팅을 활용하는 과정에서

흔적이 발생합니다.

 

루팅을 탐지할 때는

기본적으로 이러한 흔적으로 루팅을 탐지합니다.

 

예를 들면 매번 루트의 권한을 획득하는 건 귀찮으니깐,

이 과정을 생략하기 위해 su 바이너리를 이용합니다.

하지만 이 바이너리의 존재로 루팅이 탐지될 수도 있습니다.

 

또한 루트 권한을 활용하는

다른 어플리케이션의 흔적으로

루팅이 되었는지 확인할 수 있습니다.

 

---

가장 처음으로는 build.prop 파일로

루팅이 되었는지를 확인할 수 있습니다.

 

이 build.prop 파일은 제조사에서 제품을 출시할 때

제품에 대한 정보나 build 정보 등을 포함하여 출시합니다.

 

그중에서 ro.build.tags 는

출시 당시에 'release-key'로 되어 있지만,

루팅 과정에서 test-keys 나 dev-keys 같은

다른 키로 변경되는 경우가 있으며,

이 키가 변경되었는지 확인을 통해

루팅을 탐지할 수 있습니다.

 

---

그 외에도

ro.debuggable, service.adb.root,

ro.secure, sys.initd, ro.build.selinux 등을

확인하여 루팅이 되어 있는지를

확인하기도 합니다.

 

---

아까 예를 들었던 su 바이너리를 통해서

루팅을 탐지할 수 있다는 것을 기억할 것입니다.

 

근데 혹시 이 su 바이너리가

정확히 뭐하는 바이너리인지 아시나요?

 

su는 switch user 즉 사용자를 변경하는 바이너리로,

인자 없이 단독으로 su가 오게 된다면

기본적으로 root로 인식하여

root로 사용자를 변경할 수 있습니다.

 

따라서 이 바이너리의 존재로 루팅을 탐지하기도 합니다.

 

---

그다음으로

또 su 바이너리를 찾는 것입니다.

 

오른쪽에 보이는 폴더들의 리스트에서 su 바이너리가 있는지 찾습니다.

 

---

아까 which su를 통해서도 su 바이너리를 찾았고,

방금 전에는 특정 폴더들에서 su 바이너리가 있는지 찾았습니다.

 

이 둘의 차이점은 무엇일까요?

 

---

차이점은 환경변수에서

PATH 변수에 등록된 주소에서 차이점이 있습니다.

 

which 명령어의 경우에는

이 PATH 변수에 등록된 환경변수에서

인자로 들어온 이름의 실행파일을 찾습니다.

 

즉 이 PATH 변수에 등록이 안된 경로에 대해서는,

which 명령어로 su 바이너리가 존재하는지 확인할 수 없습니다.

 

따라서 su 바이너리가 자주 있거나,

있을 가능성이 높은 폴더들에 대하여

추가로 확인을 하는 것입니다.

 

---

그다음으로는 Superuser.apk 어플리케이션의

유무를 확인합니다.

 

이 superuser.apk 는

다른 어플리케이션에서 su를 이용할 수 있는 권한을

관리해주는 어플리케이션으로,

이 어필리케이션에 접근할 수 있는지 확인하는 방식으로,

루팅을 탐지합니다.

 

---

그다음으로는 busybox의 존재로

루팅을 탐지할 수 있습니다.

 

안드로이드의 경우 리눅스를 기반으로 하여,

그 커널 위에서 동작하는 것은 다 들어보셨을 겁니다.

 

이렇게 리눅스 기반이기는 하지만 완전한 리눅스가 아니기에,

기존에 사용하던 여러 리눅스 명령어를 사용하지 못합니다.

 

따라서 이 busybox를 설치하여

여러 명령어를 사용할 수 있게 합니다.

 

busybox는 여러 스크립트 들을 포함하는 실행파일로,

이 busybox로 여러 명령어들을 대체하여

명령어들을 사용할 수 있는 것처럼 해줍니다.

 

---

다음은 xposed 관련 파일들로

루팅을 탐지할 수 있습니다.

 

xposed는 일종의 프레임워크로

여러 모듈을 적용하여

시스템이나 다른 응용프로그램의 동작을

변경할 수 있게 해 준다고 합니다.

 

저는 써본 적이 없어서 잘은 모르겠습니다.

 

---

앞에서 언급한 파일들 외에도

magisk 같은 루팅을 이용하는 파일들이

존재하는지 확인합니다.

 

---

또한 폴더의 권한으로

루팅 여부를 판단할 수 있습니다.

 

system 폴더를 예로 들어 설명하겠습니다.

system 폴더의 경우 기본적으로 읽기 전용 폴더로,

이는 root 권한으로도 수정할 수 없습니다.

 

이 안에 있는 파일들을 수정하기 위해서는

system 폴더를 remount 하여야 하는데,

이러한 폴더 권한의 변경으로

루팅을 탐지하는 경우도 있습니다.

 

---

마지막으로 후킹을 탐지하는 방법입니다.

 

후킹이란 프로그램에서 함수, 이벤트, 메시지 등이 호출될 때,

이를 중간에서 낚아채가는 것을 말합니다.

 

이 안드로이드에서 후킹 하는 것에 관련된 부분은

주성이가 더 잘 설명해 줄 것이라 믿고,

저는 후킹으로 뭘 할 수 있는지

정도만 보여드리겠습니다.

 

---

* 해당 슬라이드의 사진 부분은 공개할 수 없습니다.

 

이것은 어느 메신저에서

자체 프로토콜을 빌드하는 부분의

결과 값을 후킹 한 것입니다.

 

전에 상섭이형 발표에서는

치트엔진으로 하셨다고 들은 것 같은데,

이렇게 프리다로 후킹을 해서도

그 내용을 확인할 수도 있습니다.

 

---

과제라고는 하는데 그냥 선택사항입니다.

 

첫 번째 과제는 오늘 native root checker에서

루팅을 탐지하는 방법을 소개했는데,

이를 참고하여 루팅 탐지를

우회하는 스크립트를 작성하는 것입니다.

 

두 번째 과제는

오늘 소개한 루팅 탐지 방법 외에도

여러 창의적인 방법들이 존재하는데

그중 하나를 찾아 정리해 보고,

그것은 어떤 식으로 탐지를 하는 건지

공부해 보는 것입니다.

 

할 사람들은 기한 없이 하시면서 질문 주시면 되고,

제출은 onsoim@gmail.com으로 보내주시고 알려주시면 됩니다.

 

---

그리고 안드로이드 쪽 공부를 한다면 도움이 될 자료들입니다.

 

첫 번째는 아시는 분은 아는 그 발표자료입니다.

물론 내용은 좀 삭제되어 있지만

난독화 쪽으로 흥미로운 내용을

많이 포함하고 있습니다.
한번 쭉 보시고, 나중에 더 공부하고 다시 보셔도 좋을 것 같습니다.

 

두 번째는 아까 간략하게 설명한 엑티비티 라이프사이클에 관한 자료입니다.

정리가 아주 잘 되어 있습니다.

 

이상으로 끝내겠습니다. 감사합니다.

원래는 nox로 환경을 맞춰서 같이 해보려고 했지만,,,

 

애플의 보안 정책으로 nox를 사용할 수가 없어서,

제가 해온 것으로 대체하여 진행하겠습니다. ㅜ

 

---

분석을 하려면 제일 먼저 apk부터 구해야 합니다.

 

apk를 구하는 방법으로는 playstore에서 설치 후 추출하거나,

apkpure.com에서 검색을 해서 받는 방법이 있습니다.

 

---

playstore을 통해 설치한 apk를 추출하는 방법입니다.

 

제일 먼저 해야 할건 뭘까요?

바로 어플리케이션을 설치하는 것입니다.

 

그다음으로 해야 할 것들이 추출을 위하여

노트북과 안드로이드 장치를 adb로 연결하고,

추출할 패키지의 이름을 확인한 뒤

해당 패키지를 추출하면 끝납니다.

 

---

adb 로 안드로이드 장치에 연결하는 방법입니다.

에뮬레이터의 경우 각 에뮬레이터 별로 사용하는 adb 포트로 접속을 하고,
실제 기기의 경우에는 개발자 옵션 중 하나인 usb 디버깅을 허용해주면 됩니다.

 

[*] nox : 62001

 

---

패키지의 목록은 pm list packages -f로 확인할 수 있으며,

설치된 패키지가 많을 경우에는 찾기가 힘들기에,

적당히 grep으로 추려서 확인하시면 됩니다.

 

---

추출할 패키지의 이름을 확인했다면,

pull 옵션으로 해당 apk를 추출할 수 있습니다.

 

반대로 adb로 apk를 설치할 수도 있습니다.

adb의 옵션으로 install을 주면 apk를 설치할 수 있으며,

-r 옵션을 추가로 주는 경우에는 이미 존재하는 패키지를 재설치할 수 있습니다.

 

하지만 기존에 설치된 서명과 설치하고자 하는 서명이 다른 경우에는

다른 패키지로 인식하여 재설치할 수 없습니다.

그런 경우에는 기존에 충돌되는 패키지를 삭제하고, 설치를 진행해야 합니다.

 

---

지금까지 사용한 adb 명령어들입니다.

 

---

apkpure.com 에서 apk를 구하는 방법은 간단합니다.

apk 이름만 검색하면 쉽게 다운받을 수 있습니다. 참 쉽쥬 ~?

 

---

자 이제 apk 를 구했으니 본격적으로 분석을 시작해 봅니다.

apk의 디코드와 빌드는 apktool을 이용할 수 있습니다.

 

apktool의 옵션으로

d를 주면 디코드 되며,

b를 주면 빌드되어 dist 폴더에서 확인할 수 있습니다.

 

---

루팅 탐지 루틴을 분석하기 위하여

안드로이드 어플리케이션을 분석할 수 있는 방법을 2가지 정도 소개하겠습니다.

 

물론 정해진 분석 방법은 없으며,

맞는 방법이 아닐 수도 있습니다.

본인이 편한 방법으로 분석을 진행하면 됩니다.

 

방법은 크게 Top-down 방식과 Bottom-up 방식이 있습니다.

쉽게 이야기하자면 위에서부터 아래로, 아래에서부터 위로 분석하는 방식입니다.

 

예제를 들며 설명을 하면 이해하기 편할 것 같아서,

native root checker를 대상으로 분석하면서 설명하겠습니다.

 

우선 이 어플을 선택한 이유는

native 하게 루팅을 탐지해서

조금 뒤에서 루팅 탐지 방법을 설명할 때,

익숙하지 않은 달빅 바이트코드보다는

cpp 코드가 더 이해하기 쉬울 것 같아서 골랐습니다.

 

---

Top에서 내려가는 방식보다

Bottom에서 올라가는 것이 더 간단하기에 이것부터 설명하겠습니다.

 

Bottom-up 분석 방식은 끝에서부터 원하는 분석 부분까지 올라가는 방식입니다.

 

---

분석을 하기에 가장 먼저 찾아야 할 것은 시작점을 찾는 것입니다.

여러 방법 중에서 가장 쉽다고 생각하는 방법을 하나 소개하겠습니다.

다시 한번 말하지만 분석 방법에 있어 항상 정답은 없습니다.

 

어플리케이션을 실행시켜 보면 각 항목 별로 탐지 결과를 보여주는데,

이 항목들은 문자열로 처리를 했을 것이다라고 가정을 하고 시작합니다.

 

그래서 확인 차 TEST KEYS를 검색해 보니,

strings.xml 파일에서 확인을 할 수 있습니다.

 

---

strings.xml 은 다국적의 언어를 처리하기 쉽게 하기 위한 용도의 파일로,

사용자가 선택한 언어에 따라 문자열을 동일한 name으로 처리할 수 있습니다.

 

---

이전에 strings.xml 에서 찾은 name을 검색해 보면,

public.xml에서도 사용된 것을 확인할 수 있습니다.

 

strings.xml 이 변수명과 그 값을 저장한 파일이라면,

public.xml 은 변수명과 변수의 주소를 저장한 파일입니다.

 

---

마지막으로 이 주소를 검색해 보면,

달빅 코드 내부에서는 이 주소를 이용하는 것을 확인할 수 있습니다.

 

아직 분석은 안 했지만 뭔가 감이 오는 switch 문이 보입니다.

이런 식으로 문자열을 기준으로 하여,

분석 지점을 쉽게 파악할 수 있습니다.

 

---

하지만 몇 번 말했듯이 이 방법도 정답이 아닐 수도 있습니다.

이것처럼 잘못된 시작은 삽질의 시작이 될 수도 있습니다.

 

루팅 탐지의 결과를 알려주는 맨 하단부의 초록색 창이

문자열일 것이라고 생각하고 진행을 한다면,

그 문자열은 찾지 못할 것입니다.

왜냐하면 이 문자열은 사진(png)으로 처리되어 있기 때문입니다.

 

그래서 저 같은 경우에는 이렇게 몇 개 해보고 안되면,

Top-down 방식으로 다시 분석을 합니다.

 

---

그다음으로는 Top-down 분석법입니다.

 

위에서부터 아래로, 큰 범주에서 목표를 향해 분석하는 방식입니다.

 

---

마찬가지로 Top-down 분석을 시작하려면 분석을 할 시작점부터 찾아야 합니다.

 

apk의 경우 그 시작점은 메인 엑티비티로,

메인 엑티비티는 apk 파일 내의

안드로이드 메니페스트 파일에서 확인할 수 있습니다.

 

---

이 사진은 메인 엑티비티에 해당하는 엑티비티입니다.

 

그다음은 어디를 봐야 할까요?

그것을 알려면 안드로이드 라이프사이클에 대하여 알아야 합니다.

 

---

안드로이드 라이프 사이클이라고 부르는 관계도입니다.

정확히 말하면 엑티비티 라이프 사이클입니다.

안드로이드 어플리케이션에는 여러 엑티비티가 있고,

이들 중 하나의 엑티비티가 실행되고 소멸하기까지의 관계도를 도식화한 것이 엑티비티 라이프 사이클입니다.

 

그렇다면 이 엑티비티 라이프사이클은 왜 중요할까요?

안드로이드의 경우 PC 와는 다르게 제한된 환경으로,

정해진 양의 자원을 여러 어플리케이션에서 나눠서 사용해야 합니다.

따라서 각 어플리케이션 별로 사용하는 자원을 효율적으로 관리하기 위하여 나온 것이 라이프 사이클입니다.

어디서 어떻게 사용할지 알아야,

자원을 같이 사용할 수 있는 거죠.

 

처음에 엑티비티가 호출되면 시스템에서 가장 먼저 호출하는 메소드가

onCreate( ) 메소드입니다.

onCreate( ) 메소드는 엑티비티가 처음 생성될 당시 한 번만 호출되며,

데이터를 초기화하는 단계입니다.
파라미터로 넘어온 데이터를 바인딩하거나

이전에 저장된 instance의 값 등을 불러오는 역할을 합니다.

 

onStart( ) 메소드에서는

본격적으로 엑티비티와 사용자가 상호작용 할 수 있도록 준비하는 단계입니다.

예를 들면 UI를 관리하는 코드를 초기화하여,

엑티비티를 포그라운드로 보내 상호작용을 할 수 있도록 합니다.

 

onResume( ) 메소드에서는 엑티비티를 화면에 보여주면서,

사용자와 상호작용을 하는 단계입니다.

사용자와 상호작용을 하며 엑티비티가 실행되며,

별도의 이벤트가 있기 전까지 이 상태에 머무릅니다.

 

onPause( ) 메소드는 다른 엑티비티가 호출되어,

잠시 멈출 때 호출됩니다.

화면에서 뒤에 흐리게 되어 존재는 하지만,

상호작용을 할 수 없는 상태입니다.

예를 들면 게임에서 일시정지 버튼을 눌러,

게임 관련 엑티비티가 멈춘 상태입니다.

 

onStop( ) 메소드는 엑티비티가 화면에서 사라질 때 호출되며,

필수로 저장해야 하는 데이터 등을 저장합니다.

예를 들면 게임을 하고 있는데 전화가 온다면,

화면이 변경됨과 동시에

시스템에서 게임의 엑티비티에 onStop( ) 메소드를 콜백 합니다.

 

그 후 게임으로 다시 돌아가게 된다면,

onRestart( ) 메소드를 호출하여

엑티비티의 onStart( ) 메소드를 호출할 수 있게 준비합니다.

 

마지막으로 onDestroy( ) 메소드에서는 onCreate( ) 메소드에서 할당했던 변수 등을 해제하며,

엑티비티를 정리합니다.

 

짝을 지어 보자면

onCreate( ) 메소드와 onDestory( ) 메소드가 대치되며,

nStart( ) 메소드와 onStop( ) 메소드와 대치됩니다.

 

마지막으로 정리해보면

처음 엑티비티가 호출되면,

onCreate -> onStart -> onResume 메소드를 거치며 엑티비티가 실행되며,

사용자와 상호작용하다가

특별한 이벤트가 발생하면 onPause 메소드가 로 호출되어 일시 정지되며,

사용자의 중지 요청 등으로 onStop 메소드가 호출되며,

onDestroy 메소드를 거쳐 엑티비티가 종료합니다.

 

네 그러면 native root check 어플리케이션을 이 라이프 사이클에 맞춰서 분석해 보겠습니다.

오늘 제가 발표할 주제는 안드로이드 101입니다.

원래는 안드로이드 어플리케이션에서 어떻게 루팅을 탐지하는지에 대해서만 발표하려고 하였으나,
처음 안드로이드 공부할 때 많이 막막했던 것이 생각나기도 하고,
처음 하는 분들에게 조금이라도 도움을 드릴수 있고자 안드로이드에 대한 기본적인 내용을 추가하고,
루팅 탐지 부분의 비중을 낮춰서 안드로이드 101으로 발표 주제를 정했습니다.

 

---

목차는 크게 다음과 같습니다.

 - APK에 대한 기본적인 지식들

 - APK 분석 방법

 - 루팅 탐지 방법

 

---

아시다시피 요즘 날의 모바일 어플리케이션 생태계는 크게 안드로이드와 iOS로 나눌 수 있습니다.

그중에서 non-native code 인 달빅 바이트 코드를 사용하며,
상대적으로 디버깅하기 쉬운 안드로이드 어플리케이션에 대하여 이야기해보려고 합니다.

 

---

앞에서 non-native code에 대하여 언급했는데,
조금은 헷갈릴 수 있는 개념이라 간단하게 정리하고 넘어가겠습니다.
정확하게 까지는 아니더라도 대충 native 한 게 어떤 느낌인지 정도만 아셔도 괜찮을 것 같습니다.

 

우선은 managed code입니다.

 

이 managed code는 microsoft에서 2003년에 비주얼 스튜디오 2003을 출시하면서 발표한 개념입니다.
마이크로소프트 사의 C#이나 VB .NET 이 managed code에 포함되며,
그리고 많이들 사용하는 Python, Java 등도 여기에 포함됩니다.

 

소스코드가 실행되기까지의 과정에 대하여 간단하게 이야기해보면,
사용자가 작성한 소스코드는 IL 즉 중간 언어로 컴파일되는데,
이 IL 은 어셈블리어 정도로 생각하시면 될 것 같습니다.
그 후 IL 파일이 정상인지 확인한 후 runtime에 사용되는 메소드를 호출합니다.

 

이 지터에서 runtime 시에 사용되는 메모리나 예외 등을 처리해주기 때문에,
파이썬처럼 변수를 따로 할당하지 않아도 알아서 메모리를 할당해 주고 해제해줍니다.

 

다음으로는 unmanaged code입니다.

 

managed code에 반대되는 개념으로 예전부터 있던 전통적인 C 등이 여기에 포함됩니다.

 

소스코드는 각 환경에 맞게 바로 컴파일되어 기계어로 된 프로그램의 형식으로 실행되며,
C언어를 하면서 많이들 느꼈겠지만 필요한 메모리를 직접 할당(malloc) 및 해제를 해줘야 합니다.

 

참고로 알고리즘 할 때 많이 사용되는 C++ 은 managed code 가 될 수도, unmanaged code 가 될 수도 있습니다.

 

마지막으로 좀 모호하다고 생각되는 native code입니다.

 

보통은 native code를 unmanaged code의 동의어의 일종으로 생각해서,
크게 managed code와 native code로 나누기도 합니다.
이전 슬라이드에서 말한 것처럼 native code와 non-native code로 나눈 것처럼 말이죠.

하지만 native code는 unmanaged code 일 수도,
managed code의 산출물인 machine code 인 기계어도 될 수 있습니다.

 

이 부분에 대해서는 pwnwiz 님이 더 잘 아시니,
잘 모르겠다 싶은 것은 pwnwiz 님께 질문하면 잘 알려주실 겁니다.

 

---

apk 해킹? 이 맞는 말인지 모르겠지만,
apk 해킹에서 제가 가장 중요하다고 생각하는 것은

리패키징 방지 우회 및 루팅 탐지를 우회하는 것이라고 생각합니다.

 

왜냐하면 리패키징 방지와 루팅 탐지 2개에서 자유롭다면 분석의 난이도는 다르지만,
그래도 코드를 변조해서 무엇인가는 할 수 있기 때문입니다.

 

---

안드로이드 어플리케이션인 apk의 경우 iOS 어플리케이션인 ipa에 비하여 단순한 zip 구조로 구성되어 있으며,
별다른 절차(루팅) 없이도 개발자 도구 중 하나인 usb 디버깅 모드로 apk의 설치 및 삭제가 가능합니다.

 

그래서 사용자는 설치된 apk를 추출하거나 외부에서 apk를 구하여,
수정한 후 리패키징하여 다시 설치할 수 있습니다.

이렇게 되면 악의적인 사용자는 apk를 수정하여하고 싶은 것을 할 수 있게 됩니다.

 

---

apk의 구조를 조금 더 자세히 보자면,

소스코드는 dex 파일로 컴파일되며
여기에 apk에서 사용할 여러 리소스 파일들과 네이티브 코드들을 압축하여

apk를 생성합니다.

 

이 apk를 설치하면,

반대로 압축을 풀면서 설치가 되고 달빅이가 바이트코드를 해석하고 실행이 됩니다.

 

---

앞에서 말한 바와 같이 apk 해킹하는데 첫 번째로 중요하다고 생각하는 리패키징 방지입니다.

 

리패키징 과정은 apk 만드는 과정을 거꾸로 포함하고 있습니다.

정상적이라면 소스코드에서 컴파일을 한 후,
패키징 과정을 거친 후에 서명을 하고 배포를 합니다.

하지만 리패키징 과정은 apk를 언패킹 해서,
디컴파일을 거쳐 소스코드를 획득하고,
수정을 한 후에 다시 apk를 만듭니다.

 

따라서 이렇게 리패키징을 통해 소스코드를 수정할 가능성이 있기 때문에,
apk 가 리패키징되지 못하도록 방지해야 합니다.

 

---

이름은 밝힐 수 없는 한 게임이 있습니다.
물론 이 게임에서도 여러 보안 방식들로 자사의 어플리케이션을 보호하고 있습니다.

하지만 이렇게도 할 수 있다는 것을 보면서,
리패키징 방지의 중요성을 한번 더 생각해 봤으면 좋겠습니다.

 

우선 이러한 짓을 한 개요는 다음과 같습니다.
게임을 플레이하는 게 귀찮아서

“한 가지 색상으로만 나온다면 가만히 있어도 편하게 게임을 끝낼 수 있지 않을까?"

라는 생각으로,
파란색 캔디만 생성되도록 바꿔 보았습니다.
하지만 당연히 끝날 거라 생각했던 게임은 끝나지가 않았습니다,,

 

---

그다음으로 두 번째로 중요하다고 생각하는 루팅 탐지입니다.

 

여기서 루팅이란 정확히 뭘 말하는 것일까요?
루팅이란 최고 권한인 root를 획득하는 것을 말하며,
안드로이드 운영체제에서는 최고 권한인 superuser 권한을 획득하는 것을 말합니다.

이 권한으로는 일반적으로 할 수 없는 것들을 할 수 있게 해 줍니다.

예를 들면 접근이 불가능한 시스템 폴더 같은 곳에 접근해서 삭제 불가능한 좀비 어플을 삭제하거나,
어플리케이션이 사용하는 메모리에 접근해서 수정하는 것이 가능합니다.

 

---

초등학교, 중학교 때 게임을 많이 해보신 분들은 한 번은 써봤을 러키패처와 치트엔진입니다.

일반적으로 안드로이드에서는 각 어플리케이션별로 uid를 생성하고 각 uid 별로 관리되지만,
이 어플리케이션들은 루팅을 이용하여 다른 프로세스에서 사용하는 메모리를 수정할 수 있게 해 줍니다.

 

따라서 메모리 무결성 등이 중요한 금융이나 게임 어플리케이션의 경우 루팅이 되어 있는지를 확인해야 합니다.

 

---

앞에서 소개한 루팅을 탐지하는 것과 리패키징을 방지하는 것 외에도 여러 보호 기법들이 있습니다.

이 중에서 제가 가장 싫어하는 보호 기법을 하나 보여 드리면서 넘어가도록 하겠습니다.

 

---

이 어플리케이션은 제가 분석하면서 제일 싫었던 어플리케이션 이였습니다.

 

중간에 보면 메소드들이 a.a.a으로 되어 있는데 다시는 만나고 싶지 않은 친구입니다.

 

그러면 오늘의 진짜 주제였던 안드로이드에서 루팅 탐지 방법에 대하여 소개하겠습니다.