Determining the rooted device

Solar2D General Questions/Discussion
#1

Hello!

My Android application is troubled with ROOT user’s modification of the DB.

It seems that these users are installing tools that can edit DB.

I think that you must be a ROOT user to edit the DB, but can you determine if the Android device is ROOTed with Corona SDK?

I would like to make it impossible to play the application on ROOTized devices.

I am not using Corona Enterprise.

#2

I don’t think you can determine that, but maybe putting your DB in the ApplicationSupportDirectory instead of documents will help?

Note: I may be wrong about this, so take this suggestion with a grain of salt.

#3

Hey, I forgot to ask, but why do you want to prevent users from editing the DB?

Does it cost you money?  Does it endanger secure data?  Does it ruin the experience for ‘non-cheaters’?

If not, I’d leave it alone.  

Just think of these users as being in one or more of these categories:

  1. Users who would never give you money anyways.
  2. Users who love your game so much that they want to hexedit (that’s what we called editing game data in my day) your game files.
  3. Users who just don’t have the patience to play through all aspects of your game.

If you make it impossible for group #2 to play your game, any supposed gains from blocking 1 and 3 will be completely overshadowed by the damage you do yourself.

#4

Thank you reply.

In my application, game currency and skills / experience values etc are stored in DB.

These are used in conjunction with the management on the server on the network, but since I want to play even offline, I use it with local storage and hybrid.

In the case of rooted devices, maybe system.ApplicationSupportDirectory will also be seen.

As a result, I do not want to activate it on a device which is ROOT.

Thank you.

#5

even if you detect the system is rooted to run your devices it takes less than 1 minute bypass that protection.

using  system.ApplicationSupportDirectory right now it’s not a good bet because it has a bug (doesn’t work on ipad). waiting for that. still won’t be a secure way to save your data.

you could encrypt your sensitive data inside your database, or even just use a remote database with “secure” connection only or you can simply ignore it like roaminggamer suggested. 

#6

As carloscosta says, encrypting the fields might be the way to go, fairly quick and simple to implement.

#7

Thank you reply.

I am interested in field encryption.

Is this about the DB field?

Could you tell me the method in detail?

#8

Something like the below should work.

Of course the risk is that someone clever opens the DB when they have loads of coins, and discovers that “fidjf3289389sl!r434k_w” in the DB field “coinsDefinitelyNotHereGoAway” is what represents that amount of coins, and copies that value back in after they spent them.

A way round that is to change the encryption key each time the database is saved, and try and hide a value somewhere else in the database (or maybe a little text file) that allows you to lookup the correct key.

But basically if someone r** eally** wants free coins, they will find a way.

[lua]

– encryption.lua

local openssl = require( “plugin.openssl” )

local cipher = openssl.get_cipher ( “aes-256-cbc” )

local mime = require ( “mime” )

local m = {}

m.encryptionKey = “MyEncryptionKey”

m.encryptString = function (str)

  str = mime.b64 ( cipher:encrypt ( tostring(str), m.encryptionKey ))

  return str

end

m.unencryptString = function (str)

  str = mime.unb64 (cipher:decrypt ( str,m.encryptionKey))

  return str

end

return m

[/lua]

[lua]

– from anywhere else

local encrypt = require(“encryption.lua”);

local coins = 50 ;

local coinsEncrypt = encrypt.encryptString(coins);    – send this to database as string.

— to load back in

local coins = tonumber(encrypt.uncryptString(coinsEncrypt));      – load value from DB into coinsEncrypt as string.

[/lua]

#9

Thank you for your reply.

I’m sorry for the late reply.

I was experimenting with this concept.

I thank you for teaching the great concept.

Since I think that this is the easiest implementation method,

Implement the program with this.

Thank you!

#10

I don’t think you can determine that, but maybe putting your DB in the ApplicationSupportDirectory instead of documents will help?

Note: I may be wrong about this, so take this suggestion with a grain of salt.

#11

Hey, I forgot to ask, but why do you want to prevent users from editing the DB?

Does it cost you money?  Does it endanger secure data?  Does it ruin the experience for ‘non-cheaters’?

If not, I’d leave it alone.  

Just think of these users as being in one or more of these categories:

  1. Users who would never give you money anyways.
  2. Users who love your game so much that they want to hexedit (that’s what we called editing game data in my day) your game files.
  3. Users who just don’t have the patience to play through all aspects of your game.

If you make it impossible for group #2 to play your game, any supposed gains from blocking 1 and 3 will be completely overshadowed by the damage you do yourself.

#12

Thank you reply.

In my application, game currency and skills / experience values etc are stored in DB.

These are used in conjunction with the management on the server on the network, but since I want to play even offline, I use it with local storage and hybrid.

In the case of rooted devices, maybe system.ApplicationSupportDirectory will also be seen.

As a result, I do not want to activate it on a device which is ROOT.

Thank you.

#13

even if you detect the system is rooted to run your devices it takes less than 1 minute bypass that protection.

using  system.ApplicationSupportDirectory right now it’s not a good bet because it has a bug (doesn’t work on ipad). waiting for that. still won’t be a secure way to save your data.

you could encrypt your sensitive data inside your database, or even just use a remote database with “secure” connection only or you can simply ignore it like roaminggamer suggested. 

#14

As carloscosta says, encrypting the fields might be the way to go, fairly quick and simple to implement.

#15

Thank you reply.

I am interested in field encryption.

Is this about the DB field?

Could you tell me the method in detail?

#16

Something like the below should work.

Of course the risk is that someone clever opens the DB when they have loads of coins, and discovers that “fidjf3289389sl!r434k_w” in the DB field “coinsDefinitelyNotHereGoAway” is what represents that amount of coins, and copies that value back in after they spent them.

A way round that is to change the encryption key each time the database is saved, and try and hide a value somewhere else in the database (or maybe a little text file) that allows you to lookup the correct key.

But basically if someone r** eally** wants free coins, they will find a way.

[lua]

– encryption.lua

local openssl = require( “plugin.openssl” )

local cipher = openssl.get_cipher ( “aes-256-cbc” )

local mime = require ( “mime” )

local m = {}

m.encryptionKey = “MyEncryptionKey”

m.encryptString = function (str)

  str = mime.b64 ( cipher:encrypt ( tostring(str), m.encryptionKey ))

  return str

end

m.unencryptString = function (str)

  str = mime.unb64 (cipher:decrypt ( str,m.encryptionKey))

  return str

end

return m

[/lua]

[lua]

– from anywhere else

local encrypt = require(“encryption.lua”);

local coins = 50 ;

local coinsEncrypt = encrypt.encryptString(coins);    – send this to database as string.

— to load back in

local coins = tonumber(encrypt.uncryptString(coinsEncrypt));      – load value from DB into coinsEncrypt as string.

[/lua]

#17

Thank you for your reply.

I’m sorry for the late reply.

I was experimenting with this concept.

I thank you for teaching the great concept.

Since I think that this is the easiest implementation method,

Implement the program with this.

Thank you!