Search results

'Hacking'에 해당하는 글들

  1. 2011/07/13  [KakaoTalk] JSON Objects (5) (6)
  2. 2011/06/26  [KakaoTalk] KakaoTalk PC Prototype (4) (10)
  3. 2011/06/23  [KakaoTalk] Session Key (3) (12)
  4. 2011/06/22  [KakaoTalk] Bypassing SSL (2) (1)
  5. 2011/06/19  [KakaoTalk] Preliminary Research / Analysis (1) (3)
  6. 2011/06/15  PPP is going to DefCon19 Final! (1)
  7. 2011/06/07  PHDays CTF -- Russia (2)
  8. 2011/06/03  PHDays CTF -- Russia (1)
  9. 2011/05/21  Plaid CTF 2011
  10. 2011/04/12  Codegate 2011 Final Round - 2편 (12)

에.. 이번 글에서는 카카오톡 클라이언트와 서버 사이에서 어떤 데이터가 오고가는지 짧게 적어보려 합니다.
다른 플랫폼으로 (windows phone, pc, 등등) 포팅하실분들에게 약간이나마 도움이 될지도 모르겠네요.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

일단 제 프로그램에서는 세션키 인증이 끝나면 바로 친구 리스트를 불러옵니다.
친구리스트는 다음 URL에 리퀘스트를 보내면 받을 수 있습니다:
https://ch-talk.kakao.com/iphone/chats/list.json

그러면, 다음과 같은 object에 파싱해서 넣을 수 있습니다.

view [FriendsListJSON.cs]



앞으로의 모든 JSON 객체에서 status 필드를 보실 수 있는데, 0일 경우엔 성공 음수일 경우엔 각 에러코드를 나타냅니다. 예를들어, -500 은 세션키가 http 헤더에 제공되지 않았을때 리턴되고 -998은 잘못된 (서버에 등록되어있지 않은) 세션키가 제공되었을때 리턴됩니다.


각각의 Friend 객체는 다음과 같은 구조를 가지고 있습니다.
필드설명:
- type: 현재 친구와의 관계 (1 == 이미 친구, -4 == 친구 아님)
- directChatId: 직접 채팅(방) 아이디
- userId: 유져 고유번호
- nickName: 친구 이름 (상대방이 자신의 닉네임으로 설정한 것)
- phoneNumber: 폰 번호 (폰 번호가 저장되어있다면.. 아이디로만 저장되있으면 폰 번호 없음)
- profileImageUrl: 작은 프로필 사진 주소
- statusMessage: 이름 옆에 뜨는 '오늘의 메세지'
- friendNickName: 자신이 설정한 친구의 닉네임
- UUID: 아이디 (친구 검색할때 쓰는 아이디)
- fullProfileImageUrl: 원본 프로필 사진 주소

view [Friend.cs]




이제 친구 찾기에 대해서 알아봅시다~
친구찾기는 다음 url로 리퀘스트를 보내면 됩니다:
https://fr-talk.kakao.com/iphone/friends/find_by_uuid.json?uuid=UUID
찾고 싶은 친구의 아이디 (uuid)를 파라미터로 넘기면 다음과 같은 JSON이 리턴됩니다.

필드설명:
- status: 찾기 성공 여부 (0 == 찾음, -1002 == 존재하지 않는 아이디거나 공개찾기 거부)
- member: 상대방 정보 (사실 지금보니까 그냥 Friend 클래스를 썼어도 될것 같네요, 한가지 차이점은 friendNickName 필드가 없다는것 정도..)

view [FindFriendByUUIDJSON.cs]



친구 추가를 할 때는, 다음 url에 리퀘스트를 하면 됩니다:
https://fr-talk.kakao.com/iphone/friends/add.json?id=userId
여기서 주의해야 할 점은, 위에서 말씀드린 유져 고유번호인 userId를 넣어줘야한다는점입니다. UUID (사용자 아이디)가 아닙니다.

성공적으로 리스폰스가 돌아온다면 다음과 같은 JSON이 리턴됩니다.
필드설명 (FriendJSON class):
- status: 친구 추가 성공여부 (0 or 1 == 성공 | 처음으로 추가하는거면 0, 한번 해본적 있으면 1 인듯?)
- friend: 친구 정보

친구 삭제 시에는, 다음 url에 리퀘스트를 하면 됩니다:
https://fr-talk.kakao.com/iphone/friends/remove.json
하지만, 이번 리퀘스트는 그냥 GET으로는 파라미터를 넘길 수 없고, POST를 써야합니다 (한번에 여러 아이디 삭제가 가능하므로). POST 데이터는 다음과 같습니다:
ids=[userId1,userId2,...,userIdn]
이번 역시 userId를 넣어주어야합니다.

성공적으로 리스폰스가 돌아온다면 다음과 같은 JSON이 리턴됩니다.
필드설명 (FriendIdsJSON class):
- status: 친구 삭제 성공여부 (0 == 성공)
- friendIds: 삭제된 친구 userId 리스트 (클라이언트 리스트에서 삭제할 수 있도록)

view [FriendJSON.cs]



대충 이 정도하면 친구 불러오기, 찾기, 추가, 그리고 삭제와 같은 친구관련 작업들은 다 할 수 있습니다.

이제 마지막으로 채팅에 관련된 극히 일부분을 보도록 하죠 ㅎㅎ
최근에 시간이 없어서 (제일 중요한 ^^;) 채팅쪽을 많이 못봤습니다.. 베타버전에서 이미지 전송까지 해놓으려고했는데 다음..(기약없음..ㅋㅋ)으로 미뤄야하겠네요.

일단 다음은 채팅방 리스트를 불러오는 url 입니다:
https://ch-talk.kakao.com/iphone/chats/list.json

저는 개인적으로 세션키 validation을 할때밖에 쓰지 않습니다만.. 유용한 날이 오겠죠 ㅎㅎ

view [ChatListJSON.cs]




실질적으로 채팅이 이루어지는 부분을 보도록 하죠.
사실 카카오톡에서는 '채팅'의 개념보다는 '비동기식 메세지 교환' 이라고 보는게 나을지도 모르겠네요.
한쪽에서 메세지를 보내면, 이 메세지는 카카오톡 서버에 저장되어있다가 다른쪽 유져가 '나 메세지 받은거 있니?' 라고 물어보면 서버가 받아두었던 메세지를 전달해주는 방식입니다. 물론, 그 시점에서 서버단에서 그 메세지가 삭제가 되는지 저장이 되는지는 (^^;) 저로써는 알 방법이 없지만, 카카오톡 구조상 무조건 서버에 한번은 저장되어야 합니다.

그리고 또 한가지 재밌는것은, 카카오톡은 이미 처음부터 그룹채팅을 디자인으로 개발되었던것 같습니다.
그래서, 모든것이 다수가 참여할 수 있는 '채팅방'의 구조로 되어있고 1:1대화는 그저 유져가 두 명인 채팅방에 불과합니다.

다음 url로 채팅방을 생성 또는 메세지를 적을 수 있습니다:
https://ch-talk.kakao.com/iphone/chats/create_and_write.json

사실, 보통은 create_and_write은 대화를 맨 처음 할때 한번만 전송되고 그 이후부터는 그 채팅방에 부여된 채팅방 아이디를 사용해서 메세지를 보내고 받고 하지만, 저는 따로 내부 DB를 관리하고 있지 않기때문에 그냥 그때그때 create_and_write에 리퀘스트를 합니다. 그렇다고 그때마다 채팅방이 새롭게 생기는것은 아닙니다 ㅎㅎ 고맙게도(?) 이미 존재하는 채팅이면 서버단에서 처리를 해주는것 같더군요.

위의 리퀘스트는 당연히 POST이여야하고, POST 데이터는 다음과 같습니다:
receiver_ids[]=id1,id2,...,idn   (사실 저는 지금 1:1 만 지원중이라 여러아이디에 보내는데에 쓰이는 구분자가 잘 기억이 안나네요 -_-; 콤마였던거 같은데 아닐수도있으니 그룹대화 지원하실분은 체크 먼저 하시길..)
message=msg (한글은 UTF-8 인코딩해야함)
push_alert= true (또는 false)

필드설명 (ChatRoomJSON):
- status: 성공 여부 (0 == 성공적으로 전송, -401 == 실패했음)
- chatRoom: 채팅방 정보
- chatLogs: 채팅방 로그 (아직 확인 하지 않은 메세지들)

필드설명 (ChatRoom):
- type: 그룹인지 1:1인지 판별?
- activeMemberIds: 대화 참여중인 멤버 아이디들
- lastMessage: 마지막 메세지
- pushAlert: push notification 설정 되있는지 여부
- activeMembersCount: 참여중인 멤버 수
- members: 참여중인 멤버들 정보
- watermarks: ???
- lastUpdatedAt: 마지막으로 업데이트 된 시간 (내부 카운터)
- lastLogId: 마지막으로 확인한 로그 고유번호
- newMessageCount: 새 메세지 갯수
- chatId: 현재 채팅방의 고유번호

필드설명 (ChatLog):
- type: 까먹음 (그룹 또는 1:1?)
- logId: 로그 고유번호
- message: 메세지
- sendAt: 보내진 시간 (내부 카운터)
- chatId: 로그가 속한 채팅방 고유번호

view [ChatRoomJSON.cs]



해보지는 않았지만, 요즘 화두가 되고있는 '카카오톡 서버가 메세지를 저장을 하고 있느냐 아니냐'의 질문은 아무래도 이미 (채팅방 안의 모든 멤버가) 확인한 메세지의 ChatLog를 다시 불러올 수 있느냐 없느냐로 판별 할 수도있겠네요. 정상적이라면 채팅방에 있는 멤버가 특정 메세지를 모두 확인하는 순간 (즉, 메세지 옆에 뜨는 노란 숫자가 0이 되는 순간) 서버단에서 해당 로그를 지워야하겠죠. 그런데도 그 로그 아이디로 메세지를 불러올 수 있다면, 서버에 메세지들을 계속 저장하고 있다는 뜻이겠죠.

이제 마지막으로, https://ch-talk.kakao.com/iphone/chats/chatId.json?since=lastLogId 로 리퀘스트를 보내게 되면, 역시 ChatRoomJSON이 넘어오게 됩니다. 보시다시피 chatId와 lastLogId로 새로운 메세지가 도착했는지 안했는지 fetch할 수 있습니다. 방금전에 위에서 말한 테스팅을 손쉽게 할 수 있는 리퀘스트죠 :)

제가 해보진 않았습니다만.. (별로 그쪽엔 관심이 없는지라..) 다른분들이 해보시고 알게되면 댓글 달아주세요 ^^


