Parere su un metodo di protezione

verloc · 01-07-2003, 06:01

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".

verloc · 01-07-2003, 07:42

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

(conoscendo la sua preparazione...)

cionci · 01-07-2003, 11:38

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.

recoil · 01-07-2003, 18:04

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.

verloc · 02-07-2003, 05:56

Quote:

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)?

verloc · 02-07-2003, 05:58

Quote:

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

cionci · 02-07-2003, 16:04

Quote:

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)...

recoil · 02-07-2003, 16:24

Quote:

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

tas · 02-07-2003, 16:53

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...

verloc · 02-07-2003, 17:22

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.

cionci · 02-07-2003, 19:30

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à !!!

verloc · 03-07-2003, 16:04

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.

01-07-2003, 06:01	#1
verloc Senior Member Iscritto dal: Jan 2000 Messaggi: 551	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?

01-07-2003, 07:29	#2
lombardp Senior Member Iscritto dal: Jun 2002 Città: Firenze Messaggi: 630	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". __________________ ---> Lombardp CSS Certified Expert (Master Level) at Experts-Exchange Proud user of LITHIUM forum : CPU technology Webmaster of SEVEN-SEGMENTS : Elettronica per modellismo

01-07-2003, 16:01	#5
maxithron Senior Member Iscritto dal: Mar 2002 Città: Italy/Usa Messaggi: 2817	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. __________________ "Utilizzando atomi pentavalenti drogheremo il silicio di tipo n; Utilizzando atomi trivalenti drogheremo il silicio di tipo p; Utilizzando della cannabis ci drogheremo noi e vedremo il silicio fare cose impossibili" - DSDT-HowTo

02-07-2003, 16:53	#11
tas Senior Member Iscritto dal: Feb 2001 Città: Nordest Messaggi: 217	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... __________________ Chi non cerca trova.

01-07-2003, 07:42	#3
verloc Senior Member Iscritto dal: Jan 2000 Messaggi: 551	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 (conoscendo la sua preparazione...)

01-07-2003, 11:38	#4
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	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)...

01-07-2003, 18:04	#6
recoil Senior Member Iscritto dal: Jul 2002 Città: Milano Messaggi: 19149	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.

02-07-2003, 17:22	#12
verloc Senior Member Iscritto dal: Jan 2000 Messaggi: 551	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.

02-07-2003, 19:30	#13
cionci Senior Member Iscritto dal: Apr 2000 Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29 Messaggi: 53971	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à !!!

03-07-2003, 16:04	#14
verloc Senior Member Iscritto dal: Jan 2000 Messaggi: 551	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.

Strumenti
Mostra una versione stampabile Invia questa pagina per email