0x90

Catching up!

(Cai) — Thu, 16 Feb 2012 23:22:24 -0500

흠.. -_-...

지난번 글에 '곧' 블로깅을 다시 하겠노라 해놓고.. 어느새 5개월이라는 시간이 훌쩍 지나가버렸네요 ^^;;;

사실 중간중간 글을 쓸까하고 왔었는데, 그동안의 공백동안 말린 글들을 다 쓸 생각에 그냥 다시 닫아버리곤 했죠..

근데 아무래도 이렇게 미루고 미루다 보면 그냥 문 닫게 될것 같아서 밀린것들을 하나 하나 쓰는것보다는 한번에 지난 몇 개월동안 있었던 일들과 현재 진행중인 일들을 간략하게 써보려고합니다 ㅎㅎ..

아무래도 방대한 공백을 간략히 메꾸려다보니 디테일들은 떨어지겠지만..

대충 저는 지난 5개월동안 다음과 같이 살았답니다 ㅋ

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

2011년 7월

#1 Macbook Air

일단 가장 큰 소식으로는.. 저에게 맥북 에어 신형이 생겼습니다 ㅋ

아직까지 아주 잘 쓰고 있는 녀석이죠. 한가지 흠(?)이 있다면 SSD용량이 적어서 용량 사용을 신경써가면서 사용해야한다는 점이지만.. 그거빼면 정말 더할나위없이 추천하는 랩탑입니다..

후후.. 제가 꼬득여서 에어를 구매한 사람이 지금까지 약 4명정도 된다는.... ^_^

#2 Mac OS X Lion

Mac OS X Lion도 정품 구매했습니다. 사실 조금 부끄러운 사실이지만 제가 처음으로 돈을 지불하고 구매한 OS입니다.. Lion 나온게 엊그제 같은데 벌써 Mountain Lion (Lion 다음 버전) 소식이 들려오네요 :)

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

2011년 8월

#1 Defcon 19

8월 초에는 데프콘 19 본선이 있었습니다. 18명 남짓되는 PPP 멤버들이 각지에서 (방학/인턴 때문에 뿔뿔이 흩어져 있었다는..) 라스베가스를 향해 출발했죠 :)

defcon hotel keys

hotel room

일단 데프콘 시작날보다 살짝 일찍가서 블랙햇 구경을 잠깐 했습니다 ㅎㅎ

이때 똑똑한 친구들인 Juliano와 Thai가 Padding Oracle Attack으로 server side bug pwnie award를 수상했습니다 ㅎㅎ

사실 CTF를 하느라고 컨퍼런스 토크는 하나도 듣지 못했습니다.. 돈은 돈대로 내고 말이죠 ㅠㅠ

그리고 지난 두 해에 이어 ddtek이 준비한 CTF는 거의 플레이 불가능상태에 가까웠습니다..-_-;

문제 자체들은 90% format string 버그를 이용한 exploit 문제들이었고, 일단 SLA 모니터링 및 점수판이 제대로 작동하지 않아서 대회 자체가 의미가 없었죠.. 정말 화가 나는 일이 아닐 수 없었지만.. 롤러스케이터즈 팀에서 freebsd jailbreak을 통해 재미난 퍼포먼스(?)를 해준 덕에 그나마 해커들 사이에선 재미로 남았지만.. ddtek은 그 일로 인해서 엄청 빡쳤더군요 ㅎㅎ

하여튼 우여곡절이 많은 첫 데프콘 경험이었지만, 딱 봐도 해커들 컨퍼런스라는걸 직감할 수 있었습니다.. -_-;

PPP 단체사진! 왼쪽 아래는 교수님 ㅋㅋ

#2 Apple + Alex (adc)

8월 말에는 Andrew와 함께 캘리포니아에 있는 Apple 에서 일하고 있는 Alex를 만나러 다녀왔습니다.

사실 애플 사 내부는 보안이 좀 격해서(?) 별로 건진건 없구.. 다같이 컴퓨터 역사 박물관을 다녀왔습니다 ㅋ

뿐만아니라 금문교, 바닷가, 맛난 음식, 좋은 사람들.. 아주 재밌고 정신없이 다녀왔습니다 ㅋㅋ

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

2011년 9월

#1 UIUC Friends

UIUC를 다니는 멋쟁이 친구들이 .... 누추한 Pittsburgh에 놀러오셨습니다ㅋㅋㅋ

