363 meneos
6737 clics
![Analizando la app de La Liga para Android](cache/2d/42/media_thumb-link-2966103.jpeg?1528811466)
Analizando la app de La Liga para Android
Primero vamos a ver que dice el comunicado sobre las acusaciones de espiar a los usuarios desde un punto de vista puramente lógico y luego vamos a ver cuál es la realidad basándonos en el código fuente de la aplicación en su versión 6.4.7 publicada el dia 8 de Junio de 2018 que al fin y al cabo es lo que ejecutan los usuarios en sus dispositivos. Vía twitter.com/Jorge_Morell/status/1006508024171847680
|
comentarios cerrados
Me ha asustado más que la función que devuelve si hay partido siempre devuelva true, lo que significa que cada 30 minutos se pone a grabar, con dos cojones, es para que la AEPD les cruja a base de bien.
Personalmente descarga la aplicación hace tiempo ( para saber el horario de los partidos ) y en una de las actualizaciones ( muy frecuentes por cierto ) empezó a pedir permisos ( agenda,cámara etc..) inmediatamente la borre
También ahorraría muchos malentendidos escribir sin faltas de ortografía.
Venga, todos a una: ¡malditos hijosdeputa!
Dejando a un lado el análisis de dudosa calidad que hace de la aplicación, esta persona de tecnología no tiene mucha idea. Este caso es exactamente igual que Shazam, con 2 salvedades:
1. El análisis no es necesario que sea en tiempo real, puede ser en diferido. Se graban los audios, se procesan aunque tarden semanas, y se obtiene un listado de bares sospechosos de estar pirateando la emisión de los partidos. Y la denuncia se puede presentar meses tras la emisión, no pasa nada. No hay un usuario esperando una respuesta exacta en ese preciso instante. Es decir, es mucho más fácil que Shazam.
2. El análisis no se hace contra una base de datos de cientos de millones de canciones, si no únicamente contra un único flujo de audio: el que corresponde al partido de Liga que se está emitiendo en ese momento. Es decir, otra vez es mucho más fácil que Shazam.
Me ha asustado más que la función que devuelve si hay partido siempre devuelva true, lo que significa que cada 30 minutos se pone a grabar, con dos cojones, es para que la AEPD les cruja a base de bien.
LOPD/RGpd por cuanto se obtiene información de audio de terceros que no han consentido explícitamente. Os recuerdo que poner cámaras que no graben implica necesariamente aplicación de la LOPD y hay sanciones de la agencia en ese sentido. Incluso sanciones por cámaras simuladas.
Ley de consumo por cuanto se suministra una aplicación a un usuario con una funcionalidad encubierta y oculta que no sirve al usuario y que lo convierte en medio de explotación empresarial para los exclusivos fines de La Liga, aunque se le advierta, y se usa para beneficio de un tercero. Ya, esto pasa casi con cualquier app que explote datos de los usuarios que consienten pero no las de los que no consienten.
Y no me vale que no grabe o que "binarize"el audio. Cualquier tratamiento que se haga de mi voz, que no tengo la app, en el bar donde hay otros parroquianos que si la tienen, exige de mi consentimiento.
Si se "binariza" el audio ya hay un tratamiento de mis datos biométricos. Se grabe o no.
Es viejuno pero no desfasado: coding-geek.com/how-shazam-works/
Por cierto según la GDPR deberían informar que el audio se comparte con terceros como son Fluzo. Vamos desde mi punto de vista... deberían meterles un puro por protección de datos / GDPR.
No seria de extrañar que la señal de los partidos emitiera un patrón de somidos cada x tiempo que identifique el equipo que recibió la señal.
Para esto se puede tirar de apktool para ver el smali o lo que sea, nos vale un dex to jar y tirando, total lo que interesa es ver el código de una manera estática sin necesidad de editar el comportamiento.
¿De verdad pensáis que necesitan postprocesar el audio del partido? ¡Ellos son los que generan el audio!
Les basta con incorporar un pequeño patrón (periódico) en las frecuencias no audibles por las personas pero que sí emiten altavoces y recogen micros. Podríamos decir que es un código de barras. Código único por emisión.
Se puede procesar y buscar este código en el teléfono. Sería sin duda muchos menos intrusivo que enviar trozos de audio a un servidor, pues puedes borrar el audio sin código instantáneamente. Si encuentras un audio con código, es entonces cuando lo comunicas al servicio (el código y las localización, no el audio completo).
Eso es lo que intenta vender el comunicado que el autor no entiende (y habla de viajan al futuro).
Por cierto, esto de los códigos de barras, ya es un método habitual. Los tenéis en anuncios, programas de tv, etc. y los recogen muchos juegos y aplicaciones.
la señal de bar, no trae ningún "código" trae "la orden" que hace que el decodificador OFICIAL emita su numero de abonado
Transcribir audio a texto no es difícil, hace unas semanas sin ir más lejos yo mismo implemente un sistema que envía audio a Amazon Transcribe para posteriormente analizar el sentimiento del texto (Sentiment Analysis).
#7 En cualquier caso, calcular un hash o cualquier otra cosa de mi voz, que se encuentra en el entorno de grabación supone el tratamiento de un dato biométrico.
Es el mismo concepto por el que está prohibido instalar cámaras de videovigilancia que graben audio.
Así lo estableció el Tribunal Constitucional en su Sentencia 98/2000
En resumen, la implantación del sistema de audición y grabación no ha sido en este caso conforme con los principios de proporcionalidad e intervención mínima que rigen la modulación de los derechos fundamentales por los requerimientos propios del interés de la organización empresarial, pues la finalidad que se persigue (dar un plus de seguridad, especialmente ante eventuales reclamaciones de los clientes) resulta desproporcionada para el sacrificio que implica del derecho a la intimidad de los trabajadores (e incluso de los clientes del casino). Este sistema permite captar comentarios privados, tanto de los clientes como de los trabajadores del casino, comentarios ajenos por completo al interés empresarial y por tanto irrelevantes desde la perspectiva de control de las obligaciones laborales, pudiendo, sin embargo, tener consecuencias negativas para los trabajadores que, en todo caso, se van a sentir constreñidos de realizar cualquier tipo de comentario personal ante el convencimiento de que van a ser escuchados y grabados por la empresa. Se trata, en suma, de una intromisión ilegítima en el derecho a la intimidad consagrado en el art. 18.1 CE, pues no existe argumento definitivo que autorice a la empresa a escuchar y grabar las conversaciones privadas que los trabajadores del casino mantengan entre sí o con los clientes. Lo cual conduce al otorgamiento del amparo con el restablecimiento al demandante en la integridad de su derecho, tal como le fue reconocido en instancia por el Juzgado de lo Social núm. 3 de Pontevedra.
Salu2
Ya lo dijeron los Simpson, la liga de
béisbolfútbol nos espíaPD: Yo sabia que nos la metía doblada y no tengo ni puta idea de ingeniería inversa
Pffffffff, y sacarte una foto y subirla a Facebook tambien es tratar un dato biometrico, no se, ahi veo un poco forzado tu razonamiento.
Mirando la funcion mas en profundidad, envía la información si la función DataManager.INSTANCE.getMatchLive() devuelve un True, osea deducciendo un poco, por el nombre, si hay partido activo, devuelve verdadero, sino, devuelve falso.
Realidad -> devuelve siempre verdadero.
Y no es cierto, va a preguntar a la pagina de settings de fluzo.com y al menos en este momento dice: location_enabled:false
En el caso de Facebook la utilidad primera y para el usuario es precisamente eso. Subir la foto entre otras utilidades que se ofrecen al usuario.
En el caso de la liga no. El tratamiento de audio no es para el usuario ni como uso lateral o secundario sino para uso exclusivo de la liga.
Se ve que inicializa un objeto Settings usando el JSON de esa web, usando Gson (sites.google.com/site/gson/gson-user-guide)
He leido hasta:
"Realidad -> devuelve siempre verdadero." cuando en el código no solo no pone eso sino que de ser como dice, faltarían más trazas.
y a partir de ahi, me hago una idea, dejo de leer.
Por ejemplo la app movil de eldiario.es te pide acceso a la agenda. Tu crees que es necesario que eldiario.es acceda a mi agenda de contactos para prestarme el servicio ?
No se, es que veo demasiado postureo con estas cosas ... sera que me hago viejo y me vuelvo pragmatico.
Con el apk en tu pc, existen herramientas (el winrar te vale) que permiten extraer el binario (generalmente un fichero .dex) dentro de ese paquete.
Con ese código "dex" puedes usar herramientas para pasarlo a .jar y también hay herramientas para "decompilar" el codigo jar a lenguaje java. Como bien dice #34, no lo lograrás siempre. Puedes obtener resultados parciales, totales o nulos.
Dificultad? muy baja. Estas tools estan para cualquier SO y son muy intuitivas y gratuitas. Usa google.
Por poner un ejemplo:
JavaGuard is a general purpose bytecode obfuscator, designed to fit effortlessly into your regular build and testing process, providing peace of mind that your valuable Java code is more secure against decompilation and other forms of reverse engineering.
1) En el artículo se horrorizan de que la clave del API está visible.
-¿Y qué? Es perfectamente seguro. Probad a usar integración con Maps o Firebase (servicios de Google) y me contáis dónde metéis la clave de API. O mejor aún, intentad alguna trastada con ella. Nada, ¿no?
2) El código para comprobar el permiso es un horror. ¿Guardar el permiso en SharedPreferences? ¿Con qué fin? ¿Y un return en medio de un if? Pues vale.
3) ¿ACCESS_FINE_LOCATION? ¿Qué pasa, me vais a venir a recoger o algo? ¿Para qué cogéis mi posición con la máxima precisión posible? No entiendo.
4) Lo de que la función getMatchLive() devuelve siempre verdadero es más falso que Judas. A no ser que la clase Settings que han puesto en el artículo forme parte del backend (que no me lo creo, que me digan quién les ha dado ese código... para mí que se lo han inventado ellos). Aún así, si tuviera que adivinar, diría que getMatchLive() devuelve verdadero siempre que la app pueda localizar la posición GPS del móvil, lo que sería raro de cojones igualmente.
5) Es verdad que la app intenta enviar localización GPS cada cierto tiempo al servidor. Esto es raro y no se me ocurre ningún fin justificable.
6) Más abajo los del artículo ya están viendo ovnis otra vez... Plantan una función que se llama decrypt(), que ellos suponen que sirve para cifrar claves de API (que de nuevo, no hay ninguna necesidad de hacer esto), cuando lo único que hace es transformar datos a Base64. Es decir, circulen...
7) Es gracioso que el programa (después de solicitar permiso al usuario, eso sí) intenta usar el micro para grabar siempre que puede. Digo que es gracioso porque claro, como potencialmente el usuario ya les ha dado el permiso, pues les pueden estar grabando mientras cagan, duermen, etc. Me apuesto dinero ahora mismo a que la app intenta comenzar a grabar nada más arrancar la app. Estoy por descargármela, arrancarla y grabarles porno gay ahora mismo...
Ahora, el que quiera dejarse el gorrito de albal, que se lo deje. Yo ya paso.
Te dejo lectura anda: Privacy Threats through Ultrasonic Side Channels on Mobile Devices
"we spot 234 Android applications
that are constantly listening for ultrasonic beacons in the
background without the user’s knowledge." (Y de esto hace año y medio....)
www.sec.cs.tu-bs.de/pubs/2017a-eurosp.pdf
Gracias por tu aportación.
2.Instalar Xposed.
3.Instalar Xprivacy
4.Ejecutar Xprivacy.
5.Denegar permisos de acceso al microfono.
Yo que no tengo ni pajorela, agradezco el trabajo de este señor.
Qué facil es quejarse del (mal) trabajo de otros...
No, no suben el audio a ningun lado. Pero que la realidad no nos joda una deliciosa teoria conspiranoica. Aunque el para que y como lo usen, si es para cagarse en ellos.
La mera obtención del audio para calcular el hash supone tratamiento.
Palabrita de AEPD.
De ahí en adelante lo que quieras.
Pero ya has hecho un tratamiento.
No puedes calcular el hash si no tienes el dato en si mismo. El hash ya es un dato procesado y tratado. Punto.
Pero insisto, para la AEPD no necesitas no grabar nada para tener que cumplir.
La disociación, término definido en la propia ley, es ya una acción posterior a la obtención y posterior tratamiento.
Por otro lado un hash permite identificar unívocamente, salvo colisión. Así que no es disociación per se.
en.m.wikipedia.org/wiki/Application_programming_interface_key
The API key often acts as both a unique identifier and a secret token for authentication, and will generally have a set of access rights on the API associated with it.
Y no sólo porque lo diga la wikipedia sino porque curro con varias aplicaciones en la nube y una de ellas usa el key como user+pwd y no solo como identificador del cliente.
Me da que tu estas acostumbrado a las apis usadas desde apps móviles. Pero hay más mundo ahí fuera.
www.ibm.com/support/knowledgecenter/SSYJJF_1.0.0/ApplicationSecurityon
Aquí ya empiezan a diferenciar entre Id y Secreto.
Ejemplo:
success.coupa.com/Integrate/Technical_Documentation/API/Get_Started
Requests are authenticated by a unique API key, generated in Coupa.
1. Calcular un hash supone tratamiento. Pero se hace bajo el control del usuario (su terminal). Es similar a cifrar un dato antes de enviarlo al proveedor del servicio, o de decirle "mi DNI empieza por 4". El dato personal deja de serlo. No identifica.
2. Un hash no identifica unívocamente. De hecho como sabes hay infinitas entradas que provocan un mismo hash. Me remito al ejemplo anterior.
No me sé la LOPD ni la GDPR de memoria, pero yo diría que no tienen nada que hacer aquí.
1. Captura de voz de particulares por parte de una empresa= LOPD. Da igual lo que hagas con ella. Fin.
2. Mal hash si hace eso. Colisiones. Etc. Acabas de tirar a la basura el 80% de los sistemas de almacenamiento de la contraseña de casi todo internet.
#89 Las conversaciones entre particulares están fuera de la aplicación de la LOPD. Son actividades privadas. La ley es interpretable en su aplicación pero no debe romper el espiritu de la misma
Por otro lado, si yo activo un micrófono pero de esos datos hago un filtrado tal que no queda absolutamente nada excepto esa señal que busco, no puedo estar saltándome la LOPD.
sentworks.com/blog/how-to-get-and-configure-an-everbridge-api-key/
De hecho estos usan como api-key el base64 del mismo user+password que utilizas para logarte via web. Obviamente para hacer esto tienes que ir siempre por https porque sino estarías mandando la password en claro.