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

2011.05.11 18:34 System

[+] Beginning



약 1년 전에 Google Chrome에서 웹페이지가 로딩 되지 않는 것에 대한 포스팅을 했습니다.

http://linkc.tistory.com/entry/Google-Chrome-Loading-Problem

sandbox 옵션을 사용하지 않으면 해결되는 문제였죠.

그 땐 그런가 보다 하고 넘어갔는데, 최근 다시 그런 문제가 생겨

왜 이런 문제가 일어나는지 , 해당 옵션을 사용하지 않으면 정상적으로 동작하는지

한 번 살펴보기로 했습니다.


[+] Problem



앞서 설명했던 대로입니다.

Chrome을 실행 하면 웹 페이지가 로딩 되지 않습니다.

또 가끔 페이지가 로딩 되더라도 다음과 같은 메세지를 뱉으며 죽어버리기 일수죠.

<Fig1. 크롬이 오류를 내며 죽는 경우>

개발자들의 센스가 보이는 문구네요. 귀엽죠?

<Fig1-2. 귀여워>


크롬을 실행 할 때는 물론, 실행 중에도 간혹 페이지가 뜨지 않는 현상이 발생합니다.


[+] Analysis


 

1. Session 및 Desktop의 생성

크롬은 Sandbox 기능을 사용하고 있습니다.

다음은 실제 크롬을 막 실행 시킨 직후의 모습입니다.


  <Fig2.  메인 크롬 Process의 WindowsStation>



크롬은 각 탭 하나마다 새로운 자식 프로세스를 생성하며, 탭 이외에도 Plug in 이나 확장프로그램을 사용하면 하나씩 늘어납니다.

<Fig2>를 찍을 땐 , 모든 확장 프로그램을 작동 중지한 상태에서 찍어서 2개만 떴지만, 실제 사용하는 확장 프로그램을 모두

사용하면 6~7개 정도의 크롬이 등장합니다.

아무튼 <Fig2>를 보면 아시겠지만 크롬의 WindowStation이 WinSta0 이외에도 하나 더 생성되어 있는 것을 확인할 수 있습니다.

WindowStation?

Session의 하위 개념입니다.

Session > Station > Desktop > Process 순으로 보시면 되겠네요.

자세한 사항은 다음 블로그에 상당히 정리가 잘 되어있으니 참고하시면 도움이 될겁니다 :D

http://www.benjaminlog.com/tag/%EC%9C%88%EB%8F%84%EC%9A%B0%20%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%85%98



메인 프로세스는 이렇게 2개가 혼재하고 일반 탭의 자식 프로세스는 가장 하단의 WindowStation인 Service 어쩌구 하는

Station 만 존재합니다.

<Fig3. CreateWindowStation을 호출하여 Station을 만드는 모습 >

이후에 GetUserObjectInformation 을 이용하여

만든 Station의 이름을 가져옵니다.

<Fig4. GetUserObjectInformation을 호출하여 이름을 얻어온 모습. Service ~ >

확인해보면 <Fig2>와 같은 형식을 지닌 것을 알 수 있죠.

이후 호출하는 함수를 따라가보면 다음 함수를 호출합니다.

<Fig5. CreateDesktop을 호출하여 Fig3에서 생성한 Station 내부에 Desktop을 생성한 모습>

sbox . Sand Box 를 의미하는 것이겠죠?

0xD64 는 해당 메인 Process 의 PID 입니다.



2. Process 생성

<Fig6. CreateProcessAsUsesr를 호출하여 Process를 생성하는 모습>

해당 함수를 MSDN에서 살펴보면

<Fig7. MSDN에서 살펴본 CreateProcessAsUser>


CreateProcess 와 다른 점은 첫번째 인자가 추가되었다는 점 하나 뿐입니다.

이 hToken 값은 생성될 User의 Handle값이 되겠죠.

그리고  STARTUPINFO  구조체의 lpDesktop 변수에 앞서 생성해준 Station 과 Desktop 정보가 들어갑니다.

또한 , 바로 실행하지 않고 Suspend 상태로 Process를 생성하구요.

흠. 보통 일반적인 Process를 생성하는 방법과는 약간 차이가 있네요.

이후에 CreateJobObejct 를 통해 미리 생성해둔 Job에

AssignProcessToJobOjbect 를 통해 Fig6에서 생성이 완료된 Process를 Job에 추가시킵니다.

Job은 일련의 속한 Process에게 공통적인 정책을 적용하기 위해 사용한다고만 알아두시면 될 것 같네요.



3. Check Integrity

이 후 메모리의 무결성을 검사합니다.

이 무결성을 통과하지 못하고 문제가 발생한 경우는 제가 확인했을 때 IAT Hooking 이 이루어질 때 였습니다.

[ 다른 경우가 있다면 알려주세요! ]

