iOS 입문

@codemaru · June 05, 2014 · 15 min read

#0

iOS    md 0
Android 78.1%, iOS 17.6%, Windows Phone 3.0%, From IDC

아이폰 하면 무슨 느낌이 드시나요? 제가 처음 쓴 맛폰이 갤s였고, 그 담에 아이폰4를 썼습니다. 갤s 쓰다가 아이폰4를 쓰니 신세계였죠. 갤s는 좀 아니었거든요. 아이폰4는 그랬습니다. 견고하고 빈틈없고 단단했습니다. 된다고 약속한 기능은 확실하게 동작했습니다. 아이폰4를 쓰면서 음악이 튀는 현상을 저는 경험해 본 적이 없었습니다. 쓸만한 스마트폰이었습니다. 하지만 결정적인 단점이 있었는데 바로 제 폰이 아니라 잡스횽 폰 같다는 느낌이었습니다. 저는 폰에 있는 파일들이나 시스템 설정들 또는 제가 필요한 데이터를 알아서 잘 관리할 수 있음에도 아이폰은 저에게 그런 여지를 허락하지 않더군요. 윈도용 아이튠즈는 정말 가관이었습니다. 다시 안드로이드 폰으로 갈아탈 수 밖에 없었죠. 그렇게 안드로이드 입문을 한지도 일년 넘는 시간이 지났습니다.

그간 아이폰의 시장 점유율을 유심히 지켜보았습니다. 내심 속으로는 아이폰의 점유율이 과거 맥이 그랬던것처럼 쪼그라들길 바랬습니다. 하지만 그건 단순한 제 바램일 뿐이었습니다. 아이폰은 너무나 견고하게 자신만의 독자적인 세력과 점유율을 유지하고 있는 것처럼 보여집니다. 네 맞습니다. 아이폰 코딩을 시작할 시점이 됐다는 말이죠. 멀티 플랫폼 시대의 개발자는 정말 피곤한 직업인 것 같습니다. 과거 윈도우만 해도 먹고 사는데 문제가 없었던 시절이 그립네요. ㅋㅋ~

#1

많은 사람들이 아이폰 보안이 좋다고 이야기합니다. 견고하다고 하죠. 안드로이드가 그렇게 두드려 맞는 동안에도 아이폰은 크게 이슈가 없었던 것 같습니다. 전 뭐 엔지니어로써 아이폰이라고 그닥 크게 보안성이 뛰어나다고 생각하진 않습니다. 막아 놓은 것들이 많고 사용자가 안드로이드 대비 적으니 덜 뚫린다고 생각하는 입장입니다. 어쨌든 그렇게 첩첩산중 막고 또 막고, 가리고 또 가리고, 숨기고 또 숨기고 해서 아이폰을 구매한 사용자에게는 제법 안전하다는 인식을 제공하고 있는 것 같습니다. 그렇다면 앱스토에 앱을 올리는 개발자 입장에서는 어떨까요?

iOS    md 1
알만한 사람들은 다 아는 치트계의 블루오션 iOS

맞습니다. 지옥이죠. 그 잘난 샌드박스 덕분에 여러분이 할 수 있는건 아마 거의 없을 겁니다. 아이폰을 구매한 사용자가 맘먹고 앱을 공격하겠다고 생각하는 순간 앱은 감옥(샌드박스) 속에서 속수무책 당할 수 밖에 없습니다. 요즘 치트 좀 하는 사람들은 다 공공연히 알고 있는 사실이지만 아이폰은 치트계의 진정한 블루오션입니다. 앱을 보호해 줄 그 어떤 보안장치도 없거든요. 여러가지 이유가 있지만 삼성 공화국인 국내에서는 사용자가 많지 않아서 다소 무시 당했다는 점도 한 몫 했다고 봅니다. 하지만 더이상 그렇게 방치하기에는 아이폰 점유율이 무시할 수준은 아닌 것 같습니다. 아이폰이 독점적인 점유율을 누리는 국가들도 있고, 탈옥을 하지 않고도 앱을 위변조해서 사용하는 기법들도 속속 등장하는 지금, 이제는 뭔가 필요할 때가 되긴 한 것 같습니다.

#2

iOS    md 2
Objective-C도, BSD도, MACH도, 샌드박스도 아니었다. 최고의 진입장벽… 맥 그 자체!!!

치트의 공격에 손가락만 빨고 있는 여린 앱들을 위해서 iOS 연구를 시작했습니다. 맥 미니도 사고, 버렸던 아이폰4도 다시 켜서는 운영체제 업데이트도 했습니다. 애플에 개발자 등록도 하고 드디어 Xcode를 켰습니다. 이제 아이폰의 속살을 좀 들여다 볼까 하는데 난관에 봉착했습니다. 아이폰 개발은 그렇게 바로 시작할 수 있는게 아니더군요. 내 아이폰에 내가 만든 코드를 넣기 위해서는 여러 수십만 단계를 더 거쳐야 한다는 사실을 알게 되었습니다. 헐~ 블로그 검색질로 따라하면서 온갖 인증서를 만들고 온갖 디바이스 정보를 넣어서 등록을 했습니다. 드디어 모든 단계를 마쳤다고 생각했는데 거기가 또 끝이 아니더군요. 맥에서 아이폰을 인식하지 못하는 아스트랄한 상황이 벌어진 것이었습니다. Objective-C를 쳐다보기도 전에 탈진할 것 같은 상황. 모든 iOS 개발자들이 존경스러워지는 순간이었습니다.

장치관리자가 있긴 있는건지?! 이 상황을 어떻게 해야 하는건지 도무지 몰라서 맥 좀 사용한 친구 녀석한테 어케 해야 하냐고 물어봤더니 아이튠즈를 다시 설치하라고 하더군요. 그렇게 몇 번의 재부팅을 거치고 나서야 드디어 마법처럼 인식이 되었습니다. 아이폰4 화면에 텅 빈 Hello, World! 앱이 뜨는데 뻥 좀 보태서 예전 X 윈도우를 처음 띄우고는 X 아이콘을 마주했을 때처럼 눈물이 약간 났습니다.

#3

어떤 시스템에서 동작하는 보안 솔루션을 만들기 위해서 제일 처음 검토해야 하는 것은 당연한 소리겠지만 우리가 할 수 있는 것과 할 수 없는 것을 구분하는 작업입니다. 그래야 그 시스템에서 우리가 만들 수 있는 것과 만들 수 없는 것을 명확하게 알 수 있거든요.

iOS의 속살을 파헤치기 전까지 저는 그저 안드로이드와 유사한 권한 체계를 통해서 운영체제를 구성했다고 생각했습니다. 다만 안드로이드가 읽기 권한을 줬다면 iOS는 읽기 권한 마저 제거했다고 어렴풋이 추측했을 뿐이었죠. 하지만 완전 번지수를 잘못 짚었던 착각이었습니다. iOS는 단지 리눅스/BSD의 기본 권한 체계를 사용한 권한 장난질로 샌드박스를 구현하고 있는 게 아니었습니다. 진짜 샌드박스가 있는 구조더군요. 이 말은 우리가 특정 파일에 접근할 수 있는 모든 권한을 가졌다 하더라도 샌드박스에서 그 파일 접근을 불허하면 파일 열기에 실패한다는 이야기입니다. 그럼 iOS 샌드박스가 어떤 것들을 제한하는지 한 번 살펴봅시다.

iOS — the Sandbox as a jail

  1. Inability to break out of the app’s directory. The app effectively sees its own directory (/var/mobile/Applications/) as the root, similar to the chroot (2) system call. As a corollary, the app has no knowledge of any other installed apps, and cannot access system files.

역주: 너희 영역 말고는 쳐다볼 엄두도 내지 마셈. 백신?! 스캐너?! 만들 수도 없고 만들 필요도 없음.

  1. Inability to access any other process on the system, even if that process is owned by the same UID. The app effectively sees itself as the only process executing on the system.

역주: 다른 프로세스 접근?! 꿈도 꾸지 마셈. 번지수 잘못 짚었음.

  1. Inability to directly use any of the hardware devices without going through Apple’s Frameworks.

