Newsgroup: it.comp.aiuto
Titolo: Decodificare .EXE

scritto un file eseguibile (.EXE;.COM)?
in linea di massima e' impossibile dato un programma compilato (.exe o
.com) risalire al suo sorgente, al massimo si puo' ottenere (mediante
un disassemblatore) il listato assembler del programma. Pensaci bene,
il compilatore trasforma le linee di sorgente in istruzioni elementari
per la cpu ogni riga di codice puo' dare a origine a molte istruzioni,
come potrebbe un ipotetico programma risalire righe di sorgente che le
hanno generate ? e i nomi delle funzioni e delle variabili ?
     _______ _____         
    / _____// ___ \     Gianpaolo Bottin  - 
bott...@mbox.vol.it
 
   / /____ / /__/ /     Bruino (TO) - Italy
  / //_  // ___  <      
 / /__/ // /__/ /       "Se i costruttori costruissero come i programmatori programmano,
/______//______/        il primo picchio che passa potrebbe distruggere la civilta'."

Ciao a tutti,
sono un neofita del computer quindi scusate la domanda se vi sembrerà
stupida.
Utilizzando per programmare il linguaggio PASCAL (a scuola non si fa di
meglio) e "trasformando" i miei programmi in eseguibili mi sono posto una
domanda: è possibile riaprire un file EXE per riottenere il file sorgente.
Eventualmente questo è possibile per tutti i file eseguibili, oppure è
necessario avere un programma per ognuno dei linguaggi di programmazione?
E, in questo caso, come si fa a scoprire con quale programma è stato
scritto un file eseguibile (.EXE;.COM)?
grazie in anticipo
-- 
Daniele Lanini
d.la...@iol.it
http://www.geocities.com/SiliconValley/Park/1730

hanno generate ? e i nomi delle funzioni e delle variabili ?
Tutto vero fin quando si rimane nell'ambito Pascal.
Ricordiamo che il Pascal e' un compilatore e pertanto trasforma le
istruzioni "sorgente" in istruzioni "macchina" direttamente (dopo il
linker utilizzate dal computer).
Se il linguaggio non e' un compilartore o uno pseudo-compilatore, come
il Clipper (il quale trasforma le istruzioni "sorgente" in "p-code", a
meta' tra codice macchina e sorgente) e' possibile una decompilazione
che riporta indietro proprio al sorgente.
Comunque finche' si rimane nell'ambito del compilatore puro (Pascal,
C/C++ ecc...) questo non accade.
Siddharta
 

hanno generate ? e i nomi delle funzioni e delle variabili ?
E invece e` possibile ! ;-)
Fino a qualche tempo fa, di programmi del genere ne ho visto in giro
un bel po' (come descrizioni) ed io ne ho usato uno per recuperare il
MIO sorgente (che avevo perduto) da un MIO vecchio programma  EXE
compilato con Clipper Summer 87 : mi ha tirato fuori il coniglio dal
cappello a cilindro meglio di Silvan ! ;-)  E mi ha ammannito persino
il flowchart !! Mi pare che si chiamasse Walkyrie.
Si`, ce ne vuole uno per ogni linguaggio di programmazione. O, almeno,
tutti quelli che ho visto in giro erano monolinguaggio. E di quello
che ho usato io ve ne era uno per ogni versione del Clipper fino alla
5.x.
Non so se ne esistano per il Pascal ma ricordo benissimo di averne
visto uno che serviva a decodificare una delle versioni del Basic
(Gwbasic o BasicA). 
Sul come avvenga il processo di decodifica ho soltanto idee piuttosto
vaghe: i compilatori di linguaggi di alto livello si appoggiano alle
librerie di ciascun linguaggio per espandere le macro istruzioni in
una serie di blocchi di istruzioni elementari. E i decodificatori
riescono ad indentificare inizio e fine di tali blocchi e,
appoggiandosi a loro volta alle librerie del linguaggio, riconvertono
i singoli blocchi in macroistruzioni. .... Beh, non pretendere che sia
oro colato ;-)
Ciao
 
Tommaso Friscia - Sciacca (Ag)
Email: 
fri...@sciacca.mediatel.it

