View Full Version : Parere su un metodo di protezione
Mi era venuto in mente che un metodo per proteggere un programma
tecnico-ingeneristico sarebbe quello di fornire(dopo il periodo di valutazione)risultati errati di una percentuale random (diciamo 10%-30 %
positiva o negativa a casaccio).
Questo senza mostrare pericolosi pop-up di avvertimento che sono facilmente rintracciabili con Soft-Ice.
Che ne pensate?
lombardp
01-07-2003, 07:29
Secondo me è un metodo che "impaurisce" l'utilizzatore, nel senso che avrà sempre paura che il meccanismo di "iniezione dell'errore" possa rimanere attivo.
Meglio limitare le complessità dei problemi trattabili dopo la "scadenza".
uhm...forse hai ragione.
Conosco una famosissima azienda italiana (soft di ing civile)che stando a quel che dice un amico che ha provato una loro copia di valutazione crakkata,fornisce risultati sbagliati.
Purtroppo sono io che non mi fido del mio amico :D (conoscendo la sua preparazione...)
Direi che va bene... L'impotante è che ci siano diversi punti nel tuo codice che controllino che il programma sia stato registrato (se ce n'è uno solo è equivalente alla finestra di popup)...
Anche un md5 dell'eseguibile sarebbe cosa buona e giusta (da controllare ogni volta che presenti un risultato, in molto subroutine)...
maxithron
01-07-2003, 16:01
Molte volte ho sbattuto la capoccia su questo problema....chiavi di registrazione?? disinstallazione automatica?? e poi approdai al punto in cui ti trovi tu adesso.
Fornire "volutamente" un errore random, è (da un punto di vista legale) un'arma a doppio taglio. Non sto qui a spiegarti le problematiche che ho avuto io in merito (magari te le spiego in pvt). Ora, sto finalmente terminando con alcuni collaboratori un sistema di protezione abbastanza sofisticato(certo prima o poi qualcuno un buco lo trova sempre). Ti prometto che finita la fase di testing, lo posterò sul forum perchè comunque sarà un progetto open source.
credo che protezioni di questo tipo esistano già: ricordo che un programma di masterizzazione mi aveva bruciato dei cd e questo era capitato quando, finito il periodo di prova, avevo usato un codice seriale (evidentemente ben noto) trovato in giro per registrarlo.
Originally posted by "cionci"
Anche un md5 dell'eseguibile sarebbe cosa buona e giusta (da controllare ogni volta che presenti un risultato, in molto subroutine)...
cosa intendi esattamente,(non ti seguo)?
Originally posted by "maxithron"
Molte volte ho sbattuto la capoccia su questo problema....chiavi di registrazione?? disinstallazione automatica?? e poi approdai al punto in cui ti trovi tu adesso.
Fornire "volutamente" un errore random, è (da un punto di vista legale) un'arma a doppio taglio. Non sto qui a spiegarti le problematiche che ho avuto io in merito (magari te le spiego in pvt). Ora, sto finalmente terminando con alcuni collaboratori un sistema di protezione abbastanza sofisticato(certo prima o poi qualcuno un buco lo trova sempre). Ti prometto che finita la fase di testing, lo posterò sul forum perchè comunque sarà un progetto open source.
mandami pure un PVT mi interessa sapere cosa ti è successo ;)
Originally posted by "verloc"
cosa intendi esattamente,(non ti seguo)?
Hai presente cos'è md5 ? E' una stinga di 16 caratteri (se non sbaglio) che viene calcolata su una sequenza di lunghezza variabile di byte...
Se A != B allora md5(A) è molto probabile che sia diverso da md5(B)... C'è una piccola probabilità del tutto trascurabile che sequenze diversi generino la stessa stringa md5 (è una specie di impronta digitale)...
Originally posted by "cionci"
Hai presente cos'è md5 ? E' una stinga di 16 caratteri (se non sbaglio) che viene calcolata su una sequenza di lunghezza variabile di byte...
Se A != B allora md5(A) è molto probabile che sia diverso da md5(B)... C'è una piccola probabilità del tutto trascurabile che sequenze diversi generino la stessa stringa md5 (è una specie di impronta digitale)...
beh dai, diciamo pure piccolissima!
per la miseria, sono 128 bit... 2 elevato alla 128 non oso immaginare che cifra deve essere cmq e' praticamente impossibile che un eseguibile, modificato anche solo per un byte, possa tenere lo stesso valore MD5.
tra l'altro si tratta di una protezione che si vede spesso ultimamente: oggi ad esempio ho scaricato Jedit e vicino al link per scaricare il file zippato c'era quello per vedere l'hash MD5 da confrontare una volta finito il download.
in questo modo sei sicuro che quello che scarichi e' proprio l'originale
Questo indicato da Cionci è un sistema di protezione è interessante e assomiglia ad una specie di calcolo del checksum del file. Se il checksum è sbagliato significa che il file non è uguale a quello originale e il programma si blocca oppure comincia a restituire risultati errati.
Ma come si può implementare? Ipotizzo una applicazione che, al momento dell'esecuzione o in particolari situazioni random, verifica sè stessa e determina se il checksum calcolato è uguale a quello previsto. Ma dove memorizzare il checksum previsto? Se lo metto in un file esterno sarà facilmente individuabile e modificabile, quindi escludo questa ipotesi. Se lo metto all'interno del file-applicazione è evidente che la zona di byte da includere nel calcolo non deve contenere il checksum stesso (altrimenti è come un cane che si morde la coda). Ma non avendo la possibilità di sapere dove il compilatore ha memorizzato fisicamente il checksum all'interno del file, il compito mi sembra arduo...
uhm mi è un po + chiaro (cacchio però roba tosta è :( )
A proposito su CodeProject c'è uno che ha postato un sistema a doppia chiave completo che stando alla lettura e a quello che lui diceva deve essere molto efficace.
se volete vi posto il link.Dovrei avere l'articolo sull'HD.
tas: hai centrato il problema... Avevo in mente una cosa bidirezionale... Ad esempio mettiamo che il programma sia fatto da un eseguibile e da una DLL che contiene le librerie di calcolo...
Ogni volta (o ogni tot volta) che chiamo una funzione di quella DLL prima verifico che la stringa md5 composta dal file della DLL a cui aggiungo il nome della funzione sia come quello che salvo nell'eseguibile (una stringa md5 per ogni funzione)...
Appena viene chiamata ogni funzione della DLL verifico che la stringa md5 del file eseguibile a cui aggiungo il nome della funzione sia quello salvato nella DLL (una stringa md5 all'interno di ogni funzione)...
Sicuramente non impenetrabile...ma se non altro ci vorrà molto per crackarlo...
Anzi si potrebbero studiare tante cosine anche più belline... Ad esempio...ottenere dinamicamente i nomi delle funzioni importate dalla DLL nell'eseguibile... E questo non è una novità...ma il nome non sarà il classico nome plain text, ma l'md5 della sequenza composta da esegubile + DLL + nome funzione...
Chiaramente non è semplice fare una cosa del genere e, come anche per il caso sopra, è bene farsi un programma che scrive codice automaticamente ;)
Quindi se un un stringa md5 non corrisponderà ad una funzione valida il programma si pianterà !!!
Visto che siamo nel tema.
Devo rilasciare con una data di spiramento.Ho letto che il controllo non devo farlo sulla data di sistema ma ricavare la date per esempio dall'ultimo accesso ai user.dat o di creazione (e verificare che non ci sia troppa differenza).
Chiaritemi le ideee su sto fatto.Per esempio evitare che lo smanettone
di turno metta indietro la data dal sistema oppure dal bios etc.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.