lunes, 8 de enero de 2018

SPECTRE. Recuperación del dato. Entre lo sutil y lo diabólico.

En mi entrada anterior hablé de cómo MELTDOWN y SPECTRE burlaban los mecanismos de protección de las CPU para llegar áreas protegidas pero la cuestión era ¿cómo podía recuperar el dato? -- como si a alguien le importara -- (le voy a dar a la voz en off) 

Si analizamos el comportamiento predictivo de la  CPU resulta que por un lado, puede ejecutar comandos de forma desordenada ... vale, pero si por un casual atacamos una posición de memoria protegida no la podemos dejar en ningún sitio  -- claro zoquete, por eso está protegida -- ni en un registro ni en una posición de memoria pero resulta que sí podemos averiguar su valor por medio ... sutil, como diría el maestro ... con indirectas.



Pues antes de contar cuál es ese medio, voy a explicar un poco en detalle cómo funciona una caché -- si ya sabía yo que éste si no soltaba el rollo no se quedaba a gusto --- Las CPUs son rápidas, muy rápidas pero las memorias, aunque lo parezcan, no lo son tanto y por ello metemos en medio unas memorias mas rápidas llamadas cachés que aunque no son tan rápidas como los registros son mucho más rápidas que la memoria. Con el fin de optimizar el acceso a esa memoria, cada vez que hay que ir a buscar un dato a la memoria no se copia ese dato solo a la memoria, sino que se copia una cosa llamada línea que dependiendo de la arquitectura, es un número de de bytes determinados. En el caso de las CPUs de Intel que uso ahora son 64 bytes como se puede apreciar. Es decir, yo pido un byte y si hay un fallo de caché, va a la memoria y trae 64. Como la probabilidad de que pida bytes adyacentes es muy alta, seguramente la próxima vez que pida otro dato distinto éste se encuentre en la caché.


¿Qué diferencia tenemos de que un dato esté o no en caché? Pues que tarde 400-500 ciclos de CPU en tenerlo o que tarde 200, un ahorro considerable.

Pues la idea de estas vulnerabilidades es aprovecharse de esto. Como ya he dicho previamente, la  CPU accede a datos protegidos pero no los puede dejar en ninguna parte entonces ¿cómo poder saber el valor de este dato? Pues de manera indirecta con dos cosas:
- Profundo conocimiento del funcionamiento de la CPU y cómo se maneja el manejo de páginas de memoria.
- Un array "gordo" que no quepa en una línea y que ocupe 256 páginas de memoria ¿por qué 256 páginas y no 128 bloques o cualquier otra cosas ....? Ahora lo verás. El ejemplo está sacados del whitepaper del meltdown attack.

Lo que voy a describir leerá un sólo byte de la memoria. si quieres leer por ejemplo, una clave de 2048 bits (256 bytes) pues primero tienes que averiguar dónde está y repetir el proceso de 256 veces. No es rápido pero acaba funcionando y si eres sútil, no te pillaran. Si entras a saco vas a joder todo el rendimiento del servidor y te van a pillar a la primera.

El código es el siguiente (como dije, está en el white paper de meltdown)

Previamente a hacer nada vaciaremos toda la cache mediante la instrucción CLFLUSH y cargamos en el registro RCX la dirección que queremos atacar (la protegida) y en RBX la dirección de memoria donde esté nuestro array de prueba. Como ya hemos dicho antes, tenemos que conocer el tamaño de página que se intercambia, en este ejemplo, 4096 bytes (la típica página de 4K de toda la vida)

¿Lo tenemos todo listo? -- pero ¿te crees que alguien ha llegado aquí? -- pues vamos a hacer magia. Cargamos en el byte más bajo del acumulador (recordemos que nuestros registros son de 64 bits) el byte que apunta RCX (línea 4) y multiplicamos ese valor que hemos cargado por 4096 (línea 5) -- ¿lo cualo que dices que has hecho? -- multiplicar por 4096 o lo que es lo mismo, desplazo hacia la izquierda 12 posiciones (el número hexadecimal 0x0C es el decimal 12) lo que equivale a multiplicar por 2 un total de 12 veces y como 2 elevado a 12 es 4096, ya tenemos ese valor. Y con ese valor que hemos obtenido, sumado al puntero del array que queremos acceder cargamos el dato (línea 7) Un avezado espectador diría, pero si, estás machacando el puntero original -- Oye, que estás machacando el puntero original -- (eso no vale, lo he dicho yo primero) Pues en efecto, pero el valor que tenga RBX ya no me importa porque ya he hecho la magia ¿ha quedado claro?

