Contexte

Nous avons déjà un défi à propos de lancer SIGSEGV , alors pourquoi pas un défi à lancer SIGILL?

Qu'est-ce que SIGILL?

SIGILL est le signal d'une instruction illégale du processeur, ce qui arrive très rarement. L'action par défaut après réception de SIGILL est la fermeture du programme et l'écriture d'un vidage mémoire. Le signal ID de SIGILL est 4. Vous rencontrez très rarement SIGILL, et je ne sais absolument pas comment le générer dans votre code, sauf via sudo kill -s 4 <pid>.

Règles

Vous aurez la racine dans vos programmes, mais si vous ne le souhaitez pas, vous pouvez également utiliser un utilisateur normal. Je suis sur un ordinateur Linux avec des paramètres régionaux allemands et je ne connais pas le texte anglais qui s’affiche après la capture de SIGILL, mais je pense que c’est quelque chose qui ressemble à «Instruction illégale». Le programme le plus court qui lance SIGILL gagne.

PDP-11 Assembler (UNIX Sixth Edition), 1 octet

9

L'instruction 9 n'est pas une instruction valide sur le PDP-11 (ce serait en octal, ce 000011qui ne figure pas dans la liste d'instructions (PDF)). L'assembleur PDP-11 fourni avec UNIX Sixth Edition reproduit apparemment tout ce qu'il ne comprend pas directement dans le fichier; dans ce cas, 9 est un nombre, il génère donc une instruction littérale 9. Il a également la propriété impaire (inhabituelle dans les langages d'assemblage de nos jours) que les fichiers commencent à s'exécuter depuis le début, nous n'avons donc pas besoin de déclarations pour rendre le programme travail.

Vous pouvez tester le programme à l'aide de cet émulateur , bien que vous deviez vous battre un peu pour le saisir.

Voici comment les choses se terminent une fois que vous avez compris comment utiliser le système de fichiers, l'éditeur, le terminal et des objets similaires que vous pensiez déjà savoir utiliser:

% a.out
Illegal instruction -- Core dumped

