Jens Olsson DVD011 06-04-06 1(5) Protecting games in a mobile world By Jens Olsson jeod02@student.bth.se 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, http://brew.qualcomm.com/brew/en/about/about_brew.html, 2006-03-29 Mobile phone development: J2ME Versus Brew, http://www.colinfahey.com/2002dec14_j2me_cell_phone/mobile_j2me_vs_brew.htm, 2006-03-29 Code Obfuscation, http://palisade.paladion.net/issues/2005Aug/code-obfuscation/, 2006-03-29 Gamesutra, http://www.gamasutra.com/features/gdcarchive/2003M/Crowley_Dale.ppt#360,12,Technology Breakdown, 2006-03-29 Symbian Website, http://www.symbian.se/, 2006-03-30 Nokia DRM and Download FAQ, http://www.forum.nokia.com/main/1,6566,1_41_50,00.html, 2006-03-30 Mobilehall, www.mobilehall.com, 2006-03-30 Mophun developer page, http://www.mophun.com/developer/, 2006-03-30 A generic DRM framework for J2ME Applications, http://nsantos.home.cern.ch/nsantos/papers/nsantos03DrmFramework.pdf, 2006- 04-06 . 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. 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