정말 남자들만 우글우글대는 몇일 밤낮이었지만.. 나름 재밌게 놀다갔......^^;

ㅎㅎ 겨울에 한국에 잠깐 나갔을때도 같이 놀았습죠 ㅋ_ㅋ

방학때 자기네 놀러오라지만.. ㅜㅜ 졸업이 간당간당하므로.... 다음기회에 흑..

(사진이 없네요...)

#2 CSAW 2011 CTF

매년 NYU Poly 에서 주최하는 Cyber Security Awareness Week (CSAW) 이벤트 중 하나인 CTF 예선전을 했습니다. 각 팀별로 4명 제한이 있기 때문에 PPP는 총 4개 팀 (학부팀 3팀, 그외 1팀)으로 나누어서 참여했습니다. 본선 진출은 학부 팀밖에 할 수 없다는 룰 때문에 제가 속한.. (흑흑 이젠 학부생이 아니라니 ㅠㅠ) PPP5가 1등을 했지만 본선진출 자격은 주어지지 않았습니다.

그 이후로 10월달에 열린 본선에서는 본선 진출한 PPP 학부 3팀중 2팀이 각각 1등과 2등을 하여서, 작년에 이어 PPP팀이 1,2위 모두 휩쓰는 기록을 세우고 왔습니다 :)

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

2011년 10월

#1 H.U.S.T. Hacking Festival

이번으로 3년동안 참여한 홍익대학교 보안동아리 해킹대회입니다.

일단 모든 문제들이 한글로 되어있기 때문에 팀원들간에 열심히 구글번역기 돌려가며, 또 제가 번역해주며 문제를 푸는 방식으로 해왔습니다.

사실 저희가 참여했던 첫 회는 정말 재밌게 참여했었고 그렇기에 작년에도 참여한것이었지만..

이번 대회는 해킹대회라기보다는 거의 게싱대회라고 할 정도로 운과 찍는 실력이 해킹 자체 실력보다 더 중요했습니다. 가까스로 우승하긴 했지만, 너무 고생을 했던 탓인지 팀 내부에서 앞으로는 참여하지 말자는쪽으로 기울고 있어서 내년엔 어떻게 될런지 잘 모르겠네요 ^^;

3년 연속 우승을 한 대회라 애정(?)도 가고 대회 운영진분들도 열심히 해주셔서 개인적으로는 좋은 인상을 가지고 있는 대회이지만.. 육체적으로 정신적으로 너무 힘든것 같네요 ㅠㅠ;

#2 SECUINSIDE CTF 예선

긴 말 하지 않겠습니다.. 불미스러운 일로 인해서 본선권에 들어가있던 PPP와 GoN을 비롯한 다수 팀이 경기 종료직전 밀리는 바람에 본선 진출을 사실상 할 수 없게되었었습니다. 운영을 맡은 와우해커측에서 세밀한 검증을 통해 불미스러운 일을 한 팀들에게 제재 및 조치를 취하므로써 GoN과 PPP모두 본선 진출을 할 수 있게 되었습니다.

문제들은 대체적으로 괜찮았고, 마침 HatesIrony팀에 있는 친구들이 피츠버그에 놀러올 일이 있어서 CTF에 대해서 얘기도 같이 하고 즐거운 시간 보냈습니다.

#3 SECUINSIDE CTF 본선

휴.. ㅜㅜ 본선 역시 막판에 가서 불미스러운 일들이 일어나서 엉망이 되었었습니다.

대회 문제들도 재밌었고 문제푸는 동안은 즐거웠는데 말이죠! 아쉬운 점이 많았지만, 본선 역시 운영팀이 세심하고 분주하게 운영해주셔서 공정한 결과를 판가름 해주셨습니다.

본선에 있었던 사건에 대한 제 소견은 여기서 보실 수 있습니다.

결과는 PPP팀 우승입니다 =)

학기중인지라 오래있지 못하고 정말 여행 (비행기) + 대회 시간을 합쳐서 총합 5일 미만으로 다녀왔습니다 -_-...

피곤해 죽는줄 알았다는 ㅋㅋ..

다음은 본선에 대한 뉴스기사입니다: http://biz.heraldm.com/common/Detail.jsp?newsMLId=20111025001010

#4 IDA Pro :)

