J Comput Virol (2006) 2:101–107

DOI 10.1007/s11416-006-0014-0

O R I G I NA L PA P E R

The Java mobile risk

Daniel Reynaud-Plantey

Received: 3 January 2006 / Accepted: 5 May 2006 / Published online: 8 June 2006
© Springer-Verlag France 2006

Abstract Mobile security is a relatively new field of ogy of the experimental study will be explained. Then,
research. The specific risks and counter-measures have Sect. 5 underlines some problems that are seldom men-
not been studied thoroughly yet. Java can be useful in tioned for the user. Finally, Sect. 6 underlines a few
this field because it has been designed to run untrust- problems that analysts have to consider in order to
ed code safely on mobile, heterogeneous networks. This disassemble a midlet correctly.
paper, based on an experimental study of the low-level
security of Java 2 Micro Edition (JSR 118 Expert Group,
2006), identifies some potential problems and their solu- 2 Quick Introduction to J2ME
tions in case Java malicious applications appear in the
wild. This section briefly explains what is J2ME compared to
J2SE and J2EE and how it is organised.

1 Introduction 2.1 Different platforms, different flavours

Java technology is particularly interesting in mobile envi- Java was supposed to be a kind of universal language,
ronments because of its built-in security features and able to run on smart cards as well as on mainframes.
portability. These features include downloading over the As obviously you do not expect the same features from
air and running untrusted code in a safe environment, as such different devices, the Java technology has to adapt
well as end-to-end security with networking and cryp- to what people expect from it and to the capabilities
tography APIs. of the device it is running on. For example, a Java pro-
This paper focuses on the practical aspects of the risks gram must be able to run for days without rebooting
associated with Java 2 Micro Edition. Though the archi- on an enterprise server. But on a workstation, you have
tecture is roughly the same as the standard edition, there different expectations: you probably want to use short
are differences that induce specific problems. An exper- term applications with an efficient graphical user inter-
imental study of J2ME low-level security has been con- face. That’s why Java comes in different flavours:
ducted on a Series 60 phone in order to identify and
evaluate some of these risks. • Java 2 Enterprise Edition (J2EE), for running scal-
After a quick introduction to J2ME, configurations, able enterprise applications;
profiles and the new verification scheme, the methodol- • Java 2 Standard Edition (J2SE), aimed at worksta-
tions;
• Java 2 Micro Edition (J2ME), for mobile devices;
D. Reynaud-Plantey (B) • Java Card, for smart cards.
Ecole Supérieure et d’Application des Transmissions,
Laboratoire de virologie et de cryptologie,
B.P. 18, 35998 Rennes Armées, France For the Java developer, it means two things: with a single
e-mail: [email protected] language, you can write applications for every platform.
102 D. Reynaud-Plantey

But it also means that you will have to write code for a rations are not enough and as a result profiles have been
given platform, and it usually means that you may have defined. A profile is a set of APIs which sit on top of a
to use different language constructs (for example you given configuration in order to take better advantage of
might not perform floating point operations on a smart the features of a device.
card), and you will definitely have to use different APIs. Six profiles have been defined, but only one is a CLDC
This might or might not be a big deal, depending on what profile: Mobile Information Device Profile (MIDP). It is
you want to do exactly. From a security perspective, the made to take advantage of the capabilities of the latest
broad range of devices might sound appealing to mali- mobile phones, and its APIs cover user interfaces, con-
cious programmers but they will have to face another nectivity, data storage, messaging and gaming. Profiles
drawback of the Java technology: the lack of low-level only address security issues at the application and end-
control (such as pointer arithmetic or OS-specific fea- to-end levels. For instance, they can provide cryptogra-
tures). phy APIs or features such as access to the file system.

3 A closer look at J2ME 3.3 J2ME low-level security

