Hookare ntdll.dll

[71104]

Originariamente inviato da GordonFreeman

il codice è un casino,comunque il rilocamento non l'ho fatto forse è quella la causa?? ho semplicemente copiato il contenuto delle varie sezioni (".text",".rdata",".idata",".reloc",eccetera) nell'immagine di memoria,e poi ho chiamato la funzione di entry point...non basta?

se non hai rilocato allora la causa del crash è sicuramente quella... devi rilocare per forza: se non l'hai fatto probabilmente dopo 1 po' vanno in crash anche tutti gli altri moduli (compresa la tua DLL); il motivo percui non crashano subito è che evidentemente nell'entry point non usano nessuno statement switch, nessun puntatore a variabili globali, e nessun altra causa di fixup.
leggiti bene il doc di Microsoft sul formato PE è molto dettagliato (è completo tranne che per alcuni tipi di fixup praticamente inutilizzati, roba del Mac, e per un formato proprietario di informazioni di debug che però a te non interessa).

poi per le pagine di memoria fisica non contigue chi se ne frega, quello che conta è che le pagine di memoria VIRTUALE siano contigue,e non potrebbe essere altrimenti,scusa,se no andrebbe in crash il programma se solo faccio un memcpy() o memset() per scrivere su tutta quella memoria...ma questo non succede,quindi sono contigue

io infatti non parlavo di indirizzi fisici, parlavo proprio di indirizzi virtuali... che succede se dopo aver allocato la prima pagina, durante l'allocazione della seconda il sistema operativo si accorge che il programma ne ha già allocata una in quella posizione? deve saltare di qualche kilobyte e allocare dopo, e quindi le tue sezioni non sono più contigue (e non sto parlando di indirizzi fisici); è molto meglio lasciar fare al sistema operativo utilizzando un oggetto file mapping (che oltrettutto puoi anche condividere tra più processi risparmiando memoria quando non devi rilocare).
qui sotto ti ho messo il codice del mio virus, che fa esattamente questa cosa; occhio però che ha un problema (quasi) noto che devo ancora risolvere
mi funziona perfettamente se lo metto in un paio di processi, ma provoca schermata blu ( ) se lo metto in tutti...

<il codice è stato tempestivamente rimosso>

questa è la versione base del virus che mostra una semplice MessageBox ogni 5 sec. proveniente da tutti i processi... cioè da ciascun processo ogni 5 sec arriva la MessageBox (puoi immaginarti che cosa fastidiosa ).
avevo anche scritto un piccolo txt contenente la descrizione delle caratteristiche e delle tecniche usate nel virus, che ti copio di seguito (ce n'è una che non ho ancora applicato: l'invisibilità nel call stack).

1. dimensioni ridotte
2. invisibile
3. autorilocante
4. autobindante
5. entry point mascherato
6. anti disassemblatore (solo in alcuni punti)
7. anti API tracer
8. invisibile nel call stack
9. intercetta CreateProcessW e si rimappa in tutti i nuovi processi


1. Dimensioni ridotte

Nella versione compilata in modalità Release è stato rimosso il runtime di Visual C++: il file risulta più piccolo di circa 16 kb ma deve usare solo chiamate API: no problem, visto che nel suo runtime VC++ traduce tutte le funzioni standard del C in chiamate API.


2. Invisibilità

La DLL (che può essere caricata solo in runtime con LoadLibrary) resituisce FALSE dalla DllMain, fingendo di fallire il caricamento; dunque non può essere caricata una sua copia visibile, ma prima di ritornare con FALSE la DllMain chiama una routine interna che crea una copia invisibile della DLL stessa scrivendo il contenuto del suo stesso file in un file mapping object che potrà anche essere condiviso negli altri processi del sistema.


3-4. Autorilocamento e autobinding

La copia invisibile inizia la sua esecuzione da uno speciale entry point che per prima cosa riloca la nuova copia (il codice di rilocamento non contiene fixup); successivamente la binda e crea un nuovo thread (il thread principale della DLL); infine ritorna.


