Obfuscation and Verifier/VM in JDK 1.1.1

John Neffenger

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

It confuses only one part of the JVM -- the bytecode verifier that now,
all of a sudden, checks for illegal characters in member names. At
issue is whether the change is good, or even necessary.

Crema replaces member names with characters that are illegal to the Java
compiler. That's important since it not only makes it difficult to
understand the decompiled code but also makes it impossible to recompile
the resulting source. (And, in the process, it greatly reduces the size
of your applet.)

By the way, I'm not talking about the Crema "-ill" option which goes a
step further and uses Java reserved keywords as member names and has
always been rejected by JVMs running applets.

The new bytecode verifier (from Symantec) in Netscape Communicator
Preview Release 3 is the first browser to prevent the use of such
illegal characters in applets.

Why was the check added to Netscape's bytecode verifier? Is the check
absolutely necessary? If it is, why have we done fine for the past year
without it? If it's not necessary, why limit the ability of Java
developers to protect their code by adding it?

John Neffenger

Peter van der Linden wrote:
> >But wait ... my Crema obfuscated applet has worked in over 300 Java
> >environments since October of last year, covering 7 Java vendors, 19
> >operating systems, and 12 hardware platforms.
> >
> >Then along comes Netscape Communicator Preview Release 3 and it breaks.
> >And it's a Crema problem?
>
> Yep, Crema lacks forward compatability. Crema is a utility that
> takes bytecode files and scrambles them so javap gets confused. It
> obviously does the job too well for JDK 1.1.1, such that it confuses
> other parts of the JDK too.
>
> --
> ---
> Peter van der Linden
> Java Programmers FAQ ---> http://www.best.com/~pvdl
> Chance favors the prepared mind.

Neil Aggarwal

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

Unfortunately, I have noticed this problem. I dont know exactly why
it occurs and I cannot try to devise a workaroud since a (stable)
1.1 JVM is not yet available for OS/2.

One thing I propose is to use my Obfuscate program to rename the
items to alphabetic sequences since it seems that the programs dont
like the names of the methods and fields being numeric sequences.
If that works, then the problem is that numeric names are not
allowed in the class files for the 1.1 JVM (why this would be so
makes no sense to me).

I unfortunately cannot test this right now, but if you have a 1.1
JVM, here is how to do it:
1. With a 1.0.2 JVM, use the Obfuscate program to
obfuscate a program, but make sure that you
set everything to rename numeric.
2. With a 1.1 JVM, try to run the obfuscated program.

If you do this, please let me know what happens.

I would like to be able to resolve this problem since it impinges
on the portability of the Java bytecode.

Thank you,
Neil Aggarwal

Brian Blevins <br...@maxtech.spNOam.com> wrote:
>JavaSoft and fellow Java programmers,
>
>It appears that the JavaVM in the JDK 1.1.1 is incapable of
>running class files obfuscated with the Crema obfuscator.
>The exact same class files compiled and executed without
>obfuscation will run just fine. Also, the JDK 1.0.2 VM
>and browsers ran the Crema obfuscated versions of the classes
>without a problem.
>

--
--
Neil Aggarwal ne...@monmouth.com
Want to improve your BlackJack play?
Want to obfuscate your Java bytecode?
Check out http://www.monmouth.com/~neil/

Neil Aggarwal

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

>Not speaking for JavaSoft or anything, but if a 3rd party tool doesn't
>work with the new release of a compiler (any compiler), it is the 3rd party
>tool that is broken, not the compiler.

The problem is this. The bytecode is valid 1.0.2 bytecode (because the
1.0.2 JVM run it without complaining - the interpreter explicitly
check and verifies that anything meets the specs before running it).

But, this valid 1.0.2 bytecode is not accepted by the 1.1 JVM.

In my opinion, this means that the 1.1 JVM does not fully support the
1.0.2 bytecode and therefore the 1.1 JVM needs to be fixed to support this
case.

Neil.

Neil Aggarwal

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

>I can't believe they would break Crema obfuscated applets! Without the
>illegal method and field names generated by Crema, the decompiled code
>might be hard to understand, but it will be easily recompiled and
>extended by anyone.

I could not agree more.

By the way, my Obfuscate application will allow you to rename
classes, fields, and method names to alphabetic sequences, which
should work since they conform to the Java syntax, but Obfuscate
itself will not run on the 1.1 JVM (since I dont want to give away
my source code).

Therefore, you can do your obfuscation on a 1.0.2 JVM
making sure that you rename all the attributes to alphabetic sequences.
Then, the obfuscated code should run on a 1.1 JVM.

The danger is as you describe - anyone can decompile it into VALID
(albeit not easy to read) java source, modify it and re-compile. This
is very disadvantageous to programmers who write Java code.

In my opinion, the ability to obfuscate bytecode into non-valid syntax
is a VERY important feature (even if it was not inteded to have this
feature) of the 1.0.2 JVM that SHOULD be supported in all later JVMs.

My Obfuscate program is at http://www.monmouth.com/~neil/Obfuscate.html

Craig R Hughes

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

This is a multi-part message in MIME format.
--------------F0A379E29EE897410C074D4A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neil Aggarwal wrote:

>
> Peter v.d.L wrote:
> >Not speaking for JavaSoft or anything, but if a 3rd party tool doesn't
> >work with the new release of a compiler (any compiler), it is the 3rd party
> >tool that is broken, not the compiler.
>
> The problem is this. The bytecode is valid 1.0.2 bytecode (because the
> 1.0.2 JVM run it without complaining - the interpreter explicitly
> check and verifies that anything meets the specs before running it).
>
> But, this valid 1.0.2 bytecode is not accepted by the 1.1 JVM.
>
> In my opinion, this means that the 1.1 JVM does not fully support the
> 1.0.2 bytecode and therefore the 1.1 JVM needs to be fixed to support this
> case.

Look closely at the exception messages in the original posting, or just
look at the class names that Crema generates. These class names it
generates contain the '$' character. This special character is used by
1.1 to handle naming of .class files for inner classes. So the problem
is that when your 1.1 JVM sees that it's got to load a class called $33,
it thinks that it's meant to be an inner class called "33" of a main
class called "". The fact that this latter class name is the empty
string is probably what's breaking things. If the dead dude who wrote
Crema had chosen a different character to stick on all his class names,
then the problem probably wouldn't be there. I don't know what the
original 1.0.2 spec said about $'s in class names, but I would guess
that there was some reason JavaSoft chose them to specify inner class
names.

C
--------------F0A379E29EE897410C074D4A
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Craig R Hughes
Content-Disposition: attachment; filename="vcard.vcf"

begin:vcard

fn:Craig R Hughes

n:Hughes;Craig R

org:IA Corporation

adr:Suite 600;;1900 Powell Street;Emeryville;CA;94608-1840;USA

email;internet:cr...@ia-us.com

title:Software Engineer

tel;work:(510)450-6883

tel;fax:(510)450-5918

tel;home:(510)595-9648

x-mozilla-cpt:;0

x-mozilla-html:TRUE

end:vcard

--------------F0A379E29EE897410C074D4A--

Brian Blevins

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

JavaSoft and fellow Java programmers,

It appears that the JavaVM in the JDK 1.1.1 is incapable of
running class files obfuscated with the Crema obfuscator.
The exact same class files compiled and executed without
obfuscation will run just fine. Also, the JDK 1.0.2 VM
and browsers ran the Crema obfuscated versions of the classes
without a problem.

I submit the following:

1) HotJava 1.0 on WinNT 4.0 and Solaris 2.5.1 gives
java.lang.NoClassDefFoundError
when used against Crema obfuscated classes
(see http://demo.maxtech.com/crosstie)
but runs the non-obfuscated versions of those classes
just fine.

2) The JDK 1.1.1 appletviewer on Solaris 2.5.1 gives
java.lang.VerifyError: com/maxtech/crosstie/term/CtWindowQuick
at sun.applet.AppletPanel.runLoader(AppletPanel.java:419)
at sun.applet.AppletPanel.run(AppletPanel.java:223)
at java.lang.Thread.run(Thread.java)

3) Netscape Navigator 4.0 P3 (with partial JDK 1.1 support) gives
Verifier errors when attempting to run classes obfuscated by
Crema.
(Again works just fine with non-obfuscated classes.)
Java Accelerator (JIT) Installed
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name ""
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "?"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^^"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^]"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "?"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^P"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^O"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^N"
VERIFIER CLASS ERROR com/maxtech/crosstie/term/$37:
Illegal Field name "^M"

The "binary compatibility" statements on the JavaSoft website refer
only to bytecode generated by JDK 1.0 compilers. So, technically,
there is no guarantee that obfuscated code that worked for JDK 1.0
VMs will work in JDK 1.1 VMs. However, there is a good bit of this
type of code already installed on various websites.

So, I have a couple of questions?

1) Is anyone at JavaSoft going to fix or at least explain the problem
in the JavaVM? It doesn't appear to be listed as a known bug
against the JDK 1.1.1.

2) Is there any hope of getting this fixed by the time JDK 1.1.2
is released?

3) Does anyone know if the same problem occurs with the other
obfuscators, such as:

hashjava: http://www.blackdown.org/~kbs/hashjava.html
hashjava: http://www.sbktech.org/hashjava.html
Jobe: http://www.primenet.com/~ej/
Obfuscate: http://www.monmouth.com/~neil/Obfuscate.html

Thanks in advance for any enlightment you might have on this
subject.

Brian
br...@maxtech.com

Peter van der Linden

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

>It appears that the JavaVM in the JDK 1.1.1 is incapable of
>running class files obfuscated with the Crema obfuscator.

> 1) Is anyone at JavaSoft going to fix or at least explain the problem
> in the JavaVM? It doesn't appear to be listed as a known bug
> against the JDK 1.1.1.

Not speaking for JavaSoft or anything, but if a 3rd party tool doesn't

work with the new release of a compiler (any compiler), it is the 3rd party
tool that is broken, not the compiler.

This isn't a bug fix that JavaSoft can make.

John Neffenger

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

But wait ... my Crema obfuscated applet has worked in over 300 Java
environments since October of last year, covering 7 Java vendors, 19
operating systems, and 12 hardware platforms.