해당 Hooking을 거는 프로그램이라고 하면 보안 프로그램이나 악성 프로그램정도가 되겠죠.

Sandbox 내에서 생성된 탭은 일반적인 방법으로는 Hooking 이 되지 않기 때문에

[ 물론 외부 Process와 통신이 필요한 tab은 Sandbox로 생성하지 않습니다. 그런 tab은 Hooking 이 걸리게 되죠. ]

부모, 자기 자신의 Process만 검사하는 것으로 보입니다.

체크후에는 VirtualAllocEx를 통해 Sandbox에 생성한 Process의 메모리에 접근합니다.

제가 확인한 경우는 2가지 입니다.

첫번째는 VirtualAllocEx에서 해당 Process로 접근 하는 메모리에 권한을 주지 않는 방법으로 차단하는 경우,

두번째는 특정 함수를 선택하고  ReadProcessMemory 를 이용하여 Hooking이 되었는지 여부를 확인하고 차단 하는 경우


입니다.

2가지 프로그램 밖에 테스트 해보지 않았지만 다른 것도 비슷할 것으로 보입니다.




4. Terminate Process Or Resume Process

3번의 Integrity 를 통과하지 못하면 Process를 Terminate 합니다.

Terminate Process가 실패하면 GetExitCodeProcess을 통해서 Process를 종료하구요.

뭐 통과를 하게 되면 생성해둔 Process를 다시 동작시킵니다.



5. Conclusion

<Fig2>를 보면 아시겠지만 크롬은 최소 Process가 2개 입니다

하나는 부모 Process , 하나는 탭에 할당된 Process죠.

부모는 다른 Station에서 실행되고 있는 Process를 Control 하는 역할을 하게 되고

실제 페이지를 뿌려주는건 자식 Process 입니다.

만약, 3번 Check를 통과하지 못했다면 결과적으로 남는 것은 부모 Process 하나 뿐입니다.

이렇게 되면 페이지를 탐색할 자식 Process가 없는 꼴이 되니 정상적으로 실행 될 수 없다는 겁니다.

이해 되시나요?

물론 Plug in 이나 확장 프로그램도 모두 실행이 안되더군요.





[+] Solution



정리하자면

1. IAT Hooking을 거는 특정 프로그램을 종료시킨다.

2. [ 위 Hooking을 거는 Process가 사용자 권한일 경우에 한함 ] 크롬을 관리자 권한으로 실행시켜 Hooking을 못 걸게 한다.

3. 크롬에 --no-sandbox 옵션을 줘서 실행한다.



정도가 되겠습니다.

해당 문제 때문에 크롬을 못쓰는 분들이 해결 하시고 잘 사용하실 수 있길 기원합니다 :D


Posted by LinkC

2010.05.28 10:55 Etc../잡담

저는 설치, 실행 모두 잘되었는데

지인이 안된다고 하더군요

크롬을 실행 시켰을 때 , 로드 중 이라는 말만 뜨고

사이트가 안뜨는 상황입니다

IE Tab으로는 열어지던데 왜 안되나 했죠

뭐 동기화 문제라는둥.. 악성코드 문제 일수도 있다는 둥

여러가지 설이 있었지만

명확히 답을 제시해주는 곳은 못찾았습니다

그때 발견한데 이 동영상인데요




확대해서 보시면 아시겠지만

크롬 등록정보에 가셔서

-no-sandbox 를 추가해주시면 됩니다



sandbox 가 뭔고 하니

Java 가 지원하는 기본 보안 소프트웨어 더군요

외부에서 받은 프로그램을 자바 가상 머신 [ Java Virtual Machine ]  , 보호 영역에 가둔뒤

작동 시키는 방법이라고 하는구요

sandbox 에서 접근을 허용한 애플릿은 시스템 작업이 가능하지만,

그렇지 않은 경우는 로컬 파일을 읽거나 바꿀수 없게 만들어 시스템 피해를 방지한다는 거죠



이게 왜 충돌이 난지는 모르겠습니다만..

아무튼 저런 옵션을 주시면 정상적으로 보실 수 있을 겁니다 :D



* 이 방법으로도 되지 않는다면 관리자 권한으로 실행시켜주시면 될껍니다




'Etc.. > 잡담' 카테고리의 다른 글

Is Dll injection on Windows7 impossible?  (0) 2010.06.22
Hacker Space?  (1) 2010.06.14
Google Chrome Loading Problem  (4) 2010.05.28
[ Tistory ] 초대장 발급!  (5) 2010.05.26
What is QR Code?  (0) 2010.05.17
[ 해커 간담회 ]  (0) 2010.05.04
Posted by LinkC
이전버튼 1 이전버튼

블로그 이미지
LinkC

태그목록

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

공지사항

Yesterday32
Today19
Total315,771

달력

 « |  » 2018.08
      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 29 30 31  

최근에 받은 트랙백

글 보관함


. .