Sconvolto dalla facilità di decompilazione di .net

[seven.7]

Sono un giovane amante della programmazione e il mio primo studio di linguaggio si concentrava tutto sul visual basic .net, stasera però ho avuto un shock tremendo: ho trovato un software online che penso conoscano tutti quelli del reverse engineering... e mi è caduto il mito del .NET per la facilità di decompilazione... Avevo progettato una classe per criptare i testi ma è inutile... con questo programma si vede praticamente tutto allora mi chiedo una sola cosa... vi prego ditemi che si posso criptare le classi o qualcosa del genere perchè altrimenti è inutile programmare in .net... secondo me

[RaouL_BennetH]

In genere è quello che succede anche con Java e con linguaggi simili. Fai una ricerca su .Net obfuscator e troverai diverse utility che ti permettono di mascherare il codice.

[andbin]

Originariamente inviato da seven.7

Sono un giovane amante della programmazione e il mio primo studio di linguaggio si concentrava tutto sul visual basic .net, stasera però ho avuto un shock tremendo: ho trovato un software online che penso conoscano tutti quelli del reverse engineering... e mi è caduto il mito del .NET per la facilità di decompilazione... Avevo progettato una classe per criptare i testi ma è inutile... con questo programma si vede praticamente tutto allora mi chiedo una sola cosa... vi prego ditemi che si posso criptare le classi o qualcosa del genere perchè altrimenti è inutile programmare in .net... secondo me

Guarda che la stessa problematica esiste anche in Java....
Per entrambe le piattaforme comunque esistono degli appositi offuscatori, che, nota bene, non impediscono la decompilazione ma rendono più difficile la comprensione (da parte di una persona, ovviamente) del sorgente ricavato dalla decompilazione.
L'argomento del reverse-engineering è complesso e comunque poco tollerato sul forum.

Prima di terminare, una considerazione: se hai paura che qualcuno possa vedere/capire il codice di una tua classe che (de)cripta qualcosa, allora il problema è il tuo codice. La sicurezza e l'affidabilità di una cifratura non sta nella segretezza del codice (algoritmo), ma nella segretezza delle chiavi o password usate.

[amedeoviscido]

Originariamente inviato da andbin

La sicurezza e l'affidabilità di una cifratura non sta nella segretezza del codice (algoritmo), ma nella segretezza delle chiavi o password usate.

Parole sante!

Originariamente inviato da andbin

Guarda che la stessa problematica esiste anche in Java....
Per entrambe le piattaforme comunque esistono degli appositi offuscatori, che, nota bene, non impediscono la decompilazione ma rendono più difficile la comprensione (da parte di una persona, ovviamente) del sorgente ricavato dalla decompilazione.
L'argomento del reverse-engineering è complesso e comunque poco tollerato sul forum.

Prima di terminare, una considerazione: se hai paura che qualcuno possa vedere/capire il codice di una tua classe che (de)cripta qualcosa, allora il problema è il tuo codice. La sicurezza e l'affidabilità di una cifratura non sta nella segretezza del codice (algoritmo), ma nella segretezza delle chiavi o password usate.

ci sono dei metodi, magari agendoc direttamente sul bytecode, per ingannare i decompilatori (parlo di java)?

[nico88desmo]

La sicurezza e l'affidabilità di una cifratura non sta nella segretezza del codice (algoritmo), ma nella segretezza delle chiavi o password usate.

Mi sembra di aver sentito il mio professore di sistemi

[tomminno]

Originariamente inviato da andbin

ma nella segretezza delle chiavi o password usate.

Probabilmente ci vuole un pò di perizia a nasconderle, io non ci riesco, le chiavi sono sempre riconoscibilissime anche in un programma C++, basta un qualunque programma che analizzi il formato PE di windows che le costanti sono ben evidenti. Ci devono essere delle tecniche ben precise per offuscare delle costanti, ma non ho mai trovato niente a riguardo.

[andbin]

Originariamente inviato da tomminno

Probabilmente ci vuole un pò di perizia a nasconderle, io non ci riesco, le chiavi sono sempre riconoscibilissime anche in un programma C++, basta un qualunque programma che analizzi il formato PE di windows che le costanti sono ben evidenti. Ci devono essere delle tecniche ben precise per offuscare delle costanti, ma non ho mai trovato niente a riguardo.

Innanzitutto differenziamo tra ciò che possono essere delle semplici costanti usate da un certo algoritmo e ciò che invece è una vera e propria chiave o password usata per la (de)criptazione.

