TEAMCR@K

 

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

본 문서는 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를 관통하는 프로그래밍 원리) - 정덕영

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 의 기본 구조를 이해하고, 프로세스 및 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 정보는 일부만을 기재하였음을 알려드립니다.

본 문서는 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