Domanda [AIUTO]Problema dll injection

[LoSborone]

Ciao a tutti, essendo ignorante in materia di programmazione cercavo aiuto per capire come bloccare le dll injection su un certo programma.
Ho il file che subisce l'injection e anche il "programmino" che inietta la dll perciò posso fornirvi tutto.
Gentimente chiedo chi può dedicare qualche minuto del suo tempo per aiutarmi con questo problemino.
Grazie mille

 

[digger]

mmm non ho mai preso in considerazione l'argomento quindi non ho esperienza, però solitamente quando si inietta una dll (specie se per hackerare un gioco) una delle cose che avviene è che nell'entry point della .dll di solito c'è un CreateThread che lancia una qualche funzione che si trova nella .dll appena iniettata, quindi non saprei dirti come impedire l'injecting, ma se il tuo programmino Detourasse il CreateThread e controllasse in qualche modo se sei tu a lanciarlo o qualcuno non autorizzato, in teoria dovresti rendere inoffensiva la dll appena iniettata.
Io avevo fatto cosi in un mio programma dove iniettavo hack di altri ma volevo che non partissero in automatico e funzionava.
Vale solo se il programmino vittima dell'injecting è il tuo e hai il source code. Se non è il tuo si complica
Cosi su due piedi è l'unica idea che mi viene in mente

 

[LoSborone]

Ciao, grazie per la risposta. Purtroppo l'eseguibile del gioco non è creato da me quindi non saprei dirti! Non c'è modo di bloccare queste iniezioni di codice oppure bloccare l'accesso da parte di dll esterne al programma? Scusa se non utilizzo termini corretti ma non è il mio "ambito" la programmazione!

 

[Whivel]

Ciao, grazie per la risposta. Purtroppo l'eseguibile del gioco non è creato da me quindi non saprei dirti! Non c'è modo di bloccare queste iniezioni di codice oppure bloccare l'accesso da parte di dll esterne al programma? Scusa se non utilizzo termini corretti ma non è il mio "ambito" la programmazione!

potresti controllare i moduli che sono caricati dal processo.
EnumProcessModulesEx function

 

[LoSborone]

E una volta fatto questo come si potrebbe procedere?

 

[Whivel]

controlli che ci siano solo dll necessarie al tuo programma.

 

[LoSborone]

Ma non è quello il fatto... so per certo che c'è un injector che inietta una dll nel mio programma e io vorrei fermare quello
Basterebbe un crypter per l'eseguibile? Oppure che mi consigliate?

 

[Whivel]

io non so che succede al mondo, perché questo ragionamento mi pare banale:
Se trovi una dll aggiuntiva rispetto a quelle che ti aspetti, significa che qualcuno ne ha iniettata una.

 

[LoSborone]

Allora, per spiegarlo in breve: so per certo che c'è un dll injector per il mio programma e iniettano una dll per avviare un processo automatico che io non voglio si utilizzi.
Vorrei bloccare la possibilità di iniettare dll nel mio programma in qualche maniera... come fare?

 

[SpeedJack]

Allora, per spiegarlo in breve: so per certo che c'è un dll injector per il mio programma e iniettano una dll per avviare un processo automatico che io non voglio si utilizzi.
Vorrei bloccare la possibilità di iniettare dll nel mio programma in qualche maniera... come fare?

LOL ma scherzi? Te lo ha spiegato già 2 volte xD Enumera i moduli del processo target e guarda se c'è un modulo in più a quelli che dovrebbero esserci normalmente!

 

[digger]

LOL ma scherzi? Te lo ha spiegato già 2 volte xD Enumera i moduli del processo target e guarda se c'è un modulo in più a quelli che dovrebbero esserci normalmente!

quello che dici Speed non è detto che sia fattibile nel suo caso... non ho capito veramente bene in suo problema, ma se la dll viene iniettata in un pc che non è il suo non è detto che lui sappia quali sono i moduli caricati nei processi di quel computer normalmente (escludendo quindi la dll indesiderata di cui parla), ricorda infatti che molti software si prendono la briga di iniettare loro dll in ogni processo che parte a tua insaputa.

