Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Resin took JAR security to the next level?

Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey everyone. I wonder how many people here are running Resin and were pissed off because it's an "open source" project that you have to pay for to run commercially?

Well I was playing around with the license.jar file today, which I assumed was where all the security-related stuff was at. The wierdest thing is that none of the decompilers I tried could take on license.jar. Jad-based compilers told me that the file had a "broken zip structure", but they did show me all the contents of the jar. I could even "decompile" any of the 3 .class files inside the jar, although the result would be a messed up java code.

So, I was wandering how Resin did such a thing? Next thing I thought is that probably license.jar has some sort of encryption with some bytes flipped... So I wrote a custom Class Loader and used Xbootclassloader/p with it, to see the acutal bytecode that's sent into my JVM... I saved that bytecode as .class and tried decompiling it, and tada: I still get messed up java code...

So, what's happening here? Either Resin has some sort of magical compiler that compiles java into classes that could be understood by 1.4.1 JVM, but can't be decompiled...

OR... (this just came to my mind)


is just a cover up for the REAL security that they have. Think about it - have the class loader load a corrupt java file, and throw an exception, and then you just intercept the exception and ignore it. But then again, it is my OWN ClassLoader, and the .class's do pass...

So, does anyone have any idea how does Resin make .class's that can be interpreted by 1.4.1 but cant' be decompiled correctly?
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

it's an "open source" project

author and iconoclast
Posts: 24203
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Decompilers take advantage of the fact that compilers use standard patterns in translating Java into bytecode -- i.e., a "for" loop will be compiled into a certain pattern of bytecodes, and the decompiler, knowing this, can produce a "for" loop when it sees this pattern.

Ergo, to produce a .class file that's hard to decompile, don't use those patterns. Insert "nop" instructions. Invert branches. Re-order instructions. Just generally do things the decompiler won't recognize.

There are many tools that do this for you, with varying degrees of success; they're call "bytecode obfuscators".

Now, regarding Resin itself: they release the source as a courtesy under their own license, the Caucho Developer Source License. It's not open source, and it's not free software. Please don't assume that everyone who writes software ought to give it to you for free out of the goodness of their heart. People have to eat.
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and I doubt they release their licensing code at all (I know I wouldn't).
I am Arthur, King of the Britons. And this is a tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic