(s-) protezione del software

[book]

domanda: conoscete metodi per proteggere efficacemente il software e non farselo copiare?

a me sembra di no! neanche la versione 8 con utente e pass riesce a farcela!

[stregatto]

??
i modi ci sono…
varii thread sull'argomento.


.g.

[book]

i tread ci sono ma nessuno valido.

[stregatto]

cosa cerchi, allora? protezione Hw?
personalmente uso un codice di validazione ricavato da due dati che l'utente deve inserire (ragione sociale e P.IVA) e che vengono riportati su tutte le stampe. cambiandone uno cambia il codice, e non è eccelso stampare un ordine con ragionesociale/piva di un altro…
c'è che usa il MAC address. per ogni installazione viene rilasciato (via mail) un codice da quello ricavato; il problema è se si cambia la scheda…
e così via, ce ne sono varii.

.g.

[book]

questi sono metodi noti ma non sono il massimo della sicurezza.
i valori del campo "codice di validazione" possono sempre essere letti ed utilizzati ed in linea di massima si riesce a ricavarne il calcolo eseguito.
In particolare mi riferisco a quando entrano con le password, oppure ti esportano gli script o li fanno eseguire da altri file esterni alla tua applicazione, o giocano con le relazioni ed i file civetta, ect.ect.ect.ect.
e ti ritrovi con una applicazione aperta in meno di 5 minuti!

[stregatto]

i valori del campo "codice di validazione" possono sempre essere letti ed utilizzati ed in linea di massima si riesce a ricavarne il calcolo eseguito.

mica tanto. dipende dall'algoritmo che usi. in particolare se usi in combinazione con l'algoritmo una chiave arbitraria (di almeno 40 caratteri) da cifrare, la vedo difficile, a meno di non avere un vasto campione di esempi.

in particolare mi riferisco a quando entrano con le password, oppure ti esportano gli script o li fanno eseguire da altri file esterni alla tua applicazione, o giocano con le relazioni ed i file civetta, ect.ect.ect.ect.
e ti ritrovi con una applicazione aperta in meno di 5 minuti!

anche qui, la mia esperienza con l'8 è abbastanza buona: se i profili di accesso sono ben impostati non hai possibilità di avere accesso agli script a meno che tu non abbia nome utente e password che te lo consentano…
avendo fatto la prova, non vedo la possibilità di importare script in altro file, e, anche in caso di svelamento campi/record mediante relazioni, l'unica cosa che si può vedere sono la ragione sociale e il codice assegnato all'utente (quindi, elementi noti), in quanto le operazioni di validazione si basano su script (non trasparente, non esportabile e non debugabile da altri utenti), variabili e campi globali (cancellati alla fine dello sciript).

poi, ovviamente tutto è relativo. si tratta semplicemente di capire QUALI risorse mette in campo chi vuole aprire il file, io sto parlando di utente o smanettone medio…
oltretutto, se distribuisci la tua soluzione con accesso completo disabilitato, anche entrando non serve a granché… l'idea è quella di far costare di meno (in termini di tempo, operatività e denaro) L'ACQUISTO REGOLARE rispetto ad un "krak" necessariamente monco e poco affidabile.

.g.


.g.

[stregatto]

i valori del campo "codice di validazione" possono sempre essere letti ed utilizzati ed in linea di massima si riesce a ricavarne il calcolo eseguito.

mica tanto. dipende dall'algoritmo che usi. in particolare se usi in combinazione con l'algoritmo una chiave arbitraria (di almeno 40 caratteri) da cifrare, la vedo difficile, a meno di non avere un vasto campione di esempi.

in particolare mi riferisco a quando entrano con le password, oppure ti esportano gli script o li fanno eseguire da altri file esterni alla tua applicazione, o giocano con le relazioni ed i file civetta, ect.ect.ect.ect.
e ti ritrovi con una applicazione aperta in meno di 5 minuti!

anche qui, la mia esperienza con l'8 è abbastanza buona: se i profili di accesso sono ben impostati non hai possibilità di avere accesso agli script a meno che tu non abbia nome utente e password che te lo consentano…
avendo fatto la prova, non vedo la possibilità di importare script in altro file, e, anche in caso di svelamento campi/record mediante relazioni, l'unica cosa che si può vedere sono la ragione sociale e il codice assegnato all'utente (quindi, elementi noti), in quanto le operazioni di validazione si basano su script (non trasparente, non esportabile e non debugabile da altri utenti), variabili e campi globali (cancellati alla fine dello script).

aggiungo anche che personalmente faccio aprire tutte le mie soluzione come utente ospite (senza privilegi). Gli utenti sono registrati in una tabella del programma, con tre profili prefissati (amministratore, utente, ospite), e vengono creati direttamente all'avvio (ed eliminati in chiusura), e dopo l'apertura viene loggato l'utente predefinito nelle impostazioni.

poi, ovviamente tutto è relativo. si tratta semplicemente di capire QUALI risorse mette in campo chi vuole aprire il file, io sto parlando di utente o smanettone medio…
oltretutto, se distribuisci la tua soluzione con accesso completo disabilitato, anche entrando non serve a granché… l'idea è quella di far costare di meno (in termini di tempo, operatività e denaro) L'ACQUISTO REGOLARE rispetto ad un "krak" necessariamente monco e poco affidabile.

.g.

[book]