-- Pues no, no ha quedado nada claro -- pues te lo explico, voz en off. En este caso, estoy forzando una excepción (violación de acceso a la memoria protegida) pero me aprovecho de que esto se ejecuta de manera desordenada ... es decir, que antes de que salte la excepción, la CPU ha accedido al dato, ha ejecut a la línea 7 ... y ha deshecho todo lo que hizo porque no es válido ... no hay forma de acceder al valor RBX, ni al de RCX, ni a la posición de memoria ... o quizás sí -- ¿me estás vacilando -- Pues sí, te estoy vacilando un poco porque en realidad si ha quedado un rastro. Antes hemos dicho que tenemos un array del tamaño de 256 páginas (en este caso 4K cada una, un array en memoria de un Mbyte) y que previamente, hemos vaciado la caché. Utilizando como índice el valor protegido hemos accedido a una posición de memoria de nuestro array cuyo valor es irrelevante, la cuestión es que ha cargado en memoria una página de memoria y sólo una ¿cómo sé cual? Pues de una manera muy sencilla, voy consultando página por página (desde 0 hasta 256 leo un byte en la posición multiplicada por el tamaño de la página) y miro cuanto tiempo tarda la CPU en dármela. Dado que todas están en la memoria principal, tendrá que ir a por ellas y tardará un tiempo muy similar para todas la páginas menos para una ... aquella página cuya posición coincida con el valor leído previamente en la memoria protegida -- no me queda claro-- Pues seguro que si ves este gráfico te queda más claro.


Todos los accesos pasan de los 400 ciclos de CPU menos uno que se queda por los 200, ese el que hemos pillado antes y ¡voilá! hemos hecho magia, averiguando un valor sin poder acceder a él. si quiero más datos, pues nada, repito el proceso las veces que haga falta, que con paciencia y saliva el elefante ...

El mecanismo que uses para llegar a forzar este proceso puede ser como MELTDOWN (fuerza una excepción pero antes ya ha accedido) o jugando con la predicción (SPECTRE) o algún invento nuevo, pero lo interesante del caso es que no le veo una solución sencilla al menos sin perjudicar el rendimiento del ordenador. No sirve el separar en cachés los datos e instrucciones del anillo 0 y del 3 porque estás accediendo a los datos del anillo 3 y vas a dejar el rastro en la caché. El forzar flushes de la caché cuando se produzcan violaciones puede perjudicar a otros procesos (no olvidemos que la LLC está compartida por todos los cores y procesos) Seguramente habrá que reforzar de alguna manera el acceso a la parte protegida por HW, primando el bit de protección que al parecer ahora  no es lo suficientemente estricto.

-- ¿De qué anillos hablamos? -- De estos, que te lo hay que contar todo.




Pues ... eso es esto, amigos.

-- Anonadado me hallo ¿latita Whiskas pa celebrarlo? ---

viernes, 5 de enero de 2018

Meltdown, Spectre y la caché de la muerte.

Estos días se ha hecho pública una vulnerabilidad que se aprovecha de la arquitectura de caché de todos los ordenadores. Posiblemente lo que hayas oído es que todos los ordenadores son vulnerables y que no hay protección posible que eso canta mucho en las noticias y es sensacionalista a tope. Lo malo es que por una vez tienen bastante razón.

Vamos a ver lo que pasa y para ello toca un poco de - ¿rollo patatero? - pues en efecto (macaguenlavozenoff).

Vamos a ir por partes, que la cosa tiene tela (avisados estáis ... ¡huid insensatos!) Por un lado, hay que tener en cuenta una cosa llamada "anillos de ejecución" que se definen en los sistemas operativos, el nivel 0 es el del sistema operativo y es el más privilegiado. Luego van los drives y por último, las aplicaciones, con menos privilegios.


¿Por qué se hace esto? Pues para evitar que se monte el pifostio padre y que una aplicación pueda modificar cosas del sistema operativo o de otras aplicaciones como ocurría en sistemas operativos más antiguos o simplones como el MS-DOS donde todo era accesible por todo y un programa mal hecho (no hay programa infalible) te podía colgar el ordenador o hacer algo peor, meterte un virus. Éstos inicialmente eran para tocar las narices pero ahora, con todos los ordenadores conectados te pueden robar tus datos o utilizar tu ordenador para cosas raras desde minar criptomonedas o cosas peores.

La cuestión es que los UNIX/Linux, el IOS de Apple que está basado en UNIX, Android (basado en Linux) y por fin Windows no permiten el acceso de las aplicaciones a estos niveles, haciéndolos más seguros (Claro que si sigues usando 1234 como password importa tres narices) Últimamente los virus intentan entrar por dos vías:
- Engañando al usuario para que les "eleve" la prioridad y hacer de las suyas,.
- Aprovechando bugs del sistema operativo o de las aplicaciones.

Al final todo esto, con un poco de cabeza, un antivirus y no andando haciendo el indio, más o menos se palía.

Ahora viene la segunda parte (de este rollo, que siempre se te olvida) que va un poco de arquitectura. Resulta que los vendedores de CPUs hablan mucho de cores, GHz pero suelen omitir un pequeño detalle: el acceso a la memoria. Echemos un ojo a esta captura:


La velocidad de la CPU es molona, casi 4 GHZ ... parece un pepinaco de cuidado y lo es. Lo que llama la atención es cuando aparece un campo llamado multiplicador .... ¿qué es eso? A lo mejor debemos retarnos a la era de los 486, cuando había uno con los número 33/66 (yo tuve un 33/100) y eso significaba que mientras que el procesador funcionaba internamente a 66 MHz (si, tres órdenes de magnitud por debajo) el acceso a la memoria funcionaba a la mitad (33 Mhz) Pues con el tiempo, la distancia en velocidad entre las CPUs y la memoria se ha ido incrementando. En este caso te encuentras que la memoria funciona a unos pobres 103 MHz y el multiplicador es nada menos que hasta un x44. No obstante, la memoria también ha evolucionado. Por ejemplo, utiliza ambos flancos en la señal de reloj, lo que convierte la frecuencia en el doble, transfiere varios bits en cada flanco, tiene bastantes bits de ancho de banda, .... En concreto en este caso, la velocidad teórica es de 3605 Mhz (DDR4) pero esa velocidad es sólo cuando transmite ... el problema es cuando hay que ir a buscar el dato que nos encontramos con una cosa llamada latencia que significa que el procesador está parado a la espera de un dato ... y eso pasa mucho más de lo que te piensas.


¿Cómo podemos paliar esto? -- pero ¿acaso te piensas que nos importa? -- Pues de varias maneras (incluso todas a la vez):
- Aumentando el número de cores, lo que permite hacer cosas en paralelo.La potencia del procesador equivale al número de GHz por el número de cores.
- Aumentando el número de threads por core, lo que hace que si un thread está en espera, el otro pueda que haga algo. En este caso, mi CPU no tiene Hyperthreading, pero en otras el aumento aparente es aproximadamente un 30-40% del rendimiento de la CPU. En procesadores con más threads como los SPARC, es mayor.
- Metiendo entre la memoria principal y los registros de la CPU diversas capas de memorias, cada vez más lentas pero cada vez mayores. En este caso, cada core dispone de dos cachés muy rápidas y pequeñas, de 32 KBytes cada una, una para datos y otra para código (una especie de arquitectura tipo Harvard que contrasta con el resto de la máquina, que en Von Newman) luego una segunda caché (por core) de 256 KB que mezcla datos y código y por último, una caché de L3 compartida por todos los cores de 6 MBytes que es la mayor y más lenta, pero aún así, más rápida que la memoria principal. Al último nivel de caché (en este caso la L3) se la conoce como Last Level Caché (LLC) y es el tamaño de caché que se publicita.


¿Hasta aquí todo claro? (pues seguro que lo complica) Con el fin de optimizar el rendimiento de la CPU las cachés no sólo van cargando datos a medida que se piden exclusivamente, se carga un bloque adyacente de manera que si el dato que se pide a continuación está en ese bloque (suele pasar) ya lo tienes en la caché. Es decir, la CPU va como a tirones: procesa lo que hay en la caché hasta que se queda sin datos y los vuelve a buscar a la memoria, cuando los tiene, los procesa de nuevo.

Pues resulta que las instrucciones no se ejecutan sin más, sino que primero se decodifican, se cargan los datos y luego se operan. Al final, una sola instrucción implica varios ciclos de CPU pero resulta que en realidad, las CPUs son capaces de de ejecutar una o más instrucciones por ciclo ¿cómo? Pues por medio de pipelines que ejecutan estas fases en paralelo: una decodifica instrucciones, otra carga parámetros, otras operan, ..... Pues para rizar el rizo y con la ayuda del compilador, no solo hacen eso sino que son capaces de predecir el comportamiento del programa en hilos ... es decir, pueden ejecutar el IF y el ELSE a la vez y en función del resultado, aprovechar la rama de ejecución ya calculada y descartar la mala ¡la leche! ¿no?  De hecho es capaz de ejecutar las instrucciones de manera desordenada (o lo que es lo mismo, de una manera distinta a la que fueron escritas) para optimizar los recursos y luego ordenar los resultados. Por supuesto, para ello cada procesador precisa un compilador especialmente diseñado para él

Pues toda esta parafernalia que ha costado más de una década desarrollar al nivel actual es la causante de los problemas que han aparecido recientemente. Al parecer incluso el CEO de Intel ha vendido todas las acciones que ha podido de su compañía, quedándose tan solo con las mínimas exigidas para el puesto cosa que le puede costar las cárcel por uso de información privilegiada. En España le meterían de CEO en una empresa del IBEX 35.

Lo que ha aparecido son básicamente dos vulnerabilidades:


Intenta hacer un acceso a un área de memoria restringida. El nivel de protección del Sistema Operativo y del HW se lo impide, pero consigue aprovechar una debilidad de las CPUs Intel y acceder a cualquier posición de memoria protegida. Este problema se mitiga con un parche que si no ha salido saldrá ya conocido como KPTI (Kernel Table Page Isolation) o KAISER que mueve las tablas de memoria del Kernel. Lo malo es que al parecer puede ralentizar bastante los ordenadores, en especial los que se hacen uso intensivo de los cambios de contexto (cambios de nivel en los anillos) que son las nubes, equipos virtualizados, etc. Pero mejor que permitir que desde una VM se acceda a otra ¿no? Yo no descartaría que en futuro aparezcan variantes de Meltdown que busquen otros datos aparte de las tablas de memoria. De momento, sólo afecta a CPUs Intel.