hanno generate ? e i nomi delle funzioni e delle variabili ?
Hai ragione. Tuttavia esistono dei compilatori che utilizzano la
tecnologia detta p-code: il sorgente viene compilato non in assembler
ma in un linguaggio interno un po' piu' potente. Il file .exe generato
presenta un'area in cui e' registrato il programma che legge il p-code
e un'altra in cui c'e' il p-code vero e proprio. Bene, se non ricordo
male, esistono dei programmi che risalgono al sorgente dal .exe e, se
ci sono le informazioni di debug, anche ai nomi di variabili e
funzioni. Uno dei compilatori che usano questa modalita' e' il Clipper
ma ce ne sono molti altri.
Ciao,
Felice
      _________  ___                                             
     /  ______/ /   |        Felice "Lord Felix" Mainolfi        
    /  /_|_|\ \/ /| |     Studente di Ingegneria Elettronica     
   /   ____/ \__/ | |     Universita' degli  Studi di Napoli     
  /  /   | |      | |              "Federico II"                 
 /_ /    |_|      |_|   ______________________________________   

i singoli blocchi in macroistruzioni. .... 
questo e' vero solo per linguaggi che non vengono realmente compilati
come appunto il basic e il clipper. Ritengo che sia ben difficile se
non impossibile poter decompilare un programma C ed ottenere qualcosa
di sensato.
     _______ _____         
    / _____// ___ \     Gianpaolo Bottin  - 
bott...@mbox.vol.it
 
   / /____ / /__/ /     Bruino (TO) - Italy
  / //_  // ___  <      
 / /__/ // /__/ /       "Gli errori che non si trovano hanno un'infinita varieta',
/______//______/        mentre quelli che si trovano sono per definizione finiti."

 riescono ad indentificare inizio e fine di tali blocchi
Riconoscono  appunto  un'insieme  di istruzioni   come "output"  della
compilazione da  linguaggio X a  linguaggio  Y (i.e. assembler  di una
certa CPU), e quindi lo  traducono di nuovo  in una istruzione (non le
chiamerei macro) del linguaggio.
o   oooooo	Gian Uberto Lauri        "So, are you working on finding
      o    o	
sa...@maya.dei.unipd.it
   that bug *now* or leaving it until
     o o				  later?" - "Yes!" 

C/C++ ecc...) questo non accade.
Salvo avere una specie di "controtraduttore". Mi spiego: e' possibile
disassemblare l'eseguibile, ottenendo un codice assembler e avendo poi
le immagini assembler delle istruzioni Pascal o C si puo' ritornare
fino al sorgente. Almeno in linea di massima. Infatti, facendo
un'operazione del genere si puo' vedere che quasi sempre il sorgente
iniziale e quello ricavato dall'exe non corrispondono perfettamente,
ma questo e' logico. Il tutto non vale piu' in caso, ad esempio, di
C++ a causa dell'elevata ottimizzazione di questo codice, oppure per
sorgenti molto complessi (cioe' la stragrande maggioranza degli
eseguibili che trovi in giro). Altrettanto dicasi per codici
ottimizzati allo stato assembler.
Bye, Luca.
ta...@pianeta.it
 - San Polo d'Enza (RE) - Italy
***********************************************
*****       The truth is out there        *****
***********************************************

ottimizzati allo stato assembler.
Ma allora per programmi semplici scritti anche con linguaggi
"superiori" come Pascal e C é possibile ricavare i sorgenti? Ci sono
programmi che lo fanno? Quali?
Grazie!
Ciao
 Luca Dentella
/     /   \ /---\ /---\
|     |   | |     |   |   Internet --> 
lden...@spm.it
|     |   | |     |---|
|     |   | |     |   |   Fidonet  --> 2:331/210.15
\---/ \---/ \---/ \   /

  /_ /    |_|      |_|   ______________________________________
Vorrei sapere dove trovare un decompilatore che fa questo.
Il mio email : 
Sa...@netbra.brasimone.enea.it

 che riporta indietro proprio al sorgente.
Vale in ogni caso se non erro. Perche' si tratta sempre di tradurre un
programma  da un linguaggio   A ad un   linguaggio  B. Nel caso  della
"decompilazione" i 'token' sono sequenze di istruzioni macchina che si
sa  vengono usati dal compilatore originale  per la  traduzione di una
certa istruzione.
Al piu'  si   puo` arrivare ad     un programma che non   e'  identico
all'originale ma e' ad esso perfettamente equivalente.


programmi che lo fanno? Quali?
Si', esistono alcuni programmi in grado di farlo, ma sinceramente non
so fino a che punto siano affidabili. Se non ricordo male c'era un
programma che la Borland distribuiva con il Turbo Pascal in grado di
farlo (era il Turbo Profiler forse?), ma sinceramente non ne conosco
di sicuri per Pascal o C, come invece li conosco per Clipper.
Bye, Luca.
ta...@pianeta.it
 - San Polo d'Enza (RE) - Italy
***********************************************
*****       The truth is out there        *****
***********************************************
**** To get PGP public key send a mail to  ****
**** 
pgp-pub...@keys.de.pgp.net
 with  ****
****     subject "get Luca Ugolotti"       ****
***********************************************

programmi che lo fanno? Quali?
E quando anche si riuscisse a ricreare le righe di sorgente cosa te
fai ? Tieni presente che mancano tutti i simboli globali, locali e
tutte le strutture dati. Se poi il programma e' in C++ perdi anche
tutte le gerarchie di classi. Non credo che nessuno abbia speso tempo
e denaro per produrre un software di utilita' praticamente nulla.
In fin dei conti se uno ha bisogno di curiosare dentro un programma (a
me gia' successo di doverlo fare) e' sufficiente conoscere bene
l'assembly, armarsi di un buon debugger e di tanta pazienza.
     _______ _____         
    / _____// ___ \     Gianpaolo Bottin  - 
bott...@mbox.vol.it
 
   / /____ / /__/ /     Bruino (TO) - Italy
  / //_  // ___  <      


so fino a che punto siano affidabili.
Bingo.    Infatti  sebbene la  compilazione   inversa sia teoricamente
possibile sapendo  come un compilatore traduce   in codice macchina un
certo  sorgente di alto   livello, rimane  il fatto   -di cui  mi  ero
dimenticato- che molte implementazioni  del C supportano  la direttiva
asm per l'inserimento di  codice assembler all'interno di un programma
in C.  Ora un decompilatore che  riconosce come "token" delle sequenze
di istruzioni in codice macchina e le traduce in statement C ha ottime
possibilita'  di reagire con un  "sysntax  error" a queste sequenze di
istruzioni immesse con  la direttiva asm. E  quindi di non  riuscire a
portare a termine l'operazione.


 wrote:
: >>Ma allora per programmi semplici scritti anche con linguaggi
: >>"superiori" come Pascal e C é possibile ricavare i sorgenti? Ci sono
: >>programmi che lo fanno? Quali?
: >
: >Si', esistono alcuni programmi in grado di farlo, ma sinceramente non
: >so fino a che punto siano affidabili.
: Bingo.    Infatti  sebbene la  compilazione   inversa sia teoricamente
: possibile sapendo  come un compilatore traduce   in codice macchina un
: certo  sorgente di alto   livello
E invece non lo e'. Generalmente, la mappatura da alto livello a linguaggio
macchina e' inettiva, non suriettiva ("into", non "onto"), quindi non e'
invertibile (insomma, diverse costruzioni di alto livello possono essere
ridotte allo stesso codice di basso livello).
--
Tommy Anderberg
Tommy.A...@abc.se

ridotte allo stesso codice di basso livello).
Infatti il problema e' proprio questo: l'impossibilita' di riprodurre
il codice iniziale. Resta il fatto che se il codice e' compilato senza
ottimizzazioni, avendo la symbol table adeguata si puo' compiere il
percorso inverso per riottenere un sorgente, ma non e' detto che sia
*IL* sorgente desiderato! Infatti il decompilatore potrebbe tradurre
una certa sequenza macchina in una certa istruzione, mentre casomai
all'inizio quel codice e' stato generato da due istruzioni diverse che
messe insieme davano come risultato quel codice. Forse non e' molto
chiaro, ma il concetto e' questo. E questo succede con linguaggi tipo
Pascal, C, ecc. mentre per Clipper il discorso e' ancora diverso,
visto che in questi caso i decompilatori esistono e hanno anche una
buona affidabilita'!


 ridotte allo stesso codice di basso livello).
Non arrivi con certezza al  sorgente originario,  ma puoi ottenere  un
sorgente  che calcola una funzione  equivalente. Il che vuole dire che
ottieni   lo stesso  programma.  Ed e'   gia'   molto  piu'  leggibile
dell'assembler!
Il punto  debole  (l'ho gia'  detto) non  e' nella invertibilita'  del
processo, ma nel fatto che e' possibile (in vario modo), l'alterazione
del  codice macchina    generato    dal compilatore,  col    risultato
equivalente  all'inserire    un    "token   non    riconosciuto"   dal
decompilatore.


Il che lascia aperti moltissimi dubbi sull'efficenza di Clipper...
Cosa significa 'il che lascia...'.
Se per te efficienza significa velocita' l'unico linguaggio efficiente
e' l'assembler.             ;-)
Non riesco proprio a capire questa frase...
Siddharta

 buona affidabilita'!
Il che lascia aperti moltissimi dubbi sull'efficenza di Clipper...
o   oooooo	Gian Uberto Lauri        "So, are you working on finding


dell'assembler!
In effetti su alt.cracks girava da un po' di tempo un fantomatico
exe2c che sembra funzionare... solo che io non conosco il C quindi non
so a cosa mi possa servire...


per questo se non erro ha delle buone librerie.
Scusa la mia ignoranza non so cosa intendi per bytecode o salto a
procedura.
Clipper semplicemente compila il tutto in op-code, codice intermedio
tra quello oggetto e quello sorgente.
In testata dell'eseguibile vi e' in interprete che provvede a tradurre
l'op-code in linguaggio macchina a run time.
Perche' questa scelta?
Per semplificare il lavoro al programmatore in molte situazioni:
Clipper non e' nato per database di 2/3 milioni di record, li puo'
gestire ma una indicizzazione porterebbe via molto tempo.
La facilita' di decompilazione deriva proprio dal codice op.
Valckirie infatti riesce a decompilare abbastanza bene, certio non si
puo' ricordare il nome delle variabili locali, ma ne assegna di
suoi...
Pero' e' anche possibile evitare la decompilazione dell'eseguibile se
veramente lo si vuole proteggere.


 e' l'assembler.             ;-)
Hai capito gia' buona parte del discorso. Un compilatore e' tanto piu'
efficente quanto piu' e' veloce il codice che genera. 
A me  rimane  il dubbio  che la  compilazione   di clipper,  vista  la
facilita' di decompilazione, sia poco efficente. A  naso ho il sentore
di un qualcosa come il Bytecode o un continuo salto a procedura...
D'altro  canto non  mi pare che  Clipper sia   un linguaggio  nato per
essere general  purpose, ma con  un campo di applicazione specifico, e
per questo se non erro ha delle buone librerie.
o   oooooo	Gian Uberto Lauri        "So, are you working on finding


 La facilita' di decompilazione deriva proprio dal codice op.
Infatti.  L'algoritmo   di compilazione e'    molto  semplice e quindi
conosciuto  bene. Trovarsi  davanti  del  codice  generato da  un buon
compilatore  C per una  macchina con  pipeline ed esecuzione ritardata
dei salti (non ricordo bene  se il termine  e' questo), e'  tutt'altra
musica.  Per la cronaca  la  pipeline c'e'  gia'  dal 486.  Non so  se
l'altro "truccaccio maledetto" sia gia' stato usato da Intel.


l'altro "truccaccio maledetto" sia gia' stato usato da Intel.
Bah.
In C la decompilazione e' costretta a restituire un codice in
assembler perche' la compilazione traduce il tutto in codice macchina.
In Clipper invece e' possibile perche' la compilazione trasforma in
byte-code.
Rimane nell'eseguibile una tabella di simboli che riporta i nomi delle
funzioni e variabili pubblic e private, in pratica tutto quello che
puo' essere chiamato da una macro.
Infatti walckirye mentre per quesrt'ultimi individua i nomi esatti per
le variabili locali non lo fa'.
E come potrebbe farlo? 
Siddharta

Hello Gian Uberto Lauri !
in a message in this newsgroup you wrote:
 GUL> A me  rimane  il dubbio  che la  compilazione   di clipper,  vista
 GUL> la facilita' di decompilazione, sia poco efficente.
..perche' realmente clipper non compila il codice sorgente in senso stretto, ma
produce un codice eseguibile (non macchina) che viene interpretato a
run-time..praticamente un .exe clipper consiste di un interprete e di una parte
(PCODE) da interpretare..ecco perche' la decompilazione e' semplice..
 GUL> D'altro  canto non  mi pare che  Clipper sia   un linguaggio  nato
 GUL> per essere general  purpose, ma con  un campo di applicazione
 GUL> specifico, e per questo se non erro ha delle buone librerie.
..in effetti e' nato come compilatore xbase, anche se poi e' evoluto in (quasi)
tutte le direzioni..con le librerie opportune ci si puo' fare di tutto, anche
automazione industriale..
-=NC=- (
nicola....@act.it
)
       (
http://www.tqs.it/act/nicola-chietera.html
)