lunes, 23 de septiembre de 2013

Exif y geopisicionamiento

Sábado, 13 de agosto de 2003

Hoy he leido un post de Systemadmin, y me ha vuelto a pasar. Algo que iba a hacer una semana de estas (o mes) y lo publican antes. A si que, a ver si me pongo las pilas para hacerlo cuanto antes...

Septiembre 2014

Hace un año que tendría que haber buscado esto. Posiblemente sea, porque a veces me pasa, que quiero hacer algo y al poco tiempo me encuentro con que alguien ya lo ha hecho. La verdad: tendría que aprender a que me diese igual y hacerlo de todas formas. Claro: así parece que lo he copiado o que también quiero acaparar la atención con ese tema en concreto. Sobretodo los tiros van por ahí cuando esto me sucede. Pero un año...

Por lo tanto, lo que quiero es modificar los datos exif de una imágen. Esos datos se guardan al mismo tiempo que se salva la foto, y los entrega la misma cámara. Ahí se puede ver un montón de información: desde la cámara empleada (Canon, Canon, Canon...) pasando por la apertura del obturador o, incluso, y aquí lo más importante, fecha en la que se sacó la foto, las coordenadas GPS y un montón de datos más. Sí. Y si no se tiene mucho cuidado, sobretodo con los móviles de hoy en día, te puedes encontrar con que estás dando el lugar donde te encuentras sin saberlo. También está la opción contraria: querer dar a entender que estás en un lugar que no es donde estás. Y si no te encuentras en ese lugar, ¿dónde has ido a parar? Ahora en serio. Lo que quería hacer era precisamente esta segunda opción. Cambiar estos datos. En un caso forense puede ser un quebradero de cabeza el análisis de las fotos (descartando después que se pueda descubrir que han sido manipuladas por los rastros que se queden en el sistema de ficheros).

Nos van a hacer falta dos cosas:
  • Una foto que tenga estos datos
  • Un programa que nos permita manipularlos.
Lo primero que voy a hacer va a ser buscar el programita. No voy a negar que quería montarme uno por mi cuenta, pero eso será para dentro de unos pocos años. He encontrado uno que se llama ExifTool. Alguna que otra cosa he conseguido hacer. No con el éxito que esperaba, pero sí lo suficiente como para poderlo enseñar. Si tienes alguna duda de cómo hacerlo funcionar, te puedes pasar por sus FAQs.

Vamos a ver la foto que les hice a los sushis tan buenos que me cociné hace unos pocos años:

Foto original para ver sus metadatos exif: sushi
Foto original para ver sus metadatos exif: sushi

Si ejecutas el programa, verás sus metadatos originales:

Datos exif de la imágen
Datos exif de la imágen

Ahora, queremos cambiar algunos datos. En mi caso, quiero añadirle los datos de geoposicionamiento. Pero no debería de ser ningún problema cambiar los ya existentes. Supongo que sabréis que mi casa se encuentra aquí o (en la versión antigua del maps, aquí). Como los hice en ese punto, quiero que la foto lo diga.

Para hacerlo necesitaré saber primero, cómo le digo al programa qué tengo que poner. En el enlace de antes, con las preguntas frecuentes, me lo dicen. Y también necesito localizar las coordenadas que se corresponden con el lugar donde "hice" las fotos. Por eso tuve que buscar la solución.

Por lo tanto, tenemos las coordenadas: -159.3158771 longitud, y 3.8227357 latitud.

Ahora, queremos introducirlas en nuestra imagen. Y aquí es donde más problemas estoy teniendo. No se muy bien cómo decirle en qué sentido tiene que mirar. Si miráis las instrucciones, te dicen que para el parametro -exif:gpslatitude y -exif:gpslongitude pongas las referencias con -exif:gpslatituderef  y -exif:gpslongituderef. Pero, después, para los mismo parámetros, pero empezando por -xmp en vez de por -exif te dicen que si quieres poner la referencia tendrás que usar los valores positivos o negativos según corresponda (por lo que no hay parámetros gpslongituderef y gpslatituderef). Cosa curiosa que no te diga nada si también usas los números negativos en los parámetros "-exif:".

Ahora toca ejecutar alguno de los parámetros. Antes de nada: machacar la imagen de prueba por la original. La he dejado tan inestable que por un lado dice que la latitud es sur y por otro lado dice que es norte.

Por lo tanto, vamos a escribir en una consola (cmd), en la misma ruta donde se encuentra la herramienta:

"exiftool(-k).exe" -exif:gpslatitude="3.8227357" -exif:gpslatituderef=N -exif:gpslongitude="159.3158771" -exif:gpslongituderef=W "nombre del fichero con su ruta.jpg"

