Home > Projects > Motorola Is Listening

Motorola Is Listening

article by Ben Lincoln

In June of 2013, I made an interesting discovery about the Android phone (a Motorola Droid X2) which I was using at the time: it was silently sending a considerable amount of sensitive information to Motorola, and to compound the problem, a great deal of it was over an unencrypted HTTP channel.

If you're in a hurry, you can skip straight to the Analysis - email, ActiveSync, and social networking section - that's where the most sensitive information (e.g. email/social network account passwords) is discussed.

Table of contents

1. Updates
   1. Update 5 (2013-07-28 @ 23:00) - Little Sister, and a hack/workaround to prevent Blur connectivity
   2. Update 4 (2013-07-04 @ 16:00) - other devices, and further clarifications
   3. Update 3 (2013-07-03 @ 08:30) - another problem, and another potential device
   4. Update 2 (2013-07-02 @ 08:03) - potential device security concern
   5. Update 1 (2013-07-02 @ 05:30) - Android, the Droid X2, and Blur
2. Introduction
   1. Technical notes
   2. Discovery
3. Communication/data/security analysis and opinions
   1. Analysis - email, ActiveSync, and social networking
   2. Analysis - "check-in" data
   3. Analysis - Jabber / XMPP stream communication
   4. Speaking of that privacy policy...
   5. Why this is a problem
   6. Authentication security (problems)
   7. Potential (untested) device security concern
   8. Little Sister - the physical-location reporting component
   9. Is there anything good to be found here?
   10. Has anyone else discovered this?
   11. What I am going to do as a result of this discovery
   12. Which other models of Motorola device do this?
   13. Hack/workaround for preventing connectivity to the Blur web service (on rooted devices only)
   14. Question and answer
4. Steps to reproduce (for technical/security readers)
   1. Steps to reproduce - HTTP/HTTPS data capture
   2. Steps to reproduce - check-in data decompression
   3. Steps to reproduce - XMPP communication channel

Update 5 (2013-07-28 @ 23:00) - Little Sister, and a hack/workaround to prevent Blur connectivity

Added some limited information about Little Sister - the physical-location reporting component of the Blur software.

Added a description of a hack/workaround I'm testing that seems to prevent connectivity to the Blur web service, but which requires a rooted device.

Update 4 (2013-07-04 @ 16:00) - other devices, and further clarifications

Added information on some additional devices (see Which other models of Motorola device do this?), and some question-and-answer/FAQ-type information (see Question and answer). I also added a table-of-contents (above) due to the increasing length of the writeup.

A small favour I'd like to ask - if you drop me a line using the Contact form, please make sure to include a valid email address if you'd like a reply. Please also make sure that emails from the beneaththewaves.net domain are not blocked by any anti-spam technology you may have deployed, or at least check your spam folder :).

Robin in the UK forwarded me an article describing how little location data is needed to uniquely identify a person. Definitely an interesting read in relation to systems like the one I describe here, as well as the systems that all of the wireless carriers in the US operate.

Update 3 (2013-07-03 @ 08:30) - another problem, and another potential device

I realized I'd missed a significant issue with the way authentication information is passed around. See Authentication security (problems).

I've also received an email from someone who said they tested their Photon 4G and received similar results, so I've added a note to Which other models of Motorola device do this? to that effect.

Important: for anyone who came here after reading The Register's writeup on this (or the earlier discussion on Hacker News), the data being sent to Motorola is not due to Exchange ActiveSync. I discovered the problem while testing some ActiveSync functionality, and some of the ActiveSync configuration data is sent to Motorola, but it's Motorola's software that's responsible for the personal and configuration data being sent to Motorola, not Microsoft's EAS. Other types of data will be sent to and through Motorola's Blur servers even if you never configure EAS connectivity on the device.

Update 2 (2013-07-02 @ 08:03) - potential device security concern

I realized this morning that there may be a more significant problem. See Potential (untested) device security concern, below.

Update 1 (2013-07-02 @ 05:30) - Android, the Droid X2, and Blur

This article has gotten a lot more attention than I expected.

A clarification I'd like to make (because there seems to be a lot of confusion about this) is that the Droid X2 does not use Motorola's "Blur"/"MotoBlur" user interface. That's one of the reasons I picked that model specifically back in 2011 - it seemed to be running something very close to the stock version of Android.

The email client, web browser, text-messaging app, and so on look like the ones that were included on the G1 I had previously, which is about as close to "stock Android" as you can get with a carrier-installed OS. Based on my research, it seems that they've all been modified to silently send data to and/or through the Blur web-service back-end, but there's no indication to the user that this is the case unless they do the sort of network capture that I did. There is no prompt to create or use a Blur user ID - the phone uses a randomly-generated Blur account for all of the behind-the-scenes activity described below.

I would be very interested in trying this same test with more recent Motorola phones, because there's definitely the perception out there that Blur has been phased out, and I think it's much more likely that it's just the UI on their phones that's been changed, as opposed to removing the underlying Blur functionality.

If you're still unsure why I think this is a problem, ask yourself this: if you bought a desktop PC running Windows, then discovered two years later that the hardware manufacturer had installed modified versions of standard Windows software like Outlook Express and Internet Explorer which - without any indication to the user - sent your passwords to, and routed other traffic through servers owned by the PC manufacturer instead of connecting directly to the actual websites and mail servers, would you be OK with it? If not, then why are you when it's a phone instead of a desktop PC?

Technical notes

The screenshots and other data in this article are more heavily-redacted than I would prefer in the interest of full disclosure and supporting evidence. There are several reasons for this:

1. There is a considerable amount of binary, hex-encoded, and base64-encoded data mixed in with the traffic. As I have not performed a full reverse-engineering of the data, it's hard for me to know if any of these values are actually sensitive at this time, or in the future when someone more thoroughly decodes the protocol.
2. My employer reminds its employees that publicly identifying themselves as employees of that organization conveys certain responsibilities upon them. I do not speak for my employer, so all information that would indicate who that employer is has been removed.
3. I would rather not expose my personal information more than Motorola has already.

Discovery

I was using my personal phone at work to do some testing related to Microsoft Exchange ActiveSync. In order to monitor the traffic, I had configured my phone to proxy all HTTP and HTTPS traffic through Burp Suite Professional - an intercepting proxy that we use for penetration testing - so that I could easily view the contents of the ActiveSync communication.

Looking through the proxy history, I saw frequent HTTP connections to ws-cloud112-blur.svcmot.com mixed in with the expected ActiveSync connections.

