En este post os voy a hablar un poco de como he escrito un motor de análisis de código para x86 y x86_64, de los problemas que me he encontrado y de como he intentado solucionarlos (los que he arreglado, vamos…).

Hace ya algún tiempo que comencé con un proyecto llamado Pyew (similar al todo poderoso radare) el cual está pensado, principalmente, para análisis de baterías de malware. Se podría utilizar el IDA para ello pero, en ocasiones, esta herramienta es un poco pesada y, además, requiere una licencia (no muy barata, por cierto) que no todo el mundo tiene.

Comienzo

Al lío. Para hacer un reemplazo ligero del IDA para analizar malware se necesitan como mínimo 3 cosas:

1. Un cargador de formatos de ficheros: Para PE, ELF, Mach-O o lo que sea que te interese. En mi caso he utilizado Python PEFile para PEs y VTrace para ELFs.
2. Un desensamblador para el procesador: En mi caso, elegí Distorm64 (la versión 2) ya que tiene buen soporte para Python y soporta código x86 de 16, 32 y 64 bits.
3. Un motor de análisis de código: Esta es la pieza clave que no pude ‘coger de por ahí’ fácilmente, sino que me la tendría que escribir desde “0″ (bueno, la verdad es que se podría utilizar radare, pero preferí escribirlo por mi cuenta y aprender algo de paso).

Análisis de código

En este caso, la función que estamos analizando, comienza en la instrucción TEST, en 0xa950 y el bloque básico acaba en el primer salto condicional, en la instrucción JZ (en 0xa957). Ahora tenemos 2 posibles caminos que tomar: en caso de que la condición se cumpla (saltando a 0xa9c3) y el caso contrario, en el cual continuaría con la siguiente instrucción. ¿Cuándo terminaríamos de analizar esta función? Cuando llegamos a la instrucción RET, en 0xa9c4, que es donde acaba el último basic block y ya la función (porque no hay más caminos posibles que seguir).

Grafo de la sencilla función comentada

Mientras vamos siguiendo el flujo del programa descubriendo nuevas rutas de código, guardamos las llamadas a función, las ponemos en una lista y, al acabar con la función actual, se continúa con las funciones (direcciones) que se hayan encontrado. Hasta aquí todo muy bien y muy fácil. ¿Y con esto se descubren todas las funciones y todos los bloques básicos de una función? Ni mucho menos.

Bloques básicos

Antes había dicho que un bloque básico de una función es un conjunto de instrucciones seguidas hasta un salto condicional, no? Bueno, pues no exactamente. Pongamos un ejemplo fácil:

En este caso, en el primer bloque básico llegamos a un salto incondicional (JMP) y, siguiendo ese salto, encontramos después un salto condicional (JLE) a la dirección 0x3d3.  Las instrucciones desde 0x3c5 hasta 0x3d1 y 0x3ef a 0x3f3 no forman un único bloque básico, por una razón: un bloque básico solo puede tener un único punto de entrada. Así pues, lo que inicialmente creíamos que es un bloque básico hay que separarlo en piezas más pequeñas, de modo que cada bloque tenga solo un único punto de entrada (no así de salida). El grafo de flujo para esta función quedaría como sigue:

Grafo de la función con bloques básicos que no cumplen la lóǵica explicada inicialmente.

Ahora ya sabemos como tiene que ser un bloque básico correctamente y, teniendo en cuenta esto, ¿Tendríamos ya un motor de análisis de código funcional? Ni mucho menos.

Punteros a función

Los punteros a función son un quebradero de cabeza a la hora de analizar código estáticamente para encontrar funciones. ¿Porqué? Pongamos un ejemplo con el siguiente código en C:

Si compilamos este código (con GCC en mi caso) se generará el siguiente código ensamblador:

Realmente, no tenemos ninguna ruta de código a esa función así que, siguiendo la lógica actual de nuestro motor, no encontraremos la función “func”. ¿Soluciones? Varias, una de ellas, la más compleja, es trackear los argumentos y sus valores (haciendo una especie de mini-emulación). Si una dirección es pasada como argumento a una función y después se ejecuta esa dirección, pues sabemos que es un puntero a función, así que esa dirección la metemos en la cola de direcciones a analizar y listo.

Sin embargo, esta solución tampoco es 100% correcta. ¿Porqué? Imaginemos que la función que se encarga de ejecutar el puntero que le pasamos está en una librería, no en el binario que estamos ejecutando: como no tenemos el código de la librería (no se encuentra en el binario que estamos analizando) no sabemos que hará con esa dirección que se le pasa. Mi solución para esto es la siguiente: cada  vez que se referencia una dirección a un segmento ejecutable, esta dirección la pongo en la cola para posterior análisis. De este modo, muchas funciones de este tipo se podrían descubrir.

Aún así, tenemos otro problema más: ¿Y si el puntero se calcula en ejecución? Pues estamos jodidos, básicamente. Podemos intentar otras soluciones, como la siguiente.

Prólogos de función

El modo más típico de búsqueda de funciones es la búsqueda de prólogos de función. Por ejemplo, para x86 (32 bits) el siguiente es un prólogo típico:

Podríamos, simplemente, buscar los opcodes de este prólogo de función en los segmentos con permisos de ejecución (no necesariamente, ya que para malware, puede ser que se encuentre código en segmentos que no tienen permisos de ejecución y que luego se copien a una zona de memoria donde sí se tengan privilegios)  y, si esa dirección no corresponde con ninguna función ya analizada, poner dichas direcciones en la cola de análisis. Así se pueden encontrar muchas funciones que de otro modo, probablemente, no encontraríamos.

Pero, como siempre con el análisis de código, esta técnica tiene la oxtia de problemas: ¿Y si los opcodes que he encontrado corresponden a ese prólogo pero realmente no es una función? Este problema no es tan fácil de solucionar, la verdad. Mi solución es seguir desensamblando, buscando si el código tiene sentido (encuentro rutas de código que no se van a casa krixto, encuentro bloques básicos bien formados, etc…). Aún así, esta solución es solo parcial: ¿Qué ocurre si, por casualidad, resulta que encuentro una zona que parece código correcto y no lo es? La posible solución (que en Pyew no la he puesto aún) es asegurarse que el epílogo de función coincida. Esto es, si el prólogo de función típico de x86 es PUSH EBP & MOV EBP, ESP; habrá que buscar su epílogo correspondiente en los bloques básicos de salida, que es LEAVE & RET. Aún así, esto tampoco sería correcto, un ejemplo:

Esto podría ser un código perfectamente válido. La función recibe un argumento y salta inconicionalmente (que no llama) a la dirección pasada más un offset (una VTable, por ejemplo). La función a la que salta es la que, realmente, se encarga de arreglar la pila antes de retornar, es decir, es en esa zona de memoria donde se encuentra el epílogo de función.

De todos modos, vamos a suponer que ‘mágicamente’ tenemos solucionado también este problema. ¿Se podría decir que el motor está finalizado? Ni mucho menos: la búsqueda de prólogos de función es un coñazo porque hay múltiples prólogos de función. Por ejemplo, si desensamblamos ejecutables de Microsoft (librerías de Windows, el notepad, lo que sea) nos encontraremos que los prólogos a función no son como había puesto antes, sino así:

Así que nuestro motor de análisis de código no estaría encontrando el principio de la función, si no que estaríamos saltándonos una instrucción. La solución es buscar más prólogos: en vez de buscar solo PUSH EBP & MOV EBP, ESP, buscamos también con MOV EDI, EDI antes. Pero aún así, no vamos a encontrar todas las funciones del binario. ¿Porqué? Por la convención de llamadas de cada función, entre otras n-mil cosas.

Convenciones de llamada

Cada compilador, arquitectura, etc… tiene una serie de convenciones de llamadas, siendo las más típicas (x86) CDECL y STDCALL. La diferencia principal entre estas 2 convenciones de llamadas es la siguiente: en CDECL es el que llama a la función el que se encarga de restaurar la pila, mientras que en STDCALL es la función llamada la que tiene que restaurar la pila. En ambos casos, el prólogo de función cambiará, así que estamos jodidos.

Por si esto fuera poco, estas 2 no son las únicas convenciones de llamadas existentes. Tenemos otras más, como por ejemplo FASTCALL (la cual, por cierto, es implementada por cada fabricante como se le pone de los huevos), PASCAL, THISCALL o incluso podemos tener convenciones de llamada no estándar que el compilador ha decidido meter “así” porque resultaban más eficientes o usaban menos espacio.

Pero este no es el final de los problemas, aún tenemos otros todavía más gordos…

El coño de la Bernarda (también llamado contrucciones “switch”)

