Develop Reference

Is DexGuard tamper and Environment detection helpful?

I am very new to DexGuard and Proguard. I was going through their documentation and sample examples. They have dexguard_util which helps you detect if the application is tampered with and also helps in detecting if it is running in the environment it is supposed to run. The document suggests that this tamper and environment detection be encrypted using the following code is dexgaurd-project.txt.
-encryptclasses A$D
-encryptstrings A$D
follwing is the activity
public class A extends Activity
{
#Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
new D().c();
}
private class D
{
public void c()
{
//some code to which detects the tampering and environment and takes action accordingly
}
}
}
What if a hacker inject this line of code.
public class A extends Activity
{
#Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
//code commented by hacker
//new D().c();
}
private class D
{
public void c()
{
//some code to which detects the tampering and environment and takes action accordingly
}
}
}
Then my application will run without running those tests which I think is a big problem. Is my understanding of how reverse engineering works wrong or there are better ways of doing this. Please share better methods of doing this if they exist. Thanks in advance. Note that public class A cannot be encrypted as it is an entry point and is kept using this command in progaurd-project.txt
-keep class somepackage.A

When it comes to anti-tampering, it is important to keep in mind that their goal is not to stop any and all potential tampering efforts, but, rather, it's just a matter of raising the security bar of the target high enough to dissuade most attackers.
With that said, the
A bit of a tangent:
The document suggests that this tamper and environment detection be encrypted using the following code is dexgaurd-project.txt.
Class encryption does prevent basic static analysis of the application package, e.g. simply unzipping the package and loading it in jd-gui. However, as this answer shows, it's trivial to circumvent: one only has to hook into the static method that decrypts the apk on load, and dump it. But this allows the security bar to be raised.
Now back to your original question:
What if a hacker inject this line of code.
As an attacker, that would be the next step. However, that would require repackaging the app, and signing it with the hacker's signing key. Therefore, it is necessary to combine Dexguard's anti-tampering measures like checking the apk signature.
Is DexGuard tamper and Environment detection helpful?
In summary, yes, it is helpful in as far as it raises the bar above the vast majority of apps out there. But it's no silver bullet.

How can I detect in an app that Proguard successfully removed all log calls?

Thanks to Proguard's optimization features I am now able to do as much debug-logging as I which in my code - for production I simply let it strip all this unnecessary code.
That is fine and works (with the latest Proguard version).
But: before I went this way, I had my final static boolean DEBUG constant that "guarded" all my Log.d/Log.v calls. To ensure I did not forget to disable that for signed production apk's, I just had an easily visible add on in my UI main activity that in some corner put an ugly text "DEBUG IS ON".
So, when producing my final apk, all I had to do is install it once - in case I forgot to switch debug mode off, I was reminded by that.
Now, with Proguard doing the work of removing debug-log-calls: how could I DETECT that in my app and control a UI element that states "DEBUG IS ON"?
Any idea?
My first attempt was to try this:
boolean loggingEnabled = false;
Log.d(TAG, (loggingEnabled = true) ? "Logging test" : "");
And I hoped that Proguard would also remove the assignment loggingEnabled=true- but I underestimated Proguard. It removes the call to Log.d, but still does the assignment... :)

You can do a few things:
Check the mapping.txt in proguard's output folder: grep -E '(android/util/|de/ub0r/android/logg0r/)Log.[dv]' */build/proguard/release/dump.txt
Run the app and check if any d/v log is printed.
Decompilte the app and look at the source code for calls to Log.d() and Log.v().
I build a simple wrapper library to make it a little bit more handy:
https://github.com/felixb/ub0rlogg0r
--- EDIT ---
To Check if your logs got stripped, do the following:
Fork ub0rlogg0r.
Add a public static boolean sHasDebugCalls = false; to Log.
Add sHasDebugCalls = true to all the Log.d() and Log.v() methods.
Place a Log.d(TAG, "has debug logs") somewhere in the very beginning of your app.
When creating your UI, test for Log.sHasDebugCalls to decide visibility of the DEBUG reminder.

How to make my android app clean?

In my Java code, I use the Debug flag to control debug model, if is debug ,there are some extra functions,such as:sway the phone show a activity to change app version. Now I want to erase these code when publishing the code to market.
Like the code below, is there a way to make VersionSwitchService.class code is null and other code is running normal?
I mean that even if, someone decompiles the apk, VersionSwitchService.class code is seen as blank.
if (isDEBUG) {
VersionSwitchService.libStart(this, new LibVersionSwitch() {
#Override
public void versionSwitchToOnline() {
//...
}
#Override
public void versionSwitch(String version) {
//...
}
});
}

If you make isDebug final static:
final static boolean isDebug = false;
the Java compiler will complete remove the parts of code that are unreached. Sp in your example, the 'then'-part is completely omitted and thus not available in your apk.
Furthermore, when creating a (release) apk build, the Android tools will strip all methods and classes that are unused. So, if your VersionSwitchService class is only used for debugging, it will not present (due to the combination of the static final debug constant)

Using Log.d() or Log.e() in my code