J'ai confirmé avec la documentation qu'il SIGILLs'agissait d' un signal authentique (et il avait même le même numéro de signal, 4, tout à fait à l'époque!)

C (x86_64, tcc ), 7 octets

main=6;

Inspiré par cette réponse .

Essayez-le en ligne!

Comment ça fonctionne

L'assemblage généré ressemble à ceci.

    .globl  main
main:
    .long 6

Notez que TCC ne place pas la "fonction" définie dans un segment de données .

Après la compilation, _start indiquera main comme d'habitude. Lorsque le programme résultant est exécuté, il attend du code dans main et recherche le nombre entier 6 de little-endian (!) 6 , codé sous la forme 0x06 0x00 0x00 0x00 . Le premier octet - 0x06 - est un code opération non valide. Le programme se termine donc avec SIGILL .

C (x86_64, gcc ), 13 octets

const main=6;

Essayez-le en ligne!

Comment ça fonctionne

Sans le modificateur const , l'assemblage généré ressemble à ceci.

    .globl  main
    .data
main:
    .long   6
    .section    .note.GNU-stack,"",@progbits

L'éditeur de liens de GCC considère la dernière ligne comme un indice que l'objet généré ne nécessite pas de pile exécutable. Puisque main est explicitement placé dans une section de données , le code opération qu’il contient n’est pas exécutable. Le programme se termine donc par SIGSEGV (erreur de segmentation).

En supprimant la deuxième ou la dernière ligne, l'exécutable généré fonctionnera comme prévu. La dernière ligne peut être ignorée avec l'indicateur de compilation -zexecstack( Essayez-le en ligne! ), Mais cela coûte 12 octets .

Une alternative plus courte consiste à déclarer main avec le modificateur const , ce qui entraîne l'assemblage suivant.

        .globl  main
        .section    .rodata
main:
        .long   6
        .section    .note.GNU-stack,"",@progbits

Cela fonctionne sans les indicateurs du compilateur. Notez que main=6;cela écrirait la "fonction" définie dans les données , mais le modificateur const obligera GCC à l'écrire dans rodata , qui (du moins sur ma plate-forme) est autorisé à contenir du code.

Rapide, 5 octets

[][0]

Access index 0 d'un tableau vide. Cet appel appelle fatalError()un message d'erreur et se bloque avec un SIGILL. Vous pouvez l'essayer ici .

GNU C, 25 octets

main(){__builtin_trap();}

GNU C (un dialecte spécifique de C avec extensions) contient une instruction pour planter le programme intentionnellement. L’implémentation exacte varie d’une version à l’autre, mais les développeurs essaient souvent d’implémenter le crash le moins cher possible, ce qui implique normalement l’utilisation d’une instruction illégale.

La version spécifique que j'avais l'habitude de tester est gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0; Cependant, ce programme génère un SIGILL sur un assez grand nombre de plates-formes et est donc assez portable. De plus, il le fait via l'exécution d'une instruction illégale. Voici le code d'assemblage dans lequel ce qui précède est compilé avec les paramètres d'optimisation par défaut:

main:
    pushq %rbp
    movq %rsp, %rbp
    ud2

ud2 est une instruction pour laquelle Intel garantit qu’il restera toujours indéfini.

C (x86_64), 11, 30, 34 ou 34 + 15 = 49 octets

main[]="/";
c=6;main(){((void(*)())&c)();}
main(){int c=6;((void(*)())&c)();}

J'ai présenté quelques solutions qui utilisent des fonctions de bibliothèque pour lancer, SIGILLpar divers moyens, mais on peut dire que c'est de la triche, car la fonction de bibliothèque résout le problème. Voici une gamme de solutions qui n'utilisent pas de fonctions de bibliothèque et émettent des hypothèses variables sur l'endroit où le système d'exploitation est prêt à vous permettre d'exécuter du code non exécutable. (Les constantes ici sont choisies pour x86_64, mais vous pouvez les changer pour obtenir des solutions qui fonctionnent pour la plupart des autres processeurs qui ont des instructions illégales.)

06est l'octet du plus petit numéro du code machine qui ne correspond pas à une instruction définie sur un processeur x86_64. Donc, tout ce que nous avons à faire est de l'exécuter. (Alternativement, 2Fest également non défini et correspond à un seul caractère ASCII imprimable.) Ni l'un ni l'autre n'est garanti d'être toujours non défini, mais ils ne sont pas définis à ce jour.

Le premier programme s'exécute ici à 2Fpartir du segment de données en lecture seule. La plupart des linkers ne sont pas capables de produire un saut de travail de .textvers .rodata(ou leur équivalent de système d'exploitation) car ce n'est pas quelque chose qui serait utile dans un programme correctement segmenté; Je n'ai pas encore trouvé de système d'exploitation sur lequel cela fonctionne. Vous devez également tenir compte du fait que de nombreux compilateurs souhaitent que la chaîne en question soit une chaîne large, ce qui nécessiterait un complément.L; Je suppose que tout système d'exploitation sur lequel cela fonctionne a une vue assez dépassée des choses et qu'il est donc construit par défaut pour une norme antérieure à C94. Il est possible que ce programme ne fonctionne nulle part, mais il est également possible que quelque part ce programme fonctionne. Je le répertorie donc dans cette collection de réponses potentielles plus douteuses à moins douteuses. (Après avoir posté cette réponse, Dennis a également mentionné la possibilité main[]={6}dans le chat, qui est de la même longueur et qui ne pose pas de problèmes de largeur de caractère, et a même laissé entendre que le potentiel existe main=6. Je ne peux pas raisonnablement prétendre que ces réponses le mien, comme je n'y pensais pas moi-même)

Le deuxième programme s'exécute ici à 06partir du segment de données en lecture-écriture. Sur la plupart des systèmes d’exploitation, cela entraînera une erreur de segmentation, car les segments de données en écriture sont considérés comme un défaut de conception qui rend les exploitations probables. Cela n’a pas toujours été le cas, donc cela fonctionne probablement sur une version suffisamment ancienne de Linux, mais je ne peux pas le tester facilement.