대충 이정도가 제가 알고있는 자료구조입니다. 사실 자료구조라고 하기에도 좀 난감한 'JSON parsing' 입니다.
리퀘스트해서 돌아오는 리스폰스를 파싱해서 그 데이터를 알맞게 잘 쓰면 카카오톡 포팅이 가능한거죠.

나중에 시간과 기회가 된다면, 그룹대화 (뭐 이번 포스팅에서도 대충 설명하긴했습니다만..)와 이미지/동영상 등 전송에 대해서 설명하도록 하겠습니다.

질문이 있으시면 댓글로 남겨주시거나 이메일 주시면 됩니다~~




2011/07/13 23:34 2011/07/13 23:34
─ tag  , , ,

카카오톡 관련 포스팅을 영어로 하는데에 대한 불만들이 많으셔서 ㅋㅋ..
이번 포스팅은 한국어로 하도록 하겠습니다~ :D

사실 이번엔 카카오톡 분석에 대한것보다는 간단한 분석 (2~3시간)으로 만들 수 있는 프로토타입에 대해서 소개하고자 합니다. 제가 1편에서도 말씀드린것처럼, 카톡 개발자들이 상당히 구조를 잘 짜놨기 때문에, 프로토콜과 자료구조만 알면 사실 에뮬레이션 (예를들어, PC버전 카카오톡)을 하기가 정말 쉽게 되어있습니다.


일단 기기가 카카오톡 서버에 등록이 되고 나면 세션키라는 인증토큰이 모든 패킷에 들어가야합니다. 하지만 전편에서 말씀드린대로, (jailbreak 없이) 정상적인 방법으로는 세션키를 추출하기가 불가능에 가깝습니다. 그렇기 때문에, 현존하는 모바일기기의 계정을 그대로 PC에서도 사용하시려면 이 세션키를 먼저 추출하셔야합니다. 또 다른 방법으로는, 새로운 계정을 인증하는 방법이 있긴합니다만.. 모바일기기의 계정과 연결하기는 거의 불가능합니다 -- PC버전용으로만 쓸 수 있는것이죠. 즉, 제가 앞으로 설명드릴 카카오톡PC는 세션키를 안다는 가정하에 진행하도록 하겠습니다.

세션키 추출 방법은 나중에 기회가 되면 다시 한번 포스팅을 하겠습니다만, jailbreak를 하신 폰이라면 SSL Bypass 편을 참고하시면 추출하실 수 있습니다. 유의하실 점은, 카카오톡의 유일한 인증 방식이 이 세션키이기 때문에 한번 유출되면 다른사람이 그 세션키 주인인척하고 모든 대화 및 프로필등을 도청 할 수 있다는것입니다.


=-=-=-=-=-=-=-=-=-=-=

그럼, 제가 날림으로 만든 카카오톡PC 프로토타입에 대해서 간략한 소개를 해드리겠습니다.
원래는 그냥 PoC (Proof of Concept: 된다는것을 증명하기 위해 최소 기능만 지원)용으로 만들기 시작한거라, 코드도 조잡하고 기능도 간단한것밖에 없었는데, 아무래도 요청하시는분이 많아서 릴리즈하기전에 조금 가다듬기 위해서 시간이 필요할것 같아, 아직은 릴리즈하지 않도록 하겠습니다.
[제 개인적으로 디자인적 감각이라던가, 윈도우 UI 개발을 해본적이 없기때문에.. 정말 기능적인요소만 추가되어있습니다....너무 실망마시길..ㅋㅋ]

처음 실행을 시키면 다음과 같은 창이 뜹니다:
사용자 삽입 이미지

세션키를 넣고 Verify 버튼을 누르면 카카오톡 서버에 등록되어있는 정상 세션키인지 검사를 합니다.
그리고 존재하는 세션키라면 다음의 메인화면으로 넘어가게 됩니다.

사용자 삽입 이미지

물론, 탭들을 이용해서 실제 카톡과 비슷하게 만들 수도 있었지만.. 그냥 한눈에 보는게 테스팅하기도 편하고 해서 일단 현재 디자인은 저렇습니다..

  • Friend Info: 이곳에는 오른쪽 자신의 친구리스트에서 선택된 친구의 정보가 보여지는곳입니다.
    사용자 삽입 이미지

      + Start Chat을 누르면 상대방과 채팅을 할 수 있도록 채팅창이 뜨고,
      + Delete을 누르면 친구를 삭제할 수 있습니다.

  • Menu: 아래쪽에 있는 메뉴에는 현재 지원하는 메뉴들이 있습니다.

      + Find Friend: 친구찾기 기능입니다. 디자인은 거의 카톡 기본 디자인과 흡사하게 만들어놨습니다.
    사용자 삽입 이미지

          - 찾을 ID를 넣고 Find를 누르면 그 아이디가 존재하고 찾기가 가능하게 되있다면,
            아래쪽 Friend Info에 사진, 닉네임, 아이디, status message등이 뜨게 됩니다.
          - Add를 누르면 현재 검색된 친구를 추가할 수 있습니다.

    사용자 삽입 이미지

            - 또한, 어디서든 프로필 사진이 있는곳 위에 클릭을 하면 원본사이즈의 프로필 사진을 보여줍니다.
               (새 창의 사진 아무데나 클릭하며 사라집니다.)

    사용자 삽입 이미지


      + My Profile 메뉴는 자신의 프로필을 볼 수 있고, 수정할 수 있습니다.
          (아직 사진수정 기능은 추가하지 않았습니다.)

    사용자 삽입 이미지

            - ID subject to Search 옵션은 서버에 저장만 해두고 현재 상태를 알려주지 않기때문에
              현재 어떤 상태인지 가져올 수 없습니다.. 수정하시고 싶다면 체크박스를 클릭하신 후
              업데이트 해주시면 됩니다.


  • Chatting: 아무래도 가장 중요한 기능 중 하나인 채팅은 현재 1:1 채팅만을 지원하고, 아이폰이나 안드로이드에서 지원해주는 Push notification 기능을 사용할 수 없기때문에, 매 3초마다 새로운 메세지가 있는지 체크해서 가져오도록 되어있습니다. 나중에 릴리즈할 버전에서는 이 interval을 조정하거나 수동으로 fetch해오도록 변경할 예정입니다. (너무 자주 fetch요청이 들어오면 카카오톡측에서 수상히 여기고 정지시킬 수 있기때문에..)

    사용자 삽입 이미지

    메세지 보내기


    사용자 삽입 이미지

    상대방에게 메세지가 잘 전달된 모습


    사용자 삽입 이미지

    상대방이 보낸 메세지가 잘 받아진 모습


    사용자 삽입 이미지

    KakaoTalk PC에서 한글로 보냈을때 잘 도착하는 모습


    사용자 삽입 이미지

    KakaoTalk PC 클라이언트에서 한글메세지를 잘 받는 모습


    사용자 삽입 이미지

    카카오톡 모바일에서도 푸쉬 알람이 뜨는 모습



대략 간단한 예제들을 보여드렸지만, 대부분 많이들 쓰시는 친구찾기/프로필수정/1:1대화 기능을 지원합니다.
바로 위의 스크린샷에서도 보실 수 있듯이 메세지를 받게 되면 KakaoTalkPC뿐만이 아니고 폰에서도 메세지를 확인할 수 있습니다.

이제는 이미지 파일 메세지 전송을 구현할 계획입니다만, 귀차니즘때문에 시작을 못하고 있네요..

아참. 제 프로그램에서도 모바일 카카오톡과 마찬가지로 모든 리퀘스트는 SSL을 통해서 하게됩니다.
그래서, 카카오톡pc를 사용하는 동안 누군가가 중간에서 packet sniffing을 해서 세션키를 훔치거나 메세지 변조등을 할 수 없습니다 :)


일단 요정도로 설명을 마치겠습니다. 필요한 기능인데 제가 잊은기능들이나 (전 카카오톡 헤비유져가 아니라..) 또는 이런게 있었으면 더 편하겠다 등.. 아이디어 있으시면 댓글로 남겨주시면 되겠습니다 -- 물론 100% 다 구현은 못할 수도있지만..저도 학교일을 해야하므로..ㅋㅋ 최대한 첫 릴리즈에서 그 기능들을 추가하도록 하겠습니다.

그리고 마지막으로, 카카오톡PC 베타유져를 모집합니다..
(윈도우 UI 이쁘게 만드는 기술 전수해주실분도 환영입니다!)
관심있으신분들은 brianairb [at] gmail [dot] com 으로 이메일주시면 되겠습니다.


좋은 하루 되시길...





2011/06/26 14:07 2011/06/26 14:07

Today, I'm going to explain one of the most critical parts in KakaoTalk: Session Key.

KakaoTalk has only one mechanism to authenticate the user. It is the session key that is generated in the process of registering yourself to the KakaoTalk server when you first install on your mobile device. This, then, is stored in the device until the user deletes KakaoTalk.

What's interesting here is that this session key acts as user identification AND user authentication on server side. Thus, this session does not act the same as the usual 'web' session keys, which expires after some time. KakaoTalk Session Key never expire or change -- well, I shouldn't say 'never' because there's a case that the key is purged. It is used throughout until the user deletes his/her account or KakaoTalk app from the phone. (BTW, deleting an app doesn't cause the account to be deleted.)


As you saw last time, the Session Key is required for every request that is sent to the server, and included in HTTP header with the field name of 'S'.

사용자 삽입 이미지