5. Entry point mascherato

Lo speciale entry point dal quale inizia l'esecuzione della copia invisibile si chiamava inizialmente "_unknown" (è stato necessario esportarlo per conoscerne l'indirizzo in runtime), ma con un piccolo programma ho effettuato delle modifiche al file finale e adesso l'entry point si chiama letteralmente "(Not Found)": ottimo depistaggio per chi usa programmi come PEDUMP o il Dependency Walker.


6. Anti disassemblatore

Alcune parti importanti del codice sono offuscate ai disassemblatori: è presente un finto opcode che disallinea il codice che segue; il finto opcode non viene eseguito perché viene saltato da un JMP short relativo che salta di un solo byte.

Codice assembly:

JMP $+1; JMP short relativo che salta un byte
DB 0xB8 ; primo byte di un'istruzione MOV EAX,0xXXXXXXXX (mancano altri 4 bytes)
; altri opcodes...

un disassemblatore leggerà:

JMP $+1
MOV EAX,0xXXXXXXXX
; codice disallineato...

Spesso accade che dopo qualche byte il codice si riallinea per caso, quindi ne viene offuscata solo una piccola parte.
Se questa tecnica viene congiunta all'uso di SMC (Self-Modifying Code) il programma diventa anche abbastanza difficile da debuggare.


7. Anti API tracer

Questo è il pezzo forte :-)
Il tracing delle chiamate API (solo quelle da parte della DLL) è reso impossibile per due motivi:

1) la Import Address Table in runtime viene scambiata con la Import Lookup Table: il codice della DLL continua a fare riferimento alle entries corrette (quelle della Import Address Table), ma negli headers l'RVA della IAT è scambiato con quello della ILT; di conseguenza non è possibile rintracciare la IAT per modificarla a scopo di intercettazione (un ostacolo non impossibile da superare, ma una bella noia per un ipotetico cracker ;-))

2) il binding della copia invisibile viene fatto in maniera speciale: nella Import Address Table in ciascuno slot non viene messo l'indirizzo effettivo della rispettiva funzione API, ma un indirizzo che punta a un thunk che esegue i primi byte di codice della API e salta al suo indirizzo più alcuni byte; in tal modo i primi byte del codice della funzione API non vengono eseguiti (viene eseguita una copia di essi), e non c'è pericolo di eseguire JMP messi all'inizio della funzione come breakpoint (tipico sistema dei trampolines).
Generalizzando si può dire che non è possibile intercettare le chiamate da parte della DLL a nessuna delle funzioni importate, siano esse API di Windows o altro.

Nota bene: alcune funzioni API iniziano col seguente codice:

PUSH EBP
MOV EBP,ESP

che occupa 3 bytes, mentre altre iniziano con quest'altro:

MOV EAX,EAX
PUSH EBP
MOV EBP,ESP

che ne occupa 5; dal momento che l'istruzione

MOV EAX,EAX

è inutile, lo stub prima di saltare al codice vero della funzione esegue sempre il codice da 3 bytes (quello senza il mov), ma quando deve saltare all'indirizzo della funzione salta 3 bytes più avanti nel primo caso, e 5 nel secondo; questo significa che nel secondo caso un JMP messo come breakpoint (che occupa 5 bytes) viene completamente saltato e l'esecuzione della funzione prosegue senza problemi, mentre nel primo caso il JMP provoca quasi sicuramente un crash (disallinea il codice); nella migliore delle ipotesi i due bytes rimanenti del JMP non rappresentano nessun opcode, quindi la CPU li salta ed esegue il resto della funzione senza nessun crash.


8. Invisibilità nel call stack

