Newsgroup: it.comp.lang.delphi
Titolo: Pirateria

Avete mai trovato per la rete crack dei vostri software? Se si, cosa avete
fatto? Io un anno fa abbondante trovai uno dei miei software di punta,
AltaStagione, impacchettato con file txt (con nome del pirata) e keygen. Da
allora cambiai completamente la strategia di protezione e distribuzione dei
software.
Ciao, Sandro

 ha scritto nel messaggio
news:bjnp7g$l2mud$1...@ID-43509.news.uni-berlin.de...

Non mi sono mai trovato nella situazione, sono un programmatore self-made e
faccio programmi ad uso praticamente personale, quindi non cadrò mai nella
trappola dei crack :)
Ciao, RedXIII

ma secondo voi come fanno a craccarli??? il codice delphi una volta
compilato non è difficile da interpretare??

 compilato non è difficile da interpretare??
Hai mai sentito parlare di decompilatori e reverse engineering?
--
Acqua
-------------------------------------------------------
Download new version of my PixExperts for Delphi 6/C++ Builder 6 at
http://www.salexander.supereva.it/Pix_Exp171D6.zip


Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)


Non mi sono mai trovato nella tua situazione ma credo ci sia poco da fare.
Qualsiasi tipo di protezione, sia software che con chiavi hardware è più 
o meno facilmente aggirabile.
L'unica cosa che mi viene in mente è provare a nascondere dei controlli 
"random" sia di CRC dell'eseguibile (ed eventuali librerie) che 
controlli sulla validità della licenza d'uso.
Tali controlli dovrebbero essere eseguiti a random e non dovrebbero mai 
essere gestiti da una procedura unica ma dovrebbero invece esserci 
diverse procedure che verificano la validità della licenza in modi 
diversi (ossia, nessuna procedura deve fare il "lavoro" di verifica 
nello stesso modo) richiamate per esempio da uno o più timer e scatenate 
da diversi eventi (per esempio quando l'utente preme una combinazione 
frequente di tasti o accede a certi menu... in questo caso è bene che il 
messaggio "copia pirata" [o quello che ti pare] sia ritardato per un 
tempo anch'esso random in modo da non far collegare all'utente e 
potenziale cracker l'evento con la verifica).
Esistono dei trucchetti che mandano in crash i debugger ma, essendo 
questo un argomento che ho affrontato un sacco di tempo fa, non ricordo 
più nulla al riguardo e comunque, anche in quel caso, erano facilmente 
(relativamente) aggirabili.
Le chiavi hardware sono da evitare in quanto: 1) costose e 2) inutili. 
Esistono chiavi hardware in cui è possibile scrivere "un pezzo di 
eseguibile" e quindi, senza la chiave hardware, il programma non può 
funzionare correttamente (perché gli manca un pezzo), ma dubito che un 
cracker convinto si lasci aggirare da questo problema, è sempre infatti 
possibile estrarre il pezzo di eseguibile dalla chiave e con qualche 
barbatrucco riattaccarlo al suo posto.
Esistono pacchetti anti-cracker disponibili sul mercato... ma questo è 
spesso ancora peggio che una soluzione casalinga visto che è possible 
realizzare crack generici che riconoscono il pacchetto usato e lo aggirano.
Se distribuisci versioni DEMO non metterci tutte le funzionalità... 
proprio evita di compilarle nell'eseguibile attraverso per esempio le 
condizioni del compilatore.
Solitamente il codice seriale è una protezione insufficente, una 
protezione più seria è la generazione di file crittati (non con il 
metodo della nonna ma con veri e propri algoritmi sicuri di crittazione) 
magari mixata con controlli sull'hardware della macchina autorizzata (il 
file crittato potrebbe per esempio contenere il codice seriale dell'HD e 
varie altre informazioni), tali dati dovranno essere poi verificati a 
"pezzi"... ossia, controllare solo una piccola parte di tale file alla 
volta, in modo da confondere il potenziale craker sulla funzione del 
file e delle sue varie sezioni. Per esempio... dopo 15 secondi di 
attività del software si potrebbe controllare le prime 3 cifre del 
codice seriale dell'HD (contenuto nel file crittato), dopo i primi 7 
minuti una parte del codice seriale immesso dall'utente e presente nel 
file in forma crittata, dopo 34 secondi che l'utente ha selezionato la 
voce "help" del menu verificare se la somma della sezione interna del 
numero seriale dell'HD corrisponde alla somma della medesima sezione 
interna del numero seriale contenuto nel file di licenza, dopo 7 giorni 
di attività del software verificare se il CRC del file crittato sommato 
al CRC dell'eseguibile corrisponde a quello che dovrebbe essere e così via.
Come vedi si tratta di un lavoro piuttosto ridondante e certamente 
noioso... ma l'unico modo per tentare di fermare un tentativo di crack è 
quello di inserire così tanti controlli (gestiti da procedure diverse, 
altrimenti basta craccare la singola procedura che fa la verifica e 
buona notte) e così complessi da stancare il craker stesso... spesso 
però questo stanca pure il programmatore ;)
Ciao,
   Luca

 Ciao, Sandro
