Google has unveiled their mighty Android platform SDK today. It apparently based uses that phone-based flavor of Java. An ergonomic Eclipse-based development environment and a software emulator are both provided for your experimentation.
That’s nice. But let’s cut to what really matters — multimedia. The SDK specifies the Media API along with its MediaPlayer and MediaRecorder APIs. According to the AudioEncoder class, audio can be encoded to AMR-NB. The VideoEncoder class specifies H.263, H.264, and MPEG-4 SP. All pretty standard for a mobile application, I suppose.
Who handles the multimedia heavy lifting? Vitor noticed this press release and associated fluffy overview from PacketVideo
It’s Java, though, and that means obfuscated Java bytecode programs. Time for a renaissance for my Java de-obfuscator?
Looking at the SDK (that comes with a linux image and a modified qemu) it seems that the multimedia library is a native binary (libmedia.so) with a java wrapper…
Found this:
http://www.gearlog.com/2007/11/fresh_hot_specs_googles_androi.php
And I seriously doubt that the codecs will run inside the VM. I guess they will use a jni interface. But if we are lucky the OpenCore stuff has a nice enough license for other use.
The classes for .class -> .dex converter are not obfuscated at all and can pretty cleanly decompiled by Jad. So it shouldn’t be too hard to write a Dex converter or at least a dumper. The emulator image includes “dexdump” but I couldn’t get it working.
What I find sort of puzzling is that Android doesn’t seem to make use of Jazelle acceleration. Maybe Google didn’t want to pay license fees to ARM or they found performance sufficient as is…
Although Android is programmed in Java, it doesn’t use Java Bytecode! Google has apparently developed a new VM architecture called Dalvik, details of which are fairly thin on the ground right now.
I’m just hoping that the horrible old stack machine of JBC (and the similar one in .net) has been consigned to the 70’s trash can where they belong, and a modern VM-ISA has been created. By “modern” I mean something that readily maps onto an ARM or similar RISC ISA, both simplifying the JIT, and opening the door to a proper direct implementation of the ISA in hardware.
That way, the VM performance hit might be low enough to do this all in native Dalvik bytecode.
Of course, I forgot to mention that any interest in reverse engineering a phone app is entirely predicated on whether there is anything interesting to RE released for the Android platform. Still, people seem to be interested in RE’ing Blackberry code modules, so there must be some interesting phone apps.
The OpenCore framework will be licensed under the Apache v2 license.