SEMPLICI TECNICHE DI PROTEZIONE DEL SOFTWARE

FOXPRO 2.5

© Paolino Canzoneri

Proteggere il proprio codice sorgente è sempre utile e basilare per rendere il proprio lavoro duraturo e professionale nel tempo. I pirati informatici hanno reso indispensabile l’utilizzo di tecniche di protezione che senz’altro giovano al programmatore che altrimenti vedrebbe ore ed ore di duro lavoro rubate o non più attribuite a lui stesso.

Personalmente ho potuto constatare quanto sia frustrante vedere programmatori alle prese con avvocati e cause infinite nonostante avessero registrato ufficialmente i loro programmi.

La Direttiva Legislativa n° 518 del 1992 tutela e riconosce la "Creatività" vista come espressione dello sforzo creativo di progettazione ed elaborazione a prescindere dalle possibili applicazioni industriali e sancisce la SIAE come l’organo principale che tutela i diritti d’autore e preserva da eventuali copiature e/o plagio ai danni di programmi regolarmente registrati.

Però, a volte, è sempre meglio adottare soluzioni "fai date" che di sicuro renderebbero arduo il "lavoro" dei pirati o "Hackers", i quali, ignorando la registrazione del programma, riescono a manipolare e modificare il prodotto originario sia per scopi di lucro che per insano divertimento.

E allora convengono due cose; la prima può essere quella di registrare lo stesso il programma presso la SIAE, la seconda consiste nell’applicare in seno al codice alcune tecniche di controllo e protezione.

In molti anni di lavoro, ho avuto la possibilità di poter visionare numerosissimi programmi che contenevano avvertenze e messaggi che sembravano quasi esortazioni ed appelli al buon senso che, a parer mio, risultavano inefficienti e assolutamente non attendibili dal punto di vista sicurezza.

In questo articolo verranno elencate (con chiari esempi), alcune tecniche a riguardo.

Le migliori protezioni vanno applicate fra le prime righe di codice. Il programma, una volta eseguito, dovrà effettuare svariati controlli. In fase di installazione del programma presso l’elaboratore del Cliente, si può copiare (ad insaputa dello stesso Cliente), un file creato con un qualsiasi editor di testo ma che abbia un estensione DLL oppure CPI dentro una Subdirectory molto importante come "SYSTEM" presente dentro la Dir Windows (C:\WINDOWS\SYSTEM\). Non è importante che cosa contenga il file copiato ma in fase di lancio del programma se questo file non è al suo posto vorrà dire che il programma non gira sullo stesso elaboratore dove abbiamo installato il programma. L’estensione DLL o CPI renderà il file intoccabile per utenti poco esperti. (di fatto chiaramente non si tratta assolutamente di una libreria ma di un semplice file di testo) .

Supponiamo che abbiamo creato il file "VISFRVB9.DLL , copiamolo dentro C:\WINDOWS\SYSTEM\ (è difficilissimo che esista un computer che non abbia almeno una versione di Windows!), dopo, il nostro codice dovrà contenere:

if .not. file("c:\windows\system\visfrvb9.dll") > cerca il file dll…se non lo trova…

set colo to w/n > settaggio caratteri bianchi su sfondo nero

clea > ripulisce lo schermo

@10,10 say "Utilizzo non autorizzato!" > stringa di avviso

wait timeout 10 > attesa di 10 secondi bypassabile premendo un tasto

close all > chiusura di archivi (se aperti)

clea memo > ripulisce la memoria da menù,report etc.

quit > definitiva uscita dal programma

endif > chiusura ciclo IF

Se questo ciclo viene superato è chiaro che le carte sono in regola .

Questo facile esempio dovrebbe essere utilizzabile anche con il Visual Foxpro 6 in ambiente Windows 95/98 (chiederò conferma al nostro WebMaster).

Un altro accorgimento potrebbe aiutarci nel nostro intento.

Si ponga il caso che il programma installato dal cliente sia un programma con un controllo temporaneo che lo rende utilizzabile solo per un periodo stabilito.

La prassi più semplice è la seguente: consideriamo che il cliente debba utilizzare la procedura fino e non oltre il

14 Gennaio 2001, risulta facile quindi, in fase di lancio del programma scrivere quanto segue:

fineuso=ctod("") > creiamo una variable di tipo data

fineuso=date() > assegnamo la data di sistema alla variabile

if fineuso>=ctod("14-01-2001") > controllo se la data attuale risulta uguale o

maggiore della data della variabile

set colo to w/n > settiamo colori dello schermo

clea > ripulisce lo schermo

@10,10 say "Tempo di utilizzo scaduto!" > stringa di avviso

