Faking the Green Robot – Part 2

It has been long time since Part 1, but I’ve been busy with other stuff. In the previous part, I started analyzing how “Green Robot” feature can be faked, or more precisely, how Android is identified by google talk servers. Last thing I found out was that Android’s talk application securely connects to gtalk servers. I performed SSL man in the middle attack as described in this post. I couldn’t find weakness in Android’s SSL implementation, so I had to modify it to accept my fake certificate. How did I do that ?

My first guess was to change something inside Talk.apk or gtalkservice.apk to either disable the check, or get it’s private key. If you are a software developer you’d probably think I must have the original source files for that, but the truth is I don’t. Quick inspection of “apk” files showed that it’s actually gzip archive, that contains some xml files and the executable binary, “dex” file. Another format I’ve never heard of. What I wanted to do next is something called disassembly process. It means turning binary machine code into something more readable by humans.

Unfortunately, my favorite disassembler doesn’t understand dex files, so I googled for help and found two candidates: “dedexer” and “dex2jar“. The first decompiles into “assembly like format” while the second converts to Java jar, which can be later disassembled into java source files. So, dex2jar was an obvious pick. I then disassembled the jar file with JAD (JAva Decompiler). Although, it wasn’t fully disassembled, it was enough to get around.

After brief inspection of “gtalkservice” and “Talk”, I realized the SSL authentication mechanism is not implemented by neither of them, it’s implemented by Android operating system. So, there must be a place that holds the trusted certificates. I only need to find it and add my fake certificate (served by the man in the middle server). I scanned the operating system files for suspicious files (remember ? we extracted system.img with unyaffs so we have access to these files). Umm… I wonder what /etc/security/cacerts.bks is used for… what are the odds it holds all trusted Certificate Authorities Certificates ?

To modify this file we need some sort of editor for bks files. Portecle would be good choice. The bks file is password protected but the password can be obtained here, along with instructions how to extract it from live android operating system, modify it, and push it back to android. None of the instructions worked for me, but the password was correct. Portecle’s usage as well as cacerts.bks file structure is pretty intuitive.

Once cacerts.bks contains our new certificate we need to push it back into the system.img file the emulator use. I thought it’s trivial task but it took me much more time than I expected, much more than actually needed. If you follow google results, you would either try to push the file into live android system with “adb push”, but it doesn’t survive reboot (and you must reboot if you want the new file to be used) or you follow one of the many different forums posts about kernel recompiling, using mtd pseudo devices, etc…

All you really need to do is download YAFFS2 source, go to “utils” directory, and run “make”. When compilation is done, you’ll get utility called “mkyaffs2image” which is exactly what we need. It converts a directory (with it’s files and subdirectories) into YAFFS2 image. We just need to rebuild YAFFS2 image from the extracted system.img direcrtory (with modified cacerts.bks file in it). After it’s done, rename output file to system.img and boot the emulator with it. It works seamlessly.

So now I got all communications decrypted with wireshark. I expected to find google talk’s offical protocol, XMPP, as specified here but I didn’t. What I got seemed like some sort of object serialization. Some of the strings looked familiar from XMPP protocol, some were not. I checked gtalkservice sources again, to understand the serialization process. I couldn’t figure it out completely but I got some ideas, such as the first byte of packet represents it’s type as defined in MobileProtoBufStreamConfiguration.java, the second byte is how many bytes left in the packet, string always follows it’s length (in hexadecimal), etc…

I figured out enough to come to these conclusion: port 5228 is not only used for google talk. It’s for other google services as well. The protocol is some “private” extension of XMPP or pure XML, as the smack sources (from gtalkservice) were clearly modified to handle login requests. All objects are serialized. I suspect the android identification is based on the login request ( <login-request … deviceId= …> ).

Therefor, my plan for extending existing gtalk client with some additional XMPP tags won’t work, because the whole login procedure is apparently different. That’s the end of this adventure for me. Of course, I might be wrong or completely missing something, but for what it worths, it was fun and I got quite far, didn’t I ?

However, this is the end only for me. For you, there still might be a chance. If I got it right, when client receives “presence” messages, which are part of the XMPP (those are the messages sent to notify someone became online for example), one of the fields is client type, as specified in PresenceStanza.java. Although it interprets only received messages (again, if I got it right), the XMPP protocol also defines how to send presence messages to the server. Maybe this type of messages can be used to trick the server…

Faking the Green Robot – Part 1

On last November, Google Labs released cool feature, called “Green robot icon”. If enabled, it turns the bubbles next to your chat buddies in Google Talk, into cute android robots, for buddies connected via android device. It might not be the best thing for android users’ privacy, but other than that I think it’s pretty cool, and I want this icon too!

