메모리 보호기법 우회 -3- SEH Overwrite

S/W 역공학 분석(Reversing) 2011. 5. 22. 02:37 Posted by 알 수 없는 사용자
 

메모리 보호기법 우회 연구분석보고서 -3-


By. eloi@a3sc.co.kr
(A.K.A eloi)

jtsong@a3sc.co.kr
(A.K.A trynerr)


본 문서는 Stack Overflow 보호기법과 이를 우회하는 방법에 대하여 작성하였습니다. 해당 내용과 테스트 결과가 많은 관계로아래와 같은 주제로 3회에 걸쳐 연재합니다.
 

1. 'Windows/Linux 환경에서의 Stack Overflow 보호기법'
2. 'ROP(Return Oriented Programming) Exploit'
3. 'SEH(Structed Exception Handling) Overwrite' 




SEH(Structed Exception Handling) Overwrite

1. GS 우회 가능성
GS 옵션으로 컴파일 , 스택상으론 cookie변수가 buf변수 다음 위치하게 됩니다. 따라서 공격자가 BOF 공격시 스택내에 존재하는 cookie 값을 변조하기 때문에 프로그램은 .data 영역에 있는 cookie 값과의 비교를 통하여 비교결과를 통하여 BOF 공격을 감지합니다. 하지만 .data 영역은 쓰기 권한이 있는 영역이기 때문에 RET 앞에 존재하는 cookie 값과 .data 영역에 존재하는 cookie 값을 동일한 값으로 덮어쓰게된다면 우회가 가능합니다.

다음
화면은 GS cookie 테스트 검증을 하기 위해 Window XP SP1, Visual Studio .NET 2003 상에서 BOF 공격에 취약한 소스에서 GS 옵션만 설정한 , 컴파일 화면입니다.

[그림 1] GS 옵션 설정


 

[그림 2] BOF 취약한 소스코드

 

다음 화면은 해당 프로그램을 디스어셈블리 , security cookie 확인하는 화면입니다. Cookie 값이 설정 , ebp-4 부분에 복사되는 것을 확인 있습니다. 이는 Buffer RET 사이에 cookie 존재한다는 것을 의미합니다.

[그림 3] cookie 확인

 

다음 화면은 프로그램 상에서 인자값을 “1234567890ABCDEF” 입력한 , 분석을 시도하는 화면입니다. 프로그램에서 10바이트의 스택 공간을 할당하므로, BOF 시도하여 분석을 하는 상황입니다.

[그림 4] 프로그램 실행

 

프로그램의 시작 부분에서 디스어셈블리 코드 상에서 확인한 security cookie 구간을 확인 가능합니다.

[그림 5] security cookie

 

XOR 연산 후에 레지스터에 저장되는 것을 확인 가능합니다.

[그림 6] XOR 연산

 

다음 화면은 .data 영역에 존재하는 cookie 값과  스택상에서 xor 연산된 cookie 값을 비교하는 화면입니다. 비교값이 같은 경우 에러는 발생하지 않습니다.

[그림 7] cookie 비교


 

2. SEH Overwrite(GS 우회)
GS 우회하는 대표적인 방법으로 SEH Overwrite 있습니다. 방법은 함수 Epilogue Security Cookie값을 비교하기 전에 Exception 발생시켜 실행흐름을 변경, GS Check 우회하는 방법입니다. Exception 발생시키기 위해서는 소스코드상에서 반드시 try-catch 문이 사용되어야만 합니다.

 

SEH Overwrite 스택의 이전 RET영역까지 덮어 씌우는 것이 아닌 스택에 자리잡고 있는 EXCEPTION_RECORD 구조체의 _handler 부분까지만 덮어씌우게 되기 때문에 sfp ret값은 아래와 같이 변경되지 않습니다.

 

 [그림 8] SEH Overwrite 개념도

 

[그림 9] 같이 _EXCEPTION_RECORD(이하 ER) _next _handler 구성됩니다.  _next 다음 ER 위치를 가리키고 있는 싱글리스트 형태이며, _handler 해당 Exception 발생하였을 수행되는 코드의 위치가 저장되어 있습니다. ER 상황에 맞는 다양한 Exception 처리를 위해 다수의 리스트형태(SEH Chain) 구성됩니다.

 

 [그림 9] SEH 구조

 

Exception 발생하게 되면 _exception_handler 함수가 호출 됩니다. 호출 스택구성은 다음과 같이 구성 되며 _handler 지정했던 주소가 내부적인 메커니즘(call ecx) 의해 명령이 실행됩니다.

 

우선 생각해 공격 시나리오는 _handler 주소를 원하는 shellcode 영역으로 직접 가리켜 shell 실행시키는 방법이 있습니다. 방법은 Windows 2003에서부터 SEH 수정되어 등록된 Load Configuration Directory외에 다른 위치의 주소가 가리켜져 있다면 handler 실행하지 않는 것으로 바뀌었기 때문에 공격이 성공할 없습니다. 그래서 다른 시나리오를 생각해 봐야 합니다.

 

