Concetto di codifica del codice sorgente PHP

Vediamo. Una volta che il server delle chiavi invia la chiave di decrittografia, l'hacker può monitorare l'attività di rete per recuperare la chiave e usarla per decrittografare il codice sorgente. Da questo momento, può fare tutto ciò che vuole, specialmente:

• Modificalo in modo che invii i checksum che stai aspettando, e non i veri e propri checksum dei file,

• Sostituisci la parte che contatta il server delle chiavi o semplicemente rimuovila per evitare il controllo,

• Pubblica su reti P2P il codice sorgente decrittografato con la parte di controllo chiave rimossa.

D'altra parte, una parte di gli utenti legittimi del tuo prodotto probabilmente preferiranno utilizzare il prodotto dei tuoi concorrenti , perché:

1. Scopriranno che l'avvio della tua app è lento. Il contatto con il server delle chiavi remoto richiede tempo, che può essere accettato o meno dagli utenti finali.

2. La decrittografia richiede troppo tempo, il che può sprecare troppe risorse sui server. I prodotti della concorrenza potrebbero raggiungere un ingombro della CPU molto migliore se non aggiungono questo tipo di complessità.

3. Il bando per IP renderà ulteriori problemi. La maggior parte degli utenti dispone di IP dinamici, il che significa che un divieto interesserà la persona interessata solo per un periodo di tempo molto limitato (ad esempio un giorno), quindi impedisce ad altre persone di accedere al prodotto. Allo stesso modo, vietare l'intera azienda o un punto wifi è piuttosto spiacevole in termini di marketing.

4. Non accetteranno di affidarsi a un prodotto fragile (a meno che non lavori in un'azienda molto grande che garantisce che il prodotto verrà mantenuto per i successivi 5, 10 o 15 anni). Non avere il codice sorgente significa che:

   • Se la tua azienda smette di mantenerla, i tuoi clienti utilizzeranno un prodotto obsoleto che potrebbe contenere noti ma bug non corretti .

   • Se un cliente vuole modificarlo, non ha altra scelta che pagarti (spesso molto, a causa del monopolio) per fare il resto.

5. Non accetteranno di fare affidamento su un prodotto che può contenere malware . Se sei un'azienda nota con un'ottima reputazione, questo non è un problema. Se sei una startup o non hai una reputazione consolidata, alcuni clienti non installerebbero la tua app a causa del rischio di codice dannoso. Ciò è particolarmente importante sui server che sono spesso più protetti dei PC desktop nelle aziende.

Se hai effettivamente inventato qualcosa che dovrebbe essere protetto ( e molto probabilmente, non hai ), l'unico il modo in cui puoi proteggerlo è spostare il codice sensibile nei server che possiedi , quindi fornire un'API per accedere alle funzionalità dall'esterno. Non appena rendi il codice, non importa quanto sia protetto, può essere decodificato; in caso contrario, non sarebbe possibile eseguirlo.

Se l'unico obiettivo è avere una versione di prova, è sufficiente ospitarla sui propri server. I potenziali clienti potranno provarlo e, se sono interessati, acquistano il prodotto. Naturalmente, al fine di convincere anche gli amministratori di sistema, dovresti anche fornire informazioni molto dettagliate sul modo in cui la tua app deve essere distribuita e ospitata.

Successivamente, quando il tuo prodotto avrà successo, potresti considerare l'evoluzione della tua offerta, fornendo:

• La demo a tempo limitato ospitata sul tuo server,

• La sottoscrizione pay-per-month in cui il prodotto è ancora ospitato sul tuo server. Molteplici varianti di abbonamenti possono essere destinate a singoli individui, piccole aziende e aziende di medie dimensioni. Per piccole entità, il prodotto potrebbe essere fuori uso per un anno o per un altro lungo periodo di tempo (o per sempre).

• La soluzione più costosa in cui il cliente distribuisce l'app sui propri server. Questa soluzione potrebbe essere indirizzata a grandi aziende.

Con questo modello (utilizzato da molte startup), la crittografia del codice sorgente diventa per lo più irrilevante. Le grandi aziende non tenteranno di scaricare il tuo prodotto da una rete P2P, a causa di tutti i criteri di conformità che impediscono loro di utilizzare prodotti senza licenza.

Hai scritto in un commento alla risposta di MainMa che :

I thought about this for a simple trial period of maybe a couple of days and after the purchase has been made, deliver the decrypted version. The main goal is to deliver the product without delivering the source (at first) so that the user can see if he likes the product (or if it's useful) .

che per coincidenza trasforma la tua domanda in un problema XY . In altre parole, stai cercando di risolvere un problema, e invece di chiedere del problema che vuoi risolvere, chiedi della tua soluzione proposta. (Che può funzionare, se la soluzione proposta è effettivamente buona e hai solo bisogno di alcuni dettagli minori raddrizzati.)

Se quanto sopra è la tua ragione per farlo, allora dimentica di offuscare il codice sorgente. aggiungerà un'enorme quantità di complessità e rischi, con molti aspetti negativi come spiegato da MainMa e nessun vantaggio reale e tangibile per nessuno.

Invece, ospita una copia della tua che i potenziali clienti possono accedere e sperimentare. Ripristina un database vuoto ogni mezzanotte o qualcosa del genere, chiarisci a tutti gli utenti che qualsiasi i dati che inseriscono sono accessibili pubblicamente e saranno cancellati e pubblicheranno in modo visibile un link e il nome utente e la password per accedere alla demo.

Se i dati devono essere preservati per una quantità non trascurabile di tempo affinché l'utente sia in grado di determinare se l'applicazione soddisfa le loro esigenze (che non suona basandosi sul fatto che si parla di alcuni giorni), offri ai potenziali clienti la possibilità di configurare un'installazione di prova sul tuo server che viene automaticamente cancellata dopo un periodo di tempo ragionevole e breve.

Inoltre, questa soluzione darà agli utenti la possibilità di valutare facilmente se un aggiornamento fornisce loro un valore aggiuntivo prima dell'aggiornamento. Se l'aggiornamento è in qualche modo di disturbo, o se un downgrade non è banale, solo questo può essere un vantaggio.

E tutto questo a costo di avere un hosting web aggiuntivo, un processo cron e la memorizzazione di un'istantanea del database e / o alcune copie aggiuntive dei contenuti del database predefinito.