So, how is this key generated, and what does the life cycle of the key look like?

    1. Session Key Generation
    • Session Key is consisted of two parts: X-Y
    • First part (X) is generated during the SMS verification in registration step.
      • I tested on Android KakaoTalk, and the following is the steps in detail what's happening in the process of the verification.

      1. Client requests a SMS verification to KakaoTalk server (ac-talk.kakao.com)
          - This is done through /android/account/request_sms.json
          - POST data: device_uuid, phone_number, country_iso

      2. Server responds with the one-time 'token' in json format
          - Meanwhile, the server also sends actual SMS message (which contains passcode) to the number.

      3. Once the user puts in the passcode, the client submits to the server.
          - /android/account/verify_sms.json
          - POST data: token (to verify it's you), phone_number, country_iso, passcode, device_uuid, old_session_key
          - Here, old_session_key is set when you have changed your phone but still has old_session_key backed up in the system.

      4. Server responds with status code '11' and a new token is returned when successful.

      5. Finally, the client requests [/android/account/verify.json] along with the nickname that the user specified.
          - POST data: phone_number, country_iso, device_uuid, new token, nickname, old_session_key

      6. The server generates and sends 'sessionKey' in JSON data with other information as well.
          - JSON data includes: sessionKey, 'member' object (type is set to -10, which means it's myself), userid (unique number that differentiates users), nickname, etc.

      7. At this point, the session key has been given to the client, and the client saves it locally.
          - The subsequent requests must contain this session key, otherwise the request is rejected with error code -500 (session key not specified).

      8. Client then sends a query to [/android/account/update_settings.json] to sync the information on the server and the client.
          - POST data: model, simOperator, screen_resolution, os_name, os_version, etc.
          - I wonder why they need all this much information.

      • I haven't tested on iPhone, but it's just basically the same with different URL for iPhone.

    • Second part (Y) is generated based on the device id.
      • On Android:
        • This is just plain device ID, it seems. But I haven't done much reversing on this part, so I may be slightly wrong :p

      • On iPhone:
        • It uses something called 'encryptedDeiceID' which it derives from the property named 'cryptedUniqueIdentifider' (notice their typo :p)

          사용자 삽입 이미지

        • Again, as the name indicates, it does something with the device ID, but I haven't reversed this part yet.

    • The reason I didn't go deep enough to actually understand how they generate the device ID is because while it's still possible to reverse engineer and reconstruct the encrypted device ID, there's no way to reconstruct the first part of the session key since it comes directly from the server.
      • Thus, unfortunately, there doesn't seem to be a good way to regenerate the session key. Once it's generated and given to the client, both client and server just save it locally and use that to authenticate.


    2. Session Key Life Cycle
    • As I mentioned above, the usage of the session key is blatantly obvious. They use it to authenticate. Once it's set, it never changes -- unless the device is changed.

    • The session key must be included to the request header.

    • If the device ID changes (due to changing the device, etc.), KakaoTalk asks the user to re-verify the mobile device. In this process, old_session_key is set to the previous session key and the newly generated session key is returned.

      • Session Revocation
        • I was little surprised and impressed that KakaoTalk does this correctly ;)
        • When the user  verifies with the existing (same) number, KakaoTalk server revokes (deletes) old association with the account and the session key.
        • Thus, it is not possible to impersonate a user with his/her old session key.

    • Local storage of the key:
      • Android: /data/data/com.kakao.com/shared_prefs/KakaoTalk.perferences.xml
      • iPhone: /User/Applications/XXXXX...XXXX/Library/Preferences/com.iwilab.KakaoTalk.plist

        사용자 삽입 이미지

I mean, their one-factor, fixed token authentication mechanism scares me a little, but I had an impression that they actually somewhat care about security. However, they would need to come up with the better solution to this, since it's basically game-over situation if someone is able to extract the session key. (You can basically become anyone, and KakaoTalk wouldn't know shit.)

Anyways, that's what I have and know about KakaoTalk's session key system.
I don't know how they generate the first part, so I wouldn't go ahead and reverse the algorithm for the second part. If someone knows more about this, feel free to contact me! Maybe we can collaborate to do cool things :p

Thanks for reading!



2011/06/23 21:42 2011/06/23 21:42

Welcome back, readers!

As I told you last time, I'm going to talk about how KakaoTalk uses SSL to protect its outgoing/incoming packets from the packet sniffing. Again, this involves a jailbroken phone. The article will only use KakaoTalk for iPhone for the analysis, but the analogous techniques work in Android one as well.

 
It was somewhat surprising (and not really at the same time) to figure out that KakaoTalk client uses SSL sometimes and non-SSL the other times. Since SSL adds some overheads to the packets, it would not be ideal to have turned on every time because:
  1. It's going to drain the battery way faster. Crypto is not cheap, especially in embedded devices like mobile phones.
  2. Overhead++ ==> Traffic++ ==> $$$++ for non-unlimited data plan users.
To avoid this problem as much as possible, they choose to use SSL only when WiFi is on and connected to the internet through it.

사용자 삽입 이미지

It is interesting choice to think about since they might have decided to do this because of the security related reason as well. Note that it is trivial to sniff/dump the traffic of the mobile device when it is on WiFi. You can easily either set up a router to become a packet sniffer or make the phone to connect to the WiFi network through the computers (e.g. Internet Sharing feature on Mac OS X).

It didn't take much work to find where they decide whether to use SSL or not.

사용자 삽입 이미지

Call to currentReachabilityStatus


Above, you can see the code is making a call to currentReachabilityStatus function (commented) to determine which network the phone is currently using. Little lookup of Reachability library sample code tells us what it does and returns.

Remember that the return value in ARM architecture is stored at R0 register. Right after the call (_objc_msgSend), you can verify that the code is comparing the return value ofcurrentReachabilityStatus function with the constant value 2.

Here, I want to go over little bit of ARM instruction: IT
From the instruction reference for ARM, we can find the following description for this instruction.

The IT (If-Then) instruction makes up to four following instructions (the IT block) conditional. The conditions can be all the same, or some of them can be the logical inverse of the others.

Damn, If-Then instruction?! that's pretty cool :p

Anyhow, after parsing the meaning, we know that the code will move the constant value 1 into R6 register only when R0 register (return value) isn't 2. Then, based on R6's value, R10 that contains the pointer to the CFString object containing "http" is overwritten with R0 that has CFString object pointer of "https". OK, fine. Where are these used?

We can answer our question little bit down the code:
사용자 삽입 이미지

Note that the value of R10 is moved to R3. Also, remember that R3 is the first argument to the format string that's loaded in R2 before the call to make the formatted string with the arguments (pushed onto the stack). This is to build URL to query to get the JSON response.

Now, we know what controls the first argument of this string (the protocol -- https or http), we can test it ourselves! I used my jailbroken iPhone to capture the packet data. Of course, with our theory, the phone needs to be in 3G network rather than WiFi. So, how do we capture the packets?

The answer is simple. we just run tcpdump on 3G interface!

사용자 삽입 이미지

SSH into my iPhone

 
We start listening on pdp_ip0 device:
사용자 삽입 이미지사용자 삽입 이미지

 Once we do some activities in KakaoTalk, we can see the packets are dumped to the file.
사용자 삽입 이미지

Searching friend by uuid==kakao

사용자 삽입 이미지

Then, we can simply scp the dumped file to the local computer and start analyzing!
사용자 삽입 이미지


As you can see down in the screenshots, all of the packets are non-SSL packets and easily analyzable by Wireshark. At this point, we can try multiple things in KakaoTalk to monitor what they are actually sending and receiving. One of the things the clients send to the server as a part of the HTTP header is the session key. I will do a detailed write-up on the session keys, but I just want to note that the session key is the most crucial part (and the only part) of KakaoTalk's authentication.

사용자 삽입 이미지

Request for finding friend by uuid

사용자 삽입 이미지

Session key as HTTP header



I have found another way of disabling SSL such that I don't have to go through this "tcpdump-do stuff-copy over-analyze" madness steps. I can actually see the plain packets in real time so I can easily match the packets that the client is sending out and receiving when I do certain activity on KakaoTalk. This speeds up things a lot, but since I'm not quite done with making the PC version of KakaoTalk, let me hold on to this method just in case I can use the above mentioned method anymore!
(I will release this method once I'm kinda done with the KakaoTalk PC -- the method works both in Android and iOS.)


Next time, I'm going to talk about everything I know about the session key for KakaoTalk.
I still have one part that's not too clear to me, but I'll just post them anyways :p

Thank you for reading!




2011/06/22 21:35 2011/06/22 21:35

Starting with this blog post, and over the next few posts, I'm going to explain in detail what I have found out about internals for KakaoTalk -- the most popular mobile messaging service in Korea.

In this article, I'm going to briefly go over from what KakaoTalk is, and why it's interesting target to look at. (To be honest, I started this just for fun then turned into something that I wanted to blog about :p)

So, let the fun begin!

=-=-=-=-=-=-=-=-=-=-=

Preliminary research on KakaoTalk:
  • It is well-designed (in terms of the structure), well-organized (highly modular), and carefully planned application for the users. And as a plus, it is security-aware application :)
  • There are 15 million users, and the number is growing really fast.
  • Multi-lingual support. They really try hard to push this application globally. They utilize localization, so it's really easy for them to adopt any new language if they wanted to.
  • Kakao, for some reason, doesn't make a PC version of KakaoTalk.
    • Some people have tried to make PC version in the past, but many stopped once every packet is encrypted with SSL and thus packet capturing is meaningless.
    • My guess is that they are working on making KakaoTalk PC, but it may not be true after all :p (Maybe they don't want to be just like Skype, etc. and decided to stay only on mobile side.)
  • KakaoTalk supports both Android OS and iPhone OS.
    • Obviously, Android KakaoTalk is in Java and iOS KakaoTalk is in Object-C.
    • Uses the (very) similar protocol / data structure.
  • Some traces of development environments: (Minor Security Alert!)
    • They seem to use SVN to do version controlling, but failed to manage permissions properly. I didn't look closely anymore, but there might be some juicy/useful information that can be gathered with this vulnerability.
    • Webservers: http://www.kakao.com/.svn/entries , http://www.kakao.com/talk/.svn/entries, etc.

Well, that took me a good 20 minutes or so of googling and poking at their servers.
Not many interesting things.. So I decided to dig up some interesting facts about KakaoTalk!

To do preliminary analysis on applications, I needed to grab the binaries from my iPhone and my friend's Android. This was easily done by scp (secure copy) from my iPhone to my computer, since my device was already jailbroken. Now that I received two applications for KakaoTalk, one for iOS and the other for Android, I immediately started analyzing them.



Preliminary Analysis on KakaoTalk:

Well, before I actually open up the binaries and start disassembling, I started by running through a packet capture tool -- wireshark. As I mentioned above, the traffic was encrypted with SSL. Of course, there is known way of efficiently breaking SSL, so I didn't even try to decrypt the packets :)

사용자 삽입 이미지

SSL encrypted packets


I guess we only have one option now! Open up the binary and reverse engineer!

So we load up in IDA, and find these...awesome... wait.. what?
All the symbols are stripped?!

사용자 삽입 이미지

No Symbols :'(


I don't usually do Obj-C binary reversing, but when I do, I almost always found nicely annotated symbols! I'm not an expert at Mac Hacking, but because of the way Obj-C code does function calls, it's usually not trivial to strip symbols. (Or, I guess there's a tool that does it for you... haven't check it yet.)

BUT! Whatever! Reverse engineering is more fun without symbols. Right?

Again, the way Obj-C code runs is by event-driven function calls. Thus, there's no such thing as control flow as in usual C or C++ programs. Another annoying thing about analyzing mobile phone is that we have to deal with either ARM or MIPS architecture.

Note: For iPhone, the architecture is ARM. So, unless you have hexray-arm, you will have to go through awesome ARM opcodes. For Android, all the apps are java program that runs on Dalvik VM.. so it's usually possible to use decompilers to recover the source code (or at least some kind of IL).


Since two are almost exactly the same client, the program logic should also be very similar -- which means that if we understand one thing thoroughly, we will quickly understand the other one as well, even with the protections/obfuscation.

Ok, the binary for iPhone is stripped. How about Android one?

사용자 삽입 이미지

Obfuscated java!



Aww. Crap. We can successfully decompile the classes, but class names, method names, and variable names are all obfuscated. This makes reversing little bit harder since it's not trivial to follow the method or class names such as 'a' or 'b'. Also, Android KakaoTalk seems to use AESObfuscator. Of course, this can be decrypted since we know the IV (Initialization Vector) and other necessary parameters that were used to encrypt, but it's just a tad annoying. (AESObfuscator is basically just Base64 + AES)

At this point, I realized that KakaoTalk actually care about securing their application and the network traffic to some degree. This doesn't mean that it is perfectly secure, but they tried the security through obscurity -- usually this is a wrong way of doing security...


Anyhow, are we stumped then? The answer is 'not really'.

There are some tricks that we can do:
  1. Get (part of) code flow in iOS applications using debugger.
  2. Re-label the obfuscated java files to understand the program logic.
  3. Hack KakaoTalk server and get the source code...
And... using the information from above techniques + static analysis in IDA, we can actually disable SSL encryption -- such that we can view non-encrypted packet data.

In the next blog post, I will discuss and explain what exactly they do inside of the binary and show how I could bypass SSL and get a clean capture of the packets.

Also in the following series, I will talk about their protocols, data structures and design. And of course, the security measures on each of them.


Thanks for reading!




2011/06/19 23:04 2011/06/19 23:04

네! 그렇습니다~

PPP가 올해에는 데프콘 본선을 진출하게 되었습니다. 작년에 Alternative #1에 있다가 결국엔 본선팀중 한팀은 유령팀으로 알려져서 가슴아팠던 적이 있지만.. 올해에는 확실히 가게 되었네요~

사용자 삽입 이미지



뭐.. 사실 본선 진출은 예선관련 발표날인 4월 1일부터 알고 있었던 사실이긴 합니다..
올해에는 본선진출 룰을 약간 변경하여 작년 데프콘 우승팀, iCTF (UCSB 주최) 우승팀 그리고 Codegate 우승팀을 포함한, 총 12팀이 출전하게 되었는데요.

PPP는 올해 iCTF (사실 2010년 12월) 와 Codegate 대회 모두 우승하면서 double-qualify를 하게 되었습니다 :)

