Estructura del nuevo sistema de ficheros de Apple

  • April 22, 2017
  • tuxotron
  • APFS Overview

    APFS overview

    Apple presentó en junio de 2016 un nuevo sistema de ficheros llamado APFS (Apple File System), éste viene a reemplazar HFS+. En marzo de este año, APFS fue introducido con iOS 10.3, también disponible en macOS, pero con algunas limitaciones y en una versión todavía experimental.

    Jonas Plum a través de su blog ha publicado una entrada con información sobre la estructura de APFS. Con la ayuda de Kaitai ha ido documentando la estrucutura de este nuevo sistema de ficheros.

    Como bien dice la entrada, esto es un trabajo de ingeniería inversa en proceso, y los datos presentados pueden no ser del todo correctos.

    A modo general, algunas de las características de APFS son:

    • Usa little endian para almacenar información
    • Las marcas de tiempo usan 64bits y se especifican en nanosegundos. Empezando a partir del 1 de enero de 1970 UTC (Unix epoch)
    • El tamaño de estándar de los bloques son 4096 bytes
    • Usa copy-on_write

    En dicha entrada también se especifican algunas de las estructuras de datos presentes en APFS, así como la cabecera de las mismas.

    Aunque la información proporcionada no es muy amplia, es un comienzo y esperemos que se vayan añadiendo más datos y correcciones. Esta es una fuente genial para el analista forense.

Lista de POCs para CVEs

  • April 22, 2017
  • tuxotron
  • CVE MITRE

    Common Vulnerabilities and Exposures o CVE, es un estándar que asigna valores únicos a vulnerabilidades de seguridad. Es un proyecto subvencionado por el gobierno de los EEUU y mantenido por MITRE.

    Cuando descubres una vulnerabilidad, si el producto afectado es parte de la lista que monitoriza MITRE, puedes enviarles la información sobre la misma y si es aceptada, se le agigna un número único con el formato CVE-YYYY-XXXXX, dónde YYYY es el año y XXXXX es un número secuencial, que se reinicia cada año, lo que hace que la combinación YYYY-XXXXX sea única. A parte de a la asignación de dicho número, a éste también se le asigna un estado, de forma que se puede tracear si la vulnerabilidad ha sido corregida o no y en qué versión del producto. Normalmente cuando la vulnerabilidad ha sido corregida, el descubridor de la misma, suele liberar los detalles de explotaión y/o un ejemplo de cómo explotarla, lo que también se conoce como prueba de concepto o Proof Of Concept (POC).

    Este repositorio en Github, contiene una gran lista de POCs para CVEs. La lista provee una pequeña descripción sobre la vulnerabilidad en si, y un enlace al código de ejemplo que la explota.

    Este es un recurso muy educativo, donde podemos ver exploits de vulnerabilidades reales.

Cómo crear tu propio editor de texto

  • April 6, 2017
  • tuxotron
  • Setup

    Si hay una herramienta básica y necesaria en un sistema operativo, además de la shell, ésta es el editor de texto. Estos pueden ser super simples, aún recurdo haber usado cosas como Ed o Edit, o muy potentes, por nombrar alguno: Vi/Vim, Emacs, Sublime Text, VSCode, Atom, etc

    Aunque el concepto del editor de texto es simple, la implementación o creación de una herramienta de este tipo, se puede convertir en una tarea bastante compleja, dependiendo de cuanta funcionalidad quieras añadir.

    Si alguna vez te has preguntado cómo crear un editor de texto o simplemente quieres crear uno, este tutorial te guía, en 184 pasos, a la creación de un editor de texto básico, escrito en C, en poco más de 1000 líneas de código sin dependecias externas. Éste se llama Kilo.

    El tutorial está dividido en 8 apartados:

    El código está disponible en Github, en caso de que te quedes atascado o tengas alguna duda, y en este otro repositorio tenéis el tutorial en sí.

    Aquí tenéis un pequeño vídeo con el resultado final: