Follow along with the video below to see how to install our site as a web app on your home screen.
Nota: This feature may not be available in some browsers.
Ma allora i software proprietari non sono poi cosi tanto "proprietari" appunto... Cioè, non ci sono dei modi sicuri per non fare reversare il codice?Sì e no.
Non è possibile risalire direttamente al sorgente c++, ma si può facilmente risalire all'assembler generato dal compilatore.
Ci sono svariati modi di offuscare quest'ultimo, ma finchè un programma è eseguibile da un computer, un umano dotato di sufficente pazienza e abilità nel reversing sarà sempre in grado di reversare il programma
Ciò che un uomo crea, un altro uomo può distruggere. Così come non esiste un pc sicuro se non un pc spengo, allo stesso modo non esiste un eseguibile sicuro, se per sicuro intendi impossibile da reversare.Ma allora i software proprietari non sono poi cosi tanto "proprietari" appunto... Cioè, non ci sono dei modi sicuri per non fare reversare il codice?
Era questa la spiegazione che chiedevo, grazie. Imparando il reversing imparo anche a creare qualche trick del genere? Oppure sono cose diverse?Pester come ti dicevo esistono diversi metodi, ti spiego brevemente le funzioni di quelli che ti ho menzionato.
Trick antidebug
Ce ne sono dei più disparati ma tutti servono per un motivo: riconoscere se un debugger è "attaccato" al programma.
Il più delle volte consiste nel leggere nel PEB se i flag di debug sono true, misurare i tempi di esecuzione di determinate porzioni sensibili del programma ecc...
Packer/Crypter
Consistono in un software che comprime il tuo programma per renderlo più piccolo di dimensioni. Molti packer oltre a diminuirne la dimensione rimuovono la import table e reindirizzano. Di default utilizzano trick antidebug e decryptano a runtime porzioni di condice prima di eseguirle (questo impedisce un analisi statica del software packato).
I packer sono molto comuni e ce ne sono alcuni più complicati di altri ma alla fine nella maggior parte dei casi dopo che il codice del packer è stato eseguito il controllo viene trasferito al tuo software.
Obfuscator
Offuscano come dice il nome il codice ed aggiungono del codice spazzatura (junk) in mezzo alle istruzioni reali.
Utilizzato per distrarre i reverser alle prime armi o con poca dimistichezza, un reverser alle prime armi tenterà di capire il significato di codice spazzatura perdendo tempo (il developer spera che perdita di tempo porti alla resa)
Dongle
Utilizzati per lo più per bloccare la distribuzione illegale di software. La maggior parte di essi vengono utilizzati come una licenza.
Il top dei dongle sono quelli che al loro interno contegono chiavi per decriptare il codice o addirittura porzioni di codice necessarie per eseguire il software. Sono molto sicuri ma se un bravo reverser riesce ad avere il software e fisicamente il dongle in mano anche queste protezioni cadono inesorabilmente.
Come vedi sono tutti metodi ed escamotage per tentare di bloccare/rallentare l'analisi del software. Come ti dicevo nel post precedente se un software è appetibile niente fermerà il reverser avanzato.
Conoscere più o meno bene il reverse engineering, non necessariamente significa essere anche in grado di sviluppare autonomamente una protezione. Aiuta sicuramente a capire come essa funzioni, ma la fase di sviluppo non è scontata ed è necessario dello studio in più per questo. Esistono, come giustamente segnalato, vari metodi per proteggere più o meno bene il software. Io consiglio di usare quelli perchè la probabilità di riuscir da soli a creare qualcosa di meglio è davvero bassa. Certo c'è anche il risvolto della medaglia, nel senso che prima o poi usando protezioni commerciali queste saranno prese di mira dai reverser e, prima o poi, sconfitte. Però tutto sommato se si rimane abbastanza aggiornati si ha un buon respiro.
Si e no. Parti dal presupposto che per quanto sia buona la tua protezione, questa si può bypassare. E questo indipendentemente dalle competenze di chi la scrive. Fermo restano questo, in un modo idealela logica vorrebbe che quello che dici sia sensato, ovvero: sono bravo e quindi scrivo una protezione migliore di quelle in commercio. Nel mondo reale però il dicosrso è molto diverso. Infatti scrivere da 0 una protezine "buona" è qualcosa di molto complesso e che richiede molto tempo, spesso questo è fatto non da una ma da un team di persone. Ma per una persona che vuole proteggere il proprio software, il tempo necessario per scrivere una protezione non è trascurabile, e pertanto inficia sul suo budget totale. In definitiva quindi è molto più redditizio usare una protezione commerciale, ed implementerla BENE. La maggior parte delle volte i problemi nelle protezioni infatti sta proprio nell'implementazione superficiale o frettolosa. Rimuovere winlicense da un software dove è semplicemente stata nserita una chiave che blocca l'apertura del software, è molto motlo diverso dall'inserire anche dei controlli vari che bloccano le funzionalità, e che usino le piene potenzialità dell'SDK. Sono tute cose già pronte, che è molto difficile produrre autonomamente.È pure vero che i sistemi di protezione commerciali sono pur sempre creati da persone. Perciò questo vale fin quando non hai competenze elevate perché quando questo accade è anche probabile che superi i sistemi di sicurezza perfino commerciali. Sbaglio?