As of 22 June, 2013, svcmot.com is a domain owned by Motorola, or more specifically:

Motorola Trademark Holdings, LLC

600 North US Highway 45 Attn: Law Department

Libertyville IL 60048

US

internic@motorola.com +1.8475765000 Fax: +1.8475234348

I was quickly able to determine that the connections to Motorola were triggered every time I updated the ActiveSync configuration on my phone, and that the unencrypted HTTP traffic contained the following data:

1. The DNS name of the ActiveSync server (only sent when the configuration is first created).
2. The domain name and user ID I specified for authentication.
3. The full email address of the account.
4. The name of the connection.

As I looked through more of the proxy history, I could see less-frequent connections in which larger chunks of data were sent - for example, a list of all the application shortcuts and widgets on my phone's home screen(s).

Analysis - email, ActiveSync, and social networking

I decided to try setting up each of the other account types that the system would allow me to, and find out what was captured.

 

Facebook and Twitter

For both of these services, the email address and password for the account are sent to Motorola. Both services support a mechanism (oAuth) explicitly intended to make this unnecessary, but Motorola does not use that more-secure mechanism. The password is only sent over HTTPS, so at least it can't be easily intercepted by most third parties.

Most subsequent connectivity to both services (other than downloading images) is proxied through Motorola's system on the internet using unencrypted HTTP, so Motorola and anyone running a network capture can easily see who your friends/contacts are (including your friends' email addresses), what posts you're reading and writing, and so on. They'll also get a list of which images you're viewing, even though the actual image download comes directly from the source.

 

Photobucket and Picasa

For both services, email address and password are sent to Motorola over HTTPS.

For Photobucket, username and image URLs are sent over unencrypted HTTP.

For Picasa, email address, display name, friend information, and image URLs are sent over unencrypted HTTP.

During my testing of Photobucket, the photo was uploaded through Motorola's system (over HTTPS). I was not able to successfully upload a photo to Picasa, although it appeared that the same would have been true for that service.

 

Photo uploads (to Facebook, Photobucket, etc.)

When uploading images, the uploaded image passes through Motorola's Blur servers, and at least some of the time is uploaded with its EXIF data intact. EXIF data is where things like GPS coordinates are stored.

The full path of the original image on the device is also sent to Motorola. For example, /mnt/sdcard/dcim/Camera/2013-06-20_09-00-00_000.jpg. Android devices name phone-camera images using the time they were taken with millisecond resolution, which can almost certainly be used as a unique device identifier for your phone (how many other people were taking a picture at exactly that millisecond?), assuming you leave the original photo on your phone.

 

Youtube

Email address and password are sent to Motorola over HTTPS.

Email address is also sent to Motorola over unencrypted HTTP, along with some other data that I haven't deciphered.

I didn't have time to create and upload a video, so I'm not sure what else might be sent.

 

Exchange ActiveSync

Domain name, username, email address, and name of the connection are sent over unencrypted HTTP. When a new connection is created, the Exchange ActiveSync server's DNS name is also sent.

 

IMAP/POP3 email

Email address, inbound/outbound server names, and the name of the connection are sent over unencrypted HTTP. There is a lot of other encoded/encrypted data included which I haven't deciphered.

 

Yahoo Mail

Email address is sent over unencrypted HTTP. This type of account seems to be handled in at least sort of the correct way by Motorola's software, in that a request is made for an access token, and as far as I can tell, the actual account password is never sent to Motorola.

 

Flickr

Similar to the Yahoo Mail results, but actually one step better - an explicit Flickr prompt appears indicating what permissions Motorola's system is asking for on behalf of the user.

 

GMail/Google

Interestingly, no data seemed to be sent to Motorola about this type of account. Unfortunately, if anyone adds a Youtube or Picasa account, they've sent their GMail/Google+ credentials to Motorola anyway.

Also interestingly, while testing Picasa and/or Youtube integration, Motorola's methods of authenticating actually tripped Google's suspicious activity alarm. Looking up the source IP in ARIN confirmed the connection was coming from Motorola.

 

Firefox sync

No data seems to pass through Motorola's servers.

 

News / RSS

RSS feeds that are subscribed to using the built-in News application are proxied through Motorola's servers over unencrypted HTTP.

 

Other data

Every few minutes, my phone sends Motorola a detailed description of my home screen/workspace configuration - all of the shortcuts and widgets I have on it.

Analysis - "check-in" data

As I was looking through the data I've already mentioned, I noticed chunks of "check-in" data which was a binary upload, and I thought I'd see if it was in some sort of standard compressed format. As it turns out, it is - the 0x1F8B highlighted below is the header for a block of gzip-compressed data.

What is contained in this data are essentially debug-level log entries from the device. The battery drain and bandwidth use from having the phone set up like this must be unbelievable.

Most of the data that's uploaded is harmless or low-risk on its own - use statistics, and so on. However, this is another mechanism by which Motorola's servers are collecting information like account names/email addresses, and the sheer volume and variety of other data makes me concerned that Motorola's staff apparently care so much about how I'm using my phone. If this were a corporate-owned device, I would expect the owning corporation to have this level of system data collection enabled, but it concerns me that it's being silently collected from my personal device, and that there is no way to disable it.

 

Information that is definitely being collected