Then along comes Netscape Communicator Preview Release 3 and it breaks.
And it's a Crema problem?

With Crema's author, Hanpeter van Vliet, no longer with us, I'd hate to
see this be the end of his excellent product.

John Neffenger

Peter van der Linden wrote:
>

John Neffenger

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

Dear Brian,

I just noticed the same problem yesterday (see my post called
"VerifyError on Communicator with Symantec"). It didn't happen on
Communicator until Netscape switched to the Symantec JVM in Preview
Release 3.

I can't believe they would break Crema obfuscated applets! Without the
illegal method and field names generated by Crema, the decompiled code
might be hard to understand, but it will be easily recompiled and
extended by anyone.

Crema obfuscated applets have worked fine in all browsers from all
vendors up until now, so why did they need to break it? Was this some
kind of security fix?

John Neffenger

Brian Blevins wrote:
>
> JavaSoft and fellow Java programmers,
>

> It appears that the JavaVM in the JDK 1.1.1 is incapable of
> running class files obfuscated with the Crema obfuscator.

> 1) Is anyone at JavaSoft going to fix or at least explain the problem
> in the JavaVM? It doesn't appear to be listed as a known bug
> against the JDK 1.1.1.
>

Peter van der Linden

unread,

May 9, 1997, 3:00:00 AM5/9/97

to

>But wait ... my Crema obfuscated applet has worked in over 300 Java
>environments since October of last year, covering 7 Java vendors, 19
>operating systems, and 12 hardware platforms.
>
>Then along comes Netscape Communicator Preview Release 3 and it breaks.
>And it's a Crema problem?

Yep, Crema lacks forward compatability. Crema is a utility that

takes bytecode files and scrambles them so javap gets confused. It
obviously does the job too well for JDK 1.1.1, such that it confuses
other parts of the JDK too.

Peter van der Linden

unread,

May 10, 1997, 3:00:00 AM5/10/97

to

>without it? If it's not necessary, why limit the ability of Java
>developers to protect their code by adding it?

Crema isn't the only obfuscator on the market. The FAQ lists at least one
other.

Neil Aggarwal

unread,

May 10, 1997, 3:00:00 AM5/10/97

to

>Look closely at the exception messages in the original posting, or just
>look at the class names that Crema generates. These class names it
>generates contain the '$' character. This special character is used by
>1.1 to handle naming of .class files for inner classes. So the problem
>is that when your 1.1 JVM sees that it's got to load a class called $33,
>it thinks that it's meant to be an inner class called "33" of a main
>class called "". The fact that this latter class name is the empty
>string is probably what's breaking things. If the dead dude who wrote

This does not make sense to me since my Obfuscate application does not
use the $ and the 1.1 JVM does not like applications that are obfuscated.

Is there a specific subset of identifiers that would be non-valid Java
syntax but still run under the 1.1 JVM?

Jason Marshall

unread,

May 10, 1997, 3:00:00 AM5/10/97

to

John Neffenger wrote:
>
> It confuses only one part of the JVM -- the bytecode verifier that
> now,
> all of a sudden, checks for illegal characters in member names. At
> issue is whether the change is good, or even necessary.
>
> Crema replaces member names with characters that are illegal to the
> Java
> compiler. That's important since it not only makes it difficult to
> understand the decompiled code but also makes it impossible to
> recompile
> the resulting source.

Only if your decompiler is no good. Maybe I'm gonna have to sit down
and write one of these just to prove the point, cause some folks don't
seem to grasp this.

> (And, in the process, it greatly reduces the size of your applet.)

I could show you compiler optimizations that not only make the code
faster, but make it more compressible too.

> By the way, I'm not talking about the Crema "-ill" option which goes a
> step further and uses Java reserved keywords as member names and has
> always been rejected by JVMs running applets.

> The new bytecode verifier (from Symantec) in Netscape Communicator
> Preview Release 3 is the first browser to prevent the use of such
> illegal characters in applets.

I cannot say for certain if this is for better or worse, but a 3rd
generation decompiler will always outsmart an Nth gen obfuscator,
period.

> Why was the check added to Netscape's bytecode verifier? Is the check
> absolutely necessary? If it is, why have we done fine for the past
> year

> without it? If it's not necessary, why limit the ability of Java
> developers to protect their code by adding it?

And what would you do with a bug report that read:

Yeah, I got this error running your code:

NullPointerException in class for

