AirenSoft Story

쇼스페이스 갤러리가 오픈하였습니다.

(Getroot) — Wed, 01 Apr 2009 18:04:42 +0900

현재 많은 분들이 쇼스페이스를 이용해서 개인 사진첩을 만들고 계십니다. 감사드립니다.

자신의 사진첩을 공개하여 공유할 수 있는 쇼스페이스 갤러리가 오픈하였습니다.
http://www.showspace.co.kr 에서 오른쪽 상단의 쇼스페이스 갤러리를 클릭하거나 http://www.showspace.co.kr/gallry로 접속하시면 됩니다.

쇼스페이스 갤러리는 쇼스페이스를 이용하여 만든 사진첩을 많은 사람들이 보고, 퍼갈 수 있게 하는 오픈 갤러리 입니다. 물론 쇼스페이스의 정책이 개인 정보 보호이기 때문에, 아래 그림 처럼 사진첩을 만든 후 하단에 있는 발행 버튼을 눌러야만 갤러리로 올라가게 됩니다.

많은 이용 부탁드립니다.

감사합니다

Phishing

(Getroot) — Thu, 12 Mar 2009 10:11:54 +0900

Phishing은 Fishing과 Private Data의 합성어로서 social engineering을 이용하여 사용자의 중요한 정보를 가로채는 해킹 기법이다. 주로 거짓 e-mail을 사용자에게 전송하여, attacker가 customer로부터 얻고자 하는 데이터가 존재하는 site와 똑같이 위장한 site로 유인하여 사용자의 id, password, credit card number등 financial data를 가로채는데 사용한다.

Phishing은 사실 hacking technique 보다는 사기에 가깝다. 특별히 기술적 장벽이 높은 것이 아니고 누구나 똑 같은 site를 만들어 그 site로 어떤 방법으로든 유인하여 customer로부터 정보를 입력하게 하면 되기 때문이다. 또한 Phishing은 social engineering이기 때문에 이를 기술적으로 방어하는 것은 거의 불가능에 가깝다. 때문에, Phishing을 통한 피해가 크게 증가 하고 있으며, 보안을 연구하는 사람들에게 Phishing의 보안은 가장 큰 이슈가 되어가고 있다.

New Phishing Sites by Month December '04 - December '05 : AntiPhishing.org

이 글에서는 공격자가 사용자를 어떻게 속이는지 그 social engineering을 소개하고 그를 통해 어떻게 phishing으로부터 자신의 중요 데이터를 보호할 수 있는지 소개할 것이다.

위장 사이트로

Phishing 을 하기 전 공격자는 private data를 얻으려는 사이트와 비슷하거나 똑같은 사이트를 제작한다. 이렇게 제작하는 것은 해당 사이트에서 서비스 하고 있는 웹파일들을 그대로 다운로드하여 제작하면 되므로 고도의 공격 기술이 필요한 것이 아니기 때문에 누구나 할 수 있다. 그래서 가장 많은 Phishing 공격 방식이다. 그리고 사용자를 좀 더 잘 속일 수 있기 위해 도메인을 비슷하게 제작하기도 한다.

예전 기업은행 사이트와 똑같은 모양을 가지고 있지만, 사실 기업은행 사이트가 아니다.

위장 이메일

위장된 사이트로 접속을 유도하기 위해 주로 이메일을 사용한다. 그 내용으로는 유명 은행, 카드사 등을 사칭하며 계좌번호, 카드번호, 비밀번호 등의 확인 또는 갱신을 유도하거나 이러한 조치를 취하지 않을 경우 거래가 중지 된다는 식의 소란을 일으키거나 자극적인 문구를 이용한다. 또는, 포털 사이트나 쇼핑몰 등을 사칭해 경품 당첨 안내나 이벤트 참가 등을 유도하며 주민 번호, 핸드폰 번호 등의 개인 정보를 입력하도록 유도하기도 한다. Phishing 사이트로 유도하기 위해 e-mail 내에 하이퍼링크를 넣어 그것을 클릭하면 phishing 사이트로 연결되도록 하는데 사용자를 좀 더 신뢰하게 하기 위하여 figure 3처럼 링크의 이름을 정상 적인 사이트로 설정하고 실제로 연결되는 사이트는 phishing site로 하는 방식을 사용한다.

위장된 Windows Domain Name Setup

MS-Windows에는 로컬에서 로컬에서만 사용하는 별도의 도메인 네임의 설정 방법을 제공하는데 스파이웨어가 이를 수정하여 사용자를 phishing 사이트로 유도시키기도 한다. 일반인에게 이와 같은 설정이 널리 알려지지 않아 의외로 잘 걸리지 않고 오랫동안 지속되는 방식이다. 이 설정은 C:\윈도우 설치 FOLDER\system32\drivers\etc에 hosts 파일로 설정할 수 있으며 [IP Address] [URL]을 설정하면 해당 URL을 입력했을 때 Domain name server에 쿼리하지 않고 이 파일에 있는 대로 연결된다. 이 파일이 스파이웨어를 통해 조작된 모습은 다음 그림을 통해 볼 수 있다.

로컬 도메인 설정

위 그림을 보면 www.daum.net의 실제 IP는 222.231.51.77이지만 61.251.196.31로 설정되어 있는 것을 확인 할 수 있다.

URL HIjacking

위장된 Windows Domain Name Setup과 같은 동작을 하는 방식으로서 BHO나 기타 스파이웨어가 사용자의 웹연결을 감시하다가 해당 URL로의 연결을 후킹하여 다른 사이트로 변경시키는 기술이다.

Popup Window

어떠한 사이트의 hyperlink를 클릭하여 다른 사이트로 연결 될 때, iframe tag를 이용하여 해당 사이트에 팝업 윈도우를 띄울 수 있다. 사용자는 마치 연결된 사이트에 띄우는 팝업으로 착각하고 그 내용을 신뢰하는 경향이 있는데 이를 이용한 phishing도 많이 존재한다. 주로 성인 사이트 같은 곳에 글을 올려 이 사이트에 접속하면 경품을 준다는 식으로 사용자를 유도한다.

Phishing 방어 지침
이 외에도 messenger worm이 속임수 메시지와 함께 특정한 url을 전송하여 messenger를 통해 phishing을 유도하는 경우가 과거에 종종 있었으며 기타 phishing을 위한 아주 많은 기술이 존재한다. 이렇게 다양한 phishing 공격과 앞으로 새롭게 생길 수 있는 다른 방법의 공격을 방어하기 위해선아직 기술적으로 완벽하게 방어할 수 있는 방법이 없으므로 다음과 같은 사항을 명심하고 실천해야 한다.

로그인 과정, 확인 또는 표시 되는 정보가 합법적인 사이트와 같이 정밀해 보이지 않는다면 의심해본다.
필요 이상으로 많은 것을 묻는다. Phishing 사이트는 일반적으로 요구되지 않는 추가적인 확인 정보나 개인 정보를 물어볼 가능성이 크다.
Spyware에 감염되지 않았는지, 여러 가지 Spyware 치료 툴로 주기적으로 검사하고 치료한다.
웹 사이트에 접속 할 때 보안 접속을 할 수 있는 버튼이 없다. 합법적인 금융 사이트는 보안 접속을 대부분이 지원한다.
브라우저에서 SSL 인증서 문제를 경고한다. SSL 인증서가 Spoofing되면 브라우저에 보안 경고 메시지가 표시된다. 그 메시지를 무시하지 말고 반드시 인증서을 확인하여 해당 사의 이름이 들어가 있는지 확인해 봐야 하며, 이런 경고는 사기범들이 만든 웹 사이트를 나타내는 명백한 징후로 받아들여야 한다.
메일을 통해 금융 정보를 변경하라는 메일이 온다면 해당 회사에 전화를 걸어 직접 환인해 본 뒤, 메일의 link를 클릭하여 연결하지 말고 웹 브라우저에 직접 url을 입력하여 연결해야 한다.

Reference

[1] Anti-Phishing Working Group, http://www.antiphishing.org
[2] Korea Information Security Agency, http://www.kisa.or.kr

Blind TCP/IP hijacking is still alive(TCP 하이재킹)

(Getroot) — Thu, 12 Mar 2009 10:10:30 +0900

이 글은 권위있는 인터넷 해킹/보안 전자 잡지인 Phrack Magazine의 64호에 1km이 기고한 글을 참고하여 재 구성한 글입니다. 이 글을 보고 깊은 감명을 받아서 글을 쓰기 시작하였습니다. 이 글에서 소개하고 있는 기법 그 자체가 뛰어난 해킹 방법이거나, 높은 테크닉이라서가 아닌, 해커로서 갖춰야할 사물에서 문제를 추출해 낼 수 있는 통찰력 그 자체가 뛰어나기 때문에 많은 사람들과 이 글을 공유하고 싶었습니다. 해킹은 어떤 사실에서 문제를 발견해 낼 수 있는 통찰력과 그 통찰력을 실험해볼 수 있는 기술로 이루어집니다. 기술은 공부를 통해 배울 수 있지만, 통찰력은 쉽게 만들어지는 것이 아닙니다. 몇년 몇날을 계속 생각하고 스스로의 경험과 안목을 키워야 합니다. 예를 들어 파란 약을 먹으면 그림 속으로 들어가고, 빨간 약을 먹으면 그림 밖으로 빠져나온다라는 사실이 있을 때, 해커라면 좀 더 넓은 시야로, 그렇다면 그림 밖에서 빨간약을 먹으면 어떻게 되는가?를 고민해볼 수 있어야 합니다. 각설하고, 다음 소개시켜드리는 해킹 방법은 이런 통찰력이 탁월하게 발휘된 방식이니 한번 같이 보면서 익혀보겠습니다.

본 글의 원문은 http://phrack.org/issues.html?issue=64&id=15#article 를 통해 볼 수 있는데, 어찌된 일인지 지금 접속되지 않습니다.

Introduction

우리가 흔히 쓰는 웹, FTP, 각종 온라인 게임, 메신져 등 거의 대부분의 온라인 서비스는 TCP 프로토콜을 사용합니다. TCP 프로토콜은 연결 지향적이라 보안상 신뢰할 수 있기 때문입니다. 보안상 신뢰할 수 있다는 것은 서버가 A라는 호스트로부터 패킷을 수신하였을 때 A라는 IP를 가진 호스트가 보내는 패킷은 모두 A가 보냈다고 신뢰할 수 있다는 것입니다. 이것은 TCP가 패킷을 주고 받기 위해 Sequence number(SEQ)와 Acknowledgement number(ACK)를 이용하기 때문입니다.

