2010-09-18 12 views
6

Il mio datore di lavoro utilizza Dotfuscator su tutto il nostro software di produzione .Net. Per questo motivo, è assolutamente vietato utilizzare QUALSIASI databinding integrato o qualsiasi cosa che rifletta sui nomi di proprietà/funzioni, perché dotfuscator li cambia e quindi qualsiasi cosa legata istantaneamente e irrimediabilmente si rompe.Databinding e offuscamento codice

Continuo a far scorrere questa logica nella mia mente e comincia a farmi male. Lì deve essere il essere un modo per evitare questo stallo, è un problema troppo ampio e fondamentale per non avere una soluzione ovvia che ci è sfuggita.

Quindi, come si fa Reflection with Obfuscation? Qual è il trucco? Presumibilmente ci devono essere offuscatori commerciali che sono abbastanza intelligenti da aggirare il problema. Quali sono le opzioni per la nostra versione (che è abbastanza stupida)?

risposta

3

Abbiamo apportato una serie di miglioramenti a Dotfuscator che dovrebbero contribuire ad alleviare i problemi relativi alla definizione dei dati. La funzionalità Smart Obfuscation è stata aggiunta nella versione 4.3.100 a marzo 2008 per analizzare staticamente gli assembly ed escludere automaticamente gli elementi dalla ridenominazione/rimozione noti per causare errori di runtime. Abbiamo costantemente ampliato e migliorato questa funzionalità e Dotfuscator di oggi funziona intorno agli scenari di associazione dati standard con una configurazione extra solitamente nulla o minima.

Anche se Smart Obfuscation non cattura tutti i tuoi scenari, è molto semplice definire regole personalizzate per escludere le proprietà di determinati tipi o gerarchie di ereditarietà utilizzando le regole di esclusione personalizzate (inclusi i tipi di corrispondenza per i pattern RegEx). Puoi anche decorare gli articoli con l'attributo System.Reflection.ObfuscationAttribute per assicurarti che saranno esclusi dalla ridenominazione o dalla rimozione durante l'esecuzione di Dotfuscator.

Se si esegue l'associazione da markup XAML a tipi in codebehind le ultime versioni, è stato possibile rinominare XAML/BAML in modo che corrisponda al codice sottostante. Ciò migliora l'indurimento generale ed elimina anche un'intera gamma di problemi quando i simboli nel markup non corrispondono alle definizioni del codice.

Suggerirei di lavorare su alcune semplici prove di applicazioni concettuali usando il databinding simile a quello che si desidera utilizzare nelle applicazioni e eseguendo quelle attraverso Dotfuscator per vedere quanto bene le gestisce. Se trovi scenari in cui Smart Obfuscation non esclude automaticamente i target di associazione dei dati, li invii a [email protected] Siamo sempre alla ricerca di scenari ben definiti per migliorare il prodotto.

+0

Grazie Joe, è davvero d'aiuto. Ora mi sento un po 'imbarazzato per diversi motivi: i) ho incluso un piccolo passaggio a Dotfuscator nel mio post iniziale, che rimpiango; ii) sembra che stiamo usando una versione molto vecchia (non ricordo quale, ma non fa le cose che hai menzionato) e iii) anche se mi lamento, non è la mia chiamata, e io Finora non sono stato in grado di persuadere il mio collega responsabile di questa zona ad adottare qualcosa di nuovo o cambiare in alcun modo le sue tattiche. –

+0

Come appendice; sono sicuro di presumere che 4.3 Community Edition include questa funzionalità, e non è una funzionalità di sola pagamento? Persuadere la gestione a parte con denaro non è mai semplice. –

+0

Anche senza Smart Obfuscation è possibile creare regole di esclusione personalizzate (incluse le partite RegEx) dalla versione 1.0 in poi. È un po 'di lavoro manuale, ma è certamente possibile. Smart Obfuscation nella versione gratuita di Dotfuscator è disponibile nella versione 5.0 fornita con Visual Studio 2010. –

0

È compito di un obfuscator interrompere le relazioni visibili nel codice sorgente in modo che non siano più evidenti nel codice eseguibile risultante. La riflessione si basa su relazioni come "la proprietà richiesta da questo pezzo di codice è quella definita da quel pezzo di codice". Quindi non sorprende che l'offuscamento e la riflessione non giochino bene l'uno con l'altro.

Rinominare le proprietà è solo il grado zero di offuscamento. Un offuscatore non banale farà anche cose come dividere una proprietà in due, in modo che dove il codice sorgente menziona solo una proprietà P, parte del codice runtime userà P1, e parte del codice runtime userà P2, e ci sarà abbastanza compiti tra loro in modo che le proprietà abbiano il giusto valore quando necessario, ma anche assegnazioni parassitarie in modo che non abbiano il giusto valore quando non sono necessarie. Non è solo che P è stato rinominato: non c'è più è una proprietà P.

Non so il motivo per cui si pensa che la riflessione più confusione è “ampia e fondamentale”: sia la riflessione e l'offuscamento sono abbastanza raro nel grande schema di programmazione, e non c'è alcuna correlazione tra il loro uso, quindi non penso che molte persone stiano cercando di avere entrambi.

La mancanza di riflessione è solo un elemento nella lunga lista di cose che l'offuscamento costa. Se la persona che ha deciso di usare l'offuscamento non è un esperto di sicurezza, cerca di infilarlo in esse che l'offuscamento ha un costo molto alto che sicuramente non hanno sottovalutato.

+0

Suppongo di essere abbastanza "net-centrico", che funziona per la nostra azienda mentre ci sviluppiamo su .Net. Lo sviluppatore principale è assolutamente insistente nel dire che dobbiamo offuscare tutto; è difficile da persuadere nel migliore dei casi e questa opinione in particolare è una che si attacca come una patella. A mio avviso, l'associazione è indispensabile ogni volta che si desidera utilizzare un'architettura MVC e questo preclude il suo utilizzo. Sento che ci stiamo sparando ai piedi, ma riconosco gli argomenti per l'offuscamento. Ci vorrebbe un cambiamento nella cultura aziendale per accettare l'inevitabilità di altri che decompilano le nostre applicazioni. –