Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] IL di NET

Pensieri sfusi sull'Intermediate Language di .NET
In questi giorni sto un po' giochicchiando con il codice IL di .net (cioè
quella specie di PCode o byte code che .NET produce come compilato).
In realtà l'ho iniziato a guardare per capire se prestazionalmente era
meglio un For o un Do-While (per inciso, il codice generato è esattamente
identico) e cose del genere.
Poi approfondendo un po' la cosa ho scoperto quanto sia realmente banale
convertire questo IL in qualcosa di leggibile.
Tuttora sto pensando di scrivere un mini traduttore per tradurre (appunto)
l'IL in un pseudo linguaggio leggibile da un programmatore.
Se ne avrò il tempo, seguite il NG e il Sito Comune nelle prossime settimane
:)
P.S.: inutile dire che non è bello decompilare, primo perchè non
decompilerei (ancora non sono riuscito a fare il parsing completo di un exe
e poi mi richiederebbe troppo tempo) e secondo perchè lo sanno tutti che si
può fare, come farlo è pubblicamente divulgato dall'ECMA, già chè chi lo fa,
la Microsoft stessa era consapevole del fatto durante la progettazione di
.NET.
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 .NET.
Fabio, la cosa è abbastanza interessante e affascina anche me; tuttavia
ritengo molto più utile la creazione di un proprio personale obfuscator con
qualche "punto di forza" piuttosto che un decompilatore. Dovendo spender
delle forze, le impiegherei più volentieri sul fronte "Sicurezza"... anche
se poi si sa che se si vuole riottenere il codice ci si riesce... microsoft
docet. :-D
Saluti,
--
Antonio Cangiano
Webmaster di 
www.visualcsharp.it
Discuti nei forum .NET: 
www.visualcsharp.it/forum

 P.S.: inutile dire che non è bello decompilare,
Non sono d'accordo. Non è detto che decompilare sia sempre un'operazione con
fini perversi, anzi..
-- 
Ale
La RFD originale per it.comp.dotnet su
http://www.sen.it/stoa/articles.asp?id=10
Se vuoi discuterne, vai su it.news.gruppi

 qualche "punto di forza" piuttosto che un decompilatore.
No, non ci siamo capiti :)
A me non interessa decompilare.
A me interessa verificare *come* .NET implementa il mio codice, al fine di
scegliere i costrutti migliori (es.: lo sapevi che un array mono
dimensionale viene solo dichiarato, mentre un array bi-dimensionale viene
dichiarato e interamente inizializzato a 0?).
Un obfuscatore interesserebbe anche a me, e ancora sto aspettando che
Microsoft rilasci il suo.
Inutile anche spendere forze per prodotti che esistono già in versioni
sicuramente  migliori.
Ciao
--
mathParser = "
http://www.neodatatype.net
"
sitoComune = "
http://www.it-lang-vb.net
"

 Ciao
ciao,
.A
UGIdotNET - 
http://www.ugidotnet.org

 Vuoi il mio parere? Non lo faranno mai.
Se si utilizzano degli algoritmi di uso comune, per quale motivo
bisognerebbe offuscarli?
Il fatto è che un offuscatore di codice non serve praticamente a nulla. Nel
codice l'unica cosa eventualmente da proteggere potrebbero essere gli
algoritmi, e quelli andrebbero protetti con i brevetti (questo naturalmente
per chi vuole sfruttare in esclusiva le proprie eventuali scoperte).


 eventuali scoperte).
imho i brevetti... in particolar modo quelli sul software andrebbero tutti
aboliti! (se penso solo al quicksort... brr...) :-\

 alla base dati (imho non brevettabile)!
Codificare in chiaro l'accesso alla base dati nel codice non è mai un
approccio sicuro. Questo per quanto lo si possa offuscare.


 approccio sicuro. Questo per quanto lo si possa offuscare.
Cos'è che intendete per "accesso alla base dati"?
Che significa che non dovrebbe essere in chiaro? E che fo? Cripto la
procedura? Non capisco l'affermazione.


 Cos'è che intendete per "accesso alla base dati"?
In quel contesto mi riferivo all'hardcoding di username e password in
variabili o peggio ancora costanti di tipo stringa. Ad esempio in una
ConnectionString..
