TEAMCR@K

[연구문서] 안드로이드 App Code Patch 기법

스마트폰 2011. 4. 7. 13:12 Posted by TEAMCR@K

본 문서는 안드로이드(Android) 기반에서의 APK 동적 디버깅 기법에 대해 작성하였습니다. 해당 내용은 아래와 같이 2개의 주제로 나눠 연재하겠습니다.

1. '안드로이드 기반 동적 디버깅 환경 구축'
2. '안드로이드 APP Code Patch 기법'

안드로이드 App Code Patch 기법

Android APP에서는 smali코드추출 후 수정과 새로운 코드의 첨부가 가능하여 APP의 기능 수정 및 첨부가 가능합니다. 이런 특징으로 인하여 genimi와 같이 타 APP에 악성 코드가 삽입되어 재 배포되는 악성코드가 발견되고 있습니다.
코드 패치 대상은 간단한 테트리스 게임이며, 게임을 위해 다음 블록이 내려 올 때 동일한 블록이 내려오도록 코드를 패치하는 것이 목표입니다.

1. Code Patch
코드 분석 결과 동일한 블록이 생성되도록 패치 해야 할 곳은 두 곳 입니다. 처음으로는 실제 블록이 발생하는 부분인 TetrisShape.java에서 spawn()함수입니다. 이 함수는 다음 전송되는 블록의 번호를 얻어 오며 그 결과를 v1레지스터에 반영하여 mNextType변수에 결과를 저장합니다.

다음은 TetrisShape.java에서 getNextType함수입니다. 이 함수는 다음 생성되는 블록의 그림값을 v0에 반영하여 NextType부분에 그려주어 게이머가 다음 블록을 예측하여 전략을 만들 수 있도록 합니다.

[그림 1] 다음 블록의 값을 얻어오는 부분

블록의 값을 확인해 보기 위하여 V0값을 2로 수정을 해봅니다. 그러면 에뮬레이터에서 [NEXT] 부분을 보면 다음 나올 블럭의 모양이 변경되는 것을 확인할 수 있습니다.

[그림 2] v0값 변경

[그림 3] v0값이 2일 때 블록 값

다음은 긴 막대기에 해당되는 v0값을 0으로 수정하였습니다.

[그림 4] v0값 0으로 수정

[그림 5] 다음 블록 값 확인

긴 막대의 값을 확인 한 결과 v0값이 0으로 항상 일정 하다면 항상 긴 막대의 그림으로 표시 될 것이므로, 이 부분을 패치 합니다.

[그림 6] 코드 패치

다음은 실제 생성되어 내려오는 블록의 값을 수정하는 부분입니다. NextInt()함수를 통해 다음 블록의 값을 얻어와 mNextType에 적용하는 부분으로 v1의 값이 항상 0으로 동일하다면 긴 막대가 내려 올 것이므로 이 부분을 패치 합니다.

[그림 7] v1값 동일하게 코드 패치

패치 결과 긴 막대만 나오는 것을 확인할 수 있습니다.

[그림 8] 에뮬레이터 결과

[그림 9] 막대기만 생성됨

지금까지 안드로이드(Android) 기반에서의 APK 동적 디버깅 기법을 통해서 정상적인 어플리케이션을 조작하는 (Code Patch) 것까지 알아보았습니다. 공격자는 이런 기법들을 통해서 안드로이드 마켓 or 블랙 마켓 등에 등록되어 있는 정상적인 App에 악의적인 코드 삽입을 할 수 있습니다.

사용자들은 의심되는 어플레케이션(App)은 설치 하지 않아야 하며, 스마트폰 백신을 통해 보안을 할 수 있도록 해야 합니다.

참고 자료
[1] http://code.google.com/p/android-apktool/wiki/SmaliDebugging
[2] http://www.youtube.com/watch?v=P_Zyf7jFbx4
[3] http://code.google.com/p/android-apktool/issues/detail?id=88&colspec=ID Stars Type Status Priority Milestone Owner Summary
[4] http://pastebin.com/ge39wRZS

저작자표시 비영리 변경금지

[연구 문서] 안드로이드 APK 동적 디버깅 환경 구축

스마트폰 2011. 4. 7. 11:36 Posted by TEAMCR@K

apk-sign.zip

apktool-install-windows-2.2_r01-3.tar.zip

본 문서는 안드로이드(Android) 기반에서의 APK 동적 디버깅 기법에 대해 작성하였습니다. 해당 내용은 아래와 같이 2개의 주제로 나눠 연재하겠습니다.

