Esiste un buon offuscatore per il codice Perl?

Question

Qualcuno conosce un buon oscuratore di codice per Perl?Mi è stato chiesto di esaminare l'opzione di offuscare il codice prima di rilasciarlo a un cliente.So che il codice offuscato può ancora essere decodificato, ma non è questa la nostra preoccupazione principale.

Alcuni clienti stanno apportando piccole modifiche al codice sorgente che forniamo loro e questo ci fa venire gli incubi quando qualcosa va storto e dobbiamo risolverlo, o quando rilasciamo una patch che non funziona con ciò che hanno cambiato.Quindi l'intenzione è solo quella di fare in modo che sia difficile per loro apportare le proprie modifiche al codice (non dovrebbero farlo comunque).

Answer 1

Ho già percorso questa strada ed è un vero incubo quando devi lavorare su codice "offuscato" perché aumenta enormemente i costi cercando di eseguire il debug di un problema sul server del client quando tu, lo sviluppatore, non puoi leggere il codice .Ti ritrovi con "deoffuscatori", copiando il "codice reale" sul server del client o una serie di altri problemi che diventano semplicemente una vera seccatura da mantenere.

Capisco da dove vieni, ma sembra che la direzione abbia un problema e si aspettano che tu implementi la soluzione scelta piuttosto che capire quale sia la soluzione corretta.

In questo caso, sembra che si tratti davvero di una questione di licenza o contrattuale.Lascia che abbiano il codice open source, ma rendilo parte della licenza in modo che qualsiasi modifica inviata debba tornare a te ed essere approvata.Quando distribuisci le patch, controlla le somme md5 di tutto il codice e se non corrisponde a quanto previsto, sono in violazione della licenza e verranno addebitate di conseguenza (e dovrebbe essere una tariffa molto, molto più alta).(Ricordo una società che ci ha concesso il codice open source, ma ha chiarito che se avessimo cambiato qualcosa, avremmo "comprato" il codice per $ 25.000 e non sarebbero più stati responsabili per eventuali correzioni di bug o aggiornamenti a meno che non avessimo acquistato un nuova licenza).

Answer 2

Non.Basta, non farlo.

Scrivi nel contratto (o modifica il contratto se necessario) che non sei responsabile delle modifiche apportate al software.Se stanno incasinando il tuo codice e poi si aspettano che tu lo aggiusti, hai problemi con il client che non verranno risolti offuscando il codice.E se lo offuschi e incontrano un problema reale, buona fortuna nel convincerli a riportare accuratamente il numero di riga, ecc., nella segnalazione del bug.

Answer 3

Per favore, non farlo.Se non vuoi che le persone alterino il tuo codice Perl, mettilo sotto una licenza appropriata e imponila.Se le persone modificano il tuo codice quando la tua licenza dice che non dovrebbero farlo, allora non è un tuo problema se i tuoi aggiornamenti non funzionano più con la loro installazione.

Vedere La risposta di perlfaq3 a "Come posso nascondere i sorgenti dei miei programmi Perl?" per ulteriori dettagli.

Answer 4

Sembrerebbe che il tuo problema principale sia che i client modifichino il codice, il che ti rende difficile supportarlo.Ti suggerirei di chiedere i checksum (md5, sha, ecc.) dei loro file quando vengono da te per supporto e allo stesso modo controllare i checksum dei file durante l'applicazione delle patch.Ad esempio, puoi chiedere al client di fornire l'output di un programma fornito che esegue l'installazione ed esegue il checksum di tutti i file.

Alla fine hanno il codice, quindi possono farci quello che vogliono.La cosa migliore che puoi fare è applicare le tue licenze e assicurarti di supportare solo codice non modificato.

Answer 5

In questo caso offuscare è l’approccio sbagliato.

Quando rilasci il codice al client dovresti conservare una copia del codice che gli invii (su disco o preferibilmente nel tuo controllo di versione come tag/ramo).

Quindi, se il tuo cliente apporta modifiche, puoi confrontare il codice in suo possesso con il codice che gli hai inviato e individuare facilmente le modifiche.Dopotutto, se sentono il bisogno di apportare modifiche, c'è un problema da qualche parte e dovresti risolverlo nel codebase principale.

Answer 6

Un'altra alternativa per convertire il tuo programma in un binario è quella gratuita PAR-Packer strumento acceso CPAN.Esistono anche filtri per l'offuscamento del codice, anche se, come altri hanno già detto, forse è più un problema che un vantaggio.