1. The IMEI and IMSI of the phone. These are referred to as MEID and MIN in the phone's UI and on the label in the battery compartment, but IMEI and IMSI in the logs. I believe these two values are all that's needed to clone a phone, if someone were to intercept the traffic.
2. The phone number of the phone, and carrier information (e.g. Verizon).
3. The barcode from inside the battery compartment.
4. Applications included with the device as well as installed by the user.
5. Statistics about how those applications are used (e.g. how much data each one has sent and received).
6. Phone call and text message statistics. For example, how many calls have been received or missed.
7. Bluetooth device pairing and unpairing, including detailed information about those devices.
8. Email addresses/usernames for accounts configured on the device.
9. Contact statistics (e.g. how many contacts are synced from Google, how many Facebook users are friends of the account I've configured on the device).
10. Device-level event logs (these are sent to Google as well by a Google-developed checkin mechanism).
11. Debugging/troubleshooting information about most activities the phone engages in.
12. Signal strengths statistics and data use for each type of radio included in the device. For example, bytes sent/received via 3G versus wifi.
13. Stack memory and register dumps related to applications which have crashed.
14. For Exchange ActiveSync setup, the server name and email address, as well as the details of the security policy enforced by that EAS server.

 

Information that may be being collected

The terms-of-use/privacy policy for the Blur service (whether you know you're using it or not) explicitly specify that location information (e.g. GPS coordinates) may be collected (see Speaking of that privacy policy..., below). I have not seen this in the data I've intercepted. This may be due to it being represented in a non-obvious format, or it may only be collected under certain conditions, or it may only be collected by newer devices than my 2-year-old Droid X2.

While I have no conclusive evidence, I did notice while adding and removing accounts from my phone that the account ID number for a newly-added account is always higher than that for any accounts that existed previously on the device, even if those accounts have been deleted. This implies to me that Motorola's Blur service may be storing information about the accounts I've "deleted" even though they're no longer visible to me. This seems even more likely given the references in the communication to "universalAccountIds" and "knownAccountIds" referenced by GUID/UUID-like values.

Analysis - Jabber / XMPP stream communication

In some of the check-in logs, I saw entries that read e.g.:

XMPPConnection: Preparing to connect user XXXXXXXXXXXXXXXX to service: jabber-cloud112-blur.svcmot.com on host: jabber-cloud112-blur.svcmot.com and port: 5222

XMPPConnectionManager I:onConfigurationUpdate: entered

XMPPConnectionManager I:onConfigurationUpdate: exiting

WSBase I:mother told us it's okay to retry the waiting requests: 0

NormalAsyncConnection I:Connected local addr: 192.168.253.10/192.168.253.10:60737 to remote addr: jabber-cloud112-blur.svcmot.com/69.10.176.46:5222

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Wrote out 212 bytes of data with 0 bytes remaining.

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 202 bytes into buffer

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 262 bytes into buffer

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Wrote out 78 bytes of data with 0 bytes remaining.

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 1448 bytes into buffer

TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 2896 bytes into buffer

XMPPConnection I:Finished connecting user XXXXXXXXXXXXXXXX to service: jabber-cloud112-blur.svcmot.com on host: jabber-cloud112-blur.svcmot.com and port: 5222

By running a network capture, I was able to confirm that my phone was regularly attempting this type of connection. However, it was encrypted using TLS, so I couldn't see the content of the communication at first.

The existence of this mechanism made me extremely curious. Why did Motorola need yet another communication channel for my phone to talk to them over? Why were they using a protocol intended for instant messaging/chat? The whole thing sounded very much like a botnet (which often use IRC in this way) to me.

Intercepting these communications ended up being much more work than I expected. XMPP is an XML-based protocol, and cannot be proxied by an HTTP/HTTPS proxy, so using Burp Suite or ZAP was out. My first thought was to use Mallory, an intercepting transparent proxy that I learned about in the outstanding SANS SEC 642 class back in the March of 2013. Mallory is a relatively new tool, and is somewhat finnicky to get set up, but I learned a lot doing so. Unfortunately, XMPP is not a protocol that Mallory can intercept as of this writing.

The VM that I built to run Mallory on still proved useful in this case, as I was eventually able to hack together a custom XMPP man-in-the-middle exploit and view the contents of the traffic. If you'd like to know more about the details, they're in the Steps to reproduce - XMPP communication channel section further down this page.

This channel is at least part of the Motorola Blur command-and-control mechanism. I haven't seen enough distinct traffic pass through it to have a good idea of the full extent of its capabilities, but I know that:

1. The XMPP/Jabber protocol is re-purposed for command-and-control use. For example, certain types of message are sent using the field normally used for "presence" status in IM.
2. The values exchanged in the presence fields appear to be very short (five-character) base64-encoded binary data, followed by a dash, and then a sequence number. For example, 4eTO3-52, Ugs6j-10, or t2bcA-0. The base64 value appears to be selected at boot. The sequence number is incremented differently based on criteria I don't understand (yet), but the most common step I've seen is +4.
3. As long as the channel is open, the phone will check in with Motorola every nine minutes.
4. At least one type of Motorola-to-phone command exists: a trigger to update software by ID number.
5. At least three such ID numbers exist: 31, 40, and 70 (see the table below). Each of these trigger an HTTP post request to the blur-services-1.0/ws/sync API method seen in the previous section, and the same IDs are logged in the check-in data.
6. The stream token and username passed to the service are the "blurid" value (represented as a decimal number) which shows up in various places in the other traffic between the phone and Motorola.

ID	Name	Purpose	Data Format	Observed In Testing?
2	BlurSettingsSyncHandler	Unknown	JSON	No
5	BlurSetupSyncHandler	Unverified - called when a new type of sync needs to be added?	gpb	Yes
10	BlurContactsSyncHandler	Syncs contact information (e.g. Google account contacts)	gpb	No
20	SNMailSyncHandler	Unverified - probably syncs private messages from social networking sites	gpb	No
31	StatusSyncHandler	Syncs current status/most-recent-post information from social networking sites	gpb	Yes
40	BlurSNFriendsSyncHandler	Syncs friend information from social networking sites	gpb	Yes
50	NewsRetrievalService	Syncs news feeds set up in the built-in Motorola app	gpb	Yes
60	AdminFlunkySyncHandler	Unverified - sounds like some sort of remote-support functionality	gpb	No
70	FeedReceiverService	Unknown	gpb	Yes
80	SNCommentsSyncHandler	Syncs status/comment information from social networking sites	gpb	Yes

The "gpb" data format is how that type of binary encoding is referred to internally by the client logs. I believe it is similar (possibly identical) to Google's "protocol buffer" system.

Here is an example session, including the SYNC APP command being sent by the server. Traffic from the client is represented in red. Traffic from the server is coloured blue.

<stream:stream token="XXXXXXXXXXXXXXXX" to="jabber-cloud112-blur.svcmot.com" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="xmpp.svcmot.com" id="concentrator08228e8bb1" xml:lang="en" version="1.0">

<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"></mechanisms><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features><proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>

[Communication after this point takes place over the encrypted channel which the client and server have negotiated.]

<stream:stream token="XXXXXXXXXXXXXXXX" to="xmpp.svcmot.com" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="xmpp.svcmot.com" id="concentrator08228e8bb1" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"></mechanisms><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features>

<iq id="4eTO3-24" type="set"><query xmlns="jabber:iq:auth"><username>4503600105521277</username><password>1-d052e26d5bbb5b4adce7965e3e248a331765623714</password><resource>BlurDevice</resource></query></iq><iq id="4eTO3-25" type="get"><query xmlns="jabber:iq:roster"></query></iq><presence id="4eTO3-26"></presence>

<iq type="result" id="4eTO3-24"/>

<message xmlns="urn:xmpp:motorola:motodata" id="0J8Hc-30570875" to="XXXXXXXXXXXXXXXX@jabber01.mm211.dc2b.svcmot.com"><data xmlns="com:motorola:blur:push:data:1">{"Sync":{"APP":[{"d":"sync_app_id: 31\n","q":0}]}}</data></message>

While I have seen very little sensitive data being sent as a result of this mechanism, Motorola's privacy policy/terms-of-service related to this system makes me more concerned. There is literally no reason I can think of that I would want my phone to check in with Motorola every nine minutes to see if Motorola has any new instructions for it to execute. Is there some sort of remote-control capability intended for use by support staff? I know there is a device-location and remote wipe function, because those are advertised as features of Blur (apparently even if you didn't explicitly sign up for Blur).

 

Speaking of that privacy policy...

I honestly can't remember if I explicitly agreed to any sort of EULA when I originally set up my phone. There are numerous "terms of service" and "privacy policy" documents on the Motorola website which all seem designed to look superficially identical, but this one in particular (the one for the actual "Motorola Mobile Services" system (AKA "Blur")) has a lot of content I really don't like, and which is not present in the other, similar documents on their site that are much easier to find. For example, it specifically mentions capturing social networking credentials, as well as uploading GPS coordinates from customers' phones to Motorola.

It is specific to "Motorola Mobile Services", and I know I didn't explicitly sign up for that type of account (which is probably why my phone is using a randomly-generated username and password to connect). I also know that even if I was presented with a lengthy statement which included statements about storing social media credentials, that happened when I originally bought the phone (about two years ago). Should I not have been at least reminded of this when I went to add a social networking account for the first time? Or at a bare minimum, should my phone not let me view any document I allegedly agreed to? The only reason I know of that particular TOS is because I found it referenced in a Motorola forum discussion about privacy concerns.

In any case, here are some interesting excerpts from that document (as of 22 June, 2013). All bold emphasis is mine. I am not a lawyer, and this is not legal advice.

Using the MOTOROLA MOBILE SERVICES software and services (MOTOROLA MOBILE SERVICES) constitutes your acceptance of the terms of the Agreement without modification. If you do not accept the terms of the Agreement, then you may not use MOTOROLA MOBILE SERVICES.

Motorola collects and uses certain information about you and your mobile device ... (1) your device's unique serial number ... (5) when your device experiences a software crash ... (1) use of hardware functions like the accelerometer, GPS, wireless antennas, and touchscreen; (2) wireless carrier and network information; (3) use of accessories like headsets and docks; (4) data usage ... Personal Information such as: (1) your email and social network account credentials; (2) user settings and preferences; (3) your email and social network contacts; (4) your mobile phone number; and (5) the performance of applications installed on your device. ... MOTOROLA MOBILE SERVICES will never collect the specific content of your communications or copies of your files.

The document makes a promise that the content of communications are not collected, but I have screenshots and raw data that show Facebook and Twitter messages as well as photos passing through their servers.

The agreement specifies "when your device experiences a software crash", not "memory dumps taken at the time of a software crash", which are what is actually collected.

Motorola takes privacy protection seriously.

MOTOROLA MOBILE SERVICES only collects personal information, social network profile data, and information about websites you visit if you create a MotoCast ID, use the preinstalled web browser and/or MOTOROLA MOBILE SERVICES applications and widgets like Messaging, Gallery, Music Player, Social Networking and Social Status. If you use non-Motorola applications for email, social networking, sharing content with your friends, and web browsing, then MOTOROLA MOBILE SERVICES will not collect this information. Even if you decline to use the preinstalled browser or the MOTOROLA MOBILE SERVICES applications and widgets, your device will continue to collect information about the performance of your mobile device and how you use your mobile device unless you choose to opt out.

In non-Motorola builds of Android, most/all of those components are still present, but none of them send data to Motorola. Some people might think it was extremely deceptive to add data collection to those components but not make user-visible changes to them that mentioned this. Oh, and of course the OS is still collecting massive amounts of data even if you don't use the modified basic Android functionality.

MOTOROLA MOBILE SERVICES only collects and uses information about the location of your mobile device if you have enabled one or more location-based services, such as your device's GPS antenna, Google Location Services, or a carrier-provided location service. If you turn these features off in your mobile device's settings, MOTOROLA MOBILE SERVICES will not record the location of your mobile device.

So what you're saying is that all I have to do to prevent Motorola from tracking my physical location is disable core functionality on my device and leave it off permanently? Awesome! Thanks so much!

The security of your information is important to Motorola.

When MOTOROLA MOBILE SERVICES transmits information from your mobile device to Motorola, MOTOROLA MOBILE SERVICES encrypts the transmission of that information using secure socket layer technology (SSL).

Except when it doesn't, which is most of the time.

However, no data stored on a mobile device or transmitted over a wireless or interactive network can ever be 100 percent secure, and many of the communications you make using MOTOROLA MOBILE SERVICES will be accessible to third parties. You should therefore be cautious when submitting any personally identifiable information using MOTOROLA MOBILE SERVICES, and you understand that you are using MOTOROLA MOBILE SERVICES at your own risk.

As a global company, Motorola has international sites and users all over the world. The personal information you provide may be transmitted, used, stored, and otherwise processed outside of the country where you submitted that information, including jurisdictions that may not have data privacy laws that provide equivalent protection to such laws in your home country.

You may not ... interfere with anyone's ... enjoyment of the Services

Uh oh.

That document does mention that anyone who wants to opt-out can email privacy@motorola.com. If you have any luck with that, please let me know.

I've received emails from at least two people who have sent opt-out requests to that address in the past. They were not able to verify whether or not the behaviour of their devices actually changed or not.

Why this is a problem

While I'm sure there are a few people out there who don't mind a major multinational corporation collecting this sort of detailed tracking information related to where their phone has been and how it's been used, I believe most people would at least like to be asked about participating in this type of activity, and be given an option to turn it off.

I can think of many ways that Motorola, unethical employees of Motorola, or unauthorized third parties could misuse this enormous treasure trove of information. But the biggest question on my mind is this: now that it is known that Motorola is collecting this data, can it be subpoenaed in criminal or civil cases against owners of Motorola phones? That seems like an enormous can of worms, even in comparison to the possibilities for identity theft that Motorola's system provides for.

How secure is Motorola's Blur web service against attack? I'd be really interested to test this myself, but made no attempt to do so because I don't have permission and Motorola doesn't appear to have a "white hat"/"bug bounty" programme. It would be a tempting target for technically-skilled criminals, due to the large volume of Facebook, Twitter, and Google usernames and passwords stored in it.

The fact that the phone actively polls Motorola for new instructions to execute and then follows those instructions without informing its owner opens all of these phones up to automated takeover by anyone who can obtain a signing SSL certificate issued by one of the authorities in the trusted CA store on those phones. Some people may consider this far-fetched, but consider that certificates of that type have been mistakenly issued in the past, and the root certificate for at least one of the CA's responsible for that type of mistake (TURKTRUST) were installed on my phone at the factory.

If any of the Motorola components have remote-code-execution vulnerabilities that can be exploited as a result of this service, it's very likely that the entire phone can be compromised, because nearly all of them use a 1995-style "we'll just require that the software have unrestricted access to the phone, because that's easiest" set of permissions.

Authentication security (problems)

My original focus was on my own data being sent to Motorola, and as such, I missed a significant issue with the information the device uses to authenticate to Motorola's Blur servers. I've used screenshots here with a few leading and trailing characters of sensitive values visible here to help make this easier to follow. Hopefully that wasn't a terrible idea.

What's happening here:

1. The phone makes an oAuth request to Motorola's Blur service. Among the values used are a concatenated version of the hex-string representation of the phone's Blur ID, and the ~160-bit value used as the oAuth token.
2. In subsequent HTTPS requests, such as uploading the big check-in data dumps described above, the oAuth information is included. This is probably fine - I don't see any issues here.
3. Uh oh. All of that data from the auth headers in the check-in request is also sent in unencrypted HTTP exchanges such as when syncing news feed data. But maybe there's some critical component missing that is only ever exchanged over secure channels. Maybe there's nothing sensitive that can be done with this completely unprotected auth information?
4. ...unless you could being able to authenticate to the XMPP command-and-control channel as the phone as "sensitive", because all you need to do that are two pieces of information that are included in that unencrypted HTTP exchange.

I think this would be a problem regardless, but the Blur ID value is fixed for a given phone, and I've never seen the value used for the oAuth token change in multiple weeks of traffic-monitoring.

Potential (untested) device security concern

I didn't make the connection until two days after posting the original version of this article, but I believe there is an even-more-significant problem with the way my device is behaving:

As discussed above, although the command-and-control and some of the device-to-Motorola communication take place over encrypted channels, most of the communication (at least in terms of number of connections to Motorola) is over unencrypted HTTP. That communication is triggered by commands sent over the (encrypted) XMPP channel.

Let me say that again, in a slightly different way:

Commands are being received over a trusted, encrypted channel, but those commands order the device to perform actions across an untrusted, unencrypted channel.

Theoretically, this should mean that it's possible to interfere with the unencrypted channel without having to compromise the encrypted channel at all. The only reason I can think of that this wouldn't work would be if Motorola's developers had used some sort of signing mechanism for the unencrypted HTTP traffic.

If no such additional protection exists, then it should be possible to set up a transparent proxy which forwards on SSL communication to Motorola without attempting to intercept it, while modifying or replacing the contents of the unencrypted HTTP communication. At a minimum (again, assuming there is no additional protection of the HTTP data) this should allow things like RSS feed and social media content to be changed before it reaches the user's phone.

If all of this actually works (and this is a big "if"), and such a transparent proxy is combined with e.g. Jasager, then an attacker could set up the Jasager wireless AP in a public place and simply wait for owners of Motorola devices to pass through the area. Anyone whose device received a sync command (over the encrypted XMPP channel) of the type that allowed the (currently theoretical) attack would have their device (or at least data on that device) automatically compromised.

My guess is that someone is already working on this (e.g. for causing grief for attendees at DefCon or Black Hat), but I thought I'd mention it in case no one else had made the same connection yet.

Again, this is entirely theoretical at this point. If I can find conclusive evidence either way, I'll make another update to this article.

Little Sister - the physical-location reporting component

After a few weeks of testing without root access, I went ahead and obtained it (see the Hack/workaround for preventing connectivity to the Blur web service (on rooted devices only) section for more on this). This allowed me to examine the actual software and configuration files on the phone.

There is an awful lot of research that could be done at that level, but one thing stood out from the rest: a component called "Little Sister", which appears to be the Blur component responsible for the collection of physical location information (e.g. via GPS or the cellular network). The easiest place to find a reference to Little Sister is in the /data/data/com.motorola.blur.service.blur/shared_prefs/blur_services_config.xml file (again, see the hack/workaround section below for some more information on that file). There are three entries in it related to this component. If the file on your phone is anything like the one on mine, they'll look like this:

<string name="blur.service.littlesister.gpsFixWaitTime">60000</string>

<string name="blur.service.littlesister.reportLevel2">NONE</string>

<string name="blur.service.littlesister.reportLevel">NONE</string>

As the second and third entries imply, every indication was that on my device, this component was disabled - which explains why I never saw location data being sent to Motorola from it.

To try to better understand this service, I decompiled the packages in question (/system/framework/com.motorola.blur.library.service.odex and /system/app/blur-services.odex) using baksmali.

There appear to be three valid settings for blur.service.littlesister.reportLevel: NONE, CELL, and GPS.

I'm not sure under what normal circumstances this service is activated. Is it part of a find-my-phone style service, where only the owner has the means to enable it? Is it enabled on request from law-enforcement agencies? Do Motorola support staff have the ability to switch it on silently? Does it always default to a disabled state, or is it just a coincidence in my case? That's part of the problem with undocumented, mysterious functionality like this - it's often hard to be sure what the designers were thinking.

I did attempt to switch it on myself, by setting both of the reportLevel values to CELL and GPS. I also tried reducing the gpsFixWaitTime value to 1000 (one second, I think?). None of this caused location data to be collected or sent, so I must be missing a piece of the puzzle.

I also saw indications in this component and others that the Motorola software is encrypting certain types of data using AES before sending it to Motorola. I haven't worked out how it determines the key or IV to use - it doesn't appear to be the defaults for those that are defined in SimpleEncryptUtil - but I am somewhat unsettled by this because I think this is done when the phone sends data over unencrypted HTTP. The reason I'm troubled by this is that in nearly every case where I've seen a developer implement their own encryption instead of using SSL, there has been a flaw in the implementation that meant it could be easily decrypted. There may not be such a problem here, but if the software just went ahead and used HTTPS for everything, I wouldn't even have to worry about it.

Is there anything good to be found here?

Motorola does appear to be using reasonably-strong authentication for the oAuth login to their system - the username seems to be a combination of the IMEI and a random number (16 digits long^[2], in the case of my phone's username), and the password is a 160-bit value represented as a hex string. This would be essentially impossible to attack via brute-force if the value really is random. Due to its length, I'm concerned it's a hash of a fixed attribute of the phone, but that's just a hunch. The non-oAuth components (e.g. XMPP) use the Blur ID as the username, and that is all over the place, e.g. in virtually every URL (HTTP and HTTPS) that the client accesses on the Blur servers. [ see Authentication security, above. ]

When uploading images to social networking sites, the Motorola software on the phone sometimes strips the EXIF tags (including geolocation tags) before uploading the image to Motorola. So at least they can't always use that as another method for determining your location.

Finally, both the XMPP and HTTPS client components of the software do validate that the certificates used for encrypted communication were issued by authorities the phone is configured to trust. If the certificate presented to either component is not trusted, then no encrypted channel is established, and data which would be sent over it is queued until a trusted connection can be made. If someone wants to perform a man-in-the-middle attack, they're going to need to get their root CA cert loaded on the target phones, or obtain a signing cert issued by a trusted authority (e.g. TURKTRUST).

Has anyone else discovered this?

In January of 2012, a participant in a Motorola pre-release test discovered that Motorola was performing device-tracking after a Motorola support representative mentioned that the tester had reset his phone "21 times", and a forum moderator directed him to the special, hard-to-find Motorola privacy policy discussed above.

Since I published the original version of this article, I've received emails from several people who have seen similar traffic from their Motorola devices in the past, but no information on any detailed public releases prior to now.

To my knowledge, this article is the first disclosure of anything like the full extent of the data Motorola collects.

What I am going to do as a result of this discovery

1. As of 23 June 2013, I've removed my ActiveSync configuration from the phone, because I can't guarantee that proprietary corporate information isn't being funneled through Motorola's servers. I know that some information (like the name of our ActiveSync server, our domain name, and a few examples of our account-naming conventions) is, but I don't have time to exhaustively test to see what else is being sent their way, or to do that every time the phone updates its configuration.
2. I've also deleted the IMAP configuration that connected to my personal email, and have installed K-9 Mail as a temporary workaround.
3. I'm going to figure out how to root this phone and install a "clean" version of Android. I've rooted my phone, and eventually will install a "clean" version of Android. That will mean I can't use ActiveSync (my employer doesn't allow rooted phones to connect), which means a major reason I use my phone will disappear, but better that than risk sending their data to Motorola.
4. I'll assume that other manufacturers and carriers have their own equivalent of this - recall the Carrier IQ revelation from 2011.

Which other models of Motorola device do this?

The bulk of the research I've done has been using my personal Droid X2 (Android 2.3.5).

[ Update: 2013-07-04 ] On 3 July, 2013, I had a chance to do some very brief testing with a friend's Droid Razr Maxx (not sure if it was the HD variant or not, but I think it was), and while it does not behave identically, I do know that it's communicating with api.svcmot.com using what look like JSON calls (instead of mostly-binary data like my older phone). At a minimum, I know that information like the phone number and IMSI/IMEI is sent, and I know that the system is still using a numeric account identifier that looks identical in format to the Blur ID as well as password/token that looks identical in format to the oAuth token/XMPP password that mine sends, although they've been renamed (IE it was no longer referred to as the "Blur ID", at least in the traffic I saw). To the best of my knowledge, the Droid Razr Maxx and Droid Razr Maxx HD both run Android 4.x, which implies that statements like this one made on the Motorola forums ("It does only apply to devices running Android 3.2 and older") are incorrect and/or misleading. I can't comment on whether there are settings on the newer Motorola phones to control the level of data collected, or how well those work, without more time to test one personally. There are no such controls on my older Droid X2, but I would certainly welcome such controls being present on both new and old devices. If anyone wants to try reproducing my results with Android 4.x Motorola phones, you'll probably have a much easier time, as the JSON data is much more human-friendly than the older format.

Models of device that have been reported to me in email as communicating in at least similar ways with Motorola (I have not seen the data myself):

• [ 2013-07-03 ] Motorola Photon 4G (Android 2.3.5) [thanks to GeniusMusing - included a screenshot documenting these results]
• [ 2013-07-04 ] Motorola Defy (Android 2.x) [thanks to Frank Zacharias]
• [ 2013-07-04 ] Motorola Milestone 2/Droid 2 (Android 2.3.5)

Models of device that I've tested and found to not use the Blur web services:

• [ 2013-07-28 ] Motorola Xoom tablet - both Android 3.x and 4.x

My assumption (and it is just an assumption) is that most/all Motorola Android devices released since their first Blur/MotoBlur model (the CLIQ, I think?) incorporate one or more of the mechanisms I've described, or similar mechanisms. For example, the Droid Razr Maxx I mention above doesn't literally include the same binary-data-upload mechanism as my Droid X2, but it does include one that provides at least some of the same information to Motorola using JSON calls to a different subdomain of svcmot.com.

If you have a Motorola device and are technically-inclined, the steps to reproduce my testing are in the section below. If you get results either way and would like me to include them here, please get in touch with me using the Contact form. Please include the model of your device, the results of your testing, and your name/nickname/handle/URL/etc. if you'd like to be identified. If you would like to remain anonymous, please let me know that too - that's always my assumption, but it may be the wrong one in your case.

Hack/workaround for preventing connectivity to the Blur web service (on rooted devices only)

Important: I am describing a change I made to my own device in an attempt to work around the lack of controls in the UI for changing the behaviour of the Motorola software. I do not recommend that other people do the same thing. Performing a similar change on your device involves voiding the warranty, and may result in the device ceasing to function altogether.

After performing as much research as I felt I could with the phone in a "supported" state, I obtained root access on it using the method described in this XDA Developers forum thread, and then installed the Terminal Emulator app from the Play Store.

One of the configuration files I was able to access after rooting the phone was /data/data/com.motorola.blur.service.blur/shared_prefs/blur_services_config.xml. Among other things, it contains the names of the servers to connect to for the various Blur services.

Here are the steps I took to modify the file. This could be done locally on the device (without copying the file to a PC for editing) as well, although you'd still need to copy the config file out of its normal location unless you have a good way to run your Android text-editor app as root.

Again, I do not recommend that you do this yourself. This is a log of what I've done to my own phone which may very well be updated at a later time with a final step of "realized the device was bricked".

1. Disable cellular network data access on the device. On mine this is the Data enabled checkbox in the OS-level Settings => Battery & data manager => Data delivery. This checkbox should be unchecked while the remaining steps are performed.
2. Disable wireless network connectivity as well. The Droid X2 includes a handy toggle widget for this, but it can also be found in the OS-level Settings => Wireless & networks => Wi-Fi. This checkbox should also be unchecked during this process. The reason for these first two steps is that there are several values in the configuration file which are updated every time the device communicates with the Blur web services. If I ever decide to re-enable Blur connectivity for some reason, these values should be in sync with what Blur expects them to be based on the last communication.
3. Launch the Terminal Emulator app.
4. Execute the following commands to switch to the root user context, create a local backup of the config file, and copy it to the SD card:

    

   su

   cd /data/data/com.motorola.blur.service.blur/shared_prefs

   cp blur_services_config.xml blur_services_config.bak

   mkdir /mnt/sdcard/b

   mkdir /mnt/sdcard/b/01pre

   cp blur_services_config.xml /mnt/sdcard/b/01pre/

   exit

   exit

5. Connect the device to a PC via USB, and mount it as a mass storage device.
6. On the PC, copy the 01pre directory as 01 - the 01pre directory will serve as a second backup (on the SD card) of the original config file. I also copied the files to my PC to serve as a remote backup.
7. Edit the blur_services_config.xml file in 01 using your favourite text editor (see specific changes below).
8. After saving the file, disconnect the phone from the PC.
9. Launch Terminal Emulator.
10. Execute the following commands to switch to the root user context, create a local backup of the config file, and copy it to the SD card:

     

    su

    cd /data/data/com.motorola.blur.service.blur/shared_prefs

    cp /mnt/sdcard/b/01pre/cp blur_services_config.xml ./

    exit

    exit

11. Re-enable cellular data connectivity and wireless networking.
12. If your wireless connection is configured to use a proxy, add 127.0.0.1 to the list of destinations that should not be accessed through the proxy (see HTTP Proxies and Loopback Addresses for a discussion of the reasons why).
13. If you wish, use the steps at the end of this article to verify that connectivity to Motorola is no longer occurring.

These are the specific changes I made to the file on my phone:

1. Replaced all of the following host names with 127.0.0.1^[3]:
   • jabber-cloud112-blur.svcmot.com (4 occurrences)
   • master-blur.svcmot.com
   • um.svcmot.com
   • ws-cloud112-blur.svcmot.com (4 occurrences)
   • www.motorola.com
2. Changed the blur.service.sync.engine.backoffSecs values from 10,60,120,300,600,1800,3600,7200 to 10,60,120,300,600,21600,43200,86400 in an attempt to cause the software to use less battery power trying to connect to Motorola over and over.
3. Changed the blur.service.checkin.log_level value from INFO to ASSERT in an attempt to cause the software to use less battery power by only collecting events of maximum severity.^[4]
4. Changed the blur.service.checkin.event_tags value from BLUR_APP_STATS, BLUR_APP_USAGE, BROWSER_TIME_LANDSCAPE, BROWSER_TIME_PORTRAIT, CHECKIN_FAILURE, CHECKIN_SUCCESS, DEVICE_PROPERTIES, DEVICE_TIME, MOT_APP_STATS, MOT_BRW_STATS_L1, MOT_BRW_STATS_L2, MOT_BRW_STATS_L3, MOT_CA_LOC, MOT_CA_STATS_L1, MOT_CA_STATS_L2, MOT_CA_STATS_L3, MOT_CA_STATS_L4, MOT_CA_STATS_L5, MOT_CA_STATS_L6, MOT_CALL_STATS_L2, MOT_CONTACTS_STATS_L2, MOT_DEVICE_ACCUM_STATS, MOT_DEVICE_KPI_L1, MOT_DEVICE_KPI_L2, MOT_DEVICE_STATS, MOT_DEVICE_STATS_KBD, MOT_DEVICE_STATS_L1, MOT_DEVICE_STATS_L2, MOT_DEVICE_STATS_MM, MOT_HOME_STATS_L2, MOT_MEDIA_STATS_L1, MOT_MEDIA_STATS_L2, MOT_METER_READER_POWER_DETAIL, MOT_METER_READER_POWER_TOTAL, MOT_MSG_STATS_L1, MOT_MSG_STATS_L2, MOT_MSG_STATS_L3, MOT_MSG_STATS_L4, DEV_ATTRIBS to DEVICE_TIME, in an attempt to save battery power by not collecting a bunch of statistics. I left one (mostly harmless?) tag in there, because I wasn't sure if having an empty field here would cause problems.
5. Changed the blur.service.checkin.tags value from BlurServiceMother, cUs, DevicePushListener, DevicePushListener, DeviceReconnectManager, DownloadActivity, global frequency, MediaMule, PhotoUploadReqWS, PowerProfileToggler, SyncActivityLog, SyncDataListener, Updater, WSBase, XMPPConnectionManager to Updater, for the same reason.

Depending on how much of the configuration is actually obeyed, removing the other tags will hopefully minimize the data sent to Motorola in the event that the phone somehow rediscovers the real server names.

I'm very reluctant to use this kind of workaround, because I suspect that it will result in things like log files that increase in size continuously because they're never uploaded, but better to have that happen than to have the data be sent to Motorola.

Effects and side-effects

The changes above do appear to prevent all connectivity to the Blur web services. Of course, several features of the phone depend on Blur. Here's what I've tested and found to work (or not):

• ActiveSync still works for mail, calendar, contacts, and device policy, although I believe it operates in a fallback mode where it polls the ActiveSync server instead of receiving so-called "push" updates to mail, calendar, and contacts. This may cause some delay before e.g. new messages appear on the phone. However, because this workaround involves rooting the phone, your employer may prohibit the use of ActiveSync from it.
• IMAP connectivity still works. However, I like K-9 Mail enough that I'm going to stick with it now instead of going back to the default client.
• GMail contacts are still synced.
• The built-in social networking clients no longer sync content in either direction, although they will continue to display content that was downloaded before the configuration change. They do not display any indication that there are connectivity problems, even when attempting to post status updates (which silently fail).
• The built-in RSS reader no longer downloads content, although it will continue to display content downloaded before the configuration change.

This is not an exhaustive list, as I haven't tested all of the features on the phone. There may very well be other consequences to making these changes, and some of them may not appear immediately afterward.

Question and answer

This is my attempt to cover some of the questions I've received in email as well as seen discussed elsewhere.

Is this Microsoft's fault in some way, because you mentioned ActiveSync?

No. I discovered the way my phone was behaving while I was testing some ActiveSync functionality, but ActiveSync wasn't responsible for the data transmission to Motorola. All of the same data would be sent to Motorola (with the exception of the ActiveSync configuration, of course) even if ActiveSync had never been configured on the phone.

Can I block this traffic by using a HOSTS file or other workaround on the device?

I don't know. You might be able to, but this might just cause the device to accumulate so much queued data that it causes other problems. Doing so would require root access, in which case you might as well install a clean build of Android. I get really nervous about workarounds like spoofed HOSTS files entries as anything other than a short-term approach to addressing problems with computers. Yes, it is technically possible to do this - see Hack/workaround for preventing connectivity to the Blur web service (on rooted devices only). However, I don't recommend it, because it's very difficult to predict the long-term consequences, and it involves voiding the warranty on your phone.

On (some?) newer Motorola phones, there are configurable options (in the main system settings under Privacy) that allow some control over this. I have not seen or tested these myself.

The actual Motorola software that does the upload is non-removable, at least on my Droid X2. The only way I know of for sure to remove it is to install a different build of Android (e.g. CyanogenMod or ParanoidAndroid), which I don't recommend except for advanced users as it will void your warranty. Of course, you could root the phone and then have permission to remove all of the Motorola packages, but I think this would brick the device.

Have you considered checking to see if the system sends different data depending on how it's connected to the internet (e.g. wifi versus cellular)?

Yes - I was already considering this when I posted the article, and I've had several interesting email discussions with other people since then about ways to test this. I did some basic tests, and so far have not seen any difference in behaviour.

Steps to reproduce - HTTP/HTTPS data capture

There are a number of approaches that can be used to reproduce the results in this article. This is the method that I used. Of course, the same testing can be performed in order to validate that non-Motorola devices are or are not behaving this way.

Important: I strongly recommend that you do not modify in any way the data your phone sends to Motorola. I also strongly recommend that you do not actively probe, scan, or test in any way the Blur web service. The instructions on this page are intended to provide a means of passively observing the traffic to Motorola in order to understand what your phone may be doing without your knowledge or consent.

1. Connect a wireless access point to a PC which has at least two NICs.
2. Use Windows Internet Connection Sharing to give internet access to the wireless AP and its clients.
3. Set up an intercepting proxy on the PC. I used Burp Suite Professional for the first part of my testing, then switched to OWASP ZAP (which is free) for the rest, since I used a personal system for that phase. Make sure the proxy is accessible on at least one non-loopback address so that other devices can proxy through it.^[1]
4. Configure a Motorola Android device to connect to the wireless AP, and to use the intercepting proxy for their web traffic (in the properties for that wireless connection).
5. Install the root signing certificate for the intercepting proxy on the Motorola Android device. This allows the intercepting proxy to view HTTPS traffic as well as unencrypted HTTP.
6. Power the Motorola Android device off, then back on. This seems to be necessary to cause all applications to recognize the new trusted certificate, and will also let you intercept the oAuth negotiation with Motorola./li>
7. Configure and use anything in the Account section of the device.
8. Use the built-in Social Networking application.
9. Take a picture and use the Share function to upload it to one or more photo-sharing services.
10. Leave the device on for long enough that it sends other system data to Motorola automatically.

Steps to reproduce - check-in data decompression

If you'd like to decompress one of these gzipped data packages, there are also a number of approaches available, but this is the one I used:

1. Export the raw (binary) request from your intercepting proxy's proxy history. In ZAP, right-click on the history entry and choose Save Raw -> Request -> Body. In Burp Suite, right-click on the history entry and choose Save Item, then uncheck the Base64-encode requests and responses box before saving. Note: you cannot use the bulk export feature of either tool for this step to work - both of them have a quirk in which exporting individual requests preserves binary data, but exporting in bulk corrupts binary data by converting a number of values to 0x3F (maybe it's some Java library that does that when exporting as ASCII?).
2. Open the exported data in a hex editor (I use WinHex). Remove everything up to the first 0x1F8B in the file. See example screenshot below.
3. Save the modified version (I added a .gz extension for clarity). See example screenshot below.
4. Decompress the resulting file using e.g. the Linux gzip -d command, or e.g. 7-zip.
5. Open the decompressed file in a text editor that correctly interprets Unix-style line breaks (I used Notepad++, partly because it shows unprintable characters in a useful way, and there is some binary data mixed in with the text in these files).
6. Examine the data your phone is sending to Motorola.

 

