-
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 B4A - Registri - Scrittura/Lettura...
- Thread starter Atob4a
- Start date
- Similar Threads Similar Threads
Sì, ti sei spiegato. 
Però non credo che esista qualcosa di simile.
E anche se esistesse non credo che avresti accesso a file o altro nella sezione di Sistema.
Per accedere a quella sezione è necessario il Root del telefono.
Se spieghi meglio le tue necessità magari qualcuno di più esperto in materia potrebbe darti delle soluzioni per il tuo caso.
Però non credo che esista qualcosa di simile.
E anche se esistesse non credo che avresti accesso a file o altro nella sezione di Sistema.
Per accedere a quella sezione è necessario il Root del telefono.
Se spieghi meglio le tue necessità magari qualcuno di più esperto in materia potrebbe darti delle soluzioni per il tuo caso.
Se c'è il Registro delle chiavi di Windows su Android? Android si basa sul Kernel Linux..... Anche se esistesse qualcosa di simile le chiavi non sarebbero nemmeno lontanamente uguali.
Ma se di preciso spiegasse cose vorrebbe modificare magari si può dare un suggerimento più preciso?
Last edited:
Se c'è qualcosa di simile.......... tipo il Registro di Android. ?
Vorrebbe salvare delle variabili/dati senza usare file o DB.
Però, anche se per caso esiste quel registro, dubito che sia accessibile la parte di sistema da una app normale senza Root.
Aspettiamo che @Atob4a ci spieghi meglio quale è la sua necessità/obiettivo.
Credo che possa bastare anche salvare qualcosa sulla DirInternal in modo che non sia visibile da altre app e dall'utente.
Vorrebbe salvare delle variabili/dati senza usare file o DB.
Però, anche se per caso esiste quel registro, dubito che sia accessibile la parte di sistema da una app normale senza Root.
Aspettiamo che @Atob4a ci spieghi meglio quale è la sua necessità/obiettivo.
Credo che possa bastare anche salvare qualcosa sulla DirInternal in modo che non sia visibile da altre app e dall'utente.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ora ho capito. Scusate ero su un altro pianeta. Pensavo volesse modificare qualche chiave di registro.
Invece vuole salvare dei dati che non spariscano con la disinstallazione, non possano essere cancellati quindi non salvati in un file o DB.
Se il problema è quello che ho capito (ma possibilmente ho frainteso di nuovo) è un problema annoso di Android.
Nel passato scrivevamo dati nella root principale su cartelle nascoste. Cosi da recuperare data della prima installazione, codice di attivazione app e altri dati che non vuoi l'utente acceda e che non si perdano.
Adesso che la memoria root si prevede dalla versione 11 non si possa più usare (chissà come farà WhastApp per gli archivi) rimane poco da fare se non salvarli esternamente e trovando un modo creativo per identificare il dispositivo e accedendo solo ai dati relativi a quel dispositivi/utente (visto che tutti gli ID non funzionano nelle ultime versioni a parte ID-Advice di google)
Al momento non ti saprei dire come fare escludendo l'uso di DB, file o Cloud esterni.
Io salvo i dati in un MySQL esterno che accedo con delle API PHP identificando (grossomodo) il dispositivo
Per iOS salverei su File.DirDocuments e userei questo attributo:
Questo mi permette di condividere i dati con il Mac e non verrebbero cancellati alla disinstallazione (spero) se non fatto specificatamente (credo)
Nel passato scrivevamo dati nella root principale su cartelle nascoste. Cosi da recuperare data della prima installazione, codice di attivazione app e altri dati che non vuoi l'utente acceda e che non si perdano.
Adesso che la memoria root si prevede dalla versione 11 non si possa più usare (chissà come farà WhastApp per gli archivi) rimane poco da fare se non salvarli esternamente e trovando un modo creativo per identificare il dispositivo e accedendo solo ai dati relativi a quel dispositivi/utente (visto che tutti gli ID non funzionano nelle ultime versioni a parte ID-Advice di google)
Al momento non ti saprei dire come fare escludendo l'uso di DB, file o Cloud esterni.
Io salvo i dati in un MySQL esterno che accedo con delle API PHP identificando (grossomodo) il dispositivo
Per iOS salverei su File.DirDocuments e userei questo attributo:
B4X:
#PlistExtra: <key>UIFileSharingEnabled</key><true/>Si intendo le chiavi di registro "tipo" windows...insomma quelle che si vedono con il Regedit.
Allora premetto che ho fatto un po' un casino con i post...in realtà ne avevo aperto un'altro "Proteggere un'app".ma lo modificavo sempre...poi dopo 15 minuti mi ha bloccato e non sapevo se l'aveva preso ed ho aperto quest'altro....e chiedo scusa per questo
Lo scopo è quello di scrivere delle variabili in un luogo dove solo io so!
Vorrei limitare l'uso della mia app ad un certo numero di utilizzo.
Al momento ho fatto così:
Ogni volta che viene usata l'app incremento un contatore che al momento viene memorizzato in un file
Il valore prima di essere memorizzato nel file, viene criptato
quindi supponiamo che il valore 30 corrisponda a: $&$&/)(/jgjhg$&$%$ ok!?
e supponiamo che il massimo numero di utilizzi sia 40
Il problema è che se uno smanettone/praticone fruga nel cellulare, potrebbe individuare il file che contiene il contatore e capire, una volta che gli si blocca l'app e conseguentemente sbloccata dall'assistenza, che se ci scrive dentro sempre "$&$&/)(/jgjhg$&$%$" (che corrisponde a 30) l'app non si blocca più.
Quindi avevo pensato ai registri tipo windows...in passato con vb6 mi divertivo tantissimo...perchè creavo creavo direttamente le chiavi con dei nomi assurdi, quasi impossibile da capire a chi si riferissero
...Pensavo ad una cosa del genere.
In realtà mi interessa raggiungere lo scopo della protezione sul numero di utilizzi...con "registri" o senza...se potete indicarmi un metodo.
Grazie
ciao ragazzi
Se l'app fa comunque uso di Internet, ti conviene gestire la "protezione" sul tuo server (nel tuo caso una banale tabella licenza-contatore)
Questo sarebbe sufficiente per bloccare l'utente normale. Ricorda che chi ha tempo e voglia può sempre decompilare, modificare anche solo la parte di test e riccompilare liberandosi così della protezione.
In generale bisognerebbe sempre chiedersi se valga la pena impegnare tempo erisorse per proteggere un sw piuttosto che cercare di diffonderlo il più possibile e migliorarlo ed aggiornarlo frequentemente. Anche il prezzo di vendita gioca un ruolo (AutoCAD a 10 milioni era un invito a tentare strade alternative ed illegali).
Questo sarebbe sufficiente per bloccare l'utente normale. Ricorda che chi ha tempo e voglia può sempre decompilare, modificare anche solo la parte di test e riccompilare liberandosi così della protezione.
In generale bisognerebbe sempre chiedersi se valga la pena impegnare tempo erisorse per proteggere un sw piuttosto che cercare di diffonderlo il più possibile e migliorarlo ed aggiornarlo frequentemente. Anche il prezzo di vendita gioca un ruolo (AutoCAD a 10 milioni era un invito a tentare strade alternative ed illegali).
Niente di speciale. Quando hai un nuovo utente rilasci un codice licenza e su una tabella del DB sul server memorizzi quel codice licenza ed il valore iniziale del contatore.
Ogni volta che l'app parte, invia al server un "comando" del tipo licenza+avvio (tanto per dire) e il middleware presente sul server aggiorna il contatore. Se arriva a zero risponde con "errore, contatore esaurito", altrimenti con "procedi, hai altri 5 avvi da giocarti".
La fase di creazione e rilascio licenza dipende dal sw e dal modello di business. In generale è tipica della fase di prima Registrazione e il codice lo salvi in locale (se hai un DB sqlite per altri usi, può andare lì; altrimenti basta un file testo nel DirInternal).
Al secondo avvio del sw, viene prelevato il codice licenza, inviato al server ed in funzione della risposta ricevuta si potrà mostrare un mesasggio di chiusura ("hai terminato i crediti") o proseguire con un Login (se multi-utente o multi-profilo) o con la presentazione del Menu o della schermata principale.
Scusa la genericità della risposta, ma non sapendo nulla del tuo sw né del modello di business non è facile essere precisi.
Ogni volta che l'app parte, invia al server un "comando" del tipo licenza+avvio (tanto per dire) e il middleware presente sul server aggiorna il contatore. Se arriva a zero risponde con "errore, contatore esaurito", altrimenti con "procedi, hai altri 5 avvi da giocarti".
La fase di creazione e rilascio licenza dipende dal sw e dal modello di business. In generale è tipica della fase di prima Registrazione e il codice lo salvi in locale (se hai un DB sqlite per altri usi, può andare lì; altrimenti basta un file testo nel DirInternal).
Al secondo avvio del sw, viene prelevato il codice licenza, inviato al server ed in funzione della risposta ricevuta si potrà mostrare un mesasggio di chiusura ("hai terminato i crediti") o proseguire con un Login (se multi-utente o multi-profilo) o con la presentazione del Menu o della schermata principale.
Scusa la genericità della risposta, ma non sapendo nulla del tuo sw né del modello di business non è facile essere precisi.
Last edited:
L'applicazione è singola e non prevede multiutenze.
Quando dici "server" intendi un server remoto? cioè dovrei avere un sito ed un file php che mi memorizzi gli utilizzi...potrei chiamare una quesry string https://www.miosito.it/contatore.php?licenza=skjhdfks
Altrimenti, allora, potrei gestire il tutto con sqllite...ovviamente spero di poter mettere delle password al db.
Quando dici "server" intendi un server remoto? cioè dovrei avere un sito ed un file php che mi memorizzi gli utilizzi...potrei chiamare una quesry string https://www.miosito.it/contatore.php?licenza=skjhdfks
Altrimenti, allora, potrei gestire il tutto con sqllite...ovviamente spero di poter mettere delle password al db.
Per fornire un minimo di contesto e chiarire quanto sopra, posso dire che sostanzialmente io opero tramite due distinti modelli di business: sviluppo custom o Saas (software as a service).
Il secondo direi sia vicino a quanto chiedevi.
Nel caso di un Sass, il cliente paga un abbonamento a tempo oppure acquista un credito scalare (i crediti cui ho accennato). Ricevuto il pagamento, genero un codice di licenza per quel cliente e lo invio tramite email. Il cliente lancia il sw (scaricato liberamente, tanto senza licenza non serve a nulla o va in demo) e la prima schermata che trova è quella dell'immissione del codice licenza. Tale codice viene memorizzato in locale (sqlite, file testo, kvs..) e subito trasmesso al server per una verifica. Il server risponde con opportuni codici di errore (licenza non valida, scaduta, sospesa; credito esaurito..) oppure confermado l'operatività (ok, crediti rimaneniti X; ok, tempo rimanente Y; ok, livello base/avanzato..). Il sw legge la risposta del server e si regola di conseguenza.
Al successivo riavvio del sw, la schermata di registrazione licenza viene saltata perché il sw trova già in locale tale codice e può andare direttamente alla fase di verifica. Spesso nel menu Settings c'è la possibilità di cambiare il codice licenza in modo da gestire situazioni che necessitino codici nuovi senza dover disinstallare e reinstallare, partendo da zero. Dipende dai sw.
Cosa può fare un cliente truffaldino? Usare la licenza di un amico? Se ad entrambi va bene mischiare i dati dell'uno e dell'altro o avere stampe/videate con la ragione sociale errata..io di certo non mi faccio venire il mal di testa! E considerando che cerco di praticare prezzi contenuti non credo valga la pena per loro imbrogliare. Ad ogni modo, il "ladro" non sarebbe mai stato un cliente pagante per me e, in un certo senso, non ho perso nulla..
Il secondo direi sia vicino a quanto chiedevi.
Nel caso di un Sass, il cliente paga un abbonamento a tempo oppure acquista un credito scalare (i crediti cui ho accennato). Ricevuto il pagamento, genero un codice di licenza per quel cliente e lo invio tramite email. Il cliente lancia il sw (scaricato liberamente, tanto senza licenza non serve a nulla o va in demo) e la prima schermata che trova è quella dell'immissione del codice licenza. Tale codice viene memorizzato in locale (sqlite, file testo, kvs..) e subito trasmesso al server per una verifica. Il server risponde con opportuni codici di errore (licenza non valida, scaduta, sospesa; credito esaurito..) oppure confermado l'operatività (ok, crediti rimaneniti X; ok, tempo rimanente Y; ok, livello base/avanzato..). Il sw legge la risposta del server e si regola di conseguenza.
Al successivo riavvio del sw, la schermata di registrazione licenza viene saltata perché il sw trova già in locale tale codice e può andare direttamente alla fase di verifica. Spesso nel menu Settings c'è la possibilità di cambiare il codice licenza in modo da gestire situazioni che necessitino codici nuovi senza dover disinstallare e reinstallare, partendo da zero. Dipende dai sw.
Cosa può fare un cliente truffaldino? Usare la licenza di un amico? Se ad entrambi va bene mischiare i dati dell'uno e dell'altro o avere stampe/videate con la ragione sociale errata..io di certo non mi faccio venire il mal di testa! E considerando che cerco di praticare prezzi contenuti non credo valga la pena per loro imbrogliare. Ad ogni modo, il "ladro" non sarebbe mai stato un cliente pagante per me e, in un certo senso, non ho perso nulla..
Vero, ma perché nasconderlo?
Le informazioni che contiene potrebbero essere crittate. Ma ammettiamo invece che siano in chiaro; cosa troverebbe il curioso? Il codice di licenza e magari qualche altro dato di configurazione? Cosa potrebbe fare di truffaldino a quel punto? Copiarlo su un altro device? In quel caso avresti un problema se il business model prevede un tanto a licenza e quindi per usare il tuo sw un cliente dovrebbe acquistare tante licenze quanti sono i device su cui farlo girare contemporaneamente.
E' questo lo scenario?
Le informazioni che contiene potrebbero essere crittate. Ma ammettiamo invece che siano in chiaro; cosa troverebbe il curioso? Il codice di licenza e magari qualche altro dato di configurazione? Cosa potrebbe fare di truffaldino a quel punto? Copiarlo su un altro device? In quel caso avresti un problema se il business model prevede un tanto a licenza e quindi per usare il tuo sw un cliente dovrebbe acquistare tante licenze quanti sono i device su cui farlo girare contemporaneamente.
E' questo lo scenario?
No, nel file è scritto il contatore...anche se criptato comunque potrebbe aprire il file e prendere l'ultima stringa criptata "kdjfksdfj//879024508239485", che corrisponde a 30 che significa che può ancora finzionare in quanto il limite è 40 (sto inventando dei numeri eh!), e quando l'app si blocca potrebbe editare il file e sostituire il contatore con la stringa che rappresenta 30...e l'app ...riparte!