Реверс-инжиниринг Windows Mobile Live Search Протокол определения местоположения CellID (да)

Question

Я не был уверен, как сформулировать вопрос, поэтому прошу прощения, если название вводит в заблуждение.Кроме того, вы можете захотеть выпить кофе и присесть за этим...Это долго.

По сути, я пытаюсь перепроектировать протокол, используемый приложением Windows Mobile Live Search для определения местоположения на основе идентификатора ячейки.Прежде чем продолжить, я знаю о других сервисах с открытым исходным кодом (таких как OpenCellID), но это больше ради образования и немного для дублирования.

Согласно захваченным мною пакетам делается POST-запрос на...

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

...с несколькими конкретными заголовками (агент, длина контента и т. д.) и без тела.Как только это произойдет, сервер отправит обратно ответ 100-Continue.В этот момент приложение отправляет эти данные (я отрубил заголовок пакета):

                  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                                          ...

И получает в ответ вот это (заголовки пакета и HTTP-ответа обрезаны):

         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...

Теперь вот что я определил на данный момент:

• Все строки приготовлены одним байтом, который является десятичным эквивалентом их длины.

• Похоже, есть три разных состава, которые используются в течение всего запроса и ответа.Они появляются как один байт перед байтом длины.Я пришел к выводу, что три типа отображаются следующим образом:

  1. 0x06 - родительский элемент (последующими значениями являются дети, закрытые с 0x00)
  2. 0x07 — строка
  3. 0x08 — целое число?

Основываясь на этих определениях, вот как запрос и ответ выглядят в более читабельной форме (значения в скобках обозначают длину, а значения в круглых скобках обозначают приведение):

\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

и..

\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

Мой анализ, кажется, работает довольно хорошо, за исключением нескольких моментов:

1. Меня смущают цифры 0x01...Сначала я думал, что они были какими -то терминаторами элемента базового уровня, но я не уверен.
2. Я не уверен, что 7-байтовый заголовок на самом деле является семью байтовым заголовком.Интересно, может ли это 4 байта и что три оставшихся 0x00 имеют какое -то другое значение.
3. Завершающие 0x00.Почему по запросу есть только один, но два в ответе?
4. Литой тип 8, упомянутый выше...Кажется, я не могу понять, как эти значения кодируются.Я добавил комментарии к этим строкам с тем, какие значения должен соответствуют.

Мы будем очень признательны за любые советы по этим четырем пунктам.

И да, эти пакеты были перехвачены в Уотертауне, Массачусетс.:)

Answer 1

Я не читал всю вашу разбивку, но вы можете посмотреть этот codeproject, который, похоже, сломал API сотовой башни Google для определения местоположения.Похоже, он выплевывает идентификатор сотовой вышки в свои компоненты, как то, что требуется для запроса живого поиска.

Возможно, это вам немного поможет.