Un switch es una sentencia condicional que en función del valor comprobado tomará una ruta u otra o, incluso, varias. ¿Cómo se imlementa un switch en ensamblador? Cada compilador lo hace como se le pone de ahí. El modo más típico es el siguiente: tener una tabla de offsets a función y llamar a un registro (donde está la dirección de esa tabla) “+” un offset, que sería el índice dentro de la tabla. Este es el modo más típico para un switch medio/grande. Veamos un ejemplo con el siguiente grafo visto en IDA:

Ejemplo de switch sencillo (GCC, 32bits)

Si miramos el bloque básico que tiene varias salidas nos encontraremos con el siguiente código ensamblador:

IDA ha encontrado que la dirección 0×8048670 es una tabla de offsets (direcciones) a los bloques básicos que ha unido después. Es decir, ha encontrado un switch. ¿Cómo lo ha hecho IDA? Analizando el código que se encuentra en ese offset que ha encontrado que luego se accede al mismo por índice (0x0804842E) y que después hay un salto incondicional al valor que haya obtenido. Así que, si nosotros hacemos lo mismo en nuestro motor ¿Ya tendríamos soporte para sentencias switch? Ni de lejos… Cada compilador y cada arquitectura tiene varios tipos diferentes de dialecto de switch. Unos crean tablas como la que aquí se muestra. Otros, lo hacen accediendo a zonas de memoria relativa obteniendo la posición en ejecución. Un ejemplo (escrito a mano, que ahora mismo no encuentro ningún binario):

En este ejemplo, el compilador ha decidido que era mejor (por algún motivo) coger la dirección relativa de la tabla de funciones obteniendo la dirección de la función actual (de ahí el CALL +5 & POP EAX, para saber la dirección de la instrucción que se está ejecutando en ese momento).

Otra cosa que estoy obviando: estoy suponiendo que la tabla donde se apunta a las direcciones de los bloques básicos son contiguas y que son completas, osea, que estará del modo siguiente:

Sin embargo, esto no tiene porque ser así. En muchos casos me he encontrado que lo que realmente hay son direcciones relativas. Es decir, en vez de la dirección virtual completa nos encontramos simplemente el último WORD de la dirección. Por ejemplo, en vez de encontrarte una dirección como 0×08048436, te encontrarías con la dirección 0×8436, a la cual luego se le sumaría la base 0×08040000. O, aún peor, que lo que hay son las diferencias entre direcciones, es decir, el resultado de restar la dirección anterior de la actual. Y así podría seguir hasta aburriros y no acabaría en la puta vida.

Bueno, creo que el post ya es bastante largo así que lo dejo aquí. Espero que os haya gustado!

Hoy, a menos que La Noria lleve a Ortega Cano para que explique cómo matar a alguien y estar en la calle, la pandereta estará sobrevolando “el debate” en breves minutos.

Hace unos meses surgió una nueva polémica política respecto al control de RTVE, si bien ésta era un poco más curiosa. En todas las noticias al respecto veíamos que se mencionaba explícitamente un sistema de generación de noticias para medios de comunicación, que es el estandar de facto de la industria, el iNews.

Me voy a morder la lengua por no hacer lo propio con la yugular de alguno, así que vamos a lo que vamos.

Primero establezcamos el contexto con estos artículos

http://www.rtve.es/television/20110923/comunicacion-sobre-decision-del-consejo-administracion-crtve-programa-inews/463593.shtml
http://www.vayatele.com/profesionales/que-es-inews-y-que-tiene-que-ver-con-el-consejo-de-rtve

Parece que todo el mundo confía en la integridad del acceso al iNews. Asi que me puse a investigar un poco cómo funcionan las “teles” por dentro, en este caso TVE.

Lo primero que hice fue llamar a RTVE e intentar sobornar con donetes a algunos empleados para que me pasaran información. La cosa, incomprensiblemente, no funcionó así que hubo que pasar al plan B: Open Source Intelligence. Es decir, lo de siempre: Webs,comunicados, notas de prensa, pliegos, videos, foros, ir a tomar cafe al mismo bar que suelen ir los trabajadores a poner la oreja o a dejar un pendrive con el logo de TVE olvidado en la barra, etc etc…

He hecho una selección de las fuentes que proporcionan más información:

En esta web http://www.cobdc.net/12JCD/actes/ nos encontramos con 3 documentos interesantes, las presentaciones y papers de “El Gestor de archivo, nuevo perfil profesional en la redacción única de TVE” y “El uso de imágenes procedentes de Internet en los informativos de TVE”

