0

I'm looking for a way of obfuscating the images I store in my application and am currently considering Base46 Encoding.

I need something with minimal overhead or if possible a performance boost over standard files on the file system.

Can someone comment on the feasability of base64 encoding the images (png) and subsequently using (decoding?) on the target platforms?

Thanks.

Hamid
  • 4,410
  • 10
  • 43
  • 72

3 Answers3

2

What sort of attack are you trying to protect against? Base64 is reasonably easily recognizable and has a potentially-significant impact in terms of space (each image will take an extra 33% space).

Some sort of shifting XOR would be harder to spot just from the data, but it wouldn't be adequate protection for really significant assets.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • The intention is to stop opportunists, we have no intention of spending significant time or resource on this because frankly, no "protection" is safe. Our main concern is minimal overhead, as close to zero overhead as is possible. I have read previously that storing multiple images in a single base64 encoded file "chunk" is one such way, but I am unsure as to the suitability. – Hamid Mar 16 '11 at 18:10
  • 1
    @Hamid: If you really want "quick and simple" with little overhead, keep it in a binary format and just XOR everything with a constant value. It's enough to make the file invalid as a png "as-is" and should take absolutely minimal coding. It also won't have any space overhead. – Jon Skeet Mar 16 '11 at 18:25
  • Would that be preferable compared to just xoring a certain number of bytes within each image file? – Hamid Mar 16 '11 at 18:56
0

I am sure you understand Base64 won't fool anyone who really want to get your Bitmap.

Jon Skeet is right, Base64 is nice to encode binary data in readable format but will not really help you here. An XOR against a password of yours will be faster, and won't add any size overhead.

If you really want to obfuscate your bitmaps I suggest you to store them in the "raw" ressources folder. By doing this you will be able to keep the nice Android abstraction that handles different form factors (ldpi, hdpi, ...). Extends the ImageView class to directly work with R.raw.filename id and do the reading file/decoding stream/creating bitmap there. By doing so, you will be able to rollback easily to the standard way of doing things if needed.

pcans
  • 7,611
  • 3
  • 32
  • 27
  • Coould you explain how storing them in raw would help with obufuscation? We require noneof the "abstration" you mention (hdpi/ldpi/mdpi/xhdpi) and infact explicitly require that none of the images we load handle this as it is taken care of explicitly within our application. – Hamid Mar 16 '11 at 18:11
  • Storing obfuscated bitmaps in raw folder won't help you to do any obfuscation. It will only help you to do it a clean way, allowing you to easily enabling/disabling it in your development cycle, without throwing away the nice resolution independent feature of the platform. – pcans Mar 17 '11 at 10:19
  • I see, so, as per my previous response, it doesn't really help, as I ecplicitly DO NOT want the resolution independant feature of the platform. – Hamid Mar 17 '11 at 11:33
0

Be warned that you could run into memory issues when storing multiple bitmaps within an application memory in Android. OutOfMemoryErrors seem to be a recurring problem when dealing with bitmaps in android. Here is an example: outofmemoryerror-bitmap-size-exceeds-vm-budget-android

Community
  • 1
  • 1
Twobard
  • 2,553
  • 1
  • 24
  • 27