Ciao, sicuramente fa rabbia, però nello stesso tempo ti da anche un po' di
soddisfazione perchè vuol dire che hai fatto un programma che valeva la
pena di craccare... ;-)
---------------------------------------------------------------------------
Messaggio inviato attraverso 
http://www.trucchiperpc.it
 - sezione newsgroup

Le protezioni in genere vengono crakkate perchè si usano algoritmi
standard di criptazione (tipo MD5 e altri) e pertanto
un hacker in gamba riesce con un buon decompilatore a modificarlo.
Diciamo che proteggere un programma al 100% è difficile se non
impossibile, però si può rendere
la vita difficile ad esempio iniziando a comprimere eseguibili e dll con
software tipo UPX...
Gianluca
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 software tipo UPX...
Il compressore UPX crea due sezioni,UPX0 e UPX1, facilmente
riconoscibili nell'hearder dell'eseguibile.
Con un tool di decompressione il gioco è fatto!
Acqua


 Con un tool di decompressione il gioco è fatto!
Basta anche il solo UPX. :-)


> Basta anche il solo UPX. :-)
E già...! :)
C'è anche da tenere presente una cosa! Ora che ricordo, UPX viene
distribuito in formato sorgente. Lo sviluppatore potrebbe quindi partire
da un prodotto del genere ed aggiungere, alla routine di compressione,
una successiva codifica dei dati, in modo da ottenere qualcosa di
insolito, che difficilmente un decompressore standard sarà in grado di
valutare.
Non è detto però che tale modifica sia a prova di decompressore
generico!


 pena di craccare... ;-)
e' vero :) tuttavia c'e' anche da dire che in giro si trova tanta robaccia
craccata (un nome per tutti, sempre per rimanere nell'ambito dei gestionali:
la serie completa dei software Finson) che viene da chiedersi se questi
cracker facciano un lavoro del genere per sfida personale o per rendere un
servizio ad un'ipotetica comunita'.
Resta il fatto che nell'ambito dei gestionali, oltre al rischio che l'utente
si prende in caso di controlli per mancato possesso della licenza (che nel
mio caso e' nominativa, non certo generica come quelle Microsoft), senza
assistenza e aggiornamenti non si va molto lontano: i software funzionano
mai perfettamente a tempo indefinito, in genere, c'e' sempre il virus, lo
sbalzo di tensione, il figlio pasticcione, l'amico smanettone, il
copia/incolla sbagliato, ecc.
Ciao, Sandro

Non mi sono mai trovato nella tua situazione ma credo ci sia poco da fare.
[MEGA-CUT]
Interessante il tuo post, rimane il fatto che non potrai mai evitare il crack
di un tuo programma.
Alla fine credo in una strategia di contenimento e arginamento, piuttosto che
di lotta diretta al cracking. E cioe', con servizi legati alla registrazione,
stampe con ragioni sociali del registrante, assistenza disponibile e
tempestiva.
Parlo ovviamente della maggior parte dei software di tipo gestionale.
-- 
Morde. 
(morde at programmer dot net)

 generico!
E' sufficente modificare l'algoritmo di compressione e decompressione
anche inserendo solo un semplice xor prima e dopo e il decompressore
standard non sara' in grado di decomprimerlo. COmunque un bravo
programmatore con softice riuscirebbe facilmente a decomprimerlo.
Dovrestiutilizzare tecniche com riscrittura di memoria nop etc in
assembler solo che il rischio e' che venga rilevato come virus.
Saluti.
-- 
I'am what I'am, I do what I can

 fatto? Io un anno fa abbondante trovai uno dei miei software di punta,
Mah, in genere distribuisco personalmente il crack od il keygen per gli
applicativi che faccio :)
Per invogliare il pubblico all'acquisto :)
A parte gli scherzi non mi č ancora capitato (anche perchč non c'č molta
roba mia in giro).

 assembler solo che il rischio e' che venga rilevato come virus.
