Newsgroup: it.comp.lang.visual-basic
Titolo: Conversione EXE -> VB

Vorrei sapere se esiste un programma che converta applicazioni .EXE in
una serie di form e moduli per poter leggere il sorgente con Visual
Basic.
Grazie
Tango

 wrote in message
news:371AFD45...@cdh.it...



No, non esiste (fortunatamente).
--
Roal Zanazzi
z...@iol.it

Non possono esistere VERI decompilatori di un programma. Dato che un
programma eseguibile EXE non è altro che un'ammasso di bit, mentre un file
sorgente è invece un file di testo cioè parole organizzate in "frasi" che
hanno senso compiuto. E quindi ovvio che sia impossibile effettuare il
processo inverso di conversione BINARIO --> FILE SORGENTE.
 E' come se da un articolo di giornale ritagliate tutte le singole lettere
che compongono le parole e le frasi e le mescolate: è ovvio che non sarete
più in grado di ricostruire l'articolo; al massimo potete costruire una
infinità di articoli a vostro piacere, a partire da tali lettere, che però
sono i vostri e non l'originale...
Il numero possibile di articoli a partire da tali lettere ritagliate è
praticamente infinito e quindi la probabilità di ricostruire l'articolo
orginale è NULLA.


 orginale è NULLA.
Beh, questo vale per gli eseguibili in codice nativo... invece per quelli in
p-code, usando il decompilatore giusto (l'ho sperimentato con il VB3 e il
decompilatore Dodi), ottieni proprio il sorgente originario (tranne i nomi
delle variabili che all'atto della compilazione vengono trasformate in una
sigla con un progressivo numerico).
Provare per credere !
Zeross




ma sono quasi sicuro che sia possibile!!
No, e' possibile solo se si tratta di PCODE lanciato da un Runtime e
mascherato, se si tratta di un compilato la cosa e' diversa.
Es. scrivo la ricetta per fare la torta, ingredienti quantita' tempo
di cottura tutto bello scritto e in ordine e poi faccio la torta.
Chi ha il 'disassemblatore' scoprira' i componenti, glutammato,
farina, sale ecc. ma come vedi modificare la torta rispetto alla
ricetta originaria in questo caso e' estremamente lungo e complesso e
non puoi ricostruire la ricetta di base cosi' come l'ho scritta, tra
l'altro ricette diverse possono portare allo stesso risultato.
Im pratica la 'decompilazione' di solito la fa chi vuole sproteggere
un programma, in quanto agisce in una piccolissima porzione di codice
che va bene anche in forma cosi' complessa e non per modificare il
programma.
--------------------------------------------------------
Paolo Hölzl
Metis Informatica s.a.s technical manager (Ferrara)
----------------------------------------------------------
ATTENTION!, antispam 
For reply, substitute xxx.xx with 
tin.it

Provare per credere !
Se e' un PCode si altrimenti te lo scordi.


 Se e' un PCode si altrimenti te lo scordi.
Sģ, infatti parlavo del decompiler Dodi per VB3, quindi p-code.
Zeross


Signore e signori... vediamo di fare un po' di chiarezza sull'argomento.
Decompilare il P-CODE e' piu' semplice che non decompilare codice nativo
Intel. E fin qui credo siamo tutti d'accordo.
Allora, perche' e' piu' difficile decompilare il codice nativo (NOTA BENE:
piu' difficile, ma NON impossibile)????
Semplice.
Nel processo di compilazione il codice sorgente VB (ma vale per tutti i
linguaggi) viene trasformato in linguaggio macchina (ossia il linguaggio
proprio del processore, es. 90 esadecimale = NOP). In questo processo
VENGONO PERSE delle INFORMAZIONI, che sono contenute nel linguaggio ad alto
livello (VB), ma non servono nel linguaggio macchina.
Quali sono queste informazioni?
Principalmente tutti i nomi (di variabili, costanti, funzioni).
Tutto il resto e' ricostruibile direttamente o conoscendo approfonditamente
le fasi della compilazione (es. come vengono trasformate le strutture dei
cicli, etc...).
Chiaramente piu' sono le informazioni non recuperabili, piu' difficile o
incompleta sara' l'operazione di decompilazione.
In ambito matematico la compilazione e' la funzione, la decompilazione e' la
sua inversa e, come sapete, esistono funzioni che non sono completamente
invertibili.
Conclusione:
La decompilazione e' possibile, anche per il codice nativo, fino ad un certo
punto.
Alcune informazioni presenti nel codice VB non possono essere recuperate nel
codice macchina, semplicemente perche' non esistono piu'.
Quindi, non potra' MAI essere creato un decompilatore che ricrea il sorgente
VB originario da un codice eseguibile. AL PIU' si potra' ricreare la
struttura del programma, magari le forms e gli oggetti visuali utilizzati,
fino ad arrivare ad un codice VB in cui le informazioni mancanti sono
sostituite da informazioni fittizie (nomi di variabili con numeri
progressivi, etc...)
Ultima nota:
ricordate che qualcuno usa il termine "decompilare" anche per indicare
l'operazione di ricostruzione del codice assembly, da un codice macchina.
Operazione che e' sempre possibile, e che in genere si chiama
"disassemblare".
--
Roal Zanazzi
z...@iol.it

sigla con un progressivo numerico).
esistono anche per VB6? quindi se creo un programma su VB6 da questo
si potrebbe ottenere il sorgente? 
Aranar
e-mail: 
ro...@geocities.com
http://www.nettaxi.com/citizens/Aranar/
   (above all VgaPlanets)
http://www.tempolibero.com/user/aranar
    (sopratutto VgaPlanets)

codice macchina, semplicemente perche' non esistono piu'.
dissento.... almeno a livello intuitivo mi sembra impossibile che una
variabile non esista più.. sarà stata nascosta o la sua gestione sarà stata
modificato in altro modo...
Domandina Innocua...
nei miei progetti futuri non è previsto un Decompilatore... però mi sembra
davvero molto strano che alcune informazioni vengano letteralmente
"perse"... che ne dici ?
Interessantemente und spigolosamente
ciao Davide


Non e' assolutamente strano.
E' una normale conseguenza derivante dalla traduzione di un linguaggio ad
alto livello (piu' vicino alla comprensione umana, quindi piu' ricco di
informazioni) in un linguaggio a bassissimo livello (che deve essere solo
comprensibile da una macchina, quindi ha poche informazioni di contorno).
Se ci pensi bene, questa conseguenza (la perdita di informazioni) la puoi
avere in alcuni casi anche nella traduzione tra linguaggi dello stesso
livello.
Ad esempio, una barzelletta in Inglese, che si basa sul doppio senso di una
parola, perdera' tutto il senso se tradotta in Italiano, dove non esiste una
parola che abbia quel doppio senso.
Per quanto riguarda altre informazioni, come hai ben compreso, non vengono
eliminate, ma semplicemente modificate o rese "implicite".
Ad esempio, tornando alla variabile MiaBellaVariabile, di cui sopra, in VB
e' chiaro che si tratta di un Long, perche' esiste lo statement di
dichiarazione;
nell'EXE, pero', il fatto che sia un Long lo si "deduce" dal fatto che
quella zona del segmento DATA viene utilizzata come long a 32bit nelle
istruzioni. Non esiste informazione esplicita di dichiarazione e, per di
piu', il segmento DATA (dove ci sono tutte le variabili globali) non ha
separatori o altri indicatori che permettano di individuare le singole
variabili; le "variabili" esistono dunque solo in relazione alle istruzioni
che le usano.
--
Roal Zanazzi
z...@iol.it

Scusate se mi intrometto, e per di più OT, ma tutto questo mi ha interessato
MOLTISSIMO.
Pse, sapreste dirmi dove posso trovare informazioni (tutto se è possibile)
sulla struttura dei files exe, il linguaggio macchina, e via dicendo?
So che di solito queste sono cose da hackers, ma penso che la conoscenza sia
lecita a tutti, sta a chi la possiede farne buon uso.
Grazie
Gabriele

 >Basic.
Se pur è verità sacrosanta, rimane pur sempre possibile decompilare un
eseguibile e ricostruire il codice sorgente ex-novo per un determinato
linguaggio alla volta: Per restare in tema di giornali, è come se io,
una volta che ho ritagliato tutte le lettere, le sparpagliassi per bene
sulla scrivania e poi cercassi di ricostruire un articolo che esprima
gli stessi concetti, magari in una lingua straniera.
L'operazione E' possibile, in ogni caso è una gatta da pelare di
proporzioni sommariamente infinite... è MOLTO più semplice analizzare il
programma in questione come utenti e ricostruirne a mano una copia
conforme con il tuo linguaggio preferito...
Ho sentito voci di simili aggeggi, in giro per il WEB, ma a dire il
vero, non ne ho mai visto uno e sinceramente penso che il cracker che lo
ha costruito, posto che esita un genio di simili proporzioni, se lo
tenga per sé.


Teoricamente sarebbe possibile costruire un programma che, dato in input un
altro programma, ne scrive uno "simile". Di sicuro non e' un lavoro
semplice, e non credo che ne valga la pena, a meno che uno non faccia il
"copiatore di programmi" di professione.
E' molto piu' semplice crackare il programma originale, piuttosto che
tentare di ricostruirlo...
--
Roal Zanazzi
z...@iol.it