Bonnox (Member)
Pro
 
Messaggi: 85
Iscritto: 23/08/2014
|
Buongiorno (o buonasera)
volevo chiedervi se sapete come fare questa cosa strana.
Il professore di Java ci ha detto che i nostri esercizi saranno controllati da un "sistema antiplagio" che riconosce la struttura del programma e può determinare se sia stato copiato da altri.
Io e i miei compagni che siamo bravi a programmare pensavamo che non sarebbe possibile la vecchia tecnica (molto alla ScuolaZoo  ) del passare il testo via wazzap durante l'esame e poi mandare la soluzione, in quanto una persona fa una sola soluzione e la passa a X persone, tali persone verranno indagate per plagio.
Ora, a parte il fatto che abbiamo già sostenuto l'esame e non ci interessa far copiare nessuno (si diceva così per dire), mi piacerebbe sapere se fosse possibile aggirare questo sistema; ovviamente per scopi didattici.
Se la precedente motivazione non vi basta a trattenervi dal chiudere il topic, ne aggiungo un'altra: ho scoperto un fantastico programma che permette di disassemblare i file class, e incredibilmente funziona benissimo! Riporta il byte-code quasi alla forma originaria del sorgente!
Ovviamente non credo che un programmatore voglia permettere questa cosa. Ho sentito dire che le case software di un certo livello hanno dei compilatori che sporcano il codice con istruzioni inutili... peccato che non so dove trovarne e che a me interessa il Java.
Sapete di qualche algoritmo per riempire il sorgente java di istruzioni inutili senza effettivamente scriverle personalmente? Oppure esiste un plugin di Eclipse?
ciao
|
|
|
TheDarkJuster (Member)
Guru^2
Messaggi: 1620
Iscritto: 27/09/2013
|
Dovresti implementare un analizzatore lessicale e un albero sintattico per poi aggiunge istruzioni inutili, ad esempio due xor con la stessa maschera..... Però quelle cose di cui parli sono offuscatori e non agiscono sul sorgente ma al file già compilato.
|
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
Tali sistemi anti-plagio hanno delle ovvie limitazioni; è possibile rappresentare la stessa istruzione in un infinito numero di modi. Questi sistemi funzionano per beccare gli ovvi copia-incolla, quelli che hanno semplicemente cambiato i nomi delle variabili / metodi e magari spostato un pò di codice qua e là. Trovo che cambiando ogni singola istruzione o set di istruzioni con un equivalente set di istruzioni, il sistema non noterebbe nulla. C'è poi il fatto psicologico, che gli studenti non sono a conoscenza dei dettagli del sistema anti-plagio, quindi il rischio di sotto-stimare la sua validità da solo non merita il tentativo di provare a superarlo.
I disassemblatori funzionano bene fintanto che il codice non è offuscato. Una volta offuscato, l'unica maniera per condurre una buona analisi è di analizzare il bytecode manualmente (un tantino più difficile).
Ultima modifica effettuata da pierotofy il 19/07/2015 alle 2:15
|
|
|
HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
Secondo me è un deterrente psicologico 
|
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
Postato originariamente da HeDo:
Secondo me è un deterrente psicologico |
Probabile.
|
|
|
Bonnox (Member)
Pro
Messaggi: 85
Iscritto: 23/08/2014
|
ok grazie per le risposte.
Ma voi con "offuscare il codice" intendete quello stile di scrittura del C in cui si mettono tante cose in una sola istruzione e si usano i costrutti meno comuni per rendere il codice meno leggibile oppure è un'operazione da eseguire sul byte-code?
No perchè nel vedere che mi ha riportato il sorgente quasi intatto all'inizio ho esultato, poi ho fatto 2+2 e ho iniziato a preoccuparmi
dunque per i sistemi antiplagio (mi piacerebbe averne uno per vedere cosa fa) basta riscrivere l'algoritmo? quindi ad esempio invece di un for faccio un goto per simulare il ciclo? Comunque se ci sono alcune classi collegate tra loro non si può far niente, giusto?
|
|
|
HeDo (Founder Member)
Guru^2
Messaggi: 2765
Iscritto: 21/09/2007
|
Allora, facciamo un po di chiarezza:
1) Per linguaggi compilati nativamente come il C/C++ l'offuscazione del codice è più semplice perchè non c'è un modo univoco di interpretare le istruzioni dell'assembly al fine di riottenere il sorgente iniziale. I sistemi di offuscazione implementano tecniche di criptazione a runtime e molte altre cose che possono rendere virtualmente infattibile il reversing.
2) Per linguaggi compilati in "bytecode" come Java o anche tutto il .NET la situazione è differente, in quanto la maggior parte delle ottimizzazioni che rendono complicato ritornare al sorgente vengono spostate nel JIT. Il codice intermedio è molto più difficile da offuscare in quanto contiene istruzioni ad alto livello facilmente interpretabili. Esistono tuttavia dei buoni offuscatori che rendono difficile capire il sorgente decompilato, non impediscono di decompilare il sorgente. Ad esempio possono rinominare tutti i nomi presenti con identificatori privi di significato. Possono riempire il codice di goto per rendere più difficoltoso capire cosa fa, etc...
La cosa che bisogna tenere bene a mente è che nessun sistema, per quanto sofisticato e ben realizzato, mette al riparo dalla decompilazione. Esisterà sempre qualcuno che ci riuscirà, sta tutto nella determinazione e nell'importanza che il codice ha.
Quindi, per concludere, non ti crucciare, senza un offuscatore con i contro cavoli stai virtualmente distribuendo il tuo sorgente in chiaro. E non c'è nulla che tu possa fare al riguardo.
|
|
|
Bonnox (Member)
Pro
Messaggi: 85
Iscritto: 23/08/2014
|
Postato originariamente da HeDo:
Allora, facciamo un po di chiarezza:
1) Per linguaggi compilati nativamente come il C/C++ l'offuscazione del codice è più semplice perchè non c'è un modo univoco di interpretare le istruzioni dell'assembly al fine di riottenere il sorgente iniziale. I sistemi di offuscazione implementano tecniche di criptazione a runtime e molte altre cose che possono rendere virtualmente infattibile il reversing.
2) Per linguaggi compilati in "bytecode" come Java o anche tutto il .NET la situazione è differente, in quanto la maggior parte delle ottimizzazioni che rendono complicato ritornare al sorgente vengono spostate nel JIT. Il codice intermedio è molto più difficile da offuscare in quanto contiene istruzioni ad alto livello facilmente interpretabili. Esistono tuttavia dei buoni offuscatori che rendono difficile capire il sorgente decompilato, non impediscono di decompilare il sorgente. Ad esempio possono rinominare tutti i nomi presenti con identificatori privi di significato. Possono riempire il codice di goto per rendere più difficoltoso capire cosa fa, etc...
La cosa che bisogna tenere bene a mente è che nessun sistema, per quanto sofisticato e ben realizzato, mette al riparo dalla decompilazione. Esisterà sempre qualcuno che ci riuscirà, sta tutto nella determinazione e nell'importanza che il codice ha.
Quindi, per concludere, non ti crucciare, senza un offuscatore con i contro cavoli stai virtualmente distribuendo il tuo sorgente in chiaro. E non c'è nulla che tu possa fare al riguardo.
|
grazie a tutti  |
|
|
pierotofy (Admin)
Guru^2
Messaggi: 6230
Iscritto: 04/12/2003
|
Postato originariamente da HeDo:
Esistono tuttavia dei buoni offuscatori che rendono difficile capire il sorgente decompilato, non impediscono di decompilare il sorgente. Ad esempio possono rinominare tutti i nomi presenti con identificatori privi di significato. Possono riempire il codice di goto per rendere più difficoltoso capire cosa fa, etc...
|
Per essere più precisi, un offuscatore fa più di una semplice rinonimazione dei nomi di variabili e metodi. Può cambiare il flusso di istruzioni, creare metodi proxy, firmare il codice, criptare risorse, aggiungere istruzioni invalide e altro. Quella di aggiungere istruzioni invalide è particolarmente interessante perchè rende inutili la maggior parte dei decompilatori disponibili al pubblico.
Confuser è il mio preferito per .NET. https://confuser.codeplex.com/wikipage?title=Invalid%20Meta ...
https://confuser.codeplex.com/documentation Ultima modifica effettuata da pierotofy il 19/07/2015 alle 16:53
|
|
|