하지만 수정된 SEH Load Configuaration Directory외에 외부 모듈(DLL) 대한 명령어에 대해서는 handler 실행이 허용된다는 것입니다.  이를 이용하여 shellcode 직접 가리키지 않고 간접적으로 호출하여 특정 스택 부분으로 이동, jmp코르를 사용해서 shellcode 호출하는 pop-pop-ret, jmp 사용하는 방법으로 진행하겠습니다.

 

 [그림 10] 공격코드 삽입시 스택 구조

 

공격코드가 삽입된 [그림 10] 같이 실행순서가 ~ 순서로 진행됩니다.  pop-pop-ret 명령이 실행하면서 esp+8 위치까지 올라가게되고 Exception 발생하기 전에 위치가 저장되어있는 _EstablisherFrame 부분( 위치)에서 ret명령이 실행되면서 위치로 옮겨지게 됩니다. 위치에 있는 명령어 코드가 실행되게되는데 OPCODE eb 10(jmp short eip+16) 실행되면서 위치로 옮겨지게 되고 shellcode 실행됩니다.

 

공격 시나리오는 Windows XP 영문판, 개발환경은 Visualstudio 2003에서 테스트 하였습니다.

 

다음과 같이 취약한 소스코드를 작성하여 SEH Overwrite 확인해보겠습니다.

 [그림 11] 취약점이 존재하는 소스코드

 

취약점이 존재하는 소스코드는 strcpy 함수 호출 이후 주소 0번지에 문자를 대입하여 Exception 발생하도록 유도하였습니다.

 

프로젝트 옵션에서 Buffer Security Check(GS) 설정하여 Security Cookie 삽입되도록 하였습니다.

 [그림 12] GS 옵션 설정

 

인자값으로 스트링 100개를 삽입하게되면 Security Cookie 덮어씌우게 되고 체크로직으로 인해서 Buffer 넘쳤다는 오류 메시지가 발생합니다.

 [그림 13] Buffer overrun detected!

 

동일한 인자값으로 OllyDBG 이용하여 스택에 어느부분까지 덮어씌우는지 확인해보았습니다. 우리가 공략하려는 _prev _handler 부분까지 덮어씌우려면 아직 12 Byte 부족합니다.

 [그림 14] Buffer Overflow 위치 확인

 

12 Byte 채우고 확인해보았습니다. _handler부분이 덮어씌어지고 42424242값이 EIP 값이 변경되어 실행되었고 42424242 번지는 존재하지 않는 부분이기 때문에 Error 메시지가 발생합니다.

 [그림 15] Buffer Overflow 위치 확인#2

 

이제 공격 코드를 구성하기 위해 필요한 pop-pop-ret(Gadget) 찾아보겠습니다. 현재 Process 아닌 DLL영역의 검색해야하기 때문에 findjmp 이용하여 검색하였습니다.

[그림 16] pop-pop-ret 검색

 

Exploit 사용될 공격 코드는 다음과 같은 형태로 삽입됩니다.

 [그림 17] 공격 Payload

 

앞서 설명했던 공격 시나리오와 위에 공격 Payload 형태로 Exploit 작성하여 공격해보았습니다.

 [그림 18] Exploit 작성

 

OllyDBG 계산했던 _prev _handler 위치를 인자값으로 입력하여 공격하면 다음과 같이 shell 실행됩니다.

 [그림 19] 공격 성공

 

SEH Overwrite 이용하여 GS 우회하였습니다. 하지만 이런 공격방법이 성공하자 MS SafeSEH 기술을 적용합니다. 다음 화면은 Window 상에서 메모리 보호 기법에 대한 관계도 입니다.

[그림 20] Window 메모리 보호기법

 

이는 SEH Chain 대한 Validation Check 수행하게 되는데 SafeSEH기술이 적용된 프로그램은 위와 같은 공격은 무용지물이 됩니다. 하지만 SafeSEH 또한 우회하는 기술이 발표되었습니다. 연속적으로 jmp명령을 여러번 수행하여 원하는 쉘코드로 향하게 하는 방법입니다. 부분에 대해서는 시간상 추후 연구 과제로 남겨둡니다.


참고 URL

1.   http://msdn.microsoft.com

2.   http://x82.inetcop.org/

3.   http://nchovy.kr/forum/5/article/377

4.   http://en.wikipedia.org/wiki/Buffer_overflow_protection

5.   http://ko.wikipedia.org/wiki/버퍼 오버플로우

6.   http://lucid7.egloos.com/

7.   http://uptx.egloos.com/

 

 

참고 문헌

1.   poc09-sotirov.pdf(POC 2009 발표자료)

2.   BHUS10_Paper_Payload_already_inside_data_reuse_for_ROP_expl.pdf

(BlackHat 2010 USA 발표자료)

3.   Linux Memory Protectiion Mechanism

4.   bh08sotirovdowd.pdf(BlackHat 2008 발표자료)

5.   BOF_공격방지_매커니즘_구현의_최신_동향.pdf

6.   http://www.shell-storm.org/papers/files/732.pdf

7.   www.phreedom.org/presentations/reverse.../reverse-engineering-ani.pdf

8.   CanSecWest2010 – SEH Overwrite, Shuichiro Suzuki

9.   Windows 구조와 원리 (OS를 관통하는 프로그래밍 원리) - 정덕영



TEAMCR@K 워크샵

CR@K 이야기 2011. 4. 24. 22:01 Posted by 알 수 없는 사용자

2011년 4월 23일날 가평으로 TeamCR@K 워크샵을 갔습니다.
다행히 한명도 빠지지 않고 모두 참석을 하였고, 주말임에도 불구하고 매우 즐거운 시간을 보냈습니다.

짧게나마 사진을 남깁니다.....


1. 숙소 창문으로 본 가평


2. 숙소 창문으로 본 가평

3. 숙소 창문으로 본 가평


4. 강풍속 배드민턴


5. 강풍속 배드민턴


6. Teamcr@k 화보표지

7. 미니게임 ~

8. 탄지공 시전

9. ATV 타고 질주 중!

10. ATV 타고 질주 중!

11. ATV 타고 질주 중! (시속 25 ㅠㅠ)


12. ATV 타고 질주 중!




즐거운 Teamcr@k M.T Stroy!


본 문서는 iPhone iOS 의 기본 구조를 이해하고, 프로세스 및 Debug 등에 활용될 수 있는 도구를 소개하는데 목적이 있습니다. 다.  해당 내용은 아래와 같이 4개의 주제로 나눠 연재하겠습니다.
 

1. iOS Framework 이해
2. iOS App 분석 및 프로세스/툴 도구 소개
3. Static, Dynamic Code Analyzer 소개
4. Forensic Tools 소개



iOS App 분석 프로세스/툴 소개

1. Web App with a Proxy
다양한 iOS용 App 가운데 Web 기반의 App에 적용될 수 있는 진단 방법입니다.

가. Simulator with a Proxy
(1) 특징
기존의 웹 모의해킹 시 프록시 툴을 사용하는 것과 동일하게 에뮬레이터 상에서 접근하는 모든 HTTP(S) 패킷을 열람/수정/전송 할 수 있습니다.

(2) 실행 경로
/<설치경로>/Charles.app

(3) 세부 기능
● SSL Proxying – view SSL requests and responses in plain text
● Bandwidth Throttling to simulate slower Internet connections including latency
● AJAX debugging – view XML and JSON requests and responses as a tree or as text
● AMF – view the contents of Flash Remoting / Flex Remoting messages as a tree
● Repeat requests to test back-end changes
● Edit requests to test different inputs
● Breakpoints to intercept and edit requests or responses
● Validate recorded HTML, CSS and RSS/atom responses using the W3C validator

(4) 사용 예

                                                                  [그림 1] 프록시 설정

                                                  [그림 2] 프록시 실행 후 HTTP 패킷 확인



나. in Web Browser
(1) 특징
웹 브라우저 상에서 실행되는 아이폰 시뮬레이터에서 접근하는 아이폰 용 웹 어플리케이션을 기존의 웹 모의해킹 시 프록시 툴을 사용하는 것과 마찬가지로 에뮬레이터 상에서 접근하는 모든 HTTP(S) 패킷을 열람/수정/전송 할 수 있습니다.


(2) 실행 경로
http://www.testiphone.com/


(3) 세부 기능
아이폰 용 웹 어플리케이션을 웹 브라우저 기반 시뮬레이터를 통해 실행 가능합니다.


(4) 사용 예

                                       [그림 3] 웹 시뮬레이터로 iPhone App 실행


                                         [그림 4] 웹 시뮬레이터 및 웹 프록시 실행


나. in Web Browser
(1) 특징
웹 브라우저 상에서 실행되는 아이폰 시뮬레이터에서 접근하는 아이폰 용 웹 어플리케이션을 기존의 웹 모의해킹 시 프록시 툴을 사용하는 것과 마찬가지로 에뮬레이터 상에서 접근하는 모든 HTTP(S) 패킷을 열람/수정/전송 할 수 있습니다.


(2) 실행 경로
http://www.testiphone.com/


(3) 세부 기능
아이폰 용 웹 어플리케이션을 웹 브라우저 기반 시뮬레이터를 통해 실행 가능합니다.


(4) 사용 예

                                         [그림 5] 웹 시뮬레이터로 iPhone App 실행


                                           [그림 6] 웹 시뮬레이터 및 웹 프록시 실행



2. Decompiling

가. otool
(1) 특징
otool은 실행파일(or obj, lib 등)의 정보를 보여주거나 오브젝트 파일을 디컴파일 하여 어셈블리 코드를 추출해주는 툴입니다.


(2) 실행 경로
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/otool
(otool은 기본적으로 환경변수에 등록되어 있기 때문에 bash shell에서 실행파일 명(otool)과 인자 값을 주어 실행할 수 있습니다.)


(3) 세부 기능
다음은 otool에서 사용되는 옵션들입니다.

Options

Description

-a

Display the archive header, if the file is an archive.

-S

