Domanda:
Metodo anti-forense INT 2D
lynks
2013-04-03 19:42:49 UTC
view on stackexchange narkive permalink

L'inclusione di un'istruzione INT 2D sembra essere una tattica anti-debug abbastanza comune utilizzata dagli autori di malware di Windows. Da quanto ho capito, fa sì che un processo agisca in modo diverso quando un debugger è collegato da quando non è collegato.

Ho letto che ciò è dovuto in parte a un processo asincrono (non fa parte del normale flusso del programma ) incrementa al puntatore dell'istruzione. Questo incremento può essere fatto per portare alla scissione dell'istruzione.

Qualcuno potrebbe spiegare questa tattica anti-debug, in particolare perché si verifica questo incremento al puntatore dell'istruzione e cosa succede quando un debugger è e non è allegato.

Quattro risposte:
#1
+16
peter ferrie
2013-04-03 20:29:26 UTC
view on stackexchange narkive permalink

Dal mio riferimento "Ultimate" Anti-Debugging (vedere pferrie.host22.com):

L'interrupt 0x2D è un caso speciale. Quando viene eseguito, Windows utilizza il valore del registro EIP corrente come indirizzo di eccezione, quindi incrementa di uno il valore del registro EIP. Tuttavia, Windows esamina anche il valore nel registro EAX per determinare come modificare l'indirizzo dell'eccezione. Se il registro EAX ha il valore 1, 3 o 4 su tutte le versioni di Windows o il valore 5 su Windows Vista e versioni successive, Windows aumenterà di uno l'indirizzo di eccezione. Infine, genera un'eccezione EXCEPTION_BREAKPOINT (0x80000003) se è presente un debugger. Il comportamento dell'interrupt 0x2D può causare problemi ai debugger. Il problema è che alcuni debugger potrebbero utilizzare il valore del registro EIP come indirizzo da cui riprendere, mentre altri debugger potrebbero utilizzare l'indirizzo di eccezione come indirizzo da cui riprendere. Ciò può comportare il salto di un'istruzione a byte singolo o l'esecuzione di un'istruzione completamente diversa perché manca il primo byte. Questi comportamenti possono essere utilizzati per dedurre la presenza del debugger. Il controllo può essere effettuato utilizzando questo codice (identico per 32 bit e 64 bit) per esaminare l'ambiente Windows a 32 o 64 bit:

  xor eax, eax; set Z flagint 2dhinc eax; il debugger potrebbe saltare l'essere_debuggato  

[fine]

Quindi puoi vedere che non sta succedendo nulla di asincrono qui. La modifica avviene immediatamente quando si verifica l'eccezione. Per quanto riguarda il perché si verifica, il byte saltato è destinato a essere utilizzato per passare un byte di informazioni aggiuntive al momento dell'eccezione.

In effetti era abbastanza ovvio che non ci fosse alcun controllo di "asincronia" in corso quando ho iniziato a leggerlo. Immagino che l'istruzione UD2 potrebbe fare qualcosa di simile?
UD2 non ha lo stesso effetto. Quella si comporta come qualsiasi altra istruzione non valida. Esiste esclusivamente allo scopo di vedere come appare un'istruzione decisamente non valida (al contrario di una combinazione di codice operativo casuale che non è valida oggi ma diventa valida domani in una nuova CPU).
#2
+6
cb88
2013-04-03 20:28:00 UTC
view on stackexchange narkive permalink

Una guida anti-ingegneria inversa

E il commento esplicativo principale dal codice qui presentato.

  // La funzione Int2DCheck controllare per vedere se un debugger // è collegato al processo corrente. Lo fa impostando // SEH e utilizzando l'istruzione Int 2D che causerà un'eccezione // solo se non è presente alcun debugger. Inoltre, se utilizzato in OllyDBG // salterà un byte durante lo smontaggio e creerà // un po 'di caos.  

Nota che qui è un po' su SEH.

#3
+3
Brandon Young
2013-04-17 20:45:48 UTC
view on stackexchange narkive permalink

Per alcuni buoni esempi di utilizzo di INT2d in Malware, controlla il blog del Dr. Fu:

http://fumalwareanalysis.blogspot.com/p/malware-analysis-tutorials-reverse .html

Ci sono 3 diversi esempi e spiegazioni, una è con Max ++ che dà una buona idea di cosa aspettarsi dai tuoi esempi di malware.

#4
+3
Gagou
2015-04-21 19:23:05 UTC
view on stackexchange narkive permalink

L'interrupt 0x2D è un caso speciale. Quando viene eseguito, Windows utilizza il valore del registro EIP corrente come indirizzo di eccezione , quindi incrementa di uno il valore del registro EIP . Tuttavia, Windows esamina anche il valore nel registro EAX per determinare come modificare l ' indirizzo di eccezione . Se il registro EAX ha il valore di 1, 3 o 4 su tutte le versioni di Windows o il valore 5 su Windows Vista e versioni successive, Windows aumenterà di uno l'indirizzo di eccezione . Infine, genera un'eccezione EXCEPTION_BREAKPOINT (0x80000003) se è presente un debugger. Il comportamento dell'interrupt 0x2D può causare problemi ai debugger. Il problema è che alcuni debugger potrebbero utilizzare il valore del registro EIP come indirizzo da cui riprendere, mentre altri debugger potrebbero utilizzare l'indirizzo di eccezione come indirizzo da cui riprendere. Ciò può comportare il salto di un'istruzione a byte singolo o l'esecuzione di un'istruzione completamente diversa perché manca il primo byte. Questi comportamenti possono essere utilizzati per dedurre la presenza del debugger. Il controllo può essere effettuato utilizzando questo codice (identico per 32 bit e 64 bit) per esaminare l'ambiente Windows a 32 bit o 64 bit:

All'inizio, non l'ho fatto Non capisco il significato di "indirizzo di eccezione" e penso di non essere l'unico. Fortunatamente, il blog del dottor Fu ha una spiegazione migliore al riguardo.

Dal blog del dottor Fu:

Qui l '"indirizzo di eccezione" è il "valore EIP del contesto "(che deve essere copiato di nuovo nel processo utente) e il" valore del registro EIP "è il valore EIP reale del processo utente quando si verifica l'eccezione.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...