Domanda [AIUTO]Problema dll injection

[Whivel]

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

ma a questo punto anche la mia soluzione è adegauta: cambia lo scopo. Tu eviti l'iniezione, io vedo se è presente ad un dato istante. Per poter dare giudizi ulteriori bisogna conoscere le cose che hai appena citato

 

[digger]

Tanto per fare una prova molto "barbara" ho provato a scrivere una piccola .dll che iniettata in notepad si limita a patchare i primi bytes della funzione LoadLibrary direttamente nella memoria del processo facendo si che la prima istruzione sia un retn 4.
In questo modo da qualunque parte (compreso notepad stesso) la funzione venisse chiamata non darebbe nessun effetto.
Siccome il modo piu frequente di iniettare dll (non l'unico) è quello di creare un thread remoto chiamando loadlibrary per far si che carichi la propria dll nel processo di destinazione, cosi facendo dovremmo ottenere che chiunque cercasse di iniettare in questo modo non ci dovrebbe riuscire.
Subito dopo ho provato ad iniettare una mia .dll precedente che avevo usato per testare i breakpoints usando le seh, ma mentre prima si iniettava con successo e poi funzionava, ora non si iniettava nemmeno piu. Quindi sembrerebbe che il metodo funziona senza nemmeno dover scrivere troppo codice.
Il problema di questo metodo "stupido" è che non tiene conto di chi e perchè sta chiamando LoadLibrary, in questo modo rischiamo di perdere funzionalità importanti del nostro programma (nel mio caso in notepad non si apre piu l'help in linea) o addirittura di farlo crashare.
Certo se siamo sicuri che il nostro programma non ha bisogno di chiamare loadlibrary dopo un certo momento allora possiamo andare abbastanza tranquilli.
Se mai avrò tempo e voglia approfondirò la cosa per vedere come codificare qualcosa di piu "intelligente".

p.s. ovviamente il mio era solo un test, nel caso del nostro amico non potrebbe usare un injecting per il patching, quindi a questo punto dovrebbe modificare staticamente l'eseguibile, cercare un'area per un codecave dove andare a mettere il codice che patcha la LoadLibrary e dovrebbe trovare nel codice il punto da cui chiamare il codecave possibilmente dopo tutte le chiamate a loadlibrary eventualmente presenti nel suo programma

 

[LoSborone]

Salve a tutti, mi sono "perso" nei vostri discorsi in quanti, come già detto, ignorante in materia di programmazione
Leggendo qua e la per internet ho trovato un programma, Enigma Protector, e da quanto ho letto ha diverse funzioni sui programmi.
Ho fatto alcune prove ma quando vado a "proteggere" il mio file eseguibile, all'avvio crasha subito e si blocca.... qualcuno di voi ha esperienza con questo programma osa dirmi se potrebbe funzionare per il mio scopo?
Grazie

 

[Whivel]

@Whivel ufff (sono più gli ufff contro di te che quelli che tu puoi permetterti di fare). Enumeri i processi già caricati! Come fai a prevenire il caricamento di una dll se la leggi quando è già caricata? Non logico, soluzione errata

io non ho mai parlato di prevenire, almeno non intendendo una soluzione che eviti l'iniezione. Io ho sempre parlato di prevenzione nel senso di evitare che il programmi continui l'esecuzione in caso di iniezione.

Es: i sistemi anti tampering non possono evitare la modifica, ma possono prevenirla nel senso che il codice non viene eseguito

---------- Post added at 17:17 ---------- Previous post was at 17:13 ----------

@Whivel ufff (sono più gli ufff contro di te che quelli che tu puoi permetterti di fare).

perché se è lecito chiedere?

 

[coroner]

io non ho mai parlato di prevenire, almeno non intendendo una soluzione che eviti l'iniezione. Io ho sempre parlato di prevenzione nel senso di evitare che il programmi continui l'esecuzione in caso di iniezione.

Es: i sistemi anti tampering non possono evitare la modifica, ma possono prevenirla nel senso che il codice non viene eseguito

---------- Post added at 17:17 ---------- Previous post was at 17:13 ----------

perché se è lecito chiedere?

Lui vuole bloccare l'iniezione!

 

[Whivel]

Lui vuole bloccare l'iniezione!

Bloccare un'iniezione non significa necessariamente non farla fare, ma puó significare anche rilevarla ed attuare delle operazioni di conseguenza. Non dico che la mia soluzione sia universale, ma é una soluzione

 

[digger]

un po' quello che succede in warrock, tu l'iniezione la fai, poi quello se ne accorge e ti butta fuori.
Ma secondo me dopo che te ne accorgi piuttosto che qualche azione plateale tipo chiudere il programma o visualizzare qualcosa meglio ancora se fai cose "strane" tipo impallare il programma, rallentarlo, cose cosi, in questo modo chi inietta non capisce che è stato detectato ma pensa di aver scritto uno schifo di dll oppure che ci sono problemi di altro tipo