Cómo reconstruir los PDF de Epstein a partir de adjuntos con la codificación original

• El archivo de correos de Epstein publicado por el Departamento de Justicia de EE. UU. ha recibido fuertes críticas por errores graves causados por una codificación incorrecta y una censura excesiva
• Algunos correos incluían adjuntos en formato Content-Transfer-Encoding: base64 tal como estaban, por lo que al recuperar esos datos se puede reconstruir el PDF original
• Sin embargo, por la baja calidad del OCR, los problemas para distinguir entre 1 y l en la fuente Courier New y la mala calidad del escaneo, la restauración automática es casi imposible
• El autor intentó la recuperación usando tesseract, Adobe Acrobat Pro y AWS Textract, entre otros, pero todos dieron resultados incompletos
• Este caso deja en evidencia los límites de la informática forense digital y de las técnicas de restauración documental, y se plantea como un reto técnico que la comunidad debe abordar de forma colaborativa

---

Problemas en los materiales publicados por el Departamento de Justicia

• El archivo de Epstein publicado recientemente se distribuyó con censura excesiva, desde nombres de cómplices hasta fotos de mujeres sin relación con el caso
  • Algunos archivos quedaron dañados por errores de codificación Quoted-Printable y no podían abrirse
  • Incluso se expusieron credenciales de correo, lo que permitió que usuarios de Reddit accedieran a la cuenta de Epstein
• Este manejo tan deficiente llevó a cuestionamientos sobre la falta de profesionalismo del Departamento de Justicia encabezado por Pam Bondi

Hallazgo de adjuntos en base64

• En el correo EFTA00400459 se encontraron 76 páginas de datos codificados en base64
  • Se trataba del archivo DBC12 One Page Invite with Reply.pdf, codificado para su envío por SMTP
  • En teoría debería bastar con copiarlo y restaurarlo con el comando base64 -d > output.pdf, pero en la práctica solo existía un escaneo con OCR, con numerosos errores