Le troisième programme s'exécute à 06partir de la pile. Encore une fois, cela provoque une erreur de segmentation de nos jours, car la pile est normalement classée comme non inscriptible pour des raisons de sécurité. La documentation de l'éditeur de liens que j'ai beaucoup vue implique qu'il était légal d'exécuter à partir de la pile (contrairement aux deux cas précédents, il est parfois utile de le faire), donc bien que je ne puisse pas le tester, je suis assez sûr qu'il y a version de Linux (et probablement d’autres systèmes d’exploitation) sur laquelle cela fonctionne.

Enfin, si vous donnez -Wl,-z,execstack(pénalité de 15 octets) à gcc(si vous utilisez GNU lddans le backend), il désactivera explicitement la protection de pile exécutable, permettant ainsi au troisième programme de fonctionner et donnant un signal d’opération non conforme comme prévu. Je l' ai testé et vérifié cette version 49 octets au travail. (Dennis mentionne dans le chat que cette option fonctionne apparemment main=6, ce qui donnerait un score de 6 + 15. Je suis assez surpris que cela fonctionne, étant donné que le 6 n'est pas flagrant; l'option de lien fait apparemment plus que son nom suggère.)

GNU en tant que (x86_64), 3 octets

ud2

$ xxd sigill.S

00000000: 7564 32                                  ud2

$ as --64 sigill.S -o sigill.o; ld -S sigill.o -o sigill

sigill.S: Assembler messages:
sigill.S: Warning: end of file not at end of a line; newline inserted
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078

$ ./sigill

Illegal instruction

$ objdump -d sigill

sigill:     file format elf64-x86-64

Disassembly of section .text:

0000000000400078 <__bss_start-0x200002>:>
  400078:       0f 0b                   ud2

Bash sur Raspbian sur QEMU, 4 (1?) Octets

Pas mon travail. Je rapporte simplement le travail d'un autre. Je ne suis même pas en mesure de tester l'allégation. Puisqu'une partie cruciale de ce défi semble être de trouver un environnement dans lequel ce signal sera émis et capté, je n'inclus pas la taille de QEMU, Raspbian ou bash.

Le 27 février 2013 à 20 h 49, l'utilisateur emlhalac a signalé qu'il avait reçu " des instructions illégales lorsqu'il tentait de chrooter " sur le forum Raspberry Pi.

ping

produisant

qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction (core dumped)

J'imagine que des commandes beaucoup plus courtes produiront cette sortie, par exemple tr.

EDIT: D'après le commentaire de @ fluffy's , la limite inférieure conjecturée de la longueur d'entrée a été réduite à "1?".

Fichier COM MS-DOS x86, 2 octets

EDIT: Comme indiqué dans les commentaires, le DOS lui-même ne piège pas l'exception du processeur et se bloque simplement (pas seulement l'application, mais tout le système d'exploitation). L'exécution d'un système d'exploitation basé sur NT 32 bits, tel que Windows XP, déclenchera en effet un signal d'instruction illégal.

0F 0B

De la documentation :

Génère un opcode invalide. Cette instruction est fournie pour les tests logiciels afin de générer explicitement un code opération non valide.

Ce qui est assez explicite. Enregistrer sous un fichier .com et s’exécuter dans n’importe quel émulateur DOS Les émulateurs DOS vont juste planter. Exécuter sous Windows XP, Vista ou 7 32 bits.

C (Windows 32 bits), 34 octets

f(i){(&i)[-1]-=9;}main(){f(2831);}

Cela ne fonctionne que si vous compilez sans optimisation (sinon, le code illégal de la ffonction est "optimisé").

Le désassemblage de la mainfonction ressemble à ceci:

68 0f 0b 00 00    push 0b0f
e8 a1 d3 ff ff    call _f
...