3.1 Configurations The main difference between J2SE and J2ME from the
security approach is that J2ME introduces a new ver-
So far, we have seen that J2ME was intended to bring ification algorithm. A Java program is subject to some
Java to mobile devices. These devices include mobile restrictions: it cannot explicitly deallocate memory, ac-
phones and PDAs as well as washing machines, TV set- cess a specific memory location, or interact directly with
top boxes or car electronic equipment. What do they all the OS. To ensure that a Java program can’t perform
have in common? They are mobile, which means they these operations, it is first loaded in memory and then
have a limited amount of memory and computing power. verified. The verification process is a very complex topic
All their other characteristics may vary, some of them and if it is not made correctly the whole security architec-
might need batteries, some might have a good band- ture collapses. The new verification algorithm in J2ME
width or not, and some might not even have a screen. comes along with an important modification in the class
As a consequence, Java needs again to be adapted to file format specification: a new attribute called Stack-
different kinds of mobile devices, depending on their Map has been defined. Each method must contain a
capabilities. This is the role of a configuration [4]: pro- StackMap attribute which makes the verification pro-
vide the basic set of functionalities for a specific group cess faster and less memory-consuming. Basically, there
of devices with similar characteristics, such as the total must be a stack map at the beginning of each basic block
amount of memory and network connectivity. There- in a method indicating the number and the types of the
fore, a configuration provides a virtual machine and a objects on the stack for this basic block. The former
set of core classes. algorithm consisted in inferring and then checking type
Two configurations have been defined: safety, with StackMap attributes the inference step can
be skipped.
• Connected, Limited Device Configuration (CLDC) From the developer’s point-of-view, it means that
[10]: it is the configuration currently in use on mobile additional steps are required before a program can be
phones and some PDAs. It is defined in the Java run. After the compilation, the classes must be preveri-
Specification Request (JSR) 30. fied (by the developer) and packed in a jar file. The so-
• Connected Device Configuration (CDC): for de- called preverification step adds the StackMap attributes
vices with more memory and processing power. From along with some other modifications. The name is quite
the developer point of view it is closer to J2SE. deceptive however, because it is actually an additional
compilation more than a verification. The real verifica-
3.2 Profiles tion can only take place on the virtual machine of the
user.
We have seen that J2ME had to be split into configura- There are some other important differences between
tions in order to fit on different devices. But even similar J2ME and J2SE from the security perspective, for exam-
devices like mobile phones might offer different ranges ple in J2ME there is no support for custom classloaders
of memory and processing power. They also might have and for the Java Native Interface (JNI). These two fea-
more to offer in terms of underlying user interface, or tures are very useful for virus writers and are almost
advanced features like Bluetooth. This is why configu- needed for high-level, sophisticated viruses.
The Java mobile risk 103

4 Experimental study

This section is a quick overview of the experimental

study which led to this paper [9]. The goal of this study
was to test the low-level security of a J2ME implemen-
tation on a telephone.

4.1 Testing strategy

There are two major strategies for testing software: white-

box (or structural) and black-box (or behavioural) test-
ing. The main difference between these strategies is that Fig. 1 Class files organisation
white-box testing assumes that the tester has access to
the source code of the application. Though there is a
reference implementation of the KVM for which the that the bytecode verifier has not been tested directly
source code is available, there is no way to tell exactly because of the specific amount of work needed, it would,
which VM is installed for a given phone (and even if the however, be worth testing too.
reference KVM is used, it might have been compiled
with different options set). Another interest of white- 4.3 Target
box testing is its ability to test each component of the
software individually. This is not extremely useful for The next step was to define exactly the target of the
vulnerability assessment because bugs might be located study, that is to say the kind of bugs to look for. Ulti-
in “unreachable” parts of the code, and therefore might mately, the goal was to find class files as shown in Fig. 1.
not be exploitable. Moreover, due to the embedded na- The expression class files is used instead of classes be-
ture of the KVM it is impossible to instrument its code cause the study involved creating invalid class files, which
on the telephone, and as a consequence white-box test- may not represent any class (according to the specifica-
ing the KVM would have meant working on a PC rather tion). This distinction is very important: jar files are cre-
than a telephone. ated, containing class files, which might eventually but
For all these reasons, black-box testing was chosen. not necessarily be parsed and translated into working
Practically speaking, it means that test midlets had to classes. Figure 1 refers to the set of “safe” Java class
be created, installed and run on the telephone, and then files. Giving a formal definition of “safe” is very hard,
the behaviour of the telephone had to be observed and and this is not very important for this study (we can as-
analysed. sume that “safe” and “valid” mean the same). The set
of verified Java class files is also mentioned, it is the set
4.2 Coverage of class files that will be declared valid by a verifier. The
mission of the verifier is to validate only safe class files,
When people refer to Java low-level security they usu- but Fig. 1 shows that some unsafe class files are verified.
ally refer to the bytecode verifier. However, on a J2ME For this study, we assumed that the subset of unsafe but
implementation some lower levels are worth testing. verified class files existed, and this is what we are looking
Here are the potential targets for a test: for.

