Testeando "UNREDACTER", para tomar el texto pixelado redactado e invertirlo de nuevo a su forma original

Desafío aceptado

Así que existe una herramienta llamada Depix que intenta hacer exactamente esto a través de un proceso realmente inteligente de buscar qué permutaciones de píxeles podrían haber resultado en ciertos bloques pixelados, dada una secuencia De Bruijn de la fuente correcta. Me gusta mucho la teoría de esta herramienta, pero un investigador de Jumpsec señaló que tal vez en la práctica no funcione tan bien como te gustaría. En ejemplos del mundo real, es probable que obtenga variaciones menores y ruidos que arrojan una llave en los engranajes. Luego lanzaron un desafío a cualquiera, ofreciendo un premio si podía quitar la redacción de la siguiente imagen:

¡¿Cómo podría rechazar tal desafío?!

Cómo funciona la pixelación

La pixelación se ve así:

El algoritmo es bastante simple; divide su imagen en una cuadrícula de un tamaño de bloque dado (el ejemplo anterior es 8x8). Luego, para cada bloque, establece el color de la imagen censurada igual al color promedio del original para esa misma área. Eso es todo: solo un promedio móvil de píxeles para cada bloque.

El efecto es una especie de "difuminación" de la información de la imagen en cada bloque. Pero si bien se pierde parte de la información en el proceso, se filtra mucha. Y es esta información filtrada la que usaremos a nuestro favor.

En particular, este algoritmo está ampliamente estandarizado ya que es muy simple. Entonces, no importa si haces esta redacción en GiMP, Photoshop o básicamente cualquier otra herramienta, la redacción resultará igual.

Para nuestra prueba de concepto, supongamos que el atacante sabe:

1. El tipo de fuente del texto redactado.
2. El tamaño de fuente del texto redactado
3. Que la redacción es de texto para empezar

Estas son suposiciones bastante razonables, afirmaría, ya que el atacante en un escenario realista probablemente habría recibido un informe completo, con solo una parte eliminada. En nuestro texto de desafío, puede ver algunas palabras justo encima del texto pixelado que nos brinda esta información.

Los muchos problemas para vencer la redacción

La clave en la que nos estamos enfocando es que el proceso de redacción es inherentemente local. En términos criptográficos, diríamos que no tiene difusión . Un cambio de un píxel en algún lugar de la imagen original SOLO afecta el bloque redactado al que pertenece, lo que significa que podemos (en su mayoría) adivinar la imagen carácter por carácter. Haremos una búsqueda recursiva en profundidad en cada carácter, calificando cada suposición por qué tan bien coincide marginalmente con el texto redactado.

Básicamente, adivinamos la letra "a", pixelamos esa letra y vemos qué tan bien coincide con nuestra imagen redactada. Luego adivinamos la letra “b”, y así sucesivamente. No suena tan difícil, ¿verdad? Bueno, todavía hay un montón de problemas logísticos que superar que pueden no ser tan obvios al principio. Profundicemos más en eso.

El problema del sangrado del personaje

El primer problema que encontramos de inmediato es que los caracteres de nuestro texto no se alinean 1:1 con los bloques de la redacción. Esto significa que una suposición correcta dada podría tener algunos bloques incorrectos en el borde más a la derecha. Para ver lo que quiero decir, echa un vistazo a este ejemplo:

Puedes ver que las letras “t” y “h” comparten una columna de bloques. Entonces, si tratamos de adivinar la letra "t", la columna de bloques más a la izquierda resulta correcta, pero los más a la derecha están un poco equivocados.

Píxeles correctos vs. Guess para “t” vs. Diferencia

La razón por la que la segunda columna está mal es porque la letra "h" está ahí estropeando las cosas. Si nos fijamos solo en esto, podría concluir que la letra "t" era una primera letra incorrecta, ya que casi la mitad de los bloques son totalmente incorrectos.