Esta es una vulnerabilidad peor porque afecta as todos los procesadores y arquitecturas (Apple, Android, Windows, Linux, ...) y es debida a que las cachés son compartidas por todos los procesos que corren en un ordenador y en los ordenadores modernos, procesos, lo que se dicen procesos, corren un montón (en la imagen de abajo puedes ver una captura de lo que hay en mi PC ahora mismo y no tengo precisamente muchas cosas abiertas pero procesos, dice que hay 205 corriendo) El tema es que Spectre juega con el sistema de predicción, forzando la ejecución de código privilegiado en entornos no privilegiados. Es la más complicada porque no tiene prevención (al menos ahora) y con un simple javascript pueden acceder a datos que se encuentren en el mismo servidor (aunque pensándolo bien, en entornos multiprocesador sólo se podrían acceder a VMs que corrieran en el mismo procesador e incluso, en los mismo cores, eso va a depender si está en L3 o en L2/L1) La cuestión es que la cosa tiene mala solución. Lo bueno de Spectre es que es muy complicado el sacarle partido de manera maliciosa ahora mismo ... pero todo llegará.


Y para terminar ¿qué afectación vamos a tener? Pues lo grandes servidores de nubes, públicas o privadas van a tener un problema serio de vulnerabilidad y de hecho, ya se están intentando proteger, aunque sea a costa de perder un porcentaje importante de sus prestaciones (se habla de hasta un 30%) El cambio de arquitectura y CPUs a corto plazo es irrealizable, a medio ... pues ya veremos. Se irán paliando poco a poco estos problemas, se incorporarán mecanismos de seguridad en la caché y poco a poco se irán sustituyendo los ordenadores vulnerables (hoy, 5 de enero de 2018 son todos) pero dudo que antes de una década haya desaparecido esta amenaza completamente. el tema no es tanto producir chips como el desarrollar, probar y reemplazar una arquitectura que ha estado evolucionando por más de una década.

Teóricamente los ordenadores domésticos son menos "interesantes" a la hora de infectarlos porque ya está el malware habitual, pero yo no me confiaría demasiado.

A saber de quién será la voz en off.
Felices fiestas que me voy de celebración.


viernes, 29 de diciembre de 2017

El grid maligno (IoT, seguridad, blokchain y otras hierbas)

Se nos va a ir en breve el 2017 y mirando un poco hacia atrás yo veo dos noticias interesantes (para mí que me dedico a ello, para otros les interesará el fumbol o el esperpento de banderas de Cataluña; yo ya lo encuentro cansino)

Gracias a este esperpento, el latrocinio gubernamental pasa a segundo
plano (éste también trincaba, dicho sea de paso)

Por un lado hemos sido conscientes (bueno, algunos ya lo intuíamos y otros, lo tenían bastante claro) de que con el aumento exponencial de uso de ordenadores en todas partes el número de vulnerabilidades aumentaría y el que se realizaran ataques masivos. El famoso ataque de Wannacry y en España, el impacto en una gran empresa como es Telefónica nos hizo conscientes de que estábamos con el culo al aire. Mis parabienes a esos señores tan espabilados que han recortado el presupuesto a los informáticos. A ver si conocen los conceptos lucro cesante e imagen de empresa. La cuestión es que Wannacry secuestró miles de ordenadores a los que pedía un rescate en bitcoins. Lo cierto es que según se dice, hicieron mucho ruido, pero sacar pasta ... poquita. Posiblemente haya sacado más con la revaloración del bitcoin desde entonces que con el secuestro.

Ahora estamos con el asunto del Internet of the Things (IoT) que no es ni más ni menos que disparar el número de dispositivos conectados a internet hasta varios miles de millones (unos 20.000  millones se estima ... por lo menos) con lo que vamos a estar rodeados de miles de aparatitos que en unos casos serán unos gadgets curiosos, en otros serán artefactos muy útiles y en otros serán gilipolleces, pero todo conectado ¿exagero? hace 15 año tenía en mi casa dos artefactos con conexión a Internet: el ordenador y el router de ADSL. Éste último con una compleja password por defecto: 1234. Ahora mismo, el número de equipos conectados por IP pasa de quince entre ordenadores, móviles, tablets y otros gadgets.

Por otro lado, aunque ya llevan 10 años rulando por ahí, la tecnología blockchain y asociadas junto con las criptomonedas  debido al impulso hacia arriba que ha dado la cotización. Ya hablan de bitcoin lo ejpertos más insospechados.

Ejpertos explicando la tecnología blockchain.
Si unimos las dos cosas ¿qué podríamos sacar? ¡en efecto! Utilizar vulnerabilidades para aprovecharse de otros para minar criptomonedas.

Al parecer se la han colado a la mismísima Movistar o a portales de Torrents.Ojo, esto no quiere decir que Movistar haya sido quien ha colado el minador, sino que les han hackeado (ya veremos si desde fuera o desde dentro) En otros portales, pues la cosa varía. Si te metes en portales "peculiares" a lo mejor son ellos los que lo hacen directamente. De hecho los navegadores empiezan a incorporar extensiones anti minado, similares a los bloqueadores de publicidad que ya incorporan,