위 그림은 TCP의 초기 연결을 도표화 한 것입니다. 두 호스트(클라이언트, 서버)가 초기에 연결을 맺을 때 3 way handshake 방식을 이용합니다. 3 way handshake 방식은 3개의 약속된 패킷을 주고 받아 연결을 맺는 방식입니다. 처음 연결을 시도할 때 클라이언트와 서버는 Initial Sequence Number(ISN)을 발생시킵니다. 초기 연결을 맺으려고 하는 클라이언트가 ISN 5000을 발생시켜 SEQ에 넣어서 서버에 전송하면 서버는 이 ISN에 전송받은 패킷의 크기를 더해서 ACK에 넣어서 응답 패킷으로 돌려줍니다. 위 그림에서도 서버가 응답하는 패킷의 ACK가 5001이라는 것을 보실 수 있습니다. 클라이언트가 5001이라는 ACK를 받아보면, 진짜 서버에서 돌아온 응답인지 신뢰할 수 있게 됩니다. 서버가 ACK를 넘겨줄 때 서버 또한 ISN을 발생시켜서 SEQ에 넣어서 전송해줍니다. 클라이언트는 이 ISN 패킷을 받아서 받은 패킷 크기를 더해서 다음 응답 패킷의 ACK에 넣어서 넘겨줍니다. 이것을 통해 두 호스트는 서로를 완전하게 신뢰하며 연결되는 것입니다. 이렇게 하지 않으면 1.1.1.1이라는 IP를 달고 나에게 접속을 시도하는(ISN을 전송하는) 호스트가 진짜 1.1.1.1인지 알수가 없습니다. 그렇기 때문에 1.1.1.1에 192931라는 응답을 보내고, 1.1.1.1이 다시 192931이라는 값을 응답하면, 1.1.1.1이 진짜인지 알 수 있게 되는것이죠.

여기서 한가지 의문이 들 수 있습니다. 클라이언트와 서버가 보내는 패킷을 보다가 다음 ACK를 예측하여 IP를 클라이언트의 IP로 수정한 후 순간적으로 클라이언트보다 서버에 먼저 응답한다면 서버는 그 패킷을 받아들이는가 하는 것입니다. 예 맞습니다. 그것이 바로 TCP/IP Hijacking 입니다. 과거에는 꼭 클라이언트와 서버의 패킷을 모니터링 하지 않아도 이 SEQ와 ACK를 어느정도 유추할 수 있는 방법이 있었습니다. 그것은 예전 운영체제가 ISN을 정해진 공식에 의해서 발생시킨다는 것이였는데, 예를 들어 내가 서버에 접속했을 때 ISN이 1000이였다면, 그 다음에 접속할 때 ISN이 1001이 되는 식의 방법이였습니다. ISN만 예측할 수 있다면 내 IP를 바꾸어서 서버에 충분히 접속할 수 있게 됩니다. 만약 서버가 1.1.1.1이라는 IP를 신뢰하여 모든 명령을 받아들이는 상태라면 1.1.1.1로 자신의 IP를 바꾸어 서버에 명령을 내릴 수 있겠죠. 물론 서버의 응답을 받을 순 없지만, 패킷을 받아들이게 하는 것 만으로도 수많은 것을 할 수 있을 것입니다. 하지만 최신 OS는 당연히 ISN을 랜덤하게 발생시켜서 예측할 수 없게 만들고 있습니다. 해커들이 IP-Spoofing과 Hijacking을 구분하는 것은 이와 같이 처음부터 IP를 바꾸어 서버에 접속하는 것을 IP-Spoofing이라고 부르고, 아래 그림과 같이 통신하는 중간에 자신이 패킷을 껴넣어 의도하는 명령을 내리는 것을 Hijacking이라고 구분합니다. 물론 모든 해커들이 이렇게 구분하는 것은 아니고, 이 구분 자체를 하지 않는 해커들도 있습니다.

지금까지 내용으로, 위 그림과 같이 TCP 세션에서 Hijacking을 하려면 어떻게 해야 할까요? 첫번째로 IP를 바꾸고, ACK를 유추해서 서버에 패킷을 보내면 될것입니다. 서버는 ACK만 맞다면 패킷을 받아들여서 정상 사용자가 내린 명령이라고 판단하고 명령을 수행할 것입니다. 관리자의 TELNET 세션을 HIJACKING한다면 서버를 날려버리는 것도 가능할 것입니다. 하지만 ACK를 유추해내는 것은 세션을 실시간으로 모니터링 하지 않는 이상 거의 불가능합니다. 왜냐하면 ACK는 32 bit이므로 2의 32승 만큼의 숫자 범위 내에 있기 때문입니다. 예전 방식으로는 -2의 31승 부터 2의 31승까지 순차적으로 ACK를 만들어 보내는 방법을 사용하였습니다. ACK가 순차적으로 증가하는 버그가 있었기 때문입니다. 하지만 지금은 ACK또한 순차적으로 증가하지 않습니다. 반대로 모니터링 한다면 매우 쉽게 Hijacking할 수 있을 것입니다. ACK가 노출되어 있기 때문입니다. 그래서 세션을 모니터링 할 수 있는 사내망이나 같은 건물의 사용자, 같은 AP 사용자들은 이를 쉽게 할 수 있게 되는 것입니다. 이 사실을 안다면 공공장소에서의 중요한 작업을 자제해야겠습니다.

여기까지의 내용이 지금까지 일반적인 사람들이 생각하는 TCP Hijacking이고 이제는 이 공격으로 부터 안전하다고 많은 사람들이 생각하였습니다. 하지만 이 글을 쓴 1km는 기발한 방법으로 TCP Hijacking을 시도하려고 합니다. 그 방법을 알아보기 전에 미리 알아야 할 것들 몇가지를 더 짚어보겠습니다.

Simple ACK

Simple ACK라는 것은 TCP 헤더에 Payload 사이즈가 50이라고 명시한 패킷이 도착하였지만 Payload가 50이 아닐 경우 Size가 0인 ACK로 에러를 응답하는 것을 말합니다.

Flow control mechanism

플로우 컨트롤은 TCP에서 매우 복잡한 개념입니다. 간단하게 설명하자면 Window라는 사이즈로 플로우를 관리하고, 주어진 시간안에 호스트는 Window 크기 만큼 패킷을 수신해야 한다고 생각하시면 이 글을 이해하는데 큰 문제가 없습니다. 자세한 것은 TCP/IP와 관련된 다른 서적이나 글을 통해 공부해보시기 바랍니다.

TCP Flag

TCP 는 6개의 FLAG를 가지고 있습니다. 각각의 플래그는 1개의 BIT로 켜지고 꺼지는 것으로 TCP 패킷을 속성을 나타냅니다. 각 FLAG는 다음과 같습니다.

SYN - 세션을 설정할 때 사용됩니다.
ACK - SYN에 대한 응답 패킷을 보낼 때 사용됩니다.
FIN - 세션을 종료시키는데 사용됩니다.
RST - 비 정상적인 세션 끊기에 사용됩니다.
PSH - 패킷을 모두 수신할때까지 기다리지 않고 바로 상위 레이어로 패킷을 전달합니다.
URG - 패킷이 순차적으로 상위 레이어로 올라가는데, 이 플래그가 켜져 있으면 바로 전달합니다.

IP_ID

IP 헤더에 포함되어 있는 16-bit 숫자 입니다. 이것은 패킷별로 유일한 값을 가집니다. IP_ID 값은 패킷당 유일한 값이므로 이 값을 이용하여 IP fragmentation(최대 전송 가능한 크기로 패킷을 쪼개는 것)과 Reassembly(쪼개진 패킷을 다시 합치는데)에 사용합니다. Packet 별로 유일한 값을 가져야 하기 때문에 대부분의 OS는 이 값을 Global로 처리하여 모든 프로세스가 하나의 변수를 바라보게 합니다. Window 98, 2000, XP가 모두 그렇습니다. 생각해보면 이 값은 계속 랜덤하게 바뀌면 오히려 최악의 경우 IP_ID가 같은 두개의 패킷이 생길 수 있으므로, 패킷을 전송할때마다 증가시켜서 사용하는 것이 맞습니다. 또 대부분의 운영체제가 그렇게 관리합니다. 다음 그림과 같이 1개의 PING을 받으면 IP_ID 값이 역시 증가하는 것을 보실 수 있습니다.

Hijacking!!!

Hijacking을 하려면 어떤 정보가 필요할까요? 먼저 Hijacking하려는 두개의 클라이언트와 서버를 알아야 할 것입니다. 만약 A라는 클라이언트가 GETROOT라는 서버에 연결되어 온라인 게임을 즐기고 있다. 이것을 Hijacking 하여 내가 중간에 서버에 명령을 내려야겠다고 한다면 우리는 지금 A 클라이언트의 IP, GETROOT 게임 서버의 IP, PORT를 알수 있는 상태일 것입니다. A라는 클라이언트의 IP는 메신져나 채팅, P2P 게임등을 통해 알아냈다고 가정합니다. 이때 우리가 꼭 알아내야 할것이 A 클라이언트의 통신 중인 Source TCP port 입니다. Source port를 알아내야 GETROOT 서버에 내가 A인척 하면서 패킷을 정상적으로 전달할 수 있을 것입니다. 또 클라이언트의 SEQ와 ACK를 알아내야 합니다. 이 3가지 정보를 정확히 생성할 수 있다면 Hijacking이 성공할 수 있습니다.

클라이언트의 포트 알아내기

클라이언트가 서버와 어떤 포트로 통신하고 있는지 알아내는것만으로도 해킹할 수 있는 여지는 매우 높아집니다. 이것을 알아내는것은 생각보다 매우 쉽습니다. 이 방법은 클라이언트와 서버가 현재 통신중이라는 특성과 IP_ID를 이용합니다.
먼저 공격자가 서버에 클라이언트의 IP와 추정한 포트 번호(1~65535) 까지중 한가지로 속여서 서버에 연결 시도 패킷(SYN)을 전송합니다. 서버에서는 클라이언트의 새로운 연결 시도인 것으로 생각하고 연결에 대한 응답 패킷을 클라이언트로 전송할 것입니다. 이때 서버에서 보내는 Destination port 가 클라이언트에 열려있지 않은 포트라면 클라이언트는 열려있지 않은 포트 번호이므로 서버에 RST 패킷을 보낼 것입니다. 이때 클라이언트의 IP_ID는 패킷을 전송하였기 때문에 증가하게 됩니다. 만약 열려있는 포트라면 현재 연결된 세션에 전송된 패킷이고, 분명히 SEQ와 ACK가 틀릴 것이며 새로운 접속을 맺으려고 하는 것이기 때문에 잘못된 패킷으로 생각해서 응답을 보내지 않고 그냥 무시하게 됩니다. 이때 클라이언트의 IP_ID는 증가하지 않게 될 것입니다. 공격자는 IP_ID를 PING 패킷을 전송하여 확인할 수 있습니다. 클라이언트로 PING을 처음 보냈을 때 1이고 두번째 보냈을때 2라면 1개의 패킷당 1씩 증가한다고 추측할 수 있습니다. 이것을 이용하여 서버에 패킷을 보내고 클라이언트의 IP_ID를 확인하여 더 많은 증가가 있었다면 틀린 PORT, 증가가 없었다면 맞는 PORT라고 예측해낼 수 있는 것입니다. 최악의 경우 65535번 확인해야 하지만, 컴퓨터가 돌려서 확인하는 것이므로 아무리 오래 걸려도 1분이면 확인해 낼 수 있을 것입니다. 이 방법은 클라이언트와 서버가 서로 패킷을 주고 받지 않고 있는 상태(사용자가 쉬고 있거나 하는 상태) 라는 가정이 있습니다.

클라이언트의 SEQ와 ACK 알아내기

클라이언트의 SEQ와 ACK를 알아내기 위해서는 최소한 2^32 * 2^32번의 경우의 수를 모두 해봐야 합니다. 이것은 매우 큰 수 입니다. 이만큼의 시도를 서버에 한다는 것은 매우 큰 문제를 일으킬 수 있습니다. 하지만 이것을 IP_ID를 이용해서 조금은 쉽게 추측해낼 수 있습니다.

클라이언트에 서버로 가장하여 역시 SEQ와 ACK를 전송합니다. 맞지 않다면 SIMPLE ACK를 클라이언트가 서버로 전송할 것입니다. 이것은 IP_ID가 증가한다는 것을 의미합니다. 위의 포트를 알아내는 것과 다른 점은 포트를 알아낼때는 서버가 이미 연결된 세션을 향해 새로운 연결 시도 패킷을(SYN) 보냈다는 것입니다. 클라이언트의 IP_ID가 증가하지 않을때까지 계속 랜덤한 SEQ와 ACK를 전송하는 것으로 이 값들을 구해낼 수 있습니다. 서버에는 아무런 패킷을 전송하지 않아도 된다는 것입니다. 이것은 매우 큰 장점입니다.

더 빨리 SEQ와 ACK를 추측할 수 있는 방법을 제시하는데 제가 이해를 잘 못하는 것인지 Brute force 방법과 크게 다른점이 없어 보입니다. 만약 원문을 읽으시고 Brute force이긴 하지만 시도하는 수를 확 줄일 수 있는 방법을 제시했다면 저에게 알려주시기 바랍니다.

마치며...

이 글을 읽으며 Hijacking이 성공하겠다! 라는 느낌보다는 기존에 아무도 버그라고 생각하지 못했던 IP_ID를 이용해 클라이언트의 포트를 알아내고, SEQ, ACK 추측에 서버가 아닌 클라이언트를 이용할 수 있다는 점에, 그리고 가장 큰 문제였던 SEQ, ACK가 맞는지 아닌지 그 답을 알 수 있게 발전시킨점으로 감명을 받았습니다. 누군가가 이 방식을 조금 더 발전시켜서 SEQ와 ACK도 쉽게 추측해낼 수 있는 방법을 제시할 것으로 보입니다. 몇몇 분들은 IP_ID를 랜덤하게 만들면 되지 않겠느냐고 하는데, 예 그것만으로도 이 방법은 사용할 수 없게 됩니다. 하지만 이미 WINDOW 98, 2000, XP가 이 취약점 아닌 취약점을 가지고 있습니다.

제 글은 출처를 명시한다면 누구나 퍼가실 수 있습니다.

웹 해킹 원리와 방어 방법 (하)

(Getroot) — Thu, 12 Mar 2009 09:46:46 +0900

2.1. SQL Injection

SQL injection 은 사용자의 입력이 back-end database에 바로 전달 될 때, 입력에 sql문을 넣어서 DB를 조작할 수 있는 매우 치명적인 공격 방법입니다.

[Web application]
strID = request.getParameter("id");
strPassword = request.getParameter("password");
result = Query("select count(*) from User" + "where id=" + strID+ "password =" + strPassword);
if(result == 1)
{

echo "로그인 성공";

}
[HTML]
<input type="text" name="id">
<input type="text" name="password">

예를 들어 위와 같이 로그인 하는 코드에서 사용자의 입력을 여과 없이 그대로 받아 들인다고 가정합니다. 이 때 name에 getroot'-- 를 입력한다면 어떤 결과가 발생할까요? 쿼리는 SELECT count(*) from USER where id=getroot'-- password = 과 같이 입력될 것입니다. '--는 sql문에서 주석에 해당하기 때문에 id=getroot 까지만 쿼리문으로 인식되어 패스워드의 입력에 상관없이 무조건 getroot로 로그인되는 것입니다. SQL Injection은 이제 서버사이드의 언어 자체에서 거르는 기능을 통해 크게 발생하고 있지는 않지만, 방어를 우회할 수 있는 많은 응용 방법이 나오고 있고, 아직까지 가장 광범위하게 사용되고 있는 공격 방식입니다. 이를 방어하기 위해서는 HTML로 부터 입력을 받을 때 특수 문자나 여러가지 상황을 고려해 방어하거나, 입력받는 문자를 스트링으로 강제 변환하여 받는 방법 등으로 해결해야 할 것 입니다.

2.2. Cross-site Scripting

Cross-site Scripting은 말 그대로 사이트를 넘어 스크립트를 실행하는 공격을 말합니다. 웹서버를 공격하는 방식이 아닌 사이트를 통해 다른 사용자를 공격하는 것 입니다. 게시판과 같이 동적으로 생성되는 Page에 조작된 코드를 넣어서 다른 사용자에게 공격자가 원하는 코드를 실행하게 하며, 이를 통해 다른 사용자의 쿠기를 자신의 메일로 전송하게 하거나, 다른 사용자에게 악성 코드를 설치하는 등 여러가지 공격을 수행합니다. 몇년 전 한 해커가 리니지 게임의 아이디와 패스워드를 빼내기 위해 리니지 커뮤니티에 악성 코드를 올려놓고, 감염된 사용자의 아이디와 패스워드를 대량으로 빼내가서 사회적으로 큰 이슈가 되었던적이 있었습니다. 그리고 윈도우에서 그래픽 파일을 처리하는 과정에서 발생하는 Buffer overflow를 이용하여 웹에 조작된 그림 파일을 올려놓고, 다른 사용자가 그 그림을 보는 것 만으로도 악성코드가 PC에 설치되게 했던 공격도 있었습니다. 싸이월드의 방문자 추적 시스템도 이와 같은 공격 방식으로 이루어 지는 것이다. Cross-site Scripting은 근복적인 해결책이 없는 공격 방식으로서 굉장히 유의하지 않으면 막기가 힘든 방법입니다.

이 공격 방식의 예로는 위의 박스와 같은 코드를 자바 스크립트가 동작하는 페이지에 삽입하여, 다른 사용자의 쿠키를 자신의 서버에 저장하는 방식이 있을 수 있습니다. 이와 같은 버그는 예전 대형 포탈 사이트에서도 동작하여 사용자의 많은 정보가 유출되기도 했었습니다.

2.3. HTTP Response Splitting

HTTP Response Splitting 공격은 웹 어플리케이션이 HTTP response가 분리될 수 있는 보안 취약점을 가지고 있다면 응답 메시지를 조작하여 Proxy 서버를 공격자의 의도대로 조작할 수 있는 공격 방식입니다. 공격받은 Proxy 서버를 사용하는 모든 사용자는 조작된 페이지를 보게 될 수 있습니다.

[JSP]
response.sendRedirect("/by_lang.jsp?lang="+request.getParameter("lang"));

만약 JSP에서 위와 같은 코드를 사용한다면 공격자가 다음과 같은 코드를 보내서 프록시에게 응답 패킷이 두개라고 착각하게 만들 수 있습니다.

[공격 코드]
HTTP://victim.com/redir_lang.jsp?lang=foobar%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a0d%0a<html>Getroot</html>

http://victim.com//index.html

서버사이드에서는 공격 코드에 있는 인자를 그대로 받아서 처리하기 때문에 foobar 이후의 코드를 그대로 응답에 사용하게 될 것입니다. 이 때 공격자가 http://victim.com/index.html을 빠르게 요청하면 프록시 서버에서는 다음과 같이 응답이 온것으로 착각하게 됩니다.

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 15:26:41 GMT

Location: http:// victim.com /by_lang.jsp?lang=foobar

Content-Length: 0

<index.html 에 매칭>

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

<html>Getroot</html>

따라서 해당 프록시를 사용하는 사용자는 http://victim.com/index.html 에 접근할 때 마다 Getroot 라는 조작된 페이지를 보게 될 것 입니다. 매우 많은 사용자가 사용하는 프록시 서버라면 Cross-site scripting과 결합하여 모든 URL로부터 악성코드가 감염되도록 조작할 수 있을 것입니다.

2.4. Path Traversal
Path Traversal은 웹 페이지에서 전달 받은 인자를 그대로 Path로 사용할 때, 해당 값을 조작하여 원하는 파일에 접근할 수 있게 되는 방식입니다.

[정상적인 URL]

http://www.victim.com/OpenFile.jsp?text.txt

[공격]

http://www.victim.com/OpenFile.jsp?../../etc/passwd

정상적인 URL에서는 text.txt 와 같이 정상적인 파일에 접근하는 것으로 사용하지만, 공격자가 ../../을 사용하므로서 다른 시스템의 오픈되지 않은 다른 디렉토리에 접근할 수 있는 여지가 발생하는 것입니다. 이런 공격을 방어하기 위해서는 사용자의 입력을 그대로 시스템에서 사용하지 말아야 합니다. 이 공격 방식은 현재 거의 대부분 통하지 않겠지만 이를 응용한 다른 방식이 많이 통하고 있다는 것 꼭 명심하고, 사용자의 입력을 시스템에서 그대로 사용하는 것을 최대한 방지해야 합니다.

2.5. Commnad Injection

Commnad Injection은 웹 어플리케이션에서 사용자의 입력을 직접적인 Shell 명령으로 이용할 때 이를 조작하여 원하는 명령을 실행할 수 있는 공격 방식입니다.

[ListFile.php]
Passthru(ls $path);

