Newsgroup: it.comp.appl.access
Titolo: Help per creare un dimostrativo

Ciao a tutti,
vi chiedo qualche suggerimento per poter distribuire un programmino in
access 2000.
La mia esigenza sarebbe di poter creare dalla versione base (funzionante)
una versione demo..magari limitata nel tempo o che ne so...con qualche altro
limite.....
Non ho molte idee su come operare,.....ma magari iniziando dalla
teoria...forse ho qualche speranza.
Ciao
Grazie 1000E+11
--
*Super David *

 ha scritto nel messaggio
news:wfDt7.13661$C15.1...@news.infostrada.it...

Tutti i programmatori si sono cimentati con questo problema. Ognuno di essi
lo ha risolto a suo modo.
API di windows, Password criptate, OCX di protezione, Chiavi elettroniche,
Seriale HD ecc. Anche la protezione a livello utente può essere sfruttata
per i tuoi scopi.
Personalmente mi sono costruito una protezione con un OCX abbinato a codici
criptati con doppia chiave che fino ad ora non è stata craccata e funziona
benissimo.
Su 
www.sitocomune.com
 potrai trovare qualcosa.
Ciao, Carlo


Ho letto qualche faq e altro sul sito comune, ma la mia domanda era rivolta
un po' piu a creare una soluzione che trasformi un prodotto funzionante in
demo...limiti alle funzioni o qualche cosa di similare.
Devo dire che però la tua risposta mi ha datto delle idee interessanti....
I file ocx...li creo con vb o li posso fare anche con vba? e poi scusa
l'insistenza, per criptare un codice con doppia chiave.....come fai...usi
qualche applicativo esterno o sempre tramite vb/vba?
Ciao
Grazie1000E+11
 --
 *Super David *


