Per chi, invece, segue le nuove tendenze del web (...e vuole informazioni brevi e concise) può seguire Cantelmo Software anche sui principali social network:

- facebook;

- twitter;

- youtube;

stay tuned!  

.NET Easy...

Tutti i componenti sono realizzati in puro codice managed (100% vb.net):

• DXF.IO: lettura/scrittura di file .DXF 2D/3D. Disponibile per tutte le tipologie di progetto: WinForms, WPF, ASP.NET, Silverlight, WP7;
• PaletteBar: creazione di toolbar (anche fluttuanti) posizionabili a piacimento sullo schermo (utilissime in applicazioni grafiche). Al momento disponibile solo per WinForm.

stay tuned!

Il rilascio dei nuovi decompilatori per la piattaforma .NET (...gratuiti ed in formato sorgente cioè modificabile da chiunque!) espone, il ns codice, in modo esponenziale, al reverse-engineering e decompilazione da parte di hacker e competitors!

In questo post vedremo una modifica applicata al nuovo decompilatore ilspy che bypassa una tecnica di offuscamento: il renaming a caratteri non stampabili!

L'attuale modifica unitamente all'automatismo -già presente- per l'eliminazione del control-flow mette a serio rischio la tutela delle ns applicazioni!

Se il tuo obfuscator (...gratuito e non) usa ancora queste due tecniche obsolete...il tuo codice, purtroppo, appartiene già ad un altro! 

In breve:

la modifica esegue un banale check di validità sul nome dei tipi In presenza di caratteri diversi da: "_", ".", "a-z", "A-Z", "0-9" si identifica il nuovo nome con: "Type_", "Method_", "Field_", "Event_", ect. unitamente al valore del metadata-token (che è unico!).

N.B.: Con tale tecnica si bypassa completamente l'overloads dei simboli!

La fasi da implementare sono:

- nell'assembly Mono.Cecil referenziare: System;
- nel file AssemblyReader -> classe MetadataReader inserire il seguente metodo:

// check unprintable name
public static bool IsValidName(string name)
{
     byte[] arr = Encoding.UTF8.GetBytes(name);
     int size = arr.Length - 1;
     for (int ik = 0; ik <= size; ik++)
     {
          int chkvalue = arr[ik];
          if ((((((chkvalue == 0x2e) || (chkvalue == 0x5f)) ? 1 : 0) == 0) && 
             ((((chkvalue >= 0x41) && (chkvalue <= 0x5a)) ? 1 : 0) == 0)) && 
             ((((chkvalue >= 0x61) && (chkvalue <= 0x7a)) ? 1 : 0) == 0))
             {
                  return false;
             }
          }
          return true;
      }
}

e modificare, ad esempio, il metodo: ReadMethod in questo modo:

ReadMethod (uint method_rid, Collection<MethodDefinition> methods)

e così via per i metodi: ReadType, ReadTypeReference, ReadField, ReadEvent, ReadProperty, ReadParameter, ReadMemberReferences

quando si protegge un assembly .NET con uno dei seguenti prodotti:

- bab** obfuscator;
- cryp** obfuscator;
- deeps** obfuscator

si scopre una tecnica uguale ma ormai, da tempo, obsoleta! dato il semplice metodo con un argomento stringa, ed il suo codice in assembler-IL:

.namespace MyNamespace
{
   .class private abstract auto ansi beforefieldinit MyClass 
   extends [mscorlib]System.Object
   { .method assembly hidebysig instance void MyMethod(string s) cil managed
     {
       ...
       L_000x: ldtoken instance void MyNamespace.MyClass::MyMethod(string) // D0????????
       L_00xx: pop // 26
       ...
     }
   }
}

si nota la presenza delle seguenti istruzioni: ldtoken, pop

il token passato (sia esso MethodInfo, FieldInfo o Type) viene convertito in RuntimeHandle e pushato sullo stack per poi essere immediatamente poppato!  ...in pratica nessuna modifica al codice!

tale strategia "blocca" solo .NET Reflector (per un banale bug e/o funzionalità non implementata) e getta "fumo negli occhi" a chi deve valutare realmente le potenzialità di un obfuscator!

basta spiare il codice con un altro decompilatore (ilspy, ect.) per capire il fallimento totale di tale tecnica...ed il codice "ritenuto sicuro" appartiene già ad un altro!!!

modificando la sequenza di byte: D0 ?? ?? ?? ?? 26 in 00 00 00 00 00 00 il codice torna visibile anche sotto reflector! dato che la signature (i 4 valori dopo DO) non è sempre uguale, è necessario, automatizzare lo sostituzione. Si utilizzerà il noto CFF explorer a cui passeremo questo semplice script (ldtoken_pop.cff):