El asunto es que hay que ser chapuzas. Te cuelas en miles de ordenadores y ¿no se te ocurre otra cosa que montar el pollo para que te pillen? Desde luego, si te vienes al congreso de malignos no te dejamos ni servir el café. La idea de hacer un delito es permanecer anónimo, sin que te conozca nadie y disfrutar de las ganancias y cuanto más se tarde en descubrir mejor, igual hasta con el tiempo fundas hasta una familia real y apareces en el Hola.  (*)
Listado de delincuentes anónimos a los que no se ha podido pillar por no saber quienes son.
Lo suyo es infiltrarse en ordenadores e ir recopilando información a lo bestia: passwords, usuarios, cuentas bancarias, instalar keyloggers, recopilar datos para analizar por big-data .... si minas bitcoins o similares no incordies, limita el gasto de CPU al 25% o menos para no molestar, el mejor parásito  es el que no mata al anfitrión. Pasa desapercibido, llévate información y no molestes porque lo que consigues es despertar a la bestia y te van a cazar.

Alguien podría pensar ¿y qué haces dando ideas al cibercrimen? Pues a ver si te piensas que he sido yo el primero en pensar en esto. Seguro que ya hay mucha gente trabajando en ello si no está ya medio desplegado (empezando por la NSA)

Bueno, os dejo, que tengo que quedar con unos amiguetes para planear .... la entrada del año. Feliz 2018.




(*) Seguro que más de uno pensó que iba a poner a los Borbones, pero no ...

martes, 19 de diciembre de 2017

Vamos a poner el belén correctamente (desvaríos navideños)

De todos es sabido que que en estas fechas es costumbre poner un belén con un montón de errores históricos, por no mencionar los arquitectónicos (ese Herodes más grande que su palacio ...)

Es típico poner al romano con sus loricas segmentatas que es unos 100 años posterior, por poner un ejemplo, como si hacemos una reconstrucción del 2 de Mayo y armamos a los franceses con fusiles de cerrojo, no queda serio. Parece ser que por ahí andaba por aquella época la Legio VI Ferrata junto con sus correspondientes auxiliares. Un par de décadas antes había sido la batalla de Actium aunque no creo quedaran muchos que la hubieran visto. Seguramente la mayor parte de las tropas estuvieran en Cesárea y lo que hubiera por ahí fueran auxiliares que a saber de donde provenían (lo que apuesto que no eran, era precisamente judíos)

La nieve en Jerusalén igual no está mal del todo porque aunque  no es Viena, a veces refresca y nieva (en el momento de escribir esto no hace mucho frío, entre 8 y 15 grados) En Google Maps no veo ningún río y menos de papel aluminio, así que otra cosa a quitar. El castaño tampoco parece darse por esos lares, con lo que la castañera, también sobra.

El niño es otra cosa que sobra, junto con la madre y el padre dado que el nacimiento no se produce en ese momento dado que yendo a los propios evangelios, la descripción del evento no parece muy invernal ya había pastores durmiendo al raso y aunque no haga un frío excesivo ... como que no apetece.

Había en la misma comarca unos pastores, que dormían al raso y vigilaban por turno durante la noche su rebaño. Lucas 2:8 

Pero no te apures, tienes un montón de dioses varios para poner en el portal:
- El Sol Invicto. También el 25 de diciembre.
- Baco. No se si era su nacimiento, pero las brumales se celebraban en esta fecha.  Esta festividad se sigue honrando poniéndonos todos como piojos ese día (y los siguientes)
- Saturno. Las famosas saturnales. supongo que una festividad sustituiría a otra porque de lo contrario, no hay hígado que aguante.

Hay otro dioses que se dicen que nacen el mismo día estilo Horus, Osiris, Krishna, ... pero no he encontrado nada que lo respalde y en ocasiones, sus festividades son en otras fechas.
No, estos no nacen el 25 de diciembre (obsérvese que faltan los que sí lo hacen)
También he mirado dioses babilónicos y asirios, pero hay tal cantidad que me da pereza, pero vamos, seguro que más de una deidad solar tiene alguna fiesta en algunos de los solsticios/equinocios como éste que eran desconocido para mí aunque igual no tanto en Próximo Oriente hace 2000 años (Era en el Cáucaso donde se encadenó a Prometo)

Los judíos también celebran estos días Janucá, pero aquí lo que celebran es que un candelabro se mantuvo encendido unos cuantos días (si es que en la antigüedad se conformaban con cualquier cosa)

Aparte de esos, tienes a uno real, que nació el día de Navidad y su obra revolucionó el mundo: Sir Isaac Newton

Pues nada, feliz equinocio, sea cual sea el dios solar al que adores.

domingo, 10 de diciembre de 2017

DCS AV-8B and real AV-8B+ (Spanish Navy/Armada Española)

Usually I write in Spanish but this time and thinking of the possible readers of this article I will write in English. Apologies to my usual readers (to al the six or seven)

As I wrote in other articles I am a big fan of the airplanes and simulators moreover, I own a pilot license and I own several modules of the DCS sim and now I flying the AV-8B Harrier on this sim. Fortunately I had a close contact with Harriers in the past and I am wondering how reliable are the models according to the reality? I went to my pictures library and this is the result. Real pictures have been taken in Córdoba (Spain) in 2005.

Hope than you enjoy it!