Diverso sarebbe se lui sapesse a priori il nome della dll che viene iniettata, certo che se poi chi la inietta capisce e cambia il nome siamo punto a capo

 

[francoForte]

quello che dici Speed non è detto che sia fattibile nel suo caso... non ho capito veramente bene in suo problema, ma se la dll viene iniettata in un pc che non è il suo non è detto che lui sappia quali sono i moduli caricati nei processi di quel computer normalmente (escludendo quindi la dll indesiderata di cui parla), ricorda infatti che molti software si prendono la briga di iniettare loro dll in ogni processo che parte a tua insaputa.

Diverso sarebbe se lui sapesse a priori il nome della dll che viene iniettata, certo che se poi chi la inietta capisce e cambia il nome siamo punto a capo

Ciò che dici è sbagliato, o forse semplicemente non hai capito il problema. Se ha accesso al source code e può modificarlo, leggere i simboli del moduli caricati gli permette di vedere se una dll è stata iniettata.

 

[Whivel]

quello che dici Speed non è detto che sia fattibile nel suo caso... non ho capito veramente bene in suo problema, ma se la dll viene iniettata in un pc che non è il suo non è detto che lui sappia quali sono i moduli caricati nei processi di quel computer normalmente (escludendo quindi la dll indesiderata di cui parla), ricorda infatti che molti software si prendono la briga di iniettare loro dll in ogni processo che parte a tua insaputa.

Diverso sarebbe se lui sapesse a priori il nome della dll che viene iniettata, certo che se poi chi la inietta capisce e cambia il nome siamo punto a capo

questo in vb.net (ma ovviamente le informazioni di questo tipo non se le inventa, usa API del s.o. che si possono usare anche in C)
Proprietà Process.Modules (System.Diagnostics)

Un modulo di processo rappresenta un file DLL o EXE caricato in un particolare processo.Un'istanza di ProcessModule consente di visualizzare le informazioni relative a un modulo, tra cui il nome del modulo, il nome file e i dettagli relativi alla memoria del modulo.

questo estratto e Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2 questa spiegazione del formato PE (portable executable) soprattutto il paragrafo "The Imports Section" (che ti fa capire come windows decide i moduli da caricare), dovrebbe chiudere ogni dubbio

 

[digger]

Ciò che dici è sbagliato, o forse semplicemente non hai capito il problema. Se ha accesso al source code e può modificarlo, leggere i simboli del moduli caricati gli permette di vedere se una dll è stata iniettata.

Ha detto che non ha il source, e comunque non serve il source per vedere i moduli caricati.

questo in vb.net (ma ovviamente le informazioni di questo tipo non se le inventa, usa API del s.o. che si possono usare anche in C)
Proprietà Process.Modules (System.Diagnostics)


questo estratto e Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2 questa spiegazione del formato PE (portable executable) soprattutto il paragrafo "The Imports Section" (che ti fa capire come windows decide i moduli da caricare), dovrebbe chiudere ogni dubbio

E tutto questo cosa c'entra con quello che ho scritto io?

 

[Whivel]

Ha detto che non ha il source, e comunque non serve il source per vedere i moduli caricati.

E tutto questo cosa c'entra con quello che ho scritto io?

ufff.... Il formato PE è il contenuto del file .exe => leggi i moduli che l'eseguibile chiede di caricare => controlli i moduli caricati durante l'esecuzione => se == allora OK altrimenti INJECTION

 

[francoForte]

Hai ragione, non serve, basta aprirlo in un loop di debugging leggendo l'evento LOAD_DLL_DEBUG_EVENT

 

[digger]

ufff.... Il formato PE è il contenuto del file .exe => leggi i moduli che l'eseguibile chiede di caricare => controlli i moduli caricati durante l'esecuzione => se == allora OK altrimenti INJECTION

