Newsgroup: it.comp.sicurezza.pgp
Titolo: Key Generatort

Devo distribuire una mia applicazione attraverso un rivenditore,
e vorrei tutelarmi da eventuali violazioni sul diritto di copia.
Anche se di solito questi meccanismi lasciano un po' il tempo che
trovano, vorrei implementare un meccanismo semplice ma
secondo me utile per limitare eventuali danni derivanti da
copie non autorizzate della mia applicazione.
Pensavo ad una funzione
    function KeyGenerator(const Username: string): string;
    var
        ActivationKey: string;
    begin
        ...
        Result := ActivationKey;
    end;
che prendendo in input una stringa alfanumerica "Username"
(il nome utilizzato per registrare il programma), restituisca in
output un codice di attivazione "ActivationKey" del programma stesso.
A questo punto abiliterei il funzionamento del mio programma soltanto
quando il codice di attivazione inserito dall'utente in fase di
registrazione
coincida in modo esatto con il codice (ActivationKey) restituito
dalla mia funzione KeyGenerator.
Ho letto un pochino di Crittografia, chiavi pubbliche e chiavi private, ma
non essendo un esperto cercavo dei saggi consigli, e magari qualche
aiuto concreto su come operare o dove trovare informazioni utili in
termini pratici e non prettamente teorici.
Grazie a tutti.
Riccardo
P.S.
Scusate, forse questo post è un tantino OFF TOPICS ma dovrei
implementare il tutto in Delphi, e non saprei dove chiedere aiuto.

termini pratici e non prettamente teorici.
Secondo me stai sparando un po' alto.. o melgio: io sono uno STRENUO
SOSTENITORE della crittografia ma forse qua non serve più di tanto.. ti
spiego: nel 99% dei casi quello che si fa per "craccare" un programma è
*evitare* la chiamata a quella funzione.. quindi qualunque cosa complessa e
splendida venga fatta... viene persa.
quindi più che a pensare a come fare la cosa ti conviene pensare a come
COMPLICARE LA VITA... ovvero mettendo codici assembmly non validi qua e là,
false esche... modificare variabili lontanissime che apparentemenet servono
ad altro... insomma è un bordello.
Riguardo alla funzione non ci ho mai pensato seriamente, ma il problema
principale è questo: qualunque metodo crittografico tu usi il programma deve
saperlo verificare, quindi deve avere la chiave.
Quindi chiunque sappia fare un po' di reverse engingeering sul programma
avrà la chiave.
Il che però non necessariamente gli permette di creare altre chiavi (= fare
un keygen), se usi un sistema a doppia chiave (asimmetrico o a chiave
pubblica/privata).
Non so quanto ne valga però la pena dato che sarà comunque sempre possibile
fare un crack che eviti il tutto ^_^
d'altra parte oggigiorno la crittografia non richiede neanche più eccessivi
casini per essere usata, se ti fidi (per dirne una) della libreria CryptoAPI
di Microsoft, doverbbe avere delle chiamate abbastanza semplici.
A quel punto la chiave non è altro che la crittazione (con chiave privata)
del nome di attivazione (magari in BASE64 o in esadecimale, per essere
scrivibile). Il programma può verificare che è corretto decrittandolo con la
sua chiave pubblica.
[sono stanco e mi si chiudono gli occhi, qualcuno per favore legga e
corregga eventuali 'boiate' ^______^]
-- 
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /

programmatori le usano per proteggere i prori files sorgente.
Mah, non mi pare tanto piů sicura di qualcosa di crittografico.. intendo:
una chiave hardware la "cracki" evitandone i controlli tanto quanto una
funzione di controllo...
Certo... perň usando un hardware capaci di PER SE' di crittare (che so, una
banale smartcard) sposti il problema di "cracking" a livello hardware... e
mentre per imparare a disassemblare serve solo "tempo e voglia", per
"aprire" una smartcard (con acidi o microtomometri o come diavolo sifa, nno
ne ho la piů pallida idea) servono sicuramente conoscenze maggiori.
Perň dovresti mettere una chiave diversa per ogni card, altrimenti "rotta
una, rotte tutte"... in tal caso potresti usaer direttamenet la card come
chiave.
OK, OK.
Sto divagando! ^_^
Il sonno mi chiama 0=)


 dalla mia funzione KeyGenerator.
Ovviamente devi memorizzare soltanto l'hash del codice d'attivazione.
In ogni caso, come t'hanno detto gli altri, il controllo che ne risulterebbe
nell'eseguibile è craccabile con estrema semplicità.
Cristiano

 programmatori le usano per proteggere i prori files sorgente.
Credo che questo sistema sia equivalente a quello software, tanto se togli
il controllo della chiave hardware cracchi pure questo.
Cristiano

il controllo della chiave hardware cracchi pure questo.
La possibile differenza è che quando l'hardware è "intelligente" puoi
delegare alcune funzioni direttamente all'hardware... funzionalità di cui il
software *HA* bisogno (nno per un semplice controllo, ma proprio per "fare
cose").
Si può craccare i nqualche modo scrivendo magari un vxd che simuli
l'hardware vero, ma lì l'analisi è sull'hrdware, ben più complessa.
Ne concordo comunque che "non ne vale la pena", a parte casi estremi...


 chiave. 
Ho appena acquistato un programma di contabilità di tipo professionale
dove con la licenza mi hanno consegnato la mia chiave HW personale. Ti
assicuro, è unica per la mia ditta e non è modificabile (ROM). Per le
smart card il discorso è uguale, occorre un apparecchietto HW che legga 
il contenuto della SC (COsticchia qualche milione di vecchie lire) e
una serie di software di crack non indifferenti....ihmo, sono soluzioni
secondo me sicure.
ciao :)
-- 
www.x-planet.org
  | 