Encontramos informaciones técnicas y operativas interesantes, que nos permiten ir formándonos una imagen del escenario.

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/pres/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/AGUILAR_uso_imagenes_internet_tve.pdf

Los dos últimos ficheros son fundamentales para entender el artículo, así que recomiendo su lectura. Explican la manera de funcionar de las redacciones de TVE, desde el punto de vista técnico y funcional.

Ejemplos de la información extraida

MEANA_gestor_archivo_nuevo_perfil_tve.pdf
“En los SSII de TVE todos los periodistas tienen la posibilidad de trabajar con texto, audio y vídeo en alta resolución. Todos trabajan sobre estas plataformas y elaboran su noticia desde su puesto de trabajo, es decir, escriben texto y después sobre el mismo equipo abren su software de edición que apunta a servidores de vídeo o unidades de almacenamiento compartido donde pueden encontrar las imágenes que necesitan.”

“Sin embargo, en la actual redacción digital de TVE, todo el material que
llega en cualquier formato, se digitaliza, y se introduce en el
almacenamiento compartido junto con los metadatos que lo identifican. Este
proceso de digitalización se llama “ingesta”.”

“El sistema se compone de un gran almacenamiento compartido llamado
ISIS/Interplay (Avid) que contiene todos los materiales con los que se puede
trabajar en un día. Este gran almacén tiene una capacidad cercana a 4.000
horas de vídeo y audio. Desde cualquier puesto de trabajo se puede tener
acceso a este almacén, añadiendo nuevos materiales, ingestando o
descargando contenidos que servirán para elaborar nuevos productos
informativos”

“La Ingesta Central es donde se llevan a cabo las grabaciones de líneas. En
la redacción digital de TVE existe un departamento que graba las señales
externas en ISIS. Utiliza 24 equipos llamados Airspeed (Avid), que se
pueden programar si se trata de envíos periódicos”

“Una vez que el material ha pasado desde los Airspeed a ISIS, el redactor o
el realizador dispone del mismo y pueden editar su noticia o pieza con
cualquier sistema de edición no lineal.
Para el montaje de una noticia, el redactor trabaja con dos aplicaciones
principales:
Instinct e Inews (ambos de Avid) que trabajan en paralelo”

AGUILAR_uso_imagenes_internet_tve.pdf
En el caso de los Informativos de TVE, las tareas estrictamente de ingesta
están a cargo de dos secciones distintas:
- Ingesta Central, encargada de la recepción de señales. Cuenta
para ello con 25 AirSpeed (servidor de ingesta directa de la
empresa Avid).
- Ingesta Local, responsable del resto de formatos que se capturan:
ENG, cintas del Archivo histórico, DVD, CD, Web y memorias tipo
flash. Cuenta con 6 NewsCutter Adrenalin

Esquema 1
Atendiendo a este esquema donde aparece Odetics para el archivo antiguo, deberían tener algo parecido a esto, mola.
http://www.youtube.com/watch?v=9fTJkVgRvpw

Esquema 2

Las imágenes y el texto recopiladas nos llevan a realizar otras búsquedas y averiguar que software, hardware y qué empresas están detrás.

Esta web de la revista de temática audiovisual nos ofrece un artículo con bastante información
http://www.tmbroadcast.es/index.php/tve-hasta-el-infinito-y-mas-alla/
Separándola convenientemente entre Producción, Emisión y Archivo.

Producción
“En la redacción se han instalado un total de 300 clientes concurrentes. La herramienta básica de trabajo para el redactor es Avid iNews Instinct”

Bien, esto cuadra con todo el revuelo organizado en base al control de iNews. Veamos un poco más del iNews en este video (3:05) de La 2 Noticias; Mara Torres invita a David Trueba a dirigir el informativo y donde hablan brevemente sobre este software.

El Famoso iNews

Podemos deducir un poco más de como tienen estructurada la arquitectura, se ve que usan switchs KVM

Emisión
“Como sistema de emisión se ha instalado el sistema ADC-100 de Harris con cliente, Production Client”

Fijaos en la pantalla resaltada, bastante parecida a ésta, perteneciente al BroadcastSupervisor del ADC-100, lo que también cuadra.

La arquitectura vendría a ser así

Podemos observar varios de los elementos que vemos en la foto de La 2.

A más alto nivel