Rompendo la catena dei frame pointers (i push ebp/mov ebp,esp che avvengono all'inizio di ogni chiamata) è possibile far "scomparire" del tutto le funzioni della DLL dal call stack: all'inizio di ogni funzione è sufficiente spingere nello stack un frame pointer di qualche frame più su anziché quello attuale per far credere che la chiamata provenga ad esempio da kernel32.dll anziché dalla DLL. In tal modo si possono anche ingannare alcuni tipi di firewall software che in generale, quando intercettano una richiesta di comunicazione, oltre al processo che l'ha fatta cercano di individuare anche il particolare modulo (e lo fanno analizzando il call stack).


9. Intercettazione della creazione di nuovi processi

La DLL setta un breakpoint alla funzione API CreateProcessW mettendo un JMP all'inizio; in tal modo può intercettare la creazione di nuovi processi e rimapparsi all'interno di essi.

NOTA BENE: una chiamata a CreateProcessW da parte della DLL stessa causa un crash perché il JMP messo come breakpoint viene saltato solo in parte, e il rimanente codice che viene eseguito è parzialmente disallineato.
Se la DLL ha la necessità di chiamare CreateProcessW deve chiamare MyCreateProcessW al suo posto, che sarebbe la routine di handling dell'intercettazione dei nuovi processi; in alternativa può chiamare la CreateProcessW, ma prima deve togliere temporaneamente il JMP chiamando SetJmp(FALSE) e poi lo deve rimettere con SetJmp(TRUE).

p.s. se vuoi il codice te lo mando,ma è lungo...e il binding cosa sarebbe ?

il binding è la compilazione della Import Address Table (per compilazione ovviamente qui non intendo l'operazione di un compilatore, intendo semplicemente mettere i valori, riempire la tabella insomma).

allora,il rootkit fa hooking a tutti i processi,anche al mio anti-rootkit,quindi è già scontato che le funzioni sono state sovrascritte col jmp , e io non posso usare semplicemente CreateRemoteThread() o NtCreateThread() perchè l'anti rootkit me la cattura e non mi lascia fare injection se l'handle che gli passo è quello del suo processo,magari nascosto,...oppure magari mi fà fallire la chiamata in ogni caso,o quant'altro...insomma devo creare il thread senza usare le funzioni hookate dal rootkit... e quindi mappo una nuova ntdll a mano e chiamo NtCreateThread() di quella dll....poi come ti ho già detto non posso usare VirtualProtect() originale e company per scrivere sopra le funzioni,perchè il rootkit me le ha hookate e non mi lascia,quindi chiamo quella caricata a mano

be' a parte che un malware così sofisticato da impedire la DLL injection lo devo ancora vedere in genere i programmatori di malware non si fanno troppe seghe mentali molti virus esistenti sono mooolto più niubbi di quelli che potresti creare tu o io
comunque se hai paura che nel tuo processo originale CreateRemoteThread sia stata intercetta, semplicemente anche lì fai un controllo su tutte le funzioni API che importi per vedere se hanno dei JMP (e casomai controlla anche l'integrità della IAT ).

ma che strano,e come fanno a emulare le funzioni originali? sicuramente non le chiamano,perchè tu dici che il salto resta sempre,quindi in teoria ne chiamano una copiata a mano dall'originale prima di mettere il salto...boh leggerò l'articolo,comunque spiegami + o meno come emulano la funzione originale

il salto nella funzione originale rimane sempre: per chiamarla la funzione di intercettazione non la deve chiamare direttamente (altrimenti è chiaro che provoca uno stack overflow dopo un breve loop), ma deve chiamare per l'appunto il trampolino che altro non è che uno stub dove sono stati salvati i primi bytes della funzione originale più un JMP finale che manda l'esecuzione al codice della funzione originale saltando però il JMP messo all'inizio (è un po' complicato )

[71104]

ehm, piccolo problema
il txt si vede male perché HardwareUpgrade non fa il wordwrap automatico...

edit: sistemato

[cionci]

Originariamente inviato da 71104

il txt si vede male perché HardwareUpgrade non fa il wordwrap automatico...

Certo che lo fa, basta che tu non lo metta fra i tag code...

71104: potresti rimuovere il codice del virus... Capisco che sia interessante, ma altra gente potrebbe sfruttarlo...

[71104]

Originariamente inviato da cionci

Certo che lo fa, basta che tu non lo metta fra i tag code...

me n'ero accorto, tutto sistemato

71104: potresti rimuovere il codice del virus... Capisco che sia interessante, ma altra gente potrebbe sfruttarlo...

doh!!!
è proprio necessario? tanto non funziona, e probabilmente sono l'unico essere della terra in grado di correggere il problema in mezzo a quel "Coding Horror"...

[cionci]

Originariamente inviato da 71104

è proprio necessario? tanto non funziona, e probabilmente sono l'unico essere della terra in grado di correggere il problema in mezzo a quel "Coding Horror"...

Nella storia dei virus ce ne sono stati tantissimi che non funzionavano a dovere ed hanno fatto più danni della grandine...

Magari invialo in PVT a GordonFreeman...

[71104]

Originariamente inviato da cionci

Nella storia dei virus ce ne sono stati tantissimi che non funzionavano a dovere ed hanno fatto più danni della grandine...

Magari invialo in PVT a GordonFreeman...

vabbuo'...

[GordonFreeman]

Originariamente inviato da 71104

io infatti non parlavo di indirizzi fisici, parlavo proprio di indirizzi virtuali... che succede se dopo aver allocato la prima pagina, durante l'allocazione della seconda il sistema operativo si accorge che il programma ne ha già allocata una in quella posizione? deve saltare di qualche kilobyte e allocare dopo, e quindi le tue sezioni non sono più contigue (e non sto parlando di indirizzi fisici); è molto meglio lasciar fare al sistema operativo utilizzando un oggetto file mapping (che oltrettutto puoi anche condividere tra più processi risparmiando memoria quando non devi rilocare).

ma questo è assurdo,scusa,allora uno alloca memoria inutilmente,perchè non può nemmeno fare un memset o memcpy su tutta la memoria perchè va a scrivere byte contigui mentre la memoria allocata non lo è,quindi andando a scrivere sulle pagine che stanno in mezzo e provocando un disastro...non ci credo,che porcheria è??? poi tu dici che dopo aver allocato la prima pagina windows si accorge che la seconda è occupata etc.. ma lol! scusa tu a virtualalloc o malloc gli dici quanta memoria vuoi allocare,e windows calcola quante pagine sono,poi quando va a vedere le pagine libere sceglie un blocco di pagine CONTIGUE per allocarti la memoria,mica alloca una pagina alla volta eccetera?? boh magari me lo leggerò sul libro "Inside Windows 2000" se è come dici tu o meno,ma è ridicolo accidenti

Originariamente inviato da 71104

qui sotto ti ho messo il codice del mio virus, che fa esattamente questa cosa; occhio però che ha un problema (quasi) noto che devo ancora risolvere
mi funziona perfettamente se lo metto in un paio di processi, ma provoca schermata blu ( ) se lo metto in tutti...

<il codice è stato tempestivamente rimosso>

questa è la versione base del virus che mostra una semplice MessageBox ogni 5 sec. proveniente da tutti i processi... cioè da ciascun processo ogni 5 sec arriva la MessageBox (puoi immaginarti che cosa fastidiosa ).
avevo anche scritto un piccolo txt contenente la descrizione delle caratteristiche e delle tecniche usate nel virus, che ti copio di seguito (ce n'è una che non ho ancora applicato: l'invisibilità nel call stack).

va in crash perchè alcune appllicazioni native non possono fare messagebox,ho provato anch'io quando iniettavo la dll in tutti i processi caricando anche user32.dll,facevo un messagebox ma non funzionava mi sembra su smss.exe e lsass.exe e altri...ma non ricordo se addirittura mi mandava la schermata blu comunque prova ad evitare quei processi e vedi se fa il crash

Originariamente inviato da 71104

il binding è la compilazione della Import Address Table (per compilazione ovviamente qui non intendo l'operazione di un compilatore, intendo semplicemente mettere i valori, riempire la tabella insomma).

ah sì,lo sapevo,il loader dinamico (LdrLoadDll()) và a scrivere gli indirizzi delle funzioni importate sull'array FirstThunk della import address table...ok ma è inutile,tanto sia io che il rootkit non la usiamo...

Originariamente inviato da 71104

be' a parte che un malware così sofisticato da impedire la DLL injection lo devo ancora vedere in genere i programmatori di malware non si fanno troppe seghe mentali molti virus esistenti sono mooolto più niubbi di quelli che potresti creare tu o io
comunque se hai paura che nel tuo processo originale CreateRemoteThread sia stata intercetta, semplicemente anche lì fai un controllo su tutte le funzioni API che importi per vedere se hanno dei JMP (e casomai controlla anche l'integrità della IAT ).

heheh ma non si può leggere dentro le funzioni,perchè la pagina è solo PAGE_EXECUTE , sia senza l'hooking del rootkit che dopo , perchè poi il rootkit dopo aver messo il salto,ripristina la PAGE_EXECUTE e quindi i byte delle funzioni non sono + leggibili,ma solo eseguibili,se vado a leggere mi termina il programma....prima devo usare semmai ntvirtualquery e virtualprotect,ma a quel punto il rootkit si "insospettisce" e "scappa" non deve accorgersi che qualcuno fa robe sospette...e quindi siamo sempre lì,devo usare una funzione trusted...o un modulo caricato a mano oppure un "jmp ritardato" come dici tu,ma è rischioso perchè magari il rootkit non ha scritto il jmp all'inizio ma dopo,e magari ha sovrascritto anche i byte successivi...mah non mi fido hihi

Originariamente inviato da 71104

il salto nella funzione originale rimane sempre: per chiamarla la funzione di intercettazione non la deve chiamare direttamente (altrimenti è chiaro che provoca uno stack overflow dopo un breve loop), ma deve chiamare per l'appunto il trampolino che altro non è che uno stub dove sono stati salvati i primi bytes della funzione originale più un JMP finale che manda l'esecuzione al codice della funzione originale saltando però il JMP messo all'inizio (è un po' complicato )

sisi,ho capito,ma non mi fido,vedi sopra


un'ultima cosa: se faccio il file mapping ho una mappatura DEL FILE,ma come sai l'immagine in memoria di una dll non è identica al file,perchè la dimensione di allineamento delle sezioni del file è diversa dall'allineamento di sezioni in memoria,di solito è minore nel file,ad esempio in kernel32.dll le sezioni sono allineate a 0x400 bytes,e in memoria a 0x1000 bytes...e gli RVA si riferiscono all' "indirizzo relativo all'inizio del MODULO IN MEMORIA", e quindi non è un offset all'interno del file

ecco,allora fai conto che la funzione DllEntryPoint() che tu chiami nel file mapping object si riferisca a una variabile in ".idata"...il processo crasherà perchè l'indirizzo che DllEntryPoint ha usato è un RVA, che non corrisponde all'offset della variabile DENTRO IL FILE...spero di aver esposto bene il problema....

per quello ho allocato memoria allineando correttamente le sezioni e poi riempiendole e lasciando inalterati i byte di padding (di allineamento della sezione).... mamma mia che casino

[71104]

Originariamente inviato da GordonFreeman

ma questo è assurdo,scusa,allora uno alloca memoria inutilmente,perchè non può nemmeno fare un memset o memcpy su tutta la memoria perchè va a scrivere byte contigui mentre la memoria allocata non lo è,quindi andando a scrivere sulle pagine che stanno in mezzo e provocando un disastro...non ci credo,che porcheria è??? poi tu dici che dopo aver allocato la prima pagina windows si accorge che la seconda è occupata etc.. ma lol! scusa tu a virtualalloc o malloc gli dici quanta memoria vuoi allocare,e windows calcola quante pagine sono,poi quando va a vedere le pagine libere sceglie un blocco di pagine CONTIGUE per allocarti la memoria,mica alloca una pagina alla volta eccetera?? boh magari me lo leggerò sul libro "Inside Windows 2000" se è come dici tu o meno,ma è ridicolo accidenti

AAAAAAAAAAAAAHHHHFERMAFERMAFERMAFERMAFERMAFERMA!!!!!!!
stiamo dicendo cose diverse O_o'
dunque: io (che chissa perché quando leggo su HWU capisco sempre male, sarà che leggo di fretta... O_o') avevo capito che tu per ogni sezione chiamavi VirtualAlloc, o cmq che la chiamavi più volte; da quest'ultimo post invece mi sembra che la chiami una volta sola per allocare TUTTO, e in tal caso non c'è NESSUNISSIMO problema, se non quello che devi stare attento a calcolare la reale dimensione dell'immagine PE una volta caricata in memoria.

va in crash perchè alcune appllicazioni native non possono fare messagebox,ho provato anch'io quando iniettavo la dll in tutti i processi caricando anche user32.dll,facevo un messagebox ma non funzionava mi sembra su smss.exe e lsass.exe e altri...ma non ricordo se addirittura mi mandava la schermata blu comunque prova ad evitare quei processi e vedi se fa il crash

veramente non c'entra, se alcuni processi non possono chiamare MessageBoxA (o W) sarà perché non hanno user32.dll, ma:
1) il mio bel loader invisibile carica la mia DLL in modalità invisibile, ma usa anche la normale LoadLibraryA per caricare tutti i moduli da cui dipende
2) non ho mai provato ad entrare in processi del sistema operativo (cioè in processi avviati da SYSTEM), ho provato solo con notepad, mspaint, explorer, e cazzate simili.
il problema è un problema di istanze e di protezione Copy-On-Write (come ti dicevo, il problema è (quasi) noto )

heheh ma non si può leggere dentro le funzioni,perchè la pagina è solo PAGE_EXECUTE ,

la IA32 non fa distinzione tra permessi di esecuzione e permessi di lettura
se hai i permessi di esecuzione hai anche quelli di lettura e viceversa, vai tranquillo

un'ultima cosa: se faccio il file mapping ho una mappatura DEL FILE,ma come sai l'immagine in memoria di una dll non è identica al file,perchè la dimensione di allineamento delle sezioni del file è diversa dall'allineamento di sezioni in memoria,di solito è minore nel file,ad esempio in kernel32.dll le sezioni sono allineate a 0x400 bytes,e in memoria a 0x1000 bytes...e gli RVA si riferiscono all' "indirizzo relativo all'inizio del MODULO IN MEMORIA", e quindi non è un offset all'interno del file

ecco,allora fai conto che la funzione DllEntryPoint() che tu chiami nel file mapping object si riferisca a una variabile in ".idata"...il processo crasherà perchè l'indirizzo che DllEntryPoint ha usato è un RVA, che non corrisponde all'offset della variabile DENTRO IL FILE...spero di aver esposto bene il problema....

per quello ho allocato memoria allineando correttamente le sezioni e poi riempiendole e lasciando inalterati i byte di padding (di allineamento della sezione).... mamma mia che casino

capisco perfettamente il problema, ci sono passato anch'io: io inizialmente credevo che l'immagine in memoria fosse diversa solo per i files generati dai compilatori "sfigati" () e che in realtà i compilatori "tosti" () generassero immagini "comode" da mappare direttamente...
dopodiché un bel giorno di punto in bianco il virus mi inizia a crashare senza motivo e analizzandolo col PEView scopro che gli RVA sono *COMPLETAMENTE DIVERSI* dagli offset... :|
ed era il compilatore Intel
quindi ho continuato ad usare sempre la tecnica dei file mapping, ma in maniera un po' diversa: premesso che non mi fido del flag SEC_IMAGE che si può passare alla CreateFileMapping, io procedo come segue:
1) leggo gli headers direttamente dal file e calcolo la dimensione complessiva dell'immagine virtuale una volta caricata in memoria
2) creo un file mapping object nel file di paging con la dimensione calcolata
3) ci ricopio manualmente gli headers e le sezioni
4) riloco e bindo
in pratica potrei anche usare il semplice VirtualAlloc, vero, ma col file mapping object risparmio memoria

[GordonFreeman]

ok dai allora il casino che avevo è il rilocamento,speriamo che facendolo possa avere delle API trusted funzionanti
per ora provo un normale virtualalloc e poi le ottimizzazioni vengono alla fine

ma è vero che non si può creare thread remoti nel processo SYSTEM e alcune applicazioni native?

e un'ultima domanda,considera questo dump di NtCreateFile()

NtCreateFile:
mov eax, 0x0000001A
lea edx, [esp+04]
int 0x2E
ret 0x2C

se io , per chiamare la funzione originale , semplicemente eseguissi quelle istruzioni invece di chiamare la funzione??

fantoibed all'inizio mi ha detto che non funziona,che non è la stessa cosa...ma allora non lo sarebbe nemmeno il chiamare le api trusted che carichiamo a mano tu e io... spiegami cosa intendeva

[71104]

Originariamente inviato da GordonFreeman

ok dai allora il casino che avevo è il rilocamento,speriamo che facendolo possa avere delle API trusted funzionanti
per ora provo un normale virtualalloc e poi le ottimizzazioni vengono alla fine

ma è vero che non si può creare thread remoti nel processo SYSTEM e alcune applicazioni native?

in generale credo che sia possibile chiamare OpenProcess su processi creati sotto altri utenti solo se si ha SE_DEBUG_NAME, quindi te lo deve permettere la policy e poi devi anche abilitare il privilegio (che è disabilitato di default). credo che solo gli amministratori di default abbiano SE_DEBUG_NAME. cmq di tutto questo nn sono sicuro...

