Reverse engineering windows mobile live live Protocollo di consapevolezza della posizione di CellID (yikes)

Question

Non ero sicuro di come formulare la domanda, quindi mi scuso se il titolo è fuorviante. Inoltre, potresti voler prendere un caffè e sederti per questo ... È lungo.

Fondamentalmente, sto cercando di decodificare il protocollo utilizzato dall'applicazione Windows Mobile Live Search per ottenere la posizione in base a cellID. Prima di continuare, sono a conoscenza di altri servizi open source (come OpenCellID), ma questo è più per motivi di educazione e un po 'di ridondanza.

Secondo i pacchetti che ho catturato, viene fatta una richiesta POST a ...

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

... con alcune intestazioni specifiche (agente, lunghezza contenuto, ecc.) e nessun corpo. Al termine, il server restituisce una risposta 100-Continua. A questo punto, l'applicazione invia questi dati (ho eliminato l'intestazione del pacchetto):

                  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 riceve questo in risposta (pacchetti e intestazioni di risposta HTTP troncate):

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

Ora, ecco cosa ho deciso finora:

• Tutte le stringhe sono anteposte a una byte che è l'equivalente decimale della loro lunghezza.

• Sembra che ci siano tre differenti cast che vengono utilizzati in tutto il richiesta e risposta. Si presentano come un byte prima del byte di lunghezza. Ho concluso che i tre tipi mappare come segue:

  1. 0x06 - elemento padre (successivo i valori sono figli, chiusi con 0x00)
  2. 0x07 - stringa
  3. 0x08 - int?

Sulla base di queste determinazioni, ecco come appaiono la richiesta e la risposta in un modo più leggibile (i valori racchiusi tra parentesi indicano la lunghezza e i valori racchiusi tra parentesi indicano un 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

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

La mia analisi sembra funzionare abbastanza bene, tranne per alcune cose:

1. Gli 0x01 in tutto mi confondono ... All'inizio ho pensato che fossero alcuni sorta di elemento di livello base terminatori ma non ne sono sicuro.
2. Non sono sicuro che l'intestazione a 7 byte sia, in effetti, un'intestazione di sette byte. io chiedo se è forse 4 byte e che i tre rimanenti 0x00 sono di qualche altro significato.
3. Gli 0x00 finali. Perché è quello? ce n'è solo uno nella richiesta ma due sulla risposta?
4. Il cast di tipo 8 menzionato sopra ... Non riesco a capire come quelli i valori vengono codificati. Ho aggiunto commenti a quelle righe con ciò che il i valori dovrebbero corrispondere a.

Qualsiasi consiglio su questi quattro punti sarà molto apprezzato.

E sì, questi pacchetti sono stati catturati a Watertown, MA. :)

Answer 1

Non ho letto tutto il tuo guasto, ma potresti voler guardare questo codeproject che sembra aver spezzato Google Celltower nell'API di localizzazione. Sembra che sputi l'ID celltower nei suoi componenti come quello richiesto per la richiesta di ricerca live.

Forse questo ti aiuterà un po '.