Newsgroup: it.comp.java
Titolo: Unire DB e Codice in un unico file....

Ok... Secondo voi è possibile in "qualche modo"(Qualsiasi soluzione è
buona...basta che raggiunga lo scopo) creare un applicazione in Java che
legga dati da un DB e che sia il codice che il DB risiedano(magari in un
file) nello stesso "posto"?. Il tutto però non deve essere ne visibile ne
utilizzare il codice o il DB in maniera separata... Insomma e possibile
proteggere DB e Codice in modo che l'utente finale possa leggere il DB solo
tramite l'applicazione?
Io sono un pò scettico... questo quesito me lo ha posto un mio collega...
che ne pensate?
Grazie.

 leggere il DB solo tramite l'applicazione?
Usa un formato di database personalizzato (binario) e scrivi
il programma in C/C++.
Qualcuno potrebbe mettersi a de-ingegnierizzare il database,
ma il tempo impiegato sarebbe moooolto.
Davide

 wrote in message
9p9sqn$gsnhp$1...@ID-18487.news.dfncis.de...

Grazie ancora... ma penso che sia un pò troppo complesso ... altri
suggerimenti per raggirare l'ostacolo?
Grazie.

 Grazie.
Premetto che sono molto ignorante, e la risposta potrebbe essere OT, ma è
cmq un risposta...
Ne ho sentito parlare e non ho provato di persona, quindi nemmeno io sono
molto sicuro...
Prova con File Maker Pro, che permette di racchiudere in un .EXE codice del
programma e Database. Tutto in un file.
Non penso che potrai usare Java, cmq...
Ciao!
Valerio Troiano.

 wrote in message 9p9u1s$6a7$1...@le.cs.unibo.it...

E' racchiure tutto in un .JAR e poi crittografarlo con un Obfuscator ?
Che ne pensate?

Marco Russo wrote:

Perche' non crittare semplicemente il dB? Non avresti problemi di accesso da
parte di altre applicazioni. Non capisco invece  a cosa serva avere DB e
codice nella stessa "locazione", ma forse potresti farti un Classloader che
carichi le classi direttamente dal DB invece che dal Filesystem, supposto che
la cosa abbia senso. Mai provata una cosa del genere, buttata la' cosi' al
volo e magari neanche fattibile.
Secondo me comunque con la crittografia risolvi il tutto.
ciao
uL


Intendo dire:
All'utente sia impossibile aprire il DB(protetto comunque da pasword) o
addirittura impossibile vederlo. Esempio: Inserire il Codice
dell'applicazione e il DB(qualunque) in un .EXE(Capito il concetto?) in modo
che all'apertura dell'applicazione SOLO l'applicazione sia in grado di
trovare il DB e di leggerlo... Spero di essere stato chiaro... Sò che è una
cosa particolare ... Che ne pensate?
Grazie.

 Perche' non crittare semplicemente il dB?
Per leggerlo l'applicazione deve decrittarlo, per decrittarlo
la 'chiave' deve essere scritta dentro l'applicazione stessa.
Se l'applicazione e' in Java si puo' reperire sia la chiave
che l'algoritmo usato con non troppa difficolta'.
Oltre al fatto che decrittare i dati rallenta il tutto.
Davide

 ha scritto nel messaggio
news:9p9v78$29ic$1...@stargate1.inet.it...

