No iba a hacer otro vídeo
sobre los errores del iPhone, pero el fallo de 1970 que ha estado circulando
es interesante, porque probablemente es un tipo de exploit que
no he cubierto antes. En resumen: es casi seguro que se trata de un desbordamiento de números enteros
causado por la época de Unix. Y si comprende esos términos, no
necesita este video. Todos los demás: abróchense el cinturón, porque allá vamos. El 1 de enero de 1970 es un día especial para las computadoras.
En los años 70, cuando se estaban diseñando originalmente el sistema UNIX y todos sus amigos
, los programadores necesitaban una forma sencilla de representar
fechas y horas, sin tener que lidiar con todas esas
cosas humanas incómodas como días, horas y minutos. Sólo necesitaban un reloj en marcha con el que fuera
fácil hacer aritmética. Y la forma más sencilla de hacerlo es simplemente un
número, un número entero, que represente cuántos segundos han transcurrido
desde el 1 de enero de 1970.
Y todavía lo estamos usando. Por todas partes, en prácticamente todas las computadoras del mundo. Generalmente es la mejor manera de almacenar fechas
y horas, porque ignora las zonas horarias y
cosas humanas irritantes como esas. Ahora, he hecho videos sobre esto antes, así que
no me extenderé en ello, pero todo lo que necesitas saber es que la
medianoche a principios del 1 de enero de 1970, la fecha en cuestión, es cero. Esa es la primera pista de lo que está pasando.
Pista número dos: solo ocurre en iPhones modernos de 64 bits.
Ahora, 64 bits se refiere a cómo se almacenan los números
en el procesador. Tienes 64 dígitos binarios para jugar, en lugar de los 32 antiguos, lo que significa que puedes… bueno, puedes manejar números más grandes, hasta el nivel realmente básico del procesador, sin tener que recurrir a sofisticados
trucos de programación. Sin embargo, cambiar el teléfono y su sistema operativo de ese antiguo sistema de 32 bits a 64 requiere
algo de trabajo, por lo que habrá diferencias sutiles en el código
entre los dos. Y en alguna parte, apareció este error. Ahora, mostrar 64 bits en la pantalla es un poco
complicado, así que usemos cuatro bits para demostrar
cómo funciona. 0000 es 0. Luego cuentas en base 2, en binario, 1, 2, 3, 4, hasta llegar a 15. El número más grande que puedes almacenar en cuatro bits. No puedes contar más que eso. ¿ Pero qué pasa si lo intentas? Bueno, entonces obtienes lo que se llama un desbordamiento de enteros. Después de 15 viene… 0. Se da la vuelta y empiezas de nuevo, como un
viejo odómetro analógico de un coche. Ahora bien, si sólo tienes cuatro bits, seguro que será un problema: si tienes
64, bueno, sólo te meterás en problemas cuando hayas contado más de 15 quintillones.
Probablemente estará bien.
Excepto. Si el número más grande que puedes almacenar,
más uno, resulta cero… ¿ qué obtienes si haces cero menos uno? Bueno, eso se llama subdesbordamiento de números enteros. No puedes almacenar números negativos en este formato. Si puede reducir el número por debajo de 0, no
terminará con -1, terminará con su
valor máximo. Por eso, en la versión original del
videojuego Civilization, Gandhi era un idiota. Comenzó con una puntuación de agresión de
1. Y más adelante en el juego, bajaba aún más y nadie escribió código para comprobar que no cayera
por debajo de cero.
Entonces, en lugar de eso, se convirtió en lo
máximo posible y, de repente, Gandhi comenzó a declarar la guerra
a todos. Afortunadamente, sólo en un videojuego. Ahora. Hay una versión de este formato donde se
permiten números negativos, pero si Apple estuviera usando eso, probablemente no tendrían este problema. Después de todo, ¿por qué tendrías un
valor temporal negativo? No es como si alguien alguna vez fuera a hacer algo
como configurar el reloj de su iPhone a una fecha anterior a
1970 (!) Y notarás que en realidad no puedes.
Si te desplazas hacia atrás, el calendario se detiene en el 1 de enero de 1970, en
cero, porque alguien en Apple dijo, no, espera. Esa es una mala idea. Eso podría causar un problema. Así que establecieron la época Unix, como se la llama,
el tiempo cero, como límite. Pero si configura el tiempo de su teléfono cerca de
cero, entonces en algún otro lugar del código, hay una
verificación: tal vez intenta hacer un cálculo del tiempo de la batería, tal vez simplemente ejecuta los cálculos sobre cuándo fue la última
llamada, o…
Bueno, es algo que nadie ha
resuelto aún. Pero haga lo que haga esa verificación, termina con una fecha anterior al 1 de enero de 1970, que debería ser un número entero negativo… excepto que no lo es. Está completamente envuelto, te está dando una fecha veinte veces más larga que la vida útil esperada del universo.
Y sospecho que es posible que no funcione
tan bien para mostrar esa fecha. Pero sea lo que sea, provoca lo que formalmente se
conoce como "comportamiento indocumentado" e informalmente se conoce como accidente. Ahora, debo decir que, como siempre que intento
solucionar un error en un producto Apple, esto
es una especulación: es poco probable que alguna vez confirmen exactamente
lo que sucedió, y probablemente fue un poco más sutil que
esto. Y hay otro tipo de entero binario
, llamado entero con signo, que sí maneja números negativos… pero esa es una historia para otro momento. ¿ Incluso si esto no es exactamente lo que lo causó? Bueno, con suerte evitará que cometas el
mismo error en tu código en el futuro. [¿Traduciendo estos subtítulos? ¡Agrega tu nombre aquí!].