ㅋㅋ 드디어 IDA 정품 유져가 되었습니다..?

다들 하나씩 장만하시길.. ^_^

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

2011년 11월

#1 ㅋㅋ오랜 베프와의 재회

약 2년정도 연락을 하지 않고 지내던 송현준군과 다시 연락을 하게되었습니다 ㅋㅋ

고등학교 때보다는 각자 인생의 변화가 있어서인지 ㅋㅋ 아주 예전 그대로의 느낌은 아니지만

정말 오랜만에 얘기하는데도 엊그제 얘기하던 친구 같더군요 ~_~

그래서 베프라는거겠죠 ㅋㅋ

#2 IU 신곡 발표!

아이유 신곡 소식이 왜 제 사는 얘기와 관련이 있냐고 물으실 분들도 계실테지만.....

아주..아주.. 밀접한 관계가 있습니다 ... ^_^*

의심할 필요도 없이 당연히 대박이 났죠! 크크

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

2011년 12월

#1 iCTF 2011

매년 UCSB에서 주최하는 iCTF 대회에 참여해서 4위를 했습니다. 리모트 공격/방어 스타일 게임인지라 네트워크 이슈가 조금만 있어도 플레이하기 힘들어지는 단점이 있었지만.. 나름 미국내에선 1위를 굳힌점에 만족하기로 했습니다 ^^; 올해로 3회째 참여중인데, 첫번째로 참여할때도 4등이었지만 다음해에 - 즉, 작년에 - 1등을 했으니.. 내년엔 1등하려는 징조인.......... 은 좀 오바겠죠..

#2 Arc Touch Mouse

Thanksgiving 이후에 가격이 잠시동안 훅 떨어졌던 Arc Touch 마우스를 사기로 마음먹었습니다.

원가보다 약 40% 정도 싸게 샀는데 아직까지 만족하며 사용하고 있습니다. ㅋㅋ

근데 생긴건 특이한데 딱히 뭐 더 좋거나 하진 않아요..

#3 한국!

겨울방학을 맞아 12월 16일부터 1월 10일까지 한국을 다녀왔습니다.

한국에 있는 동안 가족과 시간을 보낼 수 있어서 정말 좋았다는! :)

하지만, 저희집 가족중 막둥이(?) 라고 하기엔 사람나이로 치면 가장 연로하신 핑구 개님이 당뇨와 투병하느라 많이 힘들어하고있습니다 ㅠㅠ 정말 똑똑하고 착하구 기특하구 에너지 넘치는 녀석이었는데 야윈 모습을 보고있느라면 가슴이... 그래도 가족 모두가 열심히 열심히 보살펴주고 있어서 정말 많이 나아졌어요 ㅎㅎ

앞으로도 건강하거라 핑구야 ㅋ

털 때문에 잘 안보이지만 엄청 야위었음 ㅠ

또, 한국에 잠시 있는 동안 많은 국내/외 해커들도 많이 볼 수 있어서 좋았습니다!

다음은 KOSEC 모임 중에서 화난 얼굴로 사진 찍기... 이 날은 호빈이형께서 멋지게 쏘셨습니다 ㅋㅋ

#4 NSHC 세미나 강의

사실 저는 아직 학생이기도 하고 아직 배울것이 많은 사람이지만, NSHC (http://nshc.net) 의 허영일 대표님께서 직접 연락을 주셔서 회사 내부 세미나 강의를 하실 기회를 주셨습니다.

10명이 넘는 보안직 종사분들을 상대로 시스템 해킹 강의를 하려니 솔직히 부담이 많이 되었지만 ㅠㅠ

나름 열심히 준비해서 하게 되었습니다.

많은 분들이 강의 후에 (아마도.. 예의상 ^_^;;) 좋았다고, 많이 배우셨다고 말씀해주셔서 감사했구 자신감도 생겼답니다. 좋은 경험 허락해주신 허영일 대표님과 NSHC 분들께 다시한번 감사드립니다~

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

2012년 1월

#1 상길이형 축결혼!

PPP 창단 멤버이시자, 저희 그룹의 에이스이신 상길이형이 이번 1월 초에 결혼을 하셨습니다 ㅎㅎ

워낙 바쁘신 몸이라.. 한국에 2주 정도 계시는 동안 결혼식을 하시느라 정신이 없으셨을듯 -_-;

...동영상 캡쳐한건데 잘 안보이네요 ㅠ

마침 한국에 있던 상재와 제가 결혼식에 참여했습니다! 연구실에서와는 사뭇 다른 모습의 상길이형 ㅋㅋ

멋있었어요~ 결혼 축하드립니다~~

#2 Kaprica Security

저를 비롯한 PPP 멤버 몇 명과 Lockheed Martin에 있던 몇 명이 같이 시작한 사업입니다.

일단 지금 초점은 Mobile Security이고, 저희가 만들고 있는것에 대한 간략한 설명은 이 동영상을 보시면 됩니다. (ㅋㅋㅋ 칠판에 그림.. 제가 그렸다는 ^^;;)

아마 졸업하고 나서 친구들과 같이 계속 이 회사를 키워나갈 것 같습니다.

잘 되든 안되든, 이런 경험은 젊을때 아니면 해볼 수 없다는 생각에 리스크를 감수하고 도전해봅니다 :)

