Reverse engineering windows mobile live search CellID location awareness protocol (yikes)...

Question

I wasn't sure of how to form the question so I apologize if the title is misleading. Additionally, you may want to get some coffee and take a seat for this one ... It's long.

Basically, I'm trying to reverse engineer the protocol used by the Windows Mobile Live Search application to get location based on cellID. Before I go on, I am aware of other open source services (such as OpenCellID) but this is more for the sake of education and a bit for redundancy.

According to the packets I captured, a POST request is made to ...

mobile.search.live.com/positionlookupservice_1/service.aspx

... with a few specific headers (agent, content-length, etc) and no body. Once this goes through, the server sends back a 100-Continue response. At this point, the application submits this data (I chopped off the packet header):

                  00 00 00 01 00 00 00 05 55 54         ........UT
46 2d 38 05 65 6e 2d 55 53 05 65 6e 2d 55 53 01   F-8.en-US.en-US.
06 44 65 76 69 63 65 05 64 75 6d 6d 79 01 06 02   .Device.dummy...
50 4c 08 0e 52 65 76 65 72 73 65 47 65 6f 63 6f   PL..ReverseGeoco
64 65 01 07 0b 47 50 53 43 68 69 70 49 6e 66 6f   de...GPSChipInfo
01 20 06 09 43 65 6c 6c 54 6f 77 65 72 06 03 43   . ..CellTower..C
47 49 08 03 4d 43 43 b6 02 07 03 4d 4e 43 03 34   GI..MCC....MNC.4
31 30 08 03 4c 41 43 cf 36 08 02 43 49 fd 01 00   10..LAC.6..CI...
00 00 00                                          ...

And receives this in response (packet and HTTP response headers chopped):

         00 00 00 01 00 00 00 00 01 06 02 50 4c      ...........PL
06 08 4c 6f 63 61 6c 69 74 79 06 08 4c 6f 63 61   ..Locality..Loca
74 69 6f 6e 07 03 4c 61 74 09 34 32 2e 33 37 35   tion..Lat.42.375
36 32 31 07 04 4c 6f 6e 67 0a 2d 37 31 2e 31 35   621..Long.-71.15
38 39 33 38 00 07 06 52 61 64 69 75 73 09 32 30   8938...Radius.20
30 30 2e 30 30 30 30 00 42 07 0c 4c 6f 63 61 6c   00.0000.B..Local
69 74 79 4e 61 6d 65 09 57 61 74 65 72 74 6f 77   ityName.Watertow
6e 07 16 41 64 6d 69 6e 69 73 74 72 61 74 69 76   n..Administrativ
65 41 72 65 61 4e 61 6d 65 0d 4d 61 73 73 61 63   eAreaName.Massac
68 75 73 65 74 74 73 07 10 50 6f 73 74 61 6c 43   husetts..PostalC
6f 64 65 4e 75 6d 62 65 72 05 30 32 34 37 32 07   odeNumber.02472.
0b 43 6f 75 6e 74 72 79 4e 61 6d 65 0d 55 6e 69   .CountryName.Uni
74 65 64 20 53 74 61 74 65 73 00 00 00            ted States...

Now, here is what I've determined so far:

• All strings are prepended with one byte that is the decimal equivalent of their length.

• There seem to be three different casts that are used throughout the request and response. They show up as one byte before the length byte. I've concluded that the three types map out as follows:

  1. 0x06 - parent element (subsequent values are children, closed with 0x00)
  2. 0x07 - string
  3. 0x08 - int?

Based on these determinations, here is what the request and response look like in a more readable manner (values surrounded by brackets denote length and values surrounded by parenthesis denote a cast):

\0x00\0x00\0x00\0x01\0x00\0x00\0x00
[5]UTF-8
[5]en-US
[5]en-US
\0x01
[6]Device
[5]dummy
\0x01
(6)[2]PL
  (8)[14]ReverseGeocode\0x01
  (7)[11]GPSChipInfo[1]\0x20
  (6)[9]CellTower
    (6)[3]CGI
      (8)[3]MCC\0xB6\0x02         //310
      (7)[3]MNC[3]410             //410
      (8)[3]LAC\0xCF\0x36         //6991
      (8)[2]CI\0xFD\0x01          //259
    \0x00
  \0x00
\0x00
\0x00

and..

\0x00\0x00\0x00\0x01\0x00\0x00\0x00
\0x00\0x01
(6)[2]PL
  (6)[8]Locality
    (6)[8]Location
      (7)[3]Lat[9]42.375621
      (7)[4]Long[10]-71.158938
    \0x00
    (7)[6]Radius[9]2000.0000
  \0x00
  \0x42     //"B" ... Has to do with GSM
  (7)[12]LocalityName[9]Watertown
  (7)[22]AdministrativeAreaName[13]Massachusetts
  (7)[16]PostalCodeNumber[5]02472
  (7)[11]CountryName[13]United States
\0x00
\0x00\0x00

My analysis seems to work out pretty well except for a few things:

1. The 0x01s throughout confuse me ... At first I thought they were some sort of base level element terminators but I'm not certain.
2. I'm not sure the 7-byte header is, in fact, a seven byte header. I wonder if it's maybe 4 bytes and that the three remaining 0x00s are of some other significance.
3. The trailing 0x00s. Why is it that there is only one on the request but two on the response?
4. The type 8 cast mentioned above ... I can't seem to figure out how those values are being encoded. I added comments to those lines with what the values should correspond to.

Any advice on these four points will be greatly appreciated.

And yes, these packets were captured in Watertown, MA. :)

Answer 1

I haven't read all your breakdown, but you may like to look at this codeproject which seems to have broken the google celltower to location API. It looks like it's spitting out the celltower ID into it's components like what is required for the live search request.

Maybe that will help you a bit.