Debugging and the debug APK

As a textbook or reference book reader, debugging is "the process of identifying and fixing of problem that stopped the product to work as intended."

"debugging" - as how I see

As a practicing tester, I see, "debugging is a empirical activity which involves investigation, reasoning and analysis on the buggy/risky/enhancement incident to learn the details about it, so that a fix solution will be found for it." 

There are different techniques in debugging and the person doing the debugging may carry out multiple activities in parallel.  Discussing the different techniques, approaches and activities in debugging is not with scope of this writing. Hence I'm not sharing much about it, in this post.

I learn, "having the debugging attribute in the product is testability strengthening factor."

"no!" to debug APK while USB Debugging is enabled?

In my testing practice, I test for mobile apps as well. I test Android, iOS and WP apps.  In the context of this blog post writing, I will stick on to Android app and Android APK.

It is very common for a programmer to have "USB Debugging" option enabled on her/his Android device by turning on 'Developer' permission. So the programmer will be able to install the Android app while it is being developed. Further the programmer will use this installed app for testing and debugging, typically.

When tester enable 'Developer' permission and choose "USB Debugging" option to assist in debugging the problems in app, won't that help in developing app? Won't it reduce the time and efforts of the programmer in analyzing the problem when the tester write the detailed Test Investigation report from the debugging? To a tester, who aspire to be skilled mobile app tester, it is very usual to have this setup on her/his test or personal device as the programmer will have.

If so, then have you ever said "no!" to share the debug app to your tester who has same interest in the product as the programmer and product owner?  Why? I will leave it to you for introspection.

"few" myths around sharing the debug APK

There are myths which gives fear in mind when asked for the debug APK. I have tired to demystify few of them here and help to be confident in sharing the debug APK with your tester on mutual understanding and agreement in common interest.

"types" of debugging in developing Android APK

I understand, the IDE used to program the Android APK will use the Java debug by default. That means, the code compiled in debug mode will generate the APK which works with tools based out of Java to see the internals of app.

Along with this, if the IDE supports different configurations of debugging, it can be used. I have not used apart from 'Java' type so far. Hence I cannot share anything further on this.

By the way, when I say "developing", I mean programming along with testing.


"differences" between the debug APK and non-debug APK

When said non-debug APK, the assumption is that it will be a release APK. The debug APK is for the testing purpose. In practice, the release APK will have debug attribute to false. Beside this, the certificates used to sign the APK will be different when it is debug APK and the release APK. These certificates will be bound to date for expiry.

Both debug and non-debug APKs can be ZIP aligned and signed.  Making sure the log writing code is available in the app is essential to print system messages, debug messages and stack trace.

next Post

In the next blog post, I will share the benefits what the programmer and interested stakeholder can get by sharing the debug APK with the tester.

Few myths around sharing the debug APK

The debug APK is a useful build which helps to learn the internal aspects of the app. If security is a concern with the debug APK, then it has to be handled in building the security layers for the app and it's code. Saying the debug APK is the gateway to security problems is not thoughtful, technically and logically.

Here are few myths and fear that is observed when asked for the Android debug APK.

Myth-1: Given the release build/app it cannot be turned to debug build/app

One can use the release build/app and turn it to the debug build though the programmer do not share one. However, there is no assurance that this converted debug build will be functional as the release build/app. If tester converts it to debug build and reports the behavior which are not valid then it is additional effort to programmer and project to triage and then say it is not valid. This happens!

Myth-2: One will have access to the code of debug app

One will have access to code when one installs the app on her/his device. The question is in what format and how the access will be available. Apps having the obfuscation with help of ProGaurd and DexGaurd will obfuscate the compiled code of app. To deobfuscate it, one will require the mapping file key. Further one can go and ahead and work to deobfuscate with different approaches and techniques with no mapping file available as well.  It is upto what level the security is strengthened for app.  Anyways the code is available (in a format) when one installs the release APK/app. 

Myth-3: One can tamper the debug app and use it illegally

From above said myth's opinion, I will continue for this topic.  While building the release APK, the programmer will sign the APK with certificate. The release build certificate and debug build certificate are not same. The person who wants to use tamper the app, still she/he can decompile, edit the app, deobfuscate, recompile, sign the app and build it. When signing on recompile, if the person do not have valid certificate still she/he can go ahead with self created test certificate.  But, the question is will this certificate work well for the app which has multiple legacy SDKs included and expecting a certificate and key. In my test practice, I have seen, the app failing to function for its purpose though it launches in such context.

Myth-4: One can misuse and learn the sensitive area and information from debug app

With out the actual source code, one can reach to stage where she/he can see the register and stack values by using just the debug app's compiled code. For getting into this level, one has to successfully decompile and build it back to SMALI data structure and then start the debugging to look into the stack registers and flow sequence. If the obfuscation is applied at this level, then it a round more of strengthening. Yet it does not mean one cannot cross it but the time needed is unknown.  This is possible with non-debug app i.e. release APK as well.

Myth-5: One can know what happens in the debug app while using it

The very purpose of the debug app is this i.e. to know whats happening when using the app. The question is -- who is using the debug app? Without the actual source code of the app, the information learning will become narrow as the testing progresses with debug app.  

Myth-6: Giving the debug is like giving the permission to code of app

Debug APK means not permission to code of app for editing and building.  If there are other checks on the decompile, recompile and signing to stop app from functioning after this, the APK will not be usable as the release APK.

Myth-7: One can gain the control over the app with debug app

Unless the decompiled app is edited in code and built again to do illegal and incorrect activities, it is unfair to think as this. If this is the possibility with the Android app which is being built, then it has to be handled in how the structuring happens for security layers of the APK. This is nothing to do with debug APK.

If the debug app is pointing to the staging or test environment and access is restricted with IP white listing and similar other approaches, it will restrict the access from public use. The other way is to reduce the validity time for debug signing certificate. Keeping this validity that is reasonable for the test cycle is another approach. After this validity the debug APK will not get installed on devices unless it is decompiled and resigned again.