Oppure, una bella chiave Hw che incorpori pezzi mancanti di codice
e che, a richiesta, vengono scaricati ed eseguiti.

 Parlo ovviamente della maggior parte dei software di tipo gestionale.
Vero. Credo infatti che l'utente, quando compra un software per la sua 
ditta, ci tenga molto all'assistenza. Dopotutto non sono software così 
intuitivi e le probabilità di fare casini sono piuttosto elevate... e 
fare casini con i dati della ditta non è una cosa bella e auspicabile.
Il fatto poi che il software venga piratato non credo sia un completo 
male (non tutto il male viene per nuocere) poiché rende conosciuto il 
prodotto ed è piuttosto improbabile che uno, nella sua ditta, usi 
software piratato (se lo fa non ha il cervello). È molto più probabile 
che la copia pirata sia usata a casa, per provare il prodotto o per 
tenere copia dei dati (e lavorarci su); in entrambi i casi non danneggia 
lo sviluppatore (nel primo caso fa anzi pubblicità, nel secondo caso 
bene o male il software è già stato pagato per la ditta).
Conosco tante persone che prima provano il software piratato, e poi, se 
gli piace, se lo comprano... i medesimi odiano versioni demo o limitate 
nel tempo semplicemente perché non sono il "prodotto vero e proprio".
Ciao,
   Luca

 nel tempo semplicemente perché non sono il "prodotto vero e proprio".
valutare un gestionale non e' cosi' semplice come valutare un software
generico (vedi che so, Word, Acrobat o Nero). Dovresti caricare tutti i TUOI
dati negli archivi (clienti, fornitori, piano dei conti, fatture), far
girare il tutto per.. quanto? un mese, diciamo. Ok. E a quel punto vedere
se:
1) funziona o si blocca o da problemi in generale
2) non e' troppo farragginoso
3) e' sufficientemente sicuro (protezione dei dati a vari livelli, backup
automatici o meno, ecc.)
Supponiamo che la risposta, alla fine dei conti sia: "no, non mi va bene":
hai buttato un mese di tempo, una segretaria che si e' dedicata piu' o meno
a quello sottraendo tempo ad altre attivita', e quindi un mucchio di soldi.
In definitiva, la strategia di "voglio vedere il prodotto completo per
valutare se va bene o meno alla mia azienda", con i software gestionali a
mio parere non e' applicabile. Meglio una demo magari valutata insieme ad un
consulente, fosse pure un collega di lavoro, con cui scambiare pareri.
Ciao, Sandro

 consulente, fosse pure un collega di lavoro, con cui scambiare pareri.
Vero anche questo. Una ragione in più per evitare di buttare tempo e 
denaro in ricerche "anticrack" impossibili (anche se certamente lasciare 
il software senza alcuna protezione non è saggio). Credo che la cosa più 
semplice da fare sia implementare un sistema anticrack semplice semplice 
senza tante pretese che scoraggi eventuali "cracker della domenica" ma 
su cui non si sia investito troppo tempo... tanto se proprio vogliono 
craccarlo lo fanno... e in ogni caso non possono usarlo nella loro ditta 
(per ovvie ragioni) né hanno alcun genere di assistenza/help.
Ciao,
   Luca

craccarlo lo fanno...
Sono assolutamente allineato al tuo pensiero.


 Sono assolutamente allineato al tuo pensiero.
E comunque, appena ci sara' Palladium, potrai certificare tutto il tuo
software, e sara' impossibile craccarlo... :-) :-)

 software, e sara' impossibile craccarlo... :-) :-)
Una volta che avrai pagato una somma più che considerevole all'autorità 
per le certificazioni del software per far includere il tuo software 
nella lista dei buoni. :/
Ma una domanda mi sorge spontanea... come si sviluppa software su un 
sistema che non ti permette di eseguirlo?
Ciao,
   Luca

 sistema che non ti permette di eseguirlo?
Mi sono gia' posto il problema... Suppongo che il software possa girare
all'interno dell'ambiente di sviluppo con qualche strano meccanismo di
controllo.
I miei dubbi sull'implementazione sono altri:
- come si fa a certificare un software? L'azienda che emette il certificato
deve vedere i miei sorgenti o no?
- se deve vederli: e se per caso io producessi un programma in concorrenza
con quello dell'azienda stessa, questo non sarebbe un vantaggio sleale?
- se non deve vederli: su cosa si basa per la certificazione?

