JavaUtils is a command line tool supporting Java ME application reverse engineering round-trip and code flow analysis through instrumentation.
JavaUtils can work directly with case-sensitively obfuscated MIDlets and contains limited support for DRM protected MIDlets.
Though specialized for the J2ME platform, it can be used with other Java platforms as well.

Contents

Main Concepts

  • Reverse engineering

    • get MIDlet's Java source code - necessary to help you understand what the code does. The Java source code can not be recovered fully (with comments etc.) and many times not completely. Thus injection of modified source code back to the MIDlet  may not always be possible.

    • get MIDlet's Java assembler source code. Java assembler language maps directly to the virtual machine bytecodes. This source code is always available and it's modified version can be always injected back to the MIDlet. The assembly language used is encoded in XML format suitable for machine processing. Small modifications are simple, but larger changes may be too low-level for humans as thorough knowledge of the Java Virtual Machine's instruction set is needed (see http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html).

  • Code Flow analysis

    • debugging - get MIDlet's Java source codes through reverse engineering, use them to recreate the project with e.g. Eclipse IDE, use breakpoints and runtime memory browsing to find out what is going on right now. This is the most programmer-friendly way, with very low performance overhead, but not always possible as the Java source codes can not be always recovered. Debugging alone does not explain multi-threaded sequencing and synchronization issues.

    • code trace logging - get MIDlet's source codes, instrument it with instructions that record code flow into a log file. Typically you want to know when a method was entered with what arguments and what it returned as a result. Run the instrumented MIDlet and afterwards use the log file to find out what was going on. With JavaUtils you can always get automatically user-friendly multi-threaded nested callstacks of all methods with their arguments and both explicit (synchronized statement entered/left) and implicit (synchronized method entered/left) monitor locking. The tracing however may produce quite large log to be analyzed, may degrade performance significantly and as the timing is modified due to logging overhead, some timing-sensitive issues may not be reproducible.

How to use it (FAQ)

I have a DRM protected MIDlet. How can I instrument/analyze it?

You'll have to extract the plain JAR file first. Assuming you have a separate-delivery OMA content file yourapplication.dcf and rights file yourapplication.dr, use command

JavaUtils decrypt yourapplication.dcf yourapplication.dr extracted.jar

This command creates plain extracted.jar. Use it as normal. After making the required changes you can use it as it is, or DRM protect it again using command

JavaUtils encrypt yourapplication.dcf yourapplication.dr extracted.jar

I have a MIDlet that does not run in Sun's Wireless Toolkit - some classes are missing. What is wrong?

  •  

The MIDlet is obfuscated so that the JAR contains both lower case and upper case classes. Such JAR can not be mapped to the Windows file system (extracted) without loss of information. Use command

JavaUtils reobfuscate yourapplication.jad

to rename classes to be file system compatible.

  •  

The MIDlet uses some vendor specific class. Use command

JavaUtils xref yourapplication.jad list_of_methods.xls

to create Excel table list_of_methods.xls with all classes, interfaces and methods referenced by the MIDlet. Use Excel to go through all external references. If you find some that seems to be vendor specific (e.g. starting with com.nokia), you'll need to create empty stub for that class and add it to the yourapplication.jar. You can use project pstros.jar located in JavaUtils distribution folder to get the stub's class template. To do the extraction,
modification, injection you can use the Java assembler source code format. See commands disasm, asm for more.


Basic tasks

3.1 Convert obfuscated MIDlet into one that can be safely unzipped

3.2 Decompile MIDlet as Java source code

3.3 Create missing JAD file

3.4 Instrument MIDlet to generate code flow log

3.5 Decode code flow log into human readable form

Advanced tasks

4.1 Extract DRM protected content

4.2 Get list of classes and methods used by a MIDlet

4.3 Inject modified Java source code into MIDlet

4.4 Decompile MIDlet as Java assembler source code

4.5 Inject modified Java assembler source code into MIDlet

4.6 Perform J2ME compliant bytecode verification of a modified MIDlet


Licences

Following 3rd party components are included in the distribution:
  • ICSharpCode.net ZipLibrary (http://sharpdevelop.net/OpenSource/SharpZipLib)
    Java archive file I/O
  • Jad - the fast Java Decompiler. Copyright 2001 Pavel Kouznetsov (jad@kpdus.com http://www.kpdus.com/jad.html)
    Java class file to Java source code decompiler
  • ASM 3.1 TODO:
    Java bytecode assembler/disassembler
  • pstros.jar TODO:
    Provides vendor specific class wrappers
Following 3rd party components are used by the tool and must be installed separately:
  • Microsoft .NET Framework 2.0 TODO:
    Runtime library for the tool
  • Java Runtime Environment TODO:
    Runtime library for the ASM 3.1 tool
  • Sun's Wireless Toolkit TODO:
    Provides J2ME compliant bytecode verification

References

  • Normative

  • Informative

Máte otázky, připomínky?