하지만! 거기서 멈출 수 없다는 생각에 예선전도 참가해서 본선진출을 함으로써,
데프콘 역사사 처음으로 triple-qualify 를 성공하게 되었습니다 ~~ 짝짝짝~
(올해 데프콘 우승을 하면 내년에 quadruple-qualify 도 노려볼만 할듯..ㅋㅋㅋㅋ)

여하튼.

그래서 올해 8월초에 PPP 멤버 *다수*가 본선경기를 하기 위해서 라스베가스로 가게 됩니다.
항상 팀원제한이 있어서 열심히 예선 같이해주고 본선은 같이 못간 멤버들도 이번만큼은 거의다 같이갈 수 있게되서 다행입니다.. 아무래도 너무 많이 데려갈 수는 없으니.. 몇명 못오는 사태가 발생하긴 했지만 말이죠 ㅠㅠ;


가기전에 이것저것 준비할것들이 많네요 ㅎㅎ 워낙 경험들이 많은 팀들과 경합을 하는것이다 보니.. 아무래도 힘든 경기겠지만 최선을 다해서 좋은 결과 있기를 바라며~~~

베가스에서 뵙죠!



2011/06/15 04:18 2011/06/15 04:18
 
사용자 삽입 이미지


Positive Hack Days CTF 대회는 러시아에서 열리는 Positive Hack Days 라는 보안세미나에서 열리는 CTF입니다.
PPP팀은 이번에 초청을 받아서 모스크바를 다녀오게 되었습니다. 본 대회는 예선전은 없었고, 주최측인 Positive Technologies가 다른 CTF 성적들을 관찰하고 직접 초청장을 보낸 대회였습니다. 그래서 그런지 러시아나 유럽지역에서 정말 잘한다고 실력이 증명된 팀들도 다수 참여했었습니다.

총 10팀이 참여한 대회였고, 실시간 공격/방어 해킹대회로써.. 저희팀은 사실 경험이 거의 없는 대회 종류중 하나였습니다. 그래서 사실 꼴찌만 하지 말자 라는 각오로 출발했고, 데프콘 본선을 위한 준비단계로 여기기로 하고 참가하게 되었습니다.


대회 날 아침! 다같이 화이팅을 외치고, PPP 대회용 티셔츠를 입고! 바로 옆건물에 있는 대회장으로 발걸음을 옮겼습니다.
사용자 삽입 이미지

전날 너무 많이 걸어서 아직도 피곤에 쩔어있는 모습 ㅠㅠ



이미 싸인이 붙어있더군요 ㅋㅋ 현수막도 아니고 간판이 있음... 후덜덜..
사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

내부를 정말 멋있게 잘 꾸며놨더군요 ㅎㅎ
안내데스크도 있고 ㅎㅎㅎ 저기 보이는 사진사 아저씨가 정말 ㅋㅋ 열정적으로 사진을 찍어주셨습니다.. 행사 내내 ~

사용자 삽입 이미지


로비(?)에서 기다리고 있으니 다른팀들도 하나 둘 씩 보이기 시작했습니다 :)

사용자 삽입 이미지

Nibbles

사용자 삽입 이미지

LeetMore



나중에 알고보니 여기가 클럽이라는군요 ㅋㅋㅋ 클럽을 개조해서 세미나/경기장으로...

사용자 삽입 이미지

대회장



이극고, 경기시간이 다가오고.. 각 팀들이 자리를 잡고 셋업하기 시작합니다~

사용자 삽입 이미지사용자 삽입 이미지


경기 내내 다이나믹한 모습을 보여줬던 스크린들 ㅎㅎ 공격과 방어 상태가 실시간으로 업데이트 됩니다 :D
사용자 삽입 이미지사용자 삽입 이미지

경기 중반쯤 이기고 있을때!


사용자 삽입 이미지


대회 방식은 데프콘 본선대회와 비슷한 형식이었습니다. 주최측에서 준비한 10개의 VM이 각 팀마다 하나씩 주어지게 되고, 각 서버들은 취약점이 있는 서비스들을 포함하고 있습니다. 간략하게 해야할 것들을 설명하면, 각 서비스들을 분석하고 취약점을 찾은 다음에 일단 자기 서버의 서비스를 패치해서 보완하고, exploit을 만들어서 다른 팀들의 서비스에 공격을 해서 침투한 다음 키를 빼와서 중앙서버에 제출해야합니다. 조금 특이한 점은 한 번 공격한 서버의 서비스는 다시 공격 할 수 없다는것이었습니다 (서비스의 키가 주기적으로 변경되지 않습니다..)

총 점수는 공격점수 (attack), 사이드 챌린지 (blackbox), 방어점수 (defense), 그리고 서비스 점수 (availability)를 합산해서 계산되게 되는데, 각 점수들을 설명하자면:
  • 공격점수: 각 팀의 각 서비스마다 유니크한 키가 저장되어있습니다. 다른 팀들의 서비스를 공격해서 침투한 다음 키를 뽑아와서 중앙서버에 넣으면 점수가 올라갑니다. 각 서비스마다 점수배점이 다르며, 키가 변경되지 않기때문에 한번 공격한 서비스는 다시 공격할 수 없습니다 (해봐야 이득이 없음).
  • 사이드 챌린지: 이 문제들은 같은 내부 네트워크 어딘가에 있는 주최측의 서버들에서 돌아가고 있는 서비스들을 공격해서 키를 얻을 수 있는 문제들이었습니다. 네트워크 스캔과 포트 스캐닝으로 서비스들을 알아낼 수 있었지만, 대부분 웹성향이 강해서 저희팀은 거의 풀지 않았습니다.
  • 방어점수: 100%에서 시작해서 다른팀이 자기 서버의 키를 제출할 때마다 깎이는 점수입니다. 다행히 저희는 패치를 빨리해서 얼마 깎이지 않고 경기를 종료할 수 있었습니다.
  • 서비스점수: 이것 역시 100%에서 시작하는 점수입니다. 중앙 서버에서 틈틈히 각 팀 서버들의 서비스들이 정상작동을 하고 있는지 체크하여서 비정상작동중이거나 응답이 없을 경우에 깎이는 점수입니다. 가끔 패치를 너무 과도하게 해서 기능을 실수로 없애버리면 점수가 깎이기도 합니다.. 저희도 경기 중간에 한번 그랬던것 같네요 ㅎㅎ

역시 가장 특이했던점은 같은 서비스를 한번 이상 공격할 수 없었다는점입니다.
매 1~2시간 마다 새로운 문제가 같은 서비스 이름으로 '푸시'가 되는 방식으로 진행이 되었습니다. 매 1~2시간마다 문제가 아예 바뀌는거죠 (바이너리, 스크립트 등).. 그리고 키 역시 그때 같이 새로운것으로 업데이트가 됩니다.
총 10시간 정도 했던 대회인데 각 서비스마다 2~3번씩 바뀌었던것 같네요.

한번은 취약점을 찾아서 공격코드까지 다 만들어놓고 다른 팀들에게 자동으로 공격해서 키를 받아와서 제출까지 자동으로 해주는 스크립트를 짠 뒤에 실행하려는 찰나에 새로운 문제가 푸시가 되면서... exploit이 싹 쓸모가 없어지는 상황도 발생했었습니다 ㅠㅠ;

어찌되었든!
사실 실시간 공/방전은 처음이라서 걱정을 많이 하고 갔는데, 다행히 팀웍이 너무 잘 맞고 다들 잘해줘서 여유있게 1등을 해버렸네요 =ㅇ=;
짝짝짝~

사용자 삽입 이미지


=-=-=-=-=-=-=-=-=-=-=

경기 종료 후에는 케익컷팅과 조촐한 파티가 이어졌습니다~

사용자 삽입 이미지

러시안들이 케익을 자르는 방법.jpg


사용자 삽입 이미지사용자 삽입 이미지

메인 스테이지에서 CTF가 진행되는 동안 다른곳에서는 세미나 발표와 다른 대회들이 진행되었는데, 그중에서 흥미로운것은 Hack2Own 이라는 대회였던것 같습니다 ㅎㅎ 아실분들은 아실테지만 Pwn2Own이라는 대회와 아주 흡사합니다. 최신 버전들의 소프트웨어들을 상대로 0-day를 써서 해킹에 성공하면 상품이나 상금을 가져가는 대회인데, Pwn2Own에서는 사용된 exploit 테크닉을 공개해야하는 반면 Hack2Own은 그냥 해킹 성공만 하면 상품은 가져가고 exploit도 공개 안한채로 그냥 다른데가서 또 쓸 수 있는게 룰입니다 ㅎㅎ