Nous pouvons voir qu'il utilise une pushinstruction avec une valeur littérale 0b0f(little-endian, donc ses octets sont permutés). L' callinstruction pousse une adresse de retour (de l' ...instruction) située sur la pile près du paramètre de la fonction. En utilisant un [-1]déplacement, la fonction remplace l'adresse de retour afin qu'elle pointe 9 octets plus tôt, où se trouvent les octets 0f 0b.

Ces octets provoquent une exception "instruction non définie", telle que conçue.

Java, 50 43 24 octets

a->a.exec("kill -4 $$");

Ceci est un java.util.function.Consumer<Runtime>¹ dont la commande est volée de la réponse de Fluffy . Cela fonctionne parce que vous devez l' appeler comme whateverNameYouGiveIt.accept(Runtime.getRuntime())!

Notez que cela va créer un nouveau processus et le faire lancer un SIGILL plutôt que de lancer un SIGILL lui-même.

^{1 - Techniquement, cela peut aussi être un java.util.function.Function<Runtime, Process>parce que Runtime#exec(String)renvoie un java.lang.Processqui peut être utilisé pour contrôler le processus que vous venez de créer en exécutant une commande shell.}

Afin de faire quelque chose de plus impressionnant dans un langage aussi prolixe, voici un bonus de 72 60 à 48 octets:

a->for(int b=0;;b++)a.exec("sudo kill -s 4 "+b);

Celui-ci en est un autre Consumer<Runtime>qui passe par TOUS les processus (y compris lui-même), faisant que chacun d'eux jette un SIGILL. Mieux vaut se préparer à un accident violent.

Et un autre bonus (a Consumer<ANYTHING_GOES>), qui prétend au moins lancer un SIGILL sur 20 octets:

a->System.exit(132);

Perl, 9 octets

kill+4,$$

Appelle simplement la fonction de bibliothèque appropriée pour signaler un processus et oblige le programme à se signaler lui-même SIGILL. Aucune instruction illégale réelle n'est impliquée ici, mais le résultat approprié est obtenu. (Je pense que cela rend le défi assez bon marché, mais si quelque chose est permis, c'est l'échappatoire que vous utiliseriez…)

Langage d'assemblage unifié (UAL) ARM, 3 octets

nop

Par exemple:

$ as ill.s -o ill.o
$ ld ill.o -o ill
ld: warning: cannot find entry symbol _start; defaulting to 00010054
$ ./ill 
Illegal instruction

Après exécution nop, le processeur interprète la .ARM.attributessection en tant que code et rencontre une instruction illégale quelque part à cet endroit:

$ objdump -D ill

ill:     file format elf32-littlearm


Disassembly of section .text:

00010054 <__bss_end__-0x10004>:
   10054:       e1a00000        nop                     ; (mov r0, r0)

Disassembly of section .ARM.attributes:

00000000 <.ARM.attributes>:
   0:   00001341        andeq   r1, r0, r1, asr #6
   4:   61656100        cmnvs   r5, r0, lsl #2
   8:   01006962        tsteq   r0, r2, ror #18
   c:   00000009        andeq   r0, r0, r9
  10:   01080106        tsteq   r8, r6, lsl #2

Testé sur un Raspberry Pi 3.

Microsoft C (Visual Studio 2005 et versions ultérieures), 16 octets

main(){__ud2();}

Je ne peux pas facilement tester cela, mais selon la documentation, il devrait produire une instruction illégale en essayant intentionnellement d'exécuter une instruction réservée au noyau à partir d'un programme en mode utilisateur. (Notez que, du fait que l'instruction illégale bloque le programme, nous n'avons pas à essayer de revenir main, ce qui signifie que cette mainfonction de style K & R est valide. Visual Studio ne jamais être passé de C89 est normalement une mauvaise chose, mais il est entré utile ici.)

Ruby, 13 octets

`kill -4 #$$`

Je suppose qu'il est prudent de supposer que nous exécutons ceci à partir d'un shell * nix. Les littéraux backtick exécutent la commande shell donnée. $$est le processus en cours d'exécution Ruby, et le #est pour l'interpolation de chaîne.

Sans appeler directement le shell:

Ruby, 17 octets

Process.kill 4,$$

N'importe quel shell (sh, bash, csh, etc.), n'importe quel POSIX (10 octets)

Réponse banale mais je n'avais vu personne le poster.

kill -4 $$

Envoie simplement SIGILL au processus en cours. Exemple de sortie sur OSX:

bash-3.2$ kill -4 $$
Illegal instruction: 4

ELF + code machine x86, 45 octets

Ce devrait être le plus petit programme exécutable sur une machine Unix qui lance SIGILL (car Linux ne reconnaît pas l'exécutable s'il est réduit).

Compiler avec nasm -f bin -o a.out tiny_sigill.asm, testé sur une machine virtuelle x64.

Binaire réel de 45 octets:

0000000 457f 464c 0001 0000 0000 0000 0000 0001

0000020 0002 0003 0020 0001 0020 0001 0004 0000

0000040 0b0f c031 cd40 0080 0034 0020 0001

Liste de montage (voir source ci-dessous):

;tiny_sigill.asm      
BITS 32


            org     0x00010000

            db      0x7F, "ELF"             ; e_ident
            dd      1                                       ; p_type
            dd      0                                       ; p_offset
            dd      $$                                      ; p_vaddr 
            dw      2                       ; e_type        ; p_paddr
            dw      3                       ; e_machine
            dd      _start                  ; e_version     ; p_filesz
            dd      _start                  ; e_entry       ; p_memsz
            dd      4                       ; e_phoff       ; p_flags


_start:
                ud2                             ; e_shoff       ; p_align
                xor     eax, eax
                inc     eax                     ; e_flags
                int     0x80
                db      0
                dw      0x34                    ; e_ehsize
                dw      0x20                    ; e_phentsize
                db      1                       ; e_phnum
                                                ; e_shentsize
                                                ; e_shnum
                                                ; e_shstrndx

  filesize      equ     $ - $$

Disclaimer: code du tutoriel suivant sur l'écriture du plus petit programme d'assemblage pour renvoyer un nombre, mais en utilisant l'opcode ud2 au lieu de mov: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

AutoIt , 93 octets

Utilisation de l’assemblage en ligne de flatassembler:

#include<AssembleIt.au3>
Func W()
_("use32")
_("ud2")
_("ret")
EndFunc
_AssembleIt("int","W")

Lorsqu'il est exécuté en mode interactif SciTE, il se bloque immédiatement. Le débogueur Windows devrait apparaître pendant une fraction de seconde. La sortie de la console ressemblera à ceci:

--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
0x0F0BC3
!>14:27:09 AutoIt3.exe ended.rc:-1073741795

Où -1073741795est le code d'erreur indéfini émis par WinAPI. Cela peut être n'importe quel nombre négatif.

Similaire avec mon propre assembleur LASM :

#include<LASM.au3>
$_=LASM_ASMToMemory("ud2"&@CRLF&"ret 16")
LASM_CallMemory($_,0,0,0,0)

NASM, 25 octets

Je ne sais pas comment cela fonctionne, mais seulement sur mon ordinateur (Linux x86_64).

global start
start:
jmp 0

Compiler et exécuter comme:

$ nasm -f elf64 ill.asm && ld ill.o && ./a.out
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400080
Illegal instruction

TI-83 Hex Assembly, 2 octets

PROGRAM:I
:AsmPrgmED77

Courir en tant que Asm(prgmI). Exécute l'opcode 0xed77 non conforme. Je compte chaque paire de chiffres hexadécimaux comme un octet.

Python, 32 octets

from os import*;kill(getpid(),4)

x86 .COM, 1 octet

c

ARPLprovoque #UDen mode 16 bits

Shell Linux, 9 octets

kill -4 0

Envoie SIGILLau processus avec le PID 0. Je ne sais pas quel processus a le PID 0, mais il existe toujours.

Essayez-le en ligne!

GNU C, 24 19 18 octets

^{-4 grâce à Dennis
-1 grâce à ceilingcat}

main(){goto*&"'";}

Essayez-le en ligne! Cela suppose ASCII et x86_64. Il tente d'exécuter le code machine 27, ce qui ... est illégal.

shortC , 10 5 4 octets

AV"'

Équivalent au code GNU C ci-dessus. Essayez-le en ligne!

MachineCode sur x86_64, 2 1 octets

7

Essayez-le en ligne!

0x07Appelle simplement l'instruction x86_64 (ceilingcat a suggéré 0x07 au lieu de 0x27)