I had a think about this a while ago. My conclusion was:

- In general, you can't
- But you can dissuade people a little.

This is what I think might be a good idea:

- each copy of the MIDlet bought contains a unique code (product key)
- The Midlet, upon starting, checks the RMS store for a matching key to go with its built in key.
- If it's not found, or not valid, it prompts the user to go online to fetch one
- It speaks to a server, via HTTP, giving its product key to receive a matching key back, which it then stores in RMS
- The HTTP server stores the fact that the key has been used to register the game
- If the same game is registered more than one or two times, you can disable the key - rendering it useless for future registrations.
- The game won't play if it cannot register and has no valid key.

The only snag with this problem is
- If the RMS is copied with the game, the game will continue to work
- There is (on most vendors) no way to determine the device's serial number, so you can't make the RMS data nodelocked

Mitigating options:
- Make the RMS phone model specific - although the chances are, it can only be copied to other phones of the same model (or similar) anyway, because RMS is stored in a vendor-specific fashion on the device

There are some tools I've seen for Nokia which can literally just copy anything out of or into the device's filesystem - which includes the MIDlet itself and also its RMS data.

There is nothing you can do about this, unless there is a way of detecting the device's serial number.

---

Extra problem: There is nothing stopping someone reverse engineering and modifying the MIDlet. Midlets are not, and cannot be signed or verified at runtime by any means (You cannot read class files from the JAR to check for modifications, or anything)

Of course MIDlets are obfuscated, but this only makes it harder to reverse engineer, not impossible.

So don't try too hard, it's simply not worth it.

Mark

Quote:
Extra problem: There is nothing stopping someone reverse engineering and modifying the MIDlet. Midlets are not, and cannot be signed or verified at runtime by any means (You cannot read class files from the JAR to check for modifications, or anything)

Actually you can read the class files from the jar AFAIK, but it would still be a futile effort because if someone has managed to reverse-engineer your MIDlet, he can modify the verifying code too.

shmoove