Come viene annullata un'applicazione PHP e come evitarla

1

Come tanti altri, sono stato vittima di avere un mio prodotto PHP annullato e messo a disposizione su Internet per il download gratuito. Lo scopo di questa domanda è cercare di rendere più difficile per qualcuno di annullare un'intera applicazione PHP comprendendo come è fatto e altre prospettive su come evitarlo il più possibile.

Quello che sto cercando di sapere è come viene annullata un'applicazione PHP con le seguenti strategie di protezione. Che cosa pensa e fa un attaccante quando vuole annullare un'applicazione:

  • codice offuscato
  • attivazione della chiave di licenza (consegna del resto del file codice una volta che la licenza è stata convalidata e completata)
  • convalida interna persistente: convalida dei file generati automaticamente, al termine dell'installazione dell'app, contenente i dati crittografati del dominio approvato e nascosti in più sottodirectory con nomi file ed estensioni diversi
  • convalida esterna periodica: convalide periodiche CURL al mio server (nascoste in più parti del nucleo offuscato dell'applicazione) con tutti i nomi di funzioni comuni utilizzati per comunicare con server esterni anche offuscati con codifiche diverse

So che è impossibile creare un'applicazione da pubblicare sul pubblico per essere a prova di attacco, ma c'è qualche possibilità di costruirla per essere così difficile da annullare che il lavoro per l'attaccante non è redditizio?

    
posta CIRCLE 08.06.2016 - 16:09
fonte

2 risposte

5

Si sta ipotizzando che un utente malintenzionato interromperebbe i metodi di protezione in un'applicazione solo per ragioni finanziarie. Questo non è accurato - per molto tempo, il cracking di questo tipo di software è stato fatto per i complimenti, per mostrare abilità, o solo per divertimento. Aggiungere più livelli di protezione può anche invogliare più persone a provare, dal momento che ci sono ulteriori complimenti nella rottura di una difficile sfida - proprio come le persone tendono ad essere più impressionate da imprese difficili, come l'Everest, di quelle banali, come salire le scale , anche quando l'azione sottostante è molto simile (e sì, so che scalare l'Everest è difficile, ma sto facendo un punto!).

Come per diversi tipi di protezione:

  • codice offuscato - se voglio solo eseguirlo, non importa. Una volta che ho una copia del codice, posso usarlo senza bisogno di sapere cosa dice in realtà. Se voglio modificare l'applicazione, rende le cose più difficili, dal momento che dovrei deobfuscarlo, capire quali informazioni dai nomi delle variabili e delle funzioni mancavano, quindi apportare le mie modifiche. Puoi sempre deobfuscare il codice, con uno sforzo sufficiente.
  • attivazione della chiave di licenza - se ho accesso al codice completo, ad esempio, irrompendo in un server di una società che lo ha pagato, non importa. Puoi rintracciare la cui copia è stata rubata o condivisa, ma è una cosa legale, piuttosto che una questione tecnica.
  • convalida interna persistente - ah, ora stiamo arrivando a cose divertenti. O posso modificare tutti i punti in cui hai incorporato il nome del dominio dopo aver decodificato la crittografia, il che sembra un grosso sforzo, oppure posso trovare dove chiami le routine di verifica e cambiarle per tornare che è sempre valido o semplicemente rimuovi quel codice.
  • convalida esterna periodica - questa interrompe alcuni potenziali usi del codice. Ad esempio, è ragionevole che una regola del firewall prevenga le connessioni in uscita su un server che si affaccia su Internet per l'utente del server Web. Significa che se qualcuno si intromette, è difficile per loro utilizzare il mio server per inviare spam, ad esempio. Il tuo software non funzionerà su di esso però. Per decifrare, deoffuscare e rimuovere il codice, o fornire il mio livello di convalida, in modo che gli utenti possano aggiungere il nome del server al proprio file host e ottenere una risposta da localhost che dice "valido" in qualsiasi forma si richieda.
risposta data 08.06.2016 - 16:58
fonte
2

In risposta alla tua seconda domanda

is there any chance to build it to be so hard to null that the job for the attacker doesn't payoff?

Suppongo che per "annullamento" intendi crackato o alterato in qualche modo che permetta loro di usarlo liberamente.

L'unico modo veramente efficace è di non dare tutto il codice / i binari. Rielaborare la tua applicazione in modo che sia client-server e spedisca solo il client (anche se il client è davvero un server per altre cose). Identifica le funzionalità di base, estraile su un server che gestisci e vendi solo l'accesso ad esso. In questo modo, il peggio che possono fare è piratare un client inutile (beh, a meno che il tuo server non venga hackerato).

Se ciò non è auspicabile, gli schemi DRM come Denuvo sembrano essere finora un buon deterrente.

    
risposta data 08.06.2016 - 16:58
fonte

Leggi altre domande sui tag