1. '안드로이드 기반 동적 디버깅 환경 구축'
2. '안드로이드 APP Code Patch 기법'

안드로이드 동적 디버깅 환경 구축

1. 디버깅 환경
Android 동적 디버깅 환경에서 필요한 Tool은 APKTools와 Netbeans IDE, Android개발환경, APK Sign환경이 구축되어 있어야 합니다. APKTools를 이용하여 APK파일을 디버그 모드로 디코딩 하면 Class단위로 java파일이 생성되며 java파일안에는 smali코드가 주석처리 되어 있습니다.
Netbeans는 IDE중 주석문에도 breakpoint를 설정할 수 있기 때문에 동적 디버깅 시 이용하며, APK Sign환경은 APK 수정 후 배포 전에 사인할 때 사용합니다.

동적 디버깅 시 필요한 Tool들의 역할입니다.

2.동적 디버깅 절차
동적 디버깅 절차는 다음과 같습니다.

1.   APK Tools를 이용하여 디버깅 모드로 덤프 (-d 옵션사용)
2.   APK Tools를 이용하여 디버깅 모드로 덤프한 것을 디버깅모드로 다시 패키징 (동적 디버깅을 위함)
3.   디버깅 모드로 패키징 한 APK파일을 sign하여 AVD에 실행
4.   Netbeans를 이용하여 1번에서 덤프했던 코드를 프로젝트 추가
5.   DDMS를 이용하여 대상 APP에 대한 포트를 열어줌.
6.   Netbeans 메뉴에서 Debug -> Attach Debugger -> Select JPDA 를 통해 host와 port를 설정하여 원격 디버깅 연결
7.   분석할 부분에 bp설정
8.   에뮬레이터에서 이벤트를 줘서 bp설정부분의 라인이 실행하게 유도
9.   Line by Line으로 동적 디버깅 시작

APK Tools를 이용하여 디버그모드로 APK파일을 디코딩 합니다. 디코딩 후 파일을 확인해 보면 확장자는 .java 이지만 파일의 내용에는 smali코드가 주석으로 처리 되어 있는 것을 확인 할 수 있습니다.

[그림 1] 디버그 모드로 디코딩

out폴더에 결과 파일들이 생성된 것을 확인 할 수 있으며, java파일이 생성되었지만 함수 몸체는 smali 코드로 구성되어 있는 것을 확인 할 수 있습니다.

[그림 2] 디코딩 결과

동적 디버깅을 위하여 디코딩 된 파일을 다시 디버깅 모드로 패키징 합니다.

[그림 3] 디버깅 모드로 패키징

패키징 결과 out폴더 및에 dist라는 폴더가 생성되며 그 안에 새로운 APK파일이 생성된 것을 확인 할 수 있습니다.

[그림 4] 패키징 결과

디버깅 모드로 패키징 된 APK파일을 설치하고 실행하기 위하여 APK Sign Tool을 이용하여 사인합니다.

[그림 5] 사인하기

사인이 완료되어 새로운 파일이 생성된 것을 확인 할 수 있습니다.

[그림 6] 사인 결과

사인이 완료 되면 AVD에 설치 후 실행합니다.

[그림 7] AVD에 설치(Install)

설치 후 실행하여 제대로 설치 되었는지 확인합니다.

[그림 8] AVD설치 확인

디버그 모드로 디코딩 된 파일을 Netbeans에서 프로젝트로 추가합니다. 프로젝트에 추가 할 시에는 메뉴아이콘에서 두 번째 위치한 버튼을 이용하여 프로젝트를 추가합니다. [New Project] -> [java] -> [Java Project with Existing Source]를 선택하여 Next를 클릭합니다.

[그림 9] New Project 선택

다음은 덤프 했었던 경로를 설정하여 Next를 클릭합니다.

[그림 10] 프로젝트 경로 설정

프로젝트 경로를 설정한 후 코드가 있는 경로를 설정하여 코드를 프로젝트에 추가합니다.

[그림 11] 소스코드 추가

프로젝트 추가 후 Android의 버전에 맞게 android.jar파일을 추가해 주어야 합니다. Android.jar파일은 Android관련 API를 호출 할 때 참조되는 Library이므로 꼭 추가가 필요합니다. 추가 시 실행하였던 AVD의 버전에 맞추어 추가를 합니다.

[그림 12] Library 추가

[그림 13] android.jar추가

