This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Is YMSG for Android Encrypted?

0

I've been able to find YMSG packets from all devices on our subnet that use Yahoo IM, except for Android tablets. I have verified this by using the MAC of one of the tablets as a capture filter, verifying that Wireshark is capturing packets, then applying the YMSG display filter during a chat session initiated by me. No packets make it through the filter! I'm wondering if anyone else has seen this, and if there is any way around the problem.

asked 07 Nov '13, 15:50

crashtech66's gravatar image

crashtech66
11114
accept rate: 0%


One Answer:

1

From what I was able to find with google, only the authentication part is encrypted. So, you should be able to capture and analyze messages sent from your android tablet, if you've done the capturing in the right way, meaning you captured the whole traffic of the tablet with a system running Wireshark.

Regards
Kurt

answered 11 Nov '13, 08:02

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Oddly enough, I pressed a second tablet (well, a rooted nook color) into service, and I AM able to see ymsg packets coming from it, but NOT using "ymsg" as a display filter, but rather a text search for the string "yahoo." Something is definitely different about the Yahoo Messenger packets between PC/laptop and android, but I don't have the mojo to explain what, yet. Any more help would be much appreciated!

(11 Nov '13, 08:43) crashtech66
1

The YMSG dissector does not register for a certain TCP port. So, if Wireshark does not detect that traffic as YMSG, there are three things that could have happened

  • the traffic is encrypted
  • the tablet uses a new/modified YMSG protocol, and thus Wireshark is unable to detect/dissect it
  • you believe to have captured the traffic, but you did not

If you can post a capture file somewhere (google drive, dropbox, mega.co.nz, cloudshark.org), we might be able to figure out what's going on.

(12 Nov '13, 04:17) Kurt Knochner ♦

I'm going to attempt that as soon as possible, thanks!

(13 Nov '13, 08:25) crashtech66

It's very difficult for me to capture data in which I know a chat session is present! I was certain some data was captured which contained ymsg packets, yet after doing whois on all the IPs contained within the data, none have any reference to Yahoo, save for a scant 2 from akamai, which I don't believe relate. Something must be wrong with my capture regimen, OR, somehow ymsg traffic is being encrypted and run through Google's servers somehow? Seems farfetched. I'm gonna try and gain control of the tablet and "chat" with it from a remotely controlled machine on a different network while capturing the data. It's the only way to know for sure the chat data is there.

(20 Nov '13, 08:11) crashtech66
1

I would test it myself, but Yahoo? needs a mobile number for the registration process.

My response to that: WTF! In that case I don't need that shabby Yahoo? account ;-)

However: If you can provide a capture file I will look at it.

(20 Nov '13, 08:18) Kurt Knochner ♦

OK, here's a link to a capture in which I have logged in for a brief test chat with a remotely controlled machine:

http://cloudshark.org/captures/9869476e1200

I hope you can make some sense of it!

BTW, part of my problem was that the WAP was in the wrong spot on the LAN... Correcting the topology improved results, but still I find no way to extract message bodies...

(24 Nov '13, 10:06) crashtech66
1

There are some HTTP POST messages to Yahoo? servers, however not enough for a full chat. If some of your chat messages contained the following words

Testing testifies testicles testosterone

You will find (part of) the chat conversation by using this filter:

http.request.method eq POST and json.value.string

Then see frame 2402.

However if that does not belong to your Yahoo chat, the chat is probably encrypted (there are some https connections to yahoo servers). In that case case, you won't be able to decrypt the communication.

You could then use a decrypting proxy like Fiddler2 (http://http://fiddler2.com/ ) to intercept and decrypt the traffic.

(24 Nov '13, 10:40) Kurt Knochner ♦

That's it, thanks! You've used a display filter I knew nothing of. So odd to me that the normal ymsg filter doesn't work, I wonder why that is?

(24 Nov '13, 18:45) crashtech66
1

So odd to me that the normal ymsg filter doesn't work, I wonder why that is?

Because the Android app uses HTTP POST requests with JSON instead of the YMSG protocol. Why they did that? I can't answer. Please ask the developer of that app ;-))

Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions. For extra points you can up vote the answer (thumb up).

(25 Nov '13, 03:56) Kurt Knochner ♦

I've been seeing only half of the conversations using the capture filter:

ether host 5c:ff:35:28:aa:0a or ether host 6c:b7:f4:fa:49:f9 and not host 217.212.243.27

And the display filter:

http.request.method eq POST and json.value.string

I thought that the "ether host" filter would capture all traffic to AND from, but something is causing the remote half of the conversation to be omitted or filtered out. Any thoughts?

(11 Dec '13, 06:53) crashtech66
1

217.212.243.27 seems to be Facebook. Why did you filter on that?

Anyway: the capture filter "ether host 5c:ff:35:28:aa:0a or ether host 6c:b7:f4:fa:49:f9" will show traffic of both systems in both directions (incoming and outgoing). So, if something is missing in your capture file, there is something else wrong with your capture setup.

(11 Dec '13, 07:08) Kurt Knochner ♦

That IP filters out a Facebook app that was getting by the display filter. Maybe it would be better to include it in the display filter, but I notice that capturing excess packets can impact system performance. I don't think it should affect yahoo traffic at all.

The only difference from the test capture I posted is that the recent captures are mobile device to mobile device, though everything else is the same, and the hub from which Wireshark pulls the packets is correctly placed.

I would love to have you look at the capture file to see if the other end of the traffic is there, but am afraid to post it publicly as it is NOT a test, but an actual converstion.

(11 Dec '13, 08:26) crashtech66
showing 5 of 12 show 7 more comments