Answer 7

Sono d'accordo con i suggerimenti precedenti.

Tuttavia, se lo desideri davvero, puoi esaminare PAR e/o Filtro::Cripto Moduli CPAN.Puoi anche usarli insieme.

Ho usato quest'ultimo (Filter::Crypto) come una forma di "protezione" davvero leggera quando spedivamo il nostro prodotto su supporto ottico.Non ti "protegge", ma fermerà il 90% delle persone che vogliono modificare i tuoi file sorgente.

Answer 8

Questo non è un suggerimento serio, comunque dai un'occhiata Acme::Buffy.

Almeno ti illuminerà la giornata!

Answer 9

Un'alternativa all'offuscamento è convertire il tuo script in un binario usando qualcosa di simile Kit di sviluppo Perl di ActiveState.

Answer 10

Utilizzo un sistema operativo Windows e utilizzo perl2exe di IndigoSTAR.È improbabile che il file .EXE risultante venga modificato sul posto.

Come altri hanno già detto, "come posso offuscarlo" è la domanda sbagliata."Come posso impedire al cliente di modificare il codice" è quello giusto.

Answer 11

Il checksum e le idee contrattuali sono utili per prevenire i "problemi" che descrivi, ma se il costo per te è la difficoltà di implementare aggiornamenti e correzioni di bug, come fanno i tuoi clienti ad apportare modifiche che non superano i requisiti? suite di test completa?Se sono in grado di apportare queste modifiche (o almeno di apportare una modifica che esprima ciò che vogliono che il codice faccia), perché non rendere semplicemente semplice/automatizzata l'apertura di un ticket di supporto e il caricamento della patch?Il cliente ha sempre ragione su ciò che il cliente vuole (potrebbero non avere la minima idea di come farlo "nel modo giusto", ma è per questo che ti pagano.)

Un motivo migliore per desiderare un offuscatore sarebbe l'implementazione di desktop sul mercato di massa in cui non si hanno tutti i clienti con un contratto permanente.In tal caso, qualcosa Piace PAR: tutto ciò che racchiude la logica di crittografia/offuscamento in un binario compilato è la strada da percorrere.

Answer 12

Come hanno già detto diverse persone:non.

È praticamente implicito, data la natura dell'interprete Perl, che qualsiasi cosa tu faccia per offuscare Perl deve essere annullabile prima che Perl ci metta le mani sopra, il che significa che devi lasciare lo script/binario di deoffuscamento in giro dove l'interprete (e quindi il tuo cliente) può trovarlo :)

Risolvi il vero problema:checksum e/o una licenza opportunamente formulata.E il personale di supporto addestrato a dire "l'hai cambiato?"stiamo invocando la clausola 34b della nostra licenza, e saranno $ X.000 prima di toccarla'....

Inoltre, leggi perché-dovrei-usare-l'offuscamento per una risposta più generale.

Answer 13

Li inviterei semplicemente nel mio albero SVN sul loro ramo in modo che possano fornire modifiche e io possa vederli e integrare le loro modifiche nel mio albero di sviluppo.

Non combatterlo, abbraccialo.

Answer 14

Come dice Ovidio, è un problema contrattuale, sociale.Se cambiano il codice invalidano la garanzia.Carica loro molto per risolvere il problema, ma allo stesso tempo fornisci loro un canale in cui possano suggerire modifiche.Inoltre, guarda cosa vogliono cambiare e, se puoi, inserisci quella parte della configurazione.Hanno qualcosa che vogliono fare e finché non lo soddisfi, continueranno a cercare di aggirarti.

In Padroneggiare Perl, parlo un po' di come sconfiggere gli offuscatori.Anche se fai cose come creare nomi di variabili senza senso e simili, moduli come B::Dipartito E B::Deoffuscamento, insieme a strumenti Perl come Perl::Ordinato, rendi abbastanza facile per la persona esperta e motivata ottenere la tua fonte.Non devi preoccuparti così tanto degli inconsapevoli e degli immotivati ​​perché comunque non sanno cosa fare con il codice.

Quando ne parlo con i manager, eseguiamo la normale analisi costi-benefici.C'è ogni genere di cose in te Potevo farlo, ma non molto costa meno del beneficio che ottieni.

Buona fortuna,

Answer 15

Un altro suggerimento non serio è usare Acme::Candeggina, renderà il tuo codice molto pulito ;-)