19 junio, 2017

Generando actividades falsas en Strava

Por defecto en Strava cuando realizamos alguna actividad a través de su App Strava este da la opción de poder publicar dicha actividad nada más terminarla. Esta actividad se publica en los tiempos, fecha/hora que se realizaron, así como el tipo de dispositivo en el que fue registrada.

Tiene la opción de poder subir un fichero .gpx de algún dispositivo GPS Garmin estos dispositivos establecen unos metadatos que definen exactamente el tipo de dispositivo, ya sea Garmin un fichero GPX sin ningún metadato establecido, etc.

No sería fácil entonces engañar a Strava subiendo actividades falsas, modificando la fecha/hora, velocidades, etc. Ya que igualmente podremos ver como el tipo de dispositivo sería un fichero .gpx y no un dispositivo como un smartphone que use la App Strava. Por lo tanto sería poco creíble una actividad que sea todo un logro subida directamente desde un fichero .gpx.
¿Pero que pasaría si se pudiese modificar cualquier parámetro y a su vez que las actividades se registren y publiquen a través del dispositivo móvil, pareciendo que dicha actividad fue subida de forma pública a través de la App de Strava?.

Una actividad registrada desde un dispositivo Garmin, abriendo el fichero gpx original en Notepad++ vemos que los datos se establecen en formato XML y la etiquetas de referencias para ficheros GPX son de estandar. la etiqueta "gpx creator=" será la que nos interesa para modificar el tipo de dispositivo con el que se registró la actividad. Así como las fechas de realización de la actividad, cogeré las fechas como ejemplo a modificar, pero se podrían establecer, velocidades, distancias, nuevas coordenadas gps, etc.

Figura 1: Fichero gpx original de Garmin

Si subimos dicha actividad a Strava veremos como tanto la fecha como el dispositivo (GPX) es la original del track gpx.

Figura 2: Actividad del fichero gpx original anterior

Para comprobar que metadatos registra Strava cuando este genera su propio GPX a través de su App desde un dispositivo smartphone, descargamos cualquier actividad previamente ya registrada desde la App en Strava. Exportamos el GPX y a continuación lo exploramos.

Figura 3: Exporar GPX ya registrado por la App de Strava

Abriendo el gpx original que exportamos desde Strava de otra actividad vemos que la etiqueta gpx creator apunta a "strava.com Android" (en el caso de iPhone abría que hacer lo mismo y mirar que valor toma) en cualquier caso para engañar la subida de la actividad como un dispositivo móvil nos servirá con Android.

Figura 4: gpx original exportado de Strava APP

Una vez sabemos el valor a sustituir, abrimos el GPX original, con Notepad++ reemplazamos todos los campos que sea de una fecha por otra (Search > Replace > Replace All o Ctrl+H) y modificaremos unicamente el valor gpx creator="Garmin Desktop App" por gpx creator="strava.com Android". A mayores podemos directamente eliminar/borrar o modificar también las etiquetas xml de <metadata> de los enlaces de referencia <link href> y <text>.

El resto de datos los dejaremos igual, ya que pude comprobar que si establecen exactamente los mismos datos que el gpx original de Strava, este se da de cuenta en el momento de subir el fichero gpx a Strava y nos cancela la subida. ¿Por que pasa esto? básicamente los metadatos del gpx contienen los enlaces al tipo de mapa o topo con el que se registrará la actividad y realizará los cálculos. Por lo que Strava se da de cuenta de estas modificaciones si cambiamos todos los valores que tengan que ver con sus metadatos. De modo que dejaremos el resto de datos del gpx original de Garmin en este caso, con su topo con DEM (desniveles del terreno), sus distancias, etc. El mapa y la actividad registrada con los datos del Garmin pero el tipo de dispositivo se establecerá como "Strava App Android".
El resto de valores competentes con tiempos, fechas/horas, velocidades, etc. no se verán influenciadas por los filtros de protección de Strava a la hora de subir las actividades en ficheros gpx.

Figura 5: gpx modificado de Garmin para Strava APP

Guardamos el fichero ya modificado y subimos de nuevo la actividad a Strava desde un fichero GPX, esta vez ya nos aparecerá la fecha modificada y el tipo de dispositivo que registró la actividad será Strava Android App.

Figura 6: gpx anterior modificado y subida la actividad a Strava

Saludos!

30 noviembre, 2016

Solución a Initramfs en el arranque de Linux

Puede darse el caso por diversas razones que el sistema operativo no consiga montar la partición principal de arranque, el cual nos mostrará un prompt en el arranque tipo (initramfs).

