Di seguito gli interventi pubblicati in questa sezione, in ordine cronologico.
 
 

Vengono presentate, in breve, le tecniche di protezione utilizzate in Goliath .NET Obfuscator

La maggior parte di queste tecniche sono state poi "copiate" ed inserite in prodotti concorrenti (tecniche "spudoratamente" simili verrano -adeguatamente- segnalate).

ENCRYPTION DELLE STRINGHE:

 è un'ulteriore tecnica da adottare per la protezione del ns codice. In Goliath .NET Obfuscator si è avuta una naturale evoluzione tra le varie release 1.x, 2.x, 3.x e 4.x.

Nella release 2.x -invece di cifrare la stringa byte-per-byte- si è scelto di implementare un'evoluzione di StackCrypt (tecnica rilasciata pubblicamente su CodeProject qui e qui a luglio'2004...da notare, all'epoca,  la mia mente ancora "inquinata" da codice vb6! ) che consente anche la "compressione" delle stesse.

Quindi, per ogni stringa, viene creato un metodo contenente la stringa da ricostruire a runtime. Ad esempio per una generica stringa "hello world!":

Dim txt As String = CryptMethod()

Function CryptMethod() As String
     Dim stack As New Stack(2)
     Dim startCode As Integer = &H29BCA4A
     '<<<
     With stack
          startCode = startCode Xor 1895280235
          .Push(startCode)
          startCode = startCode Xor 491524942
          .Push(startCode)
          startCode = startCode Xor 121969411
          .Push(startCode)
     End With
     '+++
     Dim retValue As Byte() = STACKED_BYTES(stack)
     Return System.Text.Encoding.UTF8.GetString(retValue)
End Function

Private Function STACKED_BYTES(ByVal st As Stack) As Byte()
     Dim asmPos As Integer = 0
     Dim tempValue((st.Count * 4) - 1) As Byte
     '<<<
     For ik As Integer = 1 To st.Count
          Dim arr As Byte() = BitConverter.GetBytes(DirectCast(st.Pop, Integer))
          '---------------------------------------------------------------------
          For ij As Integer = 3 To 0 Step -1
               If arr(ij) > 0 Then
                    tempValue(asmPos) = arr(ij)
                    asmPos += 1
               End If
          Next
     Next
     '<<<
     Dim retValue(asmPos - 1) As Byte
     Array.Copy(tempValue, retValue, asmPos)
     Return retValue
End Function

...la generazione casuale impedisce -anche al sottoscritto- qualsiasi previsione dei risultati di codifica! Ne consegue che ad un aggressore non basta "invertire" un solo algoritmo ma deve ricostruire N-metodi (metodi offuscati) contenenti N-stringhe!

Nelle successive release l'encryption delle stringhe è legato all'offuscazione del codice!

 

CONTROL-FLOW OBFUSCATION (Spaghetti-Code)
[continua]

Vengono presentate, in breve, le tecniche di protezione utilizzate in Goliath .NET Obfuscator

La maggior parte di queste tecniche sono state poi "copiate" ed inserite in prodotti concorrenti (tecniche "spudoratamente" simili verrano -adeguatamente- segnalate).

RENAMING DEI SIMBOLI:

è una delle prime tecniche da adottare per la protezione del ns codice. Alcuni prodotti basano la protezione sul solo renaming (leggi DF). Sfortunatamente per noi -ad un aggressore che non conosce il ns programma- un metodo che si chiami "serialnumber" o "a0" poco importa...il codice interno è sempre leggibile! Il risultato è che in poco tempo è stato facile vedere solo "cloni di prodotti" (suite di controlli, ect.)

Comunque, per applicare il renaming:

goliath assembly.[exe][dll] ed utilizzare i seguenti parametri:

/renaming+
/chr:[4][6][8][16][32][U][P][D] ...output rispettivamente di 4, 6, 8, 16 o 32 caratteri stampabili. [U]=1 carattere non stampabile, [P]=1 carattere stampabile, [D]=si usa un dizionario esterno

in abbinamento al parametro /chr:[4][6][8][16][32][D] è possibile utilizzare, per comodità, anche il parametro /optchr ed ottenere un risaltato di questo tipo: 61aa2b307ae4cb8b, 61Aa2b307ae4cb8b, 61aA2b307ae4cb8b ...simili per confondere la lettura di chi "spia" ma diversi nella sostanza. In un eventuale dump su file -nomi uguali- vengono sovrascritti.

