di  -  mercoledì 17 novembre 2010

Queste sono delle obiezioni abbastanza comuni che vengono spesso tirate in ballo quando si parla di software “chiuso”, ovviamente in contrapposizione a quello definito “aperto” (che, per contro, consentirebbe tutto).

Il codice closed non si può modificare, se vuoi estenderlo non puoi farlo, se c’è un bug o una falla di sicurezza non puoi correggerli (immancabilmente virus e trojan prenderanno possesso del tuo PC; ouch!), e non puoi guardare com’è fatto per studiarlo oppure, meglio ancora, per andare a caccia delle famigerate backdoor (sicuramente ne conterrà almeno una, per farci entrare gli spioni del governo o della CIA).

Cose trite e ritrite che abbiamo sentito chissà quante volte, nella perenne diatriba fra i due modelli di distribuzione del software che, a mio avviso troppo spesso e a torto, vengono visti come mutuamente esclusivi (o stai con l’uno o con l’altro), in una sorta di logica binaria che tende ad appiattire anche le ottime capacità intellettive di cui la natura ci ha fatto dono.

Comunque affermazioni perentorie come quelle riportate sopra mi fanno un po’ sorridere, perché riportano alla mente le tante esperienze che ho avuto in passato sull’argomento, a cominciare dal mio primo computer, uno splendido (ma sfortunato, commercialmente parlando) Commodore Plus 4.

Non durò molto, soltanto un mese circa, ma grazie alla ricca dotazione di Commodore, sfruttando il monitor integrato nella ROM mi permise di disassemblare l’intero contenuto della ROM del BASIC e parte del kernel, trascrivendo il tutto su un quadernone scolastico, in modo da poterne studiare più comodamente il codice.

All’epoca lo spazio era tiranno e le prestazioni offerte dall’hardware estremamente ridotte, per cui linguaggio macchina e assembly erano i linguaggi d’elezione per lo sviluppo di codice “di spessore”, a maggior ragione per quello che veniva integrato nella ROM del computer, per cui averne un disassemblato non era come essere in possesso del sorgente originale, ma quasi.

La stessa cosa avvenne per il BASIC del Commodore 128, unica (ma più importante per me) parte non coperta dal libro “La bibbia del Commodore 128“, che riportava soltanto il disassemblato (commentato) della ROM del monitor e del kernel.

Il disassemblato del BASIC mi permise di capire come funzionava, com’era possibile estenderne le funzionalità (anche aggiungendo nuovi comandi), ma soprattutto di implementare un turbo tape per questo home computer (non ce n’erano a disposizione all’epoca, e non ricordo di averne mai visti), adattando il Flash Tape per Commodore 64 pubblicato sulle pagine di MC MicroComputer.

Passato dopo un paio d’anni all’Amiga 2000, l’occhio si posò quindi sul Turbo Pascal 3.0: prodotto ovviamente non disponibile per questa macchina, ma all’ITIS in cui studiavo lo si utilizzava per programmare, per cui mi serviva necessariamente.

L’unica soluzione era farlo girare tramite un emulatore PC (8086) interamente software, l’IBeM (precursore del ben più noto PC Task che ha spopolato su Amiga), ma che era decisamente lento, per cui mi balenò nella mente l’idea di realizzarne una versione nativa per questa macchina, dopo avere inutilmente e ingenuamente (beata gioventù) scritto una lettera all’allora Edia Borland che ne curava la commercializzazione in Italia.

Mi armai del comando DEBUG (.COM!) e di un fedele quadernone sul quale trascrivere sempre a mano (ancora niente stampante) tutto il disassemblato per studiarlo, commentarlo, e vedere in che modo era possibile realizzarne un analogo per la più amata macchina di casa Commodore.

Inutile dire che studiarmi un po’ di teoria dei compilatori e riscriverlo da zero avrebbe richiesto meno tempo (anche perché sistema operativo e processore erano completamente diversi), per cui, alla fine, abbandonai quel progetto (d’altra parte finito l’ITIS mi aspettava l’università).

Sempre con Amiga la mia sete di conoscenza mi ha portato a disassemblare altro codice (col fido Resource): in primis la ROM, in particolare Exec (sostanzialmente il kernel) per capire in che modo avveniva la sequenza di boot (in parte ne ho parlato in questo articolo), ma soprattutto il famigerato trackdisk.device per capire come veniva utilizzato il Blitter per la de/codifica delle tracce del disco in formato MFM (lavoro anch’esso inutile, visto che optai poi per l’uso della CPU).