Per i gestionali io faccio una cosa facile facile
Dato che le copie si contano con due o tre mani ad ogni cliente do un
pezzetto del programma personalzzato con i propri dati in modo che le stampe
abbino qualcosa che li identifichi
È difficile spiegare alla Finanza che le tue fatture hanno l'intestazione di
un altro
--
_________________________________________
Edmondo Di Tucci snar...@Ttin.it
guarda i miei lavori su: 
www.powernetsi.it/edmondo

 un altro
È tuttavia piuttosto facile modificare questi dati con un semplice 
hexeditor... a meno che tu non abbia "offuscato" tali dati naturalmente, 
in questo caso basterà un debugger e un po' di conoscenza di assembly.
Ciao,
   Luca

 in questo caso basterą un debugger e un po' di conoscenza di assembly.
e un piratino qualunque ti farebbe il crack con tanto di editor di
intestazione ;D
Ciao, Sandro

 
Una protezione del genere si puo' (abbastanza facilmente) bypassare.
-- 
Roal Zanazzi

 - se non deve vederli: su cosa si basa per la certificazione?
bella domanda. :)
Ciao, Sandro

 intestazione ;D
Infatti ...


Si ma dato che ne distribuisco pochi è molto difficile che possa accadere
Quanti smanettoni capaci ci sono in giro?


 Quanti smanettoni capaci ci sono in giro?
tanti, ma craccano solo cio' che, agli occhi degli altri smanettoni, da'
loro prestigio, e quindi principalmente i software blasonati. Craccare un
gestionalino personalizzato non servirebbe al loro scopo. Vuoi mettere
invece dire "ho fatto il keygen per Nero" oppure "ho scoperto il modo per
decrittare le password in XP".
Ciao, Sandro

si, infatti
Non dimentichiamoci che un gestionale non e' un software tipo Nero, o un
gioco: il cliente che compra un gestionale ha sempre bisogno di assistenza,
ecco perche' craccare un gestionale puo' non aver senso nel maggior numero di
casi.
Dove lavoro io, ad esempio, venduto il gestionale il cliente stipula un
contratto di assistenza annuale per assistenza telefonica ed eventuali
interventi presso di lui. Non avete idea (o forse si ;) con quanta frequenza
si sbagli a emettere un documento o si corrompano gli indici della base dati.
Il cracking di un gestionale e' sempre possibile e facile, ma io sostengo che
non bisogna agire in senso di contrasto, quanto di contenimento (vedi altro
filone di questo stesso thread.
A proposito, giusto per curiosita': dei due gestionali di cui siamo
rivenditori, entrambi vogliono un codice di registrazione e uno ha anche la
chiave hardware.


 chiave hardware.
la soluzione hardware l'ho considerata in passato, ma i prezzi sono sempre
stati considerevoli, sarebbe stato necessario fare un certo "magazzino" di
questi dispositivi (con relativi costi) per averli disponibili quando
necessario, e infine non erano in grado di gestire l'autenticazione del
software via rete (a parte un modello, costosissimo, della Eutron, che si
installava sul server ed era in grado di autenticare anche tutti i client
collegati). Soluzione scartata.
Ciao, Sandro

> È difficile spiegare alla Finanza che le tue fatture hanno

C'e' sempre un altro fattore: se il software e' interamente personalizzato,
trovandone una copia craccata, si puo' risalire al possessore
dell'originale, semplicemente controllando l'eseguibile.
(Che poi l'abbia copiato di proposito, che un dipendente ne abbia avuto una
copia "in prestito", o qualcuno abbia rubato l'originale, poco importa,
AFAIK. La responsabilita' e' di chi ha sottoscritto un contratto
accettandone la licenza.)

incoraggiante per il furbastro ;)
Infatti. Basta una normativa (ricordi il passaggio dell'IVA al 20%?) e quelli
si attaccano... Il vantaggio dei gestionali e' che sono legati alle normative
fiscali, e quindi gli aggiornamenti sono obbligatori.
Impensabile acquistare un gestionale senza un contratto di assistenza, sarebbe
un suicidio.


Mah, questo è il mio modesto parere. Ripeto parere, non accanitenvi =)
Secondo me non tutti i cracker e gli hacker sono cattivi, anzi fanno del
bene, ma molta gente non lo vede. Mi spiego, tutti quegli exploit per
windows e linux che sono stati messi in circolazione, sono tutti opensource,
quindi dal codice sorgente si riesce a vedere il problema... Cmq secondo me
non sono stati messi in circolazione per cattivi fini, anzi sono satti resi
pubblici, affinchè gli amministratori di sistemi o i normali (diciamo + o -
esperti) utenti del pc, rattopino il loro software o sistema operativo...
Questo comporta di sicuro ad una maggior efficienza nella generazione
successiva del programma... Quindi penso che anche i cracker che
crakkano(pardon per la ripetizione di parole) i nostri programmi, cercano a
loro modo di migliorare la sicurezza del software prodotto.
Questo è quello che penso (NB:- Io sto parlando della parte buona degli
hacker e cracker, non di quelli idioti (Lamer...), quelli sono veramente...
...lasciam perdere)...
Ripeto questo è un mio parere.

 loro modo di migliorare la sicurezza del software prodotto.