I will start with the external views. First photo is from simulator, the second one, from the reality. I tried to capture the screens as similar to the originals as possible.

A lateral view:


An angle view ...



A front view. You must consider that the Spaniard plane is the RADAR version.


A view from the back ....


The nozzles...


Hardpilons.


The other angle ....


And ... what about the inside? The right MFD



ACP, water control, landing gear control, flaps, ....

 A general view of the cockpit.

 Clock, left pedal, ACP, ...


Hope that you enjoyed it so much as I taking the photos!


¿Cuánto nos gastamos en el coche en su vida?

El otro día leí que el gasto medio de un coche a lo largo de se vida son unos 40.000 € y la cifra me sorprendió ¿puede ser verdad la cosa? Como soy de los que les gusta medir y comprobar las cosas y tengo las cifras, vamos a ver algunos números a ver qué sale. Obviamente esto es con mi coche y las cifras saldrán mayores o menores con otros modelos, peor habida cuenta que no tengo nada del otro mundo si tienes coches similares o de un coste parecido, por ahí andarán los números, algunos miles de euros arriba o abajo. Cada cual que haga sus cuentas.


Vamos al turrón. He comprado el coche hace 2,6 años y en ese tiempo he recorrido 52.334 kms, lo que hace una media de 20.023 kms. No es ni una media ni muy alta ni muy baja .. normalita tirando a cochambrosa y para ello he gastado aprox. 4.010 litros de combustible (puede que faltan algunos, pero los he ido apuntado casi desde el principio) y he dejado en la gasolinera 4.007,3 € (suelo repostar en una low cost al lado de casa y de media estoy casi en el euro por litro) Con esa media, sale que dejo cada año 1.533,19 € en gasóleo.

Si nos vamos a las ruedas, me han durado unos 50.000 kms (lo dejo así para redondear) y he dejado 542 € en su cambio (las cuatro, es un AWD y se cambian a la vez) El precio del seguro es de 430 € y cada vez que lo llevo a revisión al taller me clavan unos 400 napos (cuando pase la garantia te digo yo lo que me van a ver en el taller oficial)

Vamos a extrapolar a 10 años:

Combustible     15.331,91 €
Seguro       4.300,00 €
Ruedas       2.168,00 €
Impuesto       1.750,00 €
Mantenimiento       3.955,00 €
total     27.504,91 €

Obviamente, estos cálculos omiten gastos en peajes, posibles sanciones, accidentes, gastos en lavado y otras cosas que se pudieran hacer. En el supuesto de que se mantenga el precio del combustible, el seguro, gastos en ruedas, impuesto de circulación ....al cabo de 10 años y 200.000 kms habré dejado en el coche la nada despreciable cifra de 27.504,91 € en 10 años .... 2.750 € de media anuales. Si a esto le sumamos el precio del vehículo (21.000 € o 22.000 si incluímos el vehículo viejo) la cifra sube a 48.504 € en 10 años ... casi 5.000 € al año.


La parte del león se la lleva como es lógico, el gasto en combustible, pero hay una serie de gastos que podemos considerar "fijos" como el seguro (el mío no es caro en comparación con otro) impuesto de circulación o mantenimiento que podrían hacernos pensar si merece la pena tener un coche o no.

Por supuesto, estos cálculos son relativos a mí vehículo. Conozco gente que tiene coches que gastan bastante menos pero que también les costaron bastante más (lo comido por lo servido) y luego depende lo que circules, que seguro tengas, etc.

Sí, es para pensárselo ...

domingo, 3 de diciembre de 2017

¿Qué leches es eso del bitcoin?

Pues estos días (diciembre de 2017) está sonando mucho en las noticias la subida del bitcoin que ha superado los 10.000 $ (en el momento de escribir esto está a 10.994 $ por bitcoin) lo que viene a meter una revaloración de en torno al 1.000 % por el momento. No sé cómo acabará el año, se oyen muchas cosas a su favor y en su contra ni hasta dónde va a llegar o si se va a pegar un porrazo en algún momento (seguramente bajadas habrá, ahora hay que ver hasta donde)
Evolución del BTC en 2017

Yo no voy a analizar nada de eso porque no me considero capacitado (los economistas que lo hacen, tampoco lo están. No saben de la vida "normal" como para dominar de esto) así que lo que voy a intentar explicar a continuación es lo que el bitcoin. No es ninguna cosa de locos, tiene una base matemática y de seguridad muy importante detrás, de hecho, más segura que nuestro actual sistema monetario (si ahora hay movimientos especulativos en el mercado de futuros, va aparte de la criptomoneda) pero para aclarar qué leches es esto, para ello vamos a empezar con algunos conceptos.

Dinero fiduciario.

Este palabro tan raro, el dinero fiat, que nada tiene que ver con los fabricantes originales del 600 . sino que se refiere que el dinero vale lo que vale ... pues porque te lo crees. Anteriormente teóricamente los bancos respaldan el valor de su moneda con oro pero desde 1971, ni eso. En resumen, que lo que te crees eterno (el dinero) pues no tiene más valor que cuando te lo crees. En caso de que no creas en él, va perdiendo su valor como ha pasado en docenas de países desde la Alemania de después de la PGM a la Venezuela actual y docenas de países africanos.
Billete de cien billones de dólares de Zimbabwe. 