-- ldtoken/pop patch (c) Cantelmo Software

filename = GetOpenFile()

if filename == null then
   return
end

-- "ND" elements are wildcards

data = { 0xD0, ND, ND, ND, ND, 0x26 }

-- 0x00 = nop -> nothing instruction!
cr4ck = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }

filehandle = OpenFile(filename)

if filehandle == null then
   return
end

offset = SearchBytes(filehandle, 0, data)

while offset != null do   
   WriteBytes(filehandle, offset, cr4ck)
   offset = SearchBytes(filehandle, offset + 1, data)
end

if SaveFile(filehandle)== true then  
   MsgBox("deprotected!")
end

enjoy!

ultimamente sto riscontrando una situazione davvero divertente:

• i "piccoli" clonano le tecniche di protezione di altri obfuscator che poi re-implementano in prodotti gratuiti o, comunque, a prezzo minore dei rispettivi competitors e riuscire, in qualche modo, ad entrare e sopravvivere nel mondo del business del software;
• i "grandi" (produttori di componenti) invece rilasciano gratuitamente nuovi decompilatori per la piattaforma .NET

il riscontro immediato è che dopo, "Jetbrains" ora anche "Telerik" ha rilasciato il suo decompilatore: JustDecompile! (...la nota simpatica è che viene rilasciato un tool che danneggia tutti ma poi viene precisato che tale tool non dev'essere utilizzato per il reverse-engineering dello stesso)

nell'offuscazione del ns codice, quindi, non basta "testare" un obfuscator solo con il noto "reflector" ma i test di validazione devono essere fatti anche su tutti questi altri prodotti!

[Update] 20-giu-2011 (17:27): tale tool è stato "offuscato" (...purtroppo la concorrenza è a tutti i livelli ) con un obfuscator commerciale che fallisce miseramente all'analisi con "ilspy.net" (altro decompiler).

c'è ora da chiedersi: "chi sarà il prossimo"?  

Nell'attuale versione 5.5.x è stato inserito un ulteriore parametro di protezione (/array) che consente l'offuscazione automatica degli "array" di byte (nelle successive release anche di tutti gli altri tipi). In abbinamento a tale parametro è anche possibile usare il parametro /proxy (per usare, cioè, i "delegate-invoke" anzichè le "call-dirette")

N.B.: come sempre, tale parametro di protezione è disponibile, indipendentemente dalla tipologia di progetto usata: winforms, web, wpf, wp7, silverlight, ect.

enjoy!

Link

Oggetto di questo post è la protezione di una semplice applicazione "WPF-Browser":

A questo link è disponibile l'applicazione demo; mentre, invece, da questo link è possibile scaricare il solo eseguibile da decompilare!

I parametri utilizzati per la protezione sono:

/main:C:\testv55\tictactoe.exe /nonusercode /nopublic /cg /e:s /var /call /values /proxy /r /namespaces /stack

enjoy!

I parametri utilizzati sono:

/main:C:\testv55CalendarControl.dll /nonusercode /nopublic /cg /e:s /var /call /values /proxy /r /xap:C:\testv55\CalendarControl.xap /namespaces

L'esempio, invece, è disponibile a questo link

enjoy!

Ulteriori Aggiornamenti:

• 01-giu-2011: inserito nel processo di protezione il parametro /math per l'offuscamento delle operazioni matematiche: +, -, *, /, And, Not, Or, Xor

Un esempio di protezione su un progetto Silverlight4 è disponibile a questo link

I parametri utilizzati sono:

goliath /main:C:\g_test_v5\testSL.dll /e:s /values /nopublic /xap:C:\g_test_v5\TestSL.xap /snk:C:\g_test_v5\goliath.snk /proxy /r /var /namespaces /call

/main: assembly principale;
/e:s encryption statico delle stringhe;
/values encryption statico dei valori numerici (integer);
/nopublic esclusione dei tipi pubblici dal renaming;
/xap: il file .xap che deve essere aggiornato con gli assembly offuscati;
/snk: file strong-name da utilizzarsi per rifirmare gli assembly (ed automaticamente viene inserito un check anti-tampering);
/proxy utilizzare proxy-call anzichè call dirette ai metodi (in questo esempio applicato solo all'encryption delle stringhe e dei valori numerici);
/r renaming dei simboli;
/var offuscazione delle variabili nei metodi /namespaces renaming dei namespaces;
/call camuffamento delle call ai costruttori e metodi

Goliath .NET Obfuscator -grazie ad un uso combinato dei vari parametri di protezione- consente di raggiungere un elevato livello di sicurezza

Link

Dato l'esempio vb.net

ed il relativo codice assembler-IL:

 è possibile applicare una trasformazione al codice che esegue la somma del valore 1:

ij += 1   ...diventa:

Fino ad ora è stato abbastanza semplice bloccare tutti i decompilatori .NET

Ma dato che gli stessi quest'ultimi si stanno evolvendo -imho- servono nuove idee! Eccovi, quindi, le mie idee

L'aggressore (con un decompilatore) vuole a tutti i costi spiare il ns codice? ...Bene! Perchè, allora, non fargli spiare, analizzare e far perdere tempo con quello che vogliamo noi?

Questo è il primo di una serie di post in cui si illustra come Goliath .NET Obfuscator applica alcune trasformazioni metamorfiche e/o polimorfiche al codice (alcune delle quali già usate sin dalla release 2.x) usando le stesse -efficaci- tecniche dei virus al fine di "diversificare" il risultato finale.

Tale tecniche risultano valide (come già detto in precedenza) anche per l'eventuale watermarked del codice stesso.

Il rovescio della medaglia è che rendere il codice "troppo duro da analizzare" porta lo svantaggio nell'analisi di eventuali malware protetti con le stesse tecniche e/o programma (...ma non siamo produttori di AV).

Iniziamo ora, però, con la parte più semplice: la "p3rv3rs!0n3" dei valori numerici: "-1" e "0"

Valore "-1":

che tradotto in assembler IL diventa:

.locals init ([0] int32 a)
    L_0000: ldc.i4.m1
    L_0001: stloc.0 

quindi la prima idea è quella di ottenere il valore "-1" coinvolgendo qualche altro valore. Esempio:

Dim a As Int32 = 123 Xor 123 ...oppure:
Dim a As Int32 = 123 And 0

"From the end of February 2001 .NET Reflector will become a paid-for product, starting at $35"

Con questo annuncio l'azienda produttrice fa sapere che non ci sarà più una versione gratuita del noto decompilatore!

Le situazioni da me ipotizzate sono:
- la solita "strategia d marketing": ti regalano una cosa per farti abituare e poi, quando non ne puoi più fare a meno,...il prodotto diventa a pagamento!
- "punizione" per gli utenti: dato che circola in rete una versione completamente spacchettata e decompilata (con tanto di src code c#- pronto ad essere ricompilato con VS) si tenta, in qualche modo, di recuperare l'investimento fatto inizialmente (acquistando .NET Reflector da un dipendente MS)

Quale che sia la verità, l'azienda sarà ora costretta a "rimboccarsi le maniche"...perchè ci sarà da competere (la concorrenza purtroppo è a tutti i livelli: decompilatori, offuscatori, ect) con un nuovo prodotto open-source: ILSpy (assembly browser & decompilatore)

Il progetto è basato su Mono-Cecil & .NET FW 4.0. Per ora il codice "recuperato" è solo in assembler-IL e c#

L'impressione d'uso è buona e sembra promettere bene per il futuro. Da questo link è possibile scaricare sia la versione compilata che i src code in c#

Le nuove funzionalità (già implementate in Goliath .NET Obfuscator 5.x) sono accessibili tramite i nuovi parametri: /fakevar, /fakemath, /fakejmp)

L'idea di fondo è questa: se un aggressore riesce ad eliminare tutti gli strati di protezione di Goliath .NET Obfuscator, che tipo di codice si ritrova a dover analizzare?

Nel documento allegato è possibile valutare la "qualità del codice offuscato" ottenibile con alcune "semplici" tecniche:

/renaming: renaming dei simboli con overloads automatico;
/call: offuscazione delle call ai costruttori e metodi (nuova tecnica valida anche per progetti wp7);

ed i nuovi parametri:

/fakevar: offuscamento delle variabili interne ai metodi ("alias");
/fakemath: offuscazione dei calcoli matematici utilizzanti i 4 operatori: +, -, *, / e le funzioni booleane: "And", "Or", "Xor", "Not";
/fakejmp: offuscazione dei salti condizionali: "<", "<=", "=>", ">"

Per far comprendere meglio le nuove tecniche utilizzate sono state escluse dal processo di protezione: encryption delle stringhe, offuscazione dei valori numerici, offuscazione del controlflow e l'encryption dei metodi

Il documento (formato .pdf - dim. 487 kb) è disponibile a questo link