ziomaul ha scritto:
> Veramente, se possiedi l'eseguibile e non i sorgenti, basta
> decompilare l'eseguibile (al massimo disassemblarlo) ed op-là ecco i
> sorgenti. NON esiste protezione di compilazione  che possa essere
> violata.
secondo una base teorica nulla da eccepire solo che è un lavoro
laborioso e richiede tempo, non so voi ma io "di mestiere" sviluppo
software e finora tentare di recuperare un algoritmo di pochi KB
all'interno di un eseguibile di svariate centinaia di KB non mi è
capitato di farlo ne ci penso a meno di trovare qualcuno che mi paghi
per farlo (credo sia meno comune di un ago nel proverbiale pagliaio)
anche perché è difficile preventivare il tempo necessario per farlo
(alcuni linguaggi tipo Java e .NET son più facili da decompilare ma si
può tranquillamente assumere che chi si occupa di sicurezza non li usa o
usa tool anti-decompilazione). Già a partire da un sorgente scritto da
altri l'impresa non è veloce e siccome il tempo è un costo o se
preferite, certi lavori si "fatturano a ore" è ovvio che per un banale
documento nessuno si sogna di spendere tempo e denaro in questo modo. Se
invece ci sono a disposizione i sorgenti a spanne mi sento di dire che
un problema come questo si risolve in qualche settimana di lavoro.
> E' illegale (se roba d'altri), ma di solito conoscere la password è
> roba da cattivelli, raramente da smemorati.
Password in ambiente aziendale: le normative vigenti stabiliscono che un
dipendente di un'azienda non può (nella pratica non potrebbe) proteggere
con password un documento aziendale o connesso con l'attività svolta in
azienda senza esserne autorizzato. Le aziende più lungimiranti
utilizzano cartelle condivise in rete con gestione degli accessi a
livello di dominio e se proprio devono essere utilizzate le password
sono consegnate ai dipendenti che ne fanno uso. La cosa non è banale se
si pensa a che succede quando c'è la necessità di leggere un file
protetto da password sconosciuta ed il dipendente non è in azienda ne è
raggiungibile.
> Il reverse si effettua quando crei prodotti simili o uguali; Uno
> perché la copia viene facilmente scoperta; Due perché crei sempre
> qualcosa di meglio !!!
Poi, riguardo al reverse engineering vorrei darti una notizia
sconvolgente: in Italia entro certi limiti non è reato, anzi è un
diritto garantito dallo Stato: se "possiedi" un sw (le virgolette
indicano una diatriba tra BSA e stato su cosa si intende per possesso,
secondo lo stato italiano lo è anche la licenza d'uso) un utente ha il
diritto di effettuare il reverse engineering di un sw per "adattarlo
alle proprie esigenze, correggerne errori, aumentarne le prestazioni se
non adeguate alle proprie legittime aspettative, per adattarlo a
funzionare con un altro programma utilizzato o creato dall'utente
stesso". E' come dire che se io non riesco ad aprire un documento odt
con MS Word e ho la necessità di farlo perchè uso anche OOo allora mi è
consentito "decompilare" MS Word al fine di studiare un modo per fargli
leggere i file odt. Per la cronaca è la direttiva 91/250/CEE che è stata
recepita a tutti gli stati membri dell'UE. Questo è uno di quei
diritti...imbecilli che se capita di usarli 1 volta nella vità è tanto.
>
> Ciao
>
> Davide Prina ha scritto:
>> --- Micron Engineering ha scritto:
>>  
>>> Non è così, il numero di algoritmi di criptatura è in costante
>>> aumento ed è molto alto, conoscendolo si può ipotizzare data una
>>> chiave privata di poter calcolare una data chiave per il documento e
>>> quindi tentare di aprirlo. In questo caso a maggior ragione sapendo
>>> il criterio di scelta della chiave privata (è stabilito dall'utente?
>>> esiste un default o una back door?) e si può fare esaminando il
>>> codice sorgente, si riduce il numero di algoritmi da provare da n a
>>> 1. Dico ipoteticamente perché i tempi sono comunque elevati nel caso
>>> non esistano default e backdoor (che ahimè esistono in troppe
>>> implementazioni). Sempre se si parla di criptatura e non di
>>> salvataggio della password o di un dato ad essa
>>> collegato all'interno del documento. Vista la diversità dei 2
>>> documenti propendo per criptatura per OOo.
>>>     
>>
>> non è proprio così.
>> Se conosci l'algoritmo di criptazione ed hai anche i sorgenti, allora
>> di sicuro non ci possono essere passpartout ... altrimenti tutti li
>> conoscerebbero.
>> Se invece l'algoritmo non è conosciuto come i sorgenti, allora è
>> possibile che siano presenti passpartout (come l'NSA (National Security
>> Agency) ha richiesto ad esempio per il TC o per ms-vista o ...) ...
>> però se non hai i sorgenti hai l'eseguibile ed è sempre possibile fare
>> reversing engineering. Ora chiedo io:
>> * cosa succede se l'algoritmo di criptazione è debole e grazie al
>> reverse engineering si scopre come funziona?
>> * cosa succede se qualcuno scopre del passpartout dato all'NSA di un
>> determinato prodotto?
>>
>> Il reverse engineering non è semplice, però permette di ottenere dei
>> buoni/ottimi risultati. Per esempio la gestione dei file ms-office su
>> OOo è stata ottenuta con questa tecnica perché microsoft non rilascia
>> le specifiche per i suoi formati. Fare il reverse engineering di un
>> formato documentale è di sicuro più complesso che farlo per un
>> algoritmo di criptazione.
>>
>> Guarda alle protezioni adottate sui CD/DVD che sono costate milioni di
>> dollari, ma che la loro scoperta e quindi rimozione è sempre stata
>> questione di poche settimane ...
>>
>> Se vuoi creare qualcosa che viene distribuito ed usato da parte di
>> tutti e che sia veramente sicuro, allora la sicurezza del tuo algoritmo
>> non deve essere basato sulla segretezza, perché questa segretezza è un
>> falso attributo che sembra garantire maggior sicurezza, ma così non è.
>> Ciao
>> Davide
>>
>> Dizionari: http://linguistico.sourceforge.net/wiki
>> Esci dall'illegalità: utilizza OpenOffice.org:
>> http://linguistico.sourceforge.net/wiki/doku.php?id=UsaOOo
>> GNU/Linux User: 302090: http://counter.li.org
>> -- 
>> Non autorizzo la memorizzazione del mio indirizzo su outlook
>>
>>
>>     
>>
>>     
>>        
>> ___________________________________ L'email della prossima
>> generazione? Puoi averla con la nuova Yahoo! Mail:
>> http://it.docs.yahoo.com/nowyoucan.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rispondere a