위와 같이 사용자에게 path라는 인자를 받아서 이를 ls 에 사용하여 원하는 디렉토리의 파일 목록을 보여주는 코드가 있다고 가정하겠습니다. 프로그래머는 당연히 ls 명령이므로 보안상 문제가 없을것이라고 예상하겠지만 다음과 같은 입력을 하여 시스템에 모든 명령을 내릴 수 있습니다.

[공격]
http://www.victim.com/ListFile.php?paht="/etc/;rm -rf /*"

명령어와 명령어 사이에 ; 를 입력하면 두가지 명령어가 순차적으로 수행되는 쉘 기능이 있기 때문에 위 공격 코드는 ls /etc와 rm -rf /* 명령어 두개가 동시에 수행되는 것입니다. 이것은 매우 심각한 보안 문제를 일으킵니다. 이 문제를 해결하기 위해서는 사용자의 입력을 그대로 쉘 명령으로 수행하면 안됩니다. 쿼리문도 마찮가지이고, 어떤 상황에서도 모든 사용자의 입력은 한번 가공해서 처리해야 한다.

이로서 거의 대부분의 웹 해킹 방식의 원리를 정리하였습니다. 그대로 사용하면 현재는 거의 통하지 않는 공격 방식이지만(실수가 많은 사이트는 아직도 많은 버그가 발견되곤 합니다.) 최신 해킹 기법도 이 틀에서 벗어나지 않고, 응용 수준에서 이루어 지기 때문에 이 원리만 파악하고 방어를 철저히 해놓아도 공격에 쉽게 노출되지 않을 것입니다.

감사합니다.

웹 해킹 원리와 방어 방법 (중)

(Getroot) — Thu, 12 Mar 2009 09:46:13 +0900

1.3. Hidden Field Manipulation

Hidden Field Manipulation 공격은 웹 페이지가 Hidden 태그를 이용하여 값을 웹 어플리케이션으로 전달하는 방법을 이용하는 공격입니다. 본 공격 또한 마찬가지로 웹 페이지를 로컬에 저장한 후 태그 값을 수정하여 실행하는 것 많으로도 공격이 가능합니다. 최근에 나오는 브라우져는 브라우져에서 바로 값을 수정하여 실행시킬 수 있기 때문에 더욱 공격이 쉬워집니다.

실제 코드를 예로 들어 살펴보면 공격은 다음과 같이 이루어 집니다.

[정상적인 HTML 코드]
<input type="hidden" name="price" value="100000">

[수정한 HTML 코드]
<input ytpe="hidden" name="price" value="10">

HTML에서 웹 어플리케이션으로 값을 전달할 때, 프로그래머가 귀찮아서 또는 그리 중요하지 않은 정보라고 생각되어서 위와 같이 처리하는 경우가 많이 있습니다. 하지만 모든 해킹은 중요하지 않은 정보를 조작하므로서 중요한 정보에 영향을 주는 방법으로 이루어진다는 것을 명심해야 하겠습니다. 이 공격을 해결하지 위해서는 아무리 중요하지 않은 정보라도 Hidden 태그로 처리하기 보다는 서버사이드에서 DB와 연동하여 직접 처리해야 합니다.

1.4. HTTP Header Manipulation

HTTP Header Manipulation은 웹 어플리케이션이 HTTP 헤더의 정보를 이용할 때, 이를 조작하여 웹 어플리케이션이 오동작 하도록 유인하는 공격 방식입니다. 예를 들어 A 사이트를 통해서 B 사이트로 들어오는 정보를 특별하게 처리하기 위해 HTTP Header의 Referer 필드를 이용하는 경우가 있는데 이것은 충분히 조작이 가능합니다.

[HTTP Header]
Get Shell.php
RERFERER http://trust.com

B 사이트에서 Shell.php 요청 명령을 받았을 때, 위 박스에 있는 헤더 처럼 trust.com 사이트를 통해 들어온 명령이면 처리하고 그렇지 않으면 거부하는 코드가 있다고 가정했을 때, 이것은 Victim.com에서도 Header만 변경해서 충분히 수행할 수 있습니다. 이 공격을 방어하기 위해서는 HTTP Header를 신뢰하지 않아야 합니다.

1.5. Cookie Poisoning

Cookie Poisioning은 Cookie를 조작하여 원하는 결과를 도출해 낼 때 사용합니다. Cookie란 웹 사이트의 특정 정보를 저장하는 기법으로 사용자의 PC나 장치에 저장되며 서버에도 저장될 수 있습니다. 보통 Cookie에는 사용자의 정보를 많이 저장하는데 물건을 구매하거나 메일을 보낼 때 Cookie를 사용한다면 이를 조작하여 다른 결과를 도출해 낼 수 있습니다.

[Cookie.txt]
ID=Victim SessionID=102

[Web application]
GetCookie(ID)->Point -= 100000;
GetCookie(ID)->BuyProduct("컴퓨터");

위 예제는 사용자의 정보를 쿠키에 저장한 후, 물건을 구매할 때 서버에서 이 정보를 불러와서 물건을 결제하는 코드입니다. 이때 사용자의 ID는 사용자의 PC에 있는 쿠키에 저장되어 있으므로 이 쿠키를 조작한다면 내가 원하는 사람에게 결제를 하면서 나에게 배송되게 할 수 있는 것입니다. 이를 해결하기 위해서는 세션을 이용하고, 모든 중요한 정보는 서버사이드에서 처리해야 합니다.

1.6. Executable File Upload

웹 서버에서 실행될 수 있는 파일(PHP, JSP, ASP 등)을 업로드하여 원하는 코드를 실행시키는 공격 방법입니다. 웹 초창기에 굉장히 유행했던 공격 방식이였습니다. 웹 초기에는 보안에 큰 신경을 쓰지 않아서, 대부분의 게시판에 실행 가능한 파일이 업로드 되었었습니다.

[Hack.php]
passthru($cmd)

만약 PHP가 동작하는 웹 사이트에 Hack.php 파일이 없로드 된다면 http://victim.com/Hack.php?cmd="rm -rf *" 와 같은 URL에 접근하여 웹 서버 내부에 침투할 수 있게 됩니다. cmd에 넣는 모든 쉘 명령어를 웹서버가 처리하게 되는 것이죠. 최근에는 이 공격은 거의 통하지 않습니다. 워낙에 고전적인 방식이라 대부분이 PHP, JSP, ASP 등의 파일이 업로드 되는 것을 막기 때문입니다. 하지만 워낙 고전이라는 것에 헛점이 있어서 모두가 안심하고 있을 때, 몇년전에 Apache 서버의 버그로 이 공격이 일파만파 다시 시도되었었습니다. 그것은 Apache의 기능 중 접속 국가별로 다른 페이지를 보여주기 위해 .kr, .jp 와 같은 확장자를 사용하는 옵션이 있었는데, 서버사이드에서는 끝의 확장자가 .php만 막을 뿐이였고, 아파치는 .php.kr 또한 php 파일로 처리했던 것이죠. 불과 이삼년전의 일입니다. 또 이런식의 버그가 항상 도사리고 있다는 것 명심하시기 바랍니다.

다음 하편에서는 Exploiting Unchekced Input의 해킹 방법을 모두 알아보도록 하겠습니다.

오늘은 소녀시대 사진을 준비했습니다. 모두 즐거운 하루 보내시기 바랍니다.

웹 해킹 원리와 방어 방법 (상)

(Getroot) — Thu, 12 Mar 2009 09:45:32 +0900

"인터넷은 웹이다."라고 할 수 있을 정도로 웹은 인터넷의 커다란 부분을 차지합니다. 실제로 비전공자에게는 "인터넷 == 웹" 으로 통하는 경우도 많습니다. 어떠한 운영체제도 기본적으로 웹 브라우져를 제공하며, 심지어 새롭게 출시되는 모바일 장치도 웹 브라우져를 지원하지 않고는 사용자들에게 어필할 수 없을 정도로 웹에대한 의존도가 매우 커졌습니다. 그래서 각종 금융서비스, 국가 전산 그리고 전자상거래등이 웹을 통해 서비스 됩니다. 별도의 클라이언트를 개발하여 서비스해도 되지만, 사용자에게 친숙한 사용 방법을 제공할 수 있으며, 웹 서비스를 이용하면 새로운 프로그램을 설치해야 하는 수고로움을 덜 수 있기 때문에 웹을 통해 서비스 하고 있는 것입니다.

그래서 지난 10년간 인터넷이 성장하는 동안, 웹 보안의 중요성이 매우 크게 증가 하였습니다. 이것은 해킹/보안 분야에서의 정설인 "서비스의 전산에대한 의존도가 커질수록 보안 위협도 비례해서 커진다"라는 공식이 적용되기 때문입니다. 실제로 지금도 수많은 웹사이트가 국경을 넘어서 수많은 해커들에게 공격받고 있습니다. 그 피해는 하나의 웹 사이트의 보안 사고가 사회 전체에 영향을 끼칠 정도로 큽니다.

웹은 일반 시스템에 비해 보안에 취약합니다. 그 이유는 웹 프로그래밍이 매우 쉽고 누구나 접근 가능한 것을 목적으로 설계되었기 때문에 일반인들도 몇일만 공부하면 그럴싸한 웹 사이트를 뚝딱 만들어낼 수 있기 때문입니다. 왜 만들기 쉬운것이 보안에 문제가 되는가? 라는 질문에 대한 답변은, "모든 해킹은 프로그래머의 실수에 그 기반을 두기 때문입니다." 라고 할 수 있겠습니다. 즉, 고도의 훈련된 전문가가 만드는 프로그램은 실수가 적기 때문에, 해킹 당할 확률이 적은 반면 그렇지 않은 사람이 만드는 프로그램에는 실수가 많아 해킹 당할 확률이 높아진다고 할 수 있는 것입니다.

그래서 웹 해킹 방법을 분류하여 설명하고, 어떤 실수가 해킹 사고로 이어지는지 그리고 어떻게 해결할 수 있는지 설명하도록 하겠습니다. 소개드리는 해킹 방법은 그 원리를 설명하기 위한 예시이지만, 지금도 벌어지고 있는 실제 해킹 사고 중 거의 대부분은, 소개시켜드리는 원리와 약간의 응용으로 작동한다는 것 꼭 명심하시기 바랍니다.

다음은 웹 해킹의 종류를 방식에 따라 나열한 것입니다. 이 웹 해킹 종류를 모두 소개해드리도록 하겠습니다. 참고로 본 문서에서 정의하는 "웹 어플리케이션"이라는 용어는 서버 사이드에서 동작하는 PHP, JSP 그리고 ASP와 같은 어플리케이션을 말합니다. 즉, 사용자와 웹 서버 사이에서 정보를 입력 받고 가공하여 출력해주는 역할을 하는 어플리케이션을 지칭하는 것 입니다.

Injecting Malicious Data

Parameter Tampering
URL Tampering
Hidden Field Manipulation
HTTP Header Manipulation
Cookie Poisoning
Executable File Upload

Exploting Unchecked Input

SQL Injection
Cross-site Scripting
HTTP Response Splitting
Path Traversal
Commnad Injection

1. Injecting Malicious Data

Injecting Malicious Data는 웹 어플리케이션에 조작된 데이터를 입력하여 공격하는 것입니다. 예를 들어 웹을 기반으로 경품행사를 하는데 랜덤하게 발생되는 경품 당첨 번호를 자신이 인위적으로 조작하여 입력하는 것 같은것을 말하는 것입니다. 한가지씩 살펴보며 이해를 돕도록 하겠습니다.

1.1. Parameter Tampering

Parameter Tampering 공격은 웹 어플리케이션에서 사용하는 파라메터(매개변수, Parameter)를 강제로 입력하여 어플리케이션의 의도대로 동작하지 않게 하는 공격입니다. 예를 들어 다음과 같은 코드가 있다고 가정합니다.

[HTML code]
<script> var form = document.Login;
id(!form.id.value)
{

return false;

}
</script>

[Java code]
String strID = request.getParameter("id");

위 코드의 원래 의도는 사용자가 id 에디트박스가 빈칸이 될 수 없도록 하는 것입니다. 하지만 위 코드는 HTML 파일을 PC에 따로 저장해서 저 스크립트를 빼버리는 것 만으로 의도를 빚겨나갈 수 있습니다. 이런 공격을 해결하기 위해서는 Java script에서 아이디 필드가 비었는지 체크하는 것이 아니고, 서버사이드에서도 id 파라메터가 비어있는지 체크해야 합니다.

전자 상거래 초창기에는 위와 같은 사례가 많았습니다. 예를 들어 상품을 보여주는데 상품 가격을 Read-only 속성이 있는 에디트박스에 넣고 서버사이드에서는 해당 에디트 박스에서 값을 읽어와 사용자의 포인트를 차감하면서 상품을 배송해주었던 사례도 있습니다. 이것은 에디트박스의 Read-only 속성만을 제거하면 10원으로 100,000원 짜리 물건을 살 수 있었다는 것을 의미합니다.

요즘에 이런 실수를 하는 곳은 거의 없지만, 급하게 만들어진 매우 큰 사이트에서는 아직도 저런 코드가 종종 보이기도 합니다.

1.2. URL Tampering

URL Tampering은 URL로 중요한 데이터를 보내는 경우에 이를 조작하여 공격자가 의도하는대로 동작을 바꾸는 것 공격 방식 입니다.

[정상적인 URL]
http://www.bank.com/myaccount?Sender=Attacker&Receiver=Attacker2&DebitAmount=1000

[공격 URL]
http://www.bank.com/myaccount?Sender=Attacker&Receiver=Attacker2&DebitAmount=-5000

위 예제는 정상적인 URL이 실행되면 Attacker라는 ID에서 1000 포인트를 차감하여 Attacker2라는 사용자에게 1000 포인트를 전송한다고 가정합니다. 이때 Attacker가 위 URL을 -5000이라고 바꾸어 실행하면 어떻게 될까요? 분명 내부적으로는 다음과 같은 코드가 동작할 것입니다.

Attacker.Point -= DebitAmount;
Attacker2.Point += DebitAmount;

-5000이라는 입력은 위 코드에 들어가서 반대로 Attacker2에서 -5000을 빼고, 공격자 본인에게 +5000을 하게 될 것입니다. 이런 공격 방식 또한 대부분 인지하고있어서 위와 같은 문제가 발생하지 않게 하고 있습니다. 하지만 중요한것은 실수라는 것입니다. 위와 같은 공격에대해 확실한 인지 없이, 수많은 코드를 작성하다보면 한두가지 필드에서 실수를 하게 되는 경우가 있습니다. 해커는 그런 빈틈을 이용해 큰 결과를 얻어내곤 합니다.

URL Tampering을 막기 위해서는, 우선 GET 방식으로 중요한 데이터를 주고 받지 말아야 하겠고, 그 후에 서버사이드에서 넘어오는 모든 값을 일일히 체크해야 할 것입니다. 위와 같은 코드에서 DebitAmount에 마이너스 값이 들어오면 경고를 하고 코드가 동작하지 않도록 해야 겠습니다.

마이너스 값 입력 문제는, 예전에 어떤 온라인 게임상에서 송금 기능을 이용할때 같은 문제가 있었습니다. 마이너스 값 입력 문제는 특히 더욱 조심해야 할것입니다.

다음 중, 하 편에서 나머지 웹 해킹 원리를 마져 다루도록 하겠습니다.

멋진 자연 경치를 보면서 잠시 휴식을 취하시기 바랍니다. 전체 화면으로 보시면 눈과 마음이 정화되실 것입니다.
본 블로그에 있는 모든 글은 그 출처를 명시하고 수정하지 않는 범위내에서 허락 없이 사용하실 수 있습니다.

쇼스페이스의 재생 속도가 느려졌습니다.

(Getroot) — Wed, 11 Mar 2009 16:42:31 +0900

HTTP://WWW.SHOWSPACE.CO.KR

3월 09일 월요일에 아이렌 사무실로 한통의 전화가 걸려왔습니다. 나이가 많은 중년이라고 자신을 소개하신 분께서, 본인을 비롯한 동료들이 쇼스페이스를 정말 편리하게 사용하고 있다. 그런데 사진이 넘어가는 속도가 너무 빨라서 보기가 어렵다. 사진 속도를 늦춰주거나 속도를 조절하게 해줄 수 있으냐는 것이였습니다.

개발 당시 저희의 목표는 우리 아버지께 설명 한번 안드리고도 사용하실 수 있도록, 가장 쉽고 간편하게 만들자였습니다. 그래서 회원 가입을 비롯한 사진 올리기 등 모든 기능을 디자인적 화려함 보다는 사용하기 쉽게 만드는 것에 촛점을 맞추었습니다. 이분과 전화를 끊고, 그래도 어느정도는 목표를 달성했다는 것이 매우 기뻤습니다. 나이가 많으신 분들은 새로운 서비스를 이용하는데 소극적이고 어렵게 느끼실 것 이라고 생각했는데, 아직 잘 알려지지도 않은, 아직 한참 개발중인 쇼스페이스를 잘 사용하고 있으시다고 말씀해주시는 것에 미묘한 감동을 느꼈습니다. 그리고 적극적으로 사무실로 전화해주신 분께도 매우 감사드리고 있습니다.

전화를 받은 후 바로 수정에 들어가 재생 속도를 늦추었습니다. 예상했던 것과는 달리, 더욱 보기에 편해진것 같습니다. 앞으로 더욱 더 발전하는 쇼스페이스가 되도록 노력하겠습니다. 최근 업데이트가 별로 없는데, 더 나은 서비스를 제공해드리기 위해서 숨죽여 개발하고 있는 것이라고 해석해주시면 감사드리겠습니다.

곧 얻그레이드 된 모습으로 다시 찾아뵙겠습니다.

iPhone Development - Window, Views, Coordinate(좌표계) 개요

(Getroot) — Tue, 10 Mar 2009 21:37:06 +0900

Window는 컨텐츠를 출력하는 역할을 수행하고, Views는 컨텐츠를 구성하고 그리는 역할을 수행합니다. Window는 MS Windows와 비교하였을 때 메인 다이얼로그, Views는 컨트롤이라고 생각해도 무방합니다. 일반적으로 아이폰 어플리케이션은 1개의 Window와 여러개의 Views로 구성됩니다. 어플리케이션이 생성될 때 UIWindow 클래스의 인스턴스가 아이폰 어플리케이션의 유일한 window가 되고, 그것에 하나 이상의 Views가 포함됩니다. 그 후 UIWindow는 포함된 Views를 출력하는 역할을 수행하게 됩니다. 아이폰 운영체제가 계층적인 windows를 지원하기는 하지만, 1개가 넘는 window를 생성하지 말라고 경고하고 있습니다.

UIWindow는 닫기 버튼이나 타이틀바와 같은 UI를 제공하지 않습니다. 모든 기능은 프로그래밍으로 정의하여 처리해야 합니다. 이것은 모든 아이폰 어플리케이션이 같은 UI 방법으로 시작과 종료를 하기 위한것으로 아이폰의 바탕화면에서 아이콘을 터치하여 프로그램을 시작하고, 홈 버튼을 눌러서 종료하는 것을 위한 것입니다.

어플리케이션을 생성할 때, window의 초기 사이즈는 화면 사이즈에 꽉 차게 생성됩니다. nid나 코드 모든것을 통해서 window는 화면 사이즈보다 작아질 수 없습니다. 화면 사이즈에 맞는 UIWindow는 다음과 같이 UIScreen 을 이용하여 다음과 같은 코드로 생성할 수 있습니다.

<code>
UIWindow * aWindow = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
</code>

아 이폰 어플리케이션에서 view는 대부분 UIView를 상속받아 만들어집니다. 이것은 사용자의 인터페이스를 출력하고, 인터페이스와 통신하는 중요한 두가지 역할을 수행합니다. 모든 view 오브젝트는 지정된 사각 영역 안에서 출력하고 인터페이스의 이벤트를 처리합니다.

하나의 view는 여러개의 sub view를 관리합니다. sub view의 관점에서 그것을 포함하고 있는 view는 superview 또는 parent view라고 불립니다. sub view 또한 또 다른 sub view를 포함하여 superview가 되는 계층적 구조를 가지고 있습니다.

아이폰 운영체제는 UIKit 이라는 클래스를 제공합니다. UIKit은 UIView를 이용한 window와 각종 컨트롤(views)을 제공합니다. 정말 다양한 views를 제공하기 때문에 다른 운영체제에서 프로그래밍할 때와는 다르게 새로운 컨트롤을 제작할 일이 거의 없습니다. UI 디자인도 그 무엇보다 훌륭하여, 프로그래머가 디자인에 신경쓰지 않고 기본 컨트롤을 그대로 써도 멋진 프로그램이 될 정도입니다. 다른 운영체제(Window)에서는 그렇지 않았죠.

위 그림에서 보는 것과 같이, 정말 많은 컨트롤이 기본적으로 제공되고 있습니다. 각 컨트롤에 대한 자세한 내용은 각각의 컨트롤을 검색하여 사용해보시면 금방 숙지할 수 있습니다.

UIKit은 기본적으로 top-left 좌표계를 사용합니다. 왼쪽 상단이 0,0으로 아래, 오른쪽으로 갈 수록 숫자가 커지는 방식입니다. 다른 운영체제처럼 정수계를 사용하지 않고, floating 형식, 즉 실수계를 사용합니다. 이것은 더 정확히 위치를 잡을 수 있게 하는것에 많은 도움이 됩니다. 예를 들어 300, 300 사이즈를 1/4 로 줄였다가 다시 4배로 정확히 키울 수 있습니다. 다음 그림은 아이폰 스크린과 좌표계의 관계를 나타냅니다.

모든 View 객체는 크기와 위치 속성을 포함함니다. 크기와 위치를 결정하는 속성으로는 Frame과 Bounds라는 두 가지의 중요한 개념이 있습니다. Frame은 출력되는 화면 영역을 의미하고, Bounds는 출력할 데이트에서의 영역입니다. 아래 그림을 보면 이 개념을 확실하게 이해할 수 있습니다. 왼쪽에 있는 그림 데이터에서 사용할 영역을 지정한것이 Bounds 개념이고, 이 Bounds를 화면 영역의 어느 부분에 출력할 지 결정하는 좌표가 Frame 영역입니다.

또 한가지 속성에 Center 값이 있습니다. 이 값은 Frame 영역에서의 가운데 좌표(X, Y)를 의미합니다. Bounds 영역에서의 Center가 아니라는 점을 꼭 명심하고 있어야, 나중에 개발 할 때 헷갈림이 없을 것입니다.

View 객체가 생성될 때 위 세가지 (Bounds, Frame, Center) 속성이 다음과 같이 초기화 됩니다.
Bounds rectangle 의 원점(Top-Left)를 0, 0으로 설정하고, 가로, 세로를(Width, Height)를 Frame(화면 영역)과 같게 설정합니다. 그리고 Center 속성을 Frame의 width/2, height/2 즉 가운데로 설정합니다. 이 세가지의 속성은 각각을 수정해도 다른 두가지의 속성에 다음과 같이 영양을 끼칩니다.

* Frame 속성을 설정하면 Bounds가 Frame의 사이즈에 맞게 확장됩니다. 그리고 Center 속성이 새로운 Frame에 맞게 변화합니다.
* Center 속성을 설정하면 Frame 속성의 원점이 변경됩니다. 즉, Frame의 크기가 변경되는 것이 아니고 Frame의 가운데를 손가락으로 잡고 움직여서 Frame 자체를 움직이는 듯한 효과가 있습니다.
* Bounds의 사이즈를 변경하면 Frame이 그 크기에 맞춰서 변화합니다.
* Bounds의 원점은 두개의 속성(Frame, Center)의 변경 없이도 바꿀 수 있습니다. 아래 그림과 같이 Bounds의 원점을 대각선 아래로 변경하여 그림의 다른 부분을 똑같은 Frame 에 출력되도록 할 수 있습니다.

이로서 아이폰의 윈도우, 뷰, 좌표계의 개요를 마무리 하겠습니다. 다음 강좌에서는 각 좌표를 변환(회전, 이동, 확대, 축소)등을 수행할 수 있는 방법을 소개하고 실질적으로 실습하는 모습을 보여드리겠습니다.

iPod touch 써드파티어플 #3 Cydia - Osu

(뽀뎅) — Sat, 07 Mar 2009 09:35:03 +0900

안녕하세요. 써드파티어플 소개, 그 세 번째 시간입니다. 오늘 소개해 드릴 써드파티어플은 유틸리티가 아닌 게임입니다. 써드파티어플이라고 해서 유틸리티만 있는건 아닙니다. 다양하게 즐길거리가 있는데요. 그 중 하나인 Osu 라는 게임을 소개하도록 하겠습니다. Osu는 닌텐도의 리듬히어로라는 게임을 떠올리게 합니다. 쉬운 게임 조작법으로 처음 사용하는 사람도 쉽게 게임을 즐길 수가 있습니다. 그럼 설치와 함께 게임을 즐겨보도록 하겠습니다.

다음 그림과 같이 Cydia에서 Osu를 설치합니다.

Osu를 실행시키면 먼저 게임을 할 노래를 다운로드 받아야 합니다. 게임 안에서 이것을 지원하고 있다는 것을 아래 그림을 통해 확인할 수 있습니다. 단 무선랜이 연결되어 있는 상태에서만 다운로드를 받을 수 있습니다.

노래를 다운로드 받기 위해 Newest로 이동했습니다. 노래를 찾던 중 낯이 익은 노래제목이 보이길래 확인해보니 Wonder Girls의 So Hot 이었습니다. 노래를 선택해주면 바로 다운로드 받는 것을 확인할 수 있습니다. 아래 그림처럼 다운로드를 받은 후에는 현재 보유중인 노래가 목록으로 보여집니다. 그럼 노래를 실행시켜보겠습니다.

노래를 선택하면 아래 그림과 같이 난이도에 따라 분류가 되어 있는 것을 볼 수 있습니다. 하나를 선택 후 다시 한 번 터치해주거나 Osu를 터치해주면 게임이 시작됩니다.

아래는 제가 노래를 끝내고 나서 얻은 점수입니다. 가장 쉬운 난이도의 노래를 했음에도 불구하고 저는 C를 받았습니다. 물론 노래가 다 어려운것만 있는 것은 아닙니다. 적당히 즐길 정도의 난이도를 가진 노래도 많습니다.

다른 여러가지 노래를 들으면서 게임도 할 수 있어서 재밌는 게임이라고 생각합니다. 다만 단점이 있다면 어느 어플리케이션이나 마찬가지겠지만 무선랜이 연결되어 있는 상태에서만 노래를 다운로드 받을 수 있다는 것입니다. 하지만 다른 여러가지 노래들도 다운로드받아서 즐겨보니 기다리는 시간이나 전철을 타고 이동할 때 등 시간을 때우기에 좋은 게임 같았습니다. 노래의 종류로는 pop, Jpop을 포함해서 보아, 클래지콰이 같은 한국가요도 다수 찾아 볼 수 있었습니다. 저 같은 경우에는 모르는 노래보다 알고 있는 노래로 게임을 하니 더욱 재미있었습니다. 닌텐도의 리듬히어로를 부러워 하는 분들이 계셨다면, 저는 그런분들께 Osu를 추천하고 싶습니다. 감사합니다.

iPhone Application Review #2 - BubbleWrap

(부르주아) — Thu, 05 Mar 2009 19:48:02 +0900

이번주에는 매우 간단한 게임 두 가지에 대해서 리뷰하겠습니다. 이 두 가지 게임은 두 손가락을 가지고(한 손으로 해도 됩니다) 속도를 즐기는 게임이라는 공통점을 가지고 있습니다.

그 첫 번째는 2009년 2월 21일 Entertainment 카테고리의 free application 9 위인 Bubble Wrap 이라는 게임입니다. 이른바 사람들이 말하는 일명 뾱뾱이( 에어캡 ) 게임입니다.

게임을 시작하면 화면에 우리가 종종보던 뾱뾱이(에어캡)들이 자리를 잡고 있습니다. 자, 지금부터 45초 동안 손가락들이 얼마나 빠르게 움직일 수 있는지 내 손가락의 속도를 확인하는 일만 남았습니다.

45초간의 스피디한 손가락 움직임을 보여주었다면 나의 점수를 기록합니다.

Bubble wrap은 어릴적에 뾱뾱이(에어캡)가 생기면 장난감 삼아서 놀던, 그 향수를 불러일으키는 그런 게임입니다. 손가락을 얼마나 빠르게 움직이느냐 하는 단순함으로 다가옵니다. 하지만 제가 게임을 즐겼던 환경이 i pod touch 2세대였기 때문인지, 뾱뾱이(에어캡)를 누르는 생동감을 단순히 소리로만 느껴야 한다는 것이 작은 아쉬움으로 남았습니다. 아마도 iPhone 이라던가 국내에 있는 T 옴니아나 햅틱등의 진동이 되는 기기라면 보다 재밌게 즐길 수 있을 것으로 생각 됩니다.

팁을 한가지 드린다면, 터치를 통하여 터진 뾱뾱이(에어캡)가 다시 바람이 들어가는데 시간이 조금 걸리기 때문에 약간씩의 여유를 가지면서 터트려 준다면 높은 점수를 얻을 수 있습니다.

두번째 게임은 Fast finger 입니다.

이 application은 비록 순위에 올라있지는 않지만 Bubble Wrap 과 같이 손가락 빠르기를 테스트하는 게임입니다.
start 버튼을 누르면 아래와 같은 화면이 나오는데 tap 부분을 빠르게 눌러주면 카운트가 됩니다.

30초 동안 열정적으로 터치를 해 주는 것이 게임의 전부 입니다. 30초가 지나면 몇번 터치가 되었는지 점수가 나오고 restart 를 누르면 다시 게임을 하게 됩니다.

위 게임은 친구들과 내기용으로 한 두번 해 보기에는 유용해 보이지만 게임 중간중간에 자사의 다른 프로그램을 홍보하거나 점수를 기록하는 기능이 없어서 게임에 동기부여가 되지 않아 지속적으로 하기엔 무리가 있습니다.

이번주에 소개한 두 게임 모두 조작이 쉽고 단순함이 매력적이긴 하지만 이런 매력만으로는 게임을 지속하고 다시 찾게하기 어려워 보입니다. Bubble Wrap 의 경우 뾱뾱이(에어캡)가 다시 바람이 들어가는 시간을 줄이거나 점수를 올려주는 보너스 요소를 조금 보강하고, F.finger의 경우는 문지르기를 넣거나 자신의 기록을 남길 수 있는 공간이 생간다면 사용자들로 하여금 보다 재미를 느끼게 해 줄 수 있지 않을까 생각 해 보았습니다.

Apple Development Center 개발자 등록 하기

(아이) — Thu, 05 Mar 2009 19:47:54 +0900

아이폰 앱스토어에 자신이 만든 어플리케이션을 올리기 위한 iPhone Developer Program이라고 부르는 개발자 등록 과정에 대해 간단하게 알아보도록 하겠습니다.

http://developer.apple.com/iPhone/program 에 방문하여 Learn More를 클릭하면 곧바로 가입화면을 볼 수 있습니다.

Standard Program과 Enterprise Program 두가지를 보실 수 있는데요, 우리가 알고 있는 일반적인 개발자 프로그램은 Standard Program입니다.

밑의 Enterprise Program의 경우 Adhoc Distribution(예를 들어 택배회사에서 자사의 택배관리 프로그램을 개발하여 아이폰을 전직원들에게 배포할 경우 회사 내부의 배포가 가능해야 겠죠)을 지원하지만 이것이 필요한 회사는 국내실정에선 없을것 같군요.

Standard Program을 선택하더라도 개인(Individual)과 회사(Company)를 선택할 수 있습니다.

회사의 경우 영문 사업자 등록증을 팩스로 보내야 하는 등의 좀더 복잡한 절차가 기다리고 있습니다.

우리는 회사입장에서 진행해 보도록 하겠습니다.

조금 싱겁게 등록이 끝나버렸군요. 몇일후에 애플쪽에서 컨텍을 할테니 iPhone Dev Center 에서 개발 연습이나 하고 있으라는 군요.

약 1주일 전후로 위와 같은 메일이 도착합니다. License Agree를 요청하는 메일이죠.

이후에 따로 회사로 연락이 옵니다. 간단한것 몇가지 묻고 사업자 등록증을 팩스로 보내달라고 합니다.

국제 팩스를 보내셔야 합니다. 필요한 경우 등록한 개발자와 통화를 요청할 때도 있습니다.

제가 Development Kit 구매화면을 캡춰하지 못해 구매완료 화면으로 대신합니다.

이후에 구매 가능한 링크의 주소를 보내줍니다. 99$ 결재하시면 됩니다.

구매 완료후에는 위와같이 Activation 코드를 보내옵니다. 해당 코드로 계정을 활성화 할 수 있습니다.

모든 것이 완료된 이후의 환영 메일이군요^^

이글은 http://theeye.pe.kr/entry/Process-of-Join-in-iPhone-Developer-Program 에서도 볼 수 있습니다.

iPod touch 써드파티어플 #1 Cydia - WinterBoard

(뽀뎅) — Thu, 05 Mar 2009 19:47:39 +0900

*알려드립니다! 이 게시물은 해킹에 성공한 iPod touch에만 적용되는 것이므로 그렇지 않은 iPod touch유저분들의 오해가 없으시기 바라면서 글을 시작하겠습니다.

오늘부터 써드파티어플(Cydia 어플리케이션)중 한 가지를 선택해서 소개해드리는 시간을 갖도록 하겠습니다. 이번 시간에는 WinterBoard라는 테마변경 써드파티어플을 소개하겠습니다. WinterBoard는 iPod touch의 테마를 변경시켜주는 써드파티어플 입니다. 자기의 입맛대로 테마를 꾸밀 수 있다는 장점이 있어서 많은 iPod touch 해킹 유저들이 애용하는 써드파티어플 중 한가지이기도 합니다. 자 그럼 다 같이 설치를 시작해 볼까요?

먼저 다음 그림과 같이 Cydia에서 WinterBoard를 설치합니다.

그리고 컴퓨터와 iPod touch를 연결해주시고 아래의 경로에서 다운받은 TouchExplorer를 실행시켜줍니다. 초기 실행화면은 다음 그림과 같습니다. 단, net framework 2.0 이상이 컴퓨터에 설치되어 있지 않다면 응용 프로그램 오류 창이 뜨니 다음의 경로에서 다운로드 받아 설치해주세요.
TouchExplorer :

TouchExplorer.zip

net framework : http://download.microsoft.com/download/5/6/7/567758a3-759e-473e-bf8f-52154438565a/dotnetfx.exe

이제 받아놓은 테마를 해당 경로에 넣을 차례인데요. 아래의 경로로 찾아가봅시다.
/private/var/stash/Themes.******** (* 표시 되어 있는 부분은 iPod touch마다 다르니 Themes까지 찾아가시면 됩니다.) 받아놓은 테마를 드래그해서 통째로 넣어주시면 됩니다. (만약 압축이 되어 있으면 풀어서 넣어주세요.) 저는 '박보영'씨의 테마를 넣어보았는데요. 아래 그림과 같이 테마가 들어간 걸 보실 수 있습니다. (한글명일 경우 자음과 모음이 분리되지만 신경쓰지 않으셔도 됩니다.)

'박보영'씨 테마의 폴더로 접근하면 아래와 같이 Icons와 Dock, Wallpaper 3가지로 구성되어 있는 걸 보실 수 있습니다.

이제 적용을 시켜 볼 차례입니다. Cydia를 통해서 설치한 WinterBoard를 실행시킵니다. 저장한 '박보영'씨 테마를 선택해서 체크해줍니다. 아래 그림까지 되셨다면 Home버튼을 누릅니다.

Home버튼을 누르고 잠시 대기하면 iPod touch가 새로 Loading되면서 전체적으로 아래 그림처럼 테마가 바뀌어 있는 것을 보실 수 있습니다.

만약 배경화면을 변경하고 싶으시다면 미리 여러 개의 사진을 넣어둔 뒤에 이름만 Wallpaper로 바꿔주시거나 그때그때 iPod touch를 다시 컴퓨터와 연결하시고 TouchExplorer를 실행시킨뒤에 테마의 경로로 접근하신뒤에 원하는 사진을 넣으시면 됩니다. (jpg사진도 가능하니 참고하세요.)

지금까지 WinterBoard를 설치하고 테마를 변경하는 과정까지 차례대로 진행해보았습니다. 제가 좋아하는 사람의 사진이나 예쁜 아이콘으로 꾸미니 iPod touch를 더 즐기고 싶은 마음이 들더군요. 갖가지 어플리케이션을 설치해서 써보는 재미도 있구요. 자기만의 iPod touch를 꾸미기 위해 작은 도전을 해보는 것도 좋을 것 같다는 생각이 듭니다. 혹시 진행 과정 중 혼란이 가는 부분이 있다면 추가/수정하도록 하겠습니다. 감사합니다.

Object-C : Declared Properties

(아이) — Thu, 05 Mar 2009 19:47:28 +0900

이번에는 Object-C의 Property에 대해서 이야기를 해볼까 합니다.

어떻게 보면 조금 필요없어 보일수도 있고 어찌보면 MVC(Model, View, Controller)개발 기법과도 밀접한 연관이 있어 보입니다.

하지만 일반적으로 MVC개발에서도 setter/getter로 구성 된 도메인 객체를 따로 두고 있듯이 Object-C에서도 역시 비슷한 구현을 할 수 있는것 같습니다.

Object-C에서 일반적으로 객체의 Property에 접근하기 위해서는 한쌍의 접근자 메서드(getter/setter)를 사용합니다.

이 메서드들을 사용함으로써 객체지향 프로그래밍의 캡슐화(Encapsulation)에 더욱 충실 할 수 있습니다.

관련된 자료는 Object-Oriented Programming with Objective-C의 Mechanism Of Abstraction을 찾아보라고 하는군요.

Property를 정의함으로써 효과적으로 접근자 메서드들을 간략화 시키는 효과를 가져올 수 있습니다.

Property를 사용하기 위해서 일반적으로 @property 지시자와 @synthesize 지시자를 함께 사용합니다.

@property 지시자는 클래스의 @interface 내부에 선언하며 다음과 같은 형식으로 선언합니다.

@property(attributes) type name;

하나의 Property 선언은 두개의 접근자 메서드와 동일한 기능을 갖습니다.

@proprty float value;

위의 선언은 다음과 같이 두가지 메서드를 선언한것과 같은 기능을 하게 됩니다.

- (float)value;
- (void)setValue:(float)newValue;

@property 지시자의 attributes 에는 다음과 같은 정의를 할 수 있습니다.

getter=gettername
기본적으로 Property의 getter 메서드 명은 Property 자신의 이름과 동일 (예 : Property가 foo일 경우 foo)
하지만 이 기본 설정을 내가 원하는 메서드명으로 변경 할 수 있습니다.

setter=settername
Property의 setter 메서드 명은 setPropertyName: 입니다. (예 : Property가 foo일 경우 setFoo:)
역시나 이 기본 설정을 내가 원하는 메서드명으로 변경 할 수 있습니다.

readwrite (DEFAULT)
Property의 값을 읽고 쓸 수 있다는 것입니다. 이 설정은 기본 설정입니다.

readonly
Property의 값을 단지 읽기만 할수 있다고 정의하는 속성입니다.
이 속성은 @implementation 블럭 안에서 오로지 getter 메서드만 필요할 경우에 사용합니다.
@synthesize 지시자를 사용하였을 경우에는 역시나 getter 메서드의 역할만을 하게 됩니다.
값을 대입 하려고 할 경우 에러를 출력하게 됩니다.

assign (DEFAULT)
단순하게 값을 대입합니다. 기본설정입니다. 이전에 어떤 객체를 가리키고 있던 Property라면 이로 인해 해당 객체는 미아가 되어 메모리릭의 주범이 될 수 있습니다. 가비지콜렉터를 사용하지 않는다면 사용을 피해야 합니다.

retain
이것은 assign과 비슷하지만 조금 다릅니다. 이전에 가리키고 있던 객체가 있다면 해당 객체를 Release하여 메모리에서 제거 합니다. 가비지콜렉터를 사용한다면 결과적으로 assign과 동일한 결과를 가지겠지만 좀더 명시적으로 사용해 주면 좋을것 같습니다.

copy
객체를 바로 대입하지 않고 해당 객체의 복사 메서드를 Invoke호출합니다.
그리하여 다른 메모리 영역에 복사본을 만든 다음 그것을 반환하게 됩니다. 이전에 가리키고 있던 값은 Release 시킵니다.

nonatomic
이 속성은 접근자 메서드가 Atomic 하지 않게 동작하게 합니다(?). 기본적으로 접근자는 Atomic하게 동작합니다.
Atomic이라는 말은 멀티스레드 등으로 구성된 프로그램이 특정 접근자 메서드를 호출할때 서로 충돌이 나지 않도록(보통 세마포어니 크리티컬섹션이니 하는 말들 들어보셨을겁니다.) 객체 레벨에서 Lock을 걸고 Property에 접근하게 되는데요 매우 좋은 이야기지만 접근할때 마다 Lock을 걸고 다시 푸는 작업이 반복되므로 퍼포먼스를 떨어뜨리는 결과를 가져오게 됩니다.
이런 접근이 필요없다면 이 속성을 사용하여 Non-Atomic하게 동작하도록 만들어 주시는 것이 좋습니다.

이제 Property에 대해 거의 모든것을 알게 된것 같네요. 이제 예제를 한번 볼까요?

@interface MyClass : NSObject {
    NSString *value;
}
@property(copy, readwrite) NSString *value;
@end

@implementation MyClass
@synthesize value;
@end

value라는 이름의 Property의 getter 메서드 명은 value이고 setter 명은 setValue입니다.

값을 대입할때 복사가 일어나고 읽고 쓰기를 할 수 있습니다. 또한 nonatomic 속성이 없으니 atomic하게 동작하겠군요.

마지막으로 Property를 사용할때 주의사항이 한가지 있습니다.

객체가 제거 될때 소멸자로 dealloc이 호출되는데 Property들이 자동으로 소거되지 않아 명시적으로 제거해 주셔야 합니다.

- (void)dealloc {
    [property release];
    [super dealloc];
}

이글은 http://theeye.pe.kr/entry/iPhone-Object-C-Declared-Properties 에서도 볼 수 있습니다.

Object-C : Fast Enumeration

(아이) — Thu, 05 Mar 2009 19:08:59 +0900

Object-C 2.0에 들어 열거형 변수를 좀더 효과적이고 안전하게 사용하기 위해 for 문법이 업그레이드 되었습니다.

이것을 보고 이름하여 Fast Enumeration 이라고 부르는군요. PHP나 Ruby등에서 볼수 있는 foreach와 같은 기능입니다.

일반적인 C에서의 구현에 비해서 매우 편리하게 반복문을 작성할 수 있습니다. 문법은 다음과 같습니다.

// one
for ( Type newVariable in expression ) { statements }

// two
Type existingItem;
for ( existingItem in expression ) { statements }

사용 예제를 보시면 바로 이해가 되실 것입니다. 예제를 보실까요.

NSArray

NSArray *array = [NSArray arrayWithObjects:@"One", @"Two", @"Three", @"Four", nil];
for (NSString *element in array) {
    NSLog(@"element: %@", element);
}
// element: One
// element: Two
// element: Three
// element: Four

NSDictionary

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
                                           @"quattuor", @"four", @"quinque", @"five", @"sex", @"six", nil];
NSString *key;
for (key in dictionary) {
    NSLog(@"English: %@, Latin: %@", key, [dictionary valueForKey:key]);
}
// English: four, Latin: quattuor
// English: five, Latin: quinque
// English: six, Latin: sex

NSArray - nextObject

NSArray *array = [NSArray arrayWithObjects:@"One", @"Two", @"Three", @"Four", nil];
NSEnumerator *enumerator = [array reverseObjectEnumerator];
for (NSString *element in enumerator) {
    if ([element isEqualToString:@"Three"]) {
        break;
    }
}
NSString *next = [enumerator nextObject];
// next = "Two"

안타깝게도 인덱스가 필요하다면 따로 제공하는것이 없어 다음과 같이 사용하셔야 합니다.

NSArray *array = /* assume this exists */;
NSUInteger index = 0;
for (id element in array) {
    NSLog(@"Element at index %u is: %@", element);
    index++;
}