Initramfs (Initial Ramdisk File System), sistema de archivos ram inicial (ramdisk), es un archivo cpio comprimido normalmente en formato gzip que contiene un pequeño sistema de archivos que se cargará en la memoria RAM en el proceso de arranque del núcleo. El kernel lo montará, como una pequeña raíz, pues la necesita para completar algunas tareas relacionadas con módulos y controladores de dispositivos antes de poder arrancar el verdadero sistema de archivos raíz instalado en el disco duro e invocar al proceso init.

Figura 1: Prompt initramfs

La solución a este problema sería montar la partición raíz de forma manual, haciendo antes una comprobación de errores en el sistema de ficheros por si pasara algo, de ahí el problema inicial de que initramfs no diese montado en una primera vez la partición principal.

Desde la el prompt (initramfs) listamos el conjunto de particiones del sistema.
sudo fdisk -l
Figura 2: Lista de tablas de particiones.

En el caso anterior la partición que quiero recuperar es la la "/dev/sda1", aquí en cada caso puede ser distinto para cada usuario, dependiendo su escenario de particiones, tendremos que elegir la partición que sea correspondiente al sistema principal afectado.

Ahora usaremos fsck (File System Check) similar al chkdsk (CheckDisk) de Windows, fsck es una utilidad de comandos usada para las inconsistencias en los sistema de archivos y corregir posibles errores del sistema, se debería usar solo en sistemas desmontados.
sudo fsck /dev/sda1
Una vez realizada la comprobación anterior, montamos la partición manualmente.
sudo mount /dev/sda1 /mnt
Reiniciamos el sistema (reboot) y listo.

Saludos!

25 noviembre, 2016

Desactivar actualizaciones diarias en Ubuntu Server

Si estamos usando Ubuntu Server o seguramente cualquier distribución Linux que no disponga de una interfaz gráfica, en algunos casos, por lo menos personalmente me ocurre, cuando trabajo con este sistema después de una instalación limpia este por defecto tiene activado la comprobación de actualizaciones periódicas diarias, lo cual está bien ya que al ser un servidor que seguramente disponga de servicios en un entorno en producción, lo normal es que por defecto este intente actualizarse continuamente y así poder autoparchearse más rápidademente posibles actualizaciones de seguridad que pueden poner en una situación crítica estos entornos y con ello la organización.
Pero no en todos los casos vamos querer que un sistema se actualize a su antojo haciendo uso de todos sus repositorios ya que podemos tener servicios funcionando que no queremos que se vean alterados tras actualizaciones que les puedan afectar y de algún modo llegar a desconfigurarlo, con lo que será el administrador quien vea oportuno instalar estas updates, de que forma y cuando hacerlo.

Por eso comento como desactivar las actualizaciones periódicas diarias de un Ubuntu Server. Si no queremos modificar repositorios y complicanos mucho en tocar muchos ficheros lo más sencillo es simplemente descactivar esa perioridad diaria.

Editamos el fichero "/etc/apt/apt.conf.d/10periodic".
sudo nano /etc/apt/apt.conf.d/10periodic
Y establecemos la primeria línea a valor "0".
APT::Periodic::Update-Packge-Lists "0";
Figura 1: Desactivar actualizaciones automáticas - /etc/apt/apt.conf.d/10periodic

Reiniciaremos la máquina (sudo reboot) y listo.

Saludos!

05 octubre, 2016

Error VirtualBox máquinas inaccesibles

Para aquellos que usen VirtualBox como virtualizador y tengan instaladas VMs en un medio externo-extraible (tipo disco portable o pendrive). Tenemos que indicarle en las preferencias de VirtualBox el path destino predeterminado donde queremos que se nos instale desde ese momento en adelante las VMs.

La problemática que esto nos puede plantear sería la siguiente, pongo escenario:
Al introducir nuestro medio extraible, en el cual se almancenan nuestra máquina virtuales, el sistema Windows le asigna una letra de unidad, por ejemplo "E:". Configuramos entonces en las preferencias de VirtualBox que este nos agrege las máquinas que creemos en esa unidad, y como es la unidad por defecto que establecimos si al desconectar y volver conectar nuestro medio extraible el sistema nos asigna siempre la misma letra de unidad, en este ejemplo: E:, no hay ningún problema.
¿Pero, qué pasaría si insertamos otro medio extraible y a este le asigna E: ya que tienen esa letra libre y a continuación insertamos el medio extraible que nos corresponde a las VMs?. Pues lo más común es que no nos recozca las VMs que tuviesemos cargadas en ese VirtualBox en cuestión.