• The installer; 4.4 Tools Used

• The jar file handler (of the installer or the KVM);
• The class file format integrity checker; At the time of the study, no low-level manipulation tools
• The bytecode verifier; for jar (i.e. zip) files could be found. And one of the
• The runtime environment; only standard tools for manipulating classes was Jasmin,
• The APIs. a Java assembler. Its purpose, however, was more to
learn the virtual machine’s instruction set rather than
In order to produce accurate results, the object of the to create invalid files. Moreover, the existing Java disas-
test had to be narrowed. Therefore, the focus has mainly semblers were not satisfying, most of them crashing or
been put on the jar file handler and the class file format giving no output when they encounter an invalid class
integrity checker. It turned out that the installer was file. Therefore there was a need for new tools, fulfilling
tested too, though it was not a primary objective. Note the following requirements:
104 D. Reynaud-Plantey

• They must give sufficient low-level control over the • A Nokia 6680. It is a Series 60 v2 phone, with CLDC
creation of binary files (zip and class); 1.1 and MIDP 2.0 on Symbian OS v8.0a;
• The disassembling tools must work on broken, in- • Sun Wireless Toolkit 2.3 Beta as the emulator;
valid, illegal or truncated files. This is a very strong • Java 1.5 SDK on Windows XP SP2 as the J2SE run-
constraint, and this is one of the top reasons to create time environment.
new tools;
• The tools must automate a maximum of the process Finally, what is the nature of the errors in the jar and the
of creating invalid midlet suites. class files? The ZIP file format specification and the class
file format specification define data structures with cer-
The toolkit has been written in Java, it has a command- tain structural or semantic constraints. The idea was to
line interface and has been released under the GNU create jar and class files with invalid values for each data
General Public License [8]. It contains the following structure, one at a time. For example, for an unsigned
tools: 4-byte value in a class file, it can be tested for the values
0, 0xFFFF, 0x7FFFFFFF, 0xFFFFFFFF and some other
values that might seem interesting or are declared for-
• zip2xml: a zip “disassembler”. It converts a zip file bidden for this particular data structure. This technique
to an equivalent xml file, each element in the xml is inspired from a more general idea called fuzzing [1],
file representing a data structure defined in the ZIP which can be applied to any input parser and which
File Specification [6]. consists in generating slightly invalid input for a given
• xml2zip: the opposite tool, taking the xml represen- parser, or valid input but with unusual sizes or values in
tation of a zip file and producing the binary file. The order to find implementation flaws.
output file can be totally invalid because each value
in the specification can be modified manually.
• jasmin: the de-facto standard Java assembler. For 4.6 Test results
the occasion, it has been updated in order to give
more control over the output files. Some of the latest First of all, no security flaw was discovered during the
Java attributes are now also supported. study. However, some interesting results were found and
• dejasmin: a Java disassembler, able to produce out- their consequences are going to be detailed in the fol-
put in the new Jasmin format. lowing sections. Here is a quick summary:

• A serious J2SE bug has been found in the class file

A future improvement idea would be to provide tools
parser and has been reported to Sun [3] (the attri-
such as class2xml and xml2class in order to give absolute
bute_length, a 4-byte unsigned value, was parsed as
control over the output class file.
a signed value).
• There were many differences between the telephone
4.5 Experimental protocol and the emulator, contrary to one of the initial asser-
tions in this study. For example, it was possible to
Once the strategy, the target and the tools have been create a jar file that can run correctly only on the
found, an experimental protocol had to be defined. The telephone, not on the emulator.
idea of producing test files, running them on the tele- • Some totally unexpected behaviours showed up, par-
phone and then analysing its behaviour is fine but it ticularly in the Application Management Software
would have given nothing. The problem is that on the on the telephone. For example, the result of a given
tested telephone, when an error or an exception is thrown, installation can depend on the previous installations.
the VM shuts down silently. There is no error message or It was even possible to craft a particular jar file which
stack trace that could help understanding the problem. installation always fails but will also make the next
Therefore, it is impossible to make behavioural testing installation of a midlet fail.
with just a telephone, precisely due to the lack of ex- • Many bugs seemed to come from the fact the the
plicit behaviour. A small workaround has been used: installer unpacks and parses each class file in the jar
first produce invalid jar and class files, and then run file (detailed in Sect. 5.3).
them on a telephone, an emulator and a J2SE runtime • The jar file parsing is totally different for J2SE, for
environment. This way, it is possible to understand the the emulator and for the VM on the telephone (de-
behaviour of the KVM on the telephone, compared to tailed in Sect. 6.2). This might be exploited by mal-
the other VMs. The test platform was the following: ware authors to protect their creations.
The Java mobile risk 105