e un'ultima domanda,considera questo dump di NtCreateFile()

NtCreateFile:
mov eax, 0x0000001A
lea edx, [esp+04]
int 0x2E
ret 0x2C

se io , per chiamare la funzione originale , semplicemente eseguissi quelle istruzioni invece di chiamare la funzione??

fantoibed all'inizio mi ha detto che non funziona,che non è la stessa cosa...ma allora non lo sarebbe nemmeno il chiamare le api trusted che carichiamo a mano tu e io... spiegami cosa intendeva

mah, veramente non vedo perché non dovrebbe funzionare: nessuna di quelle istruzioni è privilegiata... guai se lo fosse... tu prova, in effetti chiamare direttamente l'interrupt anziché lo stub dell'API nativa mi sembra un'ottima idea!
secondo me funziona...

[GordonFreeman]

Originariamente inviato da 71104

mah, veramente non vedo perché non dovrebbe funzionare: nessuna di quelle istruzioni è privilegiata... guai se lo fosse... tu prova, in effetti chiamare direttamente l'interrupt anziché lo stub dell'API nativa mi sembra un'ottima idea!
secondo me funziona...

si beh,ma non si può sperare che siano così tutte le funzioni che ci interessano,sicuramente qualcuna di quelle userà le strutture dati interne alla ntdll.dll...e in quel caso bisogna chiamare la funzione originale comunque (o in una dll copia)...però si può sempre provare a vedersi i dump , magari lo farò,e in tal caso si potrebbe fare a meno di sbattersi la testa con virtualalloc,file mapping,sezioni,rilocamento etc. e sarebbe una buona cosa...