Recapitulando, tenemos que están usando básicamente:

Avid NewsCutter XP
Avid NewsCutter Adrenaline
Avid iNews/Instinct
Avid Media Composer
Avid Interplay
Servers Avid MediaStream
Server Avid Unity ISIS
25 servers AirSpeed
Sistema Harris ADC-100 con el hardware/software asociado

Echemos un ojo al uso de puertos, y por lo tanto funcionalidades, por parte del Software/hardware de Avid http://cdn.pinnaclesys.com/SupportFiles/FAQ_Avid/243397/Port_Usage_Guide_UPDATED_24SEP2009.xls

Es un CTF en toda regla. Cuanto más lejos llegues, más pollas ascii podrás poner en el mapa del tiempo durante el telediario.

¿Cómo de seguro es el iNews?

Con tanto revuelo, que si se puede acceder o no al iNews y ver qué está escribiendo cada periodista, quise echar un ojo a la autentificación al menos.

En principio debido a las características del Software de Avid y los tipos de clientes, es bastante restringido. Aunque haciendo un poco el retard-ninja he conseguido algunos, entre ellos el famoso iNews.

Como hemos visto iNews es un software cliente, y desgraciadamente no tenemos acceso al servidor. Sin embargo, sólo para escarbar la superficie de lo que puede ser, quise comprobar si al menos cifraba las credenciales antes de enviarlas al servidor. Efectivamente no.

Si no tenemos un servidor pues no los inventamos, mejor dicho lo moldeamos. La técnica es útil en estos casos: crear un server dummy, dejar que el cliente iNews -ANWS.exe- hable con nosotros y ver qué peticiones espera. Vamos analizando el parser de paquetes y construimos el servidor según esto, finalmente podemos completar la secuencia y llegar a la autentificación

Básicamente el cliente se comunica con el server, le envía un ‘ping’ y este le dice que acción realizar, sí está disponible o no, seguidamente se comprueban que las versiones de ambos son compatibles y se realiza la petición de autentificación.

Mediante ingeniería inversa vamos analizando las peticiones que espera recibir el cliente y cómo parsea los datos, moldeandonos el server según lo que vemos, que quedaría así.

Fake iNews Server – Testing plain authentication
Britney spears is connected
Receiving PING
‘\x17\n’
OK- Sending LOGIN Request
Receiving CLIENT version
‘#(@) 3.2.5.9 DOS\x00′
Sending SERVER Version
Initiating AUTH request
‘\xfc\x03\x00\x00\xfc\x03\x00\x00′
Completing AUTH request
receiving plaintext user/password…
‘\x05\x81\x81\x00\xfe\x01\x02\x00′
‘\x00\x04\x81\x81\x00\x01\x02\t\x00\xbd\x04\x81\x00\x04\x14\x02a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00….

Curiosamente tras 3 intentos fallidos de autentificación, el programa muestra un Message Box diciéndote que has agotado los intentos, que te pires y se cierra. Pero teniendo en cuenta que nosotros somos el server y no le hemos dicho nada, la cuenta de los logins fallidos está en el lado cliente.

Lo que no puedo asegurar es si sólo está en ese lado, ya que no tengo un server. Si sólo se mantiene en el client-side además podríamos construir un programa para bruteforcear logins facilmente. La forma de interceptar las credenciales ya dependería de la arquitectura de red.

Los periodistas pueden estar “tranquilos”, a nivel de la aplicación sus credenciales están viajando en texto claro. Vamos que si no oficialmente, ‘extraoficialmente’ en principio no parece muy complicado monitorizarlo.

Bueno, pues ya sabemos algo más de cómo funciona TVE por dentro. Ahora a ‘disfrutar’ del debate, a ver si pasa algo raro…

Si alguno tiene más información o correcciones, escribid un comentario!

Hasta la próxima gorrillas del ciberespacio.

Un ejemplo tipico es el caso en el que cargas un ejecutable dentro del Windbg y quieres comenzar poniendo BreakPoins hardware. Como el punto en el que el Loader de Windows ejecuta el DebugBreak es anterior al punto en el que se inicializa el contexto del hilo principal del programa, tus BreakPoints hadware desapareceran.

Una forma de solucionar ese problema es, por ejemplo, poner un BreakPoint en el EntryPoint de la aplicacion que queremos depurar y poner los BreakPoints hardware una vez que hayamos alcanzado dicho punto. Tener un Script que te ponga un punto de ruptura en el EntryPoint de la aplicacion simplifica muchisimo esta tarea:

Un ejemplo de uso de este script depurando la calculadora de windows:

A mi personalmente me gusta mas el sistema de extensiones del Windbg, pero tengo que reconocer que para algunas cosas en las que no te quieres complicar mucho la vida, los scripts de Windbg pueden estar bien )

Si analizamos el problema proupesto, vemos que no se trata de un problema dificil. A continuacion voy a exponer una posible solucion. Tenemos que demostrar que siempre se puede dibujar una linea que corte al reloj en dos y que deje tres numeros rojos y tres numeros azules a cada lado. Nosotros vamos a demostrar que esto es asi, y ademas vamos a proponer un mecanismo que nos permitira saber cuantas soluciones existen y cuales son.

Vamos a comenzar imaginandonos que dibujamos una linea uniendo cada uno de los numeros de la esfera del reloj con el numero que tiene en frente. Todas estas lineas, seis en total, se cruzaran en el centro.

El primer dato que hemos de tener en cuenta es que para cada una de estas parejas, (12,6),(1,7),(2,8), etc. los dos numeros de la pareja no pueden pertenecer al mismo lado de la solucion. Esto es asi porque todas las lineas que hemos dibujado se cruzan en el centro, y la linea solucion se cruzara con todas ellas tambien en el centro del reloj, dejando siempre un numero de la pareja a un lado, y el segundo al otro.
Ahora, imaginemos que para todas estas parejas, ambos numeros tienen el mismo color. Entonces, cualquiera de las rectas que cruzando por el centro de la esfera divide el reloj en dos partes con seis numeros cada una, es una solucion del problema. Esto debe ser asi porque si para cada pareja un numero esta en un lado de la solucion y el otro esta en el otro lado de la solucion, y todas las parejas tiene los dos numeros del mismo color, entonces tenemos que encontrar necesariamente el mismo numero de digitos de cada color a ambos lados de cualquier recta que divide al realoj en dos.
De todo esto deducimos una cosa importante. Podemos ignorar las parejas que tienen los dos numeros del mismo color. Dibujemos nuestro reloj, dejando solo las rectas que representan parejas con numeros de diferentes colores:

Ahora, pasaremos a demostrar otro detalle que es importante para llegar a la solución final. El numero de parejas con numeros de diferentes colores es siempre un numero par. Lo podemos demostrar facilmente por reduccion al absurdo. Imaginemos que existe un numero impar de parejas con numeros de diferentes color, y sea este numero k, e imaginemos que para uno de los dos colores, por ejemplo el rojo, existen n parejas con los dos numeros de colo rojo. Entonces, la cantidad de numeros rojos en la esfera debe ser: 2*n+k. Como k es impar, ese numero es impar, pero la cantidad de numeros rojos y azules en la esfera es par : 6. Por lo tanto es imposible que haya un numero impar de parejas con numeros de diferente color.

Ahora ya tenemos todas las piezas del puzzle. Las parejas con ambos numeros de igual color no crean desequilibrio entre las dos partes de la solucion y siempre hay un numero par de parejas con numeros de diferente color. Si elegimos un color, por ejemplo el rojo, y nos fijamos donde estan los numeros de cojor rojo de las parejas con numeros de diferente color, siempre podemos encontrar uno o varios puntos en el que dejamos la misma cantidad de numeros rojos a un lado y otro. La paridad de parejas nos garantiza la existencia de este punto. De esta forma garantizamos que la cantidad de numeros de color rojo, y por ende de color azul, a ambos lados de la solucion coinciden. Pero ademas de demostrar que siempre hay solucion, y de haber encontrado una, tambien hemos diseñado un mecanismo que nos permite saber cuantas soluciones hay y cuales son. Para el ejemplo con el que hemos empezado, existen varias soluciones. He marcado con un circulo los numeros que limitan la zona donde encontramos soluciones.

Como podeis ver, los problemas son asequibles y entretenidos. Asi que os animo a seguir estos retos matematicos. El de esta semana es mas sencillo que el de la semana pasada ;o)
Por cierto, si quereis ver otras soluciones, El Pais ha publicando algunas de ellas aqui.

