Topic awaiting preservation: A white rat's shot story about reverse engineering (Page 1 of 1)

In another thread, I talked about how sensitive communication points between two layers of a software system are.
Just wanted to share a little story that pretty much explains the process of "reverse engineering"...

Once upon a time, a teacher in some class said "loading custom fonts is not possible using a Java applet".
And a student, who was a java freak and a graphic effects addict, had happened to do this impossible trick about one year ago.

So the student took it as a challenge. He had lost the original code anyway.

He headed back to his home pc, where he started getting documented and put together something that would look like this:
http://www.beyondwonderland.com/data/java/truetype/test.html

He was doing everything according to the Java docs, getting a file handle and loading the ttf directly to the applet.
But the Java security model wouldn't let him do such a thing. An applet has to run in a sandbox and can only access it's originating domain.
So, since an applet runs from a webpage, it wasn't able to access the file system, even when used from the file system!

...
The youngster sat, and said to himself: "ok, applets can't do file system i/o. But they can load stuff from the web? Come on, applets are *part of the web*."

Basically, most OS vendors make theyre file system "readable" as a local web as well. Windows explorer does this.
KDE konqueror does this.

So building his file path as an URL and using it to "download" the resource rather than load it?....



Worked like a charm
I have used this to show my teacher that an applet, when launched locally, could load a truetype and use it.

But it IS a security gap, as the Virtual Machine is tricked into doing things it should not do: I have thought of ways to use this
for other purposes. Never tested them though. Never will. I don't care.

But I wouldn't like to be the guy who put this together, Java has always been web-oriented, but OS have slightly evolved towards
that too, making the original design "weaker" in some parts, and too hard to completely rethink.

Some obvious parts.

Still, it just is the way it is: Java is a masterpiece, the cream of programming languages to me,
and to run a local applet someone has sent me would be stupid, unless I have a good reason
or do know that person.

It's all about a risk/income balance. As anything we do.

Just to have this make more sense, the code:

This is the way I am not supposed to open my file.
Works like a charm, but it should not when accessing the file system.

public void init()  
    {
        java.net.URLConnection Conn = null;
        java.net.URL myUrl = null;
        java.io.InputStream fpointer = null;
        
        try{
            myUrl = new java.net.URL(this.getCodeBase().toString()+"/Kinkimono.ttf");
            fpointer = myUrl.openStream();
        }
        catch(Exception e){
            System.out.println("Bad url");
        }

In theory, I should use fpointer as a fileinputstream, and pass it a vaild file handle.
But the following code won't work.

try{
            fpointer = new FileInputStream("Kinkimono.ttf");
        }
        catch(Exception e){
            System.out.println("shoot, can't find the file:: " + " because::" + e.getMessage());
        }

Practically, this is just "applied Java coding experience", I wanted to do something the Java engineers did not expect and had blocked.
I managed to do it by abusing a feature they had expected... but didn't expect to be used this way.

It really all comes down to onions. Find the mismatch, and there you go.

Btw, as I said, I "suspect", but have not tested ways to use this from a remote applet.
Currently, the applet when run locally can bypass the Java security manager and read local files without any prompt, the user just has to open the web page which includes it.

This is convenient to geeks like me for demo purposes, and that's about it, but beware, do not open .html+.class attachments from untrusted sources.

If what I suspect is true, the trick could be extended to make it possible to load local content from a remote java applet.
I can hardly believe it works to that extent, but my little finger keeps saying "yo, they didn't even consider it would ever work locally".


...And they had no reason to consider it, theyre specs said "users will use urlinputstreams for content from the web, fileinputstreams for local files, the security manager takes care
of wether or not resources can be accessed" I love the concept.