Ingeniería inversa windows mobile live search Protocolo de reconocimiento de ubicación de CellID (yikes)

Question

No estaba seguro de cómo formular la pregunta, así que me disculpo si el título es engañoso. Además, es posible que desee tomar un café y tomar asiento para este ... Es largo.

Básicamente, estoy tratando de aplicar ingeniería inversa al protocolo utilizado por la aplicación Windows Mobile Live Search para obtener la ubicación basada en el ID de celda. Antes de continuar, conozco otros servicios de código abierto (como OpenCellID), pero esto es más por el bien de la educación y un poco por la redundancia.

Según los paquetes que capturé, se realiza una solicitud POST a ...

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

... con algunos encabezados específicos (agente, longitud de contenido, etc.) y sin cuerpo. Una vez que esto pasa, el servidor envía una respuesta de 100 Continuar. En este punto, la aplicación envía estos datos (corté el encabezado del paquete):

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

Y recibe esto en respuesta (paquetes y encabezados de respuesta HTTP cortados):

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

Ahora, esto es lo que he determinado hasta ahora:

• Todas las cadenas se anteponen con una byte que es el equivalente decimal de su longitud.

• Parece que hay tres diferentes yesos que se utilizan en todo el solicitud y respuesta. Ellos aparecen como un byte antes del byte de longitud. He concluido que los tres tipos trazar como sigue:

  1. 0x06 - elemento padre (subsiguiente los valores son hijos, cerrados con 0x00)
  2. 0x07 - cadena
  3. 0x08 - int?

Con base en estas determinaciones, así es como se ve la solicitud y la respuesta de una manera más legible (los valores entre paréntesis indican la longitud y los valores entre paréntesis indican una conversión):

\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

y ..

\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

Mi análisis parece funcionar bastante bien, excepto por algunas cosas:

1. Los 0x01s me confunden ... Al principio pensé que eran algunos tipo de elemento de nivel base terminadores pero no estoy seguro.
2. No estoy seguro de que el encabezado de 7 bytes sea, de hecho, un encabezado de siete bytes. yo me pregunto si son quizás 4 bytes y que los tres 0x00 restantes son de alguna otra importancia.
3. Los 0x00 finales. Por qué es eso solo hay uno en la solicitud pero dos en la respuesta?
4. El elenco de tipo 8 mencionado anteriormente ... Parece que no puedo entender cómo esos Los valores están siendo codificados. yo añadí comentarios a esas líneas con lo que el los valores deberían corresponder a.

Cualquier consejo sobre estos cuatro puntos será muy apreciado.

Y sí, estos paquetes fueron capturados en Watertown, MA. :)

Answer 1

No he leído todo el desglose, pero es posible que desee ver esto proyecto de código que parece haber roto la API de Google Celltower a la ubicación. Parece que está escupiendo la ID de la torre celular en sus componentes, como lo que se requiere para la solicitud de búsqueda en vivo.

Tal vez eso te ayude un poco.