web-dev-qa-db-fra.com

Comment faire pour exécuter un programme sans système d'exploitation?

Comment lancez-vous un programme sans système d'exploitation? Pouvez-vous créer des programmes d'assemblage que l'ordinateur peut charger et exécuter au démarrage, par exemple. démarrer l'ordinateur à partir d'un lecteur flash et il exécute le programme qui se trouve sur le processeur?

assemblyx86operating-systembootloaderosdev
220
user2320609

Comment lancez-vous un programme sans système d'exploitation?

Vous placez votre code binaire à un emplacement recherché par le processeur après le redémarrage (par exemple, l'adresse 0 sur ARM).

Pouvez-vous créer des programmes d'assemblage que l'ordinateur peut charger et exécuter au démarrage (par exemple, démarrer l'ordinateur à partir d'un lecteur flash et exécuter le programme qui se trouve sur le lecteur)?

Réponse générale à la question: cela peut être fait. On parle souvent de "programmation en métal nu". Pour lire à partir d'un lecteur flash, vous voulez savoir ce qu'est la clé USB et disposer d'un pilote pour travailler avec cette clé USB. Le programme sur ce lecteur devrait également être dans un format particulier, sur un système de fichiers particulier ... C’est quelque chose que les chargeurs d’amorçage font habituellement, mais votre programme peut inclure son propre chargeur de démarrage afin qu’il soit autonome, si le charger un petit bloc de code.

Beaucoup de cartes ARM vous permettent de faire certaines de ces choses. Certains ont des chargeurs de démarrage pour vous aider avec la configuration de base.

Ici vous pouvez trouver un bon tutoriel sur la façon de faire un système d’exploitation de base sur un Raspberry Pi.

Edit: Cet article et l’ensemble du wiki.osdev.org répondront à la plupart de vos questions http://wiki.osdev.org/Introduction

De même, si vous ne souhaitez pas expérimenter directement sur du matériel, vous pouvez l'exécuter en tant que machine virtuelle utilisant des hyperviseurs tels que qemu. Découvrez comment exécuter "hello world" directement sur le matériel virtualisé ARM ici .

142
Kissiel

Exemples exécutables

Créons et exécutons des programmes minuscules Hello World bare metal qui fonctionnent sans système d'exploitation:

Nous allons également les essayer sur l'émulateur QEMU autant que possible, car cela est plus sûr et plus pratique pour le développement. Les tests QEMU ont été effectués sur un hôte Ubuntu 18.04 avec QEMU 2.11.1 préemballé.

Le code de tous les exemples x86 ci-dessous et plus est présent sur ce dépôt GitHub .

Comment exécuter les exemples sur du matériel réel x86

N'oubliez pas qu'exécuter des exemples sur du matériel réel peut être dangereux, par exemple. vous pouvez nettoyer votre disque ou bricoler votre matériel par erreur: ne le faites que sur de vieilles machines ne contenant pas de données critiques! Ou encore mieux, utilisez des cartes de développement semi-jetables bon marché telles que Raspberry Pi, voir l'exemple ARM ci-dessous.

Pour un ordinateur portable x86 typique, vous devez faire quelque chose comme:

  1. Gravez l'image sur une clé USB (détruira vos données!):

    Sudo dd if=main.img of=/dev/sdX

  2. branchez la clé USB sur un ordinateur

  3. allume ça

  4. dites-lui de démarrer à partir de l'USB.

    Cela signifie que le micrologiciel sélectionne USB avant le disque dur.

    Si ce n'est pas le comportement par défaut de votre machine, continuez à appuyer sur Entrée, F12, ESC ou toute autre clé bizarre après la mise sous tension jusqu'à ce que vous obteniez un menu de démarrage dans lequel vous pouvez choisir de démarrer à partir de l'USB.

    Il est souvent possible de configurer l’ordre de recherche dans ces menus.

Par exemple, sur mon T430, je vois ce qui suit.

Après avoir allumé, je dois appuyer sur Entrée pour accéder au menu de démarrage:

enter image description here

Ensuite, ici, je dois appuyer sur F12 pour sélectionner le périphérique USB comme périphérique d’amorçage:

enter image description here

De là, je peux sélectionner le périphérique USB comme périphérique d’amorçage comme ceci:

enter image description here

Alternativement, pour changer l'ordre de démarrage et choisir le port USB pour qu'il ait une priorité plus élevée afin que je n'ai pas à le sélectionner manuellement à chaque fois, je taperais F1 sur l'écran "Startup Interrupt Menu" (Menu d'interruption de démarrage), puis naviguez jusqu'à:

enter image description here

secteur de démarrage

Sur x86, la chose la plus simple et la plus simple que vous puissiez faire est de créer un secteur de démarrage principal (MBR) , qui est un type de secteur de démarrage , puis de l'installer. un disque.

Ici, nous en créons un avec un seul appel printf:

printf '\364%509s\125\252' > main.img
Sudo apt-get install qemu-system-x86
qemu-system-x86_64 -hda main.img

Résultat:

enter image description here

Notez que même sans rien faire, quelques caractères sont déjà imprimés à l'écran. Celles-ci sont imprimées par le firmware et servent à identifier le système.

Et sur le T430, nous avons juste un écran vide avec un curseur clignotant:

enter image description here

main.img contient les éléments suivants:

  • \364 en octal == 0xf4 en hexadécimal: codage d'une instruction hlt qui indique à la CPU de ne plus fonctionner.

    Par conséquent, notre programme ne fera rien: démarrez et arrêtez seulement.

    Nous utilisons octal parce que \x nombres hexadécimaux ne sont pas spécifiés par POSIX.

    Nous pourrions obtenir cet encodage facilement avec:

    echo hlt > a.S
as -o a.o a.S
objdump -S a.o

    qui produit:

    a.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <.text>:
   0:   f4                      hlt

    mais cela est également documenté dans le manuel d’Intel, bien sûr.

  • %509s produit 509 espaces. Nécessaire pour remplir le fichier jusqu'à l'octet 510.

  • \125\252 en octal == 0x55 suivi de 0xaa.

    Ce sont 2 octets magiques requis qui doivent être les octets 511 et 512.

    Le BIOS parcourt tous nos disques à la recherche de disques amorçables et ne considère comme amorçables que ceux qui possèdent ces deux octets magiques.

    S'il n'est pas présent, le matériel ne le traitera pas comme un disque amorçable.

Si vous n'êtes pas un maître printf, vous pouvez confirmer le contenu de main.img avec:

hd main.img

ce qui montre l'attendu:

00000000  f4 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.               |
00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
000001f0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 55 aa  |              U.|
00000200

où 20 est un espace en ASCII.

Le micrologiciel du BIOS lit ces 512 octets sur le disque, les met en mémoire et configure le PC sur le premier octet pour commencer à les exécuter.

Bonjour le secteur d'amorçage mondial

Maintenant que nous avons créé un programme minimal, passons à un monde de salut.

La question évidente est: comment faire IO? Quelques options:

  • demandez le firmware, par exemple. BIOS ou UEFI, à faire pour nous
  • VGA: région mémoire spéciale qui est imprimée à l'écran si elle est écrite. Peut être utilisé en mode protégé.
  • écrivez un pilote et parlez directement au matériel d'affichage. C'est la "bonne" façon de le faire: plus puissant, mais plus complexe.

  • port série . C'est un protocole normalisé très simple qui envoie et reçoit des caractères d'un terminal hôte.

    Sur les ordinateurs de bureau, cela ressemble à ceci:

    enter image description here

    Source .

    Il n’est malheureusement pas exposé sur la plupart des ordinateurs portables modernes, mais c’est le moyen le plus courant d’utiliser des cartes de développement, voir les exemples ARM ci-dessous.

    C'est vraiment dommage, car de telles interfaces sont vraiment utiles pour déboguer le noyau Linux par exemple .

  • utiliser les fonctionnalités de débogage des puces. ARM appelle leur semi-hébergement par exemple. Sur du matériel réel, cela nécessite un support matériel et logiciel supplémentaire, mais sur les émulateurs, cela peut être une option pratique et gratuite. Exemple .

Ici, nous allons faire un exemple de BIOS car il est plus simple sous x86. Mais notez que ce n'est pas la méthode la plus robuste.

main.S

.code16
    mov $msg, %si
    mov $0x0e, %ah
loop:
    lodsb
    or %al, %al
    jz halt
    int $0x10
    jmp loop
halt:
    hlt
msg:
    .asciz "hello world"

GitHub en amont .

link.ld

SECTIONS
{
    /* The BIOS loads the code from the disk to this location.
     * We must tell that to the linker so that it can properly
     * calculate the addresses of symbols we might jump to.
     */
    . = 0x7c00;
    .text :
    {
        __start = .;
        *(.text)
        /* Place the magic boot bytes at the end of the first 512 sector. */
        . = 0x1FE;
        SHORT(0xAA55)
    }
}

Assemblez et faites le lien avec:

as -g -o main.o main.S
ld --oformat binary -o main.img -T link.ld main.o
qemu-system-x86_64 -hda main.img

Résultat:

enter image description here

Et sur le T430:

enter image description here

Testé sur: Lenovo Thinkpad T430, UEFI BIOS 1.16. Disque généré sur un hôte Ubuntu 18.04.

Outre les instructions de montage standard de l'utilisateur, nous avons:

  • .code16: indique à GAS de générer du code 16 bits

  • cli: désactive les interruptions logicielles. Ceux-ci pourraient faire redémarrer le processeur après le hlt

  • int $0x10: appelle le BIOS. C'est ce qui imprime les caractères un par un.

Les drapeaux de liens importants sont:

  • --oformat binary: sortie du code d'assemblage binaire brut, ne l'enroulez pas dans un fichier ELF comme c'est le cas pour les exécutables utilisateur standard.

Pour mieux comprendre la partie script de l’éditeur de liens, familiarisez-vous avec l’étape de relocalisation de la création de liens: Que font les lieurs?

Programmes nu-métal Cooler x86

Voici quelques configurations de métal nu plus complexes que j'ai réalisées:

Utilisez C au lieu de Assembly

Résumé: utilisez GRUB multiboot, ce qui résoudra de nombreux problèmes gênants auxquels vous n'auriez jamais pensé. Voir la section ci-dessous.

La principale difficulté de x86 réside dans le fait que le BIOS ne charge que 512 octets du disque dans la mémoire, et que vous risquez de faire exploser ces 512 octets lorsque vous utilisez C!

Pour résoudre ce problème, nous pouvons utiliser un chargeur de démarrage en deux étapes . Cela fait d’autres appels au BIOS, qui chargent plus d’octets du disque en mémoire. Voici un exemple d'assemblage minimal de niveau 2 de phase 2 utilisant le appels du BIOS int. 0x1 :

Alternativement:

  • si vous ne souhaitez que travailler avec QEMU mais pas avec du matériel réel, utilisez l'option -kernel, qui charge un fichier ELF entier en mémoire. Voici un exemple ARM que j'ai créé avec cette méthode .
  • pour le Raspberry Pi, le firmware par défaut prend en charge le chargement de l'image depuis un fichier ELF nommé kernel7.img, un peu comme QEMU -kernel.

À des fins éducatives uniquement, voici un exemple exemple en une étape avec C minimal :

principal c

void main(void) {
    int i;
    char s[] = {'h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd'};
    for (i = 0; i < sizeof(s); ++i) {
        __asm__ (
            "int $0x10" : : "a" ((0x0e << 8) | s[i])
        );
    }
    while (1) {
        __asm__ ("hlt");
    };
}

entrée.S

.code16
.text
.global mystart
mystart:
    ljmp $0, $.setcs
.setcs:
    xor %ax, %ax
    mov %ax, %ds
    mov %ax, %es
    mov %ax, %ss
    mov $__stack_top, %esp
    cld
    call main

linker.ld

ENTRY(mystart)
SECTIONS
{
  . = 0x7c00;
  .text : {
    entry.o(.text)
    *(.text)
    *(.data)
    *(.rodata)
    __bss_start = .;
    /* COMMON vs BSS: https://stackoverflow.com/questions/16835716/bss-vs-common-what-goes-where */
    *(.bss)
    *(COMMON)
    __bss_end = .;
  }
  /* https://stackoverflow.com/questions/53584666/why-does-gnu-ld-include-a-section-that-does-not-appear-in-the-linker-script */
  .sig : AT(ADDR(.text) + 512 - 2)
  {
      SHORT(0xaa55);
  }
  /DISCARD/ : {
    *(.eh_frame)
  }
  __stack_bottom = .;
  . = . + 0x1000;
  __stack_top = .;
}

courir

set -eux
as -ggdb3 --32 -o entry.o entry.S
gcc -c -ggdb3 -m16 -ffreestanding -fno-PIE -nostartfiles -nostdlib -o main.o -std=c99 main.c
ld -m elf_i386 -o main.elf -T linker.ld entry.o main.o
objcopy -O binary main.elf main.img
qemu-system-x86_64 -drive file=main.img,format=raw

Bibliothèque standard C

Les choses deviennent plus amusantes si vous souhaitez également utiliser la bibliothèque standard C, car nous n'avons pas le noyau Linux, qui implémente une grande partie des fonctionnalités de la bibliothèque standard C via POSIX .

Quelques possibilités, sans passer par un système d'exploitation complet tel que Linux, incluent:

  • Écrivez votre propre. C'est juste un tas d'en-têtes et de fichiers C à la fin, non? Droite??

  • Newlib

    Exemple détaillé sur: https://electronics.stackexchange.com/questions/223929/c-standard-libraries-on-bare-metal/223931

    Newlib implémente pour vous toutes les choses ennuyeuses non spécifiques au système d’exploitation, par exemple. memcmp, memcpy, etc.

    Ensuite, il vous fournit quelques exemples pour implémenter les appels système dont vous avez besoin.

    Par exemple, nous pouvons implémenter exit() sur ARM à travers le semi-hébergement avec:

    void _exit(int status) {
    __asm__ __volatile__ ("mov r0, #0x18; ldr r1, =#0x20026; svc 0x00123456");
}

    comme indiqué à dans cet exemple .

    Par exemple, vous pouvez rediriger printf vers les systèmes UART ou ARM, ou implémenter exit() avec semi-hébergement .

  • systèmes d'exploitation embarqués tels que FreeRTOS et Zephyr .

    De tels systèmes d'exploitation vous permettent généralement de désactiver la planification préemptive, vous donnant ainsi un contrôle total sur l'exécution du programme.

    Ils peuvent être vus comme une sorte de Newlib pré-implémenté.

GNU GRUB Multiboot

Les secteurs de démarrage sont simples, mais ils ne sont pas très pratiques:

  • vous ne pouvez avoir qu'un seul système d'exploitation par disque
  • le code de chargement doit être très petit et tenir dans 512 octets
  • vous devez faire vous-même beaucoup de démarrage, comme passer en mode protégé

C'est pour ces raisons que GNU GRUB a créé un format de fichier plus pratique appelé multiboot.

Exemple de travail minimal: https://github.com/cirosantilli/x86-bare-metal-examples/tree/d217b180be020a0b4a453f31275d38e697a99e0/multiboot/hello-world

Je l'utilise également sur mon exemple de dépôt GitHub pour pouvoir exécuter facilement tous les exemples sur du matériel réel sans graver la clé USB un million de fois.

Résultat QEMU:

enter image description here

T430:

enter image description here

Si vous préparez votre système d'exploitation en tant que fichier à démarrage multiple, GRUB est alors capable de le trouver dans un système de fichiers standard.

C'est ce que font la plupart des distributions, en plaçant les images du système d'exploitation sous /boot.

Les fichiers à démarrage multiple sont essentiellement un fichier ELF avec un en-tête spécial. Ils sont spécifiés par GRUB à: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

Vous pouvez transformer un fichier à démarrage multiple en un disque amorçable avec grub-mkrescue.

Firmware

En réalité, votre secteur de démarrage n'est pas le premier logiciel qui s'exécute sur le processeur du système.

Ce qui fonctionne réellement en premier est le soi-disant firmware , qui est un logiciel:

  • fabriqué par les fabricants de matériel
  • source généralement fermée mais probablement à base de C
  • stocké dans la mémoire en lecture seule, et donc plus difficile/impossible à modifier sans le consentement du vendeur.

Les firmwares bien connus incluent:

  • BIOS : ancien micrologiciel x86 présent. SeaBIOS est l'implémentation open source par défaut utilisée par QEMU.
  • UEFI : successeur du BIOS, mieux normalisé, mais plus capable et incroyablement gonflé.
  • Coreboot : la tentative de tentative de code source Open Cross

Le firmware fait des choses comme:

  • boucle sur chaque disque dur, clé USB, réseau, etc. jusqu'à ce que vous trouviez quelque chose de bootable.

    Lorsque nous exécutons QEMU, -hda indique que main.img est un disque dur connecté au matériel et que hda est le premier à être essayé et il est utilisé.

  • chargez les 512 premiers octets dans RAM adresse de mémoire 0x7c00, mettez le RIP de la CPU à cet emplacement et laissez-le s'exécuter

  • afficher des éléments tels que le menu de démarrage ou les appels d'impression du BIOS sur l'écran

Le micrologiciel offre une fonctionnalité de type système d'exploitation dont dépend la plupart des systèmes d'exploitation. Par exemple. un sous-ensemble Python a été porté pour fonctionner sur le BIOS/UEFI: https://www.youtube.com/watch?v=bYQ_lq5dcvM

On peut faire valoir que les firmwares ne peuvent être distingués des systèmes d'exploitation et que les micrologiciels sont la seule "vraie" programmation en métal nu que l'on puisse faire.

Comme cela CoreOS dev le dit :

La partie difficile

Lorsque vous mettez un PC sous tension, les puces composant le chipset (northbridge, southbridge et SuperIO) ne sont pas encore correctement initialisées. Même si le BIOS ROM est aussi éloigné du processeur que possible, il est accessible par le processeur, car il doit l'être, sinon le processeur n'aurait aucune instruction à exécuter. Cela ne signifie pas que le BIOS ROM est complètement mappé, généralement pas. Mais juste assez est mis en correspondance pour lancer le processus de démarrage. Tous les autres appareils, oubliez ça.

Lorsque vous exécutez Coreboot sous QEMU, vous pouvez expérimenter avec les couches supérieures de Coreboot et avec les charges utiles, mais QEMU offre peu d'occasions d'expérimenter le code de démarrage de bas niveau. Tout d’abord, RAM ne fonctionne que depuis le début.

Etat initial du post-BIOS

Comme beaucoup de choses dans le matériel, la normalisation est faible et l'une des choses que vous devriez not est l'état initial des registres lorsque votre code commence à s'exécuter après le BIOS.

Alors, faites-vous une faveur et utilisez un code d'initialisation semblable à celui-ci: https://stackoverflow.com/a/32509555/895245

Des registres tels que %ds et %es ont des effets secondaires importants. Vous devez donc les mettre à zéro, même si vous ne les utilisez pas explicitement.

Notez que certains émulateurs sont plus agréables que du matériel réel et vous donnent un bon état initial. Ensuite, lorsque vous utilisez du matériel réel, tout se brise.

El Torito

Format pouvant être gravé sur CD: https://en.wikipedia.org/wiki/El_Torito_%28CD-ROM_standard%29

Il est également possible de produire une image hybride qui fonctionne sur ISO ou USB. Ceci peut être fait avec grub-mkrescue ( exemple ), et est également effectué par le noyau Linux sur make isoimage en utilisant isohybrid.

BRAS

Dans ARM, les idées générales sont les mêmes.

Il n'y a pas de micrologiciel préinstallé semi-normalisé largement disponible, comme le BIOS, que nous puissions utiliser pour l'IO. Les deux types de IO les plus simples que nous puissions utiliser sont les suivants:

  • série, qui est largement disponible sur devboards
  • clignoter la LED

J'ai téléchargé:

Certaines différences par rapport à x86 incluent:

  • L'E/S se fait en écrivant directement dans les adresses magiques, il n'y a pas d'instructions in et out.

    Cela s'appelle IO mappé en mémoire .

  • pour certains matériels réels, tels que le Raspberry Pi, vous pouvez ajouter le micrologiciel (BIOS) vous-même à l'image du disque.

    C’est une bonne chose, car cela rend la mise à jour de ce micrologiciel plus transparente.

Ressources

668
Ciro Santilli 新疆改造中心996ICU六四事件

Système d'exploitation comme source d'inspiration

Le ​​système d'exploitation est aussi un programme, donc nous pouvons aussi créer notre propre programme en créant à partir de rien ou en modifiant ​​(limiter ou ajouter) les fonctionnalités de l'un des petits systèmes d'exploitation, puis exécutez-le pendant le processus de démarrage (à l'aide de image ISO).

Par exemple, cette page peut être utilisée comme point de départ:

Comment écrire un système d'exploitation simple

Ici, le système d’exploitation entier s’inscrit entièrement dans un secteur de démarrage de 512 octets ( MBR )!

Un système d'exploitation simple ou similaire peut être utilisé pour créer un cadre simple qui nous permettra:

make le chargeur de démarrage charge en RAM les secteurs suivants du disque et saute à ce point pour continuer l'exécution. Ou vous pourriez lisez sur FAT12, le système de fichiers utilisé sur les lecteurs de disquettes, et implémentez-le.

Il existe cependant de nombreuses possibilités. Pour, par exemple, voir un système d’exploitation langage assembleur x86 plus grand, nous pouvons explorer le système d’exécution MykeOS , x86 qui est un outil d'apprentissage pour montrer le fonctionnement simple des systèmes d'exploitation 16 bits en mode réel, avec code bien commenté et documentation détaillée.

Boot Loader comme source d'inspiration

Un autre type courant de les programmes qui s'exécutent sans le système d'exploitation sont également des chargeurs d'amorçage. Nous pouvons créer un programme inspiré par un tel concept en utilisant par exemple ce site:

Comment développer votre propre chargeur de démarrage

L'article ci-dessus présente également la architecture de base d'un tel programme:

  1. Chargement correct dans la mémoire par 0000: adresse 7C00.
  2. Appel de la fonction BootMain développée dans le langage de haut niveau.
  3. Affichez le message "Bonjour, mon monde…" à partir de bas niveau ".

Comme nous pouvons le constater, cette architecture est très flexible et nous permet d’implémenter n’importe quel programme, pas nécessairement un chargeur de démarrage.

En particulier, il montre comment utiliser la technique "code mixte" grâce à laquelle il est possible de combiner des constructions de haut nivea (à partir de C ou C++) avec les commandes de bas nivea (à partir de Assembler). C'est une méthode très utile, mais nous devons nous rappeler que:

pour construire le programme et obtenir le fichier exécutable vous aurez besoin de le compilateur et l'éditeur de liens d'Assembler pour le mode 16 bits. Pour C/C++, vous aurez uniquement besoin du compilateur pouvant créer des fichiers objet pour le mode 16 bits.

L'article explique également comment voir le programme créé en action et comment effectuer ses tests et son débogage.

Les applications de l'UEFI comme source d'inspiration

Les exemples ci-dessus utilisent le fait de charger le secteur MBR sur le support de données. Cependant, nous pouvons aller plus loin dans les profondeurs en plaçant par exemple avec les UEFI applications:

Outre le chargement d'un système d'exploitation, UEFI peut exécuter des applications UEFI, qui résident en tant que fichiers sur la partition système EFI. Ils peuvent être exécutés à partir de la commande UEFI Shell, par le gestionnaire de démarrage du microprogramme ou par d'autres applications UEFI. Les applications UEFI peuvent être développées et installées indépendamment du fabricant du système.

Un type d'application UEFI est un chargeur de système d'exploitation tel que GRUB, rEFInd, Gummiboot et Windows Boot Manager; qui charge un fichier OS en mémoire et l’exécute. En outre, un chargeur de système d'exploitation peut fournir une interface utilisateur pour permettre la sélection d'une autre application UEFI à exécuter. Les utilitaires comme le shell UEFI sont aussi des applications UEFI.

Si nous voulons commencer à créer de tels programmes, nous pouvons par exemple commencer par ces sites Web:

Programmation pour EFI: création d'un programme "Hello, World" / Programmation UEFI - Premiers pas

Explorer les questions de sécurité comme source d'inspiration

Il est bien connu qu’il existe tout un groupe de logiciels malveillants (qui sont des programmes) exécutés avant le démarrage du système d’exploitation.

Un grand groupe d'entre eux opère sur le secteur MBR ou les applications UEFI, tout comme les solutions précédentes, mais il en existe aussi qui utilisent un autre point d'entrée, tel que le Volume Boot Record (VBR) ou le - BIOS :

Il existe au moins quatre virus d'attaque du BIOS connus, dont deux à des fins de démonstration.

ou peut-être un autre aussi.

Attaques avant le démarrage du système

Bootkits ont évolué du développement de Proof-of-Concept à la distribution en masse et sont maintenant devenus des logiciels open-source.

Différentes façons de démarrer

Je pense également que, dans ce contexte, il convient également de mentionner que il existe différentes formes de démarrage le système d'exploitation (ou le programme exécutable destiné à cela). Il y en a beaucoup, mais je voudrais faire attention pour charger le code depuis le résea en utilisant l'option de démarrage réseau (PXE), ce qui nous permet pour exécuter le programme sur l'ordinateur indépendamment de son système d'exploitation et même de tout support de stockage directement connecté à l'ordinateur:

Qu'est-ce que l'initialisation de réseau (PXE) et comment l'utiliser?

2
simhumileco