예제만으로도 충분히 만족감을 주는 간단한 내용이었습니다.

이글은 http://theeye.pe.kr/entry/Object-C-Fast-Enumeration 에서도 볼 수 있습니다.

Apple Developer Program 이용 가이드

(아이) — Thu, 05 Mar 2009 19:08:52 +0900

개발자 프로그램에 등록하였다면 이제 자신의 아이폰(아이팟 터치)에 자신이 만든 어플을 올릴 수 있게 됩니다.

그런데 저는 무언가 간단한 작업이라고 생각했었는데 정말 복잡한 문제더군요.

우선 iPhone Dev Center에 방문하여 로그인을 해봅시다. 예전과는 조금 다른 화면을 보실 수 있습니다.

Apple Developer Forums이라는게 보이는군요. 중요한 Program Portal이라는 것이 오른쪽에 보입니다.

그곳이 아이폰 개발관련 포털 서비스를 제공하는 곳입니다.

1. 개발자 추가 등록

그곳에서 바로 다른 개발자를 등록해 보도록 하겠습니다. Team이라는 메뉴로 들어갑니다.

오른쪽의 Add Member를 클릭하면 사용자를 추가하는 창이 뜨게 됩니다.

이름을 입력하고 Email에는 실제로 초대장이 날라갈 이메일 주소를 적어주시면 됩니다. Role에는 일반 멤버와 관리자를 정할 수 있습니다.

