3

I'm developing an Android game that has to download some assets to the SD card to keep the size of the app as small as possible. I was thinking of using an uncompressed zip file to bundle all the assets.

A requirement from the client is to protect these assets as much as possible. Being part of the apk is considered enough protection, but if I do this the apk size will be enormous. If I just put a zip bundle in the SD card, then anyone can unzip it and explore its contents.

Is there a simple way to do this without retorting to horrid DRM?

Obviously if someone really wants to check the resources of an Android game, they can. I'm just looking for a simple solution to avoid making this very easy.

hpique
  • 119,096
  • 131
  • 338
  • 476
  • 1
    Just checking - do you realise that an APK file is just a renamed zip file? It can be opened with any program that can open a zip, and many Android file browsers don't even require you to change the file extension. Therefore including the assets to be protected in the apk isn't any protection at all, regardless of file size issues. A lot of your code and manifest is compiled/encrypted with your dev key, but things like images are available raw. – Steve Haley Apr 23 '10 at 11:10
  • I believe the user can't easily access the contents of the APK file if you turn copy protection on. Not saying it's a foolproof method, though. – hpique Apr 23 '10 at 11:13
  • @Steve H - If you "forward lock" the app by ticking the relevant box when uploading to the market then users can't find the `.apk` easily on an unrooted phone. This isn't going to stop someone determined but it will prevent casual browsers finding the assets which I think is the intent here. – David Webb Apr 23 '10 at 11:21
  • Ah, does copy protection on the app prevent backup programs from making a backup of the APK on the sdcard? If it doesn't then getting the apk is still rather easy. I admit I don't know much about that option other than that it doubles the size of your APK which can be prohibitive with large games. Anyway, Dave has made a good suggestion already so listen to him, not me :p – Steve Haley Apr 23 '10 at 11:33

1 Answers1

4

You could encrypt the ZIP file with AES but there would an overhead in extracting the assets which might be a problem since performance is usually fairly important when writing a game.

However, as you've said yourself using a secure encryption isn't really worthwhile since if someone's really interested they can find the keys in the source code of your application. So you could write an InputStream and OutputStream yourself to perform some trivial translation on the bytes of the ZIP file. This would be quick to undo when reading the file but would "corrupt" the ZIP file enough to deter someone just browsing through their SD card.

When using it you'd put your stream in between the File and ZIPInputStream, e.g.:

File assets = new File(Environment.getExternalStorageDirectory(),"assets");
ZipInputStream zip = new ZipInputStream(new TranslateInputStream(assets));

As an example translation, you could just XOR all the bytes with a known value:

private static final byte MAGIC_NUMBER = 13;

private void translateBuffer(byte[] buffer) {
    for (int i = 0;i < buffer.length;i++) {
        buffer[i] ^= MAGIC_NUMBER;
    }
}

private class TranslateOutputStream extends FileOutputStream {
    public TranslateOutputStream(File file) throws FileNotFoundException {
        super(file);
    }

    @Override
    public void write(int oneByte) throws IOException {
        oneByte ^= MAGIC_NUMBER;
        super.write(oneByte);
    }

    //In Android write(byte[]) calls this method so we don't need to override both        
    @Override
    public void write(byte[] buffer, int offset, int count)
            throws IOException {
        translateBuffer(buffer);
        super.write(buffer, offset, count);
    }
}

private class TranslateInputStream extends FileInputStream {

    public TranslateInputStream(File file) throws FileNotFoundException {
        super(file);
    }

    @Override
    public int read() throws IOException {
        return super.read() ^ MAGIC_NUMBER;
    }

    //In Android read(byte[]) calls this method so we don't need to override both        
    @Override
    public int read(byte[] buffer, int offset, int count)
            throws IOException {
        int bytesRead = super.read(buffer, offset, count);
        translateBuffer(buffer);
        return bytesRead;
    }
}

Alternatively, you could not use ZIP as you don't care about compression. Just concatenate all the assets together in one large blob. As you create the blob write the start and end location of each asset out to an index file. The index file would then be included in your .apk file allowing to get the data you needed from the big file in your application. As the big blob wouldn't be in a standard format people wouldn't be able to easily extract files from it. To be extra sure you could always pad the beginning of the file with some other data - perhaps just some plain text - to make the blob look like something else.

Community
  • 1
  • 1
David Webb
  • 190,537
  • 57
  • 313
  • 299
  • This looks like a simple and efficient solution. Will give it a try. Thanks Dave! – hpique Apr 23 '10 at 11:21
  • I think I prefer the stream transformation solution to the blob one. The former would allow me to easily update assets, while the latter would require a bit more work to regenerate and update the index file. – hpique Apr 23 '10 at 11:59