Steps to reproduce - XMPP communication channel

This section requires more technical skill and time to replicate than the other two. It assumes that you have access to a Linux system that is set up with two network interfaces and which can be easily configured to forward all network traffic from the first interface to the second using iptables. If you have a system that is set up to run Mallory successfully already (even though you won't be using Mallory itself here), that would be ideal. If you are technically-inclined and interested in building such a system, see the Multipurpose Man-in-the-Middle VM article for instructions, including detailed steps for this specific XMPP-interception task.

1. Generate an SSL server certificate and private key (in PEM format) with the common name of *.svcmot.com. I made all of the elements of my forged cert match the real one as closely as possible, but I don't know how important this is other than the common name.
2. Load the CA cert you signed the *.svcmot.com cert with onto your Motorola Android device. Again, I used a CA cert that matched the human-readable elements of the one used by the real server, but I don't know how important that is in this specific case.
3. You may need to explicitly install the forged *.svcmot.com cert onto your Motorola Android device as well.
4. Run the shell script from the XMPPPeek page to cause all traffic from the internal interface to be forwarded to the external interface, with the exception of traffic with a destination port of 5222, which should be routed to the port that XMPPPeek will be listening on.
5. Start XMPPPeek and wait for your phone to connect.

I used a VirtualBox VM with a virtual NIC which was connected for internet access, and a USB NIC which I connected to an old wireless access point. So my phone connected to that AP, which connected through the man-in-the-middle system, which connected to the actual internet connection. I configured the phone to also proxy web traffic through OWASP ZAP so that I could match up the XMPP traffic with its HTTP and HTTPS counterparts.

Related Articles:
XMPPPeek
Multipurpose Man-in-the-Middle VM

Last updated: 28 July 2013

You have Javascript disabled in your browser. This website will look a bit nicer if you turn it back on.

Copyright 2009-2013 Ben Lincoln, except where explicitly noted.

Copyright Information - Privacy Policy - Download Policy - Advertising Policy