• El resultado del OCR incluía inserción de caracteres incorrectos, omisiones y caracteres base64 no válidos (por ejemplo: [, ,), por lo que no se podía decodificar

Problemas de OCR y tipografía

• Al reintentar el OCR con Adobe Acrobat Pro y tesseract, en todos los casos aparecieron espacios insertados y errores de reconocimiento de caracteres
• Aunque en tesseract se limitó el conjunto de caracteres a los válidos para base64, persistieron problemas de longitudes de línea inconsistentes y cortes en el reconocimiento parcial
• La causa principal era la fuente Courier New, donde distinguir entre 1 y l es casi imposible
  • Debido al escaneo JPEG de baja resolución y a los artefactos de compresión, incluso la identificación visual resulta difícil
  • Por eso, la corrección manual se vuelve indispensable, y al decodificar hay que probar intercambiando 1 y l

Intentos de recuperación y comparación de herramientas

• imagemagick y ghostscript fallaron por exceso de memoria al procesar archivos grandes, por lo que se usó pdftoppm como alternativa
• AWS Textract mostró los mejores resultados, pero aun así mantuvo errores en la longitud de las líneas y resultados no deterministas
  • Se duplicó el tamaño de las imágenes de entrada para mejorar la tasa de reconocimiento, pero no se logró una restauración completa
• El intento de reconstruir la estructura del PDF con qpdf falló debido a una tabla cross-reference dañada

Propuestas de la comunidad y discusión posterior

• Al final del texto, el autor propone a la comunidad intentar recuperar otros adjuntos
  • Al buscar Content-Transfer-Encoding y base64, aparecen algunos datos potencialmente útiles
• Varios usuarios propusieron enfoques diversos, como OCR basado en ML, entrenamiento de CNN por tipografía y crowdsourcing tipo CAPTCHA
  • Algunos compartieron casos exitosos de recuperación de PDF y reportaron que usar pdfimages daba resultados más nítidos que pdftoppm
• Finalmente, se discutieron técnicas avanzadas de recuperación, como algoritmos para automatizar la distinción entre 1/l, detección de errores basada en descompresores en streaming y comparación a nivel de píxel

Importancia técnica

• Este caso muestra cómo los errores de codificación en documentos digitales y las limitaciones del OCR pueden obstaculizar el acceso real a la información
• También destaca la importancia del control de calidad en el procesamiento digital de evidencia legal y de las tecnologías de automatización forense documental
• Los intentos de recuperación colaborativa de la comunidad se valoran como un ejemplo de transparencia en los datos públicos y de posibilidad de verificación técnica

[GN⁺]

Comentarios de Hacker News

• Parece que el equipo del Departamento de Justicia de Pam Bondi no puso a su mejor gente en esto

  • Al principio fue interesante la conversación por mensajes entre agentes del FBI. Me hizo pensar que quizá fue cumplimiento malicioso (malicious compliance), haciéndolo a propósito de forma desastrosa para que la información se filtrara antes de que la volvieran a censurar
  • Como internet le está encontrando todos los errores, al final esto se está resolviendo bastante bien por crowdsourcing. La gente sigue corrigiendo fallas

• Comparten un script hecho por Claude Opus
  Enlace al script / Salida de texto / Versión depurada
  Genera un PDF legible, al menos en la primera página

  • Me pregunto si alguien podría volver a exportarlo como un PDF normalizado o compartir capturas de pantalla. Todos mis lectores de PDF se niegan a abrirlo
  • Se confirmó que fue un evento público con 450 asistentes. Los nombres coinciden entre el artículo de Mount Sinai y el artículo de Business Insider, aunque la fecha es distinta
  • Gran trabajo

• Tesseract puede entrenarse con una fuente específica. Parece un buen punto de partida
  Referencia: Guía de datos de entrenamiento de Tesseract

• Esto es un problema de decodificación binaria de PDF. Como el número de codificaciones posibles es limitado, propongo este enfoque

  1. Usar un decodificador de PDF de código abierto
  2. Decodificar los bytes hasta el primer carácter ambiguo
  3. Si el siguiente bit es válido, asumir 1; si no, asumir l
  4. Si ambos son válidos, hacer backtracking
     Con esto se pueden probar rápido solo los caracteres intermedios, así que la búsqueda completa podría hacerse de forma lineal
  • Pero como hay una etapa de compresión en medio, podría haber mucho más backtracking
  • Esto suena como algo ideal para afl

• Esto parece un nerd snipe, pero en realidad se podría terminar más rápido con fuerza bruta. Si 76 personas teclean una página cada una, se acaba antes de que salga la entrada del blog

  • Incluso una sola persona podría teclear las 76 páginas. Antes hacía este tipo de trabajo seguido
  • Pero lograr que 76 personas hagan una transcripción exacta no es nada fácil
  • Yo no tengo 76 amigos, así que tocaría publicarlo en Craigslist o Fiverr. Suena bastante complicado de coordinar

• Como PDF es un formato tan complejo, creo que sería mejor que el gobierno creara y estandarizara un nuevo formato abierto seguro

  • XPS es un estándar oficial basado en XML y tiene soporte open source bastante decente, pero la calidad de las herramientas es mala y sigue siendo complejo
    DjVu es simple y tiene buenas herramientas open source, pero le faltan funciones
    TIFF en realidad es incluso más complejo que PDF, así que no sirve
    Referencia: XPS, DjVu, TIFF
  • Pero creo que esto no es un problema de herramientas, sino de una actitud de desprecio por la ley o de hacer las cosas mal a propósito
  • Aunque se cree un formato nuevo, en 3 a 5 años terminará siendo tan complejo como PDF
  • Medio en broma, medio en serio, también está la propuesta de usar JPEG

• En el buscador de justice.gov se pudieron encontrar varias versiones del mismo correo
  Original: EFTA00400459.pdf
  Versiones adicionales:
  EFTA02153691.pdf
  EFTA02154109.pdf
  EFTA02154246.pdf
  Comparar varias versiones probablemente facilite mucho las cosas

  • También se encontró una versión con otra codificación base64 y otra fuente: EFTA00775520.pdf.
    El problema de “1” y “l” sigue igual, pero puede servir como referencia

• Pensé en probar todas las permutaciones posibles de combinaciones (1, l). Si asumimos 76 páginas × 69 líneas × 1 aparición, eso da 2^5244 posibilidades. ¿Alguien con CPU de sobra?

  • En realidad es mucho más fácil. Basta con revisar secuencialmente si cada corrección decodifica a una estructura de PDF válida.
    Si la compresión es la predeterminada, los checksums lo hacen todavía más fácil. Pero no se puede con herramientas existentes; habría que construir un test harness instrumentado dentro del decodificador
  • O si no, crear una criptomoneda tipo Epsteincoin para juntar poder de cómputo y resolver esto

• Detalles del evento: Dubin Breast Center 2nd Annual Benefit (Archivo)

  • En el póster del evento dice que fue la gala benéfica por el segundo aniversario del Dubin Breast Center, celebrada el 10 de diciembre de 2012 en el Mandarin Oriental,
    en honor a Elisa Port y la familia Ruttenberg.
    La conductora fue Cynthia McFadden y hubo presentaciones de varios músicos

• pdftoppm y Ghostscript (invocado a través de Imagemagick) son lentos porque rerasterizan páginas completas
  Extraer directamente las imágenes escaneadas con pdfimages o mutool es mucho más rápido
  En pruebas, pdfimages fue 13 veces más rápido que pdftoppm