Lo primero que intentamos fue evitar contar el bloque más a la derecha de cualquier conjetura. Es la columna que tendrá el mayor sangrado y puede tener un poco de error. El problema con esto era que, en la práctica, reducía tanto el tamaño total de nuestra conjetura que empezabas a recibir falsos positivos. Siempre existe la posibilidad de que su letra se alinee accidentalmente y produzca una coincidencia por pura casualidad, y esta posibilidad aumenta cuando hay menos bloques para considerar.

Entonces, en cambio, lo que hicimos fue cortar el bloque de comparación en el límite de la letra misma. Por lo tanto, nuestra diferencia se vería así:

Puede ver que la calidad de nuestra coincidencia aumentó mucho, ya que estamos incluyendo menos de esa área incorrecta a la derecha. Esto se debe a que cortamos la comparación en el borde donde termina la "t":

El beneficio de hacerlo de esta manera es que cuanto más se extiende nuestro carácter de suposición en el bloque, más probable es que el bloque sea una buena suposición y, por lo tanto, mantenemos más del bloque. Por lo tanto, cortará automáticamente la mayor parte del bloque cuando la suposición sea mala y mantendrá la mayor parte del bloque cuando sea buena. 

El problema de los espacios en blanco

Un subconjunto específico del problema de desangrado de caracteres es que los espacios en blanco tienden a romper algunas de nuestras suposiciones sobre cómo funciona la adivinación de caracteres. Inherente a todo este problema está la suposición de que cuando adivinamos un carácter correcto, esperamos que la versión pixelada resultante se parezca principalmente a la imagen del desafío.

Sin embargo, esto no siempre es cierto cuando el carácter que suponemos es un espacio en blanco. Cuando eso suceda, los bloques pixelados serán superados por completo por el siguiente personaje. Tome este ejemplo, adivinando "esto es" (con un espacio final):

Luego, esto se pixela como se muestra a continuación, con una columna en blanco al final, como era de esperar:

El problema es que en la imagen de la solución, hay otro carácter después del espacio. ¡Sangra tanto que nuestra suposición correcta parece estar completamente equivocada!

Hay más de una manera de abordar este problema. La más obvia es nunca hacer conjeturas de espacios en blanco por sí solo, y en su lugar emparejarlo con algún otro carácter que no sea un espacio en blanco. De esa manera podemos controlar al personaje que se desangra. Si bien esto "funciona", efectivamente duplica el juego de caracteres disponible. Esto ralentiza todo el proceso a paso de tortuga.

En cambio, lo que podemos hacer es hacer una excepción especial para las conjeturas de espacios en blanco que les den más indulgencia en lo que se considera una "buena" conjetura. En las pruebas, parecía que el sangrado nunca es tan malo como para estar más allá de un umbral más bajo. Es un poco chapucero, te lo concedo, pero parece funcionar.

El problema de la fuente de ancho variable

La mayoría de las fuentes con las que la gente escribe son de ancho variable. Esto significa que la cantidad de espacio horizontal que ocupa cada letra depende de la letra misma. Por ejemplo, una "w" ocupa más espacio que una "i". Esto contrasta con las fuentes monoespaciadas, que deliberadamente espacian las letras de modo que cada una ocupe la misma cantidad de espacio horizontal.

Ancho variable:

iiiii

www

Monoespaciado:

iiiii
www

Lo que esto significa para nuestro ataque (que se supone que está en una fuente de ancho variable) es que cada letra adivinada tiene un efecto en cascada a la derecha. Si haces la conjetura:

esto es genial

Entonces todas las letras futuras estarán desactivadas, incluso si las letras son "correctas".

Esto suena como un gran problema, pero en realidad no es tan malo. Simplemente significa que tenemos que ceñirnos a una búsqueda recursiva en profundidad y no tratar las letras como artefactos individuales e independientes. La búsqueda recursiva en profundidad funciona bien aquí porque, naturalmente, tiene en cuenta ese orden. Funciona de la siguiente manera:

Supongamos que tenemos la suposición actual de:

esto es su

