Comencemos por el principio, un gestor de arranque, también conocido como bootloader en inglés, es un programa esencial que se encarga de poner en marcha el sistema operativo cada vez que el ordenador se enciende o se reinicia. Su función principal es cargar el núcleo del sistema operativo en la memoria RAM y, una vez hecho esto, transferirle el control para que continúe con el proceso de inicio del sistema.

Linux es un sistema operativo sumamente flexible y capaz de ejecutarse en una amplia variedad de arquitecturas de hardware. Sin embargo, no en todas las arquitecturas donde puede ejecutarse Linux es estrictamente necesario un gestor de arranque. Su presencia depende en gran medida de la estructura del sistema y del contexto en el que se use el sistema operativo. 

En el caso de Windows, el gestor de arranque juega un papel fundamental en el proceso de inicio del sistema. Windows utiliza un bootloader llamado Windows Boot Manager (BOOTMGR), que se encarga de localizar y cargar el núcleo del sistema operativo desde el disco duro a la memoria RAM. Este gestor de arranque trabaja en conjunto con el BCD (Boot Configuration Data), una base de datos que almacena la información de configuración del arranque. A diferencia de Linux, donde se pueden emplear distintos bootloaders según la distribución y el hardware, Windows está diseñado para operar con su propio gestor de arranque, optimizado para su ecosistema y asegurando compatibilidad con su arquitectura cerrada.

En el caso de macOS, el gestor de arranque es boot.efi, que forma parte del firmware EFI (Extensible Firmware Interface) utilizado en los Mac modernos. Cuando se enciende el equipo, el firmware EFI detecta el hardware y busca el sistema operativo en el disco de arranque. Luego, boot.efi se encarga de cargar el núcleo de macOS en la memoria RAM y transferirle el control para completar el proceso de inicio. A diferencia de Windows y Linux, macOS está diseñado para funcionar exclusivamente en hardware de Apple, lo que permite una integración más controlada entre el software y el hardware, asegurando estabilidad y optimización en el arranque del sistema.

Volviendo a Linux, en arquitecturas de procesador como x86 y x86_64, desarrolladas por Intel y AMD, es común que se requiera un gestor de arranque para iniciar el kernel de Linux. Entre los gestores más utilizados en estos entornos se encuentran GRUB o LILO. No obstante, en arquitecturas como ARM y ARM64, que están diseñadas para ofrecer un alto rendimiento con un consumo energético reducido, no siempre es indispensable un gestor de arranque tradicional. En estos casos, el firmware o un bootloader integrado en el hardware, como U-Boot en sistemas embebidos, puede encargarse directamente de la carga del kernel. Algo similar ocurre con la arquitectura PowerPC en algunos sistemas embebidos, donde el firmware gestiona la carga del kernel debido a que la configuración del hardware es generalmente fija, eliminando la necesidad de un gestor de arranque avanzado.

Dentro de los gestores de arranque más populares se encuentra GRUB (Grand Unified Bootloader), que es ampliamente utilizado en sistemas Linux. GRUB permite, además, la coexistencia de varios sistemas operativos en una misma máquina, como Linux y Windows, facilitando que el usuario pueda elegir qué sistema iniciar en cada arranque. No obstante, con el auge de la virtualización, donde un sistema operativo puede ejecutar otro dentro de sí mismo sin restricciones significativas, la utilidad de los gestores de arranque para sistemas dual-boot ha disminuido. Ya no es imprescindible elegir entre un sistema u otro al encender el equipo, pues ambos pueden ejecutarse simultáneamente y estar disponibles para el usuario en todo momento.

El origen de los gestores de arranque en Linux se remonta a LILO (Linux Loader), un gestor que en la actualidad ha quedado prácticamente obsoleto. Posteriormente, apareció GRUB Legacy, el cual tenía la limitación de ser compatible únicamente con particiones MBR y no podía ser utilizado en sistemas con UEFI, aquí es dónde está el “kit” de la cuestión.

Los esquemas de partición juegan un papel crucial en la organización de los datos en un disco duro, y los dos más comunes son MBR (Master Boot Record) y GPT (GUID Partition Table). MBR es un esquema más antiguo con restricciones significativas, como el soporte máximo para discos de 2 TB y la posibilidad de crear únicamente cuatro particiones primarias. Por otro lado, GPT es una alternativa más moderna que permite trabajar con discos de mayor tamaño y admite un mayor número de particiones. 

