Newsgroup: it.comp.lang.delphi
Titolo: Tutela software. come?

Quando realizzo un software, come posso proteggerlo da copie?
Pensavo di utilizzare una numero desunta da alcuni parametri fissi del Pc su
cui va installato il software a cui bisogna associare un contro-numero
(opportunamente calcolato in funzione del codice) che fornisco io al momento
dell'installazione.
Come posso fare per costruire la primo numero?
Eventualmente c'è qualche idea alternativa per tatelare i nostri lavori?
Germano Balzan

 ha scritto


potresti memorizzare da qualche parte ( un po' nascosta ed inoltre criptando
tutti i dati oppure definendo un formato binario proprietario ) alcuni dati
salienti riguardanti l'installazione. ( magari memorizzali da più parti,
tipo registro, file "nascosti" ecc ecc... )
Tipo la data di installazione, l'ora di inizio e fine installazione,
directory  ed al limite il numero seriale del disco fisso. ( e chi più ne a
più ne metta )
Poi all'avvio del programma, questo controlla se è registrato e lo fa
tramite un algoritmo che ti inventi tu. ( ed il codice di riscontro )
Ovviamente l'utente deve poter fare la registrazione dal tuo programma.
Questo deve inviare a te i dati dell'utente ( che lui digita nella finestra
d'installazione ) e di nascosto ti invia il blocco dati che deriva
dall'installazione.
Tu con tutti questi dati ci fai un codice di riscontro che invii all'utente
per sbloccare il programma.
Durante l'avvio il programma controlla il blocco dati dell'installazione e
il codice che gli hai inviato tu all'utente. Se tramite il tuo algoritmo è
tutto ok allora il programma funziona, altrimenti nada de nada ed al limite
fai comparire la finestra di registrazione.
L'utente che copia il programma su un'altro PC, purtroppo non gli funzionerà
perchè non è presente il blocco dati dell'installazione.
Se fa l'installazione daccapo, il blocco dati sicuramente differisce in
qualche parte e quindi il codice che gli hai inviato non funziona.
Unica pecca deriva dal fatto che se lui formatta tutto e poi decide
d'installare il programma nuovamente, deve registrarsi di nuovo perchè il
blocco dati dell'installazione è sicuramente diverso da quello iniziale (
prima di formattare ).
Comunque non penso ci siano sistemi infallibili per la protezione di un
software che magari si scarica anche da internet.
Ormai ci stanno i crack di tutti o quasi i programmi che hanno una certa
utilità.
Tra l'altro la Microsoft è quella che adotta i sistemi di protezione più
stupidi. :-)))
Ok, ti saluto.
Forse qualcuno avrà idee migliori. Io su due piedi ho avuto questa :-))
Ciao.
Antonio Tarolla

 Germano Balzan
Andrea

 stupidi. :-)))
Tanto anche a mettere una protezione con le contropalle te la sgamano
sempre...
Se la protezione è stata fatta c'è sempre un modo per disfarla...
Cmq non c'è storia...
Puoi anche inventare l'algoritmo più sofisticato del mondo per generare un
codice di registrazione, ma se TU hai fatto un programmino che genera random
codici di sblocco per registrare il programma PUO SEMPRE FARLO ANCHE
L'HACKER...
Questo è un fattore poco corretto (non si dovrebbero crackare i programmi)
ma tutti lo fanno e purtroppo la realtà è questa.
Ciao
--
----------------------------------------
Carlo Camarda
chiamac...@tiscalinet.it
]@#[ Anna I Love You ]#@[

 sempre...
basta aggiornare spesso il programma, dotandolo di password di attivazione
sempre diverse (oltre al meccanismo, iniziale, di registrazione), che
verranno distribuite ai clienti registrati per telefono. Ah, dimenticavo,
crittografare e comprimere eseguibile e librerie. Ci sono compressori, come
UPX v.0.84, che non hanno modo di fare il reverse dell'exe compresso.
Ciao, Sandro

 L'HACKER...
hai pienamente ragione,
anche se il sistema che gli ho suggerito se fatto bene è più complesso
perchè il codice che viene generato non è proprio random, ma dipende dai
dati che l'utente gli invia ( a sua insaputa ) durante la registrazione.
Cioè non è un codice numerico che deriva da una "formula" matematica fissa.
Quindi l'hacker difficilmente troverà un metodo matematico che lega questi
codici, ma un'altra strada può essere quella di trovare i dati all'interno
del PC su cui funziona il programma e copiarli in un altro PC.
In questo modo, il codice di registrazione dell'utente registrato fa
funzionare qualsiasi copia del programma su altri PC.
Ma infine credo che un buon hacker non si fa tanti problemi e modificando un
attimino l'eseguibile fa si che il controllo fra i due codici dia sempre
esito positivo e quindi la protezione è totalmente bypassata :-))
Alla fine il sistema di protezione complica le cose, ma se si tratta di un
programma importante, prima o poi esce fuori qualcuno che trova il sistema
per vincere la protezione.
Mi dirai che se il programma non è conosciutissimo e diffusissimo, non
esisterà crack.
Non credo che il problema sia pienamente risolvibile.
Anche se distribuisco il programma su CD e riesco ( supponiamo ) ad
impedirne la copia, basta dare il CD originale ad un altro, con tanto di
codice di registrazione e anche l'altro avrà una copia bella e funzionante.
Oddio, forse non ci sono sistemi infallibili, ma l'unione di più sistemi di
sicurezza può costituire un'unico sistema non infallibile ma allo stesso
tempo molto sicuro.
Ti saluto...ciao !!
Antonio Tarolla

 sistema per vincere la protezione.
***-> Ma... e' anche vero che non tutti sono bravi a craccare un programma, 
soprattutto quando si usano dei protettori sofisticati (vedi upx, uno dei 
più "bastardi" che abbia mai trovato!).
Quindi se il programma e' la "gestione del magazzino" dell'azienda 
ortofrutticola sotto casa... non penso che serva scervellarsi piu' di 
tanto.
Un crack e' facilmente trovabile gia' bello e pronto per programmi 
"grossi"... ma per programmi fatti ad hoc... *chi* scrivera' il crack?
Ciao.
Davide DG.
-- 
All resistance is futile! Prepare to be CRACKED !

 Ah, dimenticavo, crittografare e comprimere eseguibile e librerie.
A che serve? devono pur sempre essere decompressi per essere eseguiti. 
Devono pur sempre usare funzioni del sistema operativo per leggere i 
dati ambientali
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 dati ambientali
e quindi?
Ciao, Sandro

 UPX v.0.84, che non hanno modo di fare il reverse dell'exe compresso.
Sul sito di UPX mi ricordo di aver letto che nelle versioni successive
avevano deciso di mettere anche l'opzione per decomprimere files compressi
con UPX, perchè non era studiato per proteggere a lungo le analisi di coloro
che volevano modificare l'exe. E poi perchè esistevano già dei programmi
fatti apposta per decomprimere i files compressi coll' UPX, quindi era
meglio togliere l'illusione di essere al sicuro e dare a tutti la
possibilità di decompremerli.
Se avevano ragione, il trucchetto di usare la versione vecchia non funzia un
gran chè.
Ciao
Matteo

 per tatelare i nostri lavori?
Le protezioni del software non sono mai sicure, specie se si 
basano su chiavi da introdurre al momento dell'installazione.
Una forma abbastanza sicura di protezione e' quella di fare 
in modo che l'installazione del programma sia fatta mediante 
internet.  
Mi spiego: tu fai scaricare al tuo cliente un programmino di 
"assaggio" della macchina, che provvedera' a scaricare il 
setup vero e proprio dal tuo server.  La piccola applicazione
leggera' i dati dell'ambiente in cui il programma dovra' 
girare e informera' il tuo server centrale perche' gli 
trasmetta un setup modificato per quella particolare macchina.
Questo equivale a inserire un chip nella pelle del programma,
che verra' letto ogni volta che il programma parte e confrontato
con i dati dell'ambiente.  L'unico modo per copiare il 
programma su un'altra macchina sara' quello di installarlo e
quindi il tuo server ne dovra' venire, comunque, a conoscenza.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 quindi il tuo server ne dovra' venire, comunque, a conoscenza.
Idea interessante. ma solo una domanda:
Se un programmino mi genera un codice di 8-9 cifre, + o - non può dare
sospetti (sono pochi caratteri)
Se un programma viene scaricato, analizza il PC e poi si mette in contatto
con un server e con una trasmissione di dati invia da solo questo codice,
non c'è il rischio che qualcuno non si fidi e mi possa fare delle storie
legali proponendo come tesi che invio ai miei server chissà quale dato
confidenziale o non so cos'altro possa esserci e che debba quindi 1) beghe
legali 2) mostrare il codice di generazione della chiave a qualcuno?
Ovviamente, se è un programmino, nessuno si sogna di fare qualcosa del
genere. ma se è un programma "grossettino" che prende piede... insomma...
Cosa ne pensi?
Ciao
Matteo

 trasmetta un setup modificato per quella particolare macchina.
Bella.
Mi piace.
Complimenti.
Bye
AS

Purtroppo non tutti i clienti hanno il collegamento a internet. Molti ad
esempio ne sono terrorizzati, perche' pensano (e a ragione) che con la posta
gli arrivino tonnellate di virus oppure perche' non vogliono che i
dipendenti ci giochino (mi sono capitati entrambi i casi).
Ciao, Sandro

 Purtroppo non tutti i clienti hanno il collegamento a internet. 
Non e' un problema.  In questo caso si possono prelevare i
dati dell'ambiente in cui la macchina gira (che, in soldoni,
possono essere rappresentati da una stringa simile a un GUID)
e si puo' prelevare il setup da un'altra macchina collegata
a internet.  Nel caso di un cliente facilmente raggiungibile,
in base ai dati estratti, gli si puo' recapitare il setup
in altro modo rispetto ad internet.


 legali 2) mostrare il codice di generazione della chiave a qualcuno?
Penso che sia difficile che tra un cliente e un fornitore nasca
un rapporto di sfiducia cosi' grande, pero', per carita', puo'
capitare.  Non vedo una probabilita' cosi' grande di finire in
tribunale e, comunque, se hai la coscienza pulita, chi ne fara'
le spese sara' il tuo cliente.  Il suo sospetto non e' verita'
finche' non dimostra cio' che afferma con delle prove e se tu non
hai fatto niente di cio' che lui sospetta, c'e' poco da fare: non
ci sono prove, la causa la perde e paga le spese.  
Non credo neanche sia probabile, in queste circostanze, che tu
debba svelare l'algoritmo di calcolo della chiave.  In realta',
il codice che tu generi viene elaborato, quindi basta far vedere
qual e' l'elaborazione che subisce per mostrare che da esso
non vengono estratte informazioni riservate del cliente.
Costringerti, tuttavia, a dimostrare la tua innocenza svelando 
l'algoritmo di calcolo della chiave significherebbe svelare 
un "segreto" della tua azienda e, credo (non sono un avvocato) 
che sia previsto un risarcimento.
In ogni caso penso tu possa citare il tuo cliente per danni 
(temo cesserebbe di essere un tuo cliente ;)


 e quindi?
E quindi chemmifrega se è compresso, criptato, quello che vuoi? piazzo 
le trappole a monte (chiamate di sistema), più in là di così non puoi 
andare


 andare
ammesso anche che tu riesca a ricostruire tutti i moduli, estrandoli dalla
memoria e salvandoli su disco non crittografati e non compressi, dovresti
eliminare, spulciando l'assembly (e parliamo di parecchi mega in genere),
tutte le trappole, controlli, blocchi, limitazioni, e ci sono tecniche di
programmazione non lineare, o con crittografazione interna delle password,
che rendono sconsigliabile, in termini di tempo, provare a fare un lavoro
del genere, tantopiu' se il programma e' aggiornato costantemente, le
tecniche di protezione modificate nel tempo, e il lavoro andrebbe ripetuto
periodicamente.
Insomma, tecnicamente tutto e' possibile, ma il punto e' che non sempre ne
vale la pena. Ricordiamoci in fondo che i "cracker" lo fanno per hobby e per
competizione con gli altri cracker, quindi si dedicano a titoli di larga
diffusione. Nell'ambito del software personalizzato o gestionale il problema
non esiste.
Ciao, Sandro

