Tester des règles YARA : échantillons, goodware, CI

Une règle jamais testée est une supposition. Tester répond à trois questions : compile-t-elle, détecte-t-elle ce qu’elle doit détecter, et reste-t-elle muette sur tout le reste ? Ce guide met en place une routine simple, manuelle comme en intégration continue.

Pourquoi tester

• Dérive de syntaxe : une règle écrite pour YARA 4 peut ne pas compiler avec YARA-X, et inversement.
• Détections manquées : une coquille dans une chaîne hexadécimale ou une condition trop stricte rend une règle silencieusement inutile.
• Faux positifs : des chaînes génériques touchent installeurs, navigateurs et DLL système. En production, cela signifie fatigue d’alertes et perte de confiance.
• Régressions de performance : un seul motif lent pénalise tous les scans (voir performance).

Constituer un petit corpus de test

Gardez deux répertoires à côté de vos règles :

• tests/positive/ — les échantillons que la règle doit détecter. Pour des malwares, stockez-les chiffrés (archive protégée par mot de passe) ou référencez-les par hash et récupérez-les dans un environnement maîtrisé.
• tests/goodware/ — des fichiers sains que la règle ne doit pas toucher : binaires système de plusieurs versions, installeurs courants, documents bureautiques, scripts. Plus il est gros, mieux c’est ; vos propres images « golden » sont idéales.

Pour tester une logique sans vrai malware, fabriquez de minuscules fichiers synthétiques contenant seulement vos marqueurs au bon endroit.

# Un positif synthétique : en-tête MZ + les deux chaînes attendues
printf 'MZ' > tests/positive/synthetic.bin
head -c 200 /dev/zero >> tests/positive/synthetic.bin
printf 'LoaderInit\0GetProcAddress\0' >> tests/positive/synthetic.bin

Vérifications de compilation et de format

La ligne de commande YARA-X yr fournit ce qu’il faut :

yr check rules/            # compile tout, signale erreurs et avertissements
yr fmt rules/example.yar   # réécrit le fichier au format canonique
yr scan rules/example.yar tests/positive/   # doit lister chaque échantillon positif
yr scan rules/example.yar tests/goodware/   # ne doit rien afficher

Avec YARA 4.x, yarac compile et yara -r scanne récursivement.

Une règle de test pour démarrer

rule MAL_Test_Target
{
    meta:
        description = "Règle cible du guide de tests"
        author = "yararules.org"
        date = "2026-09-29"
    strings:
        $a = "LoaderInit" ascii
        $b = "GetProcAddress" ascii
    condition:
        uint16(0) == 0x5A4D and filesize < 1MB and all of them
}

Le fichier synthétique ci-dessus la déclenche ; un exécutable sain sans LoaderInit non. Essayez les deux dans l’éditeur en ligne : collez la règle, déposez le fichier dans le panneau de test et voyez les chaînes trouvées avec leurs offsets.

Intégration continue

Exécutez les mêmes contrôles à chaque modification. Un workflow GitHub Actions minimal :

name: yara
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install YARA-X
        run: cargo install yara-x-cli
      - name: Compile
        run: yr check rules/
      - name: Positive samples must match
        run: |
          for f in tests/positive/*; do
            yr scan rules/ "$f" | grep -q . || { echo "no match: $f"; exit 1; }
          done
      - name: Goodware must not match
        run: |
          out=$(yr scan rules/ tests/goodware/ || true)
          if [ -n "$out" ]; then echo "$out"; exit 1; fi

L’installation depuis crates.io compile YARA-X depuis les sources ; un binaire précompilé téléchargé depuis les releases YARA-X accélère le job. Pour les dépôts GitHub, YARA-CI teste aussi les règles contre un corpus de goodware.

Suivre les faux positifs dans le temps

• Consignez chaque faux positif avec le hash du fichier, la règle et la correction, puis ajoutez le fichier au corpus de goodware pour éviter toute régression.
• Préférez une exclusion $fp* ou un contrôle structurel plus strict à la suppression d’une chaîne utile.
• Un champ meta score (0–100) permet aux consommateurs de pondérer les règles faibles différemment des règles de haute confiance.

Versionner ses règles

Gardez des métadonnées qui rendent les règles maintenables : un id stable (UUID), la date de création, la date modified, author, reference et les hash d’échantillons. Les conventions listent les pratiques courantes. Quand la logique change, mettez à jour modified pour que les utilisateurs sachent qu’il faut retester.

Check-list rapide

1. yr check passe sans erreur (et les avertissements sont examinés).
2. Chaque échantillon positif est détecté.
3. Le corpus de goodware ne produit aucune correspondance.
4. Le linter n’affiche aucun avertissement de performance, ou chacun est justifié.
5. Les métadonnées sont complètes et modified est à jour.