By default Shared Preferences on Android are being able to be deleted by phone setup. Is it possible to block this ?. Basically i would like to store a Shared Preference as defined on Android documentation but not to allow to delete them by any reason. Ie Phone Setup, App update nor App uninstall. If this is not possible, which storage mechanism would you suggest to do this. I need to store is primitive data mostly.
I am making an application where I need to collect certain data from user and ensure he will have just one opportunity to provide it, otherwise she would be cheating. I agree, best option is to store the data provided on my server but that approach would not work if user turn off internet. I understand both requirements might be very difficult to meet.
It is possible to delete any data stored on the phone.
Shared preferences and files not saved to the SD card will be deleted when the app is uninstalled.
Files saved to the SD card will persists after uninstall, however, the user will have access to read, over-write, and delete these files at will.
If you need truly permanent storage the best way forward would be to store the data remotely on a server that you control.
What you're suggesting of doing sounds dangerous to me.
Bear in mind that when you're programming, you're programming within a certain environment. The operating system will restrict aspects of what you can and can't do, to keep consistency across applications, provide security etc.
If you're wanting to use shared preferences as a means of providing trials for applications, or some other registration-related issue, I don't know what the framework is on Android, but I believe there's more secure ways of doing it.
Related
I have an application that use a .properties data containing password from DB, this application will be used by my client but I don't want to give him any kind of access to this properties data, not even if we look in the .jar. I thought to use zip4j but is there any another best solution for this because when I unzip it the .properties will be decompressed somewhere giving the client access to it doesn't it??
This cannot be done. Just forget about this idea and re-think your system.
You can't provide read access not providing read access at the same time.
This is a wet dream of legal depts in the media industry. They invest piles of money in solving this insolvable problem with DRM that never works, but annoys everybody.
You can make it more annoying to extract the data - using various obfuscation techniques - but that's all.
One of those ideas is to encode the passoword in C++ library and link it via JNI. Then the user cannot extract it without disassembling the binary file, but will be able to make memory dump at runtime anyway.
You can read the password from central server at runtime. You can use one-time passwords for that. Again, this is futile if the user has modest technical skills, as you can still request the server for the password using curl or some simple script.
You can use hardware access-token that will allow connection to the database (smart-card or something). This was quite popular technique in '90.
All you can do is to add some level of annoyance which will stop non-technical person. With enough money you can build some decent DRM that will stop technical-savvy people for a while, but I seriously doubt it's worth the money.
If the database access is so precious that you can't give the user access to it, yet he needs it, your design is broken.
I need to add something that generate an activation code in my android app so the app features should work only if the app is activated. what is the best way to do that ?
If I understand the question correctly, what you want to achieve is technically impossible.
Any functionality your app has is already there in the app, downloaded to the client. A user can use a debugger to disassemble the app file and change your source code to either not require an activation code or accept any code (whatever is easier, but both are possible). Anything you give to a client should be considered as being fully controlled by the client, any logic in there can be changed, secrets can be seen, etc.
This may not be straightforward, especially if you use some kind of an obfuscation, but it will always be possible. The question is only the effort needed.
And the effort is key here. In some scenarios, protecting low-value resources, it may be good enough to deter the lowest profile attackers. It's always about risk and the cost of protection. But you need to be aware of the above, that the logic in an app cannot be protected.
So if you want to protect your stuff, you have a few options for different scenarios:
Have two separate apps, one free without paid functionality included and one paid. Users can use the free one and then buy the other if they want.
Have paid functionality served by a server. If critical business logic is on the server side, you can really enforce access control rules and you can maintain control over who has access. This may have serious implications on your app architecture and functionality though.
If the value you are trying to protect is low, you can go for obfuscation and access control logic in the app as mentioned above, but you need to be aware that this can be cracked relatively easily, especially on Android by changing the apk.
I believe you cannot do this with just your app, you definitely need the help of server which would generate an activation code for you and match it with the logged in user. Once the generated activation code is passed on to the user via email or any other means, then you can match the activation code given by the user and then match with the one in the server and if they match, let them use the features.
I hope this is what you want. But I might even be dumb enough to misunderstand you. Let me know if this is what you want.
My client wants to setup a script/file in Ubuntu in one of my client's contractors system to monitor his work/sites visited etc as long as he is in office.
His contractor will have root access in the system, so how can we make sure that the file cant be changed ? Deleting wont help him as his boss will know that because he wont get the online reports anymore after deleting.
But he can change it to the way he wants. Actually, we can write a java.java file or python or some program file but I found that even java.class files and python.pyc files can also be decompiled.
So, he can easily know the program and can easily change it.
So, any solution for this ?
Assuming you have legal issues taken care of, your only hope seem to be Encryption and Security through Obscurity.
Go for languages which are tougher to decompile, such as C/C++ (see this)
Ensure that you collect a lot of data, and store all the data encrypted so the client cannot directly access it.
Try and obsfucate to hide away your encryption keys, as well as the encryption algorithm.
Send the data from the contractor's system to the server encrypted.
Possibly also monitor whenever the contractor killed your process.
The best solution would be not to do this.
Now I don't know about your country's legislation, but in mine, any solution of this sort would be highly illegal. If the client is worried about the contractor, there would be other means of "monitoring" them.
Daily reporting
Set up a proxy blacklisting sites, possibly enforcing it over network tools
Actually meet the person and talk with them about their achievements, difficulties and such. Not inquiring, actually caring about how the project is going. If that doesn't motivate the contractor to work, nothing will.
I have created an informational android app where we manually entered lots of data using our resources.It uses sqlite database.
I know it virtually impossible to protect the database 100% but I want to make it difficult so that every tom,dick or harry does not just runs a reverse engineering software in apk and get the database and create a new app or use it as a part of their app(information is found every where but our data entry effort is all wasted)
So, How can we protect our database?
I saw some SQLCipher and some other libraries.
But I found that actually the password are hard-coded in java files which can be easily reversed engineered and will be available. So,I am not understanding how it really protects rather than adding just another easy to crack layer.They will just get password from file and open that database. Plus it is increasing the application size as well.
So how does it really protect from real thief?
Am I missing something?
I just want to protect my database(even not bothered much about code for now).
Any help or suggestions?
Thank you.
SqlCipher, this will might work in your case and best security provide
Read an interesting article about securing XP,http://www.expertreviews.co.uk/software/1304965/when-windows-xp-support-ends-this-is-how-you-secure-your-pc-and-save-all-updates.
With these suggestions is building apps for the marketplace ok with this setup to get by w/o headaches.
Here are my noob thoughts and question:
Just learning to code. Do you think I could run a limited setup to learn languages Java and C# while still being able to use my desktop for deployment of apps? A limited login as described only allows certain actions which I believe is different than a typical guest account. I wonder if my comp could still act as a server to retrieve data requested by users away from my machine. I figure I would need to be logged in as an admin to make some changes but, would hope that tasking processes or jobs could still be done.
I guess my question is, do users of a program you made need access to a local machine for some functions and would that work in limited?
I would like to get something portable and keep my desktop for business to be economical and not run the risk of logging on to an unsecure Wi-Fi with a portable that has business use. Ideally, I'd pony up for newer, better. I'm just learning though.
Do users of a program you made need access to a local machine for some functions and would that work in limited.
No. If you need some sort of server backend for your app a personal computer would be a bad choice for several reasons:
It would need to be available at all times: you can't frequently turn it off or restart.
It would require the same ip address.
It could consume a good amount of you're computer's resources, making it difficult to use for personal use
Instead you should probably be using a dedicated server or a cloud based solution, of which several offer free usage tiers.