2012.12.27 20:25 System

[+] Introduction 


 

사람이 가장 잉여스러워지는 시간인 방학이 찾아왔습니다.


정신차리고 보니 크리스마스가 지났네요 

 

<Fig. 24일에 올렸어야 할 짤방>

 


왠지 1년 전에도 이와 비슷한 일이 있었던 것 같지만 그냥 넘어가요 우리..


아무튼 새해가 찾아오기 전에 글이라도 하나 올려야 제 자신에게 변명거리라도 될 거 같아요.

 

 




[+] What is "Code obfuscation"? 


 

코드 난독화는 Program들이 나날이 자신들을 역공학 해주는 리버서들의 열정에 몸둘바를 몰라 만들어낸 일종의


자기 방어술입니다.


리버서들의 목적이 대부분 악용에 있다 보니 , Program 업체들은 자신들의 자산이 까발려지지 않기 위해 혹은 악용되지 않기 위해


Anti-debugging 부터 해서 실행 압축 [ Packer ] , 여기서 더 나아간 Protector 까지 적용합니다.


물론 , 이 기술들이 악성 코드에 적용되고 있는 건 다시 말할 것도 없겠죠.


이 중에서 코드 난독화는 Protector에 흔히 적용되는 기술인데 말그대로 코드를 읽기 어렵게 하는 겁니다.


암호화 하고 코드를 치환하고 API 호출을 빙빙 돌려서 정적 분석 뿐만 아니라 동적 분석 까지 막는 것이 그들의 임무입니다.


리버서들이 해석하기 어렵게 코드를 짜야 합니다. 이를 해석해주는 Disassembler가 해석하기 어렵게 코드를 짜야 합니다.

 

이를 위해서 실제 소스 코드 상에서 말도 안되는 Dummy code를 집어넣어 흐름을 헷갈리게 만드는 경우도 있습니다만,

 

그보다는 Assembly 단에서 명령어를 꼬아서 혼란시키는 방법을 많이 사용하고 있습니다.

 

오늘 말하려고 하던 주제가 여기서 더 깊숙히 들어가면 멀어지는 관계로 간단히 정리만 하고 넘어가죠.

 

Disassembly 기법은 크게 2가지 정도 나눌 수 있습니다.

 

- Linear sweep

 

- Recursive traversal

 

이 2가지 방법의 알고리즘을 이해하고 나서,

 

그 알고리즘으로서는 해석하면 실제 실행한 것과 다른 결과를 내는 임의의 코드를 삽입하는 거죠.

 

실행과는 전혀 상관 없는 Dummy assembly 를 잔뜩 집어 넣는 방식도 해석하는 입장에서는 정말 짜증날 수 밖에 없습니다.

 

 

<Fig. 코드 난독화가 되어 있는 것을 확인했을 때>

 

 

 