Germano Balzan
1) Usare una chiave qualunque!
2) Far partire il programma
3) Se la chiave non corrisponde:
    In diverse parti del programma:
      - Aggiungere valori casuali al risultato di calcoli
      - Richiamare dei record casuali
In un mio programma multimediale:
Non rispetto l'ordine dei record, suono e parole non sono
sincronizzate.
In questo modo il programma, casualmente, provoca degli errori sempre
diversi.
Attenzione:
Bisogna essere sicuri che il  programma funzioni quando la chiave e'
esatta
Forse bisogna far vedere in modo eclatante che il pgm non funziona.
Non usare Randomize o Random (per rendere + difficile la sprotezione)
ma crearsi routine personali (non è necessario che la casualità sia
perfetta).
Penso che questa soluzione sia molto, ma molto cattiva!
Odilo Libera
Piazza Negrelli, 3
Trento
 

 ammesso anche che tu riesca a ricostruire tutti i moduli,
[...]
Non hai capito


> Non hai capito
in effetti non ho capito cosa significa "piazzo le trappole a monte
(chiamate di sistema)".. se una mia procedura interroga il registro per una
certa chiave, che fai, mi sostituisci le api di accesso al registro di win
con delle tue api che mi restituiscono un certo valore? se puoi chiarire
meglio cosa intendi.. la cosa mi interessa :)
Ciao, Sandro

Zortek ha scritto:

esatto. Vedo cosa stai cercando, e ti do quello che cerchi. Abbi 
qualche mese/anno di pazienza, è un progetto a cui sto lavorando


non sarebbe più giusto scrivere codice open source ?
Davide

 non sarebbe più giusto scrivere codice open source ?
"Piu' giusto" da che punto di vista ?
Molti contratti che vengono fatti tra cliente e azienda
produttrice del software prevedono il rilascio, con il 
prodotto finito, anche dei sorgenti.
E comunque, scrivere codice open-source non vuol dire
evitare di tutelarsi.


 eseguito, in genere.
Ma il Cracker non va a vedere l'eseguibile, per individuare dove sta la
richiesta di password, usa un sistema molto più semplice.
Solitamente viene utilizzato SoftIce che è una specie di debugger che
permette di impostare delle interruzioni a determinati eventi (la lettura da
tastiera)
Una volta individuato la sezione di codice che ha la chiave, qualsiasi
Cracker trova il modo di jumparla.
Comunque la soluzione migliore è non scemunirsi troppo, ma fare software
così complessi che possono fare guadagnare anche dall'assistenza,
l'assistenza il Cracker non la darà mai.

 prodotto finito, anche dei sorgenti.
mi chiedo fino a che punto servano i sorgenti. Supponiamo che l'azienda in
questione voglia modificare, di propria iniziativa, il sorgente. Oltre a
mettere mano in, supponiamo, su 50.000 linee di codice che posso anche
essere scritte con i piedi, dovrebbe dotarsi di tutta la dotazione software
in possesso dello sviluppatore, nonche' del know how necessario. Gia' la
dotazione software costerebbe una barcata di soldi (D6 enterprise, 3500
euro, un buon sistema di reporting, Report Builder, 1000 euro, vogliamo
metterci pure un sistema di charting professionale? Teechart Pro, 250 Euro,
e via di questo passo).
Un po' come se la Opel (tanto per dirne una) ti desse in mano, al momento di
acquistare una macchina, tutti gli schemi e piani di cablaggio, impianto
elettrico, manuali di officina, ecc. - qual e' l'utilita' quando, oltre alla
competenza di un meccanico professionista che non potrai mai avere, scopri
che per svitare una vite ti occorre un attrezzo che viene venduto in kit con
altri 10 al prezzo totale di 2000 euro (si perche' le case automobilistiche
fanno anche questo)?
Ciao, Sandro