Apple T2 Security Chip: ¿Se puede recuperar los datos de un SSD cifrado?

(Gracias Jaime) Me apunta Jaime que Apple ha dejado una puerta para poder recuperar los datos del SSD de un MMac en caso de que se estropee parte de la placa base. Como comentaba en Apple T2 Security Chip Overview, por defecto el chip T2 del Mac cifrará el contenido de la SSD aunque no se haya configurado FileVault. Bien, pues suponiendo que parte de la circuitería de la placa base funcione, especialmente la parte de Secure Enclave del T2 y el bus thunderbolt funcione, parece ser que Apple tiene un modo de funcionamiento que permitiría extraer los datos del SSD del ordenador.

Esto, sin embargo, presenta de nuevo un problema: Si te roban el portátil y no tienes activado FileVault, podrían extraer tus datos sin dificultad. En todo caso, el T2 lo que permitiría es evitar que alguien use la SSD en otro ordenador, atando esa SSD a un ordenador determinado.

El chip T2 está involucrado en el cifrado del disco (su motor de cifrado está en el bus que comunica la CPU/RAM con el SSD), lo que sería interesante ver es como la clave que se genera para cifrar el disco depende de las claves del T2 o es independiente.

Darling: Capa de emulación de binarios de OS X en Linux

Darling es un software que provee una capa de emulación de Mac OS X sobre Linux. Su objetivo es permitir la ejecución de binarios de OS X sin modificar sobre Linux. En el estado actual del proyecto, no puede ejecutar aplicaciones qure usen el entorno gráfico de OS X, pero si puede ejecutar herramientas en línea de comando como toda las herramientas de compilación en línea que incluye el XCode. Adicionalmente el proyecto tiene un componente llamado darling dmg. Ambos proyectos están publicados con la licencia GPL3.

Si fuera capaz de correr algo similar al entorno de OS X 10.4 (Tiger) o 10.5 (Leopard), me encantaría. A pesar de los años que llevo usando OS X (actualmente usio High Sierra), esas dos versiones del sistema, sumado a la línea de comando,cubrían muchas de mis necesidades. Si eso le añadimos un API Carbon y el Cocoa, podía ser entretenido :)

Aunque todavía le queda mucho camino por recorrer, Wine empezó exactamente igual y a día de hoy es capaz de ejecutar un amplio catálogo de software.

Macbook Pro 2018 y múltiples monitores: problemas de imagen

Durante estos últimos cinco años he estado usando un Macbook Pro de finales de 2013. Lo tenía conectado a dos monitores Dell modelos U2415 uno usando el puerto HDMI y otro con el Display Port. En estos años de uso intensivo no he tenido ningún tipo de problemas de imagen con los monitores.

Recientemente, me han cambiado el ordenador del trabajo a un Macbook Pro de última generación. Este ordenador utiliza puertos USB-C para conectarse con periféricos, incluido los monitores. Con dos cables USB-C a DisplayPort puedo conectar ambos monitores al Macbook y seguir trabajando como hacía con el ordenador viejo. Sólo que de serie, la calidad de imagen deja bastante que desear: halos en el renderizado de las letras, trazas azules en las mismas. Una calidad de imagen pésima.

Tras buscar un rato por Internet encontré este artículo donde explica el porqué del problema y cómo se soluciona.

Los monitores actuales pueden comunicarse con los dispositivos a los que están conectados. Esto se consigue transmitiendo la información definida en el Extended Display Identification Data a la tarjeta gráfica del ordenador por un bus. Por desgracia, los monitores no siempre transmiten esa información de manera correcta a los ordenadores, y pueden aparecer algunos artefactos como los que ocurren entre el Macbook Pro y esos monitores Dell. Concretamente, en el caso del U2415 está transmitiendo mal la manera de codificar el color, diciendo que soporta el espacio de color YCrCb cuando realmente debe ser RGB. El Mac prefiere usar el primer sistema - se supone que el monitor le ha dicho que soporta ambos - y la calidad de imagen se degrada.

¿Cómo puede solucionarse ese problema?. Bien, pues es necesario sobrescribir la información EDID que ha mandado el monitor con una configuración que desactive el espacio de color YCrCb para ese monitor. Es necesario leer la información que nos da el monitor, parchearla y posteriormente hacer que el Mac la utilice en vez de la que le está proporcionando el monitor. Para ello es necesario generar unos ficheros de configuración que se deben de instalar (al menos en High Sierra) en:

/System/Library/Displays/Contents/Resources/Overrides

Este directorio se encuentra protegido por el sistema, con lo cual será necesario arrancar en modo de recuperación (cmd - r), ejecutar un terminal y copiar la información a dicho directorio.

¿Cómo generamos los archivos de configuración necesarios?. Con ayuda de este script. Lo bajamos, lo ejecutamos en nuestro ordenador y nos generará unos directorios y ficheros con la información EDID de los monitores que tengamos conectados, parcheando la misma para que use sólo el espacio de color RGB. Por ejemplo, en el caso de mi ordenador me genera la siguiente estructura

DisplayVendorID-10ac
  DisplayProductID-a0b8
  DisplayProductID-a0bc

Arrancando el sistema en modo de recuperación y copiando ese directorio:

cp -r DisplayVendorID-10ac /System/Library/Displays/Contents/Resources/Overrides

Sólo debe de copiarse la configuración generada para aquellos monitores que tengamos problemas. Una vez copiada la configuración, reseteamos el ordenador para que tenga efecto.

Borrado seguro en macOS Sierra

