Tài liệu Protecting games in a mobile world docx

Jens Olsson DVD011 06-04-06
1(5)




Protecting games
in a mobile world


By Jens Olsson









Abstract
I have decided to investigate the different
problems with releasing games on mobile
handsets. The report will be focused on the
release of games, but many methods are the
same and can be applied for mobile applications
as well.
While I am not studying at the university I am
working at Imotus Mobile Games, which gave
me the motivation to investigate this. I will base
the report on the problems and challenges we

have encountered trying to protect the games
we have developed. I hope this will give the
report a real-world connection and make it
interesting to read.
Examples of protections that will be discussed
are: lock a game so that it can run on one device
only, encrypt the game so that resources and
source code cannot be examined, reverse
engineered or extracted by malicious users.
This will in many cases provide the possibility
to prevent users to copy games between each
other, prevent solution and media stealing,
prevent reverse engineering of critical
algorithms, prevent code tampering in for
example multiplayer games.
Jens Olsson DVD011 06-04-06
2(5)
Introduction to mobile
technology
First I would like to start with an introduction
of some different mobile phone software
platforms to give an overview of the
possibilities that exist on the mobile software
and gaming market. I will not cover all
languages and platforms here but at least some
of them in general.
Java
Java is probably the first thing that people think
about when mobile games are mentioned.
Supported by 2.5 million handsets worldwide as

of 2006
1
it is certainly the largest platform by
far. But it is one of many solutions and it has
the disadvantage of being slow. Sun has
developed a special version of java for devices
with less processor power and memory (like
mobile phones) called J2ME. Java 2 Micro
Edition. In J2ME there are 2 main APIs. The
APIs are CLDC (Connection Limited Device
Configuration) and MIDP (Mobile Information
Device Profile) working together.
Mophun
Mophun is a gaming platform for mobile
phones made by a Swedish company,
Synergenix. Mophun uses C/C++/Assembly as
programming language. Code is compiled to a
special byte code that runs on a special virtual
machine that is adapted to all the handset
models that are supported.
2

For a game to run it has to have a valid
certificate from Synergenix. It also has to be
signed by a distributor. Mophun uses an
advanced DRM system for protection.

1
Gamesutra
2

Mophun Developer page
Brew
3

Brew (Binary Runtime Environment for
Wireless) is a game and application platform
made by QUALCOMM. Supported by 2.5
million handsets worldwide as of 2006
4

“The brilliant idea behind BREW: Connect the
mobile marketplace value chain, which includes
application developers, publishers, content
providers, device manufacturers, operators and
customers with a full offering of products and
services dedicated to a global marketplace for
wireless data - built from the ground up for
wireless.” – About Brew
Symbian
Symbian is a special operating system for
mobile phones seen on many advanced phones.
Symbian phones support development in both
C++, J2ME, PersonalJava and Visual Basic. It
does not include any specific protections of the
software.
5


3
About Brew Website

4
Gamesutra
5
Symbian Website
Jens Olsson DVD011 06-04-06
3(5)
OMA DRM
6

OMA DRM made by The Open Mobile
Alliance is not a platform like the other
platforms above. It is a system to protect any
content delivered to a mobile phone, not only
software but also images etc. OMA DRM adds
functions like:
Encrypted deliveries
Content can be encrypted before delivered to
the handset. This makes de-compilation much
harder.
Forward-lock
Prevents users to forward content they have
bought and downloaded to others. It is up to the
device to prevent the game to be forwarded to
another phone.
7

Combined-Delivery
Is much like forward lock but if a game is
forwarded to another mobile phone user, the
game will still run. It will then run either in a

demo mode with maybe just a few levels or
with a time limit of game play, or maybe
playable only once or during 24 hours.
Separate-Delivery
Is much like Combined-delivery, but content is
delivered encrypted in one package and the
usage rights are delivered separately. This
makes it possible for a user to send a game to a
friend etc. and the friend then have to option to
either get a preview license or a full version
license for the game.

6
Nokia DRM and Download FAQ
7
A Generic DRM Framework for
J2ME Applications
Challenges
I will describe 4 different challenges that I have
encountered when developing for Imotus
Mobile Games. I will then show how some of
these issues can be solved.
Challenge 1: Copy
Protection
A great challenge with computer software and
games is how to prevent users to get the
software/game without paying for it from a
friend or from the Internet. This problem exists
on mobile handsets as well. On some handsets
this is prevented by not allowing access to the

software’s/game’s files. This however only
makes it a bit harder. It is still possible to
intercept the game delivery via for example a
computer.
In J2ME there is no built in copy protection.
Furthermore compiled java games can easily be
decompiled to source code with a de-compiler
(For example jad). This makes it easy to
analyze the source code of a game and to
remove any copy protection existing. To protect
from this threat there exist obfuscation software
that can be used to make it harder. Obfuscation
changes the compiled code making it more
complicated and in a way that makes it very
hard to understand by humans. Obfuscation
does not prevent from decompiling although it
makes it hard to find where the copy protection
is located and how it is designed to work.
Obfuscation programs work with special
patterns and are often predictable.
Disadvantages of using obfuscation are that
there is software that can de-obfuscate
obfuscated code for known obfuscators.
Obfuscation also often comes with a
performance penalty.
Mophun has this already solved. The distributor
will sign each game with a special tool.
Distributors get new signing certificates each
month to prevent people from using stolen
certificates. Games developed in Mophun have