#3 Mozilla CTF

모질라 그룹에서 처음으로 주최한 CTF 대회입니다. 거의 모든 문제가 웹 문제여서 시스템 해킹에 굶주린 저희 팀은 아쉬웠지만, 나름 재밌는 대회였습니다. 일단 24시간으로 짧은 대회여서 후폭풍이 덜해서 다행이었다는.. -_-ㅋ

결과는 3등.

#4 Shmoocon + Ghost in the Shellcode (GitS)

크.. 그 구하기 힘들다는 shmoocon 티켓을 여러장 구한 팀원에게 받아서 올해 shmoocon에 다녀왔습니다.

하지만 역시 대회가 병행되고있었으므로 ㅜㅜ 맘 편히 토크만 볼 수는 없었고 Ghost in the Shellcode라는 HatesIrony팀이 운영하는 대회에 참여했습니다.

2일 반동안 빡시게 대회를 한 결과 PPP가 우승하였습니다 :)

상품은 저 위에 걸려있는 배너와 실제 포노폴리(pwnapoly)판과 프로그래밍이 가능한 보드카/병 이었습니다 ㅋㅋ

(잘 보시면 저희가 다시 프로그래밍해서 PPP 가 나오도록 바꿔놨습니다ㅎㅎ)

그리고 정말 마음에 드는 티셔츠가 있어서 하나 샀습니다 ㅋㅋ 이해하실분은 이해하실만한..

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

휴.. 정말 길었지만 ^^; 요렇게 살아왔답니다... 한동안..

이젠 정말 4월말까지 논문도 내야되고.. 그러려면 제대로 된 연구를 해야되서..

졸업 전까지는 블로깅을 제대로 못하지 싶습니다..

졸업하고나면 좀 더 양질의 내용으로 블로깅을 하도록 하겠습니다 ㅋㅋ

제가 몇달동안 업데이트를 안해도 꾸준히 방문해주시고 연락주셨던 분들! 정말 감사합니다~~

그럼 5월달에 보아요!!!!

블로그 글..

(Cai) — Mon, 26 Sep 2011 15:09:28 -0400

안녕하세요~

요즘 너무 시간이 없어서 블로그에 접속을 안해본지도 몇주가 지났네요 ^^;

시간이 조금 나면 다시 돌아오도록 하겠습니다..그때까지는.....안녕..?!

ㅋㅋㅋ 몇일 이내로 새 글 포스팅 하겠습니당..ㅎㅎ

Google Music Beta!

(Cai) — Mon, 18 Jul 2011 21:44:00 -0400

Google 에서 인턴을 하고 있는 친구가 music beta 초창기에 초대장을 나눠줘서 일단 가입은 해놨었습니다.

가입한지 한 3주정도 만에 처음 써보기 시작했는데요.. 첫 느낌은 '예상대로' 라는 느낌이었습니다.

일단 전체적인 느낌은 다음과 같습니다:

왼편으로는 My Library 라는 메뉴 아래로 'New and recent', 'Songs', 'Artists', 'Albums', 'Genres' 별로 나누어서 정렬할 수 있도록 되어있고, 그 아래로는 Auto playlist 메뉴들이 있습니다.

Instant Mixes 기능은 써본적은 없지만 설명상으로는 곡을 하나 선택하고 믹스 버튼을 누르면 25곡의 믹스 리스트를 만들어주는것 같군요.