A detailed analysis of the results as well as the results has to answer yes when prompted and you have full
raw data can be found at [9]. access to the system of the victim.
To have a midlet signed for the trusted third party do-
main, it is possible to use the Java Verified program [2].
5 The Java mobile risk for the user It was initiated by the industry under the Unified Test-
ing Initiative label. It is a commercial program giving
This section underlines the importance of mobile de- you the opportunity to promote your midlet and to use
vices security for the user and some problems that might the Java Powered logo. In order to be signed, the midlet
not always be obvious: namely that a nice logo does not has to be tested automatically and manually by a test
necessarily mean the product is secure and that installing provider (which is a company). If the midlet is compli-
a program without even running it can be dangerous. ant with some quality and behaviour rules it is signed
and will run in the trusted third party domain on mobile
phones for which the UTI Root Certificate is available.
5.1 A sensitive environment Users have to be aware that running a Java program
with the Java Powered logo, which has been thoroughly
Why would there be a specific risk for mobile Java? The tested and digitally signed does not mean it is not a
short answer is the potential cost for the user. Java is malicious application. This is possible because programs
widely used on the web for applets and though there such as Java Verified are commercial and are therefore
have been historical security problems with them, hos- made for commercial applications. It means that when
tile applets have not been that important. Given the fact you submit your midlet for testing, you do not have to
that the average workstation can be considered compro- provide the source code. And due to some intellectual
mised in some way, people don’t seem to pay too much property legislation, the tester probably does not have
attention to “exotic” threats such as Java malware. How- the right to reverse engineer the application to check
ever, if a malicious application gains control of a mobile that there are no hidden features. So the tester can just
phone, it may be able to send an arbitrary number of ensure that the program is not a malware by just using it a
SMS or MMS, or even issue calls. Therefore, the serious few times, which is of course impossible. Consequently,
risk here is to end up with a huge monetary cost for the malicious applications can undergo the Java Verified
user. testing process successfully, the malware author just
Another problem specific to mobile phones is that has to implement something like: if (date < some-
the damage done to the device can be hard to put back. Date) then showFakeGame() else launchReal
It might for example be impossible to totally disinfect Malware(). This is not specific to the Java Verified
a virus or restore some data. The simplest solution in program, it is true for every behaviour-based testing
many cases is probably to just replace the telephone program.
with a new one.
5.3 Malicious installation
5.2 Signed midlets
The study which led to this paper outlined many prob-
To gain more privileges on the target device, a mid- lems in the Application Management Software on the
let can be signed. It can then access a different pro- telephone. It is the piece of software responsible for the
tection domain, depending on the MIDP version and installation and removal of applications on the phone.
the root certificate used to sign the application. MIDP Most of these problems showed up while testing the
2.0 defines four protection domains: Untrusted, Trusted JAR file format. The purpose was to study the response
Third Party, Operator and Manufacturer. An unsigned of the virtual machine to specially crafted JAR files
midlet runs in the untrusted protection domain, with but it turned out that most of the time these JAR files
very few privileges. For example, an untrusted midlet never reached the virtual machine at all because they
can only access the file system with explicit user approval caused errors in the AMS. It was surprising because
and the access to some files might not be permitted at some behaviours that have been observed were totally
all. The trusted third party domain does not allow full unexpected, for example on the tested telephone the
access to the system, as opposed to the situation with ap- AMS seemed to unpack each class file in the archive
plets. And it is no longer interesting to self-sign midlets (even unused class files) and to parse them up to this_
because they will run in the untrusted domain. The sit- class (it is a field in class files located after the constant
uation is better for malware development with applets: pool). Though there must be a good reason for it to be
you can self-sign your malicious applet and the user just implemented this way, it is quite puzzling.
106 D. Reynaud-Plantey