2. 인증서 등록

이번에는 인증서 등록을 위해 Certificates 메뉴로 들어가 봅시다. 아래의 그림에서 표시한 download now를 클릭하여 Apple Worldwide Developer Relations Certification Authority를 설치합시다.

설치시에는 위의 그림과 같이 3가지 모두다 체크를 해줍시다.

이제 개인 키페어를 생성하기 위해 유틸리티 - 키체인 접근 메뉴에 들어갑니다.

키체인 접근 - 인증 지원 - 인증기관에서 인증서 요청메뉴에 들어갑니다.

위와 같이 체크를 하여줍니다. 사용자 이메일 주소에는 Apple Developer Connection에 등록한 이메일을 공통 이름에는 맥의 내 계정에 등록한 이름으로 동일하게 작성해 줍니다.

CA 이메일 주소는 아무것도 쓰지 않습니다.

키페어 정보는 위와같이 하시면 됩니다. 기본적으로 위와 같이 설정됩니다.

위와 같이 하면 인증서 파일(공개키)이 생성됩니다. 이것을 Certificates 메뉴의 Request Certificate를 눌러 위와같은 화면이 뜨면 파일을 선택하여 등록하여 줍니다.

등록이 되면 Action에 Approve가 뜹니다. 그것을 눌러줍니다.