하지만 여기서 끝난것이 아니었으니!
한가지 대회가 더 남아있었습니다 ㅎㅎ 이름하여 Too Drunk To Hack!
이름에서 대충 파악하실 수 있겠지만, 보드카를 마시면서 해킹하는겁니다 ㅎㅎㅎ

사용자 삽입 이미지

즐비하게 놓인 술잔들 ㅎㅎ



Nibbles에서도 저희팀에서도 참가를 했습니다. 저희팀에서는 Tyler와 Andrew가 참가했습니당 ㅎㅎ
사용자 삽입 이미지사용자 삽입 이미지


시작하기전에 술마시고 어떤일이 일어나든 주최측은 책임을 지지 않겠다는 동의서에 서명을 했습니다 ㅋㅋ
사용자 삽입 이미지


그렇게.. 한잔 두잔..ㅎㅎ
사용자 삽입 이미지

다 마시기 무섭게 바로바로 채워지는 술잔들...ㄷㄷ
사용자 삽입 이미지

원래 룰은 해킹을 시도하다가 Snort 경보를 울리면 마시는것이었는데, 웹해킹이어서 그런지 다들 많은걸 시도를 안해봐서 아무도 안마시게 되자.. 룰 급변경! ㅋㅋ 무슨 공격시도든 해도 되지만, 매 3분마다 마셔야된다는..!!

그래서 마시고 마시고~
사용자 삽입 이미지

적어도 5잔은 마신 Tyler ㅋㅋ



다행히 다들 술에 취해 쓰러지기전에 한명이 풀어내서 경기는 종료가 되었습니다 ㅎㅎㅎ


=-=-=-=-=-=-=-=-=-=

끝나고 나서 얼마 안있고 시상식이 이어졌는데요~
CTF부터 TooDrunkTohack 까지 골고루 우승자들이 하나씩 나와서 상을 받아갔습니다~
사용자 삽입 이미지

사용자 삽입 이미지

Hack2Own에서 Safari 0-Day로 우승한 친구 ㅋ


저희 시상식때는 죄다 나가있어서 아무도 사진을 안찍었네요 ㅋㅋㅋ 인터넷 뒤져보면 나올지도..

하여튼 ㅋㅋ 상금 주는것도 정말 러시아스러웠습니다 ㅎㅎ
검은색 돈가방을 건네주더군요 ㅋㅋㅋ 아래는 숙소 돌아와서 돈가방을 열고 한컷~

사용자 삽입 이미지


정말 대회 준비 많이 한게 눈에 보이고, 또 운영도 정말 매끄럽게 잘 해줬습니다..
이렇게 완성도 높은 CTF 참여하기 쉽지 않은데.. 저희는 정말 운이 좋았던것 같네요 ^^

앞으로 더 발전할 Positive Hack Days! 기대하며 글을 마칩니다~~


사용자 삽입 이미지

사용자 삽입 이미지



2011/06/07 03:10 2011/06/07 03:10

사용자 삽입 이미지

졸업식이 있었던 5월 15일 바로 다음날인 16일에 저와 다른 4명의 멤버들은 러시아행 비행기에 올랐습니다.
뭐.. 게으른 제가 다른 나라로 여행가는 일은 대회밖에는 없는듯 싶군요 ㅎㅎ

이번에는 러시아에서 열리는 Positive Hack Days 라는 보안세미나에서 열리는 CTF에 초청을 받아서 모스크바를 다녀오게 되었습니다. 본 대회는 예선전은 없었고, 주최측인 Positive Technologies가 다른 CTF 성적들을 관찰하고 직접 초청장을 보낸 대회였습니다. 그래서 그런지 러시아나 유럽지역에서 정말 잘한다고 실력이 증명된 팀들도 다수 참여했었습니다.

이번 포스팅은 두 차례로 나눠서 하도록 하겠습니다.
첫번째 포스팅은 전체적인 러시아 여행기, 그리고 두번째 포스팅은 대회에 집중해서 후기를 쓸 예정입니다.

그럼! 시작해볼까요!

=-=-=-=-=-=-=-=-=-=
[Day 1]

우선 여름이라 인턴 등 때문에 각자 출발지가 조금씩 달라서, 일단 러시아에 도착해서 만나기로 했습니다 :)

사용자 삽입 이미지

SVO 공항

사용자 삽입 이미지

SVO 공항


일단.. 첫번째 들은 생각은.. '러시아는 아직 냉전시대의 후유증을 겪고 있구나' 라는 것이었습니다.
제가 많은 나라를 가본것은 아니지만, 미국과 한국 등에 비하면 훨씬 낙후되있는 느낌을 받았습니다.
나중에 가장 문제가 많이 됬던 것은.. 거의 아무도 영어를 하지 못한다는것입니다ㅠㅠ..

저희가 묵었던 호텔 Molodezhnaya. 여기서 세미나와 대회가 열렸기 때문에 일부러 숙소를 이쪽으로 택했습니다.

사용자 삽입 이미지

일단 숙소로 와서 짐을 풀고 당연히 인터넷부터 확인하기 시작했습니다 ㅎㅎ

사용자 삽입 이미지

하지만 아무래도 모스크바 변방에 있는 호텔이어서 그런지.. 내부적으로 제공하는 인터넷은 없었고
한국의 WiFi 존 같은 서비스를 하는데서 제공하는 무선인터넷이 겨우 잡히는 정도였습니다. 하지만 유료..
그래서 바로 ping tunneling을 시도했지만 놀랍게도 (이런 서비스에선 99% ping tunneling 가능함) 막아놨더군요.. 방법은 두가지였는데, 하나는 dns tunneling을 하는방법 그리고 다른 하나는 로비에 가서 공짜 인터넷을 쓰는 방법이었습니다.. ㅋㅋ

호텔 방에서 나가기 정말 싫을때는 '매우 무지 엄청 정말' 느린 dns 터널링을 이용해서 인터넷을 하다가,
정말 인터넷이 필요하면 아래층에 다녀오곤 했습니다.
여기서 또 한가지 느낀것은.. 러시아에서는 거의 모든곳이 실내흡연이 가능합니다.
그리고 흡연자가 엄청 많아요 ㅎㅎ 맑은 공기 찾아 다니느라 힘들었습니다 ㅠ

배가 고파지니 밥을 먹어야겠는데.. 지도에서 음식점을 하나 찾아서 시도해보기로했습니다.
물론 말이 안통하니 걱정이 태산이었습니다 ㅎㅎ 못찾고 빙빙 돌아서 일단 찾는데만 1시간여를 소비 한 뒤에, 결국 찾아서 들어갔습니다! 다행히 그냥 눈앞에 있는것들을 지목만 하면 되는식이라.. 일단 성공.

사용자 삽입 이미지

돌아오는 길에 근처 사진 몇장..
사용자 삽입 이미지사용자 삽입 이미지

안타깝게도 저희 멤버중 하나인 David은 채식주의자라 거의 아무것도 먹지 못했기 때문에..
오는길에 빵을 사가지고 왔습니다 ㅋㅋ 억수로 크더군요..

사용자 삽입 이미지

David의 식량


또 한가지, 러시아의 여름은.. 정말 날이 길다는것.
다음은 밤 10시에 찍은 사진입니다 -_-;;;; 거짓말 아님....
사용자 삽입 이미지

이렇게 고달팠던 저희 러시아 여행의 첫번째 날은 무사히 마쳤습니다 ㅠㅠ


=-=-=-=-=-=-=-=-=-=-=-=-=
[Day 2]

다음 날 아침엔, 받은 책자에 있었던것들을 쭉 읽어보면서, 한 켠에 러시아어 알파벳이 있길래 '말은 못해도 읽을 수 있게라도 하자' 라는 마음에 열심히 공부했습니다 ㅋㅋ 왜냐면, 한국도 마찬가지지만 꽤 많은 단어들이 영어를 발음나는데로 적어놓은 간판들이 많아서 대충 발음만 낼 수 있으면 절반정도는 뭔지 때려맞출 수 있기때문이었죠 ㅎㅎ

사용자 삽입 이미지

Greek letter가 많이 쓰이고 발음도 비슷하다. (예: 파이=P발음, 감마=G발음)


오늘은 저희 나름대로 모스크바 중심에 있는 붉은광장 (Red Square)를 관광하기로 마음 먹었습니다!
일단 근처에 있는 메트로 (지하철) 역으로 가서 표를 사기로 했습니다.

사용자 삽입 이미지

러시아를 좀 아시는 분이라면 아실테지만, 모스크바는 붉은광장을 중심으로 원형형태의 도시 형태를 취하고 있습니다. 마치 나무의 나이태 모양 처럼 말이죠 ㅎㅎ 저희는 북쪽에 있었으므로 남쪽으로 내려가는 방향의 메트로를 탔습니다. 물론 영어라곤 찾아볼 수 가 없어서 거의 러시아어를 그림맞추기 식으로 따라가며 다녔습니다 ㅎㅎ

빠르긴 무쟈게 빠르더군요.. 그 먼 거리를 초단시간에.. 근데 지하철이 오래되어서 그런지..
이러다가 탈선해서 죽겠구나 싶은적이 한두번이 아니었다는 ㅠㅠ;

일단 중심쪽 역에 도착한 뒤에 나와서 걷기 시작했습니다.

사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지

자세히 보시면 바실리 성당을 꽃으로 표현 해놓은 잔디밭입니다 ㅎ


걷다보니 삼성건물(?)도 보이는군요.. 정확히 뭐하는곳인지는 모르겠음..
사용자 삽입 이미지사용자 삽입 이미지

그러다가 붉은광장 주변의 공원같이 조성되있는 곳으로 들어가서 맑은공기좀 마시며 산책을 계속 했습니다.

사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

잔디 위의 붉은별 -0-
사용자 삽입 이미지

분수들도 많고 이솝우화에 나오는 캐릭터들 동상들도 있네요 ㅎㅎ
사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지


벽돌들이 다 빨간색~~
사실 각 건물들이 어떤 건물인지는 알 리가 없었고.. 그냥 이뻐보이는 건물들 사진을 마구 찍었습니다 ㅠㅠㅋㅋ

사용자 삽입 이미지


여기는 러시아 역사 박물관이었는데요 ㅎㅎ 현지인들을 포함해서 투어리스트까지 엄청 줄이 길었습니다 ㅎㅎ
마지막에 광장에서 나오기 전에 쭉 둘러보고 왔습니다 ㅎㅎ 역시 저는 이런거 보는 타입은 아닌가봐요..
몇 개 빼곤 엄청 지루했음...
사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지


레닌이 묻혀있는 곳...
사용자 삽입 이미지

바실리 성당. 너무 이뻐서 여기루 그림그리러 오는 사람들도 많은것 같네요 ㅎㅎ
사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지