vabbeh...tutto questo lo devo fare per la tesi di laurea...solo a me potevano dare una mazzata del genere da fare , che sfiga

consideriamo un'altra cosa: se il rootkit è furbo non chiama ntcreatefile,ma per usare un file esegue lo stub direttamente,quindi io anti-rootkit illuso non lo beccherò mai,non saprò mai che usa i file nascosti...da qui la necessità di scrivere un filter driver che catturi gli IORP e che lo becchi per forza,da lì non scappa...heheh ma tanto i rootkit modo utente con cui devo avere a che fare sono NtIllusion e pochi altri rootkit modo utente poco furbi,che non lo fanno ma chiamano la funzione...

cioè mi è stato assegnato di fare tutto ciò che è possibile in modo utente...ed è questo secondo me ...più di così bisogna scrivere un filter driver , nel caso che il rootkit sia "furbo" come ho detto sopra, o no?

[71104]

Originariamente inviato da GordonFreeman

cioè mi è stato assegnato di fare tutto ciò che è possibile in modo utente...ed è questo secondo me ...più di così bisogna scrivere un filter driver , nel caso che il rootkit sia "furbo" come ho detto sopra, o no?

più che catturare gli IRP dovresti sostituire l'int 2E (occhio che rischi di mandare veramente tutto a gentil donzelle è meglio che fai prima CLI, poi sostituisci, e poi fai STI ).
comunque penso di no, più di così non puoi fare: se il rootkit chiama direttamente int 2E senza passare per gli stub di ntdll.dll amen...