위의 그림과 같이 Download버튼이 생겨납니다. 해당 버튼을 누르면 생성된 나만을 위한 인증서를 다운받을 수 있습니다.

다운받은 인증서를 추가합니다. 키체인에는 로그인만 있으면 됩니다.

잘 추가되었군요. iPhone Developer : 이름이 추가되어있으면 정상적으로 된것입니다.

3. Device 등록

이제 XCode에서 Windows - Organizer를 띄웁니다. 연결했던 나의 아이팟 정보가 뜨게 됩니다. 선택해 봅시다.

위와 같이 Identifier에 40자리의 Hex 코드가 있습니다. 그것을 복사합니다.

Device 메뉴에 들어가서 Add Devices를 클릭합니다. 위와 같은 화면에서 디바이스의 명칭을 정하고 Device ID에는 아까 복사한 40자리 코드를 붙여넣기 합니다.

4. App ID 등록

이제 App ID를 등록할 차례입니다. 이곳에서 많은 분들이 헤매시고, 저역시고 헤매었고; 어려운 부분입니다.

App ID Name에는 그냥 Program Portal에서 사용하는 식별자라고 생각하시면 됩니다. 별 의미 없으니 뒤의 Identifier에 지정할 내용의 별칭을 지정해 주시면 됩니다.