Figura 1: VirtualBox: Error de mapeo de VMs no encontradas.

Que posibles soluciones se podrían realizar?

Eliminar solo la VM:
Una de ellas, sería eliminar la máquina virtual agregada a VirtualBox, pero no eliminar toda la VM sino eliminar solamente "el puntero o acceso hacía" la VM en cuestión, de modo que no estaríamos borrando la máquina virtual real almacenanda originalmente en el medio extraible. Cuando le damos a botón derecho > eliminar, puede mostrarnos dos opciones, una que nos la borre sin más y la otra que nos pregunte si deseamos "eliminar todos los archivos" o "solo borrar", le diremos que "solo borrar" de modo que este solo borra este acceso a la VM y no borra todos los archivos de la VM real almacenada en el medio extraible.

Agregar una VM ya existente:
Una vez eliminada solo la VM en cuestión la agregamos, aunque primeramente y para no ocasionar futuros problemas en las preferencias de VirtualBox cambiamos la letra de unidad anterior estableceida por la actual letra asignada a nuestro dispositivo externo que alamcena las VMs. Una vez hecho eso ahora tenemos dos posibles variantes para agregar una Vm ya existente.
En cualquier máquina virtual que creemos de VirtualBox esta crea tres tripos de ficheros fundamentales, un archivo .vbox (VirtualBox Machine Definition) el cual contiene la configuración inicial por defecto de la VM en la cual se cargará con esa configuración en VirtualBox entre otras opciones, el un archivo .vbox-prev sería una copia del .vbox y un último archivo .vdi (Virtual Disk Image) el cual por su tamaño de ocupación vemos que es el que contiene la máquina en su totalidad (el disco de la VM).
El fichero que nos interesa en este punto sería el .vbox extensión propietaria del propio VirtualBox el cual hace referencia al puntero de apertura de la máquina.

Opción 1: Por lo que una vez configurada en las preferencias con la nueva letra asignada como comenté anteriormente y eliminada solo la referencia de la máquina de VirtualBox, simplemente ejecutamos el fichero .vbox (puede que tarde un poco en la apertura) automáticamente se debería cargar de nuevo esa VM afectada en VirtualBox.
Opción 2: Si la opción anterior nos fallase o se nos quedase colgado VirtualBox (puede pasar en algún caso), entonces tendríamos que agregar la VM de forma manual, desde la barra de herramientas de VirtualBox > Máquina > Agregar > seleccionamos el fichero .vbox en cuestión y abrimos dicha máquina.

Figura 2: Agregar VM (.vbox) de forma manual en VirtualBox.

Cambiar letra de unidad o volumen:
Otra opción sería conservar las máquinas virtuales afectadas ya agregadas en VirtualBox y solamente cambiar la letra de unidad del medio externo por la letra que tengamos asignado en ese momento. Para esta solución tendríamos que tener privilegios de administrador local del equipo.

Opción 3: Podríamos hacerlo por consola de comandos con "Diskpart" o de forma gráfica por una consola de Microsoft con "Diskmgmt.msc".

Abrimos una consola de línea de comandos y entramos en la utilidad interactiva Diskpart, listamos los volúmenes disponibles, selecionamos la unidad de volumen afectada y finalmente asignamos la letra de unidad establecida en VirtualBox.
DISKPART> list volume
DISKPART> select volume x1
DISKPART> assign letter=x2
Donde x1: Sería número de volumen afectado a seleccionar.
Donde x2: Sería la letra de asignación a establecer.

Figura 3: Diskpart: Asignando nueva letra a un volumen.

En la siguiente captura vemos como el cambio de la nueva letra de unidad se realizó correctamente.

Figura 4: Diskpart: Nueva letra asignada con éxito.

La forma gráfica mediante diskmgmt.msc (administrador de discos de Windows), tendríamos que selecionar el volumen afectado, botón derecho en "Cambiar la eltra de y rutas de acceso de unidad...".

Figura 5: Diskmgmt.msc: Nueva letra asignada con éxito.

Selecionamos en "Cambiar...", asignar la letra de unidad siguiente y selecionamos la letra que queramos establecer y finalmente aceptamos los cambios.

Figura 6: Diskmgmt.msc: Asignando nueva letra a un volumen.

Cuarquiera de las opciones anteriores sería válida, personalmente cuando me ocurre este tipo de problema y no tengo privilegios para poder asignar otra letra de unidad, suelo agregar la VM en cuestión de forma manual a VirtualBox o directamente abrir el fichero .vbox desde el medio externo donde estuviese ubicada esa VM.

Saludos!
Entradas Relacionadas