Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
YARA-Performance-Guidelines — Una guida su come scrivere regole YARA veloci ed efficienti in termini di memoria. | Kitploit
Strumenti/GitHubGitHub/neo23x0/yara-performance-guidelines
Analisi StaticaAnalisi MalwareApprendimento e Formazione
GitHubneo23x0/yara-performance-guidelines

YARA-Performance-Guidelines

Una guida su come scrivere regole YARA veloci ed efficienti in termini di memoria.

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
17423161 anno faRevisionato da Kitploit
Condividi

Linee Guida sulle Prestazioni di YARA

Scrivere regole YARA efficienti è essenziale per mantenere prestazioni di scansione rapide e accurate. Questa guida fornisce principi chiave e buone pratiche per aiutarti a ottimizzare le tue regole, ridurre i calcoli non necessari ed evitare le insidie più comuni. Include approfondimenti di esperti del settore, tra cui Victor M. Alvarez, WXS, e contributi della community YARA.

  • Revisione 1.6, febbraio 2025, si applica a tutte le versioni di YARA successive alla 3.7

Concetti Chiave

Questa sezione fornisce un riepilogo conciso delle buone pratiche sulle prestazioni di YARA. Per spiegazioni dettagliate ed esempi, fai riferimento alla guida completa qui sotto.

Comprendere il Processo di Scansione di YARA

"Pensa a YARA come a un processo in due fasi: prima, la ricerca di tutti i pattern elencati nelle stringhe, e poi, la valutazione delle condizioni. Non puoi usare condizioni ben formate per compensare stringhe scelte male."
— Wesley Shields

YARA segue quattro passaggi principali quando scansiona un file:

  1. Compilazione delle regole – Estrazione degli atomi (sottostringhe di 4 byte) dalle stringhe definite.
  2. Ricerca Aho-Corasick – Scansione dei file alla ricerca di questi atomi.
  3. Motore bytecode – Verifica delle corrispondenze complete delle stringhe.
  4. Valutazione delle condizioni – Verifica della logica aggiuntiva della regola.

Selezione delle Stringhe – Il Fattore Più Importante

YARA cerca prima le stringhe, rendendo la selezione delle stringhe il fattore singolarmente più importante per l'efficienza delle regole.

✅ Buone Pratiche per le Stringhe:

  • Evita le stringhe corte (<4 byte) – Creano troppi falsi positivi.
  • Usa atomi unici di 4 byte – YARA si affida a essi per una scansione rapida.
  • Riduci al minimo i caratteri jolly nelle stringhe esadecimali – Mantieni almeno un segmento concreto lungo.
  • Usa le regex con parsimonia – Se necessario, includi un'ancora fissa di 4 byte per migliorare l'efficienza.
  • Evita i pattern ripetuti di un singolo byte – Ad es., \x00\x00\x00\x00 appare troppo di frequente.
  • Usa nocase con cautela – Genera esponenzialmente più varianti di ricerca.

Ottimizzare le Condizioni e lo Short-Circuit

YARA valuta le condizioni in sequenza e si ferma al primo insuccesso.

✅ Buone Pratiche per le Condizioni:

  • Metti prima i controlli rapidi (ad es., filesize < X) prima delle condizioni costose.
  • Evita i cicli su grandi quantità di dati (for all i in (1..filesize) è inefficiente).
  • Usa offset diretti (@) invece delle regex per i controlli di sequenza.

⚠ Nota: Le condizioni regex non applicano lo short-circuit e vengono sempre valutate per ultime.

Moduli – Usare con Cautela

Moduli come pe, elf o magic devono analizzare l'intero file prima della valutazione, aumentando il tempo di scansione.

✅ Alternative:

  • Invece di pe.is_pe, usa uint16(0) == 0x5A4D per identificare i file PE.
  • Evita di usare i moduli a meno che non sia richiesta un'ispezione approfondita del file.

Gestire i Troppi Match e la Scansione Lenta

I match eccessivi rallentano la scansione e possono attivare errori di "too many matches".

✅ Correggere i Match Inefficienti:

  • Controlla i quantificatori delle regex – Evita .*, .+ o {x,} senza un limite superiore.
  • Riduci i caratteri jolly nelle stringhe esadecimali.
  • Dividi le alternanze in stringhe separate dove possibile.

Video Tutorial

@herrcore ha creato un utile video tutorial che copre gli argomenti discussi in questa guida sulle prestazioni.