sarei d'accordo con te se il loro lavoro si limitasse a far sapere a NOI
PRODUTTORI che hanno creato un keygen per i nostri software. Quando invece
il keygen lo rendono di pubblico dominio dando modo alla gente di usufruire
dei nostri software senza pagare, allora quell' "onorevole lavoro" diventa
un reato, un po' come se tu fregassi al tuo vicino le sue chiavi della
macchina, ne facessi qualche migliaio di copie e le dessi in giro a tutti in
citta'.
Ciao, Sandro

 cercano a loro modo di migliorare la sicurezza del software prodotto.
Su questo non sono per nulla d'accordo. Una cosa e' la sicurezza del sistema
(per il bene di chi lo usa), un'altra e' la protezione del software (per
tutelare il diritto di chi lo produce).

In effetti non avevo analizzato questo aspetto... Sotto un certo punto di
vista hai ragione, forse nella realtà vera e prorpio è difficile fare un
esempio, in qunaotè un po' complesso. Cmq, pensa un po' al Blaster che un
mese fa faceva stragi, ha contaminato migliaia di pc, io non sono stato
contaminato, ma il pc mi si resettava in quanto l'exploit funzionava anche
da remoto... Ecco, non mi faceva per niente piacere, però mi ha incitato a
tener il sistema operativo aggiornato con le varie patch. Se questo non
veniva fatto, pensa quanti pc ci sarebbero in giro su cui sarebbe
facilissimo far girare un exploit, con conseguenze ancora più gravi...
Ho detto tutto questo perchè consegnare l'exploit solo a M1cros0ft, non
gioverebbe di sicuro agli utenti, in quanto non sanno a cosa sono in realtà
esposti, conoscere invece questi problemi, porta a dare una svegliata agli
utenti, cercando di proteggere meglio le loro cose...

 PRODUTTORI che hanno creato un keygen per i nostri software. Quando invece
Quanti FIX di grossi buchi pensi che la M$ avrebbe prodotto se qualcuno 
gli spedisse un exploit in forma privata via email?
Diciamo 1? Forse 2?
Quando invece il problema è noto a tutti allora la M$ _deve_ produrre la 
patch per non fare brutta figura in caso qualcuno sviluppi un software 
che usa tale exploit ed evitare quindi frasi tipo "te l'avevo detto".
Certo, pubblicare un exploit ha sicuramente il side-effect di permettere 
a chiunque di usarlo... ma questo serve ad accelerare i tempi di 
sviluppo delle patch e anzi, è spesso necessario affinché la patch venga 
effettivamente sviluppata. In Linux tutti i problemi vengono 
immediatamente resi pubblici e nel giro di un paio di giorni la patch è 
bella e pronta (a volte è pronta lo stesso giorno della pubblicazione 
del problema).
Ciao,
   Luca
-- 
Linux registered user #291568 (
http://counter.li.org/
)
Electronic Frontier Foundation Member (
http://www.eff.org/
)
Mandrake Club Member (
http://www.mandrakeclub.com/
)

Wow, forse qualcuno in parte condivide la mia idea !


 Diciamo 1? Forse 2?
quindi, per lo stesso ragionamento, se tu becchi e fotografi il vicino di
casa a letto con l'amante, fai un volantinaggio della foto per tutta la
citta'. Tutto, chiaramente, con il nobile scopo di insegnargli a proteggere
meglio la sua privacy :)
Ciao, Sandro

 meglio la sua privacy :)
No poiché quelle foto non hanno pubblico interesse.
Avere la patch per un potenziale problema che potrebbe portare un pinco 
pallino qualunque dentro casa mia (per rompere, rovinare e bruciare la 
mia roba) invece credo sia fondamentale.