[+] what`s the applicability of code obfuscation?


 

코드 난독화의 대상이 될만한 것이 무엇이 있을까요?


Disassembly 혹은 Decompile이 매우 쉽게 이루어지며 그 결과물이 실제와 가장 근접한 것이 이 난독화의 힘을 가장 많이 볼 수 있지 않나 싶은데요.

 

떠오르신 바로 그겁니다.

 

Java

 

아니라구요? ㅈㅅ...

 

Java는 그 특성상 구동방식이 일반 Application 과 다르기 때문에 코드 난독화를 적용하는데 어려움이 있는 건 사실입니다.

 

하지만 Java에서도 C, C++ 를 사용할 수 있는 방법이 있으니 [ 즉 우리가 알고 있는 Disassembly 를 적용할 수 있는 언어 ]

 

그것이 바로 JNI [ Java Native Interface ] 입니다.

 

* 이 방법외에도 이미 Java 에서는 안드로이드 시장이 활성화됨에 따라 Dex guard, Pro guard 등 코드 분석을 어렵게 하는 방식들이 존재합니다.

 

 

 

 

[+] Considering about JNI 


 

JNI 는 Java에서 Loadlibrary 를 통해 C, C++ 혹은 assembly 로  이루어진 library 를 호출 할 수 있도록 하는 Framework 입니다.

 

원래 목적은 말그대로 C, C++ 등으로 이루어진 library 를 추가 구현 없이 java에서 사용하기 위함입니다.

 

혹은 복잡한 수학연산 등은 JVM 보다 native code가 빠르므로 JNI 를 이 분야에서 사용하기도 하죠.

 

아무튼 이 JNI 를 통해서 기존에 사용했던 코드 난독화 기법등을 사용할 수 있게 됩니다.

 

Library 자체를 packing 하여 실행 압축을 사용할 뿐만 아니라 dummy code등을 사용할 수 있죠.

 

추가적으로 api redirection 이나 함수 포인터를 이용하여 분기 하는 모듈을 리버서에게 노출 시키지도 않을 수 있습니다.

 

가변 인자를 사용하면 모든 함수들의 호출을 일반화 할 수 있고, 함수를 구분하는 식별 인자 또한 고정방식이 아니라

 

유동적으로 변하되 항상 같은 값을 유도할 수 있게 만들 수 있죠.

 

이렇듯 코드 난독화 기법은 고정적인 방법이 아니라 얼마든지 다양한 방법으로 접근 할 수 있습니다.

 

 

 

 

 

 

쓰고보니 별로 기술적인 내용이 들어갈 게 없네요..

 

기존 난독화 기술을 설명하자니 좀 식상할 것 같고 .. 좀 더 신박한 난독화 기술이 있다면 들고 오도록 하겠습니다.

 

 

Posted by LinkC

2012.10.05 11:43 System

[+] Introduction


 

오늘의 주절 거림 대상은 감성의 iOS 입니다.


맛폰 사용률이 급격히 늘어나면서 모바일 보안쪽도 덩달아 관심을 받고 있는데요.


개방적인 안드로이드에 비해서 iOS는 상당한 제약을 두고 있죠.


그 덕에 루팅은 매우 쉽게 되고 있는 반면, 탈옥 쪽은 iOS가 버전업을 할 떄마다 전투가 벌어집니다.


Soft 단에서는 물론 Hard 측에서도 탈옥 감지 루틴을 넣어두었고 탈옥폰에서는 동작 하지 않도록 하는 어플들도 


간혹 보이고 있습니다. 


전에는 bootrom, loader, kernel 정도만 수정했어도 됐는데 말이죠. 라고


쉽게는 말했지만 그렇게 호락호락한 작업은 아닙니다.


boot rom , loader 의 check를 우회하고 들어가서 loader를 교체하고 kernel을 수정해야 합니다.


그러니까 교도관을 속이고 감옥에 들어가서 탈출할 수 있도록 시스템을 분석 후 교체 하고 


최후에는 우리쪽 교도관을 세워야 된다는 소리죠.


프리즌 브레이크보다 더 스릴 넘치는 이야기가 아닐 수 없군요.


 

<Fig. 시도조차 못하겠는데요>



 

이렇게 사람들이 저마다 석호필을 꿈꾸며 탈옥하고자 하는 이유는 여러가지가 있습니다.


애플이 막아둔 기능의 활성화 , customizing  혹은 사형선고를 받은 형을 구하러 간다던가 하는 걸로요.


다행스럽게도 이번 포스팅에서 다룰 부분은 탈옥한 상태의 iPhone을 대상으로 이루어집니다. 괜찮아요. 어렵지 않아요.


kernel patch, boot loader 수정 원리 등은 추후 포스팅에서 다룰 수 있... 지 않을까 생각해봅니다.

 

iPhone 의 Hooking은 Mobile Substrate라는 기본 탈옥 library를 이용하며 본 포스팅은 이를 분석하는 글입니다.

 

Library의 함수명 , 사용 방법 보다는 동작 원리 등에 중점을 두고 쓰도록 하죠.

 

 

 

 


[+]  Find how to patch the code 


 

가장 기본이 되는 Hooking의 원리는 물론 Code Patching 이겠죠.

 

그런데 이 Code Patching 을 어떻게 하느냐?

 

 

 

1. 원격으로 Thread를 만들어 Code를 삽입. 실행.

 

- Code Injection 얘기죠. 다만, 이미 실행되 Process를 Target으로 잡고 있으며 ,

 

새로 실행되는 Process를 감시해야되는 점이 단점으로 남죠.

 

게다가 iOS의 특성상 Sandbox 로 각 Process간에 벽이 존재하는 점 또한 큰 걸림돌이 됩니다.

 

탈옥 했다는 것은 곧 Sandbox를 탈출했다는 소리지만, 일반 앱들은 아직 mobile user 로 돌아가며

 

Sandbox 내에 있어요.

 

 

 

2. dylib 를 injection 한다.

 

 - Windows의 DLL Injection과 유사한 방법입니다. 다만 특정 Process에서 Target Process로 DLL을 Load 시키는 것이 아니라

 

[ 이 방법대로 하면 Code Injection 과 별 다를바가 없죠 . ]

 

Process가 실행 될 때 dylib [ 동적 library ]를 강제로 Loading 하게 만들고 내부에서 Code를 수정하는 방식입니다.

 

Windows 에서도 Process 시작시에 DLL을 강제 Loading하는 방법이 있죠.

 

자기 자신에서 Code를 바꾸기 때문에 Sandbox도 문제가 될 건 없어요.

 

다만.. iOS의 kernel은 기본적으로 한 메모리 구역에 쓰기 속성과 실행 속성을 동시에 줄 수 없습니다.

 

이 부분은 kernel 단에서 수정이 되어야 하는 것이고, 탈옥을 하면서 이루어진 kernel patch 중 하나가 됩니다.

 

하지만 기본적으로 text 영역엔 쓰기 속성이 없기 때문에 Patch 하기 전에는 쓰기 속성을 주셔야겠죠.

 

 

 

3. kernel level의 system call table을 바꾼다.

 

- kernel hooking 입니다. 사실 불특정 다수의 Process를 control할 때 가장 우아한 방법이긴 합니다만, 

 

이번 포스팅의 주제는 User level hooking 이므로 넘어가도록 하겠습니다.

 

iOS의 Kernel level hooking 은 이미 작년에 유동훈님이 성공하셨다고 하더군요. 시연은 Android만 하셨다고 들었습니다.

 

이번 Code Engn 에서 android 취약점 공격 분석에 관해 발표도 하셨더라구요.

 

http://codeengn.com/file/conference/2012/2012_6th_CodeEngn_[x82]_%EB%AA%A8%EB%B0%94%EC%9D%BC_%EC%8A%A4%EB%A7%88%ED%8A%B8_%ED%94%8C%EB%9E%AB%ED%8F%BC_%EC%9B%90%EA%B2%A9_%EB%A1%9C%EC%BB%AC_%EC%B7%A8%EC%95%BD%EC%A0%90_%EA%B3%B5%EA%B2%A9_%EB%B6%84%EC%84%9D.pdf

 

 

흥미로운 주제니 한번씩 보고 가시는것도 좋을거 같네요.

 

 

 

[+] Analysis the hooking method 


dylib를 로딩 시켰다면 이제 쓸 영역에 쓰기 권한을 주어야 합니다.

 

vm_protect 함수를 이용하여 해당 부분에 쓰기 권한을 주고 난 후 Code를 바꿔봅시다.

 

여기서 주의할 점은 ARM + THUMB mode 둘 다 생각하셔야 된다는 건데요,

 

16bit instruction 을 지원하기 위해 만든 THUMB mode 가 아직도 사용됨에 따라 그쪽 분기를 따로 만들어야 합니다.

 

[ 물론 이 부분은 mobile substrate에서 자동으로 해줍니다. ]

 

아무튼 mode가 달라지면 patch 해야 하는 code 자체가 달라지므로 주의를 해야 합니다.

 

ARM mode는 1 instruction 이 4byte고 THUMB mode는 1 instruction 이 2byte 라서 말이죠.

 

그렇기 때문에 같은 명령어라도 THUMB mode에서는 ARM mode에서 존재하는 instruction 을 재현하기 위해

 

여러가지 instruction 을 조합해서 쓰곤 합니다.

 

그렇게 때문에 hooking 하는데 쓰이는 code는 mode별로 크게 다르지 않아요.

 

THUMB mode 같은 경우는 ARM mode로 바꾼 후 patch 하는게 편하겠죠.

 

windows에서 흔히 쓰는 방법과 크게 다르지 않습니다. JMP! JMP!

 

 

 

<Fig1. Hooking 할 함수에 code patching 을 한 상태>

 

bx pc 명령어를 사용하여 제자리 JMP!

 

그리고 ARM mode로 변경합니다.

 

 

 

<Fig2. Hooking 할 함수중 일부. ARM mode로 변경>

 

ldr 명령어를 통해 pc counter가 가리키는 곳의 주소로 다시 JMP! 합니다.

 

*gdb에서는 끝자리가 홀수 일경우 THUMM mode , 짝수일 경우 ARM mode로 출력합니다.

 

 

<Fig3. 다음 점프할 곳은 0x658984!>

 

0x658984는 저희가 입력한 Code가 있는 곳입니다.

 

 

<Fig4. 사용자가 지정한 custom function 으로 이동한 모습>

 

중간에 blx는 원본 함수를 호출한 건데요. 이 부분은 code patching으로 잘려나간 원본 함수의 초반 부분과

 

JMP 이후의 원본 함수의 주소 값으로 다시 되돌아가는 명령어가 있습니다.

 

<Fig5. intermediate code>

 

 

<Fig6. 되돌아갈 함수의 주소>

 

그리고 원본 함수 대신 실행된 code는 저희가 지정한 dylib에 있어야 정상일테니 확인해봅시다.

 

<Fig7. hooked code가 지정한 dylib에 있는 것을 확인한 모습>

 

 

[+]Conclusion 


 

 

 

<Fig. 뭐래는거야>

 

 

제가 작성했는데도 뭔 소린지 모르겠어요.

 

정리해봅시다. 

<Fig8. Hooking의 흐름>

 

이렇게 보니 별거 아니군요?

 

비슷한 방법이다 보니 Hooking 을 방지 하는 방법도 windows와 비슷한 맥락에서 막을 수 있을거 같습니다.

 

1차적으로는 탈옥되었는지 여부를 판단하면 되겠죠.

 

실제로 skype는 이를 감지하여 비정상 동작을 하더군요. 게다가 gdb도 못붙이게 하구요.

 

아무튼 , 기회가 된다면 다음엔 탈옥시 kernel patch 하는 부분을 살펴볼까 합니다.

 

근데 iOS image내부에 kernelcache 가 IV , Key가 안맞는지 풀리지 않아서 언제가 될런지는 모르겠네요.
 

 

 

 

 

 

 

 

 


Posted by LinkC

2012.09.29 13:47 System

 [+] Introduction


 

모든 Thread가 멈춰있는데 memory 가 변경되는 process가 있을까요?

 

<Fig0. 흥미로운데 이거>

 

 

 

 

[+] Analysis 


 

몇가지 짐작 해 볼 수 있는 건 있네요.

 

1. Remote Create Thread를 이용한 다른 프로세스의 간섭

 

 - 아, 이건 결국 Thread를 Target Process에 생성하고 그 Thread도 멈춰있다고 생각하면 기각이겠군요.

 

2. Shared Memory 를 이용한 접근

 

 -  Thread는 정지 하고 있어도 값이 변경되니 이게 정답일까요?

 

 

하지만 iOS의 sandbox가 출동하면 어떨까?

 

Windows 는 Process 서로 간의 벽이 낮지만 iOS는 상당히 폐쇄적입니다.

 

모래 상자 하나씩 잡고 각자 놀아요.

 

하지만 예외가 있는데요.

 

Audio 처리가 바로 그 중 하나 입니다.

 

iOS의 Audio 처리는 Core Audio 를 기반으로 하죠.

 

다음은 iOS Dev Center에서 가져온 Core Audio 구조입니다.

 

 

<Fig1. iOS Core Audio architecture>

 

 

Core Audio는 kernel realtime thread 를 지원받는 Frame work 인데요.

 

Audio unit 을 통해 이에 접근 할 수 있고 Real time 으로 처리되는 Audio Data를 얻을 수 있다는 거죠.

 

아래 그림을 통해 좀 더 쉽게 이해해봅시다. 마찬가지로 DevCenter 펌

 

 

<Fig2. Audio processing graph>

 

앞서 Real time 처리 된다고 언급 했던 것을 기억하시나요?

 

AudioUnitRender 함수를 호출시 얻어오는 Audio Data가 그 시간의 정적인 Data를 Copy 해오는게 아니라

 

계속 변하고 있는 Memory 의 주소를 가리킨다는 것입니다.

 

공유 메모리와 비슷한 개념으로 이해하시면 될 것 같군요.

 

다만 User level process간 통신이 아니라 kernel 과 User level process간의 공유메모리로 보심이 옳겠죠. 

 

 

 

<Fig3. gdb 로 Bp가 걸려 있는 시점에서 같은 주소를 Dump했을 때 Data가 달라지는 모습>

 

[+] Conclusion 


처리 방식이 상당히 흥미롭습니다.

 

Audio Unit을 사용하는 Process가 많으면 많을수록 Overhead가 줄어들것이고 kernel 과의 통신을 통해

 

sandbox 의 존재 의의를 지켰다는 점에서도 이 감성은 높이살만 한 거 같습니다.

 

흠.. kernel의 Audio module 쪽에 접근하여 경계를 깰 수 있다면 이것 또한 재밌는 이슈가 되겠네요.

 

내용 정리는 위키에게 맡깁니다.

 

 

 

다음 포스팅은 iOS Hooking에 관한 것이 될 거 같군요.

 

올해 안에 다시 뵙도록 하겠습니다 ㅂㅂ

 

 

Posted by LinkC

블로그 이미지
LinkC

태그목록

Tistory Cumulus Flash tag cloud by BLUEnLIVE requires Flash Player 9 or better.

공지사항

Yesterday301
Today84
Total298,301

달력

 « |  » 2018.02
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      

최근에 받은 트랙백

글 보관함


. .