Infezione file eseguibili

Stato
Discussione chiusa ad ulteriori risposte.
ma in termini "pratici", a che servono i NOP ?
non si potrebbero evitare tranquillamente ?
cosa succede se ad un file eseguibile elimino tutti gli 0x90 che trovo ? (adesso provo xD)

[ot]ho sprecato così il messaggio n° 666... che palle[/ot]
 
Il polimorfismo consiste semplicemente nel modificare il codice del virus ogni volta che si replica aggiungenod porzioni di codice "inutili" da un semplice NOP a insiemi di istruzioni (xor ecc) che non incidono sul funzionamento del virus stesso e che hanno l'unico scopo di rendere il codice "diverso" e quindi meno riconoscibile...
 
Oromis92 ha detto:
ma in termini "pratici", a che servono i NOP ?
non si potrebbero evitare tranquillamente ?
cosa succede se ad un file eseguibile elimino tutti gli 0x90 che trovo ? (adesso provo xD)
I NOP vengono eseguiti dal processore in 1 nanosecondo (con clock di 4mhz) e suppongo sia una serie di essi che crea ad esempio gli _sleep(const unsigned ); fisicamente non fanno altro che incrementare il registro PC ( program counter ) quindi aumentare il numero delle istruzioni fatte eseguire al processore. Rispetto all'eseguibile varia a seconda dell'architeturra del processore, se è di tipo CISC con un solo processore è di poca utilità mentre in altri superscalari diviene essenziale per evitare errori come il "data hazard" o il "branch hazard" cui ho accenato precedentemente.

Grazie Kama, non sapevo di questo nome....

Oromis92 ha detto:
Oromis92 ha detto:
cosa succede se ad un file eseguibile elimino tutti gli 0x90 che trovo ? (adesso provo xD)

Segmentation Fault

perchè ????

In poche parole cerchi di accedere ad un area di memoria che non è appropriata al tipo di accesso.
 
Mi sono espresso male xD
Poi per aggiungere un pizzico di OffTopic diciamo che i virus cercano di nascondersi il piu' possibile pertanto usano tecniche di mimetismo dette stealth, usando codice polimorfico e altro ancora.
che significa codice polimorfico ?
cioè che dovrebbe fare un codice per essere polimorfico ?
EDIT:Non avevo visto la risposta di Kama.
ma come può fare ciò ?
 
RedSkull92 ha detto:
Mi sono espresso male xD
Poi per aggiungere un pizzico di OffTopic diciamo che i virus cercano di nascondersi il piu' possibile pertanto usano tecniche di mimetismo dette stealth, usando codice polimorfico e altro ancora.
che significa codice polimorfico ?
cioè che dovrebbe fare un codice per essere polimorfico ?
EDIT:Non avevo visto la risposta di Kama.
ma come può fare ciò ?

Aggiungere qui e lì istruzioni che non incidono al funzionamento del programma e che variano, in modo casuale o programmato.
 
Se vi interessa vi consiglio di dare un'occhiata a

THE ART OF COMPUTER VIRUS RESEARCH AND DEFENSE
By Peter Szor
Publisher: Addison Wesley Professional
Pub Date: February 03, 2005
ISBN: 0-321-30454-3

e/o

The giant black book of computer viruses
by Mark Ludwig

Si dovrebbero "trovare" sui siti specializzati in ebook ;)
 
kama ha detto:
Se vi interessa vi consiglio di dare un'occhiata a

THE ART OF COMPUTER VIRUS RESEARCH AND DEFENSE
By Peter Szor
Publisher: Addison Wesley Professional
Pub Date: February 03, 2005
ISBN: 0-321-30454-3

e/o

The giant black book of computer viruses
by Mark Ludwig

Si dovrebbero "trovare" sui siti specializzati in ebook ;)

il secondo non lo trovo. il primo eccovelo:

http://www.mediafire.com/download.php?t9ayyn09yjm

[ot]
linuxiani
Codice:
sudo apt-get install libchm-bin
extract_chmLib Addison.Wesley.The.Art.of.Computer.Virus.Research.and.Defense.Feb.2005.eBook-LiB.chm ebook
[/ot]
 
Ecco il secondo ;-)

http://vx.netlux.org/lib/files/vml01/gbbfirst.zip

Si può consultare anche online, http://vx.netlux.org/lib/vml01.html

Letture interessanti, peccato che ho ancora 3 libri da leggere xD.
 
ottimi link, me li studierò a fondo, grazie!
Appena riesco a realizzare qualche programmino di esempio lo posto qui..
 
Gian, n1ghtmare ... VI AMMAZZZOOOOOOOOOO!!!!! VI SEQUESTRO LA TASTIERA E VI DECAPITO CON QUELLA!
ci quasi 3 pagine di approsimazioni ed informazioni sbagliate!!!! vado a mangiare poi rispondo :tdf:
 
Predator ha detto:
Gian, n1ghtmare ... VI AMMAZZZOOOOOOOOOO!!!!! VI SEQUESTRO LA TASTIERA E VI DECAPITO CON QUELLA!
ci quasi 3 pagine di approsimazioni ed informazioni sbagliate!!!! vado a mangiare poi rispondo :tdf:

Ma non sono stato io, è la tastiera :moonwalkmg:
 
Predator ha detto:
Gian, n1ghtmare ... VI AMMAZZZOOOOOOOOOO!!!!! VI SEQUESTRO LA TASTIERA E VI DECAPITO CON QUELLA!
ci quasi 3 pagine di approsimazioni ed informazioni sbagliate!!!! vado a mangiare poi rispondo :tdf:

merd... lo sapevo che non dovevo rispondere... xD
 
Predator ha detto:
Gian, n1ghtmare ... VI AMMAZZZOOOOOOOOOO!!!!! VI SEQUESTRO LA TASTIERA E VI DECAPITO CON QUELLA!
ci quasi 3 pagine di approsimazioni ed informazioni sbagliate!!!! vado a mangiare poi rispondo :tdf:

SI' PREDDY, STRAPPA LE BRACCIA A TUTTI CHE FANNO DISINFORMAZIONE NEI MIEI E NEI VOSTRI CONFRONTI :mad:
scherzo xD, attendiamo tutti la tua risposta!
 
ARGH, vi va bene che sono le 23.45 e ho quasi finito di lavorare, domani vi bastono con le vostre ossa ;)

Pred
 
Quoto Predator. 5 pagine di informazioni inutili, approssimative e/o sbagliate. Se non sai le cose, salle (cit.)

cosa succede se ad un file eseguibile elimino tutti gli 0x90 che trovo ? (adesso provo xD)

Direi che è abbastanza normale la segmentation fault sai...

I NOP piazzati generalmente dal compilatore alla fine di una porzione eseguibile non servono a niente (sono operazioni che tendenzialmente non fanno niente, dato che nell'architettura Intel NOP == XCHG eax,eax, ovvero scambia eax con se stesso), se non ad allineare fra loro la lunghezza delle singole sezioni o segmenti. Se tu li cancelli, le informazioni contenute negli header dell'eseguibile, ELF o PE, vengono completamente sballate, in quanto tutti gli offset dei vari segmenti all'interno del file eseguibile diventano errati, dato che hai cancellato porzioni del file eseguibile. Per fare un esempio, in un eseguibile la label "main" comincia all'offset 7 a partire dall'inizio del file, e quest'informazione è salvata anche nei section header del file, in modo che quando l'eseguibile viene eseguito si sappia che c'è un'etichetta main a 7 byte a partire dall'inizio. Mettiamo che prima di quest'etichetta ci siano 3 byte NOP, risultanti dalle varie procedure di inizializzazione dello stack che tipicamente vengono piazzate dal compilatore. Se li cancello, main non sarà più all'offset 7 ma all'offset 4, ma se non modifico di conseguenza anche i section header quando il file viene eseguito lui andrà a pescarmi il main piazzandosi all'offset 4, eseguendo chissà che merd* a partire da chissà che punto, e il processo fa un grande fail.

Per le tecniche di infezione, la più usata consiste nell'avvelenamento dell'entry point dell'eseguibile. Ho il mio codice infettante, lo copio da qualsiasi parte nel file eseguibile e modifico l'entry point dell'eseguibile in modo che mi punti lì, e modifico di conseguenza anche gli offset nei vari section headers. Quindi, alla fine del mio codice infettante, ci piazzo un jmp all'entry point originale, in modo che il funzionamento dell'eseguibile non sia comunque compromesso. Questo sorgente vi dice nulla?
 
BlackLight ha detto:
Quoto Predator. 5 pagine di informazioni inutili, approssimative e/o sbagliate. Se non sai le cose, salle (cit.)

cosa succede se ad un file eseguibile elimino tutti gli 0x90 che trovo ? (adesso provo xD)

Direi che è abbastanza normale la segmentation fault sai...

I NOP piazzati generalmente dal compilatore alla fine di una porzione eseguibile non servono a niente (sono operazioni che tendenzialmente non fanno niente, dato che nell'architettura Intel NOP == XCHG eax,eax, ovvero scambia eax con se stesso), se non ad allineare fra loro la lunghezza delle singole sezioni o segmenti. Se tu li cancelli, le informazioni contenute negli header dell'eseguibile, ELF o PE, vengono completamente sballate, in quanto tutti gli offset dei vari segmenti all'interno del file eseguibile diventano errati, dato che hai cancellato porzioni del file eseguibile. Per fare un esempio, in un eseguibile la label "main" comincia all'offset 7 a partire dall'inizio del file, e quest'informazione è salvata anche nei section header del file, in modo che quando l'eseguibile viene eseguito si sappia che c'è un'etichetta main a 7 byte a partire dall'inizio. Mettiamo che prima di quest'etichetta ci siano 3 byte NOP, risultanti dalle varie procedure di inizializzazione dello stack che tipicamente vengono piazzate dal compilatore. Se li cancello, main non sarà più all'offset 7 ma all'offset 4, ma se non modifico di conseguenza anche i section header quando il file viene eseguito lui andrà a pescarmi il main piazzandosi all'offset 4, eseguendo chissà che merd* a partire da chissà che punto, e il processo fa un grande fail.

Per le tecniche di infezione, la più usata consiste nell'avvelenamento dell'entry point dell'eseguibile. Ho il mio codice infettante, lo copio da qualsiasi parte nel file eseguibile e modifico l'entry point dell'eseguibile in modo che mi punti lì, e modifico di conseguenza anche gli offset nei vari section headers. Quindi, alla fine del mio codice infettante, ci piazzo un jmp all'entry point originale, in modo che il funzionamento dell'eseguibile non sia comunque compromesso. Questo sorgente vi dice nulla?

uhm, tecnica interessante, ora provo a scrivere qualcosa e lo posto, predator hai qualcosa da aggiungere?
 
Stato
Discussione chiusa ad ulteriori risposte.