Text obfuscation techniques

Solar2D General Questions/Discussion
#1

Does anyone have any suggestions on text obfuscation techniques?

A large part of my game is going to be content that is going to be stored in JSON files.  Since we know that these files could be easily accessible to someone who knows how to open an iTunes IPA file or Android APK file, I want to obfuscate the text so someone can’t go in and just easily grab the content directly.

I was going to encrypt the data and then decrypt it using the OpenSSL plugin but that doesn’t seem to work and haven’t gotten any possible suggestions on that front (http://forums.coronalabs.com/topic/48495-cannot-decrypt-data-correctly-with-openssl-plugin/), so wondering if there was some quick, but effective, way to obfuscate the text some other way.

Has anyone done this before?

#2

You could use a Base64 encoding technique.  If you require the mime library:

local mime = require(“mime”)

Then I think the functions are like:  mime.b64() and mime.unb64()

See:  http://w3.impa.br/~diego/software/luasocket/old/luasocket-2.0-beta/mime.html

You can also find other versions out there as well, like in the Lua string recipies I think.  There is the old ROT13, but it only works on the letters A-Z and a-z. 

#3

A simple way is base64 encoding, as Rob said.

But if you are assuming that person is able unpack you ipa/apk file it should not be difficult to him to also decode your base64 json.

So, if you want to use something more secure, you need to use the open ssl plugin. I have successfully used it as below:

local cypher = "RC2-40-CBC" -- The "RC2-40-CBC" complies with the US export because it has less than 64 bits. local encodeKey = "your\_secret\_key" -- encrypt the data local function encrypt(data) local openssl = require "plugin.openssl" local cipher = openssl.get\_cipher (cypher) -- cypher can be "aes-256-cbc", "RC2-40-CBC",... return cipher:encrypt ( data, encodeKey) end -- decrypt the data local function decrypt(data) local openssl = require "plugin.openssl" local cipher = openssl.get\_cipher ( cypher ) return cipher:decrypt ( data, encodeKey ) end
#4

Thanks guys for the suggestions.

Rob, what you suggested is something I had thought of but ruled out as it doesn’t really offer any protection, just a slight deterrent.  I don’t need 256 bit encryption, but wanted something that someone would need to apply at least a little effort  to try to get the data directly.  :slight_smile:

Renato, I wonder if there is just some incompatibility with the files that the openssl implementation in OS X generates and how the OpenSSL plugin operates.  I did not use the plugin to encrypt the files, since I only need to decrypt them on the device.  So I had openssl on the Mac encrypt the files.  Maybe I can just write a quick app that encrypts my JSON files and writes them to files in the Documents folder and do that on the Simulator.  Then I can just copy those encrypted files to my code folders for decrypting in the app.  Maybe that will take care of the issue.  Let me go try that.

Thanks again to both of you.

#5

I would guess so.

#6

That worked, Renato.  Thanks.  Never thought that I should try encoding the content using the same plugin.  Kind of assumed that they would all need to be interoperable since it’s a standard.   :slight_smile:

Another question for you Renato, if I may.

So using the 40-bit encryption (which is totally satisfactory for my needs) keeps it in compliance with US export laws.  Does that mean that I don’t need to specify that I am using any cryptography in the app?  Or must I specify that I am, but that it falls under the exceptions provided by the US gov’t?

#7

In summary, If your app uses any kind of encryption, you should mark that you app uses it on the iTunes Connect.

If it belongs to one of the exceptions, you would also mark so (iTunes will give you that option).

Basically, all games are excepted, as stated at http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#15

So, you don’t have to bother with anything else.

Sources:

ITunes Connect Export License FAQ: https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/10.0.0.13.7.2.7.9.3.1.2.3.3.1.5.7.1

BIS: http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#15

#8

Very informative thread. Thank you. Marked for future use. 

PS. Something on my todo list is to check out the new library called Crypt from Graham Ranson. Apparently it is a little like GGData but with full encryption built in. Might be something of use for you as well. 

#9

Thanks again for the information, Renato.   :slight_smile:

#10

@ksan,

Will need to check that out.  Hadn’t heard of that yet.  Thanks.

#11

You’re most welcome. See at http://www.grahamranson.co.uk/portfolio/crypt/

#12

You could use a Base64 encoding technique.  If you require the mime library:

local mime = require(“mime”)

Then I think the functions are like:  mime.b64() and mime.unb64()

See:  http://w3.impa.br/~diego/software/luasocket/old/luasocket-2.0-beta/mime.html

You can also find other versions out there as well, like in the Lua string recipies I think.  There is the old ROT13, but it only works on the letters A-Z and a-z. 

#13

A simple way is base64 encoding, as Rob said.

But if you are assuming that person is able unpack you ipa/apk file it should not be difficult to him to also decode your base64 json.

So, if you want to use something more secure, you need to use the open ssl plugin. I have successfully used it as below:

local cypher = "RC2-40-CBC" -- The "RC2-40-CBC" complies with the US export because it has less than 64 bits. local encodeKey = "your\_secret\_key" -- encrypt the data local function encrypt(data) local openssl = require "plugin.openssl" local cipher = openssl.get\_cipher (cypher) -- cypher can be "aes-256-cbc", "RC2-40-CBC",... return cipher:encrypt ( data, encodeKey) end -- decrypt the data local function decrypt(data) local openssl = require "plugin.openssl" local cipher = openssl.get\_cipher ( cypher ) return cipher:decrypt ( data, encodeKey ) end
#14

Thanks guys for the suggestions.

Rob, what you suggested is something I had thought of but ruled out as it doesn’t really offer any protection, just a slight deterrent.  I don’t need 256 bit encryption, but wanted something that someone would need to apply at least a little effort  to try to get the data directly.  :slight_smile:

Renato, I wonder if there is just some incompatibility with the files that the openssl implementation in OS X generates and how the OpenSSL plugin operates.  I did not use the plugin to encrypt the files, since I only need to decrypt them on the device.  So I had openssl on the Mac encrypt the files.  Maybe I can just write a quick app that encrypts my JSON files and writes them to files in the Documents folder and do that on the Simulator.  Then I can just copy those encrypted files to my code folders for decrypting in the app.  Maybe that will take care of the issue.  Let me go try that.

Thanks again to both of you.

#15

I would guess so.

#16

That worked, Renato.  Thanks.  Never thought that I should try encoding the content using the same plugin.  Kind of assumed that they would all need to be interoperable since it’s a standard.   :slight_smile:

Another question for you Renato, if I may.

So using the 40-bit encryption (which is totally satisfactory for my needs) keeps it in compliance with US export laws.  Does that mean that I don’t need to specify that I am using any cryptography in the app?  Or must I specify that I am, but that it falls under the exceptions provided by the US gov’t?

#17

In summary, If your app uses any kind of encryption, you should mark that you app uses it on the iTunes Connect.

If it belongs to one of the exceptions, you would also mark so (iTunes will give you that option).

Basically, all games are excepted, as stated at http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#15

So, you don’t have to bother with anything else.

Sources:

ITunes Connect Export License FAQ: https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/10.0.0.13.7.2.7.9.3.1.2.3.3.1.5.7.1

BIS: http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs#15

#18

Very informative thread. Thank you. Marked for future use. 

PS. Something on my todo list is to check out the new library called Crypt from Graham Ranson. Apparently it is a little like GGData but with full encryption built in. Might be something of use for you as well. 

#19

Thanks again for the information, Renato.   :slight_smile:

#20

@ksan,

Will need to check that out.  Hadn’t heard of that yet.  Thanks.