역주: 우리가 만들어 준 것만 우리한테 허락 받고 쓰셈. 필요해도 없으면 그냥 손가락만 빨도록…

  1. Inability to dynamically generate code. The low-level implementations of the mmap (2) and mprotect (2) system calls are intentionally modified to circumvent any attempts to make writable memory pages also executable.

역주: 난독화? 그딴거 만들고 싶어도 못만들거임. 정 만들고 싶으면 인터프리터, 트랜슬레이터 정도 고려해보셈.

  1. Inability to perform any operations but a subset of the ones allowed for the user mobile. Root permissions for an app (aside for Apple’s own) are unheard of.

역주: 우리 혼자 짱짱맨. 서드파티가 뭔가요? 씹어먹는 건가요?

– Mac OS X and iOS Internals, Jonathan Levin

말 그대로 감옥이죠. 되는 게 없다고 보는 게 맞는 것 같습니다. iOS는 아니지만 맥 OS의 샌드박스 기능이 궁금하신 분들은 The Apple Sandbox를 같이 참고해 보시면 도움이 될 것 같습니다.

#4

iOS 샌드박스를 보면서 느낀 점은 구글과는 정말 철학 자체가 다르다는 생각이었습니다. 구글의 안드로이드는 아래 크로미움 샌드박스 디자인 원칙에 나와 있는 것처럼 기존의 있는 것을 활용하자는 생각이 강합니다. 바퀴를 새로 만들지 말자는 입장이죠. 그래서 안드로이드도 권한 장난질로 얄팍하게 흉내낸 샌드박스 구조로 되어 있습니다. 물론 세세하게 TrustedBSD까지 올라가서 바퀴를 누가 만들었냐를 따지자는 것도 아니고, 옳다 그르다를 따지자는 것도, 좋다 나쁘다를 가리자는 것도 아닙니다. 그간 애플의 행보를 보자면 바퀴를 새로 만드는 것을 좋아하는 것처럼 느껴졌다는 이야깁니다. 적어도 저한테는요…

Design principles

Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don’t. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model.

역주: 기술 부심 부리겠다고 바퀴 따위 새로 발명하지 말자.

Sandbox, The Chromium Projects

#5

iOS    md 3
XIGNCODE3의 역사가 iOS에서도 함께합니다.

그닥 쉽지는 않았습니다. 맥을 새롭게 익히는 것도 Xcode에서 Objective-C++ 접착제 코드를 만드는 것도, BSD 시스템 콜을 익히는 것도요. BSD에서 시스템 프로그래밍을 해본 경험은 없고, 맥은 더더욱 새롭기에 이 생경한 시스템에 익숙해지는 것은 생각보다 쉽지 않았습니다. 물론 샌드박스도 한 몫 했지요. 여튼 그런 아주 험난한 과정을 거치긴 했지만 결국 우리가 안드로이드에서 사용했던 대다수 기법들이 거의 모두 아이폰에도 동일하게 적용할 수 있다는 사실을 확인했습니다. 이제 곧 XIGNCODE3 for iOS가 출시된다는 말이죠.

이 글이 재앙이 될 프로그래머 분들을 위해서 초콜렛을 하나 준비했습니다. 애플이 굉장히 폐쇄적인 줄 알았는데 생각보다 거의 오픈 소스에 가깝더군요. BSD 라이선스라 굳이 그럴 필요도 없을 것 같은데 말입니다.

xnu 커널 소스 코드

http://opensource.apple.com/source/xnu/xnu-2422.90.20/

top 소스 코드

http://opensource.apple.com/source/top/top-89.1.2/

ps 소스 코드

http://opensource.apple.com/source/adv_cmds/adv_cmds-153/ps/


일단 폰부터 테스트 하구요. 패드는 그 다음에 하는걸로…

애플빠는 아닙니다. 결코 ㅋ~

#6

iOS    md 5
iOS 버전도 준비 중이신가요? 그럼 더더욱 XIGNCODE3죠.

느낌아니까… ㅋ~

@codemaru
돌아보니 좋은 날도 있었고, 나쁜 날도 있었다. 그런 나의 모든 소소한 일상과 배움을 기록한다. 여기에 기록된 모든 내용은 한 개인의 관점이고 의견이다. 내가 속한 조직과는 1도 상관이 없다.
(C) 2001 YoungJin Shin, 0일째 운영 중