Will DexGuard help me to obfuscate my broadcastReceiver ? I have important algorithm in one of my broadcast Receivers and i need a way to obfuscate it, but DexGuard needs purchase a license ? Proguards free, any suggestions ? and i can't find a link to download redex by facebook so i assume its still in development. So my question is which one of them will obfuscate my broadcastReceiver.
my proguard file has content like this:
-keep public class * extends android.app.Activity
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
**-keep public class * extends android.content.BroadcastReceiver**
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService
notice it says to keep broadcastReceiver, how can i hide my data ? I'd have to try and move all my logic to another class but broadcastreceiver gets garbage collected aggressively. So not a option.
You are right the default ProGuard and DexGuard config excludes classes that extend BroadcastReceiver so just move to another class. It would be better OO design to have your logic in separate class - makes it more testable for one. Certainly DexGuard will offer stronger protection than ProGuard given it has specific protection functionality Class encryption and API hiding sound as if they would be useful. Note there are other commercial obfuscators for Android.
For increased security one option would be to store/run the algorithm in native code given it's more difficult to reverse engineer.
But actually as you say important algorithm I wonder if it should be in the app at all. Storing and running the algorithm in a controlled server environment and having a secure API would be better IMO - of course there's no 100% security as your server could get hacked but this would likely be better than having a copy of the algorithm in every .apk downloaded.
Related
I am learning Spring Webflux. In some code samples they add a org.springframework.data.r2dbc.repository.config.EnableR2dbcRepositories annotation to the main class [example]
#SpringBootApplication
#EnableR2dbcRepositories
public class SpringReactiveApplication {
public static void main(String[] args) {
SpringApplication.run(SpringReactiveApplication.class, args);
}
}
and in others they don't [example]. I have tried it both ways with no difference in the result. So I am trying to understand when do we need this annotation and when we don't?
There is another annotation that I have seen some examples use and other's don't. That is org.springframework.stereotype.Repository. In some examples [e.g.] I see:
#Repository
public interface CustomerRepository extends
ReactiveCrudRepository<Customer, Long> {
others don't use it. so asking same question for this annotation as well.
#SpringBootApplicaton is the combination of #EnableAutoConfiguration, #ComponentScan and #Configuration annotations.
#EnableAutoConfiguration enables Spring Boot's auto-configuration mechanism.
By annotating classes/interfaces with #Repository annotation we make
clasess/interfaces available for auto-detection during auto-configuration.
Therefore, by default Spring Boot tries to guess the location of #Repository definitions as long as the interfaces are located in the same package or sub-package.
But if the repositories are outside of SpringReactiveApplication located package we need register repository beans to the context using #EnableR2dbcRepositories. We will also get more control by using the #EnableR2dbcRepositories.
For the interfaces that extend ReactiveCrudRepository it's not necessary to put #Repository annotation on them. Because Spring Boot recognizes the repositories by the fact that they extend one of the predefined Repository interfaces.
The option -keep allows to exclude from obfuscation, but it still obfuscate the methods parameter names, which can be bad for framework like Spring web.
-keep class com.example.web.** { *; }
Is there a way to preserve the arguments names for certain packages only?
Not possible:
https://sourceforge.net/p/proguard/discussion/182455/thread/59cb6762/
~~~~~~~~~~~~~~~~
From what I've tried the -keepparameternames seems to affect only the -keep-ed methods.
So the answer to your question: it's possible to limit the list of packages that fall under its action marking with -keep (or its derivatives) only certain packages.
I use Kotlin and I have many internal classes.
I want to obfuscate and shrink everything apart from all public classes.
Proguard rules:
-dontusemixedcaseclassnames
-dontskipnonpubliclibraryclasses
-verbose
-optimizationpasses 5
-overloadaggressively
-repackageclasses ''
-allowaccessmodification
-keep public class * {
public <methods>;
public <fields>;
}
Unfortunately the -keep public class * behaves defensively and keeps all names, also for the internal classes.
Your rules are way too broad.
Single "-keep" with nested rules is more broad, compared to combination of "-keepmembers" and "-keepclasseswithmembers" rules
Full "-keep" rule means "do not change bytecode of that method, ever"
Classes, referenced by kept classes and methods, can not be removed, renamed or repackaged
This line in your rules keeps all your classes and interfaces:
-keep public class * {
I mean ALL of them. Whether they have public members or not.
Use -keepclasseswithmembers instead!
Because of these lines
{
public <methods>;
public <fields>;
}
all your public methods will be left untouched, which means that repackaging and renaming methods, referenced from your public methods can not be carried out!
If you want at least some repackaging to be done, make sure to allow optimization (because repackaging is performed as part of optimization step):
-keepmembers,allowoptimization public class * {
public <methods>;
public <fields>;
}
In addition to repackaging, this will also allow for some inlining (which in turn assists in removing classes, that supply inlined methods).
Also with Android apps you are much better off repackaging into your primary package (the application package, or package with biggest number of your immovable classes in it) instead of empty package (''). This is because some "exported" classes (Activities, Views, Services, other stuff, referenced from xml files) can not be moved outside of their package by Proguard, — aapt dynamically generates special rules to prevent that. The part of optimization process, that changes access modes from public to protected/private, becomes more efficient the more classes can be placed together in single package.
I want to obfuscate and shrink everything apart from all public classes.
Bad idea. You really should try to obfuscate as much as possible, especially public classes. If you restrict obfuscation, repackaging is also restricted! It would rename them!!
Aim for the most specific rules possible.
If you want to prevent shrinking:
-keep,allowoptimization,allowobfuscation public class com.example.Example
If you want to prevent renaming, but allow stripping unused classes:
-keep,allowoptimization,allowshrinking public class com.example.*
In general, avoid wildcard rules (bare *) and -keep rules: prefer rules for specific classes and -keepmembers/-keepclasseswithmembers
The correct approaches for obfuscating applications and libraries are completely different, but they have something in common — you should not care about public methods/classes; just obfuscate/shrink/repackage as much as possible until any more would break it.
For applications you should just obfuscate/repackage as much as possible. If you don't know, which packages are safe to obfuscate, start from opting known safe packages into obfuscation.
For libraries — do not apply Proguard to library itself (unless you are trying to achieve security by obscurity). Use the feature of aar format — consumer proguard files — that allows to supply rule "segments", which should be followed during final app obfuscation.
I'm using progurad to get rid of some logging:
-assumenosideeffects class android.util.Log {
public static int d(...);
public static int v(...);
}
I don't want anything else to happen to any classes. In particular I don't want any obfuscation, since this is a library. The clients of the library will apply obfuscation themselfs.
Is there a way to tell proguard to do "nothing" except the -assumenosideeffects rule please?
This option is applied in the optimization step, so you could disable shrinking and obfuscation. You still need to provide -keep options, e.g. ProGuard manual > Examples > A typical library.
In the Head First Design Patterns book, the author often says that one should program to interface rather than implementation?
What does that mean?
Let's illustrate it with the following code:
namespace ExperimentConsoleApp
{
class Program
{
static void Main()
{
ILogger loggerA = new DatabaseLogger();
ILogger loggerB = new FileLogger();
loggerA.Log("My message");
loggerB.Log("My message");
}
}
public interface ILogger
{
void Log(string message);
}
public class DatabaseLogger : ILogger
{
public void Log(string message)
{
// Log to database
}
}
public class FileLogger : ILogger
{
public void Log(string message)
{
// Log to File
}
}
}
Suppose you are the Logger developer and the application developer needs a Logger from you. You give the Application developer your ILogger interface and you say to him he can use but he doesn't have to worry about the implementation details.
After that you start developing a FileLogger and Databaselogger and you make sure they follow the interface that you gave to the Application developer.
The Application developer is now developing against an interface, not an implementation. He doesn't know or care how the class is implemented. He only knows the interface. This promotes less coupling in code and it gives you the ability to (trough configuration files for example) easily switch to another implementation.
Worry more about what a class does rather than how it does it. The latter should be an implementation detail, encapsulated away from clients of your class.
If you start with an interface, you're free to inject in a new implementation later without affecting clients. They only use references of the interface type.
It means that when working with a class, you should only program against the public interface and not make assumptions about how it was implemented, as it may change.
Normally this translates to using interfaces/abstract classes as variable types instead of concrete ones, allowing one to swap implementations if needed.
In the .NET world one example is the use of the IEnumerable/IEnumerator interfaces - these allow you to iterate over a collection without worrying how the collection was implemented.
It is all about coupling. Low coupling is a very important property* of software architecture. The less you need to know about your dependency the better.
Coupling can be measured by the number of assumptions you have to make in order to interact/use your dependency (paraphrasing M Fowler here).
So when using more generic types we are more loosely coupled. We are for example de-coupled from a particular implementation strategy of a collection: linked list, double linked list, arrays, trees, etc. Or from the classic OO school: "what exact shape it is: rectangle, circle, triangle", when we just want to dependent on a shape (in old school OO we apply polymorphism here)