- Main Concepts
- How to use it (FAQ)
- Basic tasks
- 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
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).
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.
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,
- ICSharpCode.net ZipLibrary (http://sharpdevelop.net/OpenSource/SharpZipLib)
Java archive file I/O
- Jad - the fast Java Decompiler. Copyright 2001 Pavel Kouznetsov (email@example.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
- 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