Gli OCX possono essere creati con VB.
Per criptare uso una API o una funzione accoppiata ad un ocx. La "password"
criptata deve essere accoppiata ad una seconda chiave che viene criptata sul
mio pc. Il cliente, terminato il periodo demo, mi comunica la sua chiave ed
io gli fornisco la mia. L'accoppiata gli fanno funzionare il programma.
Tutti i dati vengono scritti in modo ancora criptato in una BitMap di
sistema (in modo invisibile per l'utente).
Qualora la bitmap venga eliminata il programma provvede a ricrearla.
Siccome la chiave locale è il risultato di una serie di variabili
impostabili solo dall'utente e del tutto univoche, anche una copia del db e
della bmp che contiene il codice di sblocco, sarebbe inutile. Quale
utilizzatore accetterebbe di vedere su bolle e fatture (per esempio) i dati
di un'altra Azienda?
Comunque questo può valere per programmi veramente importanti. Le aziende,
infatti, sanno che una verifica da parte della finanza, le esporrebbe a seri
rischi se non dispongono delle licenze dei software.
Ciao, Carlo


Si ho capito....o meglio ho capito che molte variabili formano una
chiave....che dipende da utente a utente.
Poi in base a questa ne viene creata una seconda...che tu comunichi solo
quando avviene l'aquisto del prodotto.
Le due chiavi in abinata mascherate all'interno di un file e criptate da un'
API in abinata ad un OCX permettono il funzionamento del prg.
Hai qualche info di dove si possono trovare api con queste funzioni....per
provare alcune soluzioni??
Ciao
Grazie 1000.....
--
*SuperDavid*

 ha scritto nel messaggio
news:snFt7.14956$C15.1...@news.infostrada.it...

Ti accludo delle declare:
Public Declare Function CryptAcquireContext Lib "advapi32.dll" Alias
"CryptAcquireContextA" ( _
    phProv As Long, ByVal pszContainer As String, _
    ByVal pszProvider As String, _
    ByVal dwProvType As Long, ByVal dwFlags As Long) As Long
Public Declare Function CryptReleaseContext Lib "advapi32.dll" ( _
   ByVal hProv As Long, ByVal dwFlags As Long) As Long
Public Declare Function CryptGetProvParamString Lib "advapi32.dll" Alias
"CryptGetProvParam" ( _
    ByVal hProv As Long, ByVal dwParam As Long, _
    ByVal pbData As String, pdwDataLen As Long, _
    ByVal dwFlags As Long) As Long
Tutte funzioni presenti in advapi32.dll.
Sul numero 38 (Marzo/Aprile 2001) di Visual Basic Journal potrai trovare
vari esempi concreti. Prova a scaricare i file acclusi al numero 38 da
www.infomedia.it
Ciao, Carlo


Grazie ancora Carlo,
e buona domenica!
--
*SuperDavid *

 ha scritto nel messaggio
news:wfDt7.13661$C15.1...@news.infostrada.it...



Ok per la maschera terroristica (vanno di moda ultimamente) anche se pensavo
di mettere una form dove se il cliente E' UNA CLIENTE belle e carina .... si
puo' fare lo stesso.....
scherzi a parte.....grazie anche per questa idea......una cosa vorrei
capire.....quanto č apribile un mbe?? mi da qualche sicurezza in piu' l'uso
di una dll o di un ocx?? o perche' esterni sono meno sicuri??
Ciao e Grazie 1000E+11
--
*SuperDavid*


Tornando seri... mi spiace ma non ne so abbastanza su OCX e DLL.
Veramente, anche tra chi le usa, non tutti metterebbero la mano sul fuoco
sul fatto che un craker con le palle (mangiandosi magari i creaker) non sia
in grado di scardinare un codice, per quanto fatto bene e con tutti i crismi
di sicurezza.
Se tu riesci a resistere ad un hacker, proponiti alla MS che dopo aver
permesso (indirettamente, s'intende) la copiatura dei suoi programmi a tutti
e quindi a diffondere in ogni cantone del globo i suoi codici adesso
ringrazia e ci rifila l'XP... Anche se so che l'hanno già craccato...
Se il tuo VBA di Access decide se può girare a secondo di un risultato di
una funzione invocata/monitorata attraverso un OCX o una DLL, un craker ti
bypasserebbe la chiamata e fornirebbe il dato che il tuo VBA vorrebe sapere.
Pensa alla PlayStation. Dalla rom una routine dice al lettore CD: "dimmi se
c'è un dato in un particolare punto del cd appena messo (punto incopiabile
con i normali masterizzatori). Lo sfigato ed incompreso lettore CD gli
rifila un bel DueDiPicche ma la routine viene preso per il  naso perchè il
codice gli arriva comunque attraverso il mitico "chippino con tre fili da
saldare". E allora la routine, contentissima che l'utente è ligio con la
legge, permette il prosieguo (per scrivere "prosieguo" mi si è attorcigliato
il cavo della tastiera).
Tutto è in misura del grado di appetibilità del programma. Più è appetibile
e più verrai messo a dura prova dagli hacker. E più difficoltà troveranno,
più saranno contenti di riuscire. Ma non credo che con gli strumenti di MS
si possa arrivare ad un grado di protezione tanto alto da infastidirli.
Penso che solo una sana programmazione in C con chiamate dirette in
ASSEMBLER (assembly) possa vantare un alto grado di sicurezza.
Se usi strumenti standard di protezione allora sei automaticamene sicuro che
ti craccano!
Sull'Amiga, per masterizzare, usavo (ORIGINALE!) un programma che si chiama
MakeCD. Il grado di sicurezza implementato era buono, e bastava spostare il
programma da un punto all'altro del HD che lui si accorgeva e richiedeva il
codice. Penso che lavorava sui checksum dei settori. L'Amiga offre
un'altissima flessibilità sull'installazione dei programmi, e quindi non era
difficile avere la necessità di spostare un programma da una dir ad
un'altra.
Morale: non ti dannare l'anima!
;-)


Ma sai se qualcuno ha mai provato a craccarlo? Mi sembra strano!!
Altrimenti faresti una montagna di soldi!!
L'ocx l'hai scritto te ?
Ciao,
AEOM