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.

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.

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!

 

We start listening on pdp_ip0 device:

 Once we do some activities in KakaoTalk, we can see the packets are dumped to the file.

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.

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!