Newsgroup: it.comp.lang.perl
Titolo: modifica di un file .class

Vorrei sapere se e' possibile modificare un file .class o se comunque
esiste un programma che riesce a farlo.
Grazie a chiunque mi dara' una risposta.

Antonio wrote:

Si certo.. fai un reverse engineering, modifichi qualcosa nel codice e
poi ricompili ;)
A cosa servirebbe?
Ugo

 wrote:
:> Vorrei sapere se e' possibile modificare un file .class o se comunque
:> esiste un programma che riesce a farlo.
: Si certo.. fai un reverse engineering, modifichi qualcosa nel codice e
: poi ricompili ;)
: A cosa servirebbe?
...e soprattutto, perche` non in it.comp.java?
-- 
Nando Santagata: Telemastica & infornatica
Key fingerprint = C2 D9 C0 8E D5 B7 04 97  AF E8 3F 3E AF 4E 7F 9E
finger nando (at) mail (dot) ipers (dot) net   for my PGP public key
Home: 
http://www.ipers.net/~nandos

Grazie a chiunque mi dara' una risposta.
Certo che è possibile... Il bytecode (di cui è composto il file .class) è in
sè stesso un linguaggio di programmazione: in effetti è il "ponte" fra Java
e il codice macchina che permette la tanto decantata portabilità.
Sapendo come programmare il bytecode (basterebbe studiarsi qualche
white-paper... ;-) teoricamente si potrebbero fare dei "giochini" molto poco
simpatici che normalmente verrebbero bloccati in fase di compilazione...
Non sono comunque a conoscenza di programmi di decompilazione che siano
utilizzabili da un umano dal Q.I. inferiore a 600 punti... se dovessi
trovarne uno semplice (dubito... :-) te lo farò sapere.
Calaoke ICQ #36323896.

 trovarne uno semplice (dubito... :-) te lo farò sapere.
invece e' possibile ed anche estremamente semplice; mandami un tuo
*.class che ti do una dimostrazione. Sono pure utili, non per "rubare"
il codice ad altri, ma ad esempio per estendere una classe, in cui vuoi
riscrivere un metodo senza richiamare il parent (devi sapere esattamente
tutte le operazioni da fare, spesso non documentate)
Esistono strumenti per tutelare il proprio codice; il modo piu'
semplice e' quello di evitare l'uso di JDK standard, perche' altri
strumenti (commerciali) fanno gia' per noi questo lavoro.
--
Greetings, Alessandro
http://www.esalab.it
Pesaro, Italy
Sent via Deja.com 
http://www.deja.com/
Share what you know. Learn what you don't.


Un po' di tempo fa utilizzavo Mocha ( cerca mocha+decompiler), che non mi
sembrava affatto complicato.
ciau
Mario Protto
ma...@net4u.it
www.net4u.it

di compilazione...
A quali "giochini" ti riferisci?
Mi risulta che una JVM non si "fida" delle classi che carica e opera
delle verifiche approfondite sia sul formato del file che sul bytecode
(v. il white-paper "The Java Virtual Machine Specification - CAP.4 -
The class File Format" sul sito JavaSoft).
Ciao.     Leonardo Boselli   
bos...@uno.it
   and
--   o    TETRACTYS Software 
tetr...@uno.it
 present
    o o   JOB - Java Objects Builder (0.9.4-05/17/99)
   o o o  Try it, it's FREE! <134 KB> <Java 2 needed>
  o o o o 
http://www.uno.it/utenti/tetractys/job.html

strumenti (commerciali) fanno gia' per noi questo lavoro.
Chiedo venia per la mia mancanza di fiducia...
Per caso sapete (grosso modo) qual'e il rapporto codice Java / bytecode ?
 Thx, Calaoke.

The class File Format" sul sito JavaSoft).
Verissimo: resta comunque da dire che il modello di sicurezza delle JVM č
stato via via raffinato, dopo che qualcuno č riuscito (JDK 1.0) a
gabolarlo... forse su
www.javacats.com
 si trova ancora il messaggio postato riguardo a questo
argomento (anche se dubito...)
Greetz, Calaoke.

[...]
No. A meno di bug nell'implementazione di una JVM, il bytecode verifier
e i  meccanismi di sicurezza funzionano a livello di bytecode.
Anche quelli specificati a livello di libreria (ad es.
java.lang.SecurityManager), sono in classi di sistema che - data una
JVM - sono sostituibili solo sovrascrivendo manualmente (e dall'esterno
della JVM) il file contente le classi stesse (classes.zip in JDK1.0/1.1
e rt.jar in JDK1.2).
Il che equivale a modificare il codice della jvm stessa sulla macchina
dove viene invocata - debolezza che essa condivide con ogni possibile
software che giri in un sistema operativo dove questo non e' impedito.
--
God is Real, unless declared Integer.


 e i  meccanismi di sicurezza funzionano a livello di bytecode.
JVM? Dovrebbe essere PVM no? Ma l'ultima volta che ho guardato, perl
usava un
altro meccanismo...
Oppure qualcuno ha dimenticato il significato di quelle buffe stringhe
che vanno
nella linea Newsgroup:?
Cheers,
	Alessandro


Apprezzo l'ironia, ma il msg originale era in crosspost su
it.comp.java; io non l'ho guardato - ma nemmeno tu ;-)
Cheers,
 Cris
--
--
God is Real, unless declared Integer