[GordonFreeman]

Originariamente inviato da 71104

più che catturare gli IRP dovresti sostituire l'int 2E (occhio che rischi di mandare veramente tutto a gentil donzelle è meglio che fai prima CLI, poi sostituisci, e poi fai STI ).
comunque penso di no, più di così non puoi fare: se il rootkit chiama direttamente int 2E senza passare per gli stub di ntdll.dll amen...

e invece no! heheh senti questa:

allora,considera la funzione NtQuerySystemInformation , con il parametro SystemHandleInformation...ecco io nell'anti-rootkit posso ottenere tutti gli handle del sistema , duplicarli per il mio processo , e usare NtQueryObject() , come ho detto in questo post
http://www.hwupgrade.it/forum/showthread.php?t=1031131

allora,lì c'è il problema delle pipe che non posso interrogarle per sapere il loro nome se no il mio thread si blocca e bisogna riavviare il sistema fisicamente,col tasto per resettare

quindi direi che invece che usare NtQueryObject() posso usare questa funzione presente in un MSDN Example, che si chiama
GetFilenameFromHandle()
http://msdn.microsoft.com/library/de...ile_handle.asp

bene ,quest'approccio implica non usare l'altro,che sarebbe inutile a questo punto heheh,cioè si può fare tutto in locale,non serve fare dll injection