마지막으로 Playlists에는 아이튠즈에도 있는 플레이리스트들을 추가/삭제 할 수 있습니다.

자신이 듣고싶은 음악을 구매하거나 또는 자기 컴퓨터에서 직접 업로드해놓고 인터넷이 되는 곳이라면 어디서든지 음악을 들을 수 있도록 되어있습니다.

한가지 아쉬운점은.. 업로드하는 도중에 인코딩변환에 좀 문제가 있는지 한글로 된 제목/앨범/아티스트 이름들이 깨지는게 종종 생기더군요.. 그리고 또 업로드 하기 위해서는 전용 업로더를 설치해야되는 번거로움이 있습니다.

하지만 한번 올려놓고 나면 걱정할필요없이 어디서든지 들을 수 있다는게 장점입니다.

현재 Android 애플리케이션으로도 나와서 폰에서도 바로 들을 수 있게되어있나봅니다...전 아이폰유져라..후

뭐 구글이 하는거에 비해서 엄청 눈에 띄는 기능은 없는것 같습니다. 그냥 클라우드 뮤직 스트리밍 정도로 보시면 되겠네요.

재생 화면 (중복음악은 제가 실수로 똑같은걸 업로드해서 -_-;)

지금보니 초대장이 ~~2개가 생겼네요 ㅎㅎ~~ 0개 남았습니다.. 다시 생기면 말씀드릴게요 ^^;

~~필요하신 분 있으시면 댓글로 이메일주소 남겨주시면 보내드릴게요 :)~~

~~[정말 필요하신분/쓰실분만 남겨주세요 ^^;]~~

다시 초대장이 2개 생겼습니다.

필요하신 분 이메일 남겨주세요 ^^

[KakaoTalk] JSON Objects (5)

(Cai) — Wed, 13 Jul 2011 23:34:00 -0400

에.. 이번 글에서는 카카오톡 클라이언트와 서버 사이에서 어떤 데이터가 오고가는지 짧게 적어보려 합니다.

다른 플랫폼으로 (windows phone, pc, 등등) 포팅하실분들에게 약간이나마 도움이 될지도 모르겠네요.

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

일단 제 프로그램에서는 세션키 인증이 끝나면 바로 친구 리스트를 불러옵니다.

친구리스트는 다음 URL에 리퀘스트를 보내면 받을 수 있습니다:

https://ch-talk.kakao.com/iphone/chats/list.json

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

view [FriendsListJSON.cs]

/**********************/
/* FriendsListJSON.cs */
/**********************/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace KakaoTalkPC
{
    class FriendsListJSON
    {
        public FriendsListJSON() { friends = new List<Friend>(); }
        public int status { get; set; }
        public int total { get; set; }
        public List<Friend> friends { get; set; }
    }
}

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

각각의 Friend 객체는 다음과 같은 구조를 가지고 있습니다.

필드설명:

- type: 현재 친구와의 관계 (1 == 이미 친구, -4 == 친구 아님)

- directChatId: 직접 채팅(방) 아이디

- userId: 유져 고유번호

- nickName: 친구 이름 (상대방이 자신의 닉네임으로 설정한 것)

- phoneNumber: 폰 번호 (폰 번호가 저장되어있다면.. 아이디로만 저장되있으면 폰 번호 없음)

- profileImageUrl: 작은 프로필 사진 주소

- statusMessage: 이름 옆에 뜨는 '오늘의 메세지'

- friendNickName: 자신이 설정한 친구의 닉네임

- UUID: 아이디 (친구 검색할때 쓰는 아이디)

- fullProfileImageUrl: 원본 프로필 사진 주소

view [Friend.cs]

/*************/
/* Friend.cs */
/*************/

using System;
using System.Collections.Generic;
using System.Text;

namespace KakaoTalkPC
{

    public class Friend
    {
        public Friend() { }
        public int type { get; set; }
        public Int64 directChatId { get; set; }
        public int userId { get; set; }
        public string nickName { get; set; }
        public string phoneNumber { get; set; }
        public string profileImageUrl { get; set; }
        public string statusMessage { get; set; }
        public string friendNickName { get; set; }
        public string UUID { get; set; }
        public string fullProfileImageUrl { get; set; }

        public override string ToString()
        {
            return this.nickName;
        }
    }
}

이제 친구 찾기에 대해서 알아봅시다~

친구찾기는 다음 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]