In automatico, poi, si applica l'overloads dei simboli a metodi, proprietà, field, ect. (nomi uguali a simboli diversi). Questa tecnica risulta valida perchè consentita solo in assembler IL ma non in un linguaggio di alto livello (c#, vb).

 Dato che il range di caratteri utilizzabili è: 0123456789abcdef si può anche personalizzare l'output utilizzando il parametro:

/tbl:a=#,b=?

cioè le "a" dovranno essere convertite in "#" e tutte le "b" in "?".esempio:

61aa2b307ae4cb8b diventa: 61##2?307#e4c?8?

mentre utilizzando: /tbl:a=\1,b=\2 si specifica l'utilizzo di caratteri non stampabili: chr(1), chr(2), ect.

 

ENCRYPTION DELLE STRINGHE:

[continua a breve] 

Utilizzando il nuovo Goliath .NET Obfuscator rel. 4.x è possibile "unire" gli assembly in un unico exe o dll.

Pur disponendo di un valido prodotto bisogna, però, anche saperlo usare correttamente!

Chissà perchè poi un qualsiasi "fallimento" viene sempre imputato all'offuscatore!

Nello specifico mi riferisco all'ostinazione di alcuni utenti americani che cercano di unire i propri programmi con librerie di terze parti (un esempio su tutti è la suite di controlli DOTNETBAR).

N.B.: l'unione di librerie di terze parti porta ad una violazione della licenza d'uso delle stesse. Verificare sempre le condizioni di utilizzo!

Ad esempio, in DOTNETBAR, si usano alcune tecniche per l'assegnazione delle proprietà (nomi passati come stringa):

TypeDescriptor.GetProperties(page)["BackColor"].SetValue(page, Color.White); TypeDescriptor.GetProperties(page)["CanvasColor"].SetValue(page, Color.White);

quindi da qualche altra parte del codice ci sono le proprietà:

- BackColor
- CanvasColor

Risulta immediatamente chiaro a tutti (?) che -per una corretta protezione- le proprietà "BackColor" e "CanvasColor" NON DEVONO ESSERE RINOMINATE!

A questo punto si può decidere:

1) di non rinominare utilizzando /renaming- ed usare sola offuscazione del codice;
2) decorare con l'attributo ObfuscationAttribute(Exclude:=True) solo i metodi e proprietà che devono essere escluse dalla fase di renaming;
3) modificare il codice

Come sempre detto: LA PROTEZIONE DEVE NASCERE CON IL PROGETTO!!!

Il non voler e/o saper modificare opportunamente il codice fa dire che Goliath .NET Obfuscator NON funziona e provocare un danno di immagine a CANTELMO SOFTWARE!

A mio avviso, invece, conviene dire: "per incapacità professionale non sono riuscito a proteggere il mio programma!"

Scopri le ultime novità

Continua l'evoluzione del nuovo prodotto (rel. 3.0.7) con l'inserimento di nuovi eccezionali parametri di protezione:

--clickonce
--fakeint
--fakecall
--chr:[u] o [p]

Parametro: --clickonce:[template] per la generazione automatica del ClickOnce Manifest direttamente da Goliath .NET Obfuscator senza passare da VS e/o MAGE;

esempio di template:
; -------------------------------------------------------------------
; Goliath .NET Obfuscator rel. 3.0.7 - Enterprise Edition
; The Ultimate Secure Obfuscator for .NET Platform
; Copyright (c) 2003-2009 CANTELMO SOFTWARE
; -------------------------------------------------------------------
[Application]
ProductName=clickOnce_Test

[Signing]
Certificate=d:\mypfx\myKey.pfx
CertificatePwd=12345

[Publish] Language=neutral
FolderLocation=d:\myOutFolder\
Version=1.0.0.1
...
[cut]

Parametro: --fakeint per il camuffamento dei valori booleani e di tutti i valori interi;

Parametro: --fakecall:[Fw.Namespaces] per il camuffamento delle chiamate alle funzioni interne di un determinato namespaces del Framework;

esempio d'utilizzo: --fakecall:#d:\project\myprj.txt

con il simbolo '#' -come al solito- si indica di andare a leggere il contenuto di un file (es.: myprj.txt) che contiene, ad esempio:

System.Console
System.String

N.B.: non necessariamente devono essere inseriti tutti i namespaces!

risultati ottenibili in un progetto console:

sub 'originale':

Public Shared Sub Main()
     Console.WriteLine(String.Concat("Hello", " World!")) 
     Console.ReadLine
End Sub

sub 'modificata' SENZA l'encryption delle stringhe:

Public Shared Sub a()
     a.a(a.a("Hello", " World!")) 
     a.A
End Sub

sub 'modificata' CON l'encryption delle stringhe:

Public Shared Sub a() 
     a.a(a.a(a.a, a.A)) 
     a.A
End Sub

Si evidenzia che -per far comprendere le tecniche utilizzate- in questo esempio NON è stato inserito il parametro di stop dei decompilers! ...ipotizziamo -in questo modo- che l'attacker abbia utilizzato un de-obfuscator automatico e si prepara a "spiare" il ns codice

Inoltre, sono state inserite 2 nuove opzioni al parametro --chr:

P=printable: renaming incrementale utilizzando 1 solo carattere stampabile (a, A, b, B, ect.)
U=unprintable: renaming incrementale utilizzando 1 solo carattere non-stampabile

stay tuned!

La "guerra" tra obfuscators contro decompilers (e/o deobfuscators) è sempre attuale.

Sono stati rilasciati strumenti che -se usati creativamente- potrebbero facilitare un eventuale aggressore nell'eliminazione di una precisa tecnica di protezione: il control-flow!

Prevedendo questa "realistica possibilità" è necessario complicare ulteriormente il codice dei ns algoritmi!

Ragion per cui in Goliath .NET Obfuscator release 3.0.4 (Edizione Enterprise) è stata inserita una nuova procedura che offusca i valori numerici unitamente ai valori booleani True/False (aggiornamento del 02-dic-2008).

Cantelmo Software è sempre un passo avanti! Ai competitors "poco creativi"...non rimane altro che copiare anche questa tecnica!

Come più volte ribadito .NET è una piattaforma vulnerabile!

A dimostrazione di quanto affermato questa volta a farne le spese è stato lo stesso Goliath .NET Obfuscator

Ebbene qualcuno che, forse, ritiene il proprio prodotto "competitors" di Goliath .NET Obfuscator ha pensato (bene?!?) di copiare spudoratamente una tecnica usata per bloccare Reflector ed i vari plug-in presenti sul mercato

Non riuscendo a studiare il codice interno, il tizio (pure italiano!), ha copiato direttamente il risultato finale (tecnica unica e presente *solo* in Goliath .NET Obfuscator già da 4 anni)

Che dire?
- grazie per l'interesse ad un prodotto Cantelmo Software;
- complimenti per la creatività!
- almeno ci stai guadagnando qualcosa? 

Il prodotto è stato già scaricato e corservato per benino! al momento, non lo nomino, per non fare "pubblicità occulta" però mi riprometto (appena possibile) di realizzare un...

Stay tuned!

UPDATE del 27-ott-2008: il "tizio" ha rilasciato una nuova release eliminando ("camuffando") le similitudini con Goliath .NET Obfuscator!

UPDATE del 26-ago-2009: una promessa è sempre una promessa! Con la realizzazione del nuovo Goliath .NET Obfuscator rel. 4.x è stato implementato -direttamente- un nuovo parametro (/UNPACK:) che permette di spacchettare automaticamente tale prodotto: guarda il video in anteprima

In Goliath .NET Obfuscator v3.x è stato potenziato il renaming dei simboli. E' possibile, infatti, rinominare anche i simboli pubblici (classi, metodi, proprietà, field, eventi, interface, override, ect.).

Questa feature che è inutile per la protezione di una singola dll (creazione di un componente) risulta essere abbastanza efficace nel camuffare le chiamate alle librerie referenziate in progetti più complessi.

Potendo, ora, alterare i simboli pubblici è stato possibile implementare anche la protezione contemporanea di più assembly referenziati! Di conseguenza, anche eventuali de-obfuscator, devono possedere questa caretteristica. La sola "analisi statica" sui singoli assembly è pressochè inutile. 

ESEMPIO: solo renaming di un singolo assembly:

goliath -r d:\folder\assembly.exe

ESEMPIO: solo renaming di un assembly con una libreria referenziata:

goliath -r d:\folder\assembly.exe --ref:d:\folder\assembly.dll

ESEMPIO: solo renaming di un assembly con due librerie referenziate:

goliath -r d:\folder\assembly.exe --ref:d:\folder\assembly1.dll,d:\folder\assembly1.dll