Passato al PC, invece, mi sono dilettato nel reverse enginering di un gioco del video poker (uno dei più vecchi, che metteva a disposizione il jolly per realizzare il cosiddetto “poker jollato”), per il quale ho realizzato una monitor evoluto, cioè una sorta di disassemblatore intelligente con integrato un emulatore della macchina, che mi permetteva di aggiungere etichette alle locazioni o ai dati (e anche commenti) in tempo reale, durante l’esecuzione del codice.

Gli impegni e il lavoro mi hanno portato verso altre strade, anche se qualche anno fa il mio interesse per la virtual machine di Python mi ha condotto nuovamente a smanettare col disassemblaggio, questa volta del bytecode generato e del codice x86 emesso dal compilatore (Visual Studio), anche se per motivi diversi (cercare di migliorarne le prestazioni).

In ogni caso l’assenza del sorgente originale nelle varie occasioni descritte non ha mai rappresentato una barriera invalicabile alla conoscenza, ma anche alle modifiche, del codice prodotto da altri. Hacker e cracker esistono da tempo immemore.

Chi conosce Sysinternals sa che nemmeno le parti più nascoste del kernel di Windows sono sfuggite all’occhio di Mark Russinovich (e anche Sony ha avuto le sue gatte da pelare).

Non v’è dubbio che il sorgente originale rappresenti una gran comodità (anche se bisognerebbe vedere com’è scritto: non poche volte ho preferito riscriverlo da zero piuttosto che cercare di comprendere quello che mi si parava davanti), ma non è la condicio sine qua non per capire come funziona un pezzo di codice, e per effettuarne anche delle modifiche.

Certamente richiede skill più elevate, ma d’altra parte quando si inizia a programmare non si parte certamente col reverse engineering del codice altrui. Si tratta di un naturale processo di maturazione dello sviluppatore che lo porta ad approfondire concetti sempre più complessi, fino ad arrivare, eventualmente, a cimentarsi in operazioni come quelle descritte.

Tutto ciò potrebbe finire in futuro, con l’adozione di sistemi basati sul TCPA (di cui abbiamo già abbondantemente discusso), in quanto è possibile impedire l’accesso al codice (e quindi anche al disassemblaggio, oltre che all’esecuzione tramite debugger avanzati).

Sarà con la diffusione di questi sistemi che, a mio avviso, si potrà assistere a una dicotomia fra closed e open source, per cui avere il codice sorgente in mano potrebbe avere un peso non indifferente. Ma passerà ancora parecchio tempo prima che venga gettato l’n-esimo guanto di sfida agli hacker, che non staranno certo a guardare…