The problem with these kind of behaviours is that they 6.1 What you see is not what you run
are unexpected because they are totally undocumented.
For testers, it sounds more likely to find bugs in undocu- This is particularly true if midlets are to be reverse engi-
mented pieces of software that in publicly specified and neered. Analysts are very skilled people but they are
reviewed processes such as the bytecode verification. It humans: they are going to use tools to do their job. The
turned out to be true: it was very easy to find bugs in the problem is that most Java reverse engineering tools are
AMS and they might eventually become security flaws. outdated, if maintained at all. Most disassemblers and
This is even more deceptive for the user because we decompilers have been developed at a time when people
naturally have the intuition that it might be dangerous found it revolutionary that you could translate accu-
to run something. In this case, it might be dangerous rately Java bytecode back to source code. In the mean
to install something, without even having to run it to time, the Java language has evolved and J2ME appeared.
trigger the payload. J2ME introduces a new verification process with Stack-
Map attributes. If a vulnerability is found in the verifier,
it may use malformed StackMap attributes. Therefore
5.4 Need for more usability
it might be impossible to understand the vulnerability
without looking at the StackMap attributes. And here is
The general impression is that the whole J2ME secu-
a big problem for the analyst: StackMap attributes are
rity architecture is way too tight. Developers need more
silently ignored by most Java reverse engineering tools,
features, and users want more usability. For example,
along with other new attributes. So it is possible to spend
they want to be able to install a game without being
hours trying to figure out what a given program does, but
prompted five times with “are you sure?”, and then five
it is just impossible without some “hidden” attributes.
more times in the game when it tries to use Bluetooth
The last problem of analysis tools is the way they re-
to connect to their friend and to access the file system to
solve ambiguities. Sometimes, file format specifications
save the game. In the early times there was no support
might contain ambiguities that might complicate the file
at all for Bluetooth or file I/O, now it is supported but
parsing. The class file format is very well specified and
with a lot of security prompts. These security prompts
there are only very few ambiguities. Here is an exam-
are likely to disappear or at least to be less omnipresent.
ple of ambiguity: as specified in the Java Virtual Ma-
This approach, setting up a J2ME environment with “too
chine Specification, the attribute_length field of a
tight” security, must be intentional. The industry prob-
ConstantValue attribute must be 2. But what hap-
ably did not want a virus outbreak in the early days of
pens if a class file parser encounters an attribute with
mobile Java but the situation is probably going to evolve
name “ConstantValue”, a physical length of 2 but an
as J2ME environments mature.
attribute_length value different from 2? The behav-
On the tested telephone, it seemed to be impossible to
iour is implementation-dependant and might vary be-
make a Java virus without breaking the sandbox because
tween a real virtual machine which might skip this attri-
the file connection attempts at other JAR files threw a
bute and a reverse engineering tool which might not
SecurityException. This is good news. However, the bad
know what to do with this strange attribute. These kinds
news is that the file permission system is not transpar-
of ambiguities are very common in the zip file format.
ent at all, and it is more than likely that it is telephone
The solution to these problems is to use up-to-date,
dependant and maybe even firmware dependant. Any-
reliable and low-level reverse engineering tools. The tin-
way, it is not transparent at all, therefore there is a risk
apoc toolkit described in Sect. 4 has been created for this
as explained above.
purpose.

6.2 Multiple behaviors exploitation

6 The Java mobile risk for the analyst
Different systems have different reactions, or behav-
In this part of the paper, we assume that mobile Java
iours, when they have to deal with slightly invalid input.
malicious applications exist in the wild (this is currently
Here are some of the possible behaviours:
not the case) and that they have to be analyzed quickly
in order to be stopped. So the word “analyst” refers to
a reverse engineer trying to figure out what a given mal- • Clean exit;
ware does. Some of the problems analysts might encoun- • Error message and exit;
ter with their reverse engineering tools are going to be • Warning but the program tries to cope with the error;
underlined here. • Bug or incorrect behavior;
The Java mobile risk 107