Nel primo caso non ci sono problemi (come ho detto non è importante la segretezza dell'algoritmo). Nel secondo caso la risposta è: no, non è da fare.

Quindi se ti balza anche solo l'idea di memorizzare in un eseguibile una qualunque password o chiave "sensibile" .... beh, cambia velocemente idea.

[Matrixbob]

Originariamente inviato da seven.7

Sono un giovane amante della programmazione e il mio primo studio di linguaggio si concentrava tutto sul visual basic .net, stasera però ho avuto un shock tremendo: ho trovato un software online che penso conoscano tutti quelli del reverse engineering... e mi è caduto il mito del .NET per la facilità di decompilazione... Avevo progettato una classe per criptare i testi ma è inutile... con questo programma si vede praticamente tutto allora mi chiedo una sola cosa... vi prego ditemi che si posso criptare le classi o qualcosa del genere perchè altrimenti è inutile programmare in .net... secondo me

Anche io poco tempo fa avevo affrontato questa scoperta:
[GENERICO] E' possibile decompilare 1 programma?

Tu cosa hai usato per decompilare?

[variabilepippo]

Tu cosa hai usato per decompilare?

Per applicazioni .NET il decompilatore più diffuso è certamente Reflector.

[tomminno]

Originariamente inviato da andbin

Innanzitutto differenziamo tra ciò che possono essere delle semplici costanti usate da un certo algoritmo e ciò che invece è una vera e propria chiave o password usata per la (de)criptazione.

Nel primo caso non ci sono problemi (come ho detto non è importante la segretezza dell'algoritmo). Nel secondo caso la risposta è: no, non è da fare.

Quindi se ti balza anche solo l'idea di memorizzare in un eseguibile una qualunque password o chiave "sensibile" .... beh, cambia velocemente idea.

Da qualche parte la devi pur mettere no? Ad esempio un programma che usa AES per comunicare dove può tenere la chiave? E lo stesso se usasse l'RSA dova la tiene la chiave privata? O la metti nell'eseguibile o su un file da qualche altra parte, ma sempre in chiaro la devi tenere (perchè altrimenti c'è il problema di come nascondere la chiave per cifrare il file che continere la chiave segreta).

Infatti non ho trovato la soluzione corretta al problema, forse bisognerebbe affidarsi a qualche servizio dell'OS o fare in modo che venga ricalcolata a runtime in modo da nascondere la chiave nel codice.

[PGI-Bis]

E' l'algoritmo che deve essere in chiaro (per non incappare nella cd security through obscurity). I dati necessari al funzionamento dell'algoritmo possono benissimo essere "oscurati": nel senso che una il funzionamento del prodocollo di sicurezza basato su quel sistema di cifratura può essere (e, per quanto ne so, è sempre) condizionato alla conoscenza di uno o più dati da parte di un gruppo ristretto di soggetti (al limite uno solo, come nel caso degli algoritmi a doppia chiave).

Puoi scrivere la password in chiaro nel sorgente del programma? Certamente sì. In quel caso, tuttavia, la segretezza (o disponibilità esclusiva) si estende a tutto il programma e a tutto il PC su cui il programma gira.

Aggiungo: algoritmo in chiaro non significa che il codice che lo realizza debba essere a sua volta in chiaro.

[tomminno]

Originariamente inviato da PGI-Bis

Puoi scrivere la password in chiaro nel sorgente del programma? Certamente sì. In quel caso, tuttavia, la segretezza (o disponibilità esclusiva) si estende a tutto il programma e a tutto il PC su cui il programma gira.

Aggiungo: algoritmo in chiaro non significa che il codice che lo realizza debba essere a sua volta in chiaro.

Ad esempio mettiamo il caso di un programma client-server in cui l'utente non dovrebbe mettere il naso nella comunicazione, perchè questo potrebbe compromettere la sicurezza dei dati di altri utenti di quella macchina o la sicurezza del sistema (esempio il sistema di monitoraggio informatico usato in Ferrari per scoprire le fughe di informazioni riservate). Da qualche parte sul client devo tenere una chiave, ma questa non deve essere accessibile a nessun utente di quella macchina che potrebbe essere maleintenzionato.

[PGI-Bis]

E' interessante. Non so se sia possibile. Se il programma deve usare un valore quel valore, prima o poi, apparirà in chiaro.

Intendo per valore in chiaro sia il valore scritto com'è nel sorgente, sia il valore cifrato nel sorgente o in un file o quant'altro. Prima o poi finirà nella memoria del calcolatore: a quel punto l'utente farà un dump. Ci perderà tre diottrie ma alla fine troverà la chiave.

Possiamo cifrare la memoria ma non è una soluzione: sposta il problema dalla chiave alla chiave della chiave.

Do un'occhiata alla schneier perchè questa faccenda mi ricorda il protocollo in cui una delle due parti non è fidata.

[tomminno]

Originariamente inviato da PGI-Bis

E' interessante. Non so se sia possibile. Se il programma deve usare un valore quel valore, prima o poi, apparirà in chiaro.

Intendo per valore in chiaro sia il valore scritto com'è nel sorgente, sia il valore cifrato nel sorgente o in un file o quant'altro. Prima o poi finirà nella memoria del calcolatore: a quel punto l'utente farà un dump. Ci perderà tre diottrie ma alla fine troverà la chiave.

Possiamo cifrare la memoria ma non è una soluzione: sposta il problema dalla chiave alla chiave della chiave.

Do un'occhiata alla schneier perchè questa faccenda mi ricorda il protocollo in cui una delle due parti non è fidata.

Mi è venuto in mente tardi ma come esempio è sicuramente più fulgido: i player per dischi HD (o anche solo DVD). Se hai i disco originale sei autorizzato a vedere il film, ma non devi poter accedere alle chiavi.
Lasciamo perdere il fatto che sono stati crackati entrambi, per gli HD pare che il bug nel software sia stato risolto e le chiavi sostituite.
Mi chiedo come tengano le chiavi sul software.

[PGI-Bis]

Ho fatto una breve ricerca per vedere un po' come facciano a craccare 'sti sistemi. Per i DVD il protocollo di sicurezza si chiama CSS. Per gli HD-DVD si chiama AACS.

Sembra che le chiavi di decifrazione siano immagazzinate nell'hardware o nel software. Secondo quanto riportato qui:

http://www.engadget.com/2007/02/24/a...dvd-key-found/

Nel caso di WinDVD una chiave è stata recuperata proprio con l'analisi di una copia della memoria del programma.

Nel caso di chiavi software, quindi, si tratta proprio di "security through obscurity". E non regge agli attacchi del brufoloso (lo dico amorevolmente) di turno.

Sullo schneier leggo che la conservazione sicura di queste chiavi è realizzata attraverso chip tamper proof, cioè a prova di forzatura.

[Jorgensen]

Dunque in visual studio 6.0 (e dovrebbe esserci anche nel .net) c'era la possibilità di realizzare un eseguibile che riunisse in tutt'uno quello che serviva, in pratica non avevi librerie o altro esterne per farlo funzionare, scusa la poca competenza in materia . Utilizzando questo sistema in combinazione con un pe-crypter(tipo Themida o vmprotect) saresti al sicuro da eventuali debugger/decompiler/disassembler ecc.

[tomminno]

Originariamente inviato da PGI-Bis

Ho fatto una breve ricerca per vedere un po' come facciano a craccare 'sti sistemi. Per i DVD il protocollo di sicurezza si chiama CSS. Per gli HD-DVD si chiama AACS.

Sembra che le chiavi di decifrazione siano immagazzinate nell'hardware o nel software. Secondo quanto riportato qui:

http://www.engadget.com/2007/02/24/a...dvd-key-found/

Nel caso di WinDVD una chiave è stata recuperata proprio con l'analisi di una copia della memoria del programma.

Si ma pare fosse un bug del programma adesso risolto, adesso le chiavi lette dal supporto sono cifrate anche in memoria.
Solo che risolto un problema rimane aperto quello di fondo, ovvero tenere oscurata la chiave che consente al programma di andare a leggere le chiavi sul supporto che servono a decodificare il supporto stesso. Questa purtroppo da qualche parte la devono mettere e già mi chiedo come siano riusciti ad oscurarla nei binari.

Direi che non c'è modo di tenere al sicuro una costante.

Nel caso di chiavi software, quindi, si tratta proprio di "security through obscurity". E non regge agli attacchi del brufoloso (lo dico amorevolmente) di turno.

Tutto è "security through obscurity", gli algoritmi di cifratura sono sicuri finchè è oscurata la chiave

Sullo schneier leggo che la conservazione sicura di queste chiavi è realizzata attraverso chip tamper proof, cioè a prova di forzatura.

Questo esclude i software... Fino all'avvento del TC.

[PGI-Bis]

C'è sempre una parte nascosta. Il fatto è che non è necessario che quella parte sia nota ad entrambi i soggetti per poter garantire un fatto. Prendi ad esempio gli algoritmi a doppia chiave, pubblica e privata. Io posso spedire un messaggio a Ciccio avendo la garanzia che nessuno oltre a Ciccio sarà in grado di leggerlo semplicemente disponendo di un "numero" noto a tutti (la chiave pubblica di Ciccio).

Penso sia un meccanismo simile a questo quello che ci dovrebbe interessare nel caso in questione. Anzichè nascondere la chiave, è possibile fare in modo che la conoscenza della chiave sia irrilevante?

Mi sono arrovellato un po' sulla questione ma non sono arrivato a nulla. Fortunatamente questo non significa niente perchè io non sono un esperto di sicurezza.