se invece ci sono numerose references è possibile definirle in un file esterno (ad esempio: references.txt)

d:\folder\assembly1.dll
d:\folder\assembly2.dll
d:\folder\assembly3.dll
...

e richiamate con:

goliath -r d:\folder\assembly.exe --ref:#d:\folder\references.txt

L'overloading dei simboli è automatico! Il range di simboli (standard) utilizzati per il renaming è "limitato" alla sola tipologia alfanumerica: 0123456789abcdef.

All'utente finale, però, viene data, ampia possibilità di intervento. E' possibile infatti:

- definire il numero dei caratteri del testo finale (opzione --char:{number})
- variare il singolo carattere (opzione --tbl:{})

goliath -r d:\folder\assembly.exe --ref:d:\folder\#references.txt --tbl:a=?,b== --char:4

E' possibile generare, chiaramente, anche simboli non stampabili semplicemente impostando - nel parametro --tbl:{} - la definizione \{num}:

goliath -r d:\folder\assembly.exe --ref:d:\folder\#references.txt --tbl:a=\1,b=\2,3=\3,a=\4,b=\5 --char:4

La fase di esclusione dei simboli dal renaming avviene -esclusivamente da codice- utilizzando un attributo già presente nel .NET Framework sin dalla vers. 2.0:

[Obfuscation(Exclude=true)]
public event EventHandler test1;

[STAThread, Obfuscation(Exclude=true)]
internal static int Main([Obfuscation(Exclude=true)] string[] args)
{
}

dopo la fase di renaming -per non far capire alcuna logica progettuale- questo attributo viene automaticamente eliminato!

Ma come detto più volte: rinominare i simboli non significa offuscare il codice! Nelle prossime presentazioni si darà ampio risalto all'offuscazione del codice e all'encryption dei metodi

stay tuned!

Iniziamo a conoscere il nuovo Goliath .NET Obfuscator v3.x presentando una delle features più richieste dai ns clienti: la modalità console. Il vantaggio di questa modalità è l'utilizzo del prodotto anche come "post-build" del processo di compilazione dei ns. progetti

Questa feature, però, ha comportato la completa rivisitazione di tutte le opzioni di protezione.

goliath /?

(N.B.: le caratteristiche possono variare senza preavviso)

Goliath .NET Obfuscator  3.0.0.0
Copyright (c) 2003-2008 CANTELMO SOFTWARE. All rights reserved.
The Ultimate Secure Obfuscator for .NET Platform

Usage: Goliath [options] [options]

Options:

  -? --help              Show this help list
  -c --codeshield[+|-]   Encrypt signed CodeShield methods
  -e --encryption[+|-]   Full strings encryption
  -o --obfuscating[+|-]  Full code obfuscation
  -r --renaming[+|-]     Full symbols renaming
     --bak[+|-]          Backs-up the original file before processing
     --charopt[+|-]      Optimize chars symbols for renaming
     --chr:number        Chars used for symbols renaming. number: 4 (default), 6, 8, 16 or 32
     --help+             Show an additional help list
     --ildasm[+|-]       Prevent ILDASM tool from disassembling
     --nsp:list          Also -namespaces:list. Exclude namespaces. list:namespaces,...
     --out:folder        Specifies the output folder name
     --ref:list          Also -references:list. Add references assembly. list:references,...
     --snk:key           Specifies the strong-name key file
     --tbl:list          Specifies symbol(s) table for renaming. list:name=value,...


altre opzioni: goliath --help+


Goliath .NET Obfuscator  3.0.0.0
Copyright (c) 2003-2008 CANTELMO SOFTWARE. All rights reserved.
The Ultimate Secure Obfuscator for .NET Platform

Usage: Goliath [options] [options]

Options:

  -V --version      Display version and licensing information
     --nologo[+|-]  Do not display the CANTELMO SOFTWARE copyright
     --quiet[+|-]   Report obfuscation progress
     --time[+|-]    Measure elapsed time
     --usage        Show usage syntax and exit

Goliath .NET Obfuscator è un prodotto stabile ed affidabile. La nuova versione recepisce tutte le features richieste dai clienti: - utilizzo da console per una eventuale integrazione con i processi di build automatizzati; - maggiore velocità di esecuzione nell'offuscazione del codice - nuovo schema di encryption delle stringhe (compatibile con i sistemi a 64 bit) - ect.