• Crash; analysts need to be equipped with efficient tools. Finally,

• Nothing: the error has not been noticed. we have seen that a general but simple way to increase
the security of J2ME is to adopt more transparent imple-
By running slightly invalid jar and class files on different mentations and to take care when removing security
platforms, very different behaviours have been encoun- measures.
tered: The current security level of J2ME implementations
is satisfying but likely to decrease. Java viruses for J2ME
• On the telephone: “clean exits” for the VM (some are probably going to appear, even as proof-of-concepts.
crashes might have not been noticed, anyway there The last thing is that the landscape of Java malware
was no error message). Lots of bugs and incorrect is almost empty. In the short run, real J2ME malware is
behaviours in the AMS. not likely to appear because it would need a lot more
• On the emulator: very broad range of response, work than native malware, for less benefit.
there was a quite large number of crashes though.
• On the PC: usually an error message with the stack Acknowledgements My thanks go to Mr. John Healy, lecturer at
trace, useful for debugging. the Galway-Mayo Institute of Technology in Ireland, who directed
and helped me throughout this study. I would also like to thank
the Irish officers from USAC in Galway for their support and
We can notice that the behaviours are very different on invaluable friendship, as well as Lieutenant-Colonel Filiol for his
each platform for the same input files. It means that for confidence in my work.
a given input file, different virtual machines will react
differently. It is quite easy to craft a jar file that will run
only on a telephone but not on an emulator or a PC with References
such results. The problem is that it can be exploited by
malware authors if they study the behaviour of a tele- 1. Holz, T., Van Sprundel I.: Recherche de vulnérabilités à l’aide
phone and compare it to the behavior of a debugger or du fuzzing, MISC - Le magazine de la sécurité informatique,
23, janvier (2006)
a disassembler. It is even easier for debuggers because 2. Java Verified:Unified Testing Criteria for Java(TM) Tech-
in order to debug a midlet, a debugger has to connect to nology-Based Applications for Mobile Devices, Version 2.0,
a running emulator. So if the emulator does not handle http://www.javaverified.com
the file successfully, the debugger will fail too. Disassem- 3. J2SE Bug Report http://bugs.sun.com/bugatabase/view_bug.
do?bug_id=6352834 (2005)
blers are harder to fool but in order to work, the class 4. JSR 118 Expert Group Mobile Information Device Profile
files have to be extracted from the JAR file and it is very for J2ME, Version 2.0, http://www.jcp.org/en/jsr/detail?id=118
easy to produce hard-to-parse JAR files. (2006)
To summarize: by studying the reactions to errors in 5. Lindholm, T., Yellin, F.: The Java Virtual Machine Specifica-
tion (Java Series), 2nd ed., Addison-Wesley, Reading (1996)
input files for different systems (a target phone, an emu- 6. PKWARE : ZIP File Format Specification 6.2.1.,
lator, an extraction utility), it is easy to produce a midlet http://www.pkware.com/(2006)
that will run but cannot be analysed without modifica- 7. Reynaud-Plantey, D.: Reverse Engineering and Java
tions. The solution would be to specify the exact behav- Viral Analysis. In: Proceedings of the 2005 Virus
Bulletin International Conference, pp. 121–126.
ior of an implementation when it encounters an error. http://www.esat.terre.defense.gouv.fr/cresat/articles/java_mal-
In practice this is impossible to achieve, therefore there ware_analysis.pdf (2005)
is a need for reliable and low-level analysis tools. 8. Reynaud-Plantey, D.: J2ME Low-Level Security.
http://tinapoc.sourceforge.net/ (2005)
9. Reynaud-Plantey, D.: J2ME Low Level Security: Imple-
mentation Versus Specification, Engineer Diploma Thesis.
7 Conclusion http://prdownloads.sourceforge.net/tinapoc/Reynaud_J2ME.
pdf?download (2005)
We have seen that the user must be aware of the spe- 10. Sun Microsystems Inc: Connected, Limited Device Configu-
ration 1.1 (JSR-139). http://jcp.org/jsr/detail/139.jsp (2003)
cific risks of mobile Java. The threat is less serious than
on PCs but it might evolve. And in case the situation
evolves and malicious applications appear for J2ME,