/***************************/
/* FindFriendByUUIDJSON.cs */
/***************************/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace KakaoTalkPC
{
    public class Member
    {
        public int type { get; set; }
        public Int64 directChatId { get; set; }
        public int userId { get; set; }
        public string nickName { get; set; }
        public string phoneNumber { get; set; }
        public string profileImageUrl { get; set; }
        public string statusMessage { get; set; }
        public string UUID { get; set; }
        public string fullProfileImageUrl { get; set; }
    }
    public class FindFriendByUUIDJSON
    {
        public int status { get; set; }
        public Member member { get; set; }
    }
}

친구 추가를 할 때는, 다음 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]

/*****************/
/* FriendJSON.cs */
/*****************/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace KakaoTalkPC
{
    public class FriendJSON
    {
        public int status { get; set; }
        public Friend friend;
    }

    public class FriendIdsJSON
    {
        public int status { get; set; }
        public Int64[] friendIds { get; set; }
    }
}

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

이제 마지막으로 채팅에 관련된 극히 일부분을 보도록 하죠 ㅎㅎ

최근에 시간이 없어서 (제일 중요한 ^^;) 채팅쪽을 많이 못봤습니다.. 베타버전에서 이미지 전송까지 해놓으려고했는데 다음..(기약없음..ㅋㅋ)으로 미뤄야하겠네요.

일단 다음은 채팅방 리스트를 불러오는 url 입니다:

https://ch-talk.kakao.com/iphone/chats/list.json

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

view [ChatListJSON.cs]

/*******************/
/* ChatListJSON.cs */
/*******************/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace KakaoTalkPC
{
    class ChatListJSON
    {
        public ChatListJSON() { chatRooms = new List<ChatRoom>(); }
        public int status { get; set; }
        public List<ChatRoom> chatRooms { get; set; }
        public int total { get; set; }
    }
}

실질적으로 채팅이 이루어지는 부분을 보도록 하죠.

사실 카카오톡에서는 '채팅'의 개념보다는 '비동기식 메세지 교환' 이라고 보는게 나을지도 모르겠네요.

한쪽에서 메세지를 보내면, 이 메세지는 카카오톡 서버에 저장되어있다가 다른쪽 유져가 '나 메세지 받은거 있니?' 라고 물어보면 서버가 받아두었던 메세지를 전달해주는 방식입니다. 물론, 그 시점에서 서버단에서 그 메세지가 삭제가 되는지 저장이 되는지는 (^^;) 저로써는 알 방법이 없지만, 카카오톡 구조상 무조건 서버에 한번은 저장되어야 합니다.

그리고 또 한가지 재밌는것은, 카카오톡은 이미 처음부터 그룹채팅을 디자인으로 개발되었던것 같습니다.

그래서, 모든것이 다수가 참여할 수 있는 '채팅방'의 구조로 되어있고 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]

/*******************/
/* ChatRoomJSON.cs */
/*******************/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace KakaoTalkPC
{
    public class ChatRoom
    {
        public ChatRoom() { members = new List<Member>(); }
        public string type { get; set; }
        public int[] activeMemberIds { get; set; }
        public string lastMessage { get; set; }
        public bool pushAlert { get; set; }
        public int activeMembersCount { get; set; }
        public List<Member> members { get; set; }
        public Int64[] watermarks { get; set; }
        public int lastUpdatedAt { get; set; }
        public Int64 lastLogId { get; set; }
        public int newMessageCount { get; set; }
        public Int64 chatId { get; set; }
    }

    public class ChatLog
    {
        public int type { get; set; }
        public Int64 logId { get; set; }
        public string message { get; set; }
        public int sendAt { get; set; }
        public Int64 chatId { get; set; }
    }

    public class ChatRoomJSON
    {
        public ChatRoomJSON() { chatLogs = new List<ChatLog>(); }
        public int status { get; set; }
        public ChatRoom chatRoom { get; set; }
        public List<ChatLog> chatLogs { get; set; }
    }
}

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

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

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

대충 이정도가 제가 알고있는 자료구조입니다. 사실 자료구조라고 하기에도 좀 난감한 'JSON parsing' 입니다.

리퀘스트해서 돌아오는 리스폰스를 파싱해서 그 데이터를 알맞게 잘 쓰면 카카오톡 포팅이 가능한거죠.

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

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