뒤의 App ID가 조금 중요한 부분인데, Bundle Seed ID와 Bundle Identifier를 합쳐서 App ID가 되게 됩니다.

Bundle Seed ID는 자동 생성 되는것이므로 신경 쓰지 마시고 Bundle Identifier가 중요한데요.

보통은 도메인을 뒤집어 사용합니다. apple.com의 경우 com.apple.*을 사용하게 됩니다.

이는 com.apple 이하의 모든 Bundle Identifier를 허가한다는 뜻입니다. 이런 설정이 귀찮으시다면 *하나만 달랑 써주시면 어떤 경로던지 허가가 되게 됩니다.

등록이 완료된 모습입니다. ID에 보면 XXXXXX.com.apple.* 과 같이 등록된 것을 알 수 있습니다.

여기서 중요한것은 어플리케이션을 만들때 앞의 XXXXXX부분의 코드를 사용하지 않는다는 것입니다.

5. Provisioning 등록
이제 Provisioning을 설정할 때입니다. 공급쯤으로 이해하면 될까요?

Profile Name을 정하고 자신에게 해당하는 인증서와 생성해둔 App ID 및 등록했던 Device를 선택합니다.

이제 거의 마무리 단계군요. 이제 지금까지 생성했던 나의 계정 + 인증서 + 디바이스 + App ID가 모두 짬뽕된 Provisioning Profile을 다운 받을 수 있습니다.

이 다운 받은 파일을 Organizer 창의 Provisioning 부분에 드래그하여 끌어다 놓습니다.

6. 내 아이폰(아이팟 터치)에 프로그램 올려보기

XCode에서 보시다 시피 왼쪽 위의 창을 Device로 바꿔 줍니다. 그리고 Group&Files창의 프로젝트명을 선택한 상태에서 오른쪽 위의 Info를 클릭합니다.

Build탭에서 Code Signing Identity의 하위 메뉴인 Any iPhone OS Device에서 내가 등록한 Provisioning Profile을 선택합니다.

Info.plist 파일을 열어 Bundle identifier부분을 App ID에서 등록했던 내용으로 수정하여 줍니다.

App ID가 XXXXXX.com.apple.* 이었다면 com.apple로 시작하는 어떤 값의 Identifier도 가능하다는 뜻입니다.

위의 값으로는 com.apple.${PRODUCT_NAME:identifier} 로 하면 자동으로 com.apple.HelloWorld(프로젝트명) 가 사용되게 됩니다.

참고로 위의 창을 띄우기 위해서는 Targets안의 내 프로젝트 명을 더블 클릭하여도 됩니다.

이제 마지막으로 실행을 위해 Build&Go를 클릭하면 내 디바이스에 업로드 되어 실행되는 것을 볼 수 있습니다.

* 마치며

위와 같은 과정을 거쳤음에도 인증 문제를 만나는 경우가 있었습니다.

보통은 App ID와 프로젝트의 Bundle Identifier가 불일치 해서 오는 문제였으며 이 문제는 인증서 부분과 App ID등록 부분을 잘 해보면 해결이 되는 문제입니다.

하지만 모든것이 완벽하여 XCode상에서 에러가 발생하지 않지만 인증 문제를 내뱉는 경우가 있습니다.

이때는 공장초기화를 해주고 아이튠즈에 다시 싱크를 해주니 잘 되더군요. 최악의 경우에는 초기화를 해보시기 바랍니다.

새로운 개발자를 등록하였다면 어떻게 해야 할까요?

위의 과정에서 1, 2, 3, 5를 반복하여 Provisioning Profile을 생성해 주면 됩니다.

App ID를 아무래도 같은 팀이라면 공유하는게 좋겠죠.

이글은 http://theeye.pe.kr/entry/How-to-use-Apple-Developer-Program-Portal 에서도 볼 수 있습니다.