Intermediarios financieros.

Si tenemos que pagar directamente (por ejemplo, me voy a la frutería a por patatas) no hay demasiado problema: ellos me dan patatas, yo les doy euros (me olvido del hecho de que esto es fiduciario) y todos tan contentos. Ahora el problema es cuando tengo que pagar a un tercero con el que no tengo contacto directo o no quiero llevar grandes cantidades de dinero encima, por si me roban. Entonces recurro a un tercero que es confiable al que yo le hago entrega del dinero para que éste a su vez se lo entregue al destinatario. Esta labor la pueden realizar intermediarios estilo VISA, o Paypal, por ejemplo. No es una cosa nueva. Ya los caballeros templarios hacían labores similares con los que viajan a Tierra Santa. Cuando alguien quería ir de peregrinación y no quería llevar encima mucho dinero, recurre al Temple. Les daba una serie de dinero por ejemplo en Ponferrada (hay un castillo templario) y éstos le daban una letra de cambio que podría hacer efectiva en cualquier otra "oficina" del Temple. También te guardaban el dinero y a cambio (cómo cambian los tiempos) te daban unos intereses (obviamente, también hacían moverse al dinero para sacar más rentabilidad de la que pagaban)
Sello del Temple.

Contabilidad.

Todo este tipo de operaciones hay que tenerlas registradas en alguna parte porque si no es un galimatías y nadie sabe lo que tiene, lo que debe, lo que ha prestado y para ello se recurre a la rama seria de la economía que es la contabilidad. Las operaciones se anotan en un libro contable que está guardado a buen recaudo y que es el corazón de todas estas operaciones. Aunque se sigue llamando libro contable, actualmente pocos los siguen usando, siendo programas que se ejecutan dentro de ordenadores.

Delitos.

El robar no es un invento actual del PP sino que es un invento tan antiguo como la humanidad, posiblemente anterior a que el primer homínido ya que desde la época de los dinosaurios ya había bichos que dedicaban a "distraer" los huevos de los nidos ajenos pero vamos a centrarnos en el tema: robar dinero. No nos interesan las gallinas, peras o cualquier otro tipo de robo. El método tradicional era el robo a mano armada o garrote en ristre que se ha ido sofisticando a lo largo de los tiempos con la evolución de las armas y las protecciones y que a veces acaba con ensaladas de tiros. Otra manera más sutil es el "sustraer" activos de manera sigilosa, vía butrón o similar. Uno de los textos jurídicos más antiguos hablan de un juicio a unos ladrones egipcios que saquean una tumba excavando un túnel hasta la misma. También es posible la falsificación de documentos o medios de pago para realizar operaciones falsas y que al parecer, el cubrir esos fraudes es el mayor coste de la empresas como VISA o MasterCard.

Blockchain.

En realidad lo que hay detrás de bitcoin es un protocolo llamado blockchain o cadena de bloques. Este protocolo apareció en un paper de 2008 publicado por un misterioso Satoshi Nakamoto pseudónimo de una persona o un grupo de personas que propusieron esta arquitectura.
Mientras que tradicionalmente los libros de cuentas son únicos (o eso creo) en este caso tenemos multitud de copias de estos libros distribuidos por todos los nodos que componen la red. Las operaciones se notifican a los nodos y estos apuntan las operaciones en sus libros de cuentas locales (todos tienen lo mismo) Cuando se completa una página de ese libro de cuentas esa página se firma y se cierra con un código hash que se añade el bloque siguiente, de manera que si alguien quiere alterar la cadena la tiene que reconstruir completa (y eso, como veremos en el apartado siguiente, no es tan fácil)
Dado que tenemos un montón de nodos implicados en el trabajo ¿que pasaría si un nodo se comporta de manera fraudulenta y comienza a meter valores fraudulentos en la cadena? Pues (y como veremos en el siguiente apartado) la cadena fraudulenta que genera será más corta que la cadena que siguen utilizando el resto de nodos, con lo que esta se descarta.

Adicionalmente, cada uno de los monederos que contienen los bitcoins de cada persona están protegidos por un sistema de clave pública y privada, con lo que las operaciones deben ir firmadas digitalmente por cada una de las partes para darse por válida.

Minería.

Supongo que estarás cansado de escuchar el tema de la minería de bitcoin y te dices ¿que es eso? 

Antes hemos dicho que se genera un código hash con todas las transacciones para cerrar el bloque. Lo cierto es que no es así al 100% dado que no sirve cualquier código hash (eso sería muy sencillo) sino que debe ser un hash con unas características determinadas (para simplificar, debe ser menor que cierto número o lo que es lo mismo, debe empezar por un número de ceros determinado) 


