View Full Version : [C#] Protezione della licenza
Salve,
nel software che sto sviluppando vorrei poter inserire una data di scadenza della licenza d'uso. Preciso subuto che il software e' un gestionale aziendale, quindi non esiste il pericolo che l'utente possa cambiare la data di sistema per fregarmi.
Mi sono venute in mente varie idee pero' alla fine il problema ricade sempre su un fatto: la data di scadenza deve essere memorizzata da qualche parte, e quindi un utente smaliziato (se non smanettone) potrebbe trovarla e modificarla a piacimento.
Nella mia testolina ho pensato ad alcuni scenari/soluzioni:
1) il file (poniamo anche un semplice xml) in cui e' contenuta la data di scadenza potrebbe essere criptato con una chiave simmetrica (AES o DES). All'avvio l'applicazione dovrebbe essere in grado di decriptare il file, ottenendo la data di scadenza in chiaro, confrontarla con quella di sistema ed eventualmente bloccare l'esecuzione se la licenza e' scaduta.
Il problema e' che il software deve mantenere memorizzata la chiave simmetrica per decriptare la data di scadenza. Dunque il problema si sposta su "come memorizzare in maniera sicura la chiave simmetrica". Un cane che si morde la coda.
2) la data di scadenza potrebbe essere processata da una funzione hash sicura (SHA1 o MD5) e quindi sul file di licenza avrei un "digest" della data di scadenza reale, cioe' una stringa senza alcun senso e dalla quale l'utente smanettone non potrebbe ricavare alcuna informazione. Tuttavia gli algoritmi hash non sono poi cosi' tanti e quindi basterebbe fare alcune prove per trovare quello giusto (quello utilizzato dal mio software), generare manualmente l'hash di una data di scadenza a piacimento e sostituirla nel file della licenza.
C'e' anche un secondo problema in questo scenario. Mentre nel primo decriptando la data di scadenza otterrei effettivamente una data di confrontare con quella attuale di sistema, in questo caso, avendo a che fare con dei digest, non potrei eseguire un test di comparazione del tipo "maggiore o uguale", ma solo di uguaglianza. Cioe' dovrei effettuare l'hash della data odierna di sistema e confrontarlo con l'hash della data di scadenza memorizzata. Il confronto e' quindi una semplice uguaglianza e quando l'uguaglianza e' verificata (il giorno della scadenza della licenza) si dovrebbe attivare un flag che da quel momento in poi impedirebbe l'esecuzione del software... beh ma allora il problema e': dove memorizzo in maniera sicura questo flag? Ancora il cane che si morde la coda!!!
Qualcuno ha esperienza in merito?
Consigli?
Aiuti?
Elemosina?
Grazie mille
visto che fai l'assunzione molto forte e molto comoda che l'utente non possa cambiare la data di sistema allora leggi quella e fai un confronto con una data hard-coded.
beh ma allora il problema e': dove memorizzo in maniera sicura questo flag? Ancora il cane che si morde la coda!!! non memorizzare alcun flag: ad ogni avvio leggi la data di sistema e fai il confronto, se il programma é scaduto non avviarlo (o peggio ancora: cancella qualche sua parte essenziale :D).
nel software che sto sviluppando vorrei poter inserire una data di scadenza della licenza d'uso. Preciso subuto che il software e' un gestionale aziendale, quindi non esiste il pericolo che l'utente possa cambiare la data di sistema per fregarmi.
Mi sono venute in mente varie idee pero' alla fine il problema ricade sempre su un fatto: la data di scadenza deve essere memorizzata da qualche parte, e quindi un utente smaliziato (se non smanettone) potrebbe trovarla e modificarla a piacimento.
Non è detto.
Puoi ad esempio creare un file ( che può essere il risultato della serializzazione di una classe... ) che contiene la data di scadenza criptata.
Le chiavi di creazione/lettura delle stringhe criptate le lasci hard-coded nel codice, non c'è motivo di registrarle da altre parti.
Ovviamente se l'utente modifica un solo carattere del file serializzato, lo corrompe o lo elimina, questo produce errori in fase di lettura e/o decriptazione dei valori criptati, all'apertura dell'applicazione. Errori che puoi intercettare ( Try Catch ) e nella cui gestione, chiudere in faccia l'applicazione allo smanettone di turno...
E' chiaro che chiunque manometta quel file dovrà per forza rivolgersi a te, per far ripartire l'applicazione.
Non so se era la tecnica a cui avevi già pensato. Con me ha funzionato... ;)
Tutto ciò ovviamente se il tuo scopo è creare "files-licenza" esterni e indipendenti dall'exe, che puoi
ad esempio ridistribuire successivamente come "estensioni del periodo di prova" ecc...
Se invece vuoi il controllo data più semplice in assoluto, sono d'accordo con la soluzione citata da 71104.
Mmm, ma scusate una cosa, non e' una pratica "erronea" inserire password e dati sensibili in maniera hard-coded?
In questo caso in pratica si tratta di inserire una data di scadenza hard-coded, ma in un certo senso, dovendo regolare l'esecuziona autorizzata del programma, va vista come se fosse una password.
Non c'e' il rischio che l'utente smanettone possa facilmente decompilare l'eseguibile, trovare la data di scadenza, modificarla a piacimento e ricompilare il tutto a casa sua?
Del resto si tratta di C#, cioe' codice interpretato, quindi quando compra il prodotto riceve degli eseguibili che sono compilati in un codice intermedio (IL mi pare si chiami).
Sbaglio?
Se l'utente è smanettone al punto da decompilare/ricompilare e conosce pure il C#, beh, a sto punto non c'è password che tenga, ti elimina le tue routine di controllo licenza e buonanotte...
Se sei su questi livelli :
1. Alza il prezzo e distribuisci senza limitazioni e/o fornisci i sorgenti...
2. Usa DotFuscator o cerca un Sw serio ( roba che di solito è a pagamento ) di offuscamento del sorgente.
Se scegli la 2. e riesci a trovare un buon tool freeware, fammelo sapere. ;)
Se l'utente e' smanettone e non inserisci una risorsa esterna (macchina remota certificatrice) puoi fare quello che vuoi, puoi pensare quello che vuoi, ma il sistema potra' essere rotto.
E l'esistenza di una risorsa esterna e' comunque condizione necessaria, ma non sufficiente per la robustezza.
Puo' diventare sufficiente (abbastanza sufficiente, diciamo 6--) quando parti di elaborazione sono remote, e che quindi il programma locale non sia tutto cio' che serve per funzionare.
Delegando ad un server remoto sia l'autenticazione che l'esecuzione di qualcosa, poiche' il server remoto si "suppone" inviolabile (da qui il 6--) anche a fronte di smanettoni, allora lo smanettone a casa sua non ha modo di bypassare i limiti imposti dalle licenze.
Se l'utente è smanettone al punto da decompilare/ricompilare e conosce pure il C#, beh, a sto punto non c'è password che tenga, ti elimina le tue routine di controllo licenza e buonanotte...
Se sei su questi livelli :
1. Alza il prezzo e distribuisci senza limitazioni e/o fornisci i sorgenti...
2. Usa DotFuscator o cerca un Sw serio ( roba che di solito è a pagamento ) di offuscamento del sorgente.
Se scegli la 2. e riesci a trovare un buon tool freeware, fammelo sapere. ;)
Diciamo che l'utente medio non e' certo uno smanettone, anzi non e' neppure un programmatore fortunatamente.
Ho improntato il discorso in maniera un po' piu' ampia in effetti, in modo che magari potesse tornare utile anche ad altri utenti.
Dunque la tua idea MarcoGG sarebbe quella di creare una classe serializzabile ad-hoc per gestire la licenza (magari meglio una dll separata).
Questa classe quindi, nei metodi di serializzazione/deserializzazione deve utilizzare una chiave di criptazione hard-coded, accettando il rischio che decompilando il codice l'utente possa scoprire questa chiave.
Accettato questo rischio mi viene in mente un unico problema: se ho N clienti, dovro' ricompilare la classe/dll per la gestione delle licenze N volte, perche' per ciascuna devo creare una nuova chiave.
Accettato questo rischio mi viene in mente un unico problema: se ho N clienti, dovro' ricompilare la classe/dll per la gestione delle licenze N volte, perche' per ciascuna devo creare una nuova chiave.
No. La classe serializzabile "ClassLicenza" è dentro l'applicazione stessa. Che serve una DLL esterna ? Se ti decompilano il Progetto, ti decompilano anche la DLL. Inutile complicare le cose.
In questo caso sarà una semplice Public Class di cui esiste sempre e solo un'istanza, creata all'avvio dell'Applicazione...
Poi avrai una classe, chiamiamola "ClassCriptatore", che avrà essenzialmente 2 metodi : Cripta / DeCripta...
Se ad esempio usi DESCryptoServiceProvider, avrai bisogno di definire le 2 chiavi "Key" e "IV". Bene, queste 2 chiavi saranno hard-coded nella classe Criptatore, ovviamente NON nel file licenza, che invece è la serializzazione della classe ClassLicenza.
Questa cosa della serializzazione te l'ho buttata lì così, perchè ti ho riportato un esempio di qualcosa che ho realizzato io ( nel mio caso c'erano diversi valori criptati da mettere nello stesso file licenza, per quello ho preferito farmi una classe e serializzarla ). Ovvio che se il tuo file licenza ha solo 1 valore, la data di scadenza, puoi metterla in un .txt qualunque, senza serializzare nulla e finita lì, ma il valore contenuto sarà cmq criptato.
Se distribuisci N Client, avranno tutti le stesse chiavi di Criptazione, ma potranno avere date di scadenza diverse, senza bisogno di compilarli N volte.
tomminno
15-04-2009, 12:17
Non è detto.
Puoi ad esempio creare un file ( che può essere il risultato della serializzazione di una classe... ) che contiene la data di scadenza criptata.
Le chiavi di creazione/lettura delle stringhe criptate le lasci hard-coded nel codice, non c'è motivo di registrarle da altre parti.
Dimentichi che un programma .NET è praticamente in chiaro. Un utente smaliziato non fa certo fatica a trovare la chiave che usi per cifrare i dati.
Anzi con reflector puoi pure tranquillamente inserire codice all'interno di un assembly senza troppi problemi.
Dimentichi che un programma .NET è praticamente in chiaro. Un utente smaliziato non fa certo fatica a trovare la chiave che usi per cifrare i dati.
Anzi con reflector puoi pure tranquillamente inserire codice all'interno di un assembly senza troppi problemi.
Non ho dimenticato proprio nulla. Ho semplicemente consigliato una tecnica che in presenza di utenti "normali", per mia esperienza personale ha dato i suoi frutti.
Ovvio che, come giustamente segnalato da gugoXX, ci sono livelli di sicurezza ben superiori, ma che guarda caso richiederanno assai spesso tempi e costi superiori...
La mia è una soluzione che si implementa abbastanza facilmente, e non ho mai conosciuto una segretaria o un ragioniere capace di bucarla... :D
tomminno
15-04-2009, 12:39
No. La classe serializzabile "ClassLicenza" è dentro l'applicazione stessa. Che serve una DLL esterna ?
E come fai a stabilire la data di scadenza?
O la data di scadenza è hard coded e quindi devi ricompilare il progetto per allungare la scadenza, oppure generi la data a partire dall'installazione (tipo 60 giorni da essa).
Se lo generi dall'installazione però hai il problema che ad ogni installazione la data viene resettata rendendo di fatto inutile il controllo. Dovresti "marcare" la macchina alla prima installazione così che eventuali successive installazioni riconoscano che il software è già stato installato, come fanno molti applicativi che vanno a scrivere qualche file in qualche cartella o chiave di registro sperduta.
E come fai a stabilire la data di scadenza?
O la data di scadenza è hard coded e quindi devi ricompilare il progetto per allungare la scadenza, oppure generi la data a partire dall'installazione (tipo 60 giorni da essa).
Se lo generi dall'installazione però hai il problema che ad ogni installazione la data viene resettata rendendo di fatto inutile il controllo. Dovresti "marcare" la macchina alla prima installazione così che eventuali successive installazioni riconoscano che il software è già stato installato, come fanno molti applicativi che vanno a scrivere qualche file in qualche cartella o chiave di registro sperduta.
Niente di tutto questo.
La data di scadenza è in una stringa criptata nel File Licenza.
1. Ho una piccola Applicazione separata ( che ovviamente non distribuirò al cliente :D ) che genera i vari File Licenza con una data desiderata.
2. Nell'Applicazione leggo la data dal File Licenza, se la lettura/decriptazione va a buon fine, la data letta è valida, e passo al controllo con la data di sistema ( e in questo caso, come dichiarato, si è certi che l'utente non ha modo di modificarla da Bios o da S.O. ... ).
3. Qualsiasi errore di lettura/decriptazione dal File Licenza viene intercettato e produce il blocco dell'Applicazione.
4. L'eventuale Installer NON genera alcun File Licenza, che invece distribuisco separatamente... ;)
qwerty86
15-04-2009, 13:30
Usare una chiavetta Hardware?
banryu79
15-04-2009, 13:31
Usare una chiavetta Hardware?
Con associato costo e inoltre costringere l'utente a tenere occupata una porta usb per usare un'applicativo gestionale? (Tenendo conto appunto della situazione contingente, cioè che l'utente medio non sa manco dove mettere le mani per trovare il file di licenza, figurarsi a decrittarlo...)
Beh in effetti il mio pensiero attualmente ricalca quello di MarcoGG. Si tratta di un sistema di sicurezza certamente naif, inadatto nel caso in cui l'utente possa essere anche un programmatore esperto, ma in questo caso non c'e' questo pericolo.
E' ovvio che una soluzione simile implica la previa generazione del file di licenza da parte del vendor (cioe' io in questo caso) con la data di scadenza desiderata... ovviamente con il massimo automatismo possibile.
L'unica pecca rimane se c'e' la necessita' di generare non solo date di scadenza diverse, ma si voglia anche utilizzare una chiave di cifratura per tale data diversa per ogni utente.
Essendo tale chiave necessariamente hard-coded in questo scenario, occorre ricompilare tutto ogni volta che si distribuisce un nuovo file di licenza.
Per questo motivo attualmente pensavo di utilizzare una dll esterna che svolga il compito di controllare la licenza decrifrando il file in cui e' serializzata/memorizzata. In questo modo ogni volta devo solo ricompilare la dll con la nuova chiave di cifratura hard-coded, generare il file di licenza con la data criptata con la nuova chiave, e distribuire al cliente entrambi gli elementi (dll e file).
No?
Sulle chiavi hardware sono d'accordo con banryu79... costosissime tanto che sono utilizzate solo da sistemi software proprietari molto complessi e costosi gia' di per se'.
banryu79
15-04-2009, 15:11
Sulle chiavi hardware sono d'accordo con banryu79... costosissime tanto che sono utilizzate solo da sistemi software proprietari molto complessi e costosi gia' di per se'.
Noi per un certo applicativo (settore CAD/CAM) usiamo chiavi hardware di una nota marca: a volte è capitato che i driver per Windows forniti con la chiave non fossero proprio "perfetti" oppure che l'eseguibile "criptato" venisse riconosciuto come potenziale software malevolo dalle euristiche di alcuni antivirus :doh:
Per questo motivo attualmente pensavo di utilizzare una dll esterna che svolga il compito di controllare la licenza decrifrando il file in cui e' serializzata/memorizzata. In questo modo ogni volta devo solo ricompilare la dll con la nuova chiave di cifratura hard-coded, generare il file di licenza con la data criptata con la nuova chiave, e distribuire al cliente entrambi gli elementi (dll e file).
No?
Infatti, era l'ovvia modifica al mio metodo nel caso volessi anche chiavi di codifica diverse per ognuno dei Client. ;)
Occhio poi a non fare casino con Applicazioni / DLL-Chiavi / Files-Licenza ! :D
!k-0t1c!
15-04-2009, 18:02
Non vorrei rovinare la giornata a nessuno, ma consiglio fortemente di considerare i seguenti punti:
è COMPLETAMENTE inutile usare qualunque forma di crittografia se i controlli nel codice si risolvono in un semplice if dove la condizione è una chiamata a un metodo (incluso l'accesso al valore di una proprietà), in quanto basterà reflector e una patch di pochissimi bytes a vanificare tutto lo sforzo per una corretta implementazione del controllo crittografico della licenza. A questo punto tanto vale usare uno xor, tanto chiunque analizzi il codice ci impiegherà lo stesso tempo
è spesso inutile usare chiavi hardware per proteggere programmi .NET, poiché basta effettuare il dump dei metodi compilati in runtime da parte del compilatore JIT per ricostruire l'assembly originale, e il costosissimo sistema di licenza è del tutto neutralizzato
Il mio consiglio è di usare dei software che consentano un'efficace protezione dell'assembly a livello di codice .NET con particolare attenzione alla qualita della flow obfuscation. Per chi ha un budget tale da poterselo permettere, il meglio sul mercato è rappresentato senza dubbio da DNGuard HVM, mentre chi volesse ripiegare su soluzioni meno costose può usare MaxToCode.
Inutile affidarsi a soluzioni quali SmartAssembly, .NET Reactor o peggio ancora DotFuscator perché esistono unpackers in grado di rimuovere la maggior parte dell'offuscamento e di ridurre di fatto gli effetti negativi alla sola perdita di certi metadati.
Infine non ha senso affidarsi al noto Themida/WinLicense per i prodotti .NET poiché i prodotti di casa oreans non alterano minimamente il codice CIL né sono efficaci ad impedirne il dump in runtime.
Non vorrei rovinare la giornata a nessuno, ma consiglio fortemente di considerare i seguenti punti:
è COMPLETAMENTE inutile usare qualunque forma di crittografia se i controlli nel codice si risolvono in un semplice if dove la condizione è una chiamata a un metodo (incluso l'accesso al valore di una proprietà), in quanto basterà reflector e una patch di pochissimi bytes a vanificare tutto lo sforzo per una corretta implementazione del controllo crittografico della licenza. A questo punto tanto vale usare uno xor, tanto chiunque analizzi il codice ci impiegherà lo stesso tempo
è spesso inutile usare chiavi hardware per proteggere programmi .NET, poiché basta effettuare il dump dei metodi compilati in runtime da parte del compilatore JIT per ricostruire l'assembly originale, e il costosissimo sistema di licenza è del tutto neutralizzato
Il mio consiglio è di usare dei software che consentano un'efficace protezione dell'assembly a livello di codice .NET con particolare attenzione alla qualita della flow obfuscation. Per chi ha un budget tale da poterselo permettere, il meglio sul mercato è rappresentato senza dubbio da DNGuard HVM, mentre chi volesse ripiegare su soluzioni meno costose può usare MaxToCode.
Inutile affidarsi a soluzioni quali SmartAssembly, .NET Reactor o peggio ancora DotFuscator perché esistono unpackers in grado di rimuovere la maggior parte dell'offuscamento e di ridurre di fatto gli effetti negativi alla sola perdita di certi metadati.
Infine non ha senso affidarsi al noto Themida/WinLicense per i prodotti .NET poiché i prodotti di casa oreans non alterano minimamente il codice CIL né sono efficaci ad impedirne il dump in runtime.
A me no di certo. :D
Ho consigliato anch'io l'offuscamento.
DotFuscator l'ho nominato perchè già "impacchettato" in .Net, ma sinceramente non è che mi abbia proprio esaltato.
Interessante cmq il tuo intervento. ;)
Vorrei sapere se conosci anche dotNet Protector di PV Logiciels, se l'hai provato e che giudizio ne dai.
_Claudio
16-04-2009, 00:21
Puoi sempre fare un controllo molto sofisticato sulle date di modifica dei file presenti nella cartella del programma e nelle cartelle adiacenti in modo da verificare eventuali "furbate" e modifiche al file con la data crittata, come verifica aggiuntiva.
Poi io ti consiglierei di usare uno strumento di convalida con crittografia asimmetrica dove calcoli una chiave di decodifica (hash) e il relativo file di convalida crittato con un algoritmo che garantisca l'autenticità, quando distribuisci le versioni trial ogni volta calcoli la chiave (hash) e il file crittato per quella specifica copia che conterrà la data di rilascio con un algoritmo e una chiave solo a te noti.
In questo modo chiunque modifichi il file non riuscirà più a decrittarlo a meno di ripristinarlo come in originale, tantomeno si riesce a modificare la chiave pubblica (e relativamente anche il file) che è una specie di hash del file calcolata con un algoritmo non noto a chiave privata non nota.
qwerty86
16-04-2009, 08:57
Con associato costo e inoltre costringere l'utente a tenere occupata una porta usb per usare un'applicativo gestionale? (Tenendo conto appunto della situazione contingente, cioè che l'utente medio non sa manco dove mettere le mani per trovare il file di licenza, figurarsi a decrittarlo...)
Ne ho viste di alcune che costano 19€ e poi ad oggi tenere occupata una porta usb non è di certo una cosa tragica.
_Claudio
16-04-2009, 09:44
Mioddio come si scrive contorto di notte con la stanchezza che avanza...
Quello che volevo dire è di usare un algoritmo di crittografia asimmetrico che garantisca l'autenticità, ossia per crittare si usa la chiave privata (con supporto dell'hash, digest, generato in base al file) mentre per decrittare si usa la chiave pubblica, l'hash calcolato.
Si l'uso di RSA per autenticare i file di licenza distribuiti e' una cosa a cui stiamo pensando in azienda.
Per ora siamo in fase di prototipazione comunque... quindi molte strade rimarranno aperte ancora per un po'.
Sulle chiavi hardware a sto punto non so che dire. Ho sempre saputo che avevano costi ragguardevoli (relativamente al costo del prodotto per cui vengono usate). Certo che magari per un gestionale piuttosto complesso e quindi costoso, 20 euro in piu' o in meno non cambiano molto per il cliente.
Vedremo.
_Claudio
17-04-2009, 09:22
Si l'uso di RSA per autenticare i file di licenza distribuiti e' una cosa a cui stiamo pensando in azienda.
Per ora siamo in fase di prototipazione comunque... quindi molte strade rimarranno aperte ancora per un po'.
Sulle chiavi hardware a sto punto non so che dire. Ho sempre saputo che avevano costi ragguardevoli (relativamente al costo del prodotto per cui vengono usate). Certo che magari per un gestionale piuttosto complesso e quindi costoso, 20 euro in piu' o in meno non cambiano molto per il cliente.
Vedremo.
Le chiavi hardware non vengono più usate dagli anni '90... difatti non se ne sente quasi più parlare se non in sporadici casi in cui vengono usati RFID.
Questo proprio perchè la crittografia software ha fatto passi da gigante.
banryu79
17-04-2009, 09:53
Le chiavi hardware non vengono più usate dagli anni '90... difatti non se ne sente quasi più parlare se non in sporadici casi in cui vengono usati RFID.
Questo proprio perchè la crittografia software ha fatto passi da gigante.
Fidati che nel settore CAD/CAM per gli applicativi a bordo macchina (applicativo a corredo di una macchina CN, che gira su pc) sono ancora usate.
_Claudio
17-04-2009, 09:57
Fidati che nel settore CAD/CAM per gli applicativi a bordo macchina (applicativo a corredo di una macchina CN, che gira su pc) sono ancora usate.
Esatto, nel sistemi CAD sono ancora usate, ma non hanno più una diffusione come negli anni 80-90 e tantomeno hanno avuto il successo sperato nella lotta contro la pirateria... forse perchè spesso venivano emulate a livello software...
qwerty86
17-04-2009, 10:00
Parlavo comunque di uso di chiavi Hardware per software come dire "amatoriali"
_Claudio
17-04-2009, 10:05
Parlavo comunque di uso di chiavi Hardware per software come dire "amatoriali"
Non ne vale la pena hanno costi di progettazione e produzione relativamente esosi per software amatoriali grauiti o a basso costo.
prova con activelock è free
http://activelocksoftware.com/
!k-0t1c!
19-04-2009, 11:03
A me no di certo. :D
Ho consigliato anch'io l'offuscamento.
DotFuscator l'ho nominato perchè già "impacchettato" in .Net, ma sinceramente non è che mi abbia proprio esaltato.
Interessante cmq il tuo intervento. ;)
Vorrei sapere se conosci anche dotNet Protector di PV Logiciels, se l'hai provato e che giudizio ne dai.
Ho avuto occasione di provare dotNet Protector ma non mi ha esaltato. Usando un po' di astuzia si ottiene il CIL in maniera non troppo complessa.
Diciamo che come complessità paragonerei la v5 a MaxToCode. Buona, ma ben sotto a DNGuard HVM, che è il più noioso e avvicina sostanzialmente il tempo di cracking a quello di un protettore per codice nativo di media complessità. Quello che mi piacerebbe vedere sarebbe un compilatore da EXE managed a EXE unmanaged standalone con una implementazione from scratch del sistema di metadati, del garbage collector e della reflection, ma è uno sforzo titanico che credo nessuno si azzarderà mai a fare :p Certo quello più Themida o VMProtect renderebbe il .NET decisamente più difficile da reversare :cool:
_Claudio
19-04-2009, 11:13
Ho avuto occasione di provare dotNet Protector ma non mi ha esaltato. Usando un po' di astuzia si ottiene il CIL in maniera non troppo complessa.
Diciamo che come complessità paragonerei la v5 a MaxToCode. Buona, ma ben sotto a DNGuard HVM, che è il più noioso e avvicina sostanzialmente il tempo di cracking a quello di un protettore per codice nativo di media complessità. Quello che mi piacerebbe vedere sarebbe un compilatore da EXE managed a EXE unmanaged standalone con una implementazione from scratch del sistema di metadati, del garbage collector e della reflection, ma è uno sforzo titanico che credo nessuno si azzarderà mai a fare :p Certo quello più Themida o VMProtect renderebbe il .NET decisamente più difficile da reversare :cool:
Ne esistesse uno ben fatto ed efficiente eviterei di studiarmi e usare le wx... :muro: :muro:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.