dai ce lo metto pure io un ufff ma hai letto cosa ho scritto? non ci sono solo i moduli che il programma stesso carica per i motivi suoi, ci sono spesso software (legittimi) in esecuzione che si prendono la briga di iniettare ulteriori dll nei processi altrui (ad esempio alcuni antivirus) quindi se ti limiti a controllare che non ci siano dll caricate che non hai previsto probabilmente detecterai spesso un'inezione indesiderata che indesiderata non è

 

[francoForte]

potresti controllare i moduli che sono caricati dal processo.
EnumProcessModulesEx function

Ma la tua strategia è assurda, EnumProcessModulesEx è eseguita sui moduli caricati, lui vuole prevenirlo invece

 

[francoForte]

E' una strategia che non può funzionare. In ogni caso andrai ad enumerare dll già caricate (proprio come la mia soluzione con il loop di debugging), lui vuole evitare che vengano caricate

 

[digger]

E' una strategia che non può funzionare. In ogni caso andrai ad enumerare dll già caricate (proprio come la mia soluzione con il loop di debugging), lui vuole evitare che vengano caricate

non ho ben capito, in realtà se interpreto nel modo giusto la tua idea, in realtà tu non andresti a vedere dll già caricate ma detecteresti invece proprio quelle in caricamento.

In ogni caso non avendo lui il source del programma mi pare tutta una discussione inutile, anche pensando al modo giusto poi cosa fa? cracca il programma per modificarlo in modo che impedisca l'injecting? boh

 

[francoForte]

non ho ben capito, in realtà se interpreto nel modo giusto la tua idea, in realtà tu non andresti a vedere dll già caricate ma detecteresti invece proprio quelle in caricamento.

In ogni caso non avendo lui il source del programma mi pare tutta una discussione inutile, anche pensando al modo giusto poi cosa fa? cracca il programma per modificarlo in modo che impedisca l'injecting? boh

