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
이전버튼 1 2 3 4 5 6 7 8 9 ··· 29 이전버튼

블로그 이미지
LinkC

태그목록

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

공지사항

Yesterday49
Today11
Total323,945

달력

 « |  » 2018.12
            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          

최근에 받은 트랙백

글 보관함


. .