[KakaoTalk] KakaoTalk PC Prototype (4)

(Cai) — Sun, 26 Jun 2011 14:07:17 -0400

카카오톡 관련 포스팅을 영어로 하는데에 대한 불만들이 많으셔서 ㅋㅋ..

이번 포스팅은 한국어로 하도록 하겠습니다~ :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 으로 이메일주시면 되겠습니다.

좋은 하루 되시길...

Another Pirates game w/ TIW

(Cai) — Sat, 25 Jun 2011 04:05:16 -0400

지난 일요일부터 목요일까지 CMU에서 Trusted Infrastructure Workshop (TIW) 이 있었고, 수요일부터 금요일까지는 TRUST 라는 conference가 열렸습니다.

TIW가 있기 약 2주 반전쯤에 관계자 중 한 분이 연락을 하셨습니다. 워크샵이 진행되는 동안, 이벤트 식으로 CTF를 진행하고 싶은데 도와달라는 요청이었습니다. 마침 저희 팀이 약 두 달전쯤에 Plaid CTF를 개최하면서 많은 준비를 했었고 경험이 있었던지라, 일단은 승낙을 했습니다.

하지만 문제는 시간이었습니다. 약 2주정도의 시간동안 게임보드 (저희때와는 다른 구조였기때문에)와 문제들을 출제하기가 여간 까다롭지 않았죠 ㅠ_ㅠ 다행히 참가자들의 대부분이 CTF 경험이 아예 없거나 많지 않다는 말을 듣고 어려운 문제를 출제해야한다는 부담감에서는 좀 벗어났습니다만..

여차저차해서 서버셋팅부터 시작해서 작업에 들어갔습니다. 여름 방학인지라 많은 사람들이 참여는 못하고 약 4명정도가 각자 문제들을 만들고.. 아무래도 연구실에 있으면서 연구를 안하면 눈치가 보이기때문에 ㅠㅠ 간간히 연구도하면서... 겨우 데드라인 전날 밤에 모든걸 끝냈습니다 :)

많은 분들이 익숙하실 일명 '데프콘스타일'의 게임보드로 진행되었습니다.

회색-잠김, 파랑-풀림, 초록-내가품, 금색-열렸지만아무도안품, 보라색-스페셜

아무래도 이번 CTF의 취지는 배움을 목적으로 한 대회였기 때문에 평소 CTF에서 보지 못하는 Essay형태의 스페셜 문제들도 출제되었습니다. 물론 이건 철저히 워크샵 운영진들의 의견이 반영된것이라.. 주관적인 평가에 의한 스코어링을 사람들이 어떻게 생각했는지는 잘 모르겠네요. 그래도 꽤 질 좋은 글들이 많이 나왔다고 한것 같습니다. (전 귀찮아서 안읽어봤음)

어쨋든 이놈의 대회는 4일에 걸쳐서 계속 진행되었습니다. -_-; 낮에는 워크샵 및 프레젠테이션, 밤에는 CTF.. 라곤 하지만 다들 아시다시피 요런거 하나 시작하면 워크샵이고 뭐고 ㅋㅋ 다들 문제 푸느라 정신없죠.. 아마 그래서 내년엔 워크샵이 다 끝나면 밤에만 개방하기로 할듯 싶네요 ㅋㅋ

음음.. 이 많은 일을 공짜로 할 수는 없으니.. 여기저기 많이 쫓아다니며 밥과 소셜 이벤트등을 다녔습니다 ㅎㅎ

덕분에 큰 회사 사람들과도 많은 대화를 나눴고, 학교에서 권력짱 교수님들과도 친분을 쌓았다는..ㅋㅋㅋ

또, 특히 이번에 한국에서 오신 카이스트, 고려대 (이희조 교수님 연구실) 대학원 학생분들을 뵐 수 있었는데요~

같이 야구도 보러가고 ㅋㅋ 짧았지만 재밌는 시간 보냈습니다 :p

사실 저번에 갔을때는 $10짜리 티켓이라 자리가 그저 그랬는데... 역시 비싼 자리는 다르더군요~~

고대 3인방~~ 핫도그와 치킨핑거 ㅋㄷ

제가 있던곳은 내부 건물과도 연결이 되어있었는데 음식파는데도 있고 당구치는데도 있고..

