In che modo è protetto il software principale? [duplicare]

Scrivo software da molti anni e 2 decenni fa pensavo seguendo le linee che stai descrivendo e provando a capire come proteggere il mio software.

Per rispondere alla tua domanda: la protezione del software viene eseguita tramite crittografia e offuscamento proprio come la protezione dei dati. Le carenze, come hai descritto, sono che molto codice è molto difficile da proteggere e di solito è relativamente facile da decodificare.

Un modo per proteggere il tuo codice (dalla decompilazione) è di non rilasciarne mai una versione compilata e di eseguirla sempre da un server e i tuoi consumatori usano un client come un browser. Ciò tuttavia non ti protegge dal reverse engineering.

La difesa, secondo me, non è sprecare cicli (tempo / denaro) cercando di proteggere il tuo codice, ma piuttosto di innovare continuamente e aggiungere più valore al tuo prodotto nel tempo. Se un concorrente si è impossessato del tuo codice e ha richiesto (diciamo) un mese per decompilarlo e rilasciato un prodotto concorrente, dovresti essere un passo avanti con la tua prossima funzione o il prossimo prodotto per quel momento.

Trascorrere tempo e sforzi per bloccare la concorrenza mantenendo tutto segreto sarebbe meglio spendere incoraggiando la tua squadra ad essere innovativa e stare al passo con la concorrenza.

Secondo me, prima di chiedere come, dovresti chiederti se è necessario e / o ne vale la pena.

Penso che in molti casi non lo è.

Le persone sono (comprensibilmente) piuttosto paranoiche su altre persone che rubano il loro codez. Ma questa paura è razionale? Penso che di solito non lo è.

La tua app è davvero così eccezionale che qualcuno si prenderà il disturbo di decodificarlo? (Scusa, ma probabilmente no - come hai detto, sei uno sviluppatore nuovo e anche se non lo fossi ... ci sono molti sviluppatori di grande talento là fuori)

Il reverse engineering (al punto di ottenere codice sorgente utilizzabile e completo) sarebbe molto più semplice della semplice scrittura di un prodotto concorrente? (Molto probabilmente no)

In che modo è possibile ritenere che un simile programma sarebbe? (Probabilmente non molto)

Ci sono molte, molte cose di cui preoccuparsi prima di doversi preoccupare della protezione da parte degli artisti della truffa. In primo luogo, è necessario ottenere sul mercato un prodotto valido e attraente.

Per completezza, vorrei aggiungere che ci sono ovviamente buone ragioni per provare a proteggere alcuni tipi di software, o certe parti di molti software comuni, ma in generale, penso che cercare di proteggere il tuo codice sia per lo più uno spreco di tempo speso meglio per migliorare il prodotto.

A meno che il tuo software non sia alquanto subdolo internamente, sono certo che qualsiasi programmatore competente potrebbe replicare il comportamento dei tuoi programmi più o meno nello stesso momento in cui hai iniziato a scriverlo!

Quindi spendere un sacco di sforzi per mantenere il tuo codice segreto di solito è solo perdere tempo e fatica.

Alcuni algoritmi devono essere mantenuti segreti, per esempio l'algoritmo del page rank di Google è utile solo se gli scammer non sanno come promuovere una pagina spazzatura nella parte superiore della ricerca, o, un sistema di trading automatizzato che potrebbe essere manipolato da un concorrente. Ma questa situazione è piuttosto rara.

Giganti del software come SAP e ORACLE vendono molti pacchetti in base al fatto che tutti sanno esattamente cosa fanno; "Compilare GAAP" o "Incarna le migliori pratiche commerciali" in materia di marketing.

Ma non scoraggiarti, il test è almeno il 50% dello sforzo di programmazione e probabilmente aggiunge l'80% del valore; non è possibile decodificare una serie di test decente.

Se il software è nella macchina client, tutto ciò che puoi fare è ritardare l'inevitabile.

L'offuscamento e la crittografia rendono solo più difficile il compito di smontare. Se stai seguendo questa strada, probabilmente vorrai raggiungere un punto in cui decideranno "ok, fanculo, implementerò da zero perché ci vorrà meno tempo". Anche se, in pratica, è molto difficile (se possibile) raggiungere quel punto ... come altri hanno sottolineato, la maggior parte delle aziende sindaci non raggiunge questo punto.

D'altra parte, forse gli attaccanti non vogliono creare un prodotto alternativo! (Se quello che volevano era competere con te, allora tutto quello che c'è da fare è stare davanti alla concorrenza e smettere di preoccuparsi .)