Display the contents of the `__.SYMDEF' file, if the file is an archive.

-f

Display the universal headers.

-h

Display the Mach header.

-l

Display the load commands.

-L

Display the names and version numbers of the shared libraries that the object file uses. As well as the shared library ID if the file is a shared library.

-D

Display just install name of a shared library.

-s segname sectname

Display the contents of the section (segname,sectname).  If the -v flag is specified, the section is displayed as its type, unless the type is zero (the section header flags). Also  the sections  (__OBJC,__protocol), (__OBJC,__string_object) and (__OBJC,__runtime_setup) are displayed symbolically if the -v flag is specified.

-t

Display the contents of the (__TEXT,__text) section.  With the -v flag, this disassembles the text.  And with -V, it also symbolically disassembles the operands.

-d

Display the contents of the (__DATA,__data) section.

-o

Display the contents of the __OBJC segment used by the Objective-C run-time system.

-r

Display the relocation entries.

-c

Display the argument strings (argv[] and envp[]) from a core file.

-I

Display the indirect symbol table.

-T

Display the table of contents for a dynamically linked shared library.

-R

Display the reference table of a dynamically linked shared library.

-M

Display the module table of a dynamically linked shared library.

-H

Display the two-level namespace hints table.

-p name

Used  with  the -t and -v or -V options to start the disassembly from symbol name and continue to the end of the (__TEXT,__text) section.

-v

Display verbosely (symbolically) when possible.

-V

Display the disassembled operands symbolically (this implies the -v option). This is useful with the -t option.

-X

Don't print leading addresses or headers with disassembly of sections.

-m

The object file names are not assumed to be in the archive(member) syntax, which allows file names containing parenthesis.



(4) 사용 예

                                     [그림 7] 어플리케이션 패키지 내용 보기


                                                      [그림 8] otool 실행


                                                      [그림 9] 결과파일 확인


                                        [그림 10] 어셈블리 코드 생성 확인



※ 악의적인 목적으로 이용될 수 있는 상세 설명은 해당 포스팅에서는 제외 되었습니다.


참고자료
[1] Static Analysis in Xcode, Apple Inc, 2009-08-28
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/index.html
[2] Mobile Web and App Development Testing and Emulation Tools, Paul Andrew, 2010-04-12
http://speckyboy.com/2010/04/12/mobile-web-and-app-development-testing-and-emulation-tools/
[3] iPhone Simulator
http://www.testiphone.com/
[4] charlesproxy
http://www.charlesproxy.com/
[5] Penetration Testing for iPhone/iPad Applications, Kunjan Shah,
[6] iOS Development Guide, Apple Inc, 2010-11-15
http://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iphone_development/iOS_Development_Guide.pdf
[7] iOS Application Programming Guide, Apple Inc, 2011-02-24
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html
[8] Mac OS X Developer Tools Manual Page, Apple Inc, 2010-11-03
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html
[9] class-dump
http://www.codethecode.com/projects/class-dump/
[10] Mac OS X Developer Library, Apple Inc, 2009-08-28
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/_index.html
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/SharkUserGuide/CommandReference/CommandReference.html
[11] charlesproxy
http://www.charlesproxy.com/
[12] iPhone Database Details, DAMON, 2007-08-21
http://damon.durandfamily.org/archives/000487.html
[13] iPhone Privacy, Nicolas seior

[연구 문서] IPhone (iOS) 이해

스마트폰 2011. 4. 11. 11:30 Posted by TEAMCR@K
본 문서는 iPhone iOS 의 기본 구조를 이해하고, 프로세스 및 Debug 등에 활용될 수 있는 도구를 소개하는데 목적이 있습니다. 다.  해당 내용은 아래와 같이 4개의 주제로 나눠 연재하겠습니다.
 

1. iOS Framework 이해
2. iOS App 분석 및 프로세스/툴 도구 소개
3. Static, Dynamic Code Analyzer 소개
4. Forensic Tools 소개



iOS Framework 이해

1. iOS Architecture
iOS architecture 는 기본적인 Mac OS X의 architecture 와 유사합니다. iOS는 underlying hardware 와 스크린 에 나타나는 application 사이에 중재자 역할을  합니다. 아래 그림에서 보듯이 만들어진 application은 기본이 되는 hardware 와 직접적인 통신은 하지 않습니다. 대신 application들은 하드웨어 변화로부터 application을 보호해줄 well-defined system interface 를 통하여, hardware 와 통신을 합니다. 이러한 추상화(abstraction)는 다른 하드웨어에서도 일관성 있게 작동하는 application을 쉽게 작성할 수 있게 만들어줍니다.

                                      [그림 01] Application layered in top of iOS


2. Layers of iOS
아래 그림에서 볼 수 있듯이, iOS기술의 구현은 계층들의 하나의 집합으로 보여질 수 있습니다. 모든 application들이 의존하는, 시스템의 하위 계층들은 기반이 되는 서비스 와 기술입니다. 상위 계층들은 더욱 정교한 서비스와 기술을 포함하고 있습니다.

                                                  [그림 18] Layers of iOS

application 코드를 작성시, 가능하다면 하위 계층 framework 기반의 상위 계층 framework들의 사용을 선호해야 합니다. 상위 계층의 framework들은 하위 계층 구조에서의 객체 지향 추상화(object-oriented abstraction)를 제공합니다. 이러한 추상화는 잠재적으로 복잡한 특징이 존재하는 socket 과 thread 를 작성 및 캡슐화 시, 상당한 양의 코드를 줄여 줌으로써, 일반적인 코드작성을 더욱 쉽게 만들어 줍니다. 비록 하위 계층의 기술들을 추출 하였지만, 상위 계층은 작성자로부터 사용된 그들의(상위계층) 기술을 숨기지 않습니다. 상위 계층에서 사용될 수 없는 하위 계층 framework의 특징을 사용하기 원하는 개발자를 위해 하위 계층 framework들 또한 사용가능 합니다. 이것을 통하여 각 계층의 기능을 사용하기 위해 전반적인 계층들의 framework들과 framework의 class 정보를 인지하여, iOS의 기능들을 활용 할 수 있습니다.


3. Frameworks of each layer
가. Cocoa Touch Layer
(1) CoreLocation.framework
Core Location framework는  현재 위치 또는 device 관련된 방향을 결정합니다. Core Location framework는 사용자의 위치와 방향을 을 결정하기 위해 가용한 hardware를 사용합니다. 이동 위치와 방향 event 를 관리하기 위하여 Core Location framework 의 class 와 protocol들을 사용할 수 있습니다. 사용자가 해당지역의 경계를 지날 경우를 해당 framework 를 이용하여 지리학적 지역을 확인 할 수 있습니다.

Framework

/System/Library/Frameworks/CoreLocation.framework

Header file directories

/System/Library/Frameworks/CoreLocation.framework/Headers

참고문서)
http://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CoreLocation_Framework/_index.html#//apple_ref/doc/uid/TP40007123


나. Core Service Layer
(1) CoreTelephony.framework
사용자의 cellular service provider(통신 사업자)에 대한 정보를 얻기 위해선 Core Telephony framework를 사용하시길 바랍니다. Carriers 는 그들의 가입자를 위한 service를 제공하는 application을 작성하기 위해 이러한 정보를 사용할 수 있습니다. 또한 current cellular calls(통화) 정보를 획득하기 위해서 Core Telephony framework를 사용가능 합니다. CTCarrier object는, 해당 네트워크에서 VoIP 의 사용을 허가 여부와 같은 사용자의 cellular service provider에 관한 정보를 제공합니다. CTCall object는 고유 식별자(unique identifier)와 상태정보(dialing, incoming, connected, or disconnected)를 포함하는 current call에 관한 정보를 제공합니다

Framework

/System/Library/Frameworks/CoreTelephony.framework

Header file directories

/System/Library/Frameworks/CoreTelephony.framework

/Headers


참고문서)
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Reference/CoreTelephonyFrameworkReference/_index.html#//apple_ref/doc/uid/TP40009603


다. ExternalAccessory.framework
External Accessory framework는 30-pin dock connector 또는 buletooth를 이용한 무선을 통한 iOS-based device와 연결된 외부 기기와의 통신지원을 제공합니다. external accessories를 지원하는 Application들은 그들의 Info.plist 파일이 올바르게 설정되어있는지 반드시 확인하여야 합니다. 특별히application이 지원하는 특별한 hardware protocol을 선언하기 위해서 반드시 UISupportedExternalAccessoryProtocols key 를 포함해야 합니다. 더 많은 정보를 확인하기 위해서는 External Accessory Programming Topic을 확인 하시길 바랍니다.

Framework

/System/Library/Frameworks/ExternalAccessory.framework

Header file directories

/System/Library/Frameworks/ExternalAccessory.framework

/Headers


참고문서)
http://developer.apple.com/library/ios/#documentation/ExternalAccessory/Reference/ExternalAccessoryFrameworkReference/_index.html#//apple_ref/doc/uid/TP40008235

(1) Foundation.framework
Foundation framework 는 Objective-C class들의 기반이 되는 계층입니다. 추가적으로 유용한 원시적인(primitive) 객체 클래스들을 제공합니다.
 

  • 기본적인 uitiliy class들을 제공합니다.
  • Deallocation과 같은 일관적인 규약을 소개함으로써 software 개발을 쉽게 만듭니다.
  • Unicode string , object persistence(객체 저장) 와 object distribution(객체 분산) 을 지원합니다.
  • 이식성을 강화하기 위하여, OS 독립 수준(level)을 제공합니다.

foundation framework는 string, byte array와 같은 root object class, 날짜와 같은 시스템 정보와 통신 ports 등을 나타내는 다른 객체를 저장할 수 있는 collection class 를 포함 합니다. foundation framework 에 대한 자세한 정보는 Reference url을 참고하시길 바랍니다.

Framework

/System/Library/Frameworks/Foundation.framework

Header file directories

/System/Library/Frameworks/Foundation.framework

/Headers



참고문서)
http://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/ObjC_classic/_index.html#//apple_ref/doc/uid/20001091

(2) ImageIO.framework
Image I/O programming interface는 대부분의 image file format 을 읽고 쓰는 것을 할 수 있게 합니다. Image I/O 쉽게 image 의 metadata 접근과 색 관리를 쉽게 할 수 있게 합니다.

Framework

/System/Library/Frameworks/ApplicationServices

/ImageIO

Header file directories

/System/Library/Frameworks/ApplicationServices.framework
/ImageIO.framework/Headers

참고문서)
http://developer.apple.com/library/ios/#documentation/GraphicsImaging/Reference/ImageIORefCollection/_index.html#//apple_ref/doc/uid/TP40005102

(3) MapKit.framework
MapKit framework는 view 와 windows에 직접적으로 내장되어있는 map interface를 제공합니다. 해당 framework는 지도를 나타내는 것, overlay들의 추가, 주어진 좌표로 장소정보를 결정하기 위한 reversing-geocoding nslookup(좌표로부터 주소를 구함)수행 등에 대한 지원을 제공합니다. MapKit framework 는 map data를 제공하는 google 서비스를 이용합니다. MapKit framwork 의 class를 사용할 경우 자동적으로 Google Map/Google Earth API를 이용하게 됩니다.

Framework

/System/Library/Frameworks/MapKit.framework

Header file directories

/System/Library/Frameworks/MapKit.framework/Headers



참고문서)
http://developer.apple.com/library/ios/#documentation/MapKit/Reference/MapKit_Framework_Reference/_index.html#//apple_ref/doc/uid/TP40008210


라. Core OS Layer

(1) CFNetwork.framework
CFNetwork framework 는 network protocol에 맞추어진 object-oriented abstraction(객체지향 추상화)을 사용하는 높은 수준의 성능을 지니고 있는 C-기반의 interface 집합입니다. 추상화는 protocol stack 에 대해 자세한 제어를 제공하며 BSD socket과 같은 lower-level contstructs(구조)를 쉽게 작성할 수 있게 해줍니다. CFNetwork Framework를 이용하여 FTP 와 HTTP 통신과 resolving DNS host를 결정하는 작업을 간단하게 할 수 있습니다. 다음은 CFNetwork Framework 가 지원하는 작업의 목록입니다.

  • BSD socket 의 사용
  • SSL, TLS 를 이용하는 암호화 연결(encrypted connection)
  • DNS hosts 결정(resolve DNS hosts)
  • HTTP server, 인증을 요구하는 HTTP server(authenticating HTTP server), HTTPS server 와의 연결
  • FTP server 연결
  • Publish, resolve, and browse Bonjour services

CFNetwork 는 이론이나 실제적으로 BSD sockets을 기반으로 되어있습니다. CFNetwork 사용을 위해서는 CFNetwork Programming Guide and CFNetwork Framework Reference 를 참조하시길 바랍니다.

참고문서
http://developer.apple.com/library/ios/#documentation/CFNetwork/Reference/CFNetwork_Framework/_index.html#//apple_ref/doc/uid/TP40007128

※ 현재 버전의 문서에서의 framework 및 class정보는 2011년 3월 25일의 http://developer.apple.com/library/ios/ 기반으로 작성되어 있음을 알려 드립니다.

※ 각 계층의 framework 정보는 일부만을 기재하였음을 알려드립니다.

[연구문서] SpyPhone 분석 및 응용

스마트폰 2011. 4. 8. 14:11 Posted by TEAMCR@K
본 문서는 iPhone iOS 에서 발생되었던 악성코드(웜.바이러스 등) 대하여 작성하였습니다. 해당 내용은 아래와 같이 2개의 주제로 나눠 연재하겠습니다.
 

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



SpyPhone 분석 및 응용

1. SpyPhone 소개
SpyPhone은 “스위스’의 ‘Nicolas Seriot’에 만들어졌고, 2010년 BlackHat-DC에서 발표된 App입니다.

                                                 [그림 1] iPhone SpyPhone 제작 및 발표자

iPhone OS Version 3.1.2 의 환경(발표되었던 시점에서는 최신 버전)에서 개발되었으며, private APIs를 사용하지 않아 App Store 에 등록을 하기 위해서도Jailbreak 및 Root Shell 권한을 획득할 필요 없는 환경입니다. 단지 plist 정보를 이용하여 개인정보(Personal data)를 확인하는 SpyWare라고 할 수 있습니다.


2. 세부 기능
SpyPhone을 이용하여 다음과 같은 정보를 확인할 수 있으며, 해당 내용들을 자동으로 수집하여 특정 메일주소로 전송할 수 있는 “Report” 기능이 있습니다.

  • Email Accounts
  • Wifi Information
  • Phone Information
  • Location Information
  • Safari Cache Information
  • YouTube Information
  • Photos Information
  • AddressBook Information


3. 분석 환경
● Max OS X 10.6.5
● Xcode 3.2.5
● iPhone 3G (iOS 4.2.1)




SpyPhone 소스 코드 분석


1. 호출 흐름 분석
SpyPhone 어플리케이션의 함수 호출 흐름을 분석한 모습입니다.
                                                                         [그림 2] 호출 흐름도


1. Main 실행
어플리케이션이 실행되는 순간 내부적으로는 main() 함수가 호출됩니다.

2. Auto Release Pool 생성
main 함수는 NSAutorelesePool() 함수를 호출하여, 해당 함수를 호출한 호출한 객체들을 관리하는 메모리 공간을 생성합니다.

main.m

int main(int argc, char *argv[]) {

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    int retVal = UIApplicationMain(argc, argv, nil, nil);

    [pool release];

    return retVal;

}


3. Object 생성 및 초기화 / Delegate 연결
UIApplicationMain() 함수는 내부적으로 UIApplication 객체를 하나 생성합니다.

main.m

int retVal = UIApplicationMain(argc, argv, nil, nil);



그리고 info.plist 파일을 분석하여 NSMainNibFile에 지정되어 있는 xib 파일을 읽어옵니다.

SpyPhone-info.plist

...

<key>NSMainNibFile</key>

<string>MainWindow</string>

...


                                               [그림 3] NSMainNibFile 확인


MainWindow.xib 파일에 포함된 View, Window 등의 모든 객체를 생성하고 초기화합니다.
                                                   [그림 3] MainWindow.xib 확인

마지막으로 App Delegate를 연결하여 SpyPhoneAppDelegate.m 의 applicationDidFinishLaunching()를 호출하여 어플리케이션이 초기화되었다고 알려줍니다.


SpyPhoneAppDelegate.m

- (void)applicationDidFinishLaunching:(UIApplication *)application {

   

    // Add the tab bar controller's current view as a subview of the window

    [window addSubview:tabBarController.view];

    

     BOOL isTVOutEnabled = [[NSUserDefaults standardUserDefaults] boolForKey:@"TVOutEnabled"];

     if(isTVOutEnabled) {

        [[UIApplication sharedApplication] startTVOut];

     }

}



4. 각종 이벤트 처리
어플리케이션이 정상적으로 초기화 된 이후에는 각종 이벤트를 처리하는 클래스 및 함수들이 호출되어 어플리케이션의 기능을 실행시켜줍니다.

2. 소스코드 세부 분석
SpyPhone 어플리케이션을 구성하는 항목은 다음과 같습니다.

                                              [그림 5] SpyPhone 구성도
 

● Classes
SpyPhone에서 제공하는 핵심 기능들을 구현하는 주요 소스코드 파일들이 포함되어 있습니다.
● Other Sources
main.m, UIApplication_TVOut.m, SpyPhone_Prefix.pch 등이 포함되어 있습니다.
● Resources
 info.plist, *.xib, Setting.bundle, *.png(아이콘, 이미지) 등이 포함되어 있습니다.
● Frameworks
UIKit, Foundation 등 SpyPhone.app에서 사용하는 각종 프레임워크가 포함되어 있습니다.
● Products
 SpyPhone.app가 위치하는 곳입니다.
● gpl-2.0.txt
 GNU 라이센스를 설명하고 있습니다.


가. SPAllSourcesTVC & SPSources
SPAllSourcesTVC가 호출되면 내부적으로 Email, Wifi, Phone 등 기능별로 연결되는 소스코드를 로딩합니다.

SPAllSourcesTVC.m

- (void)loadSources {

     if(sources) return;

    

     if(!self.isViewLoaded) [self loadView];

    

     self.sources = [NSArray arrayWithObjects:

                              sourceEmailTVC,

                              sourceWifiTVC,

                              sourcePhoneTVC,

                              sourceLocationTVC,

                              sourceSafariTVC,

                              sourceYouTubeTVC,

                              sourcePhotosTVC,

                              sourceAddressBookTVC,

                              sourceKeyboardTVC,

                              nil];

}


또한 사용자가 이메일 리포트를 보낼 수 있는 기능도 구현되어 있습니다.

SPAllSourcesTVC.m

- (NSString *)emailForReport {

     if(!self.isViewLoaded) [self loadView];

 

     return [sourceEmailTVC emailForReport];

}

...

- (NSString *)report {

     [self loadSources];

    

     NSMutableString *s = [NSMutableString string];

    

     for(SPSourceTVC *source in sources) {

        [s appendString:[NSString stringWithFormat:@"----- %@ -----\n\n", [source.title uppercaseString]]];

       

        [source loadData];

        NSArray *a = source.contentsDictionaries;

        for(NSDictionary *d in a) {

               [s appendString:[NSString stringWithFormat:@"[[ %@ ]]\n", [[d allKeys] lastObject]]];

               [s appendString:[[[d allValues] lastObject] componentsJoinedByString:@"\n"]];

               [s appendString:@"\n\n"];

        }

        //[s appendString:@"\n"];

     }

    

     return s;

}


세부적인 기능들은 개별적인 항목과 연계되는 민감한 데이터를 불러오는데, 웹 브라우저인 사파리의 데이터를 읽어오는 부분을 살펴보면 검색기록을 읽어오는 것을 확인할 수 있습니다.

SPSourceSafariTVC.m

- (void)loadData {

     if(contentsDictionaries) return;

 

     self.contentsDictionaries = [NSMutableArray array];

    

     NSString *path = @"/var/mobile/Library/Preferences/com.apple.mobilesafari.plist";

     NSDictionary *d = [NSDictionary dictionaryWithContentsOfFile:path];

     NSArray *searches = [d valueForKey:@"RecentSearches"];

     if(!searches) searches = [NSArray array];

    

     [contentsDictionaries addObject:[NSDictionary dictionaryWithObject:searches forKey:@"Recent Searches"]];

}


전체적으로 SpyPhone에서 읽어들이는 Data는 다음과 같은 것들이 포함됩니다.

SpyPhone에서 읽어들이는 DATA 목록

/var/mobile/Library/Keyboard/

/var/mobile/Library/Preferences/com.apple.accountsettings.plist

/var/mobile/Library/Preferences/com.apple.commcenter.plist

/var/mobile/Library/Preferences/com.apple.mobilephone.settings.plist

/var/mobile/Library/Preferences/com.apple.mobilephone.plist

/var/mobile/Library/Preferences/com.apple.mobilesafari.plist

/var/mobile/Library/Preferences/com.apple.preferences.datetime.plist

/var/mobile/Library/Preferences/com.apple.weather.plist

/var/mobile/Library/Preferences/com.apple.youtube.plist

/var/mobile/Library/Preferences/com.apple.Maps.plist

/var/mobile/Media/DCIM/



나. SPMapVC.m & SPImageVC.m & SPImageAnnotation.m & EXIF
Photos, Map, Location 메뉴 선택 시 사용되는 클래스 및 함수들로 사진 이미지에 포함되어 있는 GEO Tag 정보를 불러오고, 해당 정보를 이용하여 지도에 위치를 표시해 주는 등의 역할을 해 줍니다.
* EXIF means Exchangeable Image File Format.




동작 분석

1. 소스코드 수정
소스에서 불러오는plist 경로가 에뮬레이터와 다르기 때문에 에뮬레이터에서 수집하는 정보를 확인하기 위해서는 에뮬레이터 환경에 맞게 수정하여 재 컴파일 해야 합니다.

                                                                  [그림 6] *.plist 경로 수정


2. 실행 확인
수정된 소스를 다시 컴파일 한 뒤에 확인을 하면 기본설정(Default)에서는 나타나지 않던 정보들이 나타나게 됩니다. 아래 예제는 Safari에서 Google 검색했던 단어들을 확인하는 과정입니다.

                                       [그림 9] plist 파일 수정 후에 실행된 화면


※ Device 환경에서의 상세 분석은 위험성이 존재하여, 현 포스팅에서는 생략합니다.

참고 사항

1. 카테고리 별 프레임워크
카테고리 별로 분류 및 정리된 코코아 프레임워크입니다.

Cocoa

Category

Frameworks

오디오 비디오

Core Audio, Core MIDI, Core Video

그래픽 애니메이션

Core Animation, Core Image, OpenGL, Quartz, QuickTime, QTKit

데이터 관리

Core Data

네트워킹 인터넷

Bonjour, Directory Services, Kerberos

스크립팅 언어와 연결해주는 Cocoa Bridges

AppleScript, Python, Ruby

사용자 응용 프로그램

Address Book, Calendar Store, Instant Message



2. 하위버전 App 컴파일 하기
ios가 4.0으로 업데이트 되면서 그보다 하위버전에 대한 지원을 중단한 상태입니다. 그래서 하위버전으로 컴파일을 할 수는 없지만, Deployment Target Version을 하위버전으로 맞춰줌으로써 디바이스 및 시뮬레이터에서 실행시킬 수 있습니다.


1. Xcode의 메뉴 중 Project > Edit Project Settings를 실행합니다.

                                                       [그림 10] 메뉴 선택

2. Project Info의 Build 탭에서 Base SDK는 가장 최신의 버전으로 선택합니다.

                                                             [그림 29] Base SDK 지정

3. iOS Deployment Target 항목을 실제 어플리케이션이 실행될 수 있는 하위버전으로 설정해 줍니다. (SpyPhone은 iOS 3.1.2에 맞춰서 구현되었습니다.)





참고 자료

[1] iPhone SDK - none Device, dEV, 2009-10-17
http://samurai.tistory.com/entry/iPhone-SDK-none-Device
[2] Mac OS X - Cocoa, Apple Inc.
http://www.apple.com/kr/developer/technologies/mac/cocoa.html
[3] Q&A - iPhone SDK 4 설치후 Base SDK설정관련, Korea iOS Developer Group
http://www.iphoneos.co.kr/zbxe/?mid=tip&page=10&document_srl=46123
본 문서는 안드로이드(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



본 문서는 안드로이드(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을 대상으로 공격을 시도 하고 있습니다.

                                                                [그림 7] Ikee.B structure


참고 자료
 [1] iPhone Privacy, Nicolas seior

SHODAN for Penetration Testers

웹 어플리케이션 2011. 4. 1. 15:25 Posted by TEAMCR@K

모의해킹 환경분석을 할 시에 Google 검색과 같이 유용하게 사용될 수 있는 SHODAN 검색입니다.

이전에 http://teamcrak.tistory.com/311 관한 글을 작성 했는데, 해당 발표자료가 정리가 잘 되어 있어 첨부합니다.

http://www.scribd.com/doc/26526911/SHODAN-for-Penetration-Testers

Wireshark를 사용하다가 참고할만한 사이트(온라인, PDF파일, 샘플) 들입니다.

 Wireshark 온라인 도움말 : http://www.wireshark.org/docs/wsug_html

Wireshark 도움말 PDF 파일 : http://www.wireshark.org/download/docs/user-guide-a4.pdf

각 패킷 샘플 다운로드 : http://wiki.wireshark.org/SampleCaptures