Cantelmo Software

...ultimi ritocchi al nuovo sito web!

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!  

Estate 2011 ricca di novità! Cantelmo Software da il via ad una nuova linea di componenti per sviluppatori, denominata: .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 vero pericolo per la sicurezza è provare un falso senso di sicurezza!

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 una determinata tecnica è obsoleta, vulnerabile e/o non funziona con tutti i decompilatori si verifica il cosiddetto effetto-boomerang sugli obfuscator!

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!

grazie alle vulnerabilità del codice .NET ...tutti, ormai, riescono a fare tutto!

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"?  

Goliath .NET Obfuscator è in continua evoluzione con tecniche di protezione sempre uniche ed originali!

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!

Ancora un test sulle potenzialità del Goliath .NET Obfuscator 5.5.x su progetti WPF-MVVM (notoriamente ostici all'offuscazione del codice)

Link

Come più volte ribadito è possibile sfruttare le molteplici tecniche di protezione presenti in Goliath .NET Obfuscator rel. 5.5.x qualunque sia il tipo di progetto sviluppato!

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!

Alcune delle molteplici tecniche di protezione presenti in Goliath .NET Obfuscator rel. 5.5.x applicate ad un semplice progetto WP7:

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

Le tecniche di protezione implementate nel nuovo Goliath .NET Obfuscator rel. 5.5 sono sempre disponibili indipendentemente dal tipo di progetto utilizzato: winform, web, silverlight, ect.

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