Devi tenerne traccia nel tuo server. Potrai bloccarlo, se del caso. La seconda: devi fidarti del market contando sui grandi numeri. Cambiando spesso lo schema di protezione rendi inutili i backup di versioni "scadute".
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Italian Identificazioni varie
- Thread starter LucaMs
- Start date
- Similar Threads Similar Threads
Io mi sono perso 
Non ho ben capito se la tua app è gratuita o a pagamento, ma se fai tutto sto' casino sicuramente è a pagamento, quindi stai cercando un sistema per proteggere il programma ?
Perché non fai come whatsupp ??
Oppure una cosa ancora più semplice: quando uno acquista il pprogramma gli assegni tu un codice di molte cifre che lui dovrà inserire nella configurazione del programma e che tu inserirai nel database nella tabella degli utenti abilitati.
Se reinstalla basta che reinserisca lo stesso codice.
Però può utilizzare più dispositivi, chiaro, ma non nello stesso momento, quindi potrebbe essere una soluzione.
Sergio
Non ho ben capito se la tua app è gratuita o a pagamento, ma se fai tutto sto' casino sicuramente è a pagamento, quindi stai cercando un sistema per proteggere il programma ?
Perché non fai come whatsupp ??
Oppure una cosa ancora più semplice: quando uno acquista il pprogramma gli assegni tu un codice di molte cifre che lui dovrà inserire nella configurazione del programma e che tu inserirai nel database nella tabella degli utenti abilitati.
Se reinstalla basta che reinserisca lo stesso codice.
Però può utilizzare più dispositivi, chiaro, ma non nello stesso momento, quindi potrebbe essere una soluzione.
Sergio
Se leggi la mia "firma" capisci se la mia app sarà gratuita o a pagamento .
Come fa whatsup? L'ho distinstallata, ma era gratuita... poi si diceva che dovesse iniziare a costare 1€ /anno ma non ne ho idea.
Si, quella del codice dovrebbe essere la soluzione, ma come glielo assegno? L'utente scarica l'app e si connette; ora, che sia l'app a generare il codice ed inviarlo oppure sia il server ad inviarne uno quando l'app si connette senza averne, in entrambi i casi non c'è certezza che chi si connette abbia effettivamente la mia app installata sul suo dispositivo (che sia regolare o piratata fa lo stesso... non per le mie tasche, ovviamente).
Ragionando (ancora? prima o poi fondo) mentre scrivo, come avviene nei siti Web?
Normalmente vengono chiesti: email, nick e pw.
L'email, a quel punto, dovrebbe essere la chiave univoca di una tabella sul server nella quale saranno anche gli altri due dati. Successivamente, l'utente entrerà tramite email+pw o nick+pw se anche il nick è univoco.
Potrei fare nello stesso modo, ma so per "esperienza diretta" che fornire l'email a qualcuno è piuttosto sgradito. Inoltre, l'utente potrebbe smarrire la pw (ma per questo si potrebbe trovare un sistema per inviargliela, tramite qualche altra controprova).
Se Google permettesse (io non ne so alcunché perché non ho nemmeno un account come sviluppatore) di far scaricare l'app gratuitamente ma obbligare poi l'utente a pagare (tramite paypal, ad esempio) per "attivare" l'app, il problema sarebbe in parte risolto: alla ricezione del pagamento, il server invierebbe il codice generato e lo memorizzerebbe nel db (server) insieme ad un nick univoco.
Sarebbe comunque risolto solo parzialmente, perché l'app dovrebbe salvare da qualche parte quel codice e non c'è un posto incancellabile sul dispositivo.
.Come fa whatsup? L'ho distinstallata, ma era gratuita... poi si diceva che dovesse iniziare a costare 1€ /anno ma non ne ho idea.
Si, quella del codice dovrebbe essere la soluzione, ma come glielo assegno? L'utente scarica l'app e si connette; ora, che sia l'app a generare il codice ed inviarlo oppure sia il server ad inviarne uno quando l'app si connette senza averne, in entrambi i casi non c'è certezza che chi si connette abbia effettivamente la mia app installata sul suo dispositivo (che sia regolare o piratata fa lo stesso... non per le mie tasche, ovviamente
).Ragionando (ancora? prima o poi fondo) mentre scrivo, come avviene nei siti Web?
Normalmente vengono chiesti: email, nick e pw.
L'email, a quel punto, dovrebbe essere la chiave univoca di una tabella sul server nella quale saranno anche gli altri due dati. Successivamente, l'utente entrerà tramite email+pw o nick+pw se anche il nick è univoco.
Potrei fare nello stesso modo, ma so per "esperienza diretta" che fornire l'email a qualcuno è piuttosto sgradito. Inoltre, l'utente potrebbe smarrire la pw (ma per questo si potrebbe trovare un sistema per inviargliela, tramite qualche altra controprova).
Se Google permettesse (io non ne so alcunché perché non ho nemmeno un account come sviluppatore) di far scaricare l'app gratuitamente ma obbligare poi l'utente a pagare (tramite paypal, ad esempio) per "attivare" l'app, il problema sarebbe in parte risolto: alla ricezione del pagamento, il server invierebbe il codice generato e lo memorizzerebbe nel db (server) insieme ad un nick univoco.
Sarebbe comunque risolto solo parzialmente, perché l'app dovrebbe salvare da qualche parte quel codice e non c'è un posto incancellabile sul dispositivo.
Ciao Luca,
un piccolo contributo da parte mia.
Se ho ben compreso l'app verrebbe distribuita tramite GooglePlay e sarebbe a pagamento. Una volta avviata per la prima volta dovrebbe ricevere un token in modo che dalla volta successiva si colleghi in automatico. La registrazione del nick (più token) ti serve per discriminare tra i vari giocatori.
Non uso lo store quindi non so come un "pirata" possa avere una copia della tua app, nel senso che se è a pagamento mi aspetto che Google non consenta di scaricarla senza aver ricevuto il contributo previsto e nel suo meccanismo di distribuzione non credo invii il file apk che poi possa essere copiato, inviato via mail ad altri o cose del genere. Almeno, lo spero...
Ad ogni modo, l'uso della mail nel tuo caso potrebbe essere "pericoloso". Immagina che l'utente utilizzi una mail "usa e getta" di quelle ad accesso open (tipo yopmail.com); in tal caso chiunque immetta lo stesso identificativo potrebbe leggere sul quel sito la risposta di registrazione e quindi avere il token da immettere nella sua configurazione. In pratica uno paga e enne-mila giocano (a meno di un test che respinga un secondo accesso a parità di credenziali).
Un sistema (costoso) di controllo potrebbe essere quello di inviare il token tramite SMS. Ciò funzionerebbe anche per i tablet privi di SIM perchè è improbabile che un utente non possegga neanche un telefonino (mica uno smart, uno qualunque). In questo caso avresti la terna Nick+Recapito cellulare+token che sarà univoca e verificata. Per il gioco potrebbe bastare Nick+token ed esclusione di doppioni in contemporanea, mentre per il recovery di un token perso avresti sempre il recapito cellulare. Tra l'altro questa potrebbe essere una buona motivazione per la richiesta di questo dato.
Umberto
un piccolo contributo da parte mia.
Se ho ben compreso l'app verrebbe distribuita tramite GooglePlay e sarebbe a pagamento. Una volta avviata per la prima volta dovrebbe ricevere un token in modo che dalla volta successiva si colleghi in automatico. La registrazione del nick (più token) ti serve per discriminare tra i vari giocatori.
Non uso lo store quindi non so come un "pirata" possa avere una copia della tua app, nel senso che se è a pagamento mi aspetto che Google non consenta di scaricarla senza aver ricevuto il contributo previsto e nel suo meccanismo di distribuzione non credo invii il file apk che poi possa essere copiato, inviato via mail ad altri o cose del genere. Almeno, lo spero...
Ad ogni modo, l'uso della mail nel tuo caso potrebbe essere "pericoloso". Immagina che l'utente utilizzi una mail "usa e getta" di quelle ad accesso open (tipo yopmail.com); in tal caso chiunque immetta lo stesso identificativo potrebbe leggere sul quel sito la risposta di registrazione e quindi avere il token da immettere nella sua configurazione. In pratica uno paga e enne-mila giocano (a meno di un test che respinga un secondo accesso a parità di credenziali).
Un sistema (costoso) di controllo potrebbe essere quello di inviare il token tramite SMS. Ciò funzionerebbe anche per i tablet privi di SIM perchè è improbabile che un utente non possegga neanche un telefonino (mica uno smart, uno qualunque). In questo caso avresti la terna Nick+Recapito cellulare+token che sarà univoca e verificata. Per il gioco potrebbe bastare Nick+token ed esclusione di doppioni in contemporanea, mentre per il recovery di un token perso avresti sempre il recapito cellulare. Tra l'altro questa potrebbe essere una buona motivazione per la richiesta di questo dato.
Umberto
Ciao, Umberto e grazie per la risposta.
Ti faccio subito un'altra domanda: come mai non usi lo store? Mai pubblicato app (come il sottoscritto) o usi altri canali?
La discriminazione tra giocatori dovrà essere fatta semplicemente tramite Nick: non dovranno esistere due Nick uguali.
La creazione ed invio del "token" potrebbe avvenire dal server al client o viceversa, dipende dalla soluzione che riuscirEMO a trovare.
Non conosco quel tipo di email, poi gli darò un'occhiata, ma, come ho scritto, io penso che un utente sia restio ad inviare una propria email, quindi questa ipotesi è gia quasi scartata (quasi perché se alla fine fosse l'unica...!).
Purtroppo, per quanto riguarda un numero di cell, stesso discorso, anzi peggio (io ho fatto una domanda a Google e, alla sua richiesta di un contatto telefonico per fornirmi una risposta, ho preferito fare a meno della risposta: e parlo di Google!).
Sarà davvero difficile trovare una soluzione ideale: tra l'altro, non ho messo sul fuoco un altro problemino, che accenno soltanto, altrimenti complico ancora di più le cose: così come esiste il protocollo "sicuro" https rispetto al normale http, esiste anche il protocolo wss che è la versione sicura di ws (Web Socket); purtroppo gli strumenti a nostra disposizione non supportano wss.
Ho già pensato troppo a questo problema, è una settimana oramai. Intanto vado avanti nello sviluppo del resto, alla fine un metodo o l'altro lo userò.
Grazie ancora per il tuo interessamento, Umberto.
Ti faccio subito un'altra domanda: come mai non usi lo store? Mai pubblicato app (come il sottoscritto) o usi altri canali?
La discriminazione tra giocatori dovrà essere fatta semplicemente tramite Nick: non dovranno esistere due Nick uguali.
La creazione ed invio del "token" potrebbe avvenire dal server al client o viceversa, dipende dalla soluzione che riuscirEMO a trovare
.Non conosco quel tipo di email, poi gli darò un'occhiata, ma, come ho scritto, io penso che un utente sia restio ad inviare una propria email, quindi questa ipotesi è gia quasi scartata (quasi perché se alla fine fosse l'unica...!).
Purtroppo, per quanto riguarda un numero di cell, stesso discorso, anzi peggio (io ho fatto una domanda a Google e, alla sua richiesta di un contatto telefonico per fornirmi una risposta, ho preferito fare a meno della risposta: e parlo di Google!).
Sarà davvero difficile trovare una soluzione ideale: tra l'altro, non ho messo sul fuoco un altro problemino, che accenno soltanto, altrimenti complico ancora di più le cose: così come esiste il protocollo "sicuro" https rispetto al normale http, esiste anche il protocolo wss che è la versione sicura di ws (Web Socket); purtroppo gli strumenti a nostra disposizione non supportano wss.
Ho già pensato troppo a questo problema, è una settimana oramai. Intanto vado avanti nello sviluppo del resto, alla fine un metodo o l'altro lo userò.
Grazie ancora per il tuo interessamento, Umberto.
Ciao,
in attesa della pizza ti rispondo in merito alla distribuzione delle mie app.
Vengono tutte distribuite tramite siti Internet o webserver privati perchè o sono delle app assolutamente gratuite oppure per funzionare necessitano l'adesione ad un servizio a pagamento.
In pratica io vendo il servizio non l'app in sè che, anzi, più viene copiata e diffusa meglio è per chi ha aderito al servizio.
Ti faccio un esempio di un'app che ha avuto un discreto riscontro: "piatto o menu del giorno" per bar/ristoranti.
Il mio cliente è il bar/ristorante, per il quale rilascio una versione personalizzata dell'app. Poi questi diffonde l'app tra i suoi clienti (ad esempio gli impiegati degli uffici circostanti) tramite il suo sito (o uno che metto a disposizione io).
Finchè l'esercente paga per il servizio, ha la possibilità di aggiornare la sua offerta del giorno tramite un server dedicato al servizio e ciò si riflette nelle schermate proposte dalla "sua" app ai "suoi" utilizzatori.
Perchè non un'unica app per più esercenti? Perchè altrimenti non sarebbe personalizzata e soprattutto perchè favorirebbe il rischio di perdere la clientela a vantaggio dei concorrenti! Ovviamente tale app potrebbe essere più gradita agli utenti finali, ma gli esercenti non sarebbero così motivati ad utilizzarla e pagare per essa.. ed attendere che a pagare siano gli utenti finali mi sembra una pia illusione.
Umberto
in attesa della pizza
ti rispondo in merito alla distribuzione delle mie app.Vengono tutte distribuite tramite siti Internet o webserver privati perchè o sono delle app assolutamente gratuite oppure per funzionare necessitano l'adesione ad un servizio a pagamento.
In pratica io vendo il servizio non l'app in sè che, anzi, più viene copiata e diffusa meglio è per chi ha aderito al servizio.
Ti faccio un esempio di un'app che ha avuto un discreto riscontro: "piatto o menu del giorno" per bar/ristoranti.
Il mio cliente è il bar/ristorante, per il quale rilascio una versione personalizzata dell'app. Poi questi diffonde l'app tra i suoi clienti (ad esempio gli impiegati degli uffici circostanti) tramite il suo sito (o uno che metto a disposizione io).
Finchè l'esercente paga per il servizio, ha la possibilità di aggiornare la sua offerta del giorno tramite un server dedicato al servizio e ciò si riflette nelle schermate proposte dalla "sua" app ai "suoi" utilizzatori.
Perchè non un'unica app per più esercenti? Perchè altrimenti non sarebbe personalizzata e soprattutto perchè favorirebbe il rischio di perdere la clientela a vantaggio dei concorrenti! Ovviamente tale app potrebbe essere più gradita agli utenti finali, ma gli esercenti non sarebbero così motivati ad utilizzarla e pagare per essa.. ed attendere che a pagare siano gli utenti finali mi sembra una pia illusione.
Umberto
Quando installo una app da Google store (tramite Google play) è semplicissimo ricavarsi il file apk di installazione, ci vuole circa 30 secondi, per poi installarlo su quanti telefoni vuoi senza pagare !!
Non si riesce a ricavarsi un codice identificativo unico dal telefono ??
Ad esempio il mac ??
Sergio
Non si riesce a ricavarsi un codice identificativo unico dal telefono ??
Ad esempio il mac ??
Sergio
Ciao Sergio,
non metto in dubbio la tua affermazione (e non cerco nemmeno su Google istruzioni dettagliate) perchè, come detto, GooglePlay non mi interessa.
Ad ogni modo, bisognerebbe concludere che pubblicare app a pagamento sia inutile visto che il primo acquirente potrebbe poi diffonderle in enne-mila copie (gratis o a metà prezzo). Ed anche che, in fondo, in Google siano dei polli a proporre un sistema dove un prodotto possa essere illegalmente copiato a iosa.
Certo, vale sempre la considerazione che per 1 o 2 euro sono pochi a pensare alla copia pirata, ma la mia meraviglia è per la facilità con cui si può by-passare l'architettura prevista. Contenti loro..
non metto in dubbio la tua affermazione (e non cerco nemmeno su Google istruzioni dettagliate) perchè, come detto, GooglePlay non mi interessa.
Ad ogni modo, bisognerebbe concludere che pubblicare app a pagamento sia inutile visto che il primo acquirente potrebbe poi diffonderle in enne-mila copie (gratis o a metà prezzo). Ed anche che, in fondo, in Google siano dei polli a proporre un sistema dove un prodotto possa essere illegalmente copiato a iosa.
Certo, vale sempre la considerazione che per 1 o 2 euro sono pochi a pensare alla copia pirata, ma la mia meraviglia è per la facilità con cui si può by-passare l'architettura prevista. Contenti loro..
D
Deleted member 103
Guest
Sarebbe troppo facile!
Quello che dici vale solo per App che non usano ad esempio Licensing library .
Se si usa questa libreria si può ricavare pure il file apk, ma la App non parte se non è stata acquistata.
Esatto, è quello che faccio anche io di solito, non faccio pagare l'app, faccio pagare il servizio.
Leggi il MAC del dispositivo (che è univoco), inverti alcuni caratteri (a tuo piacimento), ti calcoli l'MD5 relativo e lo utilizzi come ID univoco.
Puoi tenere tutto il codice MD5 oppure puoi tenere solo i primi 64 bit, o gli ultimo 64 bit o quello che più ti piace.
In questo modo sarà impossibile capire come è stato calcolato l'ID e quindi non è più riproducibile su altri dispositivi
Sergio
Leggi il MAC del dispositivo (che è univoco), inverti alcuni caratteri (a tuo piacimento), ti calcoli l'MD5 relativo e lo utilizzi come ID univoco.
Puoi tenere tutto il codice MD5 oppure puoi tenere solo i primi 64 bit, o gli ultimo 64 bit o quello che più ti piace.
In questo modo sarà impossibile capire come è stato calcolato l'ID e quindi non è più riproducibile su altri dispositivi
Sergio
Già, ma il punto non è inventare un codice complesso (ho fatto una prova e il mio dispositivo non restituisce il MAC, oltretutto).
Il punto è che questo codice, comunque sia creato, non può essere salvato sul dispositivo in maniera che non venga mai cancellato.
(tra l'altro anche il MAC può essere modificato, volendo)
Il punto è che questo codice, comunque sia creato, non può essere salvato sul dispositivo in maniera che non venga mai cancellato.
(tra l'altro anche il MAC può essere modificato, volendo)
Avrei un suggerimento un po' perfido: passa la palla all'utente!
Mi spiego meglio: la tua app specifica chiaramente che il token univoco che insieme al nick identifica un giocatore viene memorizzato sul dispositivo dell'utente in modo da rendere automatico il login. L'utente viene avvisato che in caso di disinstallazione dell'app oppure di reset del dispositivo (etc etc) tale token verrà irrimediabilmente perso e sarà necessaria una nuova registrazione (e pagamento) A MENO CHE l'utente stesso non provveda a registrarsi tramite email valida.
A questo punto tocca a loro decidere se tutelarsi rivelando una mail oppure scommettere che tutto andrà bene nei secoli dei secoli.
Mi spiego meglio: la tua app specifica chiaramente che il token univoco che insieme al nick identifica un giocatore viene memorizzato sul dispositivo dell'utente in modo da rendere automatico il login. L'utente viene avvisato che in caso di disinstallazione dell'app oppure di reset del dispositivo (etc etc) tale token verrà irrimediabilmente perso e sarà necessaria una nuova registrazione (e pagamento) A MENO CHE l'utente stesso non provveda a registrarsi tramite email valida.
A questo punto tocca a loro decidere se tutelarsi rivelando una mail oppure scommettere che tutto andrà bene nei secoli dei secoli.
Ma non lo devi salvare sul dispositivo, il programma lo ricalcola ogni volta, mica lo devi tenere memorizzato
Questo codice (direi di chiamarlo IDKey da adesso) dovrebbe identificare l'accoppiata dispositivo+app, una volta per tutte, non cambiare.
Guarda che io questo sistema lo uso da anni e non ho mai avuto problemi.
Ho realizzato parecchi programmi in VB6 e VB.NET dove il problema era proprio quello di proteggere il programma dalle copie illegali.
Il programma parte, si legge un codice unico dal dispositivo o dal PC (io utilizzo il numero di serie dell'hd, o il numero di serie del microprocessore, o l'indirizzo MAC), poi ci fa dei calcoli e mostra a video un "numero di serie del programma". Questo numero di serie non potrà MAI cambiare dato che ho usato un identificativo hardware, come ad esempio il MAC del mio Android.
Il cliente fa funzionare il programma che però gira in modalità "demo" e quindi non riesce a fare tutto ma comunque può vedere che il programma fa quello che lui vuole. A questo punto paga il programma, e mi comunica (tramite email o SMS) il numero di serie.
Io faccio dei calcoli su questo numero di serie e mi ricavo un altro numero che chiamo "codice di attivazione" e che vado a comunicare al cliente.
Il cliente inserisce questo codice nella configurazione del programma.
Ogni volta che il programma parte, si legge l'identificativo hardware, si ricalcola quindi il "numero di serie", esegue gli stessi calcoli che ho fatto io e si ricava quindi il "codice di attivazione". Se questo corrisponde a quello inserito dal cliente allora ok, altrimenti si mette in modalità "demo".
Se il cliente cancella il programma e lo reinstalla, il "numero di serie" non cambia, e quindi basta che reinserisca lo stesso "codice di attivazione" che gli ho comunicato e il programma riparte.
Se invece cambia dispositivo il programma va solo in modalità "demo".
Nel tuo caso invece, io farei che il cliente mi comunica il "numero di serie" che gli appare, e nel database che ho sul server abilito quel numero di serie.
Sergio
Ho realizzato parecchi programmi in VB6 e VB.NET dove il problema era proprio quello di proteggere il programma dalle copie illegali.
Il programma parte, si legge un codice unico dal dispositivo o dal PC (io utilizzo il numero di serie dell'hd, o il numero di serie del microprocessore, o l'indirizzo MAC), poi ci fa dei calcoli e mostra a video un "numero di serie del programma". Questo numero di serie non potrà MAI cambiare dato che ho usato un identificativo hardware, come ad esempio il MAC del mio Android.
Il cliente fa funzionare il programma che però gira in modalità "demo" e quindi non riesce a fare tutto ma comunque può vedere che il programma fa quello che lui vuole. A questo punto paga il programma, e mi comunica (tramite email o SMS) il numero di serie.
Io faccio dei calcoli su questo numero di serie e mi ricavo un altro numero che chiamo "codice di attivazione" e che vado a comunicare al cliente.
Il cliente inserisce questo codice nella configurazione del programma.
Ogni volta che il programma parte, si legge l'identificativo hardware, si ricalcola quindi il "numero di serie", esegue gli stessi calcoli che ho fatto io e si ricava quindi il "codice di attivazione". Se questo corrisponde a quello inserito dal cliente allora ok, altrimenti si mette in modalità "demo".
Se il cliente cancella il programma e lo reinstalla, il "numero di serie" non cambia, e quindi basta che reinserisca lo stesso "codice di attivazione" che gli ho comunicato e il programma riparte.
Se invece cambia dispositivo il programma va solo in modalità "demo".
Nel tuo caso invece, io farei che il cliente mi comunica il "numero di serie" che gli appare, e nel database che ho sul server abilito quel numero di serie.
Sergio
Devo rileggere con più calma (a occhio mi sembra tutto molto logico e ben fatto, ma ho un bel mal di testa e un mucchio di cose da fare, sigh).
Però il problema è che non c'è un numero fisso sul dispositivo. Ad esempio, il MAC: ho trovato sul sito una funzione per ottenerlo: ebbene, il mio smartphone, ad esempio, non restituisce un numero valido.
Poi c'è il fatto di chiedere il pagamento dopo lo scaricamento e l'installazione dell'app: questa è senz'altro la soluzione migliore, ma Google lo consente o ti banna? E' chiaro che a quel punto su Google Play l'app la pubblicherei gratuita.
Però il problema è che non c'è un numero fisso sul dispositivo. Ad esempio, il MAC: ho trovato sul sito una funzione per ottenerlo: ebbene, il mio smartphone, ad esempio, non restituisce un numero valido.
Poi c'è il fatto di chiedere il pagamento dopo lo scaricamento e l'installazione dell'app: questa è senz'altro la soluzione migliore, ma Google lo consente o ti banna? E' chiaro che a quel punto su Google Play l'app la pubblicherei gratuita.
Phone.GetSettings("android_id")
Similar Threads
