Newsgroup: it.comp.lang.visual-basic
Titolo: Aiuto : come rendere illimitato un prog. in vb

Ciao a tutti
sto utilizzando un programma in vb scaricato da internet in
per completare la mia tesi di laurea, ma il programma ha una durata di 2
giorni, ho chiesto alla casa produttrice se fosse possibile avere una
versione dimostrativa per trenta giorni, mi hanno detto che potevo averla se
avessi pagato solo 500 Euro!!!!!!!!!!!!!!!  pochi č?
Volevo sapere se 1° č possibile risalire al sorgente dall'eseguibile per
modificare i parametri della limitazione dei giorni 2° se esistono dei
programmi che rendono l'eseguibile automaticamente illimitato 3° se secondo
voi il programma prende come data corente quella di Windows in questo caso
pasterebbe ogni giorni portare in dietro l'orologio ?
Grazie per l'aiuto

 pasterebbe ogni giorni portare in dietro l'orologio ?
Scusa, da che ci sei, perchè non gli fatturi il tempo che stai perdendo?
Ma chi siamo noi? babbonatale?

3° se secondo voi il programma prende come data corente quella di
Windows in questo caso pasterebbe ogni giorni portare in dietro
l'orologio ?
Aggiungerei:
4° Sto chiedendo cose illegali?
5° quante possibilità ho di prendermi una denuncia?

 avessi pagato solo 500 Euro!!!!!!!!!!!!!!!  pochi č?
brutta storia dover pagare il lavoro degli altri eh?
Davide

 Grazie per l'aiuto
visto che ti serve per la tesi , credo che quei 500Euro sono un buon
investimento se il programma e' fondamentale per la buona riuscita , conta
che _DI SOLITO_ acquistando un programma si ricevono anche assistenza.

PF wrote:

Scusa, ma credi ke se tu provassi solo, nn perderesti meno tempo?? E poi
si impara d + provando anzi ke kiedendo a delle persone ke nn ti vogliono
assolutamente aiutare per paura o per etika!!
cmq esistono crack in rete e S/N - poi se riesci a fare il reverse
engineering meglio - addirittura se i programmatori hanno avuto la felice
idea di utilizzare l'orologio di sistema, beh, meglio x te, meno fatica e
meno tempo.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Grazie per l'aiuto
Scusa, ma credi ke se tu provassi da solo, nn perderesti meno tempo?? E


ba...@jumpy.it
 (Al3xl98O) wrote in message news:<aqtg7n$5c5
Ma chi sei?
Non certo il vero Al3xI98O poichè al messaggio avevo già scritto e
poichè non uso quel sito per inviare i messaggi ai NG!

 meno tempo.
Su questo punto mi intrometto nel thread.
Tempo fa, avevo chiesto un'idea su come difendersi dalle manipolazioni
dell'orologio di sistema.
In sostanza, devo far scadere un DB dopo tot giorni dal download.
Dopo tutte le considerazioni fatte, con altri del NG, il risultato è stato
che occorre qualche indicazione del tempo trascorso, indipendente
dall'orologio di sistema.
Una idea, valida ma solo parziale come soluzione, è quella di cronometrare
l'attitivtà dell'applicativo, in modo che troppi 'arretramenti'
dell'orologio diventino incompatibili col tempo realmente trascorso.
Ma siccome l'applicativo potrebbe essere attivo per pochi minuti al giorno,
la cosa potrebbe comunque consentire di prolungare parecchio la validità del
DB.
L'ideale, e qui chiedo aiuto a te, visto che dal tuo post sembra di capire
che tu conosca altri metodi, sarebbe avere un contatempo del tempo di
attività di Windows.
Se io eseguo il download oggi alle 15.30, e il S.O. ha, ad esempio, 300 ore
di attività (informazioni che io vado a criptare nel DB), e al prossimo
riavvio vedo che l'orologio indica le 17 di oggi, ma il S.O. ha 350 ore di
attività, è evidente che l'orologio è stato manipolato.
Spetta a me, a questo punto, decidere se avvisare o bloccare il DB.
In alternativa, potrebbe essere utile andare a leggere qualcosa da un log
(tipo il registro eventi di NT), e, trovando anche solo un elemento con
data+ora più avanzata di quella di sistema, si potrebbe dedurre una
manipolazione dell'orologio.
Hai qualche idea?
Ciao
Alberto