Lo que hacemos es probar cada carácter para la siguiente letra y ver cuáles coinciden razonablemente bien con la imagen redactada. Terminaremos con un subconjunto de conjeturas "buenas", tal vez "p" y "q", ya que p es correcta y q se parece bastante. Luego comenzaremos todo este proceso de adivinar nuevamente la nueva cadena de "esto es excelente" en la cadena hasta que lleguemos a un callejón sin salida sin buenas conjeturas. En ese momento, la pila de llamadas de función retrocederá naturalmente para probar nuestra otra suposición q.

Y así sucesivamente, hasta que hayamos agotado todas las conjeturas "buenas" que existen.

El problema de la inconsistencia de fuentes

Da la casualidad de que los diferentes motores de renderizado producen imágenes ligeramente diferentes, incluso para lo que debería ser exactamente la misma fuente. Mira estas dos capturas del mismo texto. En la parte superior está la representación de GiMP en Sans Serif y en la parte inferior está FireFox:

Son casi idénticos, pero no del todo. Hay dos cosas que se destacan; uno es la longitud. Puedes ver que la imagen superior es un POCO más larga. Para cuerdas lo suficientemente largas, esto puede tener un efecto en cascada que arruinará todo. La otra diferencia es cómo se rasteriza el texto; la línea inferior es un poco más audaz que la superior. Este podemos manejarlo principalmente ajustando el brillo, pero es un dolor total.

Para Unredacter, usamos Electron para tomar capturas de pantalla de una ventana HTML local sin encabezado. Entonces, el renderizador será esencialmente Chrome. La mayoría de las veces, esto no es un problema. Pero si su texto redactado se procesó utilizando un programa realmente extraño que no cumple con los estándares, entonces podría terminar desviándose un poco del curso. Mantenlo en mente.

Si alguien quiere escribir un envoltorio para Unredacter que genere conjeturas usando MS Word a través de alguna máquina de envoltorios y macros de Rube Goldberg, puede intentarlo.

El problema de la compensación de pixelación

Al pixelar una imagen, hay dos grados de libertad que deben tenerse en cuenta: las coordenadas de desplazamiento x e y. ¿Pero qué diablos son esos?

Considere la imagen de nuestro texto de suposición separado en bloques de 8x8:

Si piensa en esto como una cuadrícula estática, entonces hay 64 ubicaciones distintas para colocar el texto en esa cuadrícula. A esto lo llamamos el "desplazamiento" de x e y. Dependiendo del desplazamiento que elija, puede producir imágenes dramáticamente diferentes:

Diferentes valores de compensación para el mismo texto

Además, no hay forma de que el atacante sepa cuáles fueron estas compensaciones. (A diferencia de la fuente y el tamaño de fuente). El desplazamiento se determina en la mayoría de los editores como GiMP por el proceso mayoritariamente aleatorio de dónde hizo clic el usuario al hacer un cuadro delimitador. Si hubieran hecho clic en un solo píxel hacia arriba o hacia abajo, ¡la pixelación habría creado una imagen bastante diferente!

La buena noticia aquí es que no hay TANTAS posibilidades para las compensaciones. Hay permutaciones de tamaño de bloque ^{2 .} Para un tamaño de bloque de 8, eso hace 64 compensaciones para probar. En nuestro texto de desafío, el tamaño del bloque es 5, lo que significa que solo hay 25 compensaciones para probar.

Entonces, el primer paso de Unredacter es descubrir qué compensación se usó. Hacemos esto probando cada desplazamiento en un ciclo y viendo si CUALQUIER letra da como resultado una buena suposición de la primera letra. Tomamos todas las compensaciones que tienen buenas conjeturas de la primera letra y las agregamos a una lista para luego intentar conjeturas adecuadas.

Resolviendo el texto del desafío Jumpsec

¡Okey! Armados con este conocimiento y una herramienta para explotarlo, echemos un vistazo a la imagen del desafío de Jumpsec nuevamente:

Una de las primeras cosas que puede notar es que tiene un poco de color curioso. ¿Lo que da? ¿No debería ser solo en blanco y negro ya que el texto es negro? ¿Nos están trolleando con letras de colores?