no appunto, ne la mia idea (di usare l'evento di debugging per le dll) ne quella di enumerare le dll stesse possono funzionare, appunto perché vanno a leggere le dll già caricate. Una cosa da fare potrebbe essere mascherare l'entry point? Non lo so...

 

[Whivel]

dai ce lo metto pure io un ufff ma hai letto cosa ho scritto? non ci sono solo i moduli che il programma stesso carica per i motivi suoi, ci sono spesso software (legittimi) in esecuzione che si prendono la briga di iniettare ulteriori dll nei processi altrui (ad esempio alcuni antivirus) quindi se ti limiti a controllare che non ci siano dll caricate che non hai previsto probabilmente detecterai spesso un'inezione indesiderata che indesiderata non è

ho scritto una cosa corretta: lui non vuole che vengano iniettate dll. Quella soluzione lo fa.
Inoltre non credo che un computer abbia miliardi di programmi non noti (gli av sono abbastanza noti) che iniettano dll e comunque la soluzione rimane valida, perché non ho detto che devi fare un confronto 1 a 1 (per esempio se la dll si trova sul desktop, non credo sia un AV no?)

---------- Post added at 18:52 ---------- Previous post was at 18:50 ----------

o meglio quella soluzione controlla se sono presenti dll iniettate o meno ad un certo momento.

 

[digger]

allora ti faccio un esempio semplicissimo a caso.
Ho appena aperto notepad sul mio pc,
bene, se vado a vedere quali DLL sicuramente notepad deve avere in memoria e controllo poi quali EFFETTIVAMENTE ci sono caricate nel suo spazio di indirizzi, cosi a colpo d'occhio vedo subito che ci sono sicuramente 3 dll inaspettate. 1 sembra una dll di patching probabilmente di una service pack di windows, te l'aspettavi?
Un'altra è una dll della synaptics per via del mio touchpad visto che sono su un portatile, te l'aspettavi?
e la terza è una dll di un tool di utilità che normalmente si installa insieme ai drivers sui portatili della Lenovo come quello che sto usando io ora, te l'aspettavi?
Capisci quello che intendo?
Se ti limiti a verificare se ci sono dll in memoria che non ti aspettavi, non puoi avere la certezza che siano "indesiderate", devi avere qualche altro modo per identificarla.
Secondo me il sistema migliore resta sempre quello di intercettare l'injecting e non far "entrare" nessuna dll nuova, che sia quella che lui non vuole che si inietti o che sia di qualche tool di terze parti come accade nel mio notepad poco cambia, probabilmente il programma funzionerà lo stesso (magari con qualche funzionalità in meno ad es nel mio caso con il touchpad) ma almeno è sicuro che anche la dll indesiderata non verrà caricata

p.s. ne ho trovate altre 2:
btmmhook.dll
guard32.dll

te le aspetteresti?
una fa parte dello stack bluetooth della broadcom e l'altra fa parte dell'antivirus che ho sul mio computer

e secondo me se vado avanti ad indagare ne trovo anche altre.
Però tieni presente che se anche le elencassi tutte poi magari chiedo ad un mio amico di lanciare il suo notepad e probabilmente lui avrà dll diverse caricate in memoria, è questo quello che intendevo

 

[Whivel]

allora ti faccio un esempio semplicissimo a caso.
Ho appena aperto notepad sul mio pc,
bene, se vado a vedere quali DLL sicuramente notepad deve avere in memoria e controllo poi quali EFFETTIVAMENTE ci sono caricate nel suo spazio di indirizzi, cosi a colpo d'occhio vedo subito che ci sono sicuramente 3 dll inaspettate. 1 sembra una dll di patching probabilmente di una service pack di windows, te l'aspettavi?
Un'altra è una dll della synaptics per via del mio touchpad visto che sono su un portatile, te l'aspettavi?
e la terza è una dll di un tool di utilità che normalmente si installa insieme ai drivers sui portatili della Lenovo come quello che sto usando io ora, te l'aspettavi?
Capisci quello che intendo?
Se ti limiti a verificare se ci sono dll in memoria che non ti aspettavi, non puoi avere la certezza che siano "indesiderate", devi avere qualche altro modo per identificarla.
Secondo me il sistema migliore resta sempre quello di intercettare l'injecting e non far "entrare" nessuna dll nuova, che sia quella che lui non vuole che si inietti o che sia di qualche tool di terze parti come accade nel mio notepad poco cambia, probabilmente il programma funzionerà lo stesso (magari con qualche funzionalità in meno ad es nel mio caso con il touchpad) ma almeno è sicuro che anche la dll indesiderata non verrà caricata

non mi sembrano così anormali.
Per il patching: sì me lo aspettavo.
per il resto no.

Comunque il metodo rimane applicabile. Non infallibile ma applicabile.

Secondo me il sistema migliore resta sempre quello di intercettare l'injecting e non far "entrare" nessuna dll nuova

Nuove rispetto a cosa? Le Dll dell'AV, ecc. sono iniettate? allora come distingui quelle dalle altre iniettate?

 

[digger]

Nuove rispetto a cosa? Le Dll dell'AV, ecc. sono iniettate? allora come distingui quelle dalle altre iniettate?

E' questo che intendo per "nuove", per onestà diciamo pure che alcune non so bene in quale momento vengono caricate (ad es. quelle di patching), ma le altre (tools di 3e parti come quelle del thinkpad e del touchpad) credo che con buona probabilità vengano iniettate dopo che il processo è stato startato, e qui andrebbe probabilmente a finire anche l'injecting della dll che il nostro amico non vuole.
quindi quando dico "quelle nuove" intendo tutte queste, quindi forse quella di patching mi si infila comunque nel processo, ma quelle del touchpad, del thinkpad, tante altre e quella che NON vogliamo si inietti, ci sono buone probabilità di fermarle. Un'altra dll che non so bene quando viene iniettata è quella dell'antivirus.
Sono tutte cose che andrebbero verificate comunque