[KakaoTalk] Preliminary Research / Analysis (1)

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.

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.