> Hai qualche idea?
Memorizzi una chiave di registro nel registro di sistema.
La aggiorni ogni volta che avvii il programma.
Decidi di far smettere il programma non so, dopo 30 utilizzi.
Questa secondo me č la soluzione piů sicura.
Tieni presente che č impossibile trovare una soluzione sicura al 100%.
Qualsiasi programma si craccka.... Si riesce a farlo con windows XP
sviluppato da centinaia di programmatori e su cui sono investiti milioni di
dollari e pretendiamo che il nostro programma sia al 100% sicuro a prova di
bifolco che si mette a manipolare l'orologio di sistema o che
disinstalla-reinsalla il programma e altri strataggemmi vari?

 Questa secondo me è la soluzione più sicura.
Beh, non voglio riaprire un thread già passato, per cui mi limito a dire che
questa soluzione non è praticabile, nel mio caso, in quanto ci sono utenti
che avviano, consultano, e chiudono, 30 volte al giorno, e ci sono utenti
che avviano al mattino e chiudono (non sempre) alla sera, per cui il numero
di utilizzi è una variabile troppo aleatoria.
Inoltre, tutti gli abbonamenti che abbiamo in giro si basano sul concetto di
tempo, per cui anche questo nuovo servizio vorremmo tenerlo basato su questo
principio.
Ciao e grazie.
Alberto

 Hai qualche idea?
Non basarti su un solo elemento. Puoi controllare l'orologio di
sistema, la data di installazione, il numero di utilizzi eccetera.
Ognuno di questi elementi puoi scriverlo nel registro, _e_ in
un file INI, _e_ in due byte a caso di una Bitmap _e_ in un file
dati, _e_ nella data di un file eccetera. Il tutto magari in codice,
o parte del dato in un punto e parte in un altro...
A run-time, in _punti diversi_ del programma[1], controlli elementi
diversi, e soprattutto, ogni tanto e magari a caso, verifichi la
coerenza fra i fari controlli. Questo tipo di controlli incrociati è
la parte più efficace.
Se qualcosa non quadra, fermi il programma, MA NON SUBITO.
Primo perché daresti un indizio su cosa il cracker ha sbagliato,
secondo perché così intanto hai il tempo di segare tutti i file dati,
o di riempirli di spazzatura, o attivare delle procedure bacate
(metodo VBI), o... vedi tu. In ogni caso, MAI danneggiare il resto
del sistema, in modo che nessuno possa poi pensare di rivalersi
su di te, chiaro ? ;-)
Ricorda che con soli metodi SW è impossibile fare qualcosa
a prova di crack, di solito ci si accontenta di rendere la vita
il più difficile possibile ai rompiscatole. Il cracker potrebbe
accorgersi subito del fatto che controlli l'orologio di sistema,
o che scrivi in un file INI "Ultima attivazione il...", e provare
a modificare questi dati, ma è difficile che pensi a fare
_contemporaneamente_ tutti i controlli.
A meno che il tuo prog non costi $$$ e quindi ne valga davvero
la pena, è già più difficile che stia a monitorizzare l'accesso a
tutti i file del sistema, al registro eccetera.
[1] In modo da non avere una unica routine che può essere
facilmente disattivata o bypassata con un MASM qualunque.
Bye, G.

 su di te, chiaro ? ;-)
ah, ecco. quindi i due byte nella fat li cancelliamo subito dopo
averli scritti :P
nb: _quelli li'_, cancelliamo. non "due byte nella fat"...

 nb: _quelli li'_, cancelliamo. non "due byte nella fat"...
Se proprio vuoi essere pignolo, direi che converrebbe riscriverci
sopra i due byte originali. :-)
Un Paperino e l'housekeeping.

 Un Paperino e l'housekeeping.
A pagamento, s'intende :-P
--
ciao, hal
--------------------------------
Inviato via 
http://usenet.libero.it

 A pagamento, s'intende :-P
che bast... ligur... :P

 A pagamento, s'intende :-P
Cioč, se l'utente paga il programma gli riscriviamo i byte giusti,
altrimenti... ;-)
Bye, G.

 Non c'e' piu' religione :-P
La presente allo scopo di confermarLe il nostro pieno e totale supporto.
Qualora optasse per azioni legali a tutela della Sua buona nomea e contro
queste volgari insinuazioni prive di fondamento, possiamo consigliarLe
rivolgerSi ad un avvocato nostro buon amico.
ugo.tangent(aro)

 ugo.tangent(aro)
Secondo me e' una trappola delle iene :-P


 Secondo me e' una trappola delle iene :-P
ROTFL
ciao
ugo

 principio.