Pero ... si un bloque sólo puede generar un código hash ¿cómo hacemos? Pues añadiendo un código
 de 32 bits aleatorio llamado nonce. Dado que no existe una manera de a partir del hash obtener el origen, la única forma de cerrar el bloque es probando diferentes valores del nonce por fuerza bruta y esto se realiza con una serie de ordenadores especiales (en un origen se usaba la CPU, luego tarjetas gráficas que permiten paralelizar operaciones y ahora, equipos especializados llamados ASIC o circuitos integrados para operaciones específicas) Cuando consigues un hash válido, puedes cerrar el bloque y recibir tu recompensa en forma de bitcoins (a día de hoy 12,5 BTC) Cada bloque se mina en unos 10-30 minutos con lo que cada ese tiempo, hay 12,5 BTC más en el mercado. En su día se puso un límite de BTC en 21 millones.
Con buen criterio podrías pensar que con el aumento de velocidad de las CPUs y el HW el minar bitcoins es cada día más sencillo , pues no, porque la complejidad para encontrar el HASH aumenta progresivamente. Aquí puedes ver que el número de ceros exigido al bloque número 10 es muy inferior al exigido al hash que he puesto arriba (en su momento, era el último bloque disponible) 

Si te sientes tentado de utilizar tu ordenador para minar bitcoins, yo te aconsejaría olvidarlo. El coste de energía es muy alto (lo comido por lo servido en el mejor de los casos) y necesita un HW especial que está muy por encima en prestaciones de lo que suelen ser equipos domésticos (hay auténticas bestias con varias tarjetas gráficas para ello) El coste de la energía influye mucho, si consigues energía barata o gratuita, saldría rentable. Los medios de comunicación españoles, dentro de la ignorancia que les caracteriza hablan mucho del minado en Venezuela (aquí parece que no se conoce otro país) cuando ni siquiera está entre los 50 primeros (está el 63 en este momento) Los mayores mineros son EEUU y Alemania como puedes ver en https://bitnodes.earn.com/

Nodos mineros por países


Seguridad.

Antes hemos dicho que si un elemento creaba transacciones falsa, que no estaba siendo verificadas por otros, no pasaba nada. Esto es debido a que tiene que reconstruir la cadena y está compitiendo por fuerza bruta contra el resto de nodos (ahora mismo unos 11.000) con lo que siempre se quedará por detrás y será descartado. Para poder hacer un ataque con éxito necesita al menos controla la mitad de los nodos (+5.500 ahora mismo) con lo que en el propio número está la mejor defensa.

Problemas

Como todo, nada es perfecto y como siempre, hay problemas. En el caso del bitcoin, hay limitaciones técnicas para que sea la moneda del futuro. Por un lado, su número está limitado y la capacidad de realizar operaciones por segunda de la red es bastante limitada. Para ello se están desarrollando otro tipo de criptomonedas más capaces. Incluso, las hay que disponen de una característica que no dispone bitcoin, el anonimato (como dijimos antes, todas las carteras tienen un identificativo único y rastreable, aunque hecha la ley, hecha la trampa)

El consumo de energía también es un hecho a considerar. Una red como VISA emplea una cantidad de energía limitada para cada operación (vamos a omitir los datáfonos y otros equipos) pero la red bitcoin es una auténtica devoradora de energía.

Hablamos de TeraWh (billones de Wh) dedicados a minar bitcoins.
También habrá que pensar que pasa en el futuro, cuando los mineros pierdan interés por la moneda y el número de nodos se reduzca y pueda llegar a ser atacable. Supongo que mucho antes de que esto ocurra ya todo el capital se habrá migrado a otro tipo de monedas como bitcoin cash o cualquier otra moneda.

Otra desventaja es a la hora de guardar las criptomonedas. En caso de perder la clave o el monedero, te has quedado sin ellas, como ocurre a los chicos de Big Bang Theory en el 9º episodio de la 11ª temporada.

Futuro del blockchain y del bitcoin

El blockchain seguramente tenga un futuro interesante por delante, el bitcoin, durará un tiempo y al final, acabará decayendo (no ahora ni dentro de tres meses) con el tiempo el coste del minado será tan prohibitivo que dejará de atraer mineros. Si no se mina, el número de transacciones también decaerá y habrá que buscar otro método alternativo,  pero de momento, la cosa parece seguir con ganas, pese a lo que diga mucho agorero. No obstante, los tiempos cambian muy rápido y lo que ahora es vigor dentro de dos años puede ser una ruina . Ya veremos. De moment, al fundador de McAfee se le ve muy convencido.

No especifica si se la va a cortar o se va a doblar.
Mientras, los gobiernos siguen cavilando qué hacer con estas criptomonedas y algunos ya empiezan a moverse en este sentido (el nuestro no, por variar)

Otras aplicaciones


Esta tecnología tiene más aplicaciones que el uso como criptomoneda,. por ejemplo, se habla mucho de ella para el seguimiento de mercancías valiosas. Lo cierto es que esto por el momento se me escapa, no por el tema técnico (la idea es la misma) sino por el modelo de negocio.¿quien va a soportar la red y pagar el enorme consumo de energía? La red BTC se paga a sí misma con los BTC, pero ¿las otras redes?

Voy a revisar mi cartera de bitcoins no sea que ...

SPECTRE. Recuperación del dato. Entre lo sutil y lo diabólico.

En mi entrada anterior hablé de cómo MELTDOWN y SPECTRE burlaban los mecanismos de protección de las CPU para llegar áreas protegidas pero...