[47757] in Cypherpunks
Re: Hack Java
daemon@ATHENA.MIT.EDU (gback@facility.cs.utah.edu)
Tue Jan 23 13:14:39 1996
Errors-To: cpadmin@toad.com
From: gback@facility.cs.utah.edu
To: rsalz@osf.org (Rich Salz)
Date: Tue, 23 Jan 1996 10:56:42 -0700 (MST)
Cc: cypherpunks@toad.com
In-Reply-To: <9601231630.AA07540@sulphur.osf.org> from "Rich Salz" at Jan 23, 96 11:30:01 am
>
> This illustrates the difference between a language with no dangerous
> constructs, and one where you must trust the implementation.
> >From some internal OSF email:
> ---------- Begin Forwarded Message ----------
>
> class Data { // an object storing 16 bytes
> byte word[16];
> }
>
>
> class Trick {
> Data data;
> long tricky_pointer;
> }
>
>
> Now suppose, I fake a compiler (or I have a malicious compiler)
> and I generate by hand malicious byte code such that
> in the symbol tables, tricky_pointer and data have the same
> offset.
>
What offset do you mean? The offset in the struct as in C++?
Java bytecode does not store such information. Fields are
accessed using putfield/getfield, which use an index to a
field reference in the constant pool. (pg. 66, lang spec)
Field references contain a name index (pg. 19) which points
to a name, i.e., a CONSTANT_Utf8 (pg. 18) field.
To my knowledge, the Java, and Java bytecode does not imply
any memory layout. I doubt it makes sense to demand to check
that 'offset do not overlap in memory'.
Could you describe in more detail the manipulation you are
proposing?
- Godmar