In pratica c'è stata una vera e propria corsa agli armamenti nelle tecniche per modare e prevenire il modding del software. Ciò accade quando si decide di aggiungere protezione da copie indesiderate aggiungendo restrizioni al software. Se lo fai, all'improvviso avrai un gruppo di persone disposte a modificare il tuo prodotto per rimuovere quelle restrizioni senza pagare. Questo è ancora più comune di una terza parte che replica il tuo software, lo vedi dai giochi (ad esempio le patch "No CD") all'attivazione illegale dei sistemi operativi ( tosse Windows tosse ), software antivirus e altri.

Come detto, questa è una corsa agli armamenti. Tu dici: Anti-A, e loro inventano A + 1, tu dici Anti-A + Infinity e loro dicono B. È come un gioco di whack-a-mole: troveranno sempre un modo per continuare a spuntare fino a quando non ottieni stanco. Puoi anche pensarlo come un gioco di Tetris, stai cercando di costruire un muro perfetto senza buchi ... ma sappiamo tutti che c'è solo un modo per finire il gioco di Tetris (Almeno il Tetris originale): tu perdere.

Quindi, dal momento che vogliono modificare il software, creano patch o software patcher che chiamiamo "cracks".

Le cose possono iniziare a sembrare spaventose quando si iniziano a fare crepe. È normale che le società antivirus aggiungano al proprio database quelle versioni false dei programmi. Come contromisura coloro che distribuiscono questi software suggeriscono di disabilitare l'antivirus ... risultato: un gruppo di persone che eseguono software con l'antivirus disabilitato. Non saprai mai quando coglieranno l'occasione per inserire software dannosi in quel posto ...

E sì, ti colpisce. Significa meno vendite per te. Da una parte perché le persone usano le crepe e dall'altra perché le crepe danneggiano la tua immagine.

Poiché tutto questo problema deriva dall'esecuzione del codice nel client, un approccio comune è quello di guidare l'attivazione delle copie attraverso un server. Ma il cliente deve ricordare se è attivato ...

Dal punto di vista dell'attaccante la maggior parte dei casi assomiglia a un ramo "se" che dice:

   If (Software is Activated) do this Else do that.

Tutto quello che devono fare per sbloccare la tua applicazione è iniettare del codice per annullare la verifica. Quindi, cose come testare l'hash dei tuoi file per vedere se sono originali non funzioneranno.

Naturalmente questo può essere mitigato, dai un'occhiata a Hash -End-Decrypt e tecniche simili che potrebbero effettivamente dare mal di testa all'attaccante.

Quindi ... Vuoi una soluzione definitiva? Qualcosa di sicuro al 100%?

Ci sono due opzioni:

1. Non eseguire mai il software nel computer del cliente. Esegui solo sui tuoi server.

2. Fornisci il software come gratuito e open source. È possibile aggiungere una buona licenza legale e sarà facile dimostrare che qualsiasi altro software contiene una copia. Guadagna denaro da qualcos'altro, come:

   2.1. Vendita di installazione e supporto.

   2.2. Prodotti aggiuntivi.

   2.3. Remote "Cloud" esecuzione servizi di calcolo.

Tutto punta a Hardware e Cloud. non è raro che tutte le società sindaci si "spostino sul cloud".

Questa domanda dipende molto da chi sono i tuoi clienti.

Se vendi business to business, dovrebbe essere abbastanza facile impedire ai concorrenti di ottenere il codice compilato. Il modo più semplice per affrontare questo tipo di situazione è con una strong formulazione contrattuale. Con IBM Cognos (il principale prodotto di business intelligence come SAP), non viene nemmeno utilizzata una chiave di licenza. Fanno cose come l'offuscamento del codice ma, per lo più, proteggono il loro prodotto con livelli.

Questo è ovviamente più difficile con situazioni di tipo business to person. Probabilmente non puoi controllare chi ha accesso al software. Riguardo a questo, gli altri poster hanno alcune buone soluzioni.

Ogni volta che vuoi proteggere qualcosa devi pensare a quali discussioni vuoi difendere.

1. Hai segreti che vuoi proteggere?

2. Vuoi proteggere dalla pirateria del software da privato individui?

3. Vuoi proteggere un'azienda dalla concorrenza.

Per quanto riguarda 1. và, se hai dei segreti, pubblica il software che li gestisce sul tuo server e fai SaaS.

Per quanto riguarda 2. va, probabilmente non vale la pena investire in protezione poiché la protezione di tutto il software si rompe.

Per quanto riguarda 3. il pericolo non è il reverse engineering diretto attraverso il codice ma qualcuno che riprogramma la tua idea. Se vuoi proteggerti, dovresti percorrere la strada costosa e comprare i brevetti.