Reverse engineering de Windows Mobile Live Search, protocole de détection de localisation par CellID

Question

Je ne savais pas trop comment formuler la question, alors je m'excuse si le titre est trompeur. De plus, vous voudrez peut-être prendre un café et vous asseoir pour celui-ci ... C'est long.

En gros, j'essaie de procéder à une ingénierie inverse du protocole utilisé par l'application Windows Mobile Live Search pour obtenir un emplacement basé sur cellID. Avant de continuer, je connais d’autres services Open Source (tels que OpenCellID), mais c’est plus pour l’éducation et un peu pour la redondance.

En fonction des paquets que j'ai capturés, une demande POST est adressée à ...

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

... avec quelques en-têtes spécifiques (agent, longueur du contenu, etc.) et aucun corps. Une fois que cela est terminé, le serveur renvoie une réponse 100-Continue. À ce stade, l’application soumet ces données (j’ai coupé l’en-tête du paquet):

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

Et reçoit ceci en réponse (en-têtes de réponse de paquet et HTTP hachés):

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

Maintenant, voici ce que j'ai déterminé jusqu'à présent:

• Toutes les chaînes sont précédées d'une chaîne octet qui est l'équivalent décimal de leur longueur.

• Il semble y avoir trois différents les moulages qui sont utilisés tout au long de la demande et réponse. Ils se présentent comme un octet avant l'octet de longueur. J'ai conclu que les trois types cartographier comme suit:

  1. 0x06 - élément parent (ultérieur les valeurs sont enfants, fermées par 0x00)
  2. 0x07 - chaîne
  3. 0x08 - int?

Sur la base de ces déterminations, voici à quoi ressemblent la demande et la réponse de manière plus lisible (les valeurs entourées par des crochets indiquent la longueur et les valeurs entourées par des parenthèses désignent une conversion):

\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

et ..

\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

Mon analyse semble assez bien fonctionner, sauf pour quelques points:

1. Les 0x01 me troublent tout au long ... Au début, je pensais qu'ils étaient certains sorte d'élément de niveau de base terminateurs, mais je ne suis pas certain.
2. Je ne suis pas sûr que l'en-tête de 7 octets soit, en fait, un en-tête de sept octets. je me demande si c'est peut-être 4 octets et que les trois 0x00 restants sont d'une autre signification.
3. Les 0x00 de fin. Qu'est-ce que c'est il n'y en a qu'un sur la demande mais deux sur la réponse?
4. La distribution de type 8 mentionnée ci-dessus ... Je n'arrive pas à comprendre comment les valeurs sont encodées. J'ai ajouté commentaires à ces lignes avec ce que le les valeurs doivent correspondre à.

Tous les conseils sur ces quatre points seront grandement appréciés.

Et oui, ces paquets ont été capturés à Watertown, dans le Massachusetts. :)

Answer 1

Je n'ai pas lu toute votre ventilation, mais vous voudrez peut-être consulter this codeproject qui semble avoir cassé l'API Google CellTower to Location. On dirait qu’il crache l’identifiant celltower dans ses composants, comme ce qui est requis pour la demande de recherche en direct.

Peut-être que cela vous aidera un peu.