넓디 넓은 광장~



대충 다 둘러보고 좀전에 말씀드린대로 박물관에 들어가서 쭉 돌아봤습니다..
뭐 사진은 정말 많이 찍었지만 의미가 없으므로 ㅋㅋ 걍 랜덤으로 몇장 집어서 올립니다 ㅎㅎ

사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지


그런 다음에는 모스크바 동부쪽에 있는 Izmailovsky 공원으로 향했습니다 :)

사용자 삽입 이미지사용자 삽입 이미지

일단 아침부터 많이 걸었기 때문에 배가 출출해진 상태라,, 밥을 먹어야하는 때가 도달하고 말았습니다!
밥시키는게 제일 어려웠던 저희로써는 ㅜㅜ 정말 들어가서 메뉴 고르고 먹을만한게 나오길 바라는게 전부였습니다ㅋㅋㅋ  케밥을 먹었는데 나름 맛있었습니다 ㅎㅎ 굳 쵸이스!

사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지

아참. 음료수가 사진에 나와서 하는 말이지만, 러시아에있는 탄산음료에는 미국에서처럼 corn syrup을 안쓰고 설탕을 쓰더군요.. 그래서 맛이 미묘하게 달랐습니다.. ㅋㅋ 어떤게 더 좋은지는 잘..

맑은 공기를 좀 섭취해준뒤, 다음 날 아침 일찍부터 있을 대회를 위해서 슬슬 집으로 돌아왔습니다~
사용자 삽입 이미지


=-=-=-=-=-=-=-=-=-=-=-=
[Day 3]

이 날은 대회가 있었던 날입니다 :)
다음 포스팅을 참고하세요!


=-=-=-=-=-=-=-=-=-=-=-=
[Day 4]

대회가 끝나고 다음날에는 대회 운영측에서 제공해준 시티투어를 했습니다 ㅎㅎ
어느정도 짐작은 했지만 붉은광장에 한번 더 가게 되었습니다.. Orz..

하지만 설명을 들으면서 다니니까 조금 더 의미있는 투어가 되더군요 ㅋㅋ 그냥 무작정 걷는것보단..

관광버스를 타고 이동~~
사용자 삽입 이미지

러시아버전 맥도날드!
사용자 삽입 이미지


일단 첫번째로 향한곳은 모스크바 대학교였습니다.
뭔가 웅장하다는 느낌? ㅎㅎ 건물도 멋있구, 주변 풍경도 일품입니다 -_-b

사용자 삽입 이미지

사용자 삽입 이미지

나중에 꼬마들이 풍선날리기 했을때~


사용자 삽입 이미지사용자 삽입 이미지



모스크바 대학교 앞에서 사진들~ ㅎㅎ 저희 팀원들과 Nibbles 팀원들!

사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지


건너편에는 잡화상이 있었는데 ㅋㅋ 별거를 다 팔더군요..
엄청 오래되보이는 사진기들부터 시작해서~~
(저거 사가지고 골동품점에서 팔면 이득이 남을것 같았지만..귀차니즘..)

사용자 삽입 이미지


모스크바 대학 관광을 마치고, 다음 행선지는 저희가 이틀전에 들렸던 붉은광장이었습니다 :p
가는길에 대형 Thinkpad 광고를 보게되었습니다 ㅋㅋ 진짜 커요..
사용자 삽입 이미지


친절히(?) 영어로 설명해주고 계신 현지 가이드분들 ㅋㅋ
사용자 삽입 이미지


뭐 붉은광장은 이미 위에서 사진들 올렸으니 ㅋㅋ 중복은 자제하도록 하겠습니다.
관광이 끝나고 다같이 식사를 하러 갔습니다. 메트로를 타고 갔는데 한국의 지옥철을 상기시켜주더군요 ㅎㅎ

사용자 삽입 이미지


지하철을 한번 갈아타고 도착한 곳은 ...... (못읽음) 라는 곳이었는데요 ㅋㅋ 흑맥주가 유명한집이었나봅니다~_~ 저야 원채 술을 안마시니 ㅋㅋ 맛있는지 안맛있는지는... 잘.. ㅋㅋ 아마 승진이형 (beist)이 왔으면 좋아했을듯..

사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지사용자 삽입 이미지

음식으로 배를 좀 채우고 나니, 연거푸 데낄라 행진~
사용자 삽입 이미지사용자 삽입 이미지


ㅋㅋㅋ 잠깐 화장실을 들렸는데 물내리는 버튼이 특이해서 한장 찍었습니다 ㅋㅋㅋ
사용자 삽입 이미지


열심히 토론도 하고 ~ 마시기도 하고 ~
(러시아의 젊은세대들은 어느정도 영어를 합니다 ㅋㅋ ..다행히)

사용자 삽입 이미지사용자 삽입 이미지

재밌게 놀다가.. 저와 Ricky, 그리고 David은 먼저 숙소로 돌아왔고.. Andrew와 Tyler는 좀 더 남아서 밤 늦게까지 놀다가 들어왔습니다 ㅎㅎ 그와중에 야경을 찍어왔는데 정말 이쁘네요
사용자 삽입 이미지

붉은광장 야경




=-=-=-=-=-=-=-=-=-=-=
[Day 5]

마지막 날인 다섯째날에는 딱히 뭐 없었습니다..ㅋ
그냥 빼놓은거 없는지 확인하고, 호텔 체크아웃 하고, 그리고 공항으로 향했습니다.

사용자 삽입 이미지

SVO 공항 외관


사용자 삽입 이미지사용자 삽입 이미지


그렇게 미국행 비행기를 게이트 앞에 앉아서 기다리고 있는데.. 옆에서 새소리가 들려서 '응?' 하고 봤더니..
참새 한마리가 옆자리에 앉아(?) 있었습니다 ㅋㅋ

사용자 삽입 이미지


그리고 곧 이륙. 러시아! 참 재밌었습니다~ 굳바이.
사용자 삽입 이미지


=-=-=-=-=-=-=-=-=-=-=
[Day 6(?)]

음... 피츠버그에 돌아와버렸군요 ㅋㅋ 마구마구 스며드는 압박감과 스트레스!
집에 돌아갈 버스를 기다리는 도중에 재미난 차량을 보았습니다 ㅋㅋ
아실분들은 아실테지만! 바로 404 에러 코드가 적혀있는 밴.. 사진을 안찍을수가 없었습니다 ㅋ_ㅋ

사용자 삽입 이미지

집에 돌아와서는 뭔가 좀 아쉬워서 (저는 피츠버그에 남지만, 친구들은 다음날 DC로 가야했기 때문에), 영화를 보러가기로 했습니다 ㅎㅎ 마침 캐리비안의 해적 4편이 개봉할 시점이어서 ㅋㅋ 바로 봤다는..

사용자 삽입 이미지

밤 11시 30분에 영화 @_@



워낙 전편들이 훌륭했어서 그런지 그렇게 큰 재미와 감동은 없었지만 ㅎㅎ 나름 괜찮게 봤습니다.


=-=-=-=-=-=-=-=-=-=-=-=

요렇게! 제 러시아 여행기는 끝이 납니다~
횡설수설 긴 얘기 읽어주셔서 감사하구, 재밌게 읽으셨으면 좋겠네요 :)

다음 편은 PHDays CTF 해킹대회에 대해서 쓸 예정입니다!! 기대해주세요~




2011/06/03 01:40 2011/06/03 01:40

사용자 삽입 이미지
두둥..!!
그렇습니다.. PPP는 이제껏 항상 ... 이라고 해봐야 2년이 채 안됬지만, CTF 경기를 참여만 해왔습니다.
그래서 무언가 색다른걸 해보자 ~ 라는 취지로 저희만의 CTF 대회를 주최하는 계획을 짜기 시작했습니다.
사실 계획 자체는 지난 학기말부터 (2010년 12월) 나왔던 얘기였지만, 실제로 실행에 옮기기 시작한건
대회주최 약 2달 정도 전인 2월쯤이었습니다. 그 전까지는 일단 다들 각자 brainstorm을 해왔습니다.
특히 Plaid CTF (pCTF) 같은 경우에는 올해가 첫 회였기 때문에 인프라부터 문제들까지 바닥부터 만들어 올려야 했기 때문에 조금 부담감이 없지않아 있었고, 그만큼 학기중에 수업들으랴, 과제하랴, 대회 참가하랴, 대회 준비하랴.. 정말 정신 없는 학기였던것 같습니다 :p
하지만 다들 한번쯤은 중형 프로젝트에 참여해본 적이 있던터라 개발과정이 그렇게 거칠지만은 않았습니다.
버젼 컨트롤은 git과 svn을 둘다 사용했고, 내부적으로 프로젝트 관리는 redmine과 wiki를 병행해서 사용했습니다. 사실 어떤식으로 하는것이 가장 효율적인지 알지 못했기때문에 이것저것 실험차 시도해본것들이 많았습니다.
 
사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지

여하튼 이래저래 아이디어들을 종합하고 구상을 짠 다음, 개발하고 테스팅 하는 매우 무난하며 일반적인 개발 루틴으로 대회 준비를 했습니다.. 물론 매주 금요일/토요일 literally 하루종일 쏟아야 했지만요 ㅠㅠ

사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지


2달동안의 폭풍 개발 및 테스팅을 어느정도 한 뒤에, 어느정도 구도가 잡혔습니다.
도중에 갑자기 게임 방식 및 보드 설계를 바꾸는 바람에 정신이 없긴 했지만, 대회가 막상 진행되고 나서 바꾸길 잘했다는 생각이 들 정도로 재밌었습니다 :) -- 적어도 저희한테는요 ㅋㅋ

게임 보드 완성 후 Rules페이지에 설명~

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지


또, Lockheed Martin에서 스폰서를 자청해줘서 막대한 상금들과 작은 상품들까지 걸리게 되었습니다
사실 저희도 처음 주최하는 대회라 불안했는데 전혀 걱정없이 처음부터 밀어준 LM사에게 감사를 표합니다~

이래저래 해서~ 총 상금 4000 USD와  티셔츠, 깃발 상품등을 걸고 대회가 시작되었습니다.

사용자 삽입 이미지

커맨드 센터!

사용자 삽입 이미지사용자 삽입 이미지


정말 많은 대회를 참여했었던 저희로써는 딱 한가지 도전해보고 싶은것이 있었는데요..
바로 대회 시작시간을 지키는것이었습니다. 보통 유명한 대회 (예를들어 데프콘)들이라고 해도 피해가지 못했던 초반 러쉬! 아무래도 엄청나게 많은 트래픽이 한번에 몰려서 모든게 멈춤상태가 되고 부서지는경우가 족족이지만 사실 저희는 내심 여러가지 로드 밸런싱을 해놓은 상태였습니다..

하지만 문제는 30여개가 넘는 문제를 보드에 배치하는데에 시간이 생각보다 오래 걸렸다는것입니다 ㅜㅜ
일일히 X,Y 좌표를 찍어줬어야 했는데, 문제 카테고리등과 거리 간격등으 조정하면서 추가하다보니 생각보다 좀 길어졌고, 또 대회 직전이라 긴장감이 더 고조되서 집중해서 할 수가 없더군요 ㅎㅎ

그래서 결국 정시에 시작은 못하구 25분 가량 지체한 뒤 시작되었습니다. 정시가 되면서 사람들이 refresh를 때려대니까 순간적으로 느려져서 문제 추가도 더 힘들어지더군요... 정말 무시무시한 트래픽이었습니다. 초당 몇천 리퀘스트가 들어 오더군요..

그래도 다행히 5~10분 내로 전체적으로 안정화가 되고 첫 세문제가 열렸습니다.
문제들이 처음 공개되고 고요해지는 IRC의 느낌이란~
그 다음부터는 수많은 쿼리 (1:1 대화)들과.. (한때는 쿼리창이 90개 가까이 열려있었다는..)
48시간동안 잠과의 싸움 이었습니다 ㅎㅎ 물론 대회를 참가하는것이 아닌 만큼 잠은 자고싶은 만큼 잘 수 있었지만, 아무래도 운영하는 재미도 쏠쏠하고~ 또 혹시 모를 일에 대비해서 적어도 두 명은 항상 깨어 있는것으로 했습니다.
다행히 화면에 띄워놓은 key submission 로그 창과 irc에서의 대화들이 간간히 재밌는것들이 많아서 잠 깨는데 도움이 많이 되었습니다 :)
특히, disekt 팀이 여기저기 심어놓은 가짜 키들을 넣는 팀들이 의외로 많더군요.. 키 내용만 읽었더라도 키가 아니라는걸 알 수 있었을텐데 말이죠 ㅠㅠ;
사용자 삽입 이미지

그리고 몇몇은 문제 출제자의 이름을 밝혀내는데도 성공을 한 듯 보이는군요 ㅋㅋ
잠이 필요하다고 절규를 외치기도..

사용자 삽입 이미지

그리고 중간에 ssh 들어가서 푸는 문제에서 참가자들이 너무 bruteforce를 많이 돌려서 로드가 심하게 걸리길래 서버 이미지를 복사해서 새로 다른 머신에다가 똑같이 카피해놓고 wall로 공지를 날렸는데... 그 공지 내용을 키로 입력한 팀도 있네요... orz..  (If machine is slow, please refer to the announcement)

사용자 삽입 이미지

경기 중후반쯤 가서는 저희가 key submission log를 보고있다고 알아챈 몇몇 팀이 아스키아트 선물을 선사하기도 했습니다 ㅋㅋ 보기 참.. 그런것도 올라왔지만 그나마 귀여운거 캡쳐해서 올립니다 ㅎㅎ

사용자 삽입 이미지

뭐.. 대회는 나름 순조롭게 진해되었습니다. (개인적인 생각으로는요 ^^;)
마지막에 가서 Hacking For Soju (HFS)가 5분남기고 역전을 하면서 우승을 거머쥐었습니다!
[작년 코드게이트 생각이 나는군요 ..훌쩍..]
48시간이 훌쩍 지나가고 경기가 마감되었습니다.

사용자 삽입 이미지

상위 5팀


보시다시피 상위 5팀이 모두 다른 나라! (6위팀은 미국팀이라 상위 6개팀이 6개 나라!)
카이스트 대학교 보안동아리인 GoN 팀 역시 좋은 성적으로 마무리 했습니다.
경기 종료 후 확인했더니 총 497팀이 등록을 했었더군요 ㅎㅎ

사용자 삽입 이미지

상위 팀들의 write-up도 마련되어있습니다.
1. HFS팀 보고서



2. C.o.P팀 보고서


3. SSH팀 보고서


4. Sutegoma2팀 보고서



대회를 하면서 신기하면서도 뿌듯했던 점은, 상위 팀들이 푼 문제 수는 비슷하지만 각자 서로 다른 문제들을 푸는 진풍경이 벌어지더군요 ㅎㅎ 각자의 강점에 맞춰서 말이죠. 총 35개 문제중에서 망가진 문제 하나를 제외한 (나중에 뺐음..) 모든 34문제가 적어도 한팀에 의해서는 풀렸습니다. 문제들을 잘 만들었다는 뜻으로...... 마음대로 넘겨짓고 가겠습니다 ㅋㅋ..

정말 팀원 모두에게 정신없이 바쁜 두 달이 지나가고..
코드게이트 뒷풀이 및 pCTF 뒷풀이를 한번에 같이 한국 음식점에서 했습니다!

사용자 삽입 이미지
사용자 삽입 이미지


다들 수고 너무 많았구~ 정말 유익하면서도 재밌었던 경험 같습니다 :D
내년 Plaid CTF 2012 도 많은 기대 부탁드리며 ㅎㅎ



2011/05/21 22:18 2011/05/21 22:18
Plaid CTF 2011 :: 2011/05/21 22:18 Hacking/PPP
 
사용자 삽입 이미지

두둥~
사실 2편은 코드게이트에 대한 얘기보다는 대회 후 팀원들과 보낸 한국여행기(?) 내용입니다 -_-;

화요일 밤에 코드게이트 네트워크세션과 2차까지 마친 후, 수요일 대낮까지 잠을 퍼잔 저희 팀은 대충 점심을 해결하고 과제, 발표준비 등을 하다가.. 저녁에는 HFS팀이 한국에서 '개고기'를 먹어보고싶다는 소원을 이뤄주기 위해 모인 그룹에 쪼인을 해서 저녁 식사를 했습니다... 저희 팀원들도 다들 잘 먹더군요ㅎㅎ
물론.. 저는 그냥 삼계탕 먹었다는 ^^;;

사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

식사를 마친 후에는 HFS팀원들이 포켓볼을 치러 가고싶다고 해서 식당 근처의 당구장을 찾아 두리번 거렸습니다. 그런데 아무래도 한국에서는 거의다 3구나 4구만 치기때문에 포켓볼 테이블이 있는 당구장을 찾기가 어렵더군요;; 두어번 시도한 끝에 마침 딱 2 테이블이 있는 당구장을 발견하고 들어갔습니다.

사용자 삽입 이미지

PPP vs. HFS! Round 2!


사실은 당구치면서 맥주를 마시고 싶다고 했었는데.. 아무래도 분위기가 목숨걸고(?) 치시는 분들이 많은지라.. 알콜은 전혀 용납되지 않는 분위기였습니다 ㅎㅎ 그래서 한 40여분만 치다가 바로 나왔습니다.

HFS팀은 이날이 한국에서 마지막 밤이었기때문에 조금 더 놀고 싶어했지만 ㅠㅠ
저희 팀은 다음 날 서울여대에서 있을 발표준비가 완료되지 않은 관계로 여기까지만 놀고 헤여졌습니다.
숙소로 돌아와서 폭풍 강연준비를 마저 한 뒤, 한 오전 4시쯤 되서 잠이 들었습니다~~



.... 다음 날 아침 9시쯤 기상해서 씻고, 슬라이드들을 대충 다시한번 검토하고.. 장소 확인 등을 마친 후에 짐을 싸서 호텔을 나섰습니다. 아침겸 점심으로 강남역 CGV 뒤쪽에 있는 '라멘 오모야' 라는 집에서 식사를 했습니다.

사용자 삽입 이미지

한국에 놀러가도 9호선 타볼 일이 거의 없었는데, 서울여대를 가기 위해서 한번 타봤습니다 :)
(아..주..짧게 2정거장이었지만요 ㅠㅠ)

사용자 삽입 이미지

태릉입구역에 도착한 뒤에 택시를 잡아서 서울여대 입구까지 갔는데 3천원 정도 나오더군요 ㅎㅎ
외국 친구들은 도대체 어떻게 택시비가 적게 나올 수 있냐며 의아해했습니다..

조금 일찍 출발했던 터라 다행히 시작 전까지 시간이 충분히 남아있어서 여유롭게 서울여대 2과학관에 계신 김윤정 교수님 오피스를 찾아갔습니다. 표지판을 따라 2과학관을 찾아가는데 이 길이 맞나 싶었는데, 확신시켜준 것이 있었으니!!

사용자 삽입 이미지

무려 플랜카드! 감동의 쓰나미였습니다 ㅠㅠ
(사실 강연 끝나고 가져갈수있냐고 부탁하고 싶은 마음은 굴뚝같았지만..ㅋㅋ 참았습니다)

김윤정 교수님 오피스에서 강연 시작전까지 담소를 나누며 마지막으로 슬라이드 및 데모 점검을 했습니다.
중간에 김형종 교수님도 잠깐 내려오셔서 저희를 반갑게 맞아주셨습니다 :)

저희가 진행한 세미나는 사실 김형종 교수님께서 가르치시는 서울여대 정보보호학과 4학년 과목인 '침입탐지 및 대응시스템' 수업 시간을 빌려서 진행되었습니다. 총 2 발표로 구성이 되어있었으며 첫번째는 저와 Andrew가 약 1시간 20분가량 진행한 'Buffer Overflow Exploitation, Protection Schemes, and how to bypass them'이었고 두번째는 Tyler가 준비한 'Physical Security - Lock Picking' 이었습니다.

<발표자료 열기...>



사실 발표 모두 영어로 준비했던 상태이었지만, 제가 인트로를 한국어로 하면서 순간 제 발표는 한국어 발표가 되어버렸습니다 ㅎㅎ.. Andrew가 진행한 부분은 간간히 제가 통역하며 진행하였습니다.

발표를 해본적이야 한 두번 있었지만.. 이렇게 많은 분들 앞에서.. 특히 50여명의 여성분들앞에서 토크를 한다는게 엄청 부담이라는것을 발표를 시작하고 나서야 깨달았습니다 ㅠㅠ 다행히 제 어줍잖은 개그(?)에 웃어도 주시고 반응도 잘 해주셔서 점점 부담감 없이 진행 할 수 있었습니다~

사용자 삽입 이미지

Cai

사용자 삽입 이미지

Andrew


하지만 예상했던대로.. 점점 후반부에 갈 수록 내용이 어려워지면서 눈에 초점이 흐려지는 분들이 보이고.. 얼굴엔 어느새 미소는 사라지고 정색이 가득..

다행히 쉬는시간 후에 진행된 두번째 발표를 해준 Tyler의 귀여움(?)에 학생분들의 미소가 다시 돌아왔고 ^^;; 특히 발표후에 각자 실제로 자물쇠를 따보는 실습을 할때에는 다들 왁자지껄 재밌어하시면서 하셔서 아주 좋은 분위기로 마무리 했던것 같습니다 :)  휴 ~

사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지

자물쇠 따기 실습을 어느정도 해본 뒤에 김형종 교수님께서 마무리를 지어주시고 저희 세미나는 끝이 났습니다!


챙겨간것들을 추려서 정리를 한 뒤에, 4명의 서울여대 학생분들과 같이 저녁식사를 하러 과학관을 나섰습니다. 마침 그때가 수업들이 끝날 시간즈음이라 그런지 엄청나게 많은 학생분들이 여러 건물에서 나오고 게시더군요..
순간 저는 천국에 와있는ㅈ... 이 아니고 여대의 분위기란 이런거구나. 라는 생각을 하며 걸어나왔습니다 ^^;
저희가 향한곳은 샤브샤브집! 교수님께서 '법인카드'의 위력을 보여주셔서 덕분에 정말 맛있는 저녁을 먹었습니다.


사용자 삽입 이미지

아무래도 말이 쉽게 통하지 않아서 ㅠㅠ; 다소 어색하긴 했지만ㅎㅎ 나름 이것저것 나눈 대화는 많은것 같아요 :D 바쁘신데 저희 때문에 시간 내주셔서 감사했습니다 _ _)!!

또한, 이런 좋은 기회 허락해주시고 적극적으로 환영해주신 서울여대 김윤정 교수님과 김형종교수님께 다시한번 감사드립니다!


저녁식사가 끝난 후, 저희 팀원들은 제 아버지와 함께 그로서리 쇼핑을 했습니다 ㅋㅋ
Andrew가 한국에 온 두번째 이유인 '소주'를 사기 위해서죠. 홈플러스에 들려서 소주 640ml짜리 10병과, 1.5L 포카리스웨트 8병, 그리고 다른 과자들 몇봉지를 집어들고 호텔로 향했습니다~
(사진을 못찍었네요 ㅠㅠ)


다들 발표준비 및 발표로 많이 피곤했는지 숙소로 돌아와서 씻고 거의 바로 기절모드로 돌입했습니다.
다음 날인 금요일에는 아무래도 마지막 날이라서 그런지 여기저기 돌아다닐 계획을 가지고 일찍부터 나왔습니다.
일단 점심시간을 맞춰서 역삼역으로 향했습니다. 거기서 혜인이를 만나서 점심식사를 했습니다~~
메뉴는 제가 팀원들에게 한국 뜨기전에 먹이겠다고 한 (한국식) 중국음식ㅎㅎㅎ

사용자 삽입 이미지사용자 삽입 이미지

아무래도 점심시간이 그리 길지는 않아서 식사후에 바로 삼성 건물로 와서 1층에 있는 카페에서 마실거리를 마시다가 혜인양을 올려보냈습니당 ㅋㅋ 마실거는 혜인이가 사줬음 ^^v

사용자 삽입 이미지

그리고 나서 저희가 향한곳은 종로~
일단 종로에서 일하고 있는 전 룸메형에게서 뭔가를 받아오기로했으므로.. 찾아갔지만 ㅋㅋ
급한일로 어딜 나가고 같은곳에서 병특하고 있는 ugo [유지오] 군을 오랜만에 만나서 건네 받았습니다.. 꽤 오랫만에 보는건데 엊그제 본거 같고 ㅋㅋㅋ 역시 친한친구는 이런게 좋은듯 ~_~

쨋든, 볼일을 본 뒤에 광화문광장으로 향했습니다.

사용자 삽입 이미지

세종대왕 상

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지

매년 한번 씩은 가보는것 같은데 갈때마다 조금씩 어딘가 모르게 달라지는것 같은 느낌의 광화문 광장입니다~

사용자 삽입 이미지사용자 삽입 이미지

광화문광장을 둘러본 뒤 향한곳은 청계천부근~
아름답게 꾸며놓은 청계천 길 따라서 쭉 걷다가 인사동으로 향하기로 하고 종각역 11번 출구쪽으로 향했습니다.
사람들이 꽤나 붐비던 지하상가를 지나서 11번 출구로 나와서 조금 걸어서 낙원상가를 끼고 돌자 인사동길이 시작되었습니다~

사실 저도 인사동은 한두번밖에 안와밨기 때문에... 딱히 뭘 해야하는지 몰라서 걷고만 있었는데, 마침 '차박물관' 이라는게 있더군요 ㅎㅎ 그래서 오래 걸어서 생긴 피로에서 회복이나 할겸 차를 마시러 들어갔습니다.

사용자 삽입 이미지사용자 삽입 이미지

Tyler는 이슬차를, 저는 감기기운이 조금 있어서 유자차를, Andrew는 대추차(!)를, 그리고 Ricky는 한국식 녹차를 시켰습니다.

사용자 삽입 이미지사용자 삽입 이미지

가래떡 구운것도 팔길래 그것도 한접시 시켜서 먹었습니다. 같이 나온 꿀에 발라먹으니 정말 맛있더군요 +_+

사용자 삽입 이미지사용자 삽입 이미지

대추차가 엄청 진하게 나올 줄 모르고 있다가... 받아보고나서 썩소짓는 앤드류 ㅋㅋㅋ 그리고 리키가 주문한 녹차는 엄청 화려했다는..ㅋㅋ 무려 그릇이 5개.. 그중에서 2개는 맨처음 말고는 쓰지도 않더군요 ㅋㅋ

사용자 삽입 이미지사용자 삽입 이미지

그래도 다들 편안하게 얘기나누면서 각종 차들을 마시며 좋은 시간 보냈습니다 ㅎㅎ
... 그런데 가격이 장난이 아니더군요 ㅋㅋ 4명갔는데 거의 5만원 가까이 나왔습니다...이건 뭐...


차 집을 나와서 다음으로 향한곳은 인사동의 유명한 쌈지길!

사용자 삽입 이미지사용자 삽입 이미지

날씨가 좋아서 그런지 사람들도 많았습니다~

사용자 삽입 이미지

대충 인사동길을 쭉 돌아본 뒤에~ 코드게이트 스태프로 수고해준 민경이와 합류!
같이 서울 N타워로 향했습니다 ㅎㅎ

사용자 삽입 이미지

명동역에서 내려서 조금 걸어서 버스정류장에서 남산타워로 가는 버스를 기다렸습니다~

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지

버스에서 내려서 한컷~


버스에서 내려서 타워까지 헉헉대며 올라가는 길에서 찰칵ㅋㅋ 사진찍는 재미 들린 타일러~

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

엉거주춤한 자세로 나와버렸군요 ㅠㅠ;


직접 타워에 올라가서 서울시를 한눈에 바라보면 더 좋았겠지만 저녁약속이 있어서 오래 있지는 못하고 주변만 둘러보다 내려왔습니다.

사용자 삽입 이미지

서울N타워 옆에 있던 운동시설을 이용중인 동네주민(?) Tyler


저녁에는 저희학교에 방문교수로 와 계신 한양대학교 박용수 교수님의 학생분들과 저녁식사를 했습니다.
신논현역과 강남역 사이에 있는 한정식집에서 먹었는데요- 정말 맛있었습니다 ^^;
또, 끊임없이 나오는 음식에 외국친구들의 감탄도 이어졌습죠~

사용자 삽입 이미지

귀여운척 타일러~ ><

사용자 삽입 이미지

좋은 기회 만들어주신 한양대 분들과 박용수 교수님께 다시한번 감사드립니다!!  _ _)
커리큘럼이나 연구 방향등에 대해서 정말 좋은 얘기들을 많이 나누었고, 한국에서의 대학생활을 해본적이 없는 저로써는 새로운 부분도 있었고 또 공감할 수 있는 부분도 많아서 즐거운 시간이었습니다 :)


이제 비로소 떠나는 날.. 토요일 아침부터 부랴부랴 짐을 싸느라고 정신이 없었습니다.
사실 비행기는 오후 5시였지만, 호텔 체크아웃과 제 아버지와 함께 점심을 먹기로 했던지라 일찍부터 짐을 쌌습니다. 그로서리 쇼핑에서 샀던 소주들부터 시작해서 음료수, 과자, 또 상패, 기념품들.. 하나도 빼놓지 않고 꼬박꼬박 다 챙겨 넣었습니다~

사용자 삽입 이미지

호텔에 머무는 동안 마신 포카리스웨트 -_-;

사용자 삽입 이미지

마저 짐을 싸고 호텔 로비로 나와서 체크아웃을 했습니다~

사용자 삽입 이미지

그리고 나서 아버지와 합류해서 강남역에 있는 보노보노 씨푸드 뷔페에서 점심식사를 했습니다 :)
ㅜㅜ 엄청 그리울거 같아서 마구마구 먹었습니다 ㅋㅋ

사용자 삽입 이미지

점심식사를 마치자마자 바로 인천공항으로 향했습니다.
차안에서 잠이 들어서 공항 도착해서는 어버버 거리면서 정신없이 수속을 마치고..

공항 내부로 들어와서 대기를 타는데, Naver에서 지원하는 인터넷존이라는게 있더군요 ㅎㅎ
죽치고 앉아서 비행기 뜰때까지 빈둥거리다가 탔습니다 =ㅅ=

사용자 삽입 이미지사용자 삽입 이미지

여기까지가 제가 가지고 있는 사진의 전부인것 같네요 ^^;

이후로는 그냥 내리 비행기를 타고 미국으로 다시 돌아온것 이외에는 딱히 특별한 일은 없었습니다..

피츠버그 집에 돌아오니... 이제부터 해야할.. 무지막지하게 쌓인 과제와 프로젝트.. 연구..등등..
눈물이 앞을 가리더군요 흑흑 ㅠㅠ

하지만, 지금이 아니면 기분을 살려서 블로깅을 못할꺼 같아서 더 늦어지기 전에 끄적여봅니다~

작년엔 대회 바로 다음날 돌아와서.. 너무 짧다 싶어서 이번엔 1주일이나 있었는데도 불구하고..
여전히 짧게 느껴지는건 어쩔 수 없네요..

보고싶었던 친구들도, 사람들도 너무 많았지만.. 거의 대부분 보지 못하고 와서 한껏 아쉬움이 남지만..
다음을 기약하며! 꼭 그때는 제가 맛있는걸 사리라 약속하며! 미안해용~

일주일 동안 정말 즐거운 추억을 만들어준 코드게이트 관계자분들, 친구들, 가족들, 팀원들, 등등 정말 모두 너무 감사했습니다! 또 앞으로 어떤 재미난 일들이 앞에서 기다리고 있을지 기대가 됩니다~~


고럼.. 이것으로 코드게이트 2011 결승 진출 겸 한국여행 편을 마치도록 하겠습니당 ㅋㅋ
읽어주셔서 감사해요~



2011/04/12 01:44 2011/04/12 01:44
openclose