Newsgroup: it.comp.lang.visual-basic
Titolo: [DA FAQ] Proteggere una dll da usi non autorizzati.

Ciao a tutti.
Torno ancora in argomento (guardando google ho visto dei post passati
veramente interessanti):
"Come fare a proteggere una dll scritta in VB da usi non autiorizzati?".
Questo ormai per mè sta diventando un punto cruciale soprattutto perchè
abbiamo messo tutto il nostro framework in varie dll e se uno fa il
cattivello le riusa per farsi un gestionele.
Ho quindi pensato di mettere una property o un metodo in ogni dll per
sbloccarla, ma tale property o metodo sarebbe comunque visibile dall'
esterno e con un bel dll replacing si sgamano anche tutti i valori passati
(dopo ne parlo).
Ho quindi pensato che se metto un modulo pubblico nella dll c'è una (penso
vaga) possibilità di poterlo utilizzare dal progetto chiamante. Che so un
metodo tipo "unlock" a cui passo qualcosa;
Ma come potrei fare?
Thanks
SebaMix
P.S. dll replacing : il termine me lo sono inventato al momento (non so se
ne esiste uno standard) :).
Mettiamo che voi avete installato un programma che usa alcune dll e che
guardacaso queste dll vi interessano particolarmente tanto;
Il primo passo da compiere è tirare giù la lista di tutti i metodi e propery
della dll (premendo F2 da VB). A questo punto create un nuovo progetto DLL
ActiveX ed impostatene la compatibilità binaria sulla dll che desiderate
utilizzare.
Ricostruite tutto il sistema di property, metodi e classi e all'inteno di
ognuno metteteci un msgbox che vi visualizza i valori passati alla propery o
metodo, compilate la dll e (per essere sicuri) deregistrate quella
precedente e registrate quella nuova (regsvr32) e lanciate il programma
vittima.
Quando questo istanzierà gli oggetti presenti nella dll sostituita non si
accorgerà che l'avete cambiata (o almeno non è successo con l'unica prova
che ho fatto) e voi potrete vedere tutti i parametri che il programma passa
alla classe.
Deregistrate quella da voi creata e riregistrate quella originale che ora è
pronta all' uso. :(
P.P.S. Non mi assumo alcuna responsabilità su quanto detto;
P.P.P.S. Ecco perchè il codice per la registrazione e check attivazioni del
programma non lo metto MAI in una dll :) ;
P.P.P.P.S. Con dll scritte in C/C++ (che richiedono di API) non credo questo
metodo funzioni :( ;


Perche', pensi che le DLL COM non richiedano API? :)
Con le DLL C hai solo il problema di non conoscere il numero e il tipo dei
parametri, ma non e' cosi' grave, specie con le chiamate safecall... Ci
metti poco a trovare il numero, mente il tipo lo sgami hookando la chiamata
e facendo un dump dello stack.
That's all folks...
Ciaotutti,
*

 proxy/stub.
Già meglio come terminologia :)
[...]
CiaoZ
SebaMix

 >             ComputeKey(Param As Long) Then
Ne hai due, una nella DLL e una nell'exe; in entrambe i casi non sono
funzioni esportate; l'exe passa alla DLL l'indirizzo della propria funzione
(usando la GetVBProcAddress), la DLL la chiama (usando la
CallOneParamProcedure) e confronta il suo valore di ritorno con quello che
ha calcolato autonomamente.
Nota che e' la DLL a guidare le danze, in quanto il parametro di riferimento
per il calcolo della chiave da parte della procedura dell'EXE lo decide lei,
percui e' la DLL ad autenticare l'exe e non viceversa.
Non so se mi sono spiegato :)
Ciaotutti,
*

 in C, altrimenti l'avrei scritta immediatamente in VB, no? :)
e noi che ne sappiamo ?
magari vb non lo conosci e te la sei cavata meglio che potevi...
non ti scusare, non ce n'e' bisogno :))
j.honni.soit

 magari vb non lo conosci e te la sei cavata meglio che potevi...
Piu' che altro e' il contrario: per riuscire a scrivere quelle tre righe di
C mi ci e' voluto un quarto d'ora di esplorazione nell'MSDN per ricordarmi
come cavolo si facesse la definizione di un tipo procedurale :P
Cmq dovrebbero funzionare... Magari sarebbe carino piazzare uno __stdcall da
qualche parte, giusto per garantire che il compilatore non liberi lo stack
due volte (o zero volte), che non sarebbe carino :P
Ciaotutti,
*