I love my Motorola, but I think she’s cheating on me

So, I got a new Motorola Q Smartphone. And, of course, the first thing anyone does when they get a new networked device is scan the sucker. I don’t expect any ports to be open (besides the synching ports), so I go for the UDP ports first. The stack on the Motorola is UDP-scanning friendly and I get:

42/udp open|filtered nameserver
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
135/udp open|filtered msrpc
136/udp open|filtered profile
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
445/udp open|filtered microsoft-ds
520/udp open|filtered route
1034/udp open|filtered activesync-notify
1434/udp open|filtered ms-sql-m
2948/udp open|filtered wap-push

Interesting. Now, I just need to generate some test cases and I can start fuzzing those services. I now scan to see what’s open on the TCP side. I honestly don’t expect anything. I start with ports 1-10000. And….port 8000 is open????? That’s a wierd port to be open, so I telnet in to the port, and I get a 4-byte packet of \x00\x00\x00\x69 followed by a packet with the following strings:

“”"
Motorola Test Command#11000
Motorola MCU Data Logger#11006
Motorola DSP Logger#11007
QC Interface#11008
“”"

Hmmmm, another bit of interesting news. And those strings (minus the pound digits) return no info via Google. Further, what are those #[DIGIT] things. And, what sort of logging is being done? For kicks, I tell nmap to scan ports 11,000-11008 on both TCP and UDP. All the UDP ports are dead…but, port 11008/TCP is open. Nice. I now scan all ports through 65535 and I note that port 13000 is also open. So, to recap. I have 13 UDP ports to fuzz and 3 TCP ports to fuzz. I don’t hold much hope for port 8000. It appears to be a poor man’s rpc or something…telling me where other services might be living. Connect to port 8000 and it just dumps it’s data and immediately FINs. 11008 and 13000 don’t respond to the nudging that I’ve been sending down the pipe thus far. I’ve got a little homemade program that I’m running (a stupid little program) which just generates rand() bytes of rand() composition and sends it down the line and waits 6 seconds for a response. Once I can get a single response, I can just run permutations of the successful-response packet in hopes of a second response, ad infinitum….blackbox testing at it’s worst. So, now I’m out of the loop and just waiting for my program to find something and send me an email. I think I’ve hit refresh on my email client 75 times this morning. I’m too impatient to be a decent fuzzer guy. It’s been running for 11 hours! I should have some data by now! … Somewhere in cyberspace, Johnny Disco is laughing at me.

What would be nice (hint hint) would be a pointer to some protocol specs ;) In case anyone has forgotten, my email address is dmitry.chan@gmail.com

!Dmitry

Share
  • http://xenomuta.blogspot.com XenoMuta

    I really wish you luck, still, you have inspired me to go dive onto the internals of my own cellphone. Does anyone knows if it has a jtag interface or something? Maybe the firmware image has further goodies you might be after.

  • Herbert Van Winkle

    UDP has a high rate of false positives when scanning for open ports so be careful.

    Remote code execution on a phone like this would be nice.

    Good luck.

  • kokanin

    the preceding packet is a dword consisting of the length of the following data in little endian order + a NULL BYTE, assuming that the “”” bis are not part of the packet and merely on this page as seperators.

  • elixx

    Wow… I just got one of these phones a couple of days ago, fire up my RSS reader today… and find this article!
    Keep up the research! I’d love to see what develops out of this…

  • The_NetLockSmith

    Now I feel stupid for not trying this myself. And for thinking that with Bluetooth off, I was mostly safe.

    Anyway, I googled “Motorola Test Command” and it did come up with something:

    Motorola Bible – Test Mode Commands
    http://www.everything2.com/index.pl?node_id=800717

    I don’t know if these all apply to the Q and are accessible by simple telnet. Time to experiment and see.

  • Beezlewaxin

    These ports are for using Motorola phone service tools (RSD Lite, RSD General, MSU, RadioComm). The QC Interface is for bypassing the Motorola phone interface, and talking directly with the QUALCOMM CDMA chipset. As far as I know, none of the hundreds of programs that communicate with the QUALCOMM chipset work over IP. They talk using serial COMx ports only.

    The MotoQ is (so far) the only CDMA phone that uses this type of interface, and it presented some unique challenges. Eventually the mobile-files forum user Ravenii posted a method using a software program called “HW Virtual Serial Port 2.5.10″, which is freeware, and its description is best copied directly from publisher’s website:

    HW VSP
    Free Virtual Serial Port to connect any TCP/IP Terminal server to your Windows as a virtual serial port (e.g. COM 7). Produced by http://www.HW-group.com.

    Download and install this software, then create a new Virtual Serial Port, using the DHCP server ip address (for your ActiveSync connection, your phone is your DHCP server, and your computer is the client ip) for the remote server, and port 13000 for the port. This will create a COMx port, that can be used with any software that works with CDMA phones. Most motorola software will not work with this virtual port, because those software use the serial P2K interface, which this is not. CDMA Workshop from http://www.cdma-ware.com has a 3wk trial, and can be used to upload a PRL to your Q, among other things.

    A very good site with more information is howardforums.com.

    Beezlewaxin