Otro aspecto importante del arranque del sistema está relacionado con la BIOS (Basic Input/Output System) y UEFI (Unified Extensible Firmware Interface), que son los sistemas de firmware responsables de la inicialización del hardware antes de cargar el sistema operativo. La BIOS, al ser una tecnología más antigua, trabaja generalmente en conjunto con MBR, mientras que UEFI ha sido desarrollado como su reemplazo, optimizado para funcionar con GPT. Si me dieran un euro cada vez que alguien me han dicho que el disco duro de 4Tb había dejado de funcionar, y en realidad el único problema que había es que lo estaba conectando a un ordenador con BIOS… Por otra parte UEFI ofrece diversas ventajas, como tiempos de arranque más rápidos y una mayor seguridad mediante Secure Boot.

El propósito de Secure Boot es impedir la ejecución de software malicioso en el arranque del sistema, permitiendo únicamente la carga de sistemas operativos que hayan sido firmados digitalmente por entidades de confianza. Esto ha generado conflictos con algunas distribuciones de Linux, ya que ciertos fabricantes de placas base, siguiendo las normativas de Microsoft, han configurado sus sistemas para que solo arranquen sistemas operativos firmados por esta compañía. Como resultado, al intentar instalar o ejecutar Linux en estos equipos, el proceso de arranque puede fallar debido a la activación de Secure Boot. En tales casos, es necesario deshabilitar esta función para poder instalar o iniciar el sistema operativo.

Un problema habitual ocurre cuando se intenta arrancar un live CD de Linux en un equipo con Windows que tiene activado Secure Boot en UEFI, ya que esto puede impedir la carga del sistema operativo. Es importante entender que deshabilitar Secure Boot en un ordenador con chip TPM para iniciar un live CD (por ejemplo, una distribución Linux forense) puede traer consigo implicaciones de seguridad graves, hasta el punto de dejar el sistema inutilizable. 

Además, en sistemas Linux donde Secure Boot está habilitado, pueden surgir problemas relacionados con la carga de ciertos módulos del kernel. Dado que Secure Boot garantiza que solo se ejecuten binarios firmados y verificados, si se intenta cargar un módulo que no tiene una firma válida, el sistema lo bloqueará. Esto puede afectar a controladores de hardware propietarios o módulos compilados manualmente, generando errores en el arranque. Un ejemplo típico es cuando módulos esenciales para la virtualización o la gestión de sensores de la placa base son rechazados por el sistema. En apariencia, el sistema podría arrancar con normalidad, pero algunos servicios esenciales podrían quedar inactivos debido a la imposibilidad de cargar los módulos requeridos.

El TPM (Trusted Platform Module) es un chip de seguridad diseñado para proteger claves de cifrado, garantizando la integridad del sistema durante el arranque. Este módulo permite funciones como el cifrado de disco y la autenticación segura. Actualmente, muchos ordenadores incluyen este chip de forma predeterminada, ya que Windows 11 requiere su uso para reforzar la seguridad del sistema.

– ¡Que no!, ¡que me dejes en paz, yo no necesito saber todo esto para ser forense!

– Continuemos, el TPM también desempeña un papel importante en la verificación de la integridad del sistema durante el arranque, asegurando que no haya cambios no autorizados en el hardware o software. En sistemas Windows que emplean el TPM para proteger el cifrado de BitLocker, desactivar Secure Boot puede tener consecuencias graves. Si Secure Boot se deshabilita en un ordenador con BitLocker activado, las claves de recuperación se invalidarán y el sistema pedirá que se introduzcan en el siguiente arranque. Si el usuario no dispone de estas claves, el sistema quedará bloqueado y cifrado de manera irreversible para siempre. Es decir, perderás toda la información del equipo.

– Nah, vuelvo a activar el SecureBoot y ya estará todo como antes.

– No, una vez que el equipo entre en modo seguridad, necesitarás la clave de recuperación para poder acceder a tus datos. Sí, esa misma clave sobre la que, cuando instalaste Windows, apareció un mensaje recomendando imprimirla o guardarla en otro lugar, pero que decidiste ignorar.

Y por este motivo, para ser un buen forense, no hay que saber solo cómo recuperar o interpretar datos, hay que conocer a bajo nivel cómo funcionan las distintas características de los sistemas operativos para saber lo que se puede hacer y lo que no. En este caso, un perito informático no puede poner la excusa de: “era mi primerito día” o “esto yo no lo sabía”. A la hora de trabajar con este tipo de sistemas, es necesario conocer en profundidad este tipo de circunstancias para no “liarla parda”.

Si te ha gustado este artículo, recuerda que en mi libro: “Linux, de cero a ninja”, explico estas y otras cosas en detalle. Lo puedes comprar en Amazon siguiendo este enlace.

¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.

 

Pulsa Aquí para invitarme a un café con hielo.

  Salu2.