protected
at java.lang.Integer.toString()
at while.#$%&&()
at ()&(*&)(&{)*{&(*&)(.run()

> > Yep, Crema lacks forward compatability.

--
Jason Marshall http://isr.co.jp/people/marshall
International Systems Research mars...@isr.co.jp
Just because it works doesn't mean it isn't broken.

John Neffenger

unread,

May 10, 1997, 3:00:00 AM5/10/97

to

Jason Marshall wrote:
> > That's important since it not only makes it difficult to
> > understand the decompiled code but also makes it impossible to
> > recompile
> > the resulting source.
>
> Only if your decompiler is no good. Maybe I'm gonna have to sit down
> and write one of these just to prove the point, cause some folks don't
> seem to grasp this.

I understand that you can write a tool that goes through and replaces
the illegal identifiers with good ones, keeping consistency across
packages, but Mocha and the other decompilers with which I'm familiar
don't do that yet. Does anyone know otherwise?

So I'm protected from everyone except people who have the time and
determination to go write such a tool.

> > The new bytecode verifier (from Symantec) in Netscape Communicator
> > Preview Release 3 is the first browser to prevent the use of such
> > illegal characters in applets.
>
> I cannot say for certain if this is for better or worse, but a 3rd
> generation decompiler will always outsmart an Nth gen obfuscator,
> period.

Yeah, it's just a game of trying to stay ahead and make it easier for
people to do their homework and write and understand their own code
instead of cutting and pasting yours.

> And what would you do with a bug report that read:
>
> Yeah, I got this error running your code:
>
> NullPointerException in class for
>
> protected
> at java.lang.Integer.toString()
> at while.#$%&&()
> at ()&(*&)(&{)*{&(*&)(.run()

I find out what version of the applet they're running (from the log file
if they don't know) and go look in the file that Crema created which
maps all the funny characters to their original names. Works every
time.

> > Yep, Crema lacks forward compatability.

Hashjava (by Peter's Java FAQ recommendation) looks like a fine tool
that is still being maintained. I'm a little concerned that it might
not compress the applet as small, but I'll find that out today. The
JInstall utility (found at the same location - http://www.sbktech.org/)
looks great, too!

John Neffenger

Jason Marshall

unread,

May 11, 1997, 3:00:00 AM5/11/97

to

John Neffenger wrote:
>
> Jason Marshall wrote:
> > > That's important since it not only makes it difficult to
> > > understand the decompiled code but also makes it impossible to
> > > recompile
> > > the resulting source.
> >
> > Only if your decompiler is no good. Maybe I'm gonna have to sit
> down
> > and write one of these just to prove the point, cause some folks
> don't
> > seem to grasp this.
>
> I understand that you can write a tool that goes through and replaces
> the illegal identifiers with good ones, keeping consistency across
> packages, but Mocha and the other decompilers with which I'm familiar
> don't do that yet. Does anyone know otherwise?
>
> So I'm protected from everyone except people who have the time and
> determination to go write such a tool.

No, you're protected until ONE person writes one. What makes you think
I or someone else wouldn't distribute it?

> > I cannot say for certain if this is for better or worse, but a 3rd
> > generation decompiler will always outsmart an Nth gen obfuscator,
> > period.
>
> Yeah, it's just a game of trying to stay ahead and make it easier for
> people to do their homework and write and understand their own code
> instead of cutting and pasting yours.

Reread what I wrote. By that I mean that aside from extensions to the
language (which, of course, breaks lots of things), some bright, bored,
person will, in the next six months, write a decompiler that could, once
completed ot the end of the year, deal with any obfuscation you or any
committee can dream up from now until the Sun grows cold, at least as
well if not sigtificantly better than the disassemblers out there now
for iX86.

Why? Because Java and the JVM are very straightforward and simple.
Given a routine, there's only one or two ways to write it that issue
those bytecodes. Most of your "cool logic" is going to be intramethod,
not inter, so if I run the debugger on it I can figure out where the
Golden Algorithm is in minutes. And I assure you I can read javap
output. It's ever so much less mindboggling than something like iX86.

This is all moot! If I have your program, know basically what it does,
and have a debugger, your classnames could be in Kanji for all I care!

Neil Aggarwal

unread,

May 11, 1997, 3:00:00 AM5/11/97

to

In article <33744187...@isr.co.jp>,

Jason Marshall <mars...@isr.co.jp> wrote:
>Only if your decompiler is no good. Maybe I'm gonna have to sit down
>and write one of these just to prove the point, cause some folks don't
>seem to grasp this.

Yes, you can write a "smart" decompiler that will reverse it into
syntatically correct code (by substituting each invalid name with a
valid one), but that requires quite an investment of
your time. An obfuscator can only make it harder to use a piece of code,
not impossible.

You can get a table of the instances where each item is used, but you
will not have the syntatic significance attached to class names,
method names, and field names.

>I cannot say for certain if this is for better or worse, but a 3rd
>generation decompiler will always outsmart an Nth gen obfuscator,
>period.

I agree, but there is no mass-market 3rd generation decompiler yet.

>And what would you do with a bug report that read:
>Yeah, I got this error running your code:
>NullPointerException in class for
>protected
>at java.lang.Integer.toString()
>at while.#$%&&()
>at ()&(*&)(&{)*{&(*&)(.run()

Ince I dont want you to read my code in any way shape or form, I dont
mind you getting such a garbled error message.

AS a matter of fact, I as the author know the mapping that was used to
prosuce the obfuscted code and can read that error message and tell
what happened.

You have to contact the author if things go wrong with the code.

If something goes wrong with a machine-code application, you dont
try to figure out what the author did and fix it, you go back to the author
of the code and report a bug. It is up to the author to fix it.

D'Arcy Smith

unread,

May 12, 1997, 3:00:00 AM5/12/97

to Neil Aggarwal

This is a multi-part message in MIME format.

--------------535DA3ED665FC13E91AAA273

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neil Aggarwal wrote:

> One thing I propose is to use my Obfuscate program to rename the
> items to alphabetic sequences since it seems that the programs dont
> like the names of the methods and fields being numeric sequences.
> If that works, then the problem is that numeric names are not
> allowed in the class files for the 1.1 JVM (why this would be so
> makes no sense to me).

Since Java doesn't allow identifiers to start with a numeric character
a legal Java compiler could not have generated bytecode that has
identifiers starting with a numeric character. The verifier has
every righ to dissalow an illegal class file.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

JDK 1.1 for Cafe 1.53 Prerelease 2 -
ftp://itools.symantec.com/pub/windows/cafe/1.53/

http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe
--------------535DA3ED665FC13E91AAA273

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit

Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin:vcard

fn:D'Arcy Smith

n:Smith;D'Arcy

org:Symantec, Internet Tools

adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA

email;internet:d...@itools.symantec.com

title:Sr. Software Engineer

x-mozilla-cpt:;0

x-mozilla-html:FALSE

end:vcard

--------------535DA3ED665FC13E91AAA273--

D'Arcy Smith

unread,

May 12, 1997, 3:00:00 AM5/12/97

to Neil Aggarwal

This is a multi-part message in MIME format.

--------------8ADEADCA906FE619D22E4A5A

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neil Aggarwal wrote:
>
> >Not speaking for JavaSoft or anything, but if a 3rd party tool doesn't
> >work with the new release of a compiler (any compiler), it is the 3rd party
> >tool that is broken, not the compiler.
>

> The problem is this. The bytecode is valid 1.0.2 bytecode (because the
> 1.0.2 JVM run it without complaining - the interpreter explicitly
> check and verifies that anything meets the specs before running it).
>
> But, this valid 1.0.2 bytecode is not accepted by the 1.1 JVM.

If it were valid... but it never was.

> In my opinion, this means that the 1.1 JVM does not fully support the
> 1.0.2 bytecode and therefore the 1.1 JVM needs to be fixed to support this
> case.

The 1.0.2 verifier allowed illegal bytecode to be executed. This has
(apparently) been fiexed - for good or bad.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

JDK 1.1 for Cafe 1.53 Prerelease 2 -
ftp://itools.symantec.com/pub/windows/cafe/1.53/

http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe

--------------8ADEADCA906FE619D22E4A5A

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin:vcard

fn:D'Arcy Smith

n:Smith;D'Arcy

org:Symantec, Internet Tools

adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA

email;internet:d...@itools.symantec.com

title:Sr. Software Engineer

x-mozilla-cpt:;0

x-mozilla-html:FALSE

end:vcard

--------------8ADEADCA906FE619D22E4A5A--

D'Arcy Smith

unread,

May 12, 1997, 3:00:00 AM5/12/97

to jo...@volano.com

This is a multi-part message in MIME format.

--------------D66CED27E7FB44D60AE54389

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Neffenger wrote:

>
> It confuses only one part of the JVM -- the bytecode verifier that now,
> all of a sudden, checks for illegal characters in member names. At
> issue is whether the change is good, or even necessary.
>
> Crema replaces member names with characters that are illegal to the Java

> compiler. That's important since it not only makes it difficult to

> understand the decompiled code but also makes it impossible to recompile

> the resulting source. (And, in the process, it greatly reduces the size
> of your applet.)

Actualy, I would say the Crema technicaly makes illegal class files.
The reduction would still be able to be done by Crema replacing
"foo" with "_01" instead of "01". "_01" is legal but recompileable.
There is litle value of using Crema to decompile something and
then recompile it so not a big issue.

I agree that if the change wasn't necessary it was silly to make.

> The new bytecode verifier (from Symantec) in Netscape Communicator
> Preview Release 3 is the first browser to prevent the use of such
> illegal characters in applets.

I don't know if this is our issue - but I'll find out. We use whatever
is coming from JavaSoft - but I don't know what all Netscape uses.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

JDK 1.1 for Cafe 1.53 Prerelease 2 -
ftp://itools.symantec.com/pub/windows/cafe/1.53/

http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe

--------------D66CED27E7FB44D60AE54389

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin:vcard

fn:D'Arcy Smith

n:Smith;D'Arcy

org:Symantec, Internet Tools

adr:City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA

email;internet:d...@itools.symantec.com

title:Sr. Software Engineer

x-mozilla-cpt:;0

x-mozilla-html:FALSE

end:vcard

--------------D66CED27E7FB44D60AE54389--

John Neffenger

unread,

May 12, 1997, 3:00:00 AM5/12/97

to

D'Arcy Smith wrote:

> John Neffenger wrote:
> >
> > The new bytecode verifier (from Symantec) in Netscape Communicator
> > Preview Release 3 is the first browser to prevent the use of such
> > illegal characters in applets.
>
> I don't know if this is our issue - but I'll find out. We use whatever
> is coming from JavaSoft - but I don't know what all Netscape uses.

It's JavaSoft, as I found with the verify option of javap:

Using JDK 1.0.2:

C:\vcclient>javap -verify COM.volano.VolanoChat
Class COM.volano.VolanoChat succeeds

Using JDK 1.1.1 with the same applet:

C:\vcclient>\jdk1.1.1\bin\javap -verify COM.volano.VolanoChat
Class COM.volano.VolanoChat fails

Meanwhile, I've made the switch to Hashjava and the applet works fine in
Communicator Preview Release 4 now. The applet is a bit larger, though,
since Hashjava uses 4-character names like "$414" instead of Crema's
more cryptic (and now rejected) 2-character names like "ǹ".

ZIP CAB CLASS
------- ------ -----
Crema 97,843 37,360 8,558 (broken in Preview 3 & 4)
Hashjava 105,755 40,503 9,056 (works fine in Preview 4)

It also took only a minor 2-line code change to get the decompiled
version compiling again, whereas a decompiled Crema version would have
taken a lot more work or another tool to recompile.

I did file a bug report to JavaSoft, just to make sure they're aware of
the change and that it was necessary (and a good) thing to do. If the
change stays in Netscape Communicator, it's a forced upgrade for all my
customers for something that was supposed to be backward compatible with
valid JDK 1.0.2 applets and applications.

John Neffenger

Patrick G. Bridges

unread,

May 13, 1997, 3:00:00 AM5/13/97

to

D'Arcy Smith <d...@itools.symantec.com> writes:

> This is a multi-part message in MIME format.

> --------------535DA3ED665FC13E91AAA273

> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>

> Neil Aggarwal wrote:
>
> > One thing I propose is to use my Obfuscate program to rename the
> > items to alphabetic sequences since it seems that the programs dont
> > like the names of the methods and fields being numeric sequences.
> > If that works, then the problem is that numeric names are not
> > allowed in the class files for the 1.1 JVM (why this would be so
> > makes no sense to me).
>
> Since Java doesn't allow identifiers to start with a numeric character
> a legal Java compiler could not have generated bytecode that has
> identifiers starting with a numeric character. The verifier has
> every righ to dissalow an illegal class file.
>

You're confusing two seperate things. Identifiers in the Java Language
are not allowed to start with a numeric character. This is something
enforced by the Java Compiler, and is not a safety issue that should
be enforced by the Verifier or Virtual Machine. Java the Language and
Java the Virtual Machine are two seperate things which (unfortunately)
share a name.

--
*** Patrick G. Bridges bri...@cs.arizona.edu ***
*** #include <std/disclaimer.h> ***

Roedy Green

unread,

May 13, 1997, 3:00:00 AM5/13/97

to

D'Arcy Smith <d...@itools.symantec.com> wrote:

>Since Java doesn't allow identifiers to start with a numeric character
>a legal Java compiler could not have generated bytecode that has
>identifiers starting with a numeric character. The verifier has
>every righ to dissalow an illegal class file.

This is really too bad. By needlessly enforcing Java naming
conventions, it looks almost as if Sun is trying to stop other
languages from using the JVM as a target.

On the other hand, Java wants to protect itself say in displaying a
stack trace where these illegal names might be used.

I had a look at a class file I wrote and discovered that method and
variable names consume a considerable proportion of the space. At some
point we might want to rename not so much for obfuscation, but for
compactness.

--
Roedy Green (ro...@bix.com)
Canadian Mind Products, Quadra Island BC.
http://oberon.ark.com/~roedy
-30-

Kristian Emil Aspehaug Schjelderup

unread,

May 14, 1997, 3:00:00 AM5/14/97

to

Roedy Green (ro...@oberon.ark.com) wrote:
: D'Arcy Smith <d...@itools.symantec.com> wrote:
:
: This is really too bad. By needlessly enforcing Java naming

: conventions, it looks almost as if Sun is trying to stop other
: languages from using the JVM as a target.

Why should Sun make it easy to target other languages to the Java VM ?
The Java VM is made for running JAVA code, so it it optimized
accordingly, and has no need for supporting other languages.

- Kristian -
________________________________________________________________________
Kristian Emil Aspehaug Schjelderup : Phone (+47) 223 55 887
Graduate Stud., Dept. of Informatics : GSM / SMS (+47) 924 17 595
University of Oslo, Norway : http://www.ifi.uio.no/~kristias

Mark Tillotson

unread,

May 14, 1997, 3:00:00 AM5/14/97

to

D'Arcy Smith <d...@itools.symantec.com> wrote:

> Since the language does not allow identifiers to start with a numeric
> char
> (as well as some others) no legal compiler can produce a Java class file
> that has an identifier that starts with a non-legal Java identifier.

That's patently not true, all java compilers have to generate the
identifiers "<init>" and "<clinit>" in there output .class files, and
these are not valid Java identifiers...

One can imagine all sorts of reasons a compiler might generate
non-java names (the inner-class stuff of Java 1.1 is the canonical
example) and having a rich enough alphabet in the JVM to prevent
name-clashes is rather important!

I think apart from the tests for "<init>" and "<clinit>", and the 1.1
inner class reflection stuff(??), the JVM's only restriction on
identifiers is that their UTF8 encoding take up less than 2^16
octets. Of course _class_ names are in practice restricted by file
system considerations.

__Mark
[ ma...@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]

Patrick G. Bridges

unread,

May 14, 1997, 3:00:00 AM5/14/97

to

D'Arcy Smith <d...@itools.symantec.com> writes:

> This is a multi-part message in MIME format.

> --------------A364A2FC9719D0ACDF2760EC

> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>

> Patrick G. Bridges wrote:
>
> > You're confusing two seperate things. Identifiers in the Java Language
> > are not allowed to start with a numeric character. This is something
> > enforced by the Java Compiler, and is not a safety issue that should
> > be enforced by the Verifier or Virtual Machine. Java the Language and
> > Java the Virtual Machine are two seperate things which (unfortunately)
> > share a name.
>

> Since the language does not allow identifiers to start with a numeric
> char
> (as well as some others) no legal compiler can produce a Java class file
> that has an identifier that starts with a non-legal Java identifier.
>

Incorrect. No legal. JAVA compiler can do so. The JVM spec (which, as
required by page XV of the spec, applies to all future versions) does
not restrict the form of identifiers. The obfuscator produced a legal
(by Sun's spec) class file, and now it doesn't work. Seems to me that
this is not Crema's problem, but Sun's, for violating their own
specification unnecessarily.

* It is the job of the compiler to enforce the syntax of the Java language
* It is the job of the verifier to enforce type safety

Crema abided by the JVM spec, and got screwed as a result.

s...@netcom.com

unread,

May 14, 1997, 3:00:00 AM5/14/97

to

In article <smrafag...@blackoak.CS.Arizona.EDU> you write:
>
>Incorrect. No legal. JAVA compiler can do so. The JVM spec (which, as
>required by page XV of the spec, applies to all future versions) does
>not restrict the form of identifiers. The obfuscator produced a legal
>(by Sun's spec) class file, and now it doesn't work. Seems to me that
>this is not Crema's problem, but Sun's, for violating their own
>specification unnecessarily.

While I agree that making such a tight link between the jvm and the
language is largely unnecessary, my interpretation of the vm spec does
seem to specifically make this restriction.

I'm looking at the latest vmspec available from the sun site:
(http://www.javasoft.com:80/docs/language_vm_specification.html)

Section 4.4.1 on page 93 for instance, states:

The CONSTANT_Class_info structure is used to represent a class or
an interface:

[...] The constant_pool entry at that index
must be a CONSTANT_Utf8_info (Sec: 4.4.7) structure representing
a valid fully qualified Java class name (Sec: 2.8.1) that has been
converted to the class file's internal form (Sec: 4.2)

Similarly, Section 4.4.6 on pages 99-100 states (essentially for
data structures to describe fields and methods)

[...] The constant_pool entry at that index
must be a CONSTANT_Utf8_info (Sec: 4.4.7) structure representing a
valid Java field name or method name (Sec 2.7) stored as a simple
(not fully qualified) name (Sec 2.7.1), that is, as a Java identifier.

Both of these refer to Chapter 2 of the VM specification, which
is billed as "[...]enough of an overview of Java to support the
discussion of the Java Virtual Machine to follow. Its material has
been condensed from The Java Language Specification, by James
Gosling, Bill Joy and Guy Steele."

Chapter 2 goes on to describe Java class names and Java identifiers in
terms of the usual restrictions on the Java language names.

[ As an aside, and a little unfortunately for obfuscator writers,
there is also a bug in the 1.1.1 Character.isLetter() method which
is used in both the VM Specification as well as the Java language
specification
(http://www.javasoft.com:80/docs/language_specification/3.doc.html#40625)
to define what a valid identifier is supposed to be.

It returns true for some characters defined as invalid according to
the explicit listing also provided in the Java language
specification.

It also returns false for some characters that are listed as valid
in the explicit listing also provided in the Java Language
specification.

As far as I can tell, both the JDK 1.1.1 and symantec verifier
follow the "correct" definition.

However, the JDK 1.1.1 javac compiler appears to use
java.lang.Character to verify correctness of identifier names. This
causes it to either reject some correct input or causes it to accept
some incorrect input which then fails to pass the verifier.

And as far as I can tell, the symantec compiler always does the
correct thing.

(thanks to Brian Blevins (br...@maxtech.spNOam.com) who started this
thread and has since been following up this issue with sun
engineers) ]

-KB-

D'Arcy Smith

unread,

May 15, 1997, 3:00:00 AM5/15/97

to Mark Tillotson

This is a multi-part message in MIME format.

--------------8F6947BD94A8EC5B3DDA6433

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Tillotson wrote:
>
> D'Arcy Smith <d...@itools.symantec.com> wrote:

> > Since the language does not allow identifiers to start with a numeric
> > char
> > (as well as some others) no legal compiler can produce a Java class file
> > that has an identifier that starts with a non-legal Java identifier.
>

> That's patently not true, all java compilers have to generate the
> identifiers "<init>" and "<clinit>" in there output .class files, and
> these are not valid Java identifiers...

These are dictated by the spec though - they are special cases.

> One can imagine all sorts of reasons a compiler might generate
> non-java names (the inner-class stuff of Java 1.1 is the canonical
> example) and having a rich enough alphabet in the JVM to prevent
> name-clashes is rather important!

Again - a specified deviation.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

JDK 1.1 for Cafe 1.53 Prerelease 2 -
ftp://itools.symantec.com/pub/windows/cafe/1.53/

http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe

--------------8F6947BD94A8EC5B3DDA6433

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: D'Arcy Smith
n: Smith;D'Arcy
org: Symantec, Internet Tools
adr: City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet: d...@itools.symantec.com
title: Sr. Software Engineer
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard

--------------8F6947BD94A8EC5B3DDA6433--

D'Arcy Smith

unread,

May 15, 1997, 3:00:00 AM5/15/97

to Patrick G. Bridges

This is a multi-part message in MIME format.

--------------DC93266B8B78D5FF8D581A54

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Patrick G. Bridges wrote:

>
> D'Arcy Smith <d...@itools.symantec.com> writes:
>
> > This is a multi-part message in MIME format.

> > --------------A364A2FC9719D0ACDF2760EC

> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> >

> > Patrick G. Bridges wrote:
> >
> > > You're confusing two seperate things. Identifiers in the Java Language
> > > are not allowed to start with a numeric character. This is something
> > > enforced by the Java Compiler, and is not a safety issue that should
> > > be enforced by the Verifier or Virtual Machine. Java the Language and
> > > Java the Virtual Machine are two seperate things which (unfortunately)
> > > share a name.
> >

> > Since the language does not allow identifiers to start with a numeric
> > char
> > (as well as some others) no legal compiler can produce a Java class file
> > that has an identifier that starts with a non-legal Java identifier.
> >
>

> Incorrect. No legal. JAVA compiler can do so. The JVM spec (which, as
> required by page XV of the spec, applies to all future versions) does
> not restrict the form of identifiers. The obfuscator produced a legal
> (by Sun's spec) class file, and now it doesn't work. Seems to me that
> this is not Crema's problem, but Sun's, for violating their own
> specification unnecessarily.
>

> * It is the job of the compiler to enforce the syntax of the Java language
> * It is the job of the verifier to enforce type safety
>
> Crema abided by the JVM spec, and got screwed as a result.

Now that I am back in the office I can grab my copy of the VM spec.

After taking a look at it I found on page 6 section 2.2 that :

"The Java method Character.isJavaLetter"

is used to find out if an identifier is legal. Depending on how
you want to interpret all of this, and by looking at the source for
that method we find that:

"* Determines if the specified character is a
* "Java" letter, that is, the character is permissible
* as the first character in an identifier in the Java language."

So by the book - Crema produces invalid .class files.

..darcy

--
D'Arcy Smith
Symantec, Internet Tools

JDK 1.1 for Cafe 1.53 Prerelease 2 -
ftp://itools.symantec.com/pub/windows/cafe/1.53/

http://cafe.symantec.com
ftp://itools.symantec.com
snews://secnews.netscape.com/netscape.symantec.visualcafe

--------------DC93266B8B78D5FF8D581A54

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for D'Arcy Smith
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: D'Arcy Smith
n: Smith;D'Arcy
org: Symantec, Internet Tools
adr: City Center One;;20300 Stevens Creek Blvd;Cupertino;CA;95014;USA
email;internet: d...@itools.symantec.com
title: Sr. Software Engineer
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard

unread,

May 19, 1997, 3:00:00 AM5/19/97

to d...@itools.symantec.com

Patrick G. Bridges wrote:
> You're confusing two seperate things. Identifiers in the Java Language
> are not allowed to start with a numeric character. This is something
> enforced by the Java Compiler, and is not a safety issue that should
> be enforced by the Verifier or Virtual Machine. Java the Language and
> Java the Virtual Machine are two seperate things which (unfortunately)
> share a name.

D'Arcy Smith wrote:
> "The Java method Character.isJavaLetter"
>
> is used to find out if an identifier is legal. Depending on how
> you want to interpret all of this, and by looking at the source for
> that method we find that:
>
> "* Determines if the specified character is a
> * "Java" letter, that is, the character is permissible
> * as the first character in an identifier in the Java language."
>
> So by the book - Crema produces invalid .class files.

Note that the current Java compiler (1.1.1) released by Sun will allow
you to begin an identifier with certain characters which are "numbers"
in certain languages (according to the Unicode Standard, Version 2.0).

Strangely, isJavaLetter is returning "false" to these same characters
when I test the compiler, so I assume that it's a bug in the compiler as
it should be using this method to test tokens pulled in. Perhaps a
locale problem?

In Japanese, I see valid source for variables written with the the
"kanji" numerals as the head character all the time.
--
Adrian Havill <URL:http://www.threeweb.ad.jp/>
Engineering Division, System Planning & Production Section

Patrick G. Bridges

unread,

May 19, 1997, 3:00:00 AM5/19/97

to

g...@u.washington.edu (G. Herrmannsfeldt) writes:

> But I believe that newer optimizing compilers will render mocha useless,
> making some people happy. Good optimizers move enough code around that
> even if one can decompile, it won't look anything like what went in.
>
> -- glen

On the other hand, there has also been work on enhancing the ability
of decompilers to untangle control flow graphs in a more sophisticated
way than Mocha did. (Mocha often failed to decompile certain control
flow constructs, even when the control flow graph was reducible. I
know of at least one decompiler in the works that can decompile any
reducible control flow graph.)

And even if the code that comes out doesn't look like what went in, if
you can get reasonable output, you can still figure out the algorithms
being used.