wait timeout 10 > attesa di 10 secondi o di un tasto

close all > chiusura di archivi (se aperti)

clea memo > ripulisce la memoria da menù,report etc.

quit > definitiva uscita dal programma

endif > chiusura ciclo IF

Si potrebbe più semplicemente evitare l’apertura della variabile di tipo data scrivendo direttamente:

if date()>= etc. (come sopra)

ma per una maggiore comprensione ho preferito fare più passaggi.

Chiramente è sempre consigliabile controllare che fra i settaggi iniziali vi sia quello riguardante la data estesa onde evitare malfunzionamenti (SET CENTURY ON).

Oltre la data, si può limitare l’utilizzo della procedura concedendo al Cliente la possibilità di archiviare solo un numero stabilito di record. Chiaramente questa è una prassi da applicare in un programma "shareware" (di valutazione).

Poniamo il caso, quindi, di rilasciare al Cliente un programma di gestione alunni di una scuola.

Per valutare tutti gli aspetti di un nuova procedura, oltre all’estetica e alla funzionalità, daremo, per esempio, la possibilità di poter archiviare 100 record oltre i quali bloccheremo questa funzionalità avvisando il Cliente della limitazione.

Basterà inserire questo controllo:

use clienti.dbf > apriamo l’archivio clienti

if recno()=>100 > se i record inseriti sono 100 o più

set colo to w/n > settiamo colori dello schermo

clea > ripulisce lo schermo

@10,10 say "Questa Versione limita l’uso a 100 record!" > messaggio d’avviso

wait timeout 10 > attesa di 10 secondi o di un tasto

close all > chiusura di archivi (se aperti)

clea memo > ripulisce la memoria da menù,report etc.

quit > definitiva uscita dal programma

endif > chiusura ciclo IF

Come si evince da questi esempi, proteggere e/o limitare l’uso dei programmi può essere possibile e giusto ma se abbiamo bisogno di adottare tecniche un po’ più complesse è bene considerare il prossimo esempio.

Resta sempre il fatto che unendo tutti gli esempi sopra descritti abbiamo già, in sequenza, controlli efficaci ed attendibili.

Creiamo adesso un file memoria chiamato "dat.mem". In fase di installazione della procedura copiamo questo file nella directory ove risedono gli altri file (archivi, indici etc.).

Adottiamo adesso un ultimo controllo che risulta più efficace. Una volta superato quest’ultimo passaggio il programmatore può dormire sonni tranquilli .

Creiamo un file memory chiamato "DAT.MEM"; in fase di installazione del programma presso il Cliente insieme al file eseguibile, gli archivi, gli indici, accoderemo anche questo file.

Dopo i vari accorgimenti sopra descritti scriveremo il seguente codice:

if .not. file("dat.mem") > nel caso non trovi il file

set colo to w/n > settaggio caratteri bianchi su sfondo nero

clea > ripulisce lo schermo

close all > chiusura di archivi (se aperti)

clea memo > ripulisce la memoria da menù,report etc.

quit > definitiva uscita dal programma

else > altrimenti….

Restore from dat.mem additive > richiamo in memoria la variabile gia’

Memorizzata nel file…ed uso additive per impedire la cancellazione

If dat>date() >se quindi dat risulta magggiore della data di sistema

set colo to w/n > settaggio caratteri bianchi su sfondo nero

clea > ripulisce lo schermo

close all > chiusura di archivi (se aperti)

clea memo > ripulisce la memoria da menù,report etc.

quit > definitiva uscita dal programma

else > altrimenti

dat=date() > il file dat adesso contiene la data attuale

erase dat.mem > cancelliamo il file dat.mem

save all like dat* to dat.mem >salva il contenuto pronti per il prossimo controllo.

endif >chiusura ciclo if interno

endif >chiusura ciclo if esterno

Potrebbe risultare quest’ultimo passaggio un po’ complesso da assimilare e’ sufficiente consultare una guida alla programmazione Fox e soffermarsi sui capitoli che includono "restore", "save all like" etc.

Un codice che contiene ad uno ad uno i controlli sopra descritti, e’ un codice molto sicuro e di difficile violazione.

E’ bello pero’ lasciare che la fantasia ponga altri rimedi.

Vi sarebbero molte altre possibilità di includere controlli più o meno complessi, basta pensarci ed inventarne dei nuovi.

Copyright dell'articolo: Paolino Canzoneri

© FoxPro e Visual FoxPro sono un marchi registrati da Microsoft Corporation



Data: 05/02/2000
webmaster@foxitaly.com

dal 22 Giugno 1999