a time bomb protection (makes sure that a game
can only be installed on the date it was signed).
It also has an optional IMEI lock. This locks the
game so that it can run on the phone with the
specific IMEI number it has been signed for
only.
Jens Olsson DVD011 06-04-06
4(5)
Another generic solution is to make the
program connect to the author’s server and
require the user to logon with a serial number
for example. Then the program retrieves some
small essential parts of the program from the
server that is required for the program to run.
8

One method is to compile the program at
delivery. It is then possible to have a program
that is locked to the specific phone model and
maybe other parameters like IMEI number for
example. The problem with this is that most
market places for mobile games on the Internet
and on the WAP portals does not support
compile at download. So this solution is maybe
only a solution in theory.
At Imotus one of our approaches to the problem
is to make sure a certain binary of the game is
valid for one phone model only. It is not as fun
for people trying to break copy protection on
software that runs on only one phone because

they will then target a much smaller audience. It
is also not that easy for people to share games
with each other because chances are that people
who want to share have different phone
manufacturers and phone models. There are
over 700
9
mobile phones that support for
example J2ME so this may be a big problem for
people trying to release cracked versions. I have
not found any documents describing this
approach thought.
Challenge 2: High score list
Many games for mobile phones offer the
players after finishing a game to upload their
high score to an on-line high score list on the
World Wide Web. This is usually done by
sending the name and score and some kind of
web server. The problem with this is how to
prevent users from reverse engineering the
binary and find out how the request looks like
and create their own (client-side security).

8
Mobile phone development: J2ME
Versus Brew
9
Mobilehall
Many developers use a checksum to make it
harder to fabricate registrations. This solution

relies on that the server and the game share a
secret algorithm for calculating checksums and
this algorithm has to be protected from the
malicious user.
In Java there is a serious problem with this
scenario because the algorithm to calculate the
checksum is inside the game binary and can
therefore be examined and reverse engineered
with a de-compiler. A tool to register any score
can be invented. To protect from this we need
to prevent users from reverse engineering the
source code.
In Mophun the built-in code tampering and
code de-compilation protection makes the life
much easier. All games released on the Mophun
platform must be certified and is then encrypted
with a private key. All mobile phones have a
public key that can decrypt the games. This
makes any code recompilation useless if the
aim is to copy the program or make changes,
because there is no way to have this code
encrypted again so that it can run on a handset.
In theory it would probably be possible to find
out the key and get the unencrypted binary from
the phone.
Another solution would be to use OMA DRM,
developed by the Open Mobile Alliance, to
prevent the code being decompiled and
examined. OMA DRM (Open Mobile Alliance
Digital Rights Management) is something quite

similar to the protection used in Mophun.
None of these solutions however protects from
malicious users listening to network traffic
trying to analyze the algorithm by taking
samples. However one of these 2 methods
combined with a for example Diffie-Hellman
handshake and encrypted connection to transfer
the high score over would probably be
sufficient to protect the transmission.
Jens Olsson DVD011 06-04-06
5(5)
Challenge 3: Multiplayer
gaming
Just as with multiplayer games on personal
computers, it is possible to modify the binary
code of a game so that it will give you
advantages over other players. But it is maybe
even easier on a mobile phone because most
games are written in Java and can therefore be
de-compiled to fully understandable and
editable source code. Just decompile, edit some
parameters and recompile.
On a PC it is often possible to solve this by
actively validating using the server. On a
mobile phone on the other hand it is much more
difficult. Network connection on those devices
has far too high network latency for this to
work in real time.
Challenge 4: Solution
protection

One problem with delivering games to an end
user is how to protect the solutions and graphics
etc from use by other parties. With java for
example as earlier mentioned is easy to extract
both source code and resources like images and
sounds with a de-compiler like jad and a jar
archive utility.
In Mophun the whole game is encrypted and
can only be decrypted by a mobile phone.
Furthermore if someone gets the old of code to
use Synergenix must validate and certify the
game. There is no other way to get the game
released, and this of course increases security
even though it would still be possible because
the key is in every phone.
Conclusion
Software protections in the mobile world are rather similar to protections on the personal computer. There
exit a few advantages and disadvantages though. Most mobile phones are closed devices and are protected
in a way that it is very hard to access the internals in order to bypass copy protection etc. If combined with
sending the games encrypted we got a rather good copy protection and it feels like copy protection on the
mobile phones are much easier to achieve there than on PC.
The high score problem is something that cannot be completely solved. The device has to have some way
of reading the game, and then it is also possible for people to read it if they reverse engineer the device.
Maybe to be sure, high score lists can only exist on turn-based games that connect to a server to validate the
result. En encrypted game and a diffie-hellman type handshake would probably be sufficient though. It will
require very much of the malicious gamers to bypass such a protection.
Sources
About Brew Website, 2006-03-29
Mobile phone development: J2ME Versus Brew,
2006-03-29

Code Obfuscation, 2006-03-29
Gamesutra, Breakdown, 2006-03-29
Symbian Website, 2006-03-30
Nokia DRM and Download FAQ, 2006-03-30
Mobilehall, www.mobilehall.com, 2006-03-30
Mophun developer page, 2006-03-30
A generic DRM framework for J2ME Applications, 2006-
04-06