Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/16 Enrico Franchi : > > On Nov 13, 2010, at 12:23 PM, lex mlist wrote: Scusate, partito per errore. Avevo gia' risposto. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Nov 13, 2010, at 12:23 PM, lex mlist wrote: > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? > oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/11/2010 20:01, Manlio Perillo ha scritto: > [...] > > La parte tecnicamente più complessa è verificare l'hash. > Una idea è farlo al momento in cui avviene l'import di un modulo; per > questo prova a dare una occhiata al modulo ihooks (non documentato, devi > leggere il codice). > > Oppure dai una occhiata a > http://www.python.org/dev/peps/pep-0302/ > Ecco un proof of concept, basato sul PEP 302: http://paste.pocoo.org/show/290997/ Vantaggi può essere implementato in C senza problemi; ti basta, dopo aver inizializzato l'interprete, aggiungere il tuo importer in sys.meta_path. L'importer lo puoi anche scrivere in C. Svantaggi = Per disabilitare la verifica delle firme, all'utente basta (a scelta): * modificare la funzione __import__ * rimuovere l'importer da sys.meta_path Ovviamente questo è un problema solo se permetti di importare moduli "untrusted"; ma il caricamento di un modulo untrusted fallirà comunque, con la politica di default (permetti solo l'import di moduli "noti" ed integri). L'unica precauzione è *disabilitare* gli hook eseguiti all'avvio dell'interprete, ad esempio il caricamento di site.py; questo perchè gli hook permettono di eseguire codice utente arbitrario *prima* che l'importer hook sia stato registrato (XXX check me). > [...] Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzfCAYACgkQscQJ24LbaUTGzwCfTgjnKrlpunVPmqNI+j8tFAY4 cMYAmwS+dJ+uLr+/Zgs+FnYzkd33vKdo =kXzb -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 20:01, Manlio Perillo ha scritto: > Si. Un semplice hash (SHA1, SHA e simili) oppure una firma tramite > cifratura a chiave pubblica. Tieni conto che è comunque suscettibile di attacchi, dato che devi > memorizzare le firme da qualche parte. > Se il core è in C, la manomissione è difficile ma non impossibile > (credo, non ho esperienze a riguardo). > Si magari si trova qualcosa di alternativo, comunque è veramente una cosa difficile, ma penso che usando opportune tecniche di obfuscation del codice si riesca a mettere in difficoltà qualsiasi strumento di disassembling, persino del calibro di Ida (ovviamente parliamo di opcode), se ti potrebbe interessare (in caso contrario puoi tranquillamente ignorare): opaque predicates, junky bytes, e altri piccoli trucchetti come punti di ritorno falsi, e altri giochini in assembly puro che permettono davvero di complicare il lavoro a chiunque (anche se in termini assolutistici non saprei dire in quale percentual, sebbene approssimativa al nullo, possa essere fattibile il reverse engineering anche con tali condizioni. Ovviamente l'intera lista comunque va a complicare il codice sorgente e non poco :s quindi direi non proprio nello stile di python :)) La parte tecnicamente più complessa è verificare l'hash. > Una idea è farlo al momento in cui avviene l'import di un modulo; per > questo prova a dare una occhiata al modulo ihooks (non documentato, devi > leggere il codice). > Si ci avevo pensato, ma non ero a conoscenza di questi strumenti. Io avevo pensato di modificare eventualmente l'interprete di CPython, aggiungendo in caso di import le relative funzioni per operare sul modulo da importare e poi ritornare al flusso standard del programma. La cosa è fattibile e per altro segna una svolta decisiva contro gli strumenti già pronti per la decompilazione dei file sorgenti criptati. Purtroppo (o non) si va a sacrificare l'interprete CPython standard perchè il programma deve essere eseguito dalla versione modificata dell'interprete. > > Oppure dai una occhiata a > http://www.python.org/dev/peps/pep-0302/ > > > Banale non lo è di certo, diciamo che la trovo comunque molto interessante, sinceramente pensavo ci fossero già buoni progetti in corso di realizzazione in questo senso, ma mi sembra che siano più i decompilatori pyc pyo che i compilatori per proteggere il programma. La cosa non è comunque banale; magari se trovi una soluzione condividila! > Ovviamente, sono in debito con la comunità per quanto state condividendo con me, e comunque anche per piacere personale, se troverò qualche soluzione sarete i primi ad essere informati :) > > Ciao Manlio > Ciao e buona serata! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/11/2010 17:23, lex mlist ha scritto: > > > Il giorno 13 novembre 2010 15:22, Manlio Perillo > mailto:manlio.peri...@gmail.com>> ha scritto: > > > In casi come questo, invece che criptare/nascondere potresti firmare > crittograficamente i vari moduli. > > Intendi che dovrei ricavare l'hash del file originale e compararlo con > il file che vad ad eseguire per accertarmi che non ci siano manomissioni? Si. Un semplice hash (SHA1, SHA e simili) oppure una firma tramite cifratura a chiave pubblica. > Se è questo, l'idea è geniale! Non ci avevo pensato mai prima d'ora. > Tieni conto che è comunque suscettibile di attacchi, dato che devi memorizzare le firme da qualche parte. Se il core è in C, la manomissione è difficile ma non impossibile (credo, non ho esperienze a riguardo). La parte tecnicamente più complessa è verificare l'hash. Una idea è farlo al momento in cui avviene l'import di un modulo; per questo prova a dare una occhiata al modulo ihooks (non documentato, devi leggere il codice). Oppure dai una occhiata a http://www.python.org/dev/peps/pep-0302/ La cosa non è comunque banale; magari se trovi una soluzione condividila! Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkze4HYACgkQscQJ24LbaUQS4gCgi1qVShPCaFuRqeAv4FrkbaaW HxcAoI9QJky0q19j/ff9WPBznozX3mse =X5yG -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 19:44, Raffaele Salmaso < raffaele.salm...@gmail.com> ha scritto: > On 11/12/2010 09:36 PM, lex mlist wrote: > > Esattamente che cosa intendi con "lua è molto più parco di risorse"? > che è pensato per girare con meno risorse: l'interprete pesa circa 100kb > Ti ringrazio per la precisazione, ora mi è più chiaro :) > no. > se la cosa ha senso, e solo tu come creatore del programma lo sai, > potresti fare una cosa del genere: quando hai bisogno di elaborare i > dati, li mandi al server che poi li restituisce al client. In pratica > esponi un'api rest. > Ovvio questo non ha sempre senso, dipende anche dal contesto del programma. > Si nota che non ho mai usato un approccio di questo tipo, non ci avevo pensato, ed in effetti è una bella soluzione. Non la userò per il progetto corrente perchè davvero non serve, ma la realizzerò cosi, a tempo perso per test e curiosità personale, che fonte di illuminazione questa MailingList :D > ok, allora ti basta questo > > http://bitbucket.org/ubernostrum/django-funserver/src/tip/funserver/management/commands/funserver.py > > :D > ahahahaha, buono spunto. ma è una cosa che funziona per davvero? non resisto, vado a provarlo :p ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On 11/12/2010 09:36 PM, lex mlist wrote: > Esattamente che cosa intendi con "lua è molto più parco di risorse"? che è pensato per girare con meno risorse: l'interprete pesa circa 100kb > Uhm, in termini pratici il programma a runtime dovrebbe prendere > attraverso la rete i file (.py) necessari e leggerli? no. se la cosa ha senso, e solo tu come creatore del programma lo sai, potresti fare una cosa del genere: quando hai bisogno di elaborare i dati, li mandi al server che poi li restituisce al client. In pratica esponi un'api rest. Ovvio questo non ha sempre senso, dipende anche dal contesto del programma. > Beh diciamo che il mio fine ultimo è quello di evitare i .py > modificabili con la criptazione per evitare che un semplice editor hex > possa permettere di leggerlo. Se poi l'utente ha voglia di farsi del > reverse engineering, studiarsi il flusso del programma e generare dei > file alternativi, beh la vedo dura, perchè davvero dovrebbe conoscere la > chiave di crittazione, dovrebbe sapere ogni file .py quali funzioni deve > esporre e tante altre variabili, e poi non mi preoccupo certo di quel > livello, alla fine il gioco non ne vale la candela. ok, allora ti basta questo http://bitbucket.org/ubernostrum/django-funserver/src/tip/funserver/management/commands/funserver.py :D -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 15:22, Manlio Perillo ha scritto: > > In casi come questo, invece che criptare/nascondere potresti firmare > crittograficamente i vari moduli. > Intendi che dovrei ricavare l'hash del file originale e compararlo con il file che vad ad eseguire per accertarmi che non ci siano manomissioni? Se è questo, l'idea è geniale! Non ci avevo pensato mai prima d'ora. > Ciao Manlio > Ciao Ciao Manlio, grazie mille =) Il giorno 13 novembre 2010 15:53, enrico franchi ha scritto: > Perche' so cosa vuole dire open source. Se ti leggi la definizione, e' > piuttosto banale vedere che hai errato Mi sembra piuttosto arrogante questa tua risposta, perdonami se te lo dico. Comunque beh, premettendo che non voglio assolutamente discutere ne scatenare flame di qualsiasi genere, penso che sia una definizione piuttosto personale di ciò che si intende correlato ad un software. Io sono cresciuto con la convinzione di non fidarmi di nessuno, e non assumo per oro ciò che mi dice il sito "opensource.org". Ti spiego perchè penso che sia una cosa molto personale (ma non per questo non la rispetto essendo opinione altrui): "no discrimination against persons or groups". Qui si parla tutto tranne che di software, mi sembra un aspetto molto più "umanistico" e rivolto al sociale, "license must be technology-neutral". Più che una definizione di quello che si può voler intendere per open source a me sembra una chiara linea guida da seguire se vuoi sottoporre una tua licenza al sito, poi ad ognuno il suo pensiero. Continuerò a tenermi per buona la mia convinzione di open source e rispetto la tua, al massimo se la cosa ti infastidisce in futuro cercherò di evitare open-source in favore di altri termini. Buona serata. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist : >> > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente >> > decompilabile, hai quindi una qualche alternativa? >> > oppure un programma python è destinato a rimanere open source!? >> >> Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non >> vuole dire essere open source. > > Uhm solitamente si tende a confondere open source con freeware, io non > intendo dicendo "open source" che deve essere gratuito, sia chiaro, intendo > proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè > ritieni che l'abbia usato impropriamente? Perche' so cosa vuole dire open source. Se ti leggi la definizione, e' piuttosto banale vedere che hai errato: Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: Il resto continua qui: http://www.opensource.org/osd.html -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist : >> Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non >> vuole dire essere open source. > > Uhm solitamente si tende a confondere open source con freeware, io non > intendo dicendo "open source" che deve essere gratuito, sia chiaro, intendo > proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè > ritieni che l'abbia usato impropriamente? Perche' so cosa vuole dire open source. La prima riga della definizione dice chiaramente che quello che tu chiamo open source non e' open source. """ Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: """ da: http://www.opensource.org/osd.html Poi se vuoi vedere i criteri, sono dentro la pagina. ;) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 12/11/2010 20:55, lex mlist ha scritto: > Sera a tutti. > > Pensavo di incorporare l'interprete di python in un mio progetto C, > visto che ho bisogno di permettere ad alcuni non-sviluppatori di > sviluppare facilmente le loro idee. > La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma > sebbene LUA lo conosco solo di vista, mi sembra che python sia più > completo, almeno in termini di package già pronti (se sbaglio vi prego > di correggermi). > > Avrei però la necessità di produrre per la release del programma un > sistema di "protezione" per evitare che l'utente possa modificare i > sorgenti di python e compromettere il flusso di esecuzione del > programma. In casi come questo, invece che criptare/nascondere potresti firmare crittograficamente i vari moduli. Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzenxUACgkQscQJ24LbaUQZjQCffPaNunLymscCJ6tG+olNh0Cd vQ8AoIZHaHHhRnjV0F4cjx73Q/wUfShe =f9XW -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 14:24, Enrico Franchi ha scritto: > > On Nov 13, 2010, at 12:23 PM, lex mlist wrote: > > > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? > > oppure un programma python è destinato a rimanere open source!? > > Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non > vuole dire essere open source. > Uhm solitamente si tende a confondere open source con freeware, io non intendo dicendo "open source" che deve essere gratuito, sia chiaro, intendo proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè ritieni che l'abbia usato impropriamente? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Nov 13, 2010, at 12:23 PM, lex mlist wrote: > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? > oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non vuole dire essere open source. -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 12:32, Paolo Bernardi ha scritto: > Ben detto! Un ragionamento di questo tipo (costi/benefici) è proprio > quello che devi fare. > =)) beh sono contento ogni tanto di far qualcosa nel senso giusto :D > > > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > > decompilabile, hai quindi una qualche alternativa? > > oppure un programma python è destinato a rimanere open source!? > > L'alternativa più sicura, come detto (mi pare) in questo thread, è avere > la parte più significativa del programma lato server. Tuttavia devi > sempre valutare i costi e i benefici della scelta; da quanto ho capito > nel tuo caso distribuire i file pyc, magari inclusi in un qualche > eseguibile, dll o quant'altro, è più che sufficiente. > > Si nel mio caso và più che bene la soluzione .pyc, però mi piace conoscere le cose sia per possibiltà future che per innata curiosità :) Tanto per, proverò comunque qualcosa di tipo client-server perchè mi interessa davvero molto. 2010/11/13 Massimiliano Pippi > Dai un'occhiata anche a questo vecchio thread > http://lists.python.it/pipermail/python/2009-June/006900.html > Grazie, me lo leggo subito :) > Ciao > Ciao, e grazie di nuovo a tutti! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist : > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? Dai un'occhiata anche a questo vecchio thread http://lists.python.it/pipermail/python/2009-June/006900.html Ciao -- M. http://twitter.com/maxpippi :: http://masci.wordpress.com http://www.pypg.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Sat, 2010-11-13 at 12:23 +0100, lex mlist wrote: > Beh, sperando che rimanga cosi... supporta solo python 2.5 e > python2.6, io mi stò già appoggiando a Python3 direttamente. > > Lo sò che non è una soluzione al problema unpyc che prima o dopo ci > arriverà (magari già è in sviluppo), comunque ripeto, non è che ci sia > da difendere chissà che in termini di proprietà intellettuale, una > eventuale decompilazione non espone a rischi di natura pecuniaria, ma > dovrebbe servire semplicemente da dissuasore per le modifiche, poi se > qualcuno ha voglia di farsi tutto quello, beh... Ben detto! Un ragionamento di questo tipo (costi/benefici) è proprio quello che devi fare. > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? > oppure un programma python è destinato a rimanere open source!? L'alternativa più sicura, come detto (mi pare) in questo thread, è avere la parte più significativa del programma lato server. Tuttavia devi sempre valutare i costi e i benefici della scelta; da quanto ho capito nel tuo caso distribuire i file pyc, magari inclusi in un qualche eseguibile, dll o quant'altro, è più che sufficiente. Paolo signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Beh, sperando che rimanga cosi... supporta solo python 2.5 e python2.6, io mi stò già appoggiando a Python3 direttamente. Lo sò che non è una soluzione al problema unpyc che prima o dopo ci arriverà (magari già è in sviluppo), comunque ripeto, non è che ci sia da difendere chissà che in termini di proprietà intellettuale, una eventuale decompilazione non espone a rischi di natura pecuniaria, ma dovrebbe servire semplicemente da dissuasore per le modifiche, poi se qualcuno ha voglia di farsi tutto quello, beh... Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Sat, 2010-11-13 at 01:04 +0100, Daniele Varrazzo wrote: > Basta che distribuisci solo i file .pyc invece dei .py: quelli sono > sufficienti ad eseguire il programma e vengono trovati dall'import. Questo > non è criptare, ma sembra quello che ti serve: è una protezione sufficiente > per evitare tampering da parte di chi non è *veramente* motivato e che > sappia leggere il bytecode. Direi che basta motivazione sufficiente a spendere 5 minuti per una ricerchina: http://sourceforge.net/projects/unpyc/ Se le pretese sono minori invece basta il modulo "dis": >>> def test(a): ... print a ... >>> test(23) 23 >>> import dis >>> dis.dis(test) 2 0 LOAD_FAST0 (a) 3 PRINT_ITEM 4 PRINT_NEWLINE 5 LOAD_CONST 0 (None) 8 RETURN_VALUE Quest'ultimo però in sola lettura, mentre con unpyc si può fare un intero ciclo decompila->modifica->ricompila. Paolo signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Grazie sia a Daniele che a Marco per le risposte :) Non mi devo preoccupare di hacking sui sorgenti, tanto gira e rigira un modo chi è determinato lo trova sempre, e poi dovrei fare anche l'obfuscation del codice macchina prodotto dalla compilazione in C, e non mi serve. Penso che l'idea di distribuire il solo bytecode sia sufficiente, l'importante è "tamponare" l'utente che vede il file di testo e pensa di guardarlo/modificarlo senza sapere quel che stà facendo. Ho già provato a includere l'interprete di Python e non mi sembra una cosa affatto difficile! Ci sono proprio tutti gli strumenti necessari, io mi stò studiando un po' l'architettura di python per interesse personale, ma trovo che anche senza saperne un tubo sia fattibile scrivere con le Python C/API. (e quindi immagino che Lua sia davvero semplice da incorporare) Il giorno 13 novembre 2010 01:04, Daniele Varrazzo ha scritto: > > PyInstaller fornisce anche supporto per creare un unico bundle che > contiene sia l'eseguibile che i .pyc delle librerie che servono (e i > .so/.dll). Probabilmente è facile modificarlo per fargli creare un bundle > con l'eseguibile che vuoi tu invece dell'interprete Python., magari lo fa > già... > > Ciao! > Gli darò un'occhiata, grazie per la segnalazione! Vediamo un po' cosa riesco a fare... questo Python mi piace sempre di più =)) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Fri, 12 Nov 2010 20:55:15 +0100, lex mlist wrote: > Sera a tutti. > > Pensavo di incorporare l'interprete di python in un mio progetto C, visto > che ho bisogno di permettere ad alcuni non-sviluppatori di sviluppare > facilmente le loro idee. > La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma > sebbene LUA lo conosco solo di vista, mi sembra che python sia più > completo, > almeno in termini di package già pronti (se sbaglio vi prego di > correggermi). Sì. Forse Lua è più facile da embeddare (Python non è troppo difficile comunque). Ma hai il vantaggio di una libreria molto più sostanziosa, come hai visto. > Avrei però la necessità di produrre per la release del programma un > sistema > di "protezione" per evitare che l'utente possa modificare i sorgenti di > python e compromettere il flusso di esecuzione del programma. Basta che distribuisci solo i file .pyc invece dei .py: quelli sono sufficienti ad eseguire il programma e vengono trovati dall'import. Questo non è criptare, ma sembra quello che ti serve: è una protezione sufficiente per evitare tampering da parte di chi non è *veramente* motivato e che sappia leggere il bytecode. PyInstaller fornisce anche supporto per creare un unico bundle che contiene sia l'eseguibile che i .pyc delle librerie che servono (e i .so/.dll). Probabilmente è facile modificarlo per fargli creare un bundle con l'eseguibile che vuoi tu invece dell'interprete Python., magari lo fa già... Ciao! -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Fri, Nov 12, 2010 at 08:55:15PM +0100, lex mlist wrote: > Sera a tutti. > > Pensavo di incorporare l'interprete di python in un mio progetto C, visto > che ho bisogno di permettere ad alcuni non-sviluppatori di sviluppare > facilmente le loro idee. > La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma > sebbene LUA lo conosco solo di vista, mi sembra che python sia più completo, > almeno in termini di package già pronti (se sbaglio vi prego di > correggermi). Non conosco lua, ma so' che lo scopo principale, o uno dei principali, è proprio quello di funzionare da interprete embedded, quindi dipende dai tuoi bisogni. Python sicuramente ha una grande community e qua la quantità di codice è sterminata. Inoltre conoscere bene i propri strumenti è importare, trovo. > Avrei però la necessità di produrre per la release del programma un sistema > di "protezione" per evitare che l'utente possa modificare i sorgenti di > python e compromettere il flusso di esecuzione del programma. Probabilmente > la risposta sarebbe "non dovresti usare python", ma scrivere un interprete > porta via troppo tempo e sinceramente non mi và di usare altri linguaggi > visto che quasi sempre sono per uno specifico scopo e non general purpose. > Pensavo di crittare il file con Rijndael e di scrivere quindi su un file > binario, e a runtime decrittare, e passare il file in memoria "in chiaro" > all'interpete. Allora, di fatto anche i binari sono modificabili, quindi se uno vuol pestarsi i piedi da solo un modo lo trova sempre, inoltre il bytecode python è distribuibile e binario. Potresti distribuire quello, ma ho l'impressione che lo scopo finale non sia proprio quello di evitare pasticci da parte degli utenti, ma non sono affari miei. > Come sistema pensavo potesse andare (se avete esperienze e volete > condividerle sono tutt'orecchie), ma poi ho pensato che se uno di questi > sorgenti include un'altro modulo, sorgerebbero problemi perchè python > cercerebbe un python ".py" in chiaro e non lo troverebbe. Quale file python dovrebbe cercare, uno facente parte la libreria standard oppure consideri il caso in cui l'estenzione sia composta da più di un file? Credo che il caso in esame sia il secondo (dopotutto è possibile includere la libreria standard nell'estenzione stessa). In questa ottica prendi in esame il modulo ``zipimport`` (e il pep 302[1]), costruisci un wrapper che nel momento in cui va' a leggere il file prima lo decripta. Lavorare con gli archivi zip (o gli egg) credo che semplificherà un po' le cose. [1] http://www.python.org/dev/peps/pep-0302/ Comunque in linea di massima si tratta sempre di costruire un import hook, ma dove salverai la chiave per decifrare i file? Se lo scopo è scoraggiare un utente a modificare un sorgente python allora la soluzione migliore è distribuire il bytecode dei sorgenti, se lo scopo è tenere nascosto il codice sorgente dai curiosi, questo è solo un placebo. m. -- Dalle virtù che si esigono in un domestico, l'Eccellenza Vostra conosce molti padroni degni d'esser servitori? -- Pierre Augustin Caron de Beaumarchais ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 12 novembre 2010 21:11, Raffaele Salmaso < raffaele.salm...@gmail.com> ha scritto: > Ni, py ha molte più librerie pronte, lua è molto più parco di risorse e > molto più semplice da includere in un programma c. Dipende dagli usi > (molti giochi usano lua e non python per implementare la logica) > Si infatti sono a conoscenza del fatto che molti videogame usino lua, e non solo i videogame, per questo l'avevo messo tra le possibiltà. Esattamente che cosa intendi con "lua è molto più parco di risorse"? > Sinceramente. Non distribuirlo. > > Fallo client-server, sposta la logica in rete. > Uhm, in termini pratici il programma a runtime dovrebbe prendere attraverso la rete i file (.py) necessari e leggerli? > Se invece non vuoi/puoi, se vuoi semplicemente evitare che un appena > appena intraprendere hakaro giochi con i tuoi file, prendili e compilali > dentro un file c, e falli caricare dall'interprete. > Beh diciamo che il mio fine ultimo è quello di evitare i .py modificabili con la criptazione per evitare che un semplice editor hex possa permettere di leggerlo. Se poi l'utente ha voglia di farsi del reverse engineering, studiarsi il flusso del programma e generare dei file alternativi, beh la vedo dura, perchè davvero dovrebbe conoscere la chiave di crittazione, dovrebbe sapere ogni file .py quali funzioni deve esporre e tante altre variabili, e poi non mi preoccupo certo di quel livello, alla fine il gioco non ne vale la candela. Grazie mille per la tua risposta, ciao! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On 11/12/2010 08:55 PM, lex mlist wrote: > Sera a tutti. > > Pensavo di incorporare l'interprete di python in un mio progetto C, > visto che ho bisogno di permettere ad alcuni non-sviluppatori di > sviluppare facilmente le loro idee. > La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma > sebbene LUA lo conosco solo di vista, mi sembra che python sia più > completo, almeno in termini di package già pronti (se sbaglio vi prego > di correggermi). Ni, py ha molte più librerie pronte, lua è molto più parco di risorse e molto più semplice da includere in un programma c. Dipende dagli usi (molti giochi usano lua e non python per implementare la logica) > > Avrei però la necessità di produrre per la release del programma un > sistema di "protezione" per evitare che l'utente possa modificare i > sorgenti di python e compromettere il flusso di esecuzione del > programma. ... > Avete da proporre qualche soluzione/workaround per questo problema? Vuoi essere sicuro che nessuno che abbia voglia di decifrare il programma per farne quello che vuole? Semplice! Non distribuire il programma! Sinceramente. Non distribuirlo. Fallo client-server, sposta la logica in rete. Se invece non vuoi/puoi, se vuoi semplicemente evitare che un appena appena intraprendere hakaro giochi con i tuoi file, prendili e compilali dentro un file c, e falli caricare dall'interprete. -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
