La  #malwareAnalysis prevede lo studio del #malware e dei suoi comportamenti.
Questo può essere fatto in modalità statica (senza eseguire il malware) o dinamica (eseguendo il malware in ambiente controllato).
L'analisi dinamica avanzata prevede di eseguire un malware all'interno di un #debugger (es. #OllyDbg) in modo da poter seguire, istruzione per istruzione (parlo di istruzioni #Assembler), il suo comportamento.
Ma i malware, per evitare di essere studiati, spesso utilizzano tecniche definite di #AntiDebugging, ovvero tecniche che alterano il suo comportamento in caso si accorga di essere eseguito all'interno di questi strumenti.
Ma come fa a rendersene conto?
Le tecniche sono molte, una di queste prevede di andare a controllare il campo Beingdebugged all'interno della #PEB del proprio processo.
Infatti, quando un processo viene eseguito all'interno di un debugger, il campo #BingDebugged viene impostato ad 1 altrimenti è 0.
Tipicamente le istruzioni che si possono trovare in malware che eseguono questo controllo, prevedono di saltare all'indirizzo della PEB che si trova in fs:[30h] e da lì ci si sposta di 2 byte. Un esempio di istruzioni potrebbe essere

mov eax, fs[30h] // carico in eax l'indirizzo della peb
mov ebx, [eax+2] // carico in ebx il flab BeingDebugged
test ebx, ebx // testo se il campo BeingDebugged è 1
jz NoDebuggerDetected // a questo indirizzo si esegue il codice alternativo

Tweet