En primer lugar, pedir perdón a toda la gente que asistió a la rooted por el desastre de conferencia que perpetré. Me ha jodido de una manera que no os podéis imaginar, cuando llevas tiempo investigando algo, pones ilusión y en el último instante te sale un churro, pues es una putada bastante considerable. Nervios, cansancio, y el puto video que no se veía una mierda me terminaron de desconcentrar. Creo que 50 minutos no daban para lo que tenía pensado explicar el sistema eléctrico, subestaciones, 0days, ataques a los estimadores de estado…Tenía que haber planteado la charla de otra manera :/

En fin, estas cosas pasan… Estoy escribiendo un paper para explicar todo el tema, tal y como quería, y quedarme algo más a gusto. Debería estar listo en poco tiempo.

Ah, se me olvidaba! A los que no les gustaba mi camisa de lesbiana leñadora, mi cresta, etc… la próxima vez me lo comentáis en una reunión cara a cara. Que me tenéis cerca…No es un buen lugar para despotricar contra alguien un auditorio lleno de colegas

Yo sigo empeñado en no ir rajando de los demás, mala costumbre en este país parece ser. Eso sí, si me buscas me encuentras, que estoy ya hasta los cojones de tanto subnormal.

Pero eso es otra historia, hoy vamos a hablar de Rap. Más concrétamente del rap que han hecho los trabajadores de Garoña….

“¿Qué sabemos de ‘X’? No sabemos mucho.” en este caso sustituiremos X por Garoña.

Y es cierto, no se mucho. De lo que me interesa saber, sería mejor especificar. Tampoco me había planteado nunca buscar info sobre Garoña, pero a raiz del rap todo cambió. No duermo tranquilo sabiendo el flow que se gastan por allí.

Lo primero de todo es ver el video

que si me como una pera,que si es radioactiva, que no mola, tu alucinas etc etc

El video tuvo su repercusión en la prensa, donde se comentaba el hecho de que aparecieran en imágenes ciertas partes de la central de acceso restringido. Cuando se habla de que en algo salen cosas restringidas, aunque sea un capítulo de Padres Forzosos, ese elemento ya se torna interesante.

Así que lo siguiente era analizar fotogramas a ver qué veíamos, y si este vídeo nos ayudaba a complementar u obtener información adicional de fuentes abiertas.

Al principio podemos ver las salas de la turbina, compresores, laboratorio, tornos de seguridad, uniformes usados… y a este señor

Si por mi fuera le ponía una central nuclear para él sólo. Consigue condensar en su intervención toda la tristeza y desazón por el posible cierre. Me da penica.

De la parte de tornos, vemos que usan como metodo de autentificación una tarjeta (mano derecha) para acceder al pabellón donde se encuentra el circuito primario.

En los siguientes fotogramas lo dicen directamente, pero aun así podríamos inferir que el tío iba a un lugar chungo porque:
-Hay que llevar mono y cajco.
-Hay que pasar un control.
-Hay carteles arriba con el símbolo de radiación.

Posteriormente aparece el simulador de la sala de control, que supongo que es donde llevan a los colegios y eso.

Luego sale un señor encabronado con la mano en el pecho, que te mira fijamente hasta que te acojonas.

A partir de ahí, la cámara pasa a exteriores. Donde vemos la subestación,los transformadores y los shunts son de siemens. Nada raro.

Fijándonos en los elementos distinguibles y con la ayuda de google maps, podemos averiguar desde donde está grabada esa escena. Supongo que ese edificio sea el del turbogenerador.

Hasta aquí lo más interesante del video. Ahora pasamos a la empresa propietaria de Garoña, Nuclenor. http://www.nuclenor.org/

Si le pasas la FOCA te sale que el Subdirector de Emergencias del Consejo de Seguridad Nuclear es problable que use Microsoft Office 95.

Luego nos vamos a la galería fotográfica http://nuclenor.org/interior.htm

Se nos permite bajar las imágenes originales en alta resolución y con metadatos.

Es muy bonita esta foto

Podemos ver el HMI de Siemens Simatic, por lo tanto Stuxnet podría haber infectado a Garoña xD Obviamente ahora también sabemos qué están usando. A mi modo de ver, no mola.

Si comparamos los metadatos de la foto con la hora y la fecha de las pantallas, coinciden en el tiempo.

También podemos observar otros sistemas de la central, distintos monitores (Samsung, no Siemens), distinto software. Usan Windows 2000.
En una de las pantallas vemos el HMI de lo que parece ser el sistema de tratamiento de gases de reserva.

Y ya está. Ya sabemos algo más de Garoña.