2009-04-30 18 views
14

Come proteggere le DLL del mio progetto in modo che non possano essere referenziate e utilizzate da altre persone?Come proteggere le DLL?

Grazie

risposta

20

La risposta breve è che oltre le cose ovvie, non c'è molto che tu possa fare.

Le cose ovvie che si potrebbe desiderare di prendere in considerazione (o meno in ordine di difficoltà crescente e decrescente di plausibilità) includono:

  • collegamento statico quindi non c'è DLL di attaccare.
  • Elimina tutti i simboli.
  • Utilizzare un file .DEF e una libreria di importazione per includere solo le esportazioni anonime conosciute solo dai relativi ID di esportazione.
  • Conservare la DLL in una risorsa ed esporla nel file system (con un nome adeguatamente oscuro, forse anche generato in fase di esecuzione) solo durante l'esecuzione.
  • Nasconde tutte le funzioni reali dietro un metodo factory che scambia un segreto (migliore, prova di conoscenza di un segreto) per una tabella di puntatori di funzioni ai metodi reali.
  • Utilizzare tecniche di anti-debug prese in prestito dal mondo del malware per impedire il reverse engineering. (Si noti che probabilmente otterrete falsi positivi dagli strumenti AV.)

Indipendentemente da ciò, un utente sufficientemente determinato può ancora capire come usarlo. Un disassemblatore decente fornirà rapidamente tutte le informazioni necessarie.

Si noti che se la DLL è in realtà un oggetto COM o, peggio ancora, un assieme CLR, vi è un'enorme quantità di informazioni sul tipo di runtime che non è possibile rimuovere senza interrompere l'uso previsto.

EDIT: Dal momento che hai rimarcato implicare che C# e .NET sono l'ambiente piuttosto che un puro Win32 DLL scritta in C, poi ho davvero dovrebbe rivedere quanto sopra per "Non si può, ma .. . "

C'è stato un mercato per gli strumenti di offuscamento per un lungo periodo di tempo per occuparsi di ambienti in cui la consegna di fonti compilabili è obbligatoria, ma non si vuole fornire una fonte utile. Ci sono prodotti C# che giocano in quel mercato, e sembra che almeno uno abbia suonato.

Poiché caricare un assembly richiede così tanto sforzo dal framework, è probabile che ci siano bit di autorizzazione che esercitano un certo controllo per fornitori onesti e consumatori di Assemblee. Non ho visto alcuna discussione sulla reale sicurezza fornita da questi metodi e semplicemente non so quanto siano efficaci contro un determinato attacco.

Molto dipenderà dal vostro caso d'uso. Se vuoi semplicemente prevenire l'uso casuale, puoi probabilmente trovare una soluzione che funzioni per te. Se vuoi proteggere preziosi segreti commerciali dal reverse engineering e dal riutilizzo, potresti non essere così felice.

3

Si potrebbe integrarlo in un eseguibile, ed estrarre e LoadLibrary in fase di esecuzione e chiamare in esso. O potresti usare un qualche tipo di chiave condivisa per criptare/decodificare il file allegato e fare lo stesso sopra.

Suppongo che tu abbia già considerato soluzioni come compilarlo se davvero non lo vuoi condividere. Se qualcuno vuole davvero arrivarci, ci sono molti modi per farlo.

+0

In .NET i file exe sono anche assiemi e possono essere referenziati. –

+0

Qual è la soluzione per questo? – Josh

+0

Purtroppo, questa è una soluzione molto semplice da evitare. È abbastanza semplice scaricare l'assembly dalla memoria una volta caricato, consentendo così a chiunque di utilizzare l'assembly "crittografato". –

5

Dai uno sguardo allo StrongNameIdentityPermissionAttribute. Ti consentirà di dichiarare l'accesso all'assembly. Combinato con un buon strumento di protezione del codice (come CodeVeil (dichiarazione di non responsabilità che vendo CodeVeil)) sarete abbastanza felici.

12

Stai affrontando lo stesso problema dei sostenitori del DRM.

Se vostro programma (che si desidera essere in grado di eseguire la DLL) è eseguibile da alcuni account utente, quindi non c'è nulla che può fermare un programmatore sufficientemente determinato che possono accedere come quell'utente da isolare il codice che esegue la decrittografia e che utilizza quello per decrittografare la DLL ed eseguirlo.

Ovviamente è possibile rendere scomodo eseguire questo tipo di decodifica e ciò potrebbe essere sufficiente.

+2

+1 perché +100 non è consentito. – RBerteig

1

Beh si potrebbe contrassegnare tutte le classi "pubbliche" come "interno" o "protetta interna", allora si contrassegna assiemi con [assembly: InternalsVisibleTo ("")] Attributo e nessuno tranne gli assembly contrassegnati può vedere il contenuto.

+0

Reflection consente di utilizzare anche tipi/membri privati. –

+0

Intendi, anche se applichi l'attributo InternalsVisibleTo Reflector.Net può ancora esporre il codice? – Jon

+0

Sì. Qualcuno può anche utilizzare un disassemblatore e visualizzare il contenuto del proprio attributo InternalsVisibleTo e creare un assembly con lo stesso nome e ottenere l'accesso. –

1

Hai provato. Netto reattore? L'ho scoperto di recente. Alcuni dicono che è fantastico, ma lo sto ancora testando.