Reverse Engineering: Finding the (Not So) Secrets of javaxnet10.dll

When I was restoring my Blackjack from backup last week, I noticed a file with an interesting name in the Yahoo! Go application folder: javaxnet10.dll

Eh? ... some kind of Java library? or a JVM? or maybe just a Microsoft runtime DLL for using J# with the .Net Compact Framework? Running J2ME apps on .Net CF would be a kind of cool... Ok, off to Google. A Google search for "javaxnet10" (over the web and newsgroup archive) produces several links to this single discussion thread where someone speculates on this exact question.

So I did some research. I'll save my conclusions and speculation for my next post; here, I'll tell you how I did my 10-minute analysis of this app. Old news to Win32 developers, but I think there may be a few .net/mobile/Web2.0 devs out there that might find this useful.

First, I used ActiveSync to pull all the DLLs and EXE for Y!Go off of my phone and onto my desktop. Then I right-clicked on the files to see if there was any metadata I could view that way. There was nothing -- either because it wasn't published, or it was removed at some point.

So I opened up a Visual Studio command prompt and cranked up dumpbin.exe. Dumpbin is a command-line PE format file processor. Since Windows Mobile is built on Windows CE and uses PE format for binaries, dumpbin doesn't care that these files are for a phone with an ARM processor rather than a desktop with an x86. Dumpbin will tell you which libraries a file loads, what it exports for other files to use, and all kinds of other fun stuff, including disassembly and -- get this -- it will disassemble an ARM binary into ARM assembly (the register names are the giveaway). I wonder how many instruction sets it understands?

But that's not relevant here because javaxnet10.dll is not a native code library at all.

It's a .Net assembly. How do I know? It reports a single import of mscoree.dll. mscoree.dll, short for "Microsoft component object runtime execution engine" is the .Net virtual machine. Or, as Don Box more poetically put it, "mscoree is the last COM DLL." He meant that metaphorically, not literally, of course. "mscorlib," he continued, "is the first .Net DLL," since that's the base library that mscoree loads to do anything useful.

Ok, let's look at all the files from Y!Go and see how they break down: javaxnet10.dll is .net, platform.dll is .net, ygonet.exe is .net, interop.dll is native (it imports a handful of OS binaries, and not the .net runtime -- try dumpbin /dependents to see).

So this is looking like a .Net CF app, with a native interop helper library for things that are hard or impossible to do with .Net CF. But we still haven't answered the question of what javaxnet10.dll is about.

Since it's a .Net assembly, we can bring in the magical MRI machine of dot-net, Lutz Roeder's .NET Reflector. This tool is an amazing free application that allows you to fully explore the insides of a .Net assembly, from the class-and-namespace level down to full decompilation. And, since .Net IL is much richer in metadata than native assembly, the decompilation produces intelligible code in the .Net language of your choice!

Point the .NET Reflector at javaxnet10.dll, and the mystery is revealed: it's an implementation of most (maybe all) of the J2ME and MIDP APIs. It does not run Java bytecode (it's not a JVM, interpreter, or cross compiler). Instead, it implements Java platform interfaces the way WINE implements Windows APIs. Here's a screenshot... the namespaces read like a tour of the MIDP API.

Just to confirm our understanding, we can basically browse the source of the whole application, and see the use of Java types and patterns everywhere. For example, StringBuffer is the classic Java equivalent of .Net's System.Text.StringBuilder. Although the waters have been muddied with the recent introduction of a Java class called StringBuilder, J2ME/MIDP predates that API by years. Which is to say, if the app were being written in a .Net CF style, we would see StringBuilder in high-level functions even if Java libraries were leveraged down below. In a Java mobile style, we'd see StringBuffer. The fact the we see StringBuffer (and many similar cases) argues that, in fact, this is basically a Java app. Heck, com.yahoo.go.app.YGo extends javax.microedition.midlet.MIDlet.

'Nuff said. Next time, we'll talk about the significance or usefulness of our discoveries, and where javaxnet10.dll might have come from.