android.jar와 코드를 프로젝트에 추가하였으니 제대로 추가되었는지 확인합니다.

[그림 14] 프로젝트 확인

DDMS에서 현재 동작하고 있는 APP중 방금 디버그 모드로 패킹되어 설치된 APP를 선택하여 열린 PORT번호를 확인합니다. 화면에서는 8700번이 open되 있는 것을 확인 할 수 있습니다.

[그림 15] 디버깅 대상 원격 포트확인

포트가 확인 되었으면 Netbeans에서 원격 디버깅을 위한 세팅을 합니다.

[그림 16] Attach Debbuger 메뉴 선택

[그림 17] JPDA선택

디버거 선택 후 host와 port정보를 설정해야 합니다. local에서 디버깅을 할 것이기 때문에 host에는 127.0.0.1, port에는 앞에서 확인한 8700으로 설정합니다.

[그림 18] 원격 디버깅 환경 설정

원격 디버깅을 위한 설정이 끝나면 디버깅관련 기능을 사용할 수 있습니다. 원격 디버깅을 위한 연결이 맺어 졌는 지 확인합니다. DDMS에서는 버그 모양이 앞에 표시 되며, Netbeans에서는 대상 프로그램을 pause시킬 수 있으므로 이 기능을 이용하여 연결이 정상적인지 확인 가능합니다.

[그림 19] DDMS에서 디버깅연결 확인

디버깅을 위한 연결이 맺어 졌기 때문에 bp설정을 하여 분석을 시작 할 수 있습니다. 다른 IDE같은 경우 주석문에 bp설정을 할 수 없지만 Netbeans에서는 Alt + Shift + F8번을 이용하여 line break point를 이용하여 bp 설정이 가능합니다.
원격 디버깅으로 중간에 디버거에 Attach 되었기 때문에 처음부터 프로그램의 분석이 필요하다면 bp를 첫 부분에 설정한 후 프로그램을 다시 시작하여 처음 부분부터 분석이 가능합니다.

[그림 20] break point 설정

[그림 21] break point 설정

이렇게 디버거 연결이 완료 됩니다.

이제 안드로이드 에물레이터에서 실행을 하면서 각 단계마다 변하는 값들을 조작할 수 있으며, 이 내용은 "제 2부 안드로이드 APP Code Patch" 를 통해 알아가도록 하겠습니다.

참고 자료
[1] http://code.google.com/p/android-apktool/wiki/SmaliDebugging
[2] http://www.youtube.com/watch?v=P_Zyf7jFbx4
[3] http://code.google.com/p/android-apktool/issues/detail?id=88&colspec=ID Stars Type Status Priority Milestone Owner Summary
[4] http://pastebin.com/ge39wRZS

저작자표시 비영리 변경금지

[연구 문서] iPhone 악성 코드 특징

스마트폰 2011. 4. 6. 21:21 Posted by TEAMCR@K

본 문서는 iPhone iOS 에서 발생되었던 악성코드(웜.바이러스 등) 대하여 작성하였습니다. 해당 내용은 아래와 같이 2개의 주제로 나눠 연재하겠습니다.

1. 'iOS 웜/바이러스/악성코드 특징'
2. 'SpyPhone 분석 및 응용'

iOS 웜/바이러스/악성코드 특징

1. exploit
가. Libtiff
2007년 7월, Tavis Ormandy에 의해 libtiff 에서의 여러 가지 buffer overflow를 이용한 최초의 Exploit이 발견되었습니다. 취약한 libtiff 버전은 Apple의 ImageIO framework에서 사용되는 것이었습니다. 악의적인 TIFF image를 간단히 열어봄으로써 악성코드가 실행되는 취약점 이었으며 Rik Farrow가 발표하였습니다. Apple 은 해당 취약점을 iPhone OS 1.1.2 에서 패치를 실시 하였습니다.

나. SMS fuzzing
2009년 7월, Black Hat USA 2009 에서 Charlie Miller와 Collin Mulliner 에 의해서 SMS fuzzing Exploit 발표되었습니다. 그들은 hacker가 악의적인 SMS message를 통하여 iphone의 통제권을 강탈하는 것을 발표하였습니다. 해당 취약점은 iPhone OS 3.0.1 에서 패치 되었습니다.

[그림 1] SMS Injector Model

[그림 2] iPhone lost its network connectivity and starts searching.

다. Directory traversal
2010년 말, 여러 hacker들에 의해 file server 기능을 가진 application 에서 사용자입력 값 검증 부족을 이용한 directory traversal이 가능한 Exploit들이 발견되었습니다. 해당 취약점을 이용하여 device 내의 전화번호부와 같은 database 정보를 획득 할 수 있었습니다.

[그림 3] 취약점이 존재하는 application

[그림 4] 전화번호부 열람

2. 개인정보 수집
가. Aurora Feint
2008년 7월, 인기 있었던 iPhone 게임인 Aurora Feint가 사생활 침해로 인하여 App Store에서 최초로 퇴출되었습니다. 해당 게임은 저장된 모든 접속 정보를 개발자의 서버로 업로드 하였습니다.

나. MogoRoad
2009년 8월, 많은 회사들로부터 스팸성 전화를 받은 사용자들의 항의로 인하여, 스위스 도로 정보 안내 application(전화번호 수집)이 AppStore에서 퇴출되었습니다.

다. Storm8 complaint
2009년 11월. 캘리포니아의 연방정부가 다운로드 회수가 2,000만 건을 초과한 게임 application 제작사인 Strom8을 대상으로 소송을 제기 하였습니다. 해당 게임은 사용자의 휴대전화 번호를 암호화를 거치지 않고 수집하였습니다. 그 후로 storm8의 게임들은 휴대전화 번호를 수집하지 않았습니다.

라. Pinch Media
Pinch Media는 많은 개발자로부터 사용되었던 무료 통계 프레임워크 입니다. 이것은 휴대전화에서 사용 데이터를 수집하였습니다. 2009년 7월, 몇 블로거들이 Pinch Media에 대해 관심을 가지기 시작하였고, 알림과 선택의 기회 없이 application 자체적으로 사용자들의 정보가 수집 된다는 것을 주장하였습니다. Pinch Media에 의하면 수집되는 정보는 다음과 같았습니다.

● 기기 고유 번호
● iPhone 과 iOS의 모델 정보
● application의 이름과 버전 정보
● jailbroken iphone임을 확인할 수 있는 결과 데이터
● application이 도둑 맞은 것인지 확인 할 수 있는 데이터
● application이 작동된 시간
● 사용자 동의 시, 사용자의 위치정보
● Application이 Facebook에 접근 시, 사용자의 성과 나이 정보

3. Worm on jailbroken device
2009년 11월부터, jailbroken iPhone들을 목표로 한 웜의 물결을 관찰 할 수 있었습니다. jailbroken iPhone의 경우, ssh서비스 실행 시 기본 계정(root, mobile)을 목표로 한 bot 의 침투로 기기의 ssh 서비스 차단 공격 및 공격자의 경유지가 될 수 있는 가능성이 존재합니다.

application을 다운로드 할 경우에도, AppStore를 통한 정식적인 서비스가 아니기 때문에 application의 무결성을 보장 할 수 없습니다.

가. Ikee
Ikee 는 최초의 iPhone 웜 이었습니다. jailbroken iPone에서 사용자가 ssh 기본 계정의 비밀번호(root/alpine)를 변경하지 않는 것을 이용하여 ssh접근 후 iPhone의 배경화면을 ‘Ikee is never gonna give you up’ 이라는 문구가 적힌 1980년대 가수인 Rick Astley의 사진으로 바꾸었습니다. 해당 웜은 호주의 21세의 청년에 의해 작성되었고, 청년은 그 후에 호주의 iPhone 개발 회사인 mogeneration에 입사했다고 전해집니다.

[그림 5] Ikee

나. Dutch 5 € ransom
‘Your iPhone`s been hacked because it`s really insecure! Please visit doiop.com/iHacked and secure ypur iPhone right now!’ 라는 사라지지 않는 경고 메시지를 사용자가 배포자의PayPal 계좌로 ransom 5€(8$)를 지불 할 때까지 유지 하도록 하는 웜이 배포되었습니다.

[그림 6] ransom

다. Ikee.B / Dutch
Ikee.B 웜은 매우 유해하였습니다. 전통적인 봇넷처럼 리투니아의 C&C서버에 접속하였습니다. 기본 root 비밀번호를 ‘oshit’으로 변경 후, 개인정보를 탈취와 타 호스트를 감염시키기 위한 시도를 하였습니다. 또한 해당 웜은 ING Direct 은행의 SMS를 이용한 두 가지 인증요소에 대해 exploit을 시도 하였습니다. 그리고 추후 POC-BBot과 같은 변종 bot의 형태로, 현재에도 jailbroken iPhone을 대상으로 공격을 시도 하고 있습니다.