Hasta la versión 10.11 de macOS (El Capitan), el sistema operativo instalaba el comando srm, el cual se podía utilizar para hacer un borrado seguro de los ficheros,usando el métido Gutmann (opción -G). Apple partió de una versión semiabandonada de srm que fue actualizando en sus propias fuentes. Actualmente la versión de Sourceforge tiene los cambios y mejoras introducidos por Apple.

Si se quiere instalar en Sierra, se puede bajar las fuentes (última versión 1.2.15) , compilar e instalar de la siguente manera:

$ ./configure --prefix=/usr/local
$ make
$ sudo make install

A partir de macOS Sierra (OS X 10.11) Apple ha añadido una nueva opción al comando rm que realiza tres sobrescrituas del fichero antes de eliminarlo del disco:

-P    Overwrite regular files before deleting them. Files are
      overwritten three times, first with the byte pattern 0xff,
      then 0x00, and then 0xff again, before they are deleted.

¿Por qué se ha eliminado el comando srm?. Porque a día de hoy, las unidades de disco sólido (SSD) que traen de serie los Mac soporta el comando trim, donde el sistema operativo le indica a la unidad que bloques han quedado libres, encargándose la unidad de borrarlos internamente. De esta manera se evitan escrituras innecesarias a los bloques de datos.

Apple: App Development with Swift

Si hay algo que tengo claro que ha contribuido al éxito de diversas plataformas en el mundo de la informática ha sido la disponibilidad de un buena documentación y herramientas asequibles para el desarrollo. En el lado de la documentació Apple ha decido poner a disposición de los usuarios de iOS y OS X una serie de libros gratuitos para aprender a programar en su plataforma.

El libro se titula App Development with Swith, en el contenido desarrolla los rudimentos básicos de la programación de aplicaciones para entornos Apple usando el lenguaje Swift. Se trata de un libro interactivo en formato iBooks donde a través de sus casi 900 páginas se va introduciendo el lenguaje Swift y las diferentes librerías y herramientas en las que se apoya para crear aplicaciones para los entornos Apple.

Imagen ISO de un CD/DVD en MacOS El Capitan

Hasta OS X 10.10, la utilidad de DiskUtil.app del sistema operativo permitía generar imágenes en formato ISO de cualquier DVD o CDROM. Sin embargo, esta opción ha desaparecido a partir de la versión 10.11 de El Capitan. ¿Cómo generar una imagen, entonces?, pues se puede hacer fácilmente con la utilidad de línea de comandos hdiutil.

Para obtener la imagen del CD/DVD se usará la opción -srcdevice de la opción create y se especificará la opción -format UDTO para que sea el formato ISO necesario. Estas órdenes deben de ejecutarse con un usuario con privilegios de administrador y es necesario que el CD/DVD introducido en la unidad, esté desmontado:

$ mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk2s0 on /Volumes/CODONICS032700 (cd9660, local, nodev, nosuid, read-only, noowners)
$ sudo umount /dev/disk2s0
Password:
$ sudo hdiutil create -srcdevice /dev/disk2s0 -format UDTO /Users/cterron/salida.iso
Leyendo CODONICS032700                   (Apple_ISO: 0)…
...............................................................................
Tiempo transcurrido: 21.619s
Velocidad: 1.7Mbytes/s
Ahorro: 0.0%
created: /Users/cterron/salida.iso.cdr
$ file /Users/cterron/salida.iso.cdr 
/Users/cterron/salida.iso.cdr: ISO 9660 CD-ROM filesystem data 'CODONICS032700                 '

En esta secuencia de órdenes y su salida, el dispositivo de CDROM equivale a /dev/disk2s0 y lo averiguamos con la orden mount.

Mac OS X: Configurar paths y uso de path_helper

Estaba configurando algunos directorios en la ruta de búsqueda de ejecutables (PATH) de mi OS X y en principio recurrí a modificar mi $HOME/.profile - uso bash como shell - añadiendo las nuevass rutas a la variable PATH, si estas rutas no están añadidas con un código similar al siguiente:

DIRS=(/usr/local/java/maven/bin)
for d in ${DIRS[@]}; do
    if [[ !  ":$PATH:" == *":$d:"* ]]; then
       PATH=$PATH:$d
    fi
done
export PATH

Normalmente, si quería que ese PATH estuviera disponible en todo el sistema, solía modificar uno de los scripts en /etc que se ejecutan cuando el usuario hace login. Sin embargo, viendo el valor de la variable en mi OS X me di cuenta que había algunos directorios en el PATH que habían sido añadidos por alguno de los paquetes que he ido instalado en el sistema a lo largo del tiempo. He buscado qué mecanismo utiliza OS X para establecer esas ruta en la configuración, encontrando la respuesta en en esta entrada de StackOverflow: OS X utiliza un mecanismo llamado path_helper para configurar la variable PATH.

path_helper lee los directorios de búsqueda por defecto de ejecutables de /etc/paths y luego los ficheros que estén en /etc/paths.d y compondrá las rutas de búsquedas definidas en la variable PATH de acuerdo al contenido de los mismos.

Si se quiere añadir una ruta, por ejemplo /usr/local/java/maven/bin al sistema, basta con crear un fichero /etc/path.d/maven donde cada línea especifica una ruta donde se deben de buscar los ejecutables y path_helper se encargará del resto.

Este mecanismo también se usa para las rutas de las páginas de manual. Las rutas por defecto se definen en /etc/manpaths y se pueden añadir otras en el directorio /etc/manpaths.d

La ventaja de este tipo de mecanismos es que nos permite no tener que tocar scripts del sistema que pueden machacarse con posteriores actualizaciones.