De hecho, esta es la primera vez que lo pruebo del tirón. El resto de las pruebas, las he hecho con los dos grupos (latitud y longitud) por separado. Además, antes de daros el pantallazo, quiero cambiar otro dato más. Vamos a ver... alguno que no me obligue a montar otra pantalla grande... Según las instrucciones, si ejecuto el programa con el parámetro -s me saldrán los nombres de los tags que tendré que utilizar para cambiar los datos.

"exiftool(-k).exe" -s "nombre del fichero.jpg"

Así que, vamos a ver, vamos a ver...

"exiftool(-k).exe" exif:lightvalue="1000" -exif:aperturevalue=300 -exif:lightsource=flash "2011-11-11 22.34.43.jpg"

Y, tenemos el resultado:

Datos exif modificados: geoposicionamiento, fuente de luz...
Datos exif modificados: geoposicionamiento, fuente de luz...
Y aquí lo tenemos, casi todos los datos deseados se han modificado. A excepción del light value (lightValue), los demás han surtido efecto.

Así, si vemos otra vez la foto:

Foto con sus metadatos exif modificados: sushi
Foto con sus metadatos exif modificados: sushi

Así, si cogemos las coordenadas que os he indicado, podremos ver que esta comida tan rica, rica la hice en estas islas que están a aproximadamente a... ¿20.000 kilómetros a ojo de buen cubero?:

Coordenadas actualizadas en los metadatos exif puestas en el Gogle Maps
Coordenadas actualizadas en los metadatos exif puestas en el Gogle Maps
Algo que no he querido probar sería el qué pasaría si intentase cambiar el thumbnail que me dice que tiene la foto. Pero eso ya será otra historia para otro día.

viernes, 20 de septiembre de 2013

Trust no one, user-agent.

Este es uno de esos que lo escribí a medias tiempo ha y creo que va siendo hora de revisarlo bien, terminarlo (si es que hace falta terminarlo) y editarlo bien, dado que el original estaba escrito desde el móvil.

--

Como si fuera Garganta Profunda en esa (para mí) magnífica serie de televisión Expediente X, "no confíe en nadie, agente Mulder", tendríamos que decirle lo mismo a nuestros navegadores.

Se me ha ocurrido todo esto a raíz de un artículo de SbD, y escrito por Juan Garrido, Juanito, @tr1ana.

Seguro que ya os he hablado alguna vez de las CAs. Son las entidades que se encargan de suministrar los certificados digitales. Si alguien ha llegado aquí y no sabe qué es eso, es un fichero que de guarda en un lugar especifico del ordenador y que hace que cuando visitas una página que lo usa, salga el famoso "candado".
Sí, está explicado de una manera muy, muy simple y no muy exacta. No es (¿era?) fácil hacerlo desde el móvil.

¿Y cómo sabemos si es bueno o no? Precisamente porque si está guardado en ese lugar, llamado almacén, es que confiamos en él. Y, si confiamos en él, el sistema no nos alterará de nada sospechoso. Por lo que, si aceptamos uno de estos sin ser conscientes, el hecho de que tu navegador ponga el candado no servirá de nada. Y mucho menos si se acepta que se guarde permanentemente en el almacén. Tengamos en cuenta que normalmente ese almacén suele pertenecer al sistema operativo. Aunque, en ocasiones, un navegador (como por ejemplo Firefox), tiene su propio sistema de almacenamiento y obvia el que tiene el sistema operativo.

Además, a veces, los navegadores, o el propio sistema, preguntan a la CA si su certificado sigue siendo valido. Pongamos un ejemplo: una CA, que en teoría, es seria, se ve comprometida. Una vez se dan cuenta, ésta puede avisar de que lo que ha emitido ya no es válido. Cada navegador reacciona de una forma un otra según los sistemas para preguntar o si le llegan o no las respuestas.

La historia está en que algunos no hacen nada, no avisan ni ponen medios para activar el aviso. Otros, como en el post de Juanito, se puede activar.

Total, que volvemos al principio: la confianza en la CA que ha emitido ese certificado. Porque :¿de qué sirve tener el candado o la "s" al final del http si estamos confiando en alguien en el que no deberíamos confiar? Al fin y al cabo, eso es lo que suele pasar en los MITM (Man In The Middle).

Me faltaría explicar en dos líneas, para el que no lo sepa, que esa entidad emisora/CA es capaz de descifrar aquello para lo que ha sido emitida además de poder hacerlo para todos sus hijos. Una vez más, muy resumido.

¡Y todo esto, por asociación de ideas del post de Triana! De todas formas, si tienes dudas o no has entendido algo, por favor, no tengas reparos en poner un comentario e intentaremos explicarlo lo mejor posible. 

lunes, 16 de septiembre de 2013

Condones para USB

Hoy voy a contar otro que viene de también del correo de la RootedCon: condones para USB.

Recordando la broma que se hizo en la anterior edición, año 2012, del mueblecito para "recargar móviles", nos han enviado este producto tan interesante.

La verdad, es una chorrada como usa casa. Pero, si no hay problemas como que controlen algún tipo de dato para identificar el móvil, funcionaría muy bien.

Para explicarlo un poco rápido y que todo el mundo lo entienda:

los cables que usamos en los ordenadores, independientemente del que sea (USB, red...) suelen estar construidos para que en su interior tengan más cables o, al menos, una serie de conectores pequeños con un propósito determinado. El propósito sería, por ejemplo, enviar datos. O recibirlos. O dar corriente. O evitar interferencias (los cables de red, de los 8 mini-cables que lo forman, la mitad están para evitar precisamente eso, cuyo nombre, en este caso, es diafonía).

¿Qué han hecho estos señores? Han dicho: pues construimos unos cables, en el que hacemos que el pin de datos no exista. Así, no se pueden llevar nada del dispositivo. Lo dicho: es una pequeña chorrada que, a día de hoy sábado (aunque leáis esto el lunes), no tienen existencias. Y las esperan precisamente para el lunes 16 de septiembre (de 2013, por si alguien llega más tarde). Típica cosa que hay que caer en la cuenta antes que cualquiera para tener éxito.

De todas formas, después de haber preparado toda esta parrafada, estoy viendo que los hay que tienen ideas a lo MacGiver: creártelo tu mismo. Dos conectores, puentear los pines correctos... No se. ¿Qué otras ideas se os ocurrirían para evitar las pérdidas de datos en estos dispositivos?

sábado, 14 de septiembre de 2013

Wifi is not radio

Hoy uno corto:

Desde la lista de correo de la RootedCon nos han enviado (n0p) un enlace en el que se indica que Google ha afirmado que:

wifi isn't radio

El wifi no es radio. Y por lo tanto, no tiene que acogerse a sus reglas.

No voy a negar que al ser muy largo, he ido haciendo lecturas muy rápidas y no he acabado de pillar del todo en qué se basa Google para afirmarlo. Al menos, es lo que quiere mostrar legalmente, dado que yo también estoy de acuerdo en que físicamente es una burrada como una casa decir que las redes inalámbricas no son radio.

Recordemos que aunque lo llamemos wifi, esto realmente es el consorcio que ha acabado dando el estándar y el nombre a la tecnología. Contado así corto y rápido.

lunes, 9 de septiembre de 2013

Desmontar unidad en linux: device is busy

Ahora mismo estoy intentando desmontar una de las unidades que tengo (valga la redundancia) montadas en mi backtrack con un

#umount /mnt/usb

pero sin éxito, dado que me está dando un error como el siguiente:

umount: /mnt/usb: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))


Por lo que he decidido seguir las instrucciones. Pero, dado que el listado es demasiado grande, he decidido aplicarle un pipe (más comunmente conocido como "tuberia") para filtrar la salida y que sea más sencillo de encontrar el resultado:

#lsof | grep /mnt

Y, así, a la segunda, me ha salido un único resultado que es el que necesitaba. Entre otras cosas, sale el pid del proceso que tendré que matar para desmontar correctamente ese mapeo:

bash      3697       miUsuario  cwd       DIR               8,33        20480          5 /mnt/usb

Aún así, tengo curiosidad por el resultado que me devolvería el otro comando. fuser. Por eso, antes de matar el proceso anterior, vamos a ver el resultado que me suelta.

Vale. He tenido que hacer un pequeño ensayo y error. El comando fuser necesita recibir un parámetro para funcionar. Además, ese parámetro puede necesitar a su vez un valor determinado. En mi caso tengo que poner

#fuser -m /mnt/usb

Porque, de no pasarle uno, nos devolverá la ayuda.

El resultado sería:

/mnt/usb: 3697c

que, como se puede observar, coincide (en gran medida) con el que nos da lsof.

Total, que al ejecutar:

#kill -9 3697
#umount /mnt/usb

deja de quejarse.

Esto hay que apuntárselo para que no nos olvidemos. Que muchas veces sucede y al final acabamos quitando el dispositivo sin desconectarlo correctamente.