Sarebbe una buona idea. Ma dici che sia fattibile?
Ciao!

 
se la chiave e` hard-coded nell'applicazione, java o no, e tu hai a
disposizione una copia dell'applicazione, questa chiave la recuperi cmq
(al piu` decompilare da .class piuttosto che da .exe e` piu` facile).
Riguardo l'algoritmo, per quanto mi riguarda  potrebbe pure (anzi
dovrebbe) essere pubblico (a parte che java e` "intrinsecamente"
OpenSource, quindi usare un algoritmo segreto sarebbe un po`
difficile... ma su questo vedi dopo).
Dico questo perche` non mi e` chiaro cosa intendi, non perche` ci tenga
particolarmente ad avvalorare l'idea della cifratura. Voglio dire:
pure la crittografia ha i suoi limiti: la chiave potrebbe essere fornita
dall'utente in fase di startup, ma se l'utente ha la chiave, e
l'algoritmo e` noto -perche` e` famoso, o perche` l'ho ricavato
decompilando il codice-, tutta la crittografia a cosa servirebbe? Quindi
l'utente non deve conoscere la chiave, ma allo stesso tempo questa non
puo` essere hard-coded. Inoltre non si puo` supporre di recuperarla da
un canale sicuro (senno` ci faremmo passare direttamente i dati, quando
servono, tagliando la testa al toro e tenendoli al sicuro!), ne` tenerla
su disco che sarebbe cmq accessibile.
Qui cifrare questi dati mi sembra diventare sempre piu` improbabile...
Anche gli algortimi a chiave pubblica/privata prevedono -appunto- una
chiave che sia *privata*, ma se il tutto viaggia in un unico pacchetto,
ed e` a disposizione di chiunque si prenda la briga di esaminarlo,
inizia ad essere difficile che quella chiave rimanga privata per molto!
(se dico fesserie, ovviamente, correggetemi).
Nelle condizioni poste (applicazione e dati che viaggiano "insieme", con
il db come file su disco, senza un sistema dbms che operi controlli
sull'accesso, non dare neppure all'utente la chiave da utilizzare e da
inserire allo startup per decifrare il file) magari sara` anche l'unica
soluzione possibile... forse... ma a naso non lo credo (e piu` di cosi`
non mi spingo perche` contraddire Ugo Landini che ne sa` decisamente
piu` del sottoscritto non me la sento! ;) ... il fatto e` che l'intera
situazione non mi sembra abbastanza chiara! Diciamo che la
prima risposta che mi sarebbe venuta e`: no, quello che viene chiesto
non si puo` (ne`, se qualcuno ci tenesse a saperlo, per quanto mi
riguarda, si dovrebbe).
I cosiddetti "formati proprietari" (cifratura o no) mi sembra abbiano
sempre fatto quanto viene qui chiesto: nessuno conosce il formato del
file, se non l'applicazione che lo legge, quindi il file non e`
leggibile se non tramite l'applicazione stessa (faccio un esempio magari
non corretto al 100%: M$ Word). ...il problema si sposta quindi sulla
difficolta` di disassemblare il codice e recuperare l'algoritmo di
accesso al file (cosa piu` semplice se il programma e` un .class
piuttosto che un binario eseguibile).
Torniamo allora al "problema" dell'OpenSource (la parola problema e`
virgolettata in quanto x il sottoscritto di problema proprio non si
tratta! anzi -per partito preso- e` cosa buona e giusta, e non vedo
quali motivazioni possano portare alla creazione di un formato
proprietario). Ma io mi chiedo: i dati sono cosi` "sensibili"? E allora
perche` lasciarli "alla merce`" di eventuali occhi indiscreti? Che
significa che "non si puo` utilizzare il db in maniera separata"? Piu`
che altro mi interessano le motivazioni di questa scelta: e` per
mantenere una certa coerenza nei dati? E` perche` questi dati sono
segreti? Se lo fossero realmente questo problema non si sarebbe posto, e
si utilizzerebbero invece le ormai consolidate soluzioni. Ma ok, sia
come sia...
Avendo la necessita` cmq di adottare un sistema a chiave simmetrica (o
ho capito male io?) la questione si riduce alla solita domanda: come
faccio in modo che il mio codice non venga decompilato? Che e` di per
se` una FAQ...
Esiste una possibilita` di "nascondere" (stealth?) il codice java
piuttosto che i dati, che cmq sono li e non ho modo di sottrarre ad un
analisi di chi non dovrebbe vederli? voglio dire nascondere l'algoritmo,
che so`, un classloader personalizzato che carica un .class criptato, o
che modifica, caricandolo, un .class criptato, o che lo genera al
volo... bhe` insomma: roba "da virus" per intenderci... (che poi
diciamocelo, per quanto camaleontico, per quanto possa fare, basta
sempre un buon debug e una buona dose di pazienza...). La risposta e`:
no, o meglio "bho`!", nel senso che puoi rendere il processo di
disassemblamento tanto "oneroso" che alla fine per i piu` "non varra` la
pena" compierlo, ma non puoi impedire ad un chicchessia motivato di
perderci tempo e disassemblare cmq. Rimane alla tua capacita` e alla tua
fantasia, ma scusa se insisto, mi sembra una battaglia persa in
partenza.
Il suggerimento: "Usa un formato di database personalizzato (binario) e
scrivi il programma in C/C++" mi sembra un modo sbagliato di rispondere,
perche` se il programma e` C/C++ o Java, sempre e` disassemblabile (e se
il problema e` che l'assembler e` piu` difficile da leggere che il
bytecode, allora questi dati non erano cosi` interessanti come si
credeva e ci stiamo facendo problemi per niente, perche` nessuno
perderebbe cmq tempo a cercare di leggerli), e non aggiunge nessuna
sicurezza in piu` (anzi, come risposta mi sembra fuorviante).
Torniando all'esempio di Word (scritto in C/C++ con file binari in
formato proprietario) alla fine programmi in grado di leggere quei
documenti sono sorti lo stesso (e non mi riferisco a chi a pagato M$ per
avere la documentazione sul formato del file!), e i documenti si possono
"criptare" (proteggere con password) con una chiave mantenuta nel
documento stesso... eppure questa protezione non e` -ovviamente- sicura
e puo` essere "infranta" (o sbaglio?).
Tutto questo, ovviamente IMHO, ma penso che cercando con google
salterebbero fuori numerosi vecchi articoli piu` o meno sullo stesso
argomento, che darebbero piu` o meno la stessa risposta (che` poi e` un
modo come un altro per dire: scusatemi se mi sono dilungato su cose
trite e ritrite... ;).
Se invece sono io a non aver afferrato qualcosa, o se ho detto
"oscenita`", vi prego di correggermi.
-- 
Ciao,  |     Gott weiss ich will kein Engel sein
Matteo |                     -- Rammstein, Engel

Devo dire la verità: non ci ho capito niente.
A parte gli scherzi, leggendo gli ultimi msg mi sembra di capire che si
voglia implementare una forma di protezione "primitiva" di
un'applicazione lato client modello documenti pdf, word o access. Come
hai detto tu, inerentemente crackabili con un po' di pazienza, un
disassemblatore e del tempo da perdere.
Avevo capito tutt'altro, pensando come al solito "server-side", ed
immaginavo un client in un'applicazione multilivello di cui però il
codice per qualche motivo dovesse essere downloadabile in stile
"applet", ma dovesse risiedere nella stessa locazione del dB (e in
effetti mi chiedevo perchè).
comunque, mi sembra poco fattibile, oltre che una pessima scelta
architetturale. Per quanto riguara eventuale codice C/C++, non vedo
grosse differenze.
ciao

 in un unico pacchetto,
Calma, solo i dati viaggiano nel 'pacchetto', il meccanismo e'
cosi' costruito, io ho una chiave di 'criptatura' (pubblica)
ed una di 'decriptatura' (privata), la chiave di criptatura e'
pubblica e chiunque puo' saperla, se vuoi inviarmi un messaggio
usi la mia chiave pubblica per crittarlo, ed io usero' la mia
chiave (che solo io conosco) per decrittarlo.
Il meccanismo con cui queste chiavi sono costruite e' tale
per cui sapendo la chiave pubblica non c'e' modo (in tempo
umano utile) di risalire alla chiave privata.
Davide

 Davide
Non mi smebra molto applicabile al contesto che mi sembra di aver
capito, però. A meno che non abbia di nuovo capito male... perchè a
questo punto non ci spiegate meglio qual'è il problema, da un punto di
vista utente e non tecnico? (Ossia, COSA si vuole ottenere, e non COME?)
Se c'è una soluzione praticabile, qualcuno dei tanti la troverà!
ciao
uL

 perchè a questo punto non ci spiegate meglio qual'è il problema
Da quello che ho capito IO il problema e' il seguente: distribuire
una applicazione che utilizza dei dati (in un qualche formato),
in modo che, chiunque vogli accedere a tali dati debba farlo
necessariamente tramite l'applicazione stessa e non possa
accedere (o quasi) ai dati in altro modo.
Ecco perche' ritengo che la crittografia non sia una
soluzione valida.
Davide

 soluzione valida.
non ci sono soluzioni, che io sappia, se non parziali (che rendono il
compito più difficile ma non impossibile). Se a uno dai accesso fisico
al codice e ai dati, in qualche modo potrà sempre accedere alle info.
Una soluzione sarebbe quella di spostare i dati, e rientrare in più
consone architetture client server, ma evidentemente avranno le loro
ragioni per non farlo
Comunque, che c'azzecca con Java?
ciao
uL

 
ah, ok, ho capito cosa intendi, ma forse diciamo la stessa cosa e io non mi 
so' spiegare: il db e' insieme all'applicazione ok? quindi l'applicazione 
deve poterlo aggiornare, quindi criptare, quindi la chiave pubblica e' 
insieme all'applicazione (e tu dici: fa nulla, e io ci posso stare). Pero' 
quando tu dici "usi la mia chiave pubblica per crittare e io la mia chiave 
privata (che conosco solo io) per leggere" non ti seguo: a quanto ho capito 
stiamo trattando un caso in cui quel "tu" e "io" sono la stessa entita', e 
nella fattispecie e' l'applicazione, quindi il "chiave che conosco solo io" 
lo capisco, ma mi chiedo "conosco solo io, per quanto?" visto che *anche* 
quella chiave dovra' viaggiare insieme all'applicazione? (senno' i dati li 
scrivo ma non li leggo?).
Spero di essermi chiarito meglio (poi ovviamente non pretendo di aver 
ragione... anzi, ancora non sono sicuro affatto di aver afferrato il 
problema posto! ;-)
-- 
Ciao,
Matteo

 
-- 
Ciao,
Matteo

 wrote in message
9pc32h$hc8k2$1...@ID-18487.news.dfncis.de...

E' ESATTAMENTE QUESTO CHE INTENDEVO !!!!!!
Ma ribadisco che mi hanno posto questo quesito altre persone ... ma io come
voi ritengo che o si scende ad un livello basso di programmazione(e non sò
se sia comunque possibile raggiungere lo scopo) o in qualunque altro modo si
troverebbe la soluzione di "Crakkarlo" !!
Io sono scettico!
Che ne pensate?

disassemblatore e del tempo da perdere.
Vero. Puo' essere occasionalmente divertente, pero'.
Qualche tempo fa, munito di un'adeguata quantita' di tempo da 
perdere, usai (a tutt'altro scopo) un'archittettura composta da
un ClassLoader che implementava findClass() in modo nativo,
usando come sorgente un array definito nel codice C++ che
implementa il metodo nativo (in un'altra versione, ho usato
il registry).
Fin qui, niente di che. La cosa interessante era verificare se -
come la teoria su portable executable comanda - fosse possibile
applicare allo stesso tempo JNI per implementare metodo nativo e 
usarlo attraverso l'invocation api.
Quindi ho scritto il metodo nativo *e* un main() e linkato il tutto exe..
il main usa l'invocation api per creare una JVM, setta il classLoader,
e lancia la classe di partenza, che richiama il metodo nativo nello 
stesso eseguibile quando findClass viene eseguito..
Con un programmino a parte, ho creato un header che legge le classi
generate da javac e crea l'array usato dal classloader - e usato
quello per linkare il tutto (la cose e' gestita da un makefile).
Infine, un minimo tocco di criptazione sull'array e nel classloader - 
voila': un programma java, in formato "exe" in cui cose (tra cui 
resources, quindi "data") possono essere caricate dalla memoria 
e sono facilmente incapsulate nell'exe, ma in modo crittato
(cosi' non e' possibile usare direttamente un text finder per
leggere cose come "java/lang/String" etc nell'exe).
Ovviamente la cosa continua ad avere tutte le debolezze che dicevi,
ma e' uno schema vagamente inusuale - e forse in grado di sopportare 
attacchi superficiali. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 mail! ;-)
la capacità di sintesi è tipica di chi sa poco i dettagli e vuole
evitare pericolosi approfondimenti. La mia trasformazione in commerciale
sta pian piano divenendo sempre più evidente. Dilbert docet.
uL