Обратный инжиниринг Windows Mobile Live Search Протокол распознавания местоположения CellID (Yikes) - PullRequest
Новая
       16

Обратный инжиниринг Windows Mobile Live Search Протокол распознавания местоположения CellID (Yikes)

0 голосов
/ 19 марта 2009

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

По сути, я пытаюсь реконструировать протокол, используемый приложением Windows Mobile Live Search для определения местоположения на основе cellID. Прежде чем продолжить, я знаю о других сервисах с открытым исходным кодом (таких как 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 - int?

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

\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 байта и что три оставшихся 0x00s другого значения.
  3. Трейлинг 0x00s. Почему это так есть только один по запросу, но два на ответ?
  4. Тип 8, упомянутый выше ... Я не могу понять, как эти значения кодируются. я добавил комментарии к этим строкам с тем, что значения должны соответствовать.

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

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

1 Ответ

0 голосов
/ 29 марта 2009

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

Может быть, это вам немного поможет.

...