www.x-privat.org
 | 
www.x-freedom.org
  |
news.x-privat.org
 | 
ftp.x-privat.org
 | 
smtp.x-privat.org
  |
Mirror ufficiale di Bynoi - X-Planet NO-PROFIT Web Community

secondo me sicure.
...resta il fatto che se cracki il software tutto questo splendido hardware
non viene neanche eseguito...


Un Dmitry che ricorda a malincuore i P-CODE di Clipper..
Ho fatto un *PELINO* di Clipper alle superiori, ma poi ho "rimosso" 0=)


 linguaggi sono facilmente craccabili..
Odddddio.... che i linguaggi piu' ad alto livello una volta compilati
siano piu' difficilmente comprensibili sono d'accordo. Ma una volta
decompilato il codice (e qualunque codice e' decompilabile facilmente!)
puoi solo nasconderlo con meccanismi di compressione/criptazione, cio'
non toglie che avendo a disposizione tempo e conoscienza, ed un minimo
di attrezzatura, _qualunque_ codice e' violabile.
-- 
HappyCactus - Linux User #209744 - LFS User #6046 - >>> SMSPM1050 <<<
              YAGF Member Group >>> 
www.google.com
 <<<
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

 Beh, non sono d'accordo
Purtroppo ha ragione.
Salvo bastardate piuttosto grosse.... tipo chiavi con decrittatore
incorporato e codice criptato all'interno dell'eseguibile stesso...
HappyCactus che ne ha viste di tutti i colori.


infilare i contatti li' dove serve....
Ecco, questo mi risultava.. nno che non sia mai stato fatto, ma non è certo
cosa "facile".


di attrezzatura, _qualunque_ codice e' violabile.
Questo è certo.
Per il solo fatto che il computer *deve* avere la possibilità di eseguirlo
allora chiunque può avere la possibilità di leggerlo in forma "eseguibile".


mi hanno detto che lavorano con un altro concetto...
...ovvero quale?


pensiamo a livello civile/amatoriale (credo almeno)
IMHO "i militari fanno cose che noi non possiamo neanche immaginare" č in
molti casi una cortina di fumo che loro stessi alimentano per "incutere
timore" =)


 BCC
Non hai piu' i sorgenti, eh? Se vuoi ricompilarli per adattarli, senza i
sorgenti, me la vedo molto dura...


 certo cosa "facile".
Sai, se fanno il reverse-engineering dei Circuiti Integrati...
Ora che ci penso, si possono utilizzare anche le radiografie....


 forma "eseguibile".
Direi che e' palese.
IMHO il miglior metodo per proteggere del codice e' rendere il crack
talmente difficile o laborioso da rendere piu' vantaggioso l'acquisto.
In questo senso, consiglierei di diffondere i check di integrita' su
tutto il codice come funzioni inline, e possibilmente polimorfe. I
numeri di serie non sono buoni metodi di protezione, molto meglio
investire sulle chiavi hardware, se il costo dell'applicativo e'
consistente.


 senza i sorgenti, me la vedo molto dura...
esatto, sono cosine di tanti anni fa che tenevo in floppy che non trovo 
più :(. Gli EXE di clipper è semplice decompilari (sono in p-code) ma 
quelli in C, azz...
-- 
Official mirror of     | 
www.bynoi.org
X-Planet Web Community | 
www.x-planet.org

 timore" =)
Sicuramente, una parte piů o meno consistente delle nostre trattenute in
busta, va ad alimentare quella cortina di fumo...
Almeno, spero che la facciano fruttare...
Ciao,
un TJL73 che sta ancora imprecando per il conguaglio di dicembre...
-- 
"L'Esercito č un ente fine a se stesso."
                                                                   -- GC

 Cosa intendi per "campo aerospaziale"? 0_o
Forse all'Alenia brucia ancora l'ultimo scherzetto di Echelon...
Ciao,
un TJL73 che, viste le keywords, questo post è pronto per Carnivore...
-- 
"Ci sono due specie di sciocchi:
quelli che non dubitano di niente
e quelli che dubitano di tutto."
                                                     -- C. J. de Ligne

Sai, se fanno il reverse-engineering dei Circuiti Integrati...
Già, a quanto mi ha detto il prof di elettronica digitale il reverse dei
"chip altrui" è pratica più che diffusa quasi obbligata... sopratutto tra i
giganti in lotta.
Il copyright copre solo il "metodo" e non il "risultato finale" ovviamente.


 un TJL73 che sta ancora imprecando per il conguaglio di dicembre...
Sorvoliamo, per favore.
HappyCactus e il coltello nella piaga


Forse all'Alenia brucia ancora l'ultimo scherzetto di Echelon...
Sě va beh che gli brucia, ma non č che *allora* oggi usano "sistemi non alla
portata dei comuni civili" gh gh gh ;-)
BTW: carina la vicenda, a suo tempo me l'ero persa...


sorgenti, me la vedo molto dura...
Giusto per comlpetezza: in Java invece è *semplicissimo*... ho provato un
paio di decompilatori e ho ottenuto, in uno dei due casi, codice così simile
al mio da essere irriconoscibile e.. nell'altro caso invece indentato in
modo diverso ^_^
Questo perché "javac", così come "jikes" e "gcj" generano del bytecode
TOTALMENTE NON OTTIMIZZATO... (cosa che peralto mi ha intristito molto...
sopratutto da parte di gcj, ma ho scoperto dopo che per ora è una specie di
'programma esterno' e non genera il codice interno che gcc sa ottimizzare).
