janelas de engenharia reversa de pesquisa ao vivo protocolo de reconhecimento de local CellID móvel (yikes)

Question

Eu não tinha certeza de como formar a questão por isso peço desculpas se o título é enganador. Além disso, você pode querer tomar um café e tomar um assento para este ... É muito tempo.

Basicamente, eu estou tentando fazer engenharia reversa do protocolo usado pelo aplicativo Windows Mobile Live Search para obter localização com base no CellID. Antes de eu ir, eu estou ciente de outros serviços de código aberto (como OpenCellID), mas isso é mais por uma questão de educação e um pouco para a redundância.

De acordo com os pacotes I capturados, um pedido POST é feita para ...

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

... com alguns cabeçalhos específicos (agente, o conteúdo de comprimento, etc) e nenhum corpo. Uma vez que este passa, o servidor envia de volta uma resposta 100-Continue. Neste ponto, os submete uma aplicação esses dados (I cortou o cabeçalho do pacote):

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

E recebe este em resposta (cabeçalhos dos pacotes e HTTP de resposta picado):

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

Agora, aqui é o que eu determinado até agora:

• Todas as cordas são precedidas por um byte que é o equivalente decimal do seu comprimento.

• Parece haver três diferentes moldes que são utilizados em todo o pedido e resposta. Eles aparecem como um byte antes do byte de comprimento. Eu já concluiu que os três tipos mapear as seguintes:

  1. 0x06 - elemento pai (posterior Os valores são crianças, fechado com 0x00)
  2. 0x07 - corda
  3. 0x08 -? Int

Com base nestas determinações, é aqui que a solicitação e resposta de olhar como de uma forma mais legível (valores entre colchetes comprimento denote e valores rodeado por parêntesis denotam um elenco):

\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

e ..

\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

A minha análise parece funcionar muito bem, exceto para algumas coisas:

1. Os 0x01s todo confundem-me ... No começo eu pensei que eles eram alguns tipo de elemento de nível básico terminadores, mas eu não estou certo.
2. Não sei o cabeçalho de 7 bytes é, de facto, um byte cabeçalho sete. Eu pergunto se é talvez 4 bytes e que os três restantes são 0x00s de algum outro significado.
3. Os 0x00s à direita. Por que é isso há apenas uma no pedido, mas dois na resposta?
4. O elenco tipo 8 mencionado acima ... Eu não consigo descobrir como aqueles Os valores estão a ser codificado. Eu adicionei comenta a essas linhas com o que a valores deve correspondem a.

Qualquer conselhos sobre estes quatro pontos serão muito apreciados.

E sim, estes pacotes foram capturados em Watertown, MA. :)

Answer 1

Eu não li todo o seu colapso, mas você pode gostar de olhar para este codeproject que parece ter quebrado o google celltower a localização API. Parece que de cuspir fora o ID celltower em seus componentes, como o que é necessário para a solicitação de pesquisa ao vivo.

Talvez isso irá ajudá-lo um pouco.