En realidad, no estoy 100% seguro de por qué sucede esto (ya veces no sucede), pero es un artefacto del proceso de rasterización cuando el texto se representa en la pantalla. Solo mire lo que sucede cuando acerca el texto escrito en el Bloc de notas:

Cuando Unredacter representa las letras en una ventana de Chrome sin encabezado, no aparecen artefactos coloreados, por lo que tendremos que convertir la imagen a escala de grises. Esto perderá algo de información, pero está bien. Unredacter no necesita coincidencias exactas, solo que las conjeturas sean "en su mayoría correctas". Una vez convertida, nuestra imagen de desafío se ve así:

Hay un último ajuste que tuve que hacer, y está en la fila inferior:

¡Es demasiado pequeño! El resto de los bloques son de 5x5, pero la fila inferior es de 5x3. Después de algunas horas de prueba y error, también noté que estos bloques son demasiado oscuros. Mira cómo se ve una conjetura de la letra "g", en comparación con la imagen del desafío:

Imagen de desafío vs. Guess

¿Ves cómo esa fila inferior es demasiado oscura ? Es porque cuando la imagen se pixeló, deben haber seleccionado un cuadro delimitador que no era un tamaño múltiplo de 5. Entonces, cuando el algoritmo determinó el promedio, fue un promedio sobre un área más pequeña. (Por lo tanto, más oscuro) No importa, podemos arreglarlo simplemente aclarando la última fila. Esto nos da nuestra imagen de desafío final de:

Lo siguiente es averiguar la fuente y el tamaño de fuente correctos. Afortunadamente esto no fue demasiado difícil, la imagen fue tomada en MS Notepad con la fuente predeterminada de Consolas. Después de un poco de prueba y error, descubrí que el tamaño de fuente es de 24 px. (Hice esto simplemente probando los tamaños de fuente una y otra vez hasta que la altura de la M mayúscula coincidiera). La única parte complicada de esto terminó siendo que el Bloc de notas aparentemente tiene un espacio entre letras predeterminado de -0.2px. Si intenta renderizar texto en Chrome en Consolas, es demasiado largo. Pero el espaciado entre letras de -0.2px coincide exactamente .

Arriba : Imagen del desafío original Abajo : Representación cromada sin cabeza de Unredacter

Si observa detenidamente, la "s", "e" y "c" tienen un poco más de curva en la representación del Bloc de notas. Pero esta bien. Nuevamente, no necesitamos ser 100% exactos. ¡Así de cerca!

Unredacter rápidamente se concentra en una compensación de [3, 1], ¡así que veamos cómo lo hace!

Después de correr durante unos minutos, Unredacter escupe la conjetura final de:

¡Incluso puedes ver a simple vista que nuestra suposición es bastante cercana!

Arriba : imagen original del desafío (en escala de grises y fila inferior fija) Abajo : Suposición de Unredacter

Así que contacté a Caleb Herbert en Jumpsec, ¡y me confirmaron que mi suposición era correcta!

Caleb también me pidió que no revelara la solución, así que usted que lee esto puede intentarlo usted mismo. (Está borroso arriba, y no hay forma de que puedas leer el texto borroso, ¿verdad?) Un gran agradecimiento a Jumpsec por lanzar este desafío, fue muy divertido. ¡También fue una excelente manera de probar una nueva herramienta!

La línea de fondo

Si desea consultar el código fuente de prueba de concepto de Unredacter, está disponible en nuestro GitHub aquí .

La conclusión es que cuando necesite redactar texto, use barras negras que cubran todo el texto. Nunca use nada más. Sin pixelización, sin desenfoque, sin borrosidad, sin remolinos. Ah, y asegúrese de editar el texto como una imagen. No cometas el error de cambiar tu documento de Word para que tenga fondo negro con texto negro. (Aún puedes leer eso solo resaltándolo así ).

Lo último que necesita después de hacer un excelente documento técnico es filtrar accidentalmente información confidencial debido a una técnica de redacción insegura.

Fuente: https://bishopfox.com/blog/unredacter-tool-never-pixelation