Ti premetto che non sono uno sviluppatore professionista, non distribuisco soluzioni e nemmeno le vendo ed ovviamente non sono un hacker.

La mia curiosità è solo per fini teorici e non pratici. Vorrei trovare una risposta che sia diversa dal “NO” a questa domanda. E’ possibile sviluppare con FM applicativi “complessi” con le necessarie “tutele” per il lavoro dello sviluppatore e la proprietà del software?

Sembra chiaro ad entrambi che per la protezione dell’applicazione non si può fare affidamento sulle pass di accesso ai file.
Valutiamo adesso l’affidabilità degli script.
- non trasparente (diciamo non trasparente al 80%)
- non esportabile (vero se blocchi l’esportazione)
- non debugabile (vero)
- non eseguibili da altri file esterni alla tua applicazione – lo hai dimenticato - (falso)

La congiunzione della mia citazione è una “o” e non una “e”

Affinché l’applicazione funzioni devi lasciare all’utente corrente la possibilità di eseguire gli script anche quelli non visibili ed eseguiti in background.
Il programmino che manda in esecuzione con la sequenza voluta gli script (non visibili dall’utente corrente) di un file di FM è cosa nota.

nel caso della chiave arbitraria...
… in questo caso è un tantino più difficile il computer dovrebbe calcolare per qualche settimana di seguito.
Pensa che ci sono sviluppatori che si sono inventati cose ancora più complicate e poi sono caduti come le pere quando sono passati dal collo della bottiglia.

Alla fine di tutte le invenzioni di cifratura lo sviluppatore deve scrivere codice che di solito ha questo aspetto:
se tutto quello che ha elaborato l’algoritmo è uguale alla stringa che ti ho mandato per Email per attivare l’applicazione esegui “attiva” in caso contrario esegui “demo”.

Di solito “attiva” e “demo” sono script.

Alcune volte basta mandare in esecuzione “attiva” con il programmino… e l’algoritmo va a farsi friggere.
Altre volte basta andare nel formato invisibile con lo script invisibile per leggere il valore visibile di tutto quello che ha elaborato l’algoritmo e ricopiarlo.
Quando nelle tue applicazioni escludi alcuni script dal menù credi di giocare a script coperti invece tutti gli script scoperti.
Certo non così facile come scritto ma è sufficiente per considerare poco affidabili gli script per la protezione delle applicazioni.
Prova a distribuire le tue applicazioni con il menù degli script completo (tanto lo fai già ma non lo sai – anzi da adesso lo sai) e vedi cosa accade.

…oltretutto, se distribuisci la tua soluzione con accesso completo disabilitato, anche entrando non serve a granché…

Nelle runtime di FM l’accesso completo è solo disabilitato non tolto......

… l'idea è quella di far costare di meno (in termini di tempo, operatività e denaro) L'ACQUISTO REGOLARE rispetto ad un "krak" necessariamente monco e poco affidabile:

È vero fintanto che parliamo di programmi di qualche centinaio di Euro di valore… nelle applicazioni moltoooo più costose quello che cercano di copiarti è la logica e non l’applicazione.
saluti

[stregatto]

- non eseguibili da altri file esterni alla tua applicazione – lo hai dimenticato - (falso)

non l'ho dimenticato assolutamente. semplicemente se lo script è scritto bene e se non è debugabbile, non permette di carpire informazioni non volute.

Alla fine di tutte le invenzioni di cifratura lo sviluppatore deve scrivere codice che di solito ha questo aspetto: se tutto quello che ha elaborato l’algoritmo è uguale alla stringa che ti ho mandato per Email per attivare l’applicazione esegui “attiva” in caso contrario esegui “demo”.

Di solito “attiva” e “demo” sono script.

Alcune volte basta mandare in esecuzione “attiva” con il programmino… e l’algoritmo va a farsi friggere.

mica tanto. una buona chiusura dovrebbe funzionare sul tipo: se non ci sono le condizioni mostra finestra di avviso, se dopo la finestra continuano a non sussistere chiudi l'applicaizone/file; in caso contratio prosegui.

Altre volte basta andare nel formato invisibile con lo script invisibile per leggere il valore visibile di tutto quello che ha elaborato l’algoritmo e ricopiarlo.

allora non leggi! dal momento che l'algoritmo di validazione si basa su variabili interne ad esso e non su campi calcolati, che cosa si legge l'eventuale spione, se lo script non è debuggabile? può al massimo eseguirlo non avendo altri risultati…

È vero fintanto che parliamo di programmi di qualche centinaio di Euro di valore… nelle applicazioni moltoooo più costose quello che cercano di copiarti è la logica e non l’applicazione.

in questo caso hanno bisogno dell'intero accesso al file. e -ripeto- con una buona chiusura la vedo abbastanza dura…

.g.

[book]

allora non leggi! dal momento che l'algoritmo di validazione si basa su variabili interne ad esso e non su campi calcolati, che cosa si legge l'eventuale spione, se lo script non è debuggabile? può al massimo eseguirlo non avendo altri risultati…

è come nella vita c’è chi vede di più e c’è chi vede di meno.
pensa che tanto tempo fa per gioco con i miei ragazzi ho utilizzato i primi 4 caratteri di un campo, i primi 11 di un altro e creato un codice alfanumerico di 40 caratteri.
Non ci crederai un 486 è riuscito a decriptarlo in circa 10 giorni.
da quel giorno ho usato come codice segreto questa stringa: “1”