Introduzione a YARA - Scrivere Regole YARA Efficienti

Le Basi

Per capire meglio cosa e dove può essere ottimizzato nelle prestazioni di YARA, è utile comprendere il processo di scansione. È fondamentalmente suddiviso in 4 fasi che verranno spiegate in modo molto semplificato usando questa regola di esempio:

import "math"
rule example_php_webshell_rule
{
    meta:
        description = "Just an example php webshell rule"
        date = "2021/02/16"
    strings:
        $php_tag = "<?php"
        $input1   = "GET"
        $input2   = "POST"
        $payload = /assert[\t ]{0,100}\(/
    condition:
        filesize < 20KB and
        $php_tag and
        $payload and
        any of ( $input* ) and
        math.entropy(500, filesize-500) >= 5
}

1. Compilazione delle regole

Questo passaggio avviene prima della scansione vera e propria. YARA cercherà i cosiddetti atoms nelle stringhe di ricerca per alimentare l'automa di Aho-Corasick. I dettagli sono spiegati nel capitolo atomo, ma per ora è sufficiente sapere che sono lunghi al massimo 4 byte e che YARA li sceglie in modo piuttosto intelligente per evitare troppi match. Nel nostro esempio, YARA potrebbe selezionare i seguenti 4 atomi:

  • <?ph
  • GET
  • POST
  • sser (da assert)

2. Automa di Aho-Corasick

Qui la scansione è iniziata. I passaggi 2.-4. verranno eseguiti su tutti i file. YARA cercherà in ogni file i 4 atomi definiti sopra utilizzando un albero dei prefissi chiamato automa di Aho-Corasick. Qualsiasi corrispondenza viene passata al motore bytecode.

3. Motore bytecode

Se, ad esempio, c'è una corrispondenza su sser, YARA verificherà se è preceduta da una a e continua con una t. Se è così, proseguirà con la regex [\t ]{0,100}\(. Con questo approccio intelligente, YARA evita di far passare un lento motore regex sull'intero file e seleziona solo alcune parti da esaminare più da vicino.

4. Condizioni

Dopo che tutto il pattern matching è stato completato, vengono verificate le condizioni. YARA ha un altro meccanismo di ottimizzazione per eseguire il controllo ad alta intensità di CPU math.entropy della nostra regola di esempio solo se le 4 condizioni precedenti sono soddisfatte. Spiegato in maggior dettaglio nel capitolo Condizioni e Valutazione Short-Circuit

Se le condizioni sono soddisfatte, viene segnalato un match. La scansione continua con il file successivo al passaggio 2.

Atomi

YARA estrae dalle stringhe brevi sottostringhe lunghe fino a 4 byte chiamate "atoms". Questi atomi possono essere estratti da qualsiasi punto della stringa e YARA li cerca durante la scansione del file; se trova uno degli atomi, verifica che la stringa corrisponda effettivamente.

Ad esempio, considera queste stringhe:

/abc.*cde/

=> i possibili atomi sono abc e cde; si può usare l'uno o l'altro. L'atomo abc è attualmente preferito perché hanno la stessa qualità ed è il primo dei due.

/(one|two)three/

=> i possibili atomi sono one, two, thre e hree; possiamo cercare solo thre (o hree), oppure sia one che two. L'atomo thre è preferito perché porterà a meno corrispondenze potenziali rispetto a one e two (che sono più corti) e non contiene la doppia e (più la lettera è unica, meglio è).

YARA fa del suo meglio per selezionare i migliori atomi da ogni stringa, per esempio:

{ 00 00 00 00 [1-4] 01 02 03 04 }

=> qui YARA usa l'atomo 01 02 03 04, perché 00 00 00 00 è troppo comune

{ 01 02 [1-4] 01 02 03 04 }

=> 01 02 03 04 è preferito rispetto a 01 02 perché è più lungo

Quindi, il punto importante è che le stringhe dovrebbero contenere buoni atomi. Queste sono stringhe pessime perché contengono atomi troppo corti o troppo comuni:

{00 00 00 00 [1-2] FF FF [1-2] 00 00 00 00}
{AB  [1-2] 03 21 [1-2] 01 02}
/a.*b/
/a(c|d)/

Le stringhe peggiori sono quelle che non contengono alcun atomo, come:

/\w.*\d/
/[0-9]+\n/
Scarica lo strumento