la soluzione di sotterratovivo e valida comunque..
nel registry.. in 2 o 3 chaivi dai nomi insospettabili , cioè non legati a
te, alla azienda, al software
scrivi criptate la data d'uso quando lanci il programma...
così sai benissimo se al prossimo avvio hanno manipolato l'orologio, a
questo punto setti un'altra chiave che se attiva non fa avviare + il tuo
software....
ciao
Davide

 cosě sai benissimo se al prossimo avvio hanno manipolato l'orologio
E' questo 'benissimo' quello su cui stavamo discutendo.
Se io avvio il sw oggi alle 12.30, lo uso per cinque minuti, poi lo chiudo,
diciamo che nel registry, al massimo, avrň scritto 12.35
Domani il sw deve scadere.
Fra un mese l'utente sposta l'orologio alle 12.40 di oggi, avvia il sw, e
tutto va bene, anzichč bloccarsi.
Ed era su questo che ci stavamo chiedendo come fare...
Ciao
Alberto

 Ed era su questo che ci stavamo chiedendo come fare...
Ripeto che secondo me una soluzione sicura al 100% non esiste.
Puoi provare a (non mi ricordo chi l'ha detto... ) a rendere la vita
difficile utilizzando vari metodi
Quello del registro
Memorizzare data ed ora di un file
Oppure dare un tempo di utilizzo ossia:
Dire: questo programma smetterà di funzionare quando si raggiungono le 30
ore di utilizzo.
In questo modo ogni volta che avvi il programma, conti quanto tempo resta in
esecuzione.
Ti metti sul form una tex box invisibile che ti conta l'orario e sull'evento
onchange controlli che l'orario precedente non sia minore di quello
successivo (ossia che durante l'esecuzione del programma non hanno
modificato l'orologio, in questo caso blocchi il programma). All'evento
unload dell'applicazione fai il conto di quanto tempo il programma è stato
in esecuzione e lo memorizzi da 5-6 parti diverse (chiavi di registro, file,
campo nel db etc).
Ad ogni riavvio fai la stessa storia fino a quando il tempo di esecuzione
raggiungerà un tempo da te impostato e a quel punto blocchi tutto...
Spero di essermi spiegato bene :-D

 Oppure dare un tempo di utilizzo ossia:
Credo che questo thread stia prendendo una piega poco costruttiva.
Tutti i post suggeriscono esattamente le stesse cose già postate.
Tutti d'accordo che possano funzionare queste belle idee sul numero di
attivazioni, il tempo di utilizzo, ecc...
Ma, ripeto, a me servirebbe qualcosa d'altro (ed ho spiegato abbondantemente
perchè).
Se nessuno ha altre idee, ripiegherò su una di queste soluzioni.
Ma è inutile ripostarle. Dette una volta, e chiarito che sono idee valide,
alla domanda "Altre idee?" mi piacerebbe sentire idee diverse.
Soprattutto perchè credo che il dilemma sia comune ed interessi a molti: se
esistesse un modo per capire se l'orologio è stato manipolato rispetto
all'ultimo avvio, le applicazioni sarebbero moltissime.
Altrimenti, seguiremo le vie classiche del registry, del tempo di utilizzo,
della data di ultimo utilizzo, ecc...
Alberto

 attivazioni, il tempo di utilizzo, ecc...
Se ho ben capito, a te serve un "doppio" controllo:
1) Max tempo di utilizzo (escludendo il numero degli avvii)
2) Data di scadenza (senza che vi sia qualcosa che "costringa" a una data
reale, come un bollato contabile)
L'uno indipendentemente dall'altro e/o "cumulabili".
Il primo non credo che non sia risolvibile (indipendentemente dall'orologio
di sistema) se non _sommando_ il tempo di effettivo utilizzo: Start, End,
sommo End-Start al totale precedente e controllo.
Il secondo dipende intimamente dall'orologio di sistema che può essere
"falsato", retrodatando in continuazione. Non si possono ritenere
sufficienti i controlli sul valore massimo perchè si potrebbe retrodatare
andando "sempre più nel passato".
Non ho sinceramente idee, ma mi pare si parlasse di Internet (download,
etc.), quindi, ipotesi: Rilevare la _vera_ data di sistema da un servizio
esterno (senza arrivare all'orologio atomico, basta un sito _proprio_ che
indica la data e ora esatte).

Allora dovete considerare anche l'ora legale e solare.
Se giusto durante l'utilizzo del programma c'č l'ora legale o solare il
programma si blocca?