Even a private member/function of my class can be accessed by reflection by using setAccessible(true). Is there a way to prevent this kind of access from outside code?
I read something, here on stack-overflow, that I can use SecurityManager for prevention of reflection in applets(not sure how it works, though), but is there a similar mechanism for Android as well? Maybe an annotation or clever-programming?
Taking a step back, what you're observing is a difference in security philosophy, between the Java execution model as originally embodied in JVMs at Sun and the execution model of Android.
The original Java VM design was intended for a system wherein multiple, mutually-suspicious applications (or "applets" in the Java parlance) would simultaneously inhabit a single address space, running in a single VM. Because the designers didn't want one app to be able to mess with another, they went through great pains to define an intra-VM security model that would disallow things such as one object touching the private fields of another object of a different class.
That said, the Java library ended up having various "escape hatches" out of the security model. One of those is setAccessible() on reflection objects, as you note.
Android's model is different: Android uses processes as the security boundary and unit of application isolation, instead of trying to insinuate it into the process as was done with traditional JVMs. This renders moot the entirety of the Java security model, except in that it helps an application "save it from itself." That is, it's good design to not have an object poke into another object's private parts, and the default Java security model provides just that.
Leaving aside the question of people modifying your code, with Android, as an application author, you control all the code that ends up running inside the process of your app. If you choose to include code that calls setAccessible() that's your business. You might be shooting yourself in the foot, but you certainly won't be shooting any other apps' feet, since the Android security model, running as it as at the layer of processes, inherently doesn't let that happen. Likewise, using native code will totally break you out of the Java object model, which allows for the possibility of things going totally higgledy-piggledy in the process but also allows you to express some things in a more productive manner than you could in Java. It's a trade-off, but it's a per-application-developer tradeoff and not one that particularly impacts anything else that's happening on your phone / device.
I know this doesn't directly answer your question, but I hope it provided some useful context.
Is there a way to prevent this kind of access from outside code?
Not really.
is there a similar mechanism for Android as well?
Even if there is (and I am not aware that such a thing exists), anyone can remove it, by decompiling your code (assuming they do not have your source already), getting rid of the protection, and recompiling the code.
Bear in mind that ProGuard, when used properly, will obfuscate your private classes and methods for your production APK builds. That, plus a lack of documentation, will make it tedious for anyone to gain access to those private classes and methods.
I don't believe that you can ever really 100% protect from users using reflection on your project with malicious intent. You can make it more difficult for users to do it by doing things like obfuscating your code, but it is still possible to reflect on the obfuscated code.
I don't believe SecurityManager can be used for the purpose that you are suggesting, though I could be wrong.
Related
I'm new to android and I don't know much about software engineering. I wanna know about things should be done to make it harder to decompile an app. I made some research about it and I ran into this debugger JEB which seems like it can monitor some stuff while app running. Yet I don't know the advantages of using it since I don't get the critical points of an android app which is being monitored by JEB. for example:
enter image description here
appearantly the right side shows local variables. what does x / xh means for an int? or for the string value "secretKey" is the value of string seriously? if it is then all variables in my code are at risk!!!??
I think maybe one of the attempts is to make a lot of fake variables in code so that the real ones can't be seen easily. Does it make sense? And are there other leaks that I should try to prevent for example about this JEB? Does proguard have anything to do with this? As I said I donno much about soft-eng and I didn't get to understand what proguard actually does.
And another thing I've seen is https://ibotpeaches.github.io/Apktool. How to make it more mixed up for such tool to handle?
The last question, I code in java and don't think yet I have the opportunity to start native coding but for future; I've seen people say its safer to code natively. Is it by itself? or there are more libraries to keep more safety? or its because of the final apk structure?
sorry if some words look dumb. thanks in advance
You should not try to prevent reverse engineering, because doing so is largely futile. Instead, you should design your app to minimize the effect that reverse engineering would have (i.e. you should not include secret data like keys or passwords in the app).
The amount of effort that people are willing to put into reverse engineering your app depends on how important and popular it is, while obfuscation increases the effort required to reverse engineer the app. However, if your app becomes popular, no amount of obfuscation will stop people, while if it languishes in obscurity, nobody's going to bother to look at it, even if you post the source code on Github. Also, in rare cases, adding obfuscation will make people crack it just for the challenge.
Apart from that, there is the risk that obfuscation will give you a false sense of security. Anyone can devise a system that they themselves cannot break, but if you aren't an expert at reverse engineering, the measures you come up with are unlikely to stop those who are. It is best to instead assume that everything in your app is public information and design accordingly.
You can protect your code by using some powerful obfuscator tool like: Bg+Anti Decompile/Reverse Java
It has a lot of protection options:
Hide string value (helpful when you keep some sensitive info in java source, ex: "Hello world" ->ߤª )
Obfuscate with unicode characters
Hide packagename
Add fakecode to trap the decompiler tools
Check resource-string (helpful when someone try to edit the resources of your APK)
....
I have been developing a much-revamped version of an earlier android application. So many additions and changes to the infrastructure, UI, and general organization were necessary that it was far easier to start from scratch with the new application and transplant some of the guts from the old one rather than trying to understand everything the previous developer wrote and incrementally perform smaller surgeries.
I have the source code from the previous developer, and it contains several activities, fragments, classes, etc. that I know likely are not being used in the final build. To make the transplant process as easy as possible, is there an easy way to find out which of the above components are simply not being used in the app?
A couple ideas that immediately come to mind are:
stepping through everything in a debugger and taking note of which components are used (this seems like a super inefficient and terribly tedious process)
add a log message to each component's onCreate/instantiation code and then run through the entire app (more efficient, but still a pain)
Is there an easy way to do this?
Effective Java (Joshua Bloch) Item 17 says :
"Design and Document or inheritance or else prohibit it"
However, just a cursory glance through the Android APIs reveals that most of the API classes are non-final; which is OK if they are also documented for inheritance (View of Activity, for example). But there are also several non-final classes, but the documentation makes no mention about the inheritability of these classes. Just some arbitrary examples to illustrate my point:
The classes representing the System Services (WifiManager, NotificationManager ...)
Utility classes like UriMatcher.
Some hardware-specific classes like Camera.
Openness and extensibility being the philosophy of Android, is the convention reversed here? Meaning, could one assume that all of the Android API classes are designed to be inherited (whether explicitly documented or otherwise); unless declared final?
Just my €0,02: Clean OO design by the book is one thing, making things work for all possible use cases in practice is another. The principles of clean OO design sometimes are somewhat of academic nature. - And maybe a little bit of black and white.
Think for instance about who uses the Android API provided by google: It's not only app developers but also device manufacturers who need to specialize general APIs for their devices.
So, for me, SW design is neither black nor white in most cases; the shades of grey are important.
And finally: In practice I have seldom (read: never) seen problems caused by "carelessly" omitted final keywords (on classes), while unreflected overuse of final (often caused by thoughts like "my code is sooo [great | ugly], no one will actually ever want to modify it through inheritance") can be quite a pain.
"I know that I know nothing" seems to fit here: It is presumptuous to claim that one knows all the crazy, ingenious, creative, smart,... ideas of others for how one's code may be used in the future beforehand.
The Android developers went to great lengths to ensure that extensibility, while not recommended in many cases, is possible. The motivation behind this appears to be related to testing environments.
For instance, it would be much more difficult to create a faux WifiManager for the purposes of creating unit tests if it were finalized. Without the finalization, it is trivial to subclass the WifiManager (e.g. to mimic "unexpected" wifi disconnection during operation) and return an instance of this subclass from a customized testing Context.
So while you will probably never find a reason to implement a subclass of the these classes in an application that you ship to the end users, the flexibility is there to allow you to extend them if it is necessary for one reason or another.
In the case of utility classes, the answer is simply that the utility of the class is not diminished by allowing the developer to subclass; in many cases, a developer can achieve more understandable code reuse by inheritance than by aggregation and delegation.
A coworker and I were talking (after a fashion) about an article I read (HTC permission security risk). Basically, the argument came down to whether or not it was possible to log every action that an application was doing. Then someone (an abstract theroetical person) would go through and see if the app was doing what it was supposed to do and not trying to be all malicious like.
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing. Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
Can I get some input one way or the other? Is it completely impractical to even attempt to log what a foriegn application is doing?
I have been programming in Android for a year now, and as far as I know if -- if -- that was possible, you would have to hack Dalvik and output what each process was doing.
Not so much "hack Dalvik" but "hack the android.* class library, and perhaps a few other things (e.g., java.net).
Even if you were to do that, I think it would be completely indecipherable because of the sheer amount of stuff each process was doing.
You might be able to do some fancy pattern matching or something on the output -- given that you have determined patterns of inappropriate actions. Of course, there is also the small matter of having to manually test the app (to generate the output).
Is it completely impractical to even attempt to log what a foriegn application is doing?
From an SDK app? I damn well hope so.
From a device running a modded firmware with the aforementioned changes? I'd say it is impractical unless you have a fairly decent-sized development team, at which point it is merely expensive.
This is both possible and practical if you are compiling your own ROM. Android is based on Linux and I know several projects like this for Linux, like Linux Trace Toolkit. I also know of research into visualizing the results and detecting malicious apps from the results as well.
Another thing functionality like this is often used for is performance and reliability monitoring. You can read about the DTRACE functionality in Solaris to learn more about how this sort of stuff is used in business rather than academia.
I want to implement MVC in my Android application for reasons I have heard but not realized. Can anyone lead me to implement MVC in my application? Kindly mention the benefits for using the same.
Thanks
The key benefit of MVC (and its variations) in general and not only for Android is separation of concerns. This means you keep business logic isolated in the Model instead of mingled with the presentation logic. In turn the Model becomes easier to unit test, modify, and reuse (when reuse is a concern at least).
I'm not sure if there is much sense in testing the View or Controller parts of MVC. The View for one thing is supposed to be as much 'dumb' as possible, to the point of lacking even presentation logic.
MVC apparently has trouble telling where the presentation logic belongs to -- this seems to be the reason why MVP has been created, so all this logic goes to the Presenter. So by using MVP instead of MVC you would also have the benefit of easily testable presentation logic.
MVC also allows (in theory at least) to change the user interface adopted by the application, though I'm not sure how this applies to Android (maybe for games?).
Needless to say, Android apps DO NOT implement MVC by design. Otherwise those benefits would be available to Android apps by design, which is not true.
It's already implemented as per this post here: MVC pattern on Android
For one thing, it allows you to plug in a different algorithms or data store/source into your app with a single line of code. So in my sample Android app, I can switch from DES, to AES to TDES encryption in one line of code. It allows you to port your algorithm to another app with a completely different user interface and architecture. So in .NET I can write a Windows Form app and then port it to a Web Form app without re writing the core algorithm code. If you are looking for an example in Android I have a complete example here. If you can read C# code I have an example here.
Have fun.
JAL
Java has very powerful features behind it. The word MVC means at the bottom line, basically, componentization. Components are a very important definition in a OOP language like Java, and even more important to languages that implement memory allocation and handling like Java with the GC (Garbage Collector).
There's lots of GC algorithms & types implemented out there, each JVM has it's own number of sets, Oracle has it's own, IBM, Apache's OpenJDK, and so on and on. But the concept is almost every time the same: reference counting. Let's picture an example where you have an object A, that define a property of type B, and this class B has also a property to another class called C, and they are all in the same processing scope (e.g. a method). Analysing this example, the runtime (JVM) could only release "B" after "C" is out of scope (out scoped), and also "A" could not be liberated because of "B" being used by the same scope. Putting this in perspective, the scope modifiers, methods, classes, static methods and classes, final declarations, everything needs to be carefuly chosen.
Summing all together, that means not only you get a more well organised code using patterns like MVC, but also more performance in the JVM runtime, because depending on the size of your program, your GC pool can really be a bottom-neck, and fine grained java code, with methods with a just few lines divided by a few number of classes, will always perform better. Huge classes, with just a few methods with a lot of lines of code within, tend to perform poorly.
... and that's the beauty of things. MVC not only gives a more well organised code, but also, more performance. Hope it helps!