The only problem, I don’t own android enabled phone, and even if I did, I want that icon appearing even when I’m not connected through it. You might find it really unnecessary, specially because “green robot” feature is disabled by default and considering all the trouble I went through, but it’s really not about the icon. The icon is nice benefit but it’s about the challenge, the educational experience and the adventure. Sometimes I challenge myself with that kind of things, just to prove it’s doable and I can do it. Before I began, I had no idea how long would it take, whether it’s possible or not and if I have the necessary tools/knowledge, but that’s part of the idea, study new things along the adventure.

Where do we start ? we need to be able to determine success, meaning sign-in to gmail as one of our chat buddies, enable green robot feature and check if we appear as cute android. It’s somewhat problematic to sign in with two different accounts using the same browser. There are many workarounds, like simply using different browsers, or different computers (could be virtual as well). I used another computer, making my testing environment as neutral as possible.

In order to win our green robot, we must make Google Talk believe we are connected through android, and for that purpose we need to understand how it identifies android users. Having no prior knowledge of how android users connect to Google Talk, I made an educated guess based on my knowledge of how websites identify clients: according to the browser. The HTTP defines, among the rest, how web browser identifies itself to web server. It’s done via HTTP header called “user-agent”. You can check your own user agent here. It’s very common for websites to serve device dependent content based on user-agent, for example, if you browse this blog from iphone, the same page would appear differently, optimized to iphone.

After setting up test environment, we need to change our browser user-agent string to android’s user-agent string. In Firefox, it can be achieved with add-on called User Agent Switcher. All we need to do is to enter android’s user-agent string (can easily be found on google) and browse to gmail -> talk. Not surprisingly, I got mobile web version of Google Talk (“talk gadget”) and I was able to chat but it didn’t change my icon.

So, my educated guess wasn’t good. Google Talk doesn’t identify android users by user-agent string, at least not alone. What’s next ? Observation. If only we had android phone and a way to observe what’s going inside, we could solve this… is it the end of our little adventure ? not quite yet. You see, Google is awesome. They made android emulator for developers, and it even works on Linux out of the box. It’s time to get the emulator (Android SDK), and start getting dirty.

After some playing, I figured out how to work with it and I started the emulation. It takes a minute or two until it’s fully loaded. The first time I got it working I was thinking “this android looks pretty cool” but I soon found out that looking cool alone won’t get me anywhere. Using android’s browser didn’t change the icon, and I had no Google Talk application installed. So I made a little research. We can install android apps (.apk files) with “adb” command that comes with the SDK, and it seems that we need to get “gtalkservice.apk” and “Talk.apk”. I couldn’t find download links to those files but I found a download link to HTC’s android system image file, and supposedly it comes with these apps. So I downloaded it, and examined the file.

“VMS Alpha executable” announced the “file” command I ran. What?! I expected it to be either FAT/EXT/ISO9660 or DOS image variant. I tried to mount the file but as you probably guessed, it failed: “you must specify the filesystem type”. Yes, if only I knew… I googled a little more and found that it’s Cramfs. I tried using “fusecram” to mount the image file but it didn’t work either. So I read a little more and find out that it’s actually not Cramfs, but YAFFS2. I don’t know what about you, but it’s way too many filesystems I’ve never heard about for one day. Anyway, in order to support YAFFS mounting, it seemed that I must recompile my kernel, and I wasn’t really in the mood so I found another utility called unyaffs, that can extract files from YAFFS images. Using unyaffs, I finally got “gtalkservice.apk” and “Talk.apk”. When I tried to install them, I got this error: “Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]”. This message led me to dead end (google-wise).

My next thought was resolving the missing library failure by copying the library from extracted files to the emulator, and then I realized, I already got a system image file with everything I need installed! All I need to do is to boot the emulator with this system image instead of it’s default development system image. So I did and it worked (almost) out of the box. I only had to add  “GSM modem support” to enable networking. So mission accomplished. I managed to connect to Google Talk from within the emulator and my icon changed to cute green robot.

But honestly, that’s not how I wanted it. It’s not very different from having an android device and just using it with Google Talk. I want to understand what is it exactly that identifies it as android platform. So I turned to my old friend wireshark (ethereal) to snoop around the network. Here are my conclusions: the “google talk” app first queries the DNS for “mtalk.google.com”. After it gets respond, it establishes TLS (SSL) connection on destination port 5228. Since it’s non-standard port for SSL, wireshark didn’t automatically decoded the messages correctly, but once I chose “Analyze -> Decode As… -> SSL” I could clearly see the protocol in action. Unfortunately, the protocol purpose is to encrypt application data, meaning, I couldn’t see the data in the messages, I could only see messages, with data I can’t understand.

I was actually quite impressed. It takes relatively a lot of computing resources (=money) on behalf of Google to establish secure connection for each user that signs into chat. It serves only one purpose: protecting user’s privacy, and lets not forget it’s a non-paid service. Way to go Google!

At this point, some people would have stopped. I didn’t. I knew there must be a way in, and if it exists I can find it. Did I succeed ? read on part 2.