Risolvi un crypto KeyGenMe e vinci:

- 1 Licenza d'uso: Goliath .NET Obfuscator rel. 4.x (Enterprise Edition)
- assurance program (per 1 anno)

Maggiori informazioni sono disponibili a questo link

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!":

...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!"

E' possibile scaricare -gratuitamente- il generatore di combinazioni (vincenti) da questo link

Scopri le ultime novità

L'acquisto di un nuovo computer è sempre una scelta difficile. I fattori in gioco sono diversi: prezzo, caratteristiche e -non per ultimo- l'eventuale servizio di assistenza tecnica. Pur di non avere problemi (e bloccare un'attività) siamo disposti anche a spendere qualcosa in più!

La mia scelta è ricaduta su un prodotto HP (azienda già a me nota grazie ad un palmare: iPAQ h5450) ed ho acquistato un notebook dv5-1140el.

L'enfasi iniziale ha subito una piccola battuta di arresto a causa di un errore con il masterizzatore. Qualsiasi tentativo di copiatura falliva evidenziando un errore: 0xEB020B88.

Dopo qualche ricerca leggo sul forum del produttore del software (in bundle con il notebook) che tale errore è dovuto ad un difetto di fabbrica!

In questo post voglio segnalare la pazienza, cortesia e professionalità del Servizio Clienti HP (rif. Sig.ra Marchionni e Sig. La Grassa) che ha provveduto immediatamente (a stretto giro di e-mail) alla risoluzione del mio problema. Dopo essersi accertati delle mie competenze tecniche e, quindi, di conseguenza, senza bloccarmi l'attività commerciale (nel caso avessi dovuto inviare loro il notebook) mi hanno fatto pervenire -senza alcuna spesa- il nuovo masterizzatore.

Ora tutta la soddisfazione di aver scelto un buon prodotto...ed un'azienda affidabile!

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 protezione dei ns programmi è un argomento sempre attuale!

Per una protezione efficace è necessario rendere INSEPARABILE il legame tra protezione e programma. Ma chi utilizza il .NET deve prevedere -anche la possibilità- che il Suo codice venga spiato e/o analizzato (con l'ausilio dei decompilatori).

Se il codice può essere analizzato, risulta superfluo, utilizzare crittografia a chiave simmetrica per proteggere i dati utilizzati per il licensing. Il punto debole degli algoritmi a chiave simmetrica è la chiave che -necessariamente- deve essere distribuita con il programma.

Ora, quindi, l'idea è questa:

1) utilizzare Goliath .NET MuPAL (Multi-Precision Arithmetic Library);
2) implementare ALGORITMI A CHIAVE ASIMMETRICA: si cryptano i dati con la chiave privata e si decryptano i dati con la chiave pubblica (distribuita con il programma);
3) e, come detto, per RENDERE INSEPARABILE IL LEGAME tra protezione e programma invece di inserire manualmente i valori utilizziamo quelli presenti nello STRONG-NAME.

Ne consegue:

- per alterare anche 1 solo byte dei ns programmi è necessario ELIMINARE LO STRONG-NAME;
- eliminando lo strong-name, RISULTA FALSATA, qualsiasi decodifica dei ns dati.

Per esporre quanto detto, si decide, di utilizzare RSA:

normalmente per cryptare si utilizza:

C = M^E mod N

e per decryptare:

M = C^D mod N

dove:

M = testo da cifrare ( per non avere problemi la dim. consigliata è: (keysize/8)+1 )
P = 1° NUMERO PRIMO di grandi dimensioni (per ora >=512 bits)
Q = 2° NUMERO PRIMO di grandi dimensioni (per ora >=512 bits)
E = ESPONENTE PUBBLICO che soddisfa: GCD(E, (P-1)*(Q-1))==1)
N = MODULO PUBBLICO, il prodotto di P e Q: N=P*Q
D = ESPONENTE PRIVATO: D=E^(-1) mod ((P-1)*(Q-1))

P, Q e D ...DEVONO RIMANERE SEGRETI!!!

invece nel ns sistema di licensing utilizzeremo il sistema RSA al contrario (verifica firma):

per cryptare: C = M^D mod N e per decryptare: M = C^E mod N

il risultato di tale operazioni potrà -ad esempio- essere utilizzato per far compiere al ns programma una qualsiasi operazione (e non un banale vero/falso del risultato!)

N.B.: con tale tecnica è virtualmente impossibile realizzare un keygen dei ns programmi perchè è necessario scoprire i parametri P e Q dalla chiave pubblica N. Per riuscire nell'impresa si deve fattorizzare N (la sfida del nuovo millennio). Lo strong-name usa chiavi a 1024 bits. I tempi di calcolo -per tali dimensioni di chiavi- risultano -con le attuali macchine- davvero proibitivi!

Per maggiori informazioni si consiglia di visionare gli esempi contenuto con la libreria Goliath .NET MuPAL!

enjoy!

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!