I have used Log.d() and Log.e() through out my android application for debugging purpose.
I would like to know if I release my application like this, will the user sees all those debug statement that I put in? Do I need to do something special so that user won't see the debug log even if they hook up 'adb logcat'?
Thank you.

Leaving logging statements can, in some cases, be very bad:
http://web.archive.org/web/20121222023201/http://vbsteven.com/archives/535
You can use ProGuard to automatically remove them all:
-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** e(...);
}

Consider using this : isLoggable()
Checks to see whether or not a log for the specified tag is loggable at the specified level. The default level of any tag is set to INFO. This means that any level above and including INFO will be logged. Before you make any calls to a logging method you should check to see if your tag should be logged. You can change the default level by setting a system property: setprop log.tag.<YOUR_LOG_TAG> <LEVEL> Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or SUPPRESS. SUPPRESS will turn off all logging for your tag. You can also create a local.prop file that with the following in it: log.tag.<YOUR_LOG_TAG>=<LEVEL> and place that in /data/local.prop
Personally for releases, I'd remove the debug logs and keep the error logs using Proguard.
It is better to wrap it like so:
public class MyLog {
public static void d(String tag, String msg) {
if (Log.isLoggable(tag, Log.DEBUG)) {
Log.d(tag, msg);
}
}
public static void i(String tag, String msg) {
if (Log.isLoggable(tag, Log.INFO)) {
Log.i(tag, msg);
}
} // and so on...
You can set logging level by issuing an adb command

Not only can the user (or any app with log access) see your logs, but your logs also cause your app to run slower and use more battery power.
Writing a log, especially from Java, is probably much more expensive than you think: just building the string in Java is a lot of work.

There are apps in the Market that allow users to see logs even without hooking up a development environment.
CatLog is one I have personally used and it will show you everything.
What I've done in my app is create a wrapper class that I can turn off myself with a boolean flag. It has the added benefit of having the TAG parameter being common throughput my code.
public class QLog {
private static final String TAG = "MyAppTag";
private static final boolean DEBUG_MODE = true;
public static void d(String msg) {
if(DEBUG_MODE) {
Log.d(TAG, msg);
}
}
...
}

As it is said in android.developer.com
when you're building the string to pass into Log.d, the compiler uses a StringBuilder and at least three allocations occur: the StringBuilder itself, the buffer, and the String object. Realistically, there is also another buffer allocation and copy, and even more pressure on the gc. That means that if your log message is filtered out, you might be doing significant work and incurring significant overhead.
here is the link:
http://developer.android.com/reference/android/util/Log.html

They can be used when developing. When release, it is better to remove or obfuscate the message to protect PII(Personally identifiable information). The answer here is very useful: Android Log.v(), Log.d(), Log.i(), Log.w(), Log.e() - When to use each one?
Here is the one teach you the tool to deal with these logs when release the software.Remove all debug logging calls before publishing: are there tools to do this?

If your user is a developer, and connects the device to a developing machine and have LogCat opened he will se all logs on Logcat if he interracts with that application. When you are going to publish the application to the final user you should remove those logs.

Logging guidelines
Log.v(String tag, String msg) (verbose)
Log.d(String tag, String msg) (debug)
Log.i(String tag, String msg) (information)
Log.w(String tag, String msg) (warning)
Log.e(String tag, String msg) (error)
To only show logs on debug builds:
if (BuildConfig.DEBUG) Log.d(TAG, "The value of x is " + x);

Log.d and impact on performance

I'm not entirely sure about what I'm reading in the documentation. Is it ok to leave a bunch of log.d pieces of code scattered about, or should I comment them out so that they don't impact my app's performance.
Thanks,
I'm a little confused because if you read about the log object (documentation) you see this:
"The order in terms of verbosity, from least to most is ERROR, WARN,
INFO, DEBUG, VERBOSE. Verbose should never be compiled into an
application except during development. Debug logs are compiled in but
stripped at runtime. Error, warning and info logs are always kept. "
It almost sounded like it's ok to leave debug messages in there because they are "stripped." Anyway, thanks for the answers, I'll comment them out when I'm done. Not like I need them in there once the app is completed.
Thanks

Log has impact on performance, so it's recommended that you comment it out or log with conditional statements.
For example
public class MyActivity extends Activity {
// Debugging
private static final String TAG = "MyApp";
private static final boolean D = true;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(D) Log.e(TAG, "MyActivity.onCreate debug message");
}
Then in when you publish your release version just change "D" to false

My solution:
Add unguarded log statements wherever you like
Strip them out for release builds

Definitely comment them out. They add up quickly and could noticeably slow down your app, especially if you have them in loops.

Simply use code guard methods.
if (Log.isLoggable(LOG_TAG, Log.DEBUG)) {
Log.d(LOG_TAG, "Your log here");
}

Yes print, println, Log.d, Log.e and all similar methods affect performance.
The solution
create a class named C
class C{
public static String TAG="My_debug_tag";
public static boolean isInTesting=true;
public static void log(String tag, String msg){
if(!isInTesting) return;
Log.d(tag==null?TAG:tag, msg);
}
}
and use these methods for all your logs, and when you are ready to generate final .apk/.aab just set isInTesting=false to disable all logs from this method.