ora i problemi sono 2:

1. siamo sicuri che CreateFileMapping() non si blocchi sulle pipe?? spero che ritorni solo un errore

2. per usare un CreateFileMapping() trusted,forse combino a caricare un ntdll a mano e chiamare NtCreateSection() , ma per GetMappedFileName() come farei?? questo è un po' un casino,perchè io non so quali funzioni di ntdll esso chiama e più o meno com'è implementata...allora direi di fare una furbata:

- sospendo tutti i processi forchè il mio chiamando NtSuspendProcess() che è disponibile da windows xp
- chiamo NtCreateProcess() dalla mia dll trusted e creo un "processino" che faccia questo lavoro,senza alcun pericolo di hooking perchè nessuno può aver intercettato la chiamata,e poi se ipotizziamo un thread nel processo rootkit che periodicamente chiama NtQuerySystemInformation per ottenere i processi sul sistema...beh non può vederlo perchè il rootkit viene sospeso
- chiamo NtResumeProcess() per far ripartire tutti i processi

hihihih ma tutto questo và fatto periodicamente,e spero che non rallenti vistosamente il sistema...ma chissenefrega,sicuramente sarà + veloce di zonealarm

poi c'è un pericolo che il rootkit metta questo thread "demone" in tutti i processi,anche nel mio,ma anche lì posso controllare i miei thread e vedere se ce n'è qualcuno che so di non aver creato io