29 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    banryu
     scrive: 

    Bell’articolo, con considerazioni che sento di condividere in toto (per quanta poca cultura in materia possa io avere).

    Circa il fatto di copiare sul quadernone codice: OMG! Questa sì che è passione :D

    Infine volevo segnalare che la path string dell’url del link al sito di Sysinternals è errata.

  • # 2
    MauSeventyOne
     scrive: 

    :) Grandioso…

    Mi hai fatto tornare in mente quando anche io trascrivevo a mano (eh si, ai tempi le stampanti costavano!) i disassemblati del commodore 64.

    Sono stato pure rimandato di matematica in 3za sup. perchè beccato dalla prof a studiare il dissassemblato di Ghosts N Goblins!

    Per non parlare del Flash Tape per Commodore 64 pubblicato su MC MicroComputer (lacrimuccia).

    :D ah bei tempi!

  • # 3
    wdasm32
     scrive: 

    cazzo sei forte ne ho trovato uno che ha la mia stessa malattia ;-).

    E poi un altro cazzo sei forte per tutto quel lavoro che hai fatto sul quaderno perchè mi hai fatto ricordare quando mi segnavo routine e indirizzi per navigare all’interno di eseguibili..

    sono daccordo in pieno, nn serve avere il sorgente per estendere o capire un software.. e soprattuto per migliorarlo (esperienza fatta con una driver del mouse)!

    serve sapere usare un debugger come softice o wdasm32 o un dsassembler come ida e un editor esacimale…. debug del dos
    (ce ne sono una marea)

    sicuramete sarai molto bravo anche adesso che ti “annoi” ;-) con linguaggi di alto livello…

    beh puoi sempre cominicare a crivere un sistema operativo nel tempo libero come sto facendo io per rituffarti nel magico mondo del low level..

    alla prossima..

  • # 4
    avve
     scrive: 

    Non cogli il punto:
    il software closed source vieta espressamente il reverse engineering, all’interno di praticamente ogni EULA, con poche eccezioni legate alle legislazioni locali (che consentono in alcuni stati e in alcuni casi ristretti tale pratica, per lo più per ragioni di compatibilità)
    Quindi che tu venga a fare l’articolo che è una versione espansa del vecchio detto “tutto è open source per chi conosce il linguaggio macchina” mi fa un po’ ridere, ma molto pena.
    DI FATTO un modello permette certe cose, e un altro sì.
    Che poi il cantinaro tipo se ne fotta delle licenze, cambia poco l’assetto mondiale.

    Già che c’eri potevi espandere il discorso su diversi fattori. Ad esempio, parlando di fix: chi è l’owner del processo di fix?
    Penso sempre a questa storia quando sento parlare di Open Source e di come è facilmente aggiornabile e modificabile (e quindi patchabile!) visto che il sorgente è gratuito.
    E’ la storia di 4 persone, chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C’era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciacuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Nesuno capì che Ognuno l’avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

    E questo è emblematico nel mondo OSS, mentre nel closed, chi lo deve fare è chi ha i diritti sul software, punto!

    Così fare software opensource diventa una paraculata per diffondere su internet roba pluribacata e poi non manutenerla perché “E’ open, fattelo te.”. E la cosa brutta è che oramai si è abituata l’utenza media ad avere tutto gratis (che è diverso da open, ma al 99% quando è open è gratis!), e non c’è più mercato per applicazioni commerciali.
    Questo è dumping! Vai a lavorare in fabbrica gratis, poi vedi se gli operai ti sono amici….
    Questa dell’open source doveva essere la lotta alle grandi multinazionali informatiche, microsoft, apple, ecc. Ma queste hanno la schiena robusta e reggono a tutto, e quindi poi alla fine chi ci rimette sono i piccoli sviluppatori, che avrebbero potuto distribuire software commerciali per le esigenze comuni (ed essendo prodotti commerciali avere il tempo e gli interessi economici per manutenerli!), ma attualmente non hanno l’interesse di farlo, visto che per ogni programma commerciale se ne trovano 30 gratuiti, open, e fatti col culo, ma la gente preferisce quelli oppure craccarsi i commerciali (oramai si sono abituati al gratis).

  • # 5
    Emanuele Rampichini
     scrive: 

    @avve
    Come ci sono piccole e grandi realtà che sono scomparse ce ne sono di piccole e grandi che sono nate con e grazie ad un altro modello di business (chiedi a Cesare che licenza ha il framework che utilizza al lavoro).
    Il paragone con l’operaio in fabbrica non ha senso poiché parte dal presupposto che tutti quelli che scrivono codice open lo facciano per campare d’aria e di sogni. I modelli di business cambiano e purtroppo chi non riesce ad aggiornarsi e a trovare un modo per monetizzare i propri sforzi è destinato a scomparire (succede in tutti i campi). La colpa la può dare a chiunque, a qualcuno, a ciascuno o a nessuno ma la realtà è che la colpa è solo la sua.

  • # 6
    Andrea R
     scrive: 

    Tra EULA che vietano il reverse engineering e offuscamento del codice secondo me la dicotomia è già evidente oggi.
    Senza contare che una volta fatta una modifica locale sul sorgente disassemblato uno perde le possibilità di aggiornamento e si deve di fatto mantentere un fork dell’applicazione. Tra l’altro in segreto, perchè non puoi di certo aprirci un progetto su google code.
    Sicuramente è una gran cosa riuscire a studiare e modificare un eseguibile, ma i programmatori di oggi non lo sanno più fare, quindi un’azienda che avesse bisogno deve pagare molto caro questa operazione.
    I problemi “triti e ritriti” del software closed vengono ben poco mitigati dal disassemblaggio, solo il divertimento ed il profitto di chi lo sa fare ne giova.

  • # 7
    Cesare Di Mauro (Autore del post)
     scrive: 

    @banryu: grazie per la segnalazione! :)

    @wdasm32: già da qualche tempo mi frulla in testa l’idea di usare il basso livello per aiutare quello alto. O:-)

    @avve:

    Non cogli il punto:
    il software closed source vieta espressamente il reverse engineering, all’interno di praticamente ogni EULA, con poche eccezioni legate alle legislazioni locali (che consentono in alcuni stati e in alcuni casi ristretti tale pratica, per lo più per ragioni di compatibilità)
    Quindi che tu venga a fare l’articolo che è una versione espansa del vecchio detto “tutto è open source per chi conosce il linguaggio macchina” mi fa un po’ ridere, ma molto pena.
    DI FATTO un modello permette certe cose, e un altro sì.
    Che poi il cantinaro tipo se ne fotta delle licenze, cambia poco l’assetto mondiale.

    Non hai colto lo scopo dell’articolo: chi ha parlato di licenze e legislazione? Non c’è una sola parola in merito, perché il piano è prettamente tecnico: si tratta di vedere ciò che è possibile fare anche avendo davanti un software closed.

    Secondo te quando disassamblavo le ROM dei miei computer Commodore pensavo a queste cose? Assolutamente no, appunto.

    Altra cosa, sempre parlando di quest’argomento, le licenze esistono anche per software di cui si ha la disponibilità del sorgente.
    Vedi la GPL, che ti obbliga a rilasciare i sorgenti che fanno uso di codice da essa coperto. Oppure la licenza con cui Microsoft ha rilasciato i sorgenti di .NET, che t’impedisce di riutilizzarne il codice o farne delle modifiche (puoi solo studiarlo o eseguirne il trace con un debugger).

    Già che c’eri potevi espandere il discorso su diversi fattori. Ad esempio, parlando di fix: chi è l’owner del processo di fix?
    Penso sempre a questa storia quando sento parlare di Open Source e di come è facilmente aggiornabile e modificabile (e quindi patchabile!) visto che il sorgente è gratuito.
    E’ la storia di 4 persone, chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C’era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciacuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Nesuno capì che Ognuno l’avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

    E questo è emblematico nel mondo OSS, mentre nel closed, chi lo deve fare è chi ha i diritti sul software, punto!

    A parte quanto già scritto sopra, questo chi l’ha detto? Non hai scritto prima che bisogna vedere cosa dice la legge? Lo sai che in Italia reverse engineering e modifica di un’applicazione sono consentite se ciò permette di migliorare la fruizione del software?

    Inoltre è già capitato che società terze abbiano rilasciato patch per correggere delle falle.
    Ecco http://www.hwupgrade.it/news/apple/falla-di-sicurezza-in-itunes_15843.html il primo link che ho recuperato con una rapida ricerca. Non credo che Apple le abbia fatto causa…

    Sul resto ha già risposto Emanuele, col quale mi trovo d’accordo (vedi http://www.zeroc.com e i modellI di licenzE che propone per il suo software… open source).

    @Andrea R:

    Tra EULA che vietano il reverse engineering e offuscamento del codice secondo me la dicotomia è già evidente oggi.

    Come dicevo ad avve, questo non era in discussione.

    Senza contare che una volta fatta una modifica locale sul sorgente disassemblato uno perde le possibilità di aggiornamento e si deve di fatto mantentere un fork dell’applicazione. Tra l’altro in segreto, perchè non puoi di certo aprirci un progetto su google code.

    Questo capita anche per progetti open source. Vedi, ad esempio, la distribuzione Linux che utilizza Google, forkata dal ramo ufficiale e mantenuta costantemente aggiornata.

    Poi ti assicuro che non è certo complicato tenere traccia degli aggiornamenti dopo avere già affrontato il grosso delle difficoltà, cioè capire come funziona un certo programma. In genere chi ha crackato un certo programma è anche quello che farà lo stesso per le versioni successive. Facci caso.

    Sicuramente è una gran cosa riuscire a studiare e modificare un eseguibile, ma i programmatori di oggi non lo sanno più fare, quindi un’azienda che avesse bisogno deve pagare molto caro questa operazione.
    I problemi “triti e ritriti” del software closed vengono ben poco mitigati dal disassemblaggio, solo il divertimento ed il profitto di chi lo sa fare ne giova.

    Secondo me questo vale a prescindere dal modello di distribuzione. Tanto per fare un altro esempio, anche per capire, ed eventualmente modificare, il kernel di Linux ci vogliono capacità non indifferenti, vista la dimensione e complessità della code base.

  • # 8
    goldorak
     scrive: 

    Cesare di Mauro ha scritto :
    “on hai colto lo scopo dell’articolo: chi ha parlato di licenze e legislazione? Non c’è una sola parola in merito, perché il piano è prettamente tecnico: si tratta di vedere ciò che è possibile fare anche avendo davanti un software closed.

    Secondo te quando disassamblavo le ROM dei miei computer Commodore pensavo a queste cose? Assolutamente no, appunto.”

    Come, il piu’ grande difensore di metodi antipirateria e TPM e piattaforme chiuse che giustifica il reverse engineering di codice chiuso ? Ma dove va il mondo ? ^_^ Non eri tu che dicevi che il consumatore deve solamente consumare e tenere la bocca ed il cervello chiusi ?
    Senti come le restrizioni che si impongono al codice chiuso (tramite eula e ordinamento giudirico e metodi tecnici) ti sta (stava) stretto anche a te ? Anche se per motivi puramente “didattici” ? Che giustizia poetica, anche il grande Cesare Di Mauro era un pirata.

  • # 9
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ti ricordo che la legge sul reverse engineering risale a pochi anni fa: prima non c’era nulla del genere.

    L’unica legislazione vigente era quella sul copyright (tra l’altro arrivata ben dopo il periodo d’oro di Commodore 64 & co.), e non ho mai fatto uso di ciò che disassemblavo (ho sempre considerato lamer chi si appropriava del codice altrui).

    Quanto al consumatore, non ho mai fatto asserzioni del genere. Quindi o ricordi male o sei in perfetta malafede.

  • # 10
    goldorak
     scrive: 

    Che io ricordi tutti i programmi commerciali da quando esiste il mercato pc, console etc… contenevano una licenza che vietava il reverse engineering. Trovami un programma commerciale che ti autorizzava a disasemblare (anche se per uso prettamente privato). Non esiste. Quindi gia’ il fatto di operare sul codice disassemblato era una operazione illecita (a meno di non detenere i diritti sul codice in questione).

    Sulla seconda frase hai ragione, tu non l’hai mai detta l’ho detta io. Ma l’ho inferita dai tuoi discorso pro-tpm, pro-acta, che hai tante volte ribadito nei tuoi articoli proprio qui su appunti digitali etc… Quindi permettimi di dire che la mia inferenza non e’ proprio campata per aria.

  • # 11
    Pluto
     scrive: 

    @Cesare

    Ti seguo da questo blog da un po’ di tempo perché mi piacciono i tuoi articoli tecnici. Ma, ti devo dire la verità, anch’io ho avuto la senzazione che tu sei un po’ anti-consumatore, anti-piccoloprogrammatore e pro-microsoft.
    Senza offesa, non che tu lo abbia mai scritto.

  • # 12
    banryu
     scrive: 

    @Pluto & @Goldorak:
    Anche io ho sempre letto gli articoli di Di Mauro in questo blog.
    E non ho mai “dedotto” o avuto la sensazione che Cesare fosse anti-consumatore, anti-piccoloprogrammatore e tutte le altre etichette che gli avete attribuito ne vostri due post qui sopra.

    Ma al di là di questo, io penso che questo attribuire etichette all’autore e quindi (di fatto) attaccarlo persornalmente invece di parlare dell’articolo mi sembra poco appropriato per questo spazio: non fornisce spunti per intavolare discussioni interessanti sull’argomento trattato.

  • # 13
    Dario S.
     scrive: 

    La dicotomia fra “chiuso” e “aperto” esiste già adesso, eccome.
    C’è una netta distinzione fra quello che si può fare (anche se illegale, come il reverse engineering) e quelli che possono essere i frutti del tuo lavoro.
    PUOI certamente fare reverse engineering sul kernel di windows, ma dopo che hai scoperto 20 bug critici e li hai patchati, che fai? Manda tutto a Ms: è più probabile che ti arrivi a casa l’FBI piuttosto che i ringraziamenti. TU avrai fatto un bellissimo lavoro, bravo, ma alla comunità non interessa per nulla, perchè solo ms può rilasciare aggiornamenti per il kernel di windows. Il fatto che tu ci fai reverse engineering non sposta la situazione di una virgola. Il software chiuso resta chiuso… anche se te lo decompili.

  • # 14
    Ale
     scrive: 

    Studio, fix e modifiche al codice: *illegalmente e con taaaaanto tempo da buttare nel cesso* anche per quello “chiuso”

  • # 15
    Pluto
     scrive: 

    Per quanto riguarda l’argomento trattato,
    Se un software ha una licenza open sono sicuro che posso modificarlo rimanendo nei confini della legalità, se invece e close
    e lo disassemblo potrei essere sempre nel dubbio che sia illegale.

  • # 16
    banryu
     scrive: 

    @Pluto

    Quote:


    Se un software ha una licenza open sono sicuro che posso modificarlo rimanendo nei confini della legalità, se invece e close
    e lo disassemblo potrei essere sempre nel dubbio che sia illegale.

    Perchè potresti essere nel dubbio? La licenza che accompagna il tuo software closed che vuoi disassemblare non lo permette o vieta espressamente?
    Se non ne fa espressamente menzione, per legge come va interpretato il silenzio?

    Chiedo perchè sono ignorante in materia!

  • # 17
    Pluto
     scrive: 

    Se non ne fa espressamente menzione mi sembra che si possa fare, il problema si ha quando invece c’è scritto.

    Ma allora mi stavo domandando, perché disassemblare un programma close quando posso trovare una alternativa open già “disassemblato”?

    Se invece ho interesse specifico per le funzionalità di un determinato programma, a quel punto mi conviene comprarlo e pagarlo il dovuto.

  • # 18
    banryu
     scrive: 

    @Pluto

    Quote:

    Ma allora mi stavo domandando, perché disassemblare un programma close quando posso trovare una alternativa open già “disassemblato”?


    Beh, ma per curiosità ovviamente! (oddio, ovviamente…)
    Diciamo che un utente programmatore smaliziato potrebbe anche essere semplicemente curioso di vedere cosa fa il software sulla sua macchina (e i possono essere ottime ragioni, vedi il link in riferimento a Mark Russinovich incluso nell’articolo).

    Il tema dell’articolo infatti, a prescindere dalle motivazioni, è la attuale *fattibilità* del’azione conoscitiva di reverse engeneering sui software (open o closed poco importa) che verrebbe poi a mancare, in teoria, con l’adozione del TPA, rendendo il software “closed” tale di nome e di *fatto*

  • # 19
    Pluto
     scrive: 

    Ma se espressamente viene vietato di disassemblaggio viene di fatto vietato anche il “conoscere”.
    Può darsi anche che tu abbia il diritto di conoscere cosa fa un software nella tua macchina, ma il produttore non ha il dovere di garantirtelo, lui vuole proteggere il suo investimento e non vuole che altri leggano e comprendano il codice.

    c’è la licenza “d’uso” non di “cosa fa il software”

  • # 20
    Giacomo
     scrive: 

    @ Pluto – banryu
    il 99,99% dei software closed commerciali (anche la maggior parte di quelli freeware) sono accompagnati da licenze che proibiscono espressamente la modifica, il disassemblamento e il reverse engineering dell’eseguibile.
    Credo che anche l’attuale legislazione sul software impedisca questi atti sul software closed, per cui paragonare le modifiche al software open e a quello closed come equivalenti, come descritto nell’articolo, mi sembra improprio e fuorviante.

  • # 21
    Cesare Di Mauro (Autore del post)
     scrive: 

    banryu ha centrato perfettamente i termini della questione.

    @goldorak: ricordi male. Fino agli anni ’80 in Italia non c’era nulla. POI è stato introdotto il copyright. Qualche anno fa è stato introdotto il divieto di reverse engineering e modifica (se non alle condizioni che avevo già citato). Informati.

    Cerchiamo, inoltre, di distinguere fra copyright e altri diritti/licenze (come quello di reverse engineering).

    Per il resto avete inferito male tu e Pluto.

    Dal punto di vista del mercato sono un ultraliberista: piena libertà per i produttori di realizzare e vendere i loro prodotti come gli pare (tranne se infrangono proprietà intellettuali altrui), e piena libertà ai consumatori di scegliere se acquistare o meno i prodotti sul mercato; il mercato si regolerà di conseguenza (“se non compro muori di fame, quindi devi scendere a compromessi”).

    Pertanto sono anche pro-TCPA/TPM/ecc. perché tutelano i produttori dalle copie e/o utilizzi non autorizzati.

    Per me consumatore = titolare di licenza alla fruizione di un bene. Quindi escludo automaticamente gli scrocconi da quest’insieme.

    Infine non capisco come abbiate potuto dedurre che sono anti-programmatori (li metto tutti: grandi e piccoli): sono un programmatore anch’io, e fino a prova contraria ho interesse a sviluppare.

    Ridicola poi l’etichettura pro-Microsoft. Bisogna scendere veramente così in basso in una discussione squisitamente tecnica? Dovreste imparare a focalizzare l’attenzione sui FATTI. E se per un determinato fatto la mia posizione concide in maniera contingente con quella di Microsoft, in base a quale “logica” mi si può dire di essere pro-Microsoft? Vi rendete conto di quello che affermate?

    La mia libertà di pensiero non si piega alla monocultura che circola troppo spesso (dove esistono soltanto alcune posizioni “lecite”). Possono non piacervi, ed è comprensibile (ognuno ha le sue), ma evitate etichettature che lasciano il tempo che trovano.

    @Dario S.: un link su Apple l’ho fornito prima. Altri su Microsoft li puoi recuperare facilmente.

  • # 22
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Giacomo: come già ampiamente discusso, l’articolo discute della fattibilità TECNICA o meno.

    Non di questioni legali che, in quanto tali, dipendono esplicitamente dal paese in cui si lavora. In Cina, tanto per portare l’esempio più noto, si può fare di tutto; anche copiare il software.

  • # 23
    Giacomo
     scrive: 

    @ Cesare
    d’accordo, ma converrai che per forza di cose andare a mettere il naso in un eseguibile chiuso, magari blindato con tecniche di offuscamento, o con dongle hardware, sia per forze di cose più faticoso e meno produttivo di un eseguibile del quale si abbia il sorgente.. e oltretutto spesso gli sforzi ottenuti devono essere ripetuti nel momento in cui l’eseguibile venga aggiornato dal produttore, magari reso più blindato da ulteriori tecniche antificcanaso.
    Francamente paragonare i due mondi mi sembra paragonare mele con pere, comunque just my 2 cents :)

  • # 24
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’ho scritto chiaramente nell’articolo. ;)

  • # 25
    banryu
     scrive: 

    @Pluto

    Quote:

    Può darsi anche che tu abbia il diritto di conoscere cosa fa un software nella tua macchina, ma il produttore non ha il dovere di garantirtelo…

    Ammettiamo per amor di discussione che un utente proprietario di un computer abbia sempre il diritto di conoscere cosa fa un qualsiasi software con la sua macchina.

    Chi produce e vende software all’utente finale non ha il “dovere di garantire” l’esercizio di questo diritto da parte dell’acquirente, ma forse non ha neanche il diritto di “impedire o comunque ostacolare attivamente” l’esercizio dello stesso?

    Mi sa che la questione non è del tipo o bianco o nero, ma è una questione di grado.

    Con la situazione attuale un produttore/venditore di software “closed” può rilasciare il prodotto con una licenza che dichiara illegale il fatto di disassemblare il software, ma niente impedisce *di fatto* all’utente, avendone le capacità, di farlo lo stesso. Incorerenza? Forse, o forse è una di quelle classiche “pieghe del sistema” per salvare, in alcuni contesti, capra & cavoli.

    Con l’introduzione del TPA, se non ho capito male l’articolo di Cesare, verrebbe impedito anche *di fatto* l’accesso alla conoscenza di cosa fa il software con la tua macchina a runtime.
    Qunindi cambia l'”equilibrio” e *di fatto* tu utente non hai più il diritto di conoscere cosa fa un qualsiasi softwarecon la tua macchina.

    A questo punto mi piacerebbe sapere cosa dice la legge (italiana, ad esempio) in materia, e le vostre opinioni.

  • # 26
    Francesco
     scrive: 

    Assolutamente non d’accordo!
    Certo, non ci vuole il sorgente per capire come funziona il codice se devo fare una banale fix, ma se devo estendere il funzionamento, è tutto un altro discorso.
    Proprio il fatto che il codice sia open porta a codice scritto ( abbastanza) bene da renderlo leggibile e facile l’estensione. Prova a fare lo stesso con un debugger. Sarebbe come imparare a capire com’è fatto un motore di una macchina guardandolo dall’esterno.
    Infine c’è il discorso, appunto, che spesso non è legale fare reverse engineering con il closed-source.

  • # 27
    Dario S.
     scrive: 

    @Cesare:

    io ho fatto un esempio con MS, ovvero la prima software house che m’è passata per la zucca, ma non era quello il punto.

    Cerco di spiegarmi: tu puoi disassemblare qualunque cosa, il problema è che è ILLEGALE. Anche se sei un curiosone e non sviluppi nulla.

    Il post si poggia sul fatto “che tanto chissenefrega”, in un’ etica puramente hacker. Questo va pure bene (sono io stesso il primo a smanettare), ma quando poi vai a confrontare software libero vs commerciale la discussione non si pone nemmeno: il software commerciale è nel 99% dei casi intoccabile. *Commercialmente* e *legalmente* parlando l’etica hacker non vale proprio niente.
    Non esiste nessuna azienda che prenderebbe il prodotto X per decompilarlo: non ti prenderebbero nemmeno in considerazione.
    A Sysinternals è andata meglio? Questo non significa nulla: a Russinovich è andata bene, ma poteva finir denunciato.

    Perciò, anche se per certi versi decompilare è una pratica perfino accettata, in un confronto fra software libero vs privato non può in nessuno modo essere presa in considerazione.

  • # 28
    homero
     scrive: 

    “anche se bisognerebbe vedere com’è scritto: non poche volte ho preferito riscriverlo da zero piuttosto che cercare di comprendere quello che mi si parava davanti”

    sottoscrivo in pieno quanto espresso da cdmauro. per analizzare il codice opensource di un software complesso sono alle volte necessari mesi….pertanto l’opensource non vuol dire assolutamente che chiunque puo’ mettere le mani al codice, ma richiede un investimento di tempo-uomo alle volte insostenibile anche per medie aziende.

    commuovente il suo percorso nell’analisi del codice negli anni d’oro del PC che è descritto nell’articolo….

    per il futuro non so cosa accadrà con grande probabilità agli utenti sarà impedito di attraversare il layer di esecuzione delle applicazioni e quindi la figura del programmatore freelance potrebbe limitarsi ad ambienti ben delimitati (ambiente python, php, ruby, java..) eliminando totalmente il contatto con il layer che ha accesso all’hardware della macchina)

    in realtà la vera incognita sono i nuovi sistemi di calcolo basati su nanotecnologie che sfruttano la fotonica o la meccanica quantistica, che permetterebbero (si noti il condizionale) prestazioni del’ordine di grandezza di circa 10^6 rispetto ai sistemi attuali, immaginatevi cosa potrebbe fare unhacker con un sistema del genere in casa sua, allora le aziende si preparano a separare l’hardware dal software in maniera definitiva in modo da custodire questa enorme potenza di calcolo nelle stanze di pochi……
    inoltre verrebbe eliminata anche la necessità di aggiornare un sistema ogni 2-3 anni ma la vita di un sistema di calcolo sarebbe allineata a quella di un’automobile o di un elettrodomestico, circa 10-15 anni….
    insomma la rivoluzione continua a passare sulle nostre teste e io mi sento un dinosauro nonostante la mia giovane età….

  • # 29
    j
     scrive: 

    Francesco

    Certo, non ci vuole il sorgente per capire come funziona il codice se devo fare una banale fix, ma se devo estendere il funzionamento, è tutto un altro discorso.

    ma che l’ utente modifichi il programma a livello di funzionalità, in proprio, è proprio quello che una sw house vuole evitare che accada – ed è giusto che sia così
    poni che poi lo smanettone si metta a distribuire la versione modificata, ci si ritroverebbe a dover fronteggiare richieste di supporto (o anche solo di chiarimento, che creano comunque fastidi quando intasano forum e caselle email) sulle funzionalità di quello che in effetti un fork non ufficiale – e non è un’ eventualità fuori dal mondo, è successo in vari casi, Paint.net l’ ultimo in ordine di tempo

    Proprio il fatto che il codice sia open porta a codice scritto ( abbastanza) bene da renderlo leggibile e facile l’estensione.

    ai tempi di diamonds su hwu, quando qualcuno si accostava (pur sapendo magari già programmare in java) per la prima volta al codice, immancabilmente faticava non poco a comprendere le responsabilità delle varie classi e il funzionamento dell’ ambaradan – e questo nonostante le classi fossero dieci in croce e composte di codice oggettivamente leggibilissimo (conseguenza dell’ avere un checkstyle enforced e un coach che minacciava di spezzare le ditine a chi scriveva in modo meno che ortodosso :D)

    per estendere una code base devi prima padroneggiarla, per padroneggiarla devi prima assimilarne struttura, convenzioni, finanche idisiosincrasie, e in certo qual modo ripercorrere i ragionamenti che hanno portato a quel design e a quella implementazione
    ora, il codice altro non è che la stesura di una soluzione concepita da altri, a un problema che magari si risolverebbe in modo differente – per questo, tipicamente non è nè facile nè immediato assimilare il modo di ragionare di altri, già potendolo fare da una documentazione
    entrare nella testa dello sviluppatore partendo dal codice è ancora meno “facile”, e non è poi (molto) diverso dal farlo decompilando l’ eseguibile (infatti si parla di reverse engineering anche riguardo la creazione dei driver per i sistemi operativi BSD, costretti a desumere le specifiche dal codice dei driver omologhi per linux – non riutilizzabili in quanto coperti da GPL – per poi scriverne di nuovi)

    quando poi la codebase è vasta, contorta e bloated come nel caso di open office e gimp, lo è ancora meno …

    Dario

    Il post si poggia sul fatto “che tanto chissenefrega”, in un’ etica puramente hacker

    credo che il post si basi su altro, però scritto tra le righe e quindi inavvertito da chi è passato e ha letto superficialmente ( tutti, finora)
    ovvero, da una parte il fatto che esiste sw proprietario e commerciale che pur essendo tale, non è comunque segreto, essendo il suo codice disponibile (a determinate condizioni) a fini di studio (vedi il WRK) o di sicurezza (da parte di enti governativi, società di settore ecc)
    e dall ‘altra la differenza tra uno stato attuale in cui lo smanettone può comunque ancora studiare (a prescindere dalla legalità o meno dell’ operazione) il comportamento del sw, e un ambiente fully trusted in cui non potrà più farlo dovendo il sw escludere il tampering, e soprattutto essere certificato a monte come proveniente da fonti a loro volta certificate – scenario in cui diviene obbligatorio fidarsi dei certificatori, ma si presume questi siano agenzie governative o enti alle dipendenze di queste..

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.