I recently heard of a software security company that makes your code hack-proof in terms of reverse engineering and code modification. Their technique is this:
They insert checksums in multiple check points in the code that secure the code between them. As the code flow is executed at every checkpoint the checksum is checked and if the code has been tampered with then the checksum fails and you know there has been code modification. If a checkpoint is removed then the next checkpoint will also fail because a checkpoint has been removed.
To buy their services would be completely out of budget for my project (an Android application) however I would like to implement that technique on my own.
Could someone offer some insight on how something like this could be implemented ? Also if there are other methods that one could use το prevent code modification please share.
(Just to clarify I'm aware of obfuscation, weird missleading code logic, and writing fake methods to further make the code difficult to read and will apply these methods too )
prevent code modification techniques
There is not any trick for complete avoidance of reverse engineering.
You basically can't protect your application from being modified. And any protection you put in there can be disabled/removed.
If you have the option of including shared libraries, you can include the needed code in C++ to verify file sizes, integration, etc
Hack-proof is a very loosely defined term. Even if you implement checksums on various portions of your code, there are many other exploits that you need to be aware of that would be outside of modifying the source code like injection, authentication, etc.. My recommendation to you is to worry less about how to prevent someone from modifying your code and focus more on protecting the vulnerable areas if they were to modify your source code including hashed and salted passwords, encrypted data transfer, etc..
Related
I have a little design dilemma. I have java and sql and no rules engine. I don't want to implement a full on rules engine either.
My scenario:
I have some input data, ie. code, description and an amount.
Using these i will pass them into a function which will run lots of if else statements which are my business rules and will determine the output.
I can do this in java, but the problem is that these codes and descriptions may change at anytime and so can the business rules, so my "if elses" need to change easily. My thought was given what i have to work with, is use a stored procedure in sql instead to manage the many if elses, and this can simply be changed by editing the stored proc and simply hitting f5, whereas with java, i'd have to modify the java code and recompile and deploy which takes much longer.
I would like to know if anyone has had such a problem and what were their experiences and successful approaches. The requirement is speed and being able to edit these business rules easily.
Thanks guys
If your requirement is only changing values to check in if and else statements then the answer by ema is the right way to go. If your requirement is that also the logic must be changed and refreshed on the fly then you need to externalize it and deploy apart. There are several ways to do this. In my experience I've used drools a library rule engine from codehouse now from jboss that allow to build from very simple to very complex rules in a scriptable way so that you can deploy your files change and reload it. this is the link to their site http://www.drools.org/
I have a class (Android Activity) which handles start-up of my application. The application has some pretty complex start-up rules. Right now it looks like a bunch of spaghetti and I'm looking for strategies for refactoring it.
It's honestly such a mess I'm having problems hacking it down to provides pseudo code. In general there are some rules for start-up that are basically codified in logic:
Steps:
Check for error on last exit and flush local cache if necessary
Download settings file
Parse settings and save settings to local native format
Using the values in settings, do a bunch of 'house keeping'
Using a value in settings, download core data component A
Parse component A and load up local cache
During this logic, its also updating the user interface. All of this is handled in a zig-zagging, single monolithic class. Its very long, its got a bunch of dependencies, the logic is very hard to follow and it seems to touch way too many parts of the application.
Is there a strategy or framework that can be used to break up procedural start-up code?
Hmmm. Based on your steps, I see various different "concerns":
Reading and saving settings.
Downloading settings and components (not sure what a "component" is here) from the server.
Reading and instantiating components.
Flush and read cache.
Housekeeping (not really sure what this all entails).
UI updates (not really sure what this requires either).
You might try splitting up the code into various objects along the lines of the above, for example:
SettingsReader
ServerCommunicationManager (?)
ComponentReader
Cache
Not sure about 5 and 6, since I don't have much to go on there.
Regarding frameworks, well, there are various ones such as the previously mentioned Roboguice, that can help with dependency injection. Those may come in handy, or it may be easier just to do this by hand. I think that before you consider dependency injection, though, you need to untangle the code. All that dependency injection frameworks do is to initialize your objects for you -- you have to make sure that the objects make sense first.
Without any more details, the only suggestion that I can think of is to group the various steps behind well structured functions which do one thing and one thing only.
Your 6 steps look to be a good start for the 6 functions your init function should have. If #2 was synchronous (I doubt it), I would merge #2, #3 into a getSettings function.
A recent question on SO lead me to an older answer about the Java Security Manager. My question about this line in that answer:
The security manager impacts performances though, and it is rarely used on the server side.
Can someone please back this up or refute? I thought there is always a security manager, a custom one or the default and that containers use it all the time.
In server-side code that you yourself write, I can't think for any need for you to use a SecurityManager, since if you are writing the code to perform some operation in your application, it's unlikely that you need to check if your code has the permissions that you have given it.
For instance, a lot of the methods in SecurityManager are related to IO operations - checkDelete(), checkRead(), checkWrite(), etc. The JDK library classes will call these methods when you try to create/write/read/delete a file, so calling them yourself would be pointless.
So it's unlikely that your server-side code would make much use of the SecurityManager. However, the code that your code runs in - if you are deployed in a servlet container for instance - might make use of these methods, because they are interested in determining if your code has some level of permission that they give it.
In my folder assets/data, there are a lot of XML files containing static data for my app.
It's really easy for someone to retrieve an APK, modify a part of it and install on a device.
I would like to prevent users to alter my static data by checking the integrity of my assets/data folder.
Initially I was considering to use MD5 checksum, but it will probably be too slow for the amount of files I gonna have (50-100).
Do you have any suggestion?
Edit:
This app is a game with an XML file describing each level.
I'll describe how you can effectively protect against modification and repackaging, not how you can protect the assets on their own, although you could ultimately apply the same technique to encrypting them. It's imperfect, but you can make modification significantly more difficult.
You sign the application with a certificate. Although they can remove yours, noone else can produce the same certificate when putting it back together. You can therefore check the signature of the application at runtime, to make sure it's what you expect.
Here's some cheap and nasty code to do this:
PackageManager pm = context.getPackageManager();
PackageInfo info = pm.getPackageInfo( context.getPackageName(), PackageManager.GET_SIGNATURES );
if ( info.signatures[ 0 ].toCharsString().equals( YOUR_SIGNATURE ) )
{
//signature is OK
}
where YOUR_SIGNATURE is a constant, obtained from running this code on the signed app.
Now, there are two remaining problems that you have already hinted at:
how can you stop someone just modifying the constant in the source code to match their certificate, then repackaging and re-signing the app?
how can you stop someone finding the check method and removing it?
Answer to both: you can't, not absolutely, but you can do a pretty good job through obfuscation. The free Proguard, but more usefully the commercial Dexguard, are tools for doing this. You may baulk at the current €350 cost of the latter; on the other hand, I have tried to reverse engineer apps that are protected like this, and unless the stakes were very high, it isn't worth the trouble.
To an extent, you could also do the obfuscation for (1) yourself; have the signature 'constant' assembled at runtime through some complicated programmatic method that makes it difficult to find and replace.
(2) is really a software design issue; making it sufficiently complicated or annoying to remove the check. Obfuscation just makes it more difficult to find in the first place.
As a further note, you might want to look at whether stuff like Google Licensing gives you any protection in this area. I don't have any experience of it though, so you're on your own there.
Sort of an answer although it is in the negative.
If the person has your apk and has decoded it, then even if you used a checksum, they can just update the code portion with the new checksum. I don't think you can win this one. You can put a great deal of effort into protecting it but if you assume somebody can obtain and modify the apk, then they can also undo the protection. On my commercial stuff, I just try to make the decoding non-obvious but not bullet proof. I know anything more is not worth the effort or even possible.
Perhaps you could zip up the xml files and put it in the assets/data folder; and then do a checksum on that .zip. On the first run, you could unzip the files to get the .xml layouts. See Unzip file from zip archive of multiple files using ZipFile class for unzipping an archive.
Probably the most reliable way would be for the level XML data to be downloaded from a server when the app is started with a check of the time stamp and sizes of the level files. That also lets you provide updates to level data over time. Of course this means you have the added expense of a server to host which may be another problem.
I've run Sonar on a project at work and found a violation 'The user-supplied array is stored directly'.
So looking a little deeper into what that means exactly I came across lots of stuff discussing it from security perspective (for example...). So when I read or hear 'security' I'm thinking malice, cracking, data breach and other grave consequences.
But I wonder what else could go wrong, especially in a load balance environment. Would this be a reason to worry about data contamination across sessions? One customers order data getting corrupted with someone else's details, etc?
Basically, you should consider this rule as very important if you're exposing a Java API to the rest of the world. The link you provided perfectly explains why (a consumer of your API would be able to change the array at any time if you don't clone it).
If violations occur in your internal implementations (that no one else will ever touch or use), you can lower the severity of the violations as there's no risk that a third-party code can modify the array. However, don't forget that code lives and evolves, and some day even your internal classes may be exposed to the rest of the world.