Domanda Reversing E' possibile risalire ad un sorgente?

Stato
Discussione chiusa ad ulteriori risposte.

BhuDd

Utente Emerald
8 Maggio 2012
876
149
50
456
Ciao ragazzi, mi chiedevo se fosse possibile risalire al sorgente di un file exe compilato in c++.
Me lo chiedo visto che ne sto scrivendo uno.
Se fossi possibile risalire al sorgente c'è un modo per evitare che questo accada?
 
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
 
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
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?
 
Risalire al "sorgente" come probabilmente intendi tu è impossibile.
Come dice __ puoi disassemblare facilmente un programma scritto in C++, addirittura con IDA Pro è possibile generare per una determinata funzione del tuo software uno pseudo C da cui un reverser può partire per replicarne il funzionamento.

Esistono un sacco di metodi per rendere il lavoro più difficile, trick antidebug, packer, obfuscator e dir si voglia. Se te la cavi con l'inglese posso linkarti qualcosa da leggere per proteggere un po' meglio il tuo codice.

Considera comunque che se un software è appetibile e soprattutto diventa diffuso nessuna delle soluzioni che attuerai serviranno per fermare il reverser dal crackarlo, estrarre funzionalità ecc..

I metodi migliori attualmente per proteggere un software sono:
- Comunicazione con un server online ed effettuare check e/o decrypt del codice a runtime
- Utilizzare dei dongle per proteggere il software (uno che reputo ottimo se configurato a dovere è SenseLock)
 
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?
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.
Come vedi quando esce un nuovo gioco dopo poco vedi la crack su internet. Cos'è la crack? Semplicemente l'eseguibile, o occasionalmente altri file, modificati a dovere per eludere i controlli di sicurezza. Di metodi di sicurezza non ne conosco, anche perché non me ne occupo molto, ma posso dirti che per ogni protezione applicata ci sarà sempre un ragazzo pronto a eluderla, basta solo sapere cosa fare.
Tornando in topic, non è possibile, a partire da un eseguibile risalire ad sorgente scritto in C++ (perchè se non sbaglio esiste qualche linguaggio al quale si può applicare una ricostruzione parziale). Il sorgente che tu stai scrivendo, una volta compilato, non sarà recuperabile in alcun modo dall'eseguibile. Ma è possibile risalire, più o meno facilmente, alle istruzioni che il tuo programma esegue, in un linguaggio (assembly) abbastanza diverso da quello di alto livello, e che descrive le istruzioni una per volta tenendo conto delle operazioni che il processore deve svolgere sui registri. Puoi quindi notare come l'assembly sia un linguaggio molto più vicino alla macchina di quanto non lo sia un linguaggio di alto livello quale il C++, ma lo svantaggio principale di scrivere un programma in assebly è la mancanza di portabilità, la difficoltà di scrittura e la lunghezza delle istruzioni. Ecco perchè si preferisce un linguaggio di alto livello all'asm, ma sto divagando e.e
 
Eagle ti ringrazio ma sembra che non mi conosci, mi hai preso un po per ignorante ahaha
Tutto quello che hai scritto lo so, volevo solo conoscere qualche metodo per limitare il reversing del codice. Tutto qua...
 
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.
 
  • Mi piace
Reazioni: Pester
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.
Era questa la spiegazione che chiedevo, grazie. Imparando il reversing imparo anche a creare qualche trick del genere? Oppure sono cose diverse?
 
Diciamo che il miglior modo per imparare e a creare questi trick è sconfiggerli. :evvai:
Una buona parte di questi li puoi trovare implementati in packer e crypter. Non so quale sia il tuo livello di reversing e quali conoscenze di assembly hai ma se non hai esperienza ti conviene partire dai packer più semplici e andare mano a mano a salire. :sisi:

Il reverse engineering etico sta proprio in questo, imparare a disfare per poter creare meglio.
Reversare ti renderà un miglior softwarista sicuramente. :)
 
  • Mi piace
Reazioni: Pester
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.
 
  • Mi piace
Reazioni: Pester
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.

È 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?
 
No non ti sbagli ma per arrivare a questo risultato ti servono anni di duro lavoro, studio e sperimentazione. Se reversando capisci studiando approfondisci e dovresti arrivare al punto in cui sai riprodurre quello che hai reversato (e di conseguenza creare qualcosa di più complicato ove possibile).

Questo è un discorso ottimista. Molte persone si fermano prima per pigrizia o mancanza di basi solide. Ma se persisti e non ti fermi alle difficoltà tutto è possibile! :)
 
  • Mi piace
Reazioni: Pester
È 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?
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.
 
  • Mi piace
Reazioni: Pester
Stato
Discussione chiusa ad ulteriori risposte.