Reverse engineering windows mobile live search CellID location awareness protocol (yikes)...
- by Jean-Charles
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:
0x06 - parent element (subsequent
values are children, closed with 0x00)
0x07 - string
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:
The 0x01s throughout confuse me ...
At first I thought they were some
sort of base level element
terminators but I'm not certain.
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.
The trailing 0x00s. Why is it that
there is only one on the request but
two on the response?
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. :)