잘되어있더군요 ㅋㅋ 그래서 그냥 한컷.. (근데 지금보니까 빨간티셔츠 아저씨가 압권이네영..)

아참! 저번에 갔을때는 모자와 수건을 공짜로 주더니..

이번엔 컵을 주더군요 ㅎㅎ 1971년 월드 시리즈 우승팀에 있던 선수들이 와서 오프닝을 열어줬습니다 ㅋㅋ

밤까지 야구는 계속~~

9이닝 시작할때쯤 버스로 돌아와야해서 경기를 마져보진 못했지만.. 꽤 빨리 끝났나봅니다 ㅋㅋ

내려와서 버스 탈때쯤 되니까 환호성 들리더니 사람들이 물밀듯 나오더군요..

제가 나올때만 해도 Pirates가 이기고 있었으니.. 그사이에 지진 않았겠죠? ㅋㅋ 아마 이긴듯 싶습니다.

하루종일 힘들어서 다들 집에 돌아가자마자 떡실신~ 그래도 재밌는 하루였어요 :)

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

수요일 저녁에는 Pittsburgh Athletics Association (이런곳이 있는줄도 몰랐음..)에서 저녁식사가 있었는데..

완전 맛있었습니다 ㅋㅋ 스테이끼좀 썰어주고..[근데 이건 나오자마자 쳐묵쳐묵 하는지라 사진을 못찍었음..]

후식엔 치즈케익 한조각과 브라우니 한조각 + 과일..덩어리(?). 치즈케익부터 먹었는데, 나중에 브라우니는 너무 달아서 못먹겠더군요 ㅠㅠ;

여하튼 배불리 먹고 집에와서.. 딩가딩가...는 못하고 대회운영 막바지..ㅋㅋ

그리고 뭐 마지막날인 다음날 아침엔 경기 종료시키고 시상식 하고 ~ 문제 풀이 해주고..등등

정신없이 흘러갔네요 한 주가.. 이제 정말 데프콘 전까지는 연구에 충실해야할듯 싶습니다!!

(..라곤 하지만 이미 그 전에 다른 대회 참가 계획만 두 개..)

[KakaoTalk] Session Key (3)

(Cai) — Thu, 23 Jun 2011 21:42:00 -0400

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.

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
Server responds with the one-time 'token' in json format
- Meanwhile, the server also sends actual SMS message (which contains passcode) to the number.
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.
Server responds with status code '11' and a new token is returned when successful.
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
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.
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).
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!

[KakaoTalk] Bypassing SSL (2)

(Cai) — Wed, 22 Jun 2011 21:35:15 -0400

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:

It's going to drain the battery way faster. Crypto is not cheap, especially in embedded devices like mobile phones.
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!

[KakaoTalk] Preliminary Research / Analysis (1)

(Cai) — Sun, 19 Jun 2011 23:04:27 -0400

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:

Get (part of) code flow in iOS applications using debugger.
Re-label the obfuscated java files to understand the program logic.
~~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!

PPP is going to DefCon19 Final!

(Cai) — Wed, 15 Jun 2011 04:18:00 -0400

네! 그렇습니다~

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

뭐.. 사실 본선 진출은 예선관련 발표날인 4월 1일부터 알고 있었던 사실이긴 합니다..

올해에는 본선진출 룰을 약간 변경하여 작년 데프콘 우승팀, iCTF (UCSB 주최) 우승팀 그리고 Codegate 우승팀을 포함한, 총 12팀이 출전하게 되었는데요.

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

하지만! 거기서 멈출 수 없다는 생각에 예선전도 참가해서 본선진출을 함으로써,

데프콘 역사사 처음으로 triple-qualify 를 성공하게 되었습니다 ~~ 짝짝짝~

(올해 데프콘 우승을 하면 내년에 quadruple-qualify 도 노려볼만 할듯..ㅋㅋㅋㅋ)

여하튼.

그래서 올해 8월초에 PPP 멤버 *다수*가 본선경기를 하기 위해서 라스베가스로 가게 됩니다.

항상 팀원제한이 있어서 열심히 예선 같이해주고 본선은 같이 못간 멤버들도 이번만큼은 거의다 같이갈 수 있게되서 다행입니다.. 아무래도 너무 많이 데려갈 수는 없으니.. 몇명 못오는 사태가 발생하긴 했지만 말이죠 ㅠㅠ;

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

베가스에서 뵙죠!