Log in

View Full Version : IDA/Android - App gets killed by system when debugging native code (timeout)


Uridium
April 24th, 2012, 17:03
Hallo,
i'm debugging an android target with IDA (native code, shared object exchanging messages with dalvik code). I can connect to the native code (ARM), let it run, step through the code and so on. The problem is if i halt the code the host app (dalvik code) waits for an answer and if it doesn't get one in time the OS kills the app (Timeout executing service, Process (pid 7896) has died, Scheduling restart of crashed service in 5000ms) so i only have maybe 10 seconds to work with IDA. If i don't continue the process in that time it will be killed.

Anyone know how to solve that?

Woodmann
April 24th, 2012, 19:48
Howdy,

I'm just getting started with playing with android apps and the like.
I am not at a point of debugging or dis-assembling apps but I have
seen that a lot of people use a debugger made by Eclipse.

Maybe it would help ?

Woodmann

Uridium
April 24th, 2012, 21:18
Eclipse is used as frontend for different debuggers only if i get it right. Mostly DDMS (Dalvik Debug Monitor Server) and GDB (GNU Debugger). The latter one is the official debugger for low-level code (arm, native) whereas DDMS is more of a debug bridge for high-level debugging (dalvik code), process watching, debug log output, dumping, halting processes and such. I played some time with it already. Possible that i missed something there though...

I tried both (low-level) debug servers with IDA (hex-rays and GDB). Both show the same behavior (get kicked by system due to timeout). They work properly though as long as they live. And even Android does it right by kicking apps that do not respond in time. But its not very suitable for debugging. I hope i don't need to compile a new (debug) kernel for this.

I will try the official GDB client as well (works in conjunction with eclipse). Maybe it freezes more processes or something like that. I don't think so but just to make sure...

It's also possible that it's just my specific target because it has uncommon runtime environment (service, multi process). It would be a heck of a lot easier to have a kernel debugger here..

The best solution would be setting something in the build.prop to stop android from kicking "frozen" apps or something like that. I also tried setting android:debuggable="true" in the application element of the AndroidManifest.xml but leads to nothing.

Currently i'm out of ideas...

JMI
April 24th, 2012, 21:47
Start with the understanding that I know "nothing" about debugging Android Apps. I did, however do a google search using: "debugging android" and got a number of hits you may want to consider.

One of them is a link to the Android Developers Homepage and it references various issues with debugging Android software.

You will find that link here: http://developer.android.com/guide/developing/debugging/index.html

It mentions:

The Android SDK provides most of the tools that you need to debug your applications. You need a JDWP-compliant debugger if you want to be able to do things such as step through code, view variable values, and pause execution of an application. If you are using Eclipse, a JDWP-compliant debugger is already included and there is no setup required. If you are using another IDE, you can use the debugger that comes with it and attach the debugger to a special port so it can communicate with the application VMs on your devices. The main components that comprise a typical Android debugging environment are:

adb ("http://www.woodmann.com/guide/developing/tools/adb.html"): adb acts as a middleman between a device and your development system. It provides various device management capabilities, including moving and syncing files to the emulator, running a UNIX shell on the device or emulator, and providing a general means to communicate with connected emulators and devices.
Dalvik Debug Monitor Server ("http://www.woodmann.com/guide/developing/debugging/ddms.html"): DDMS is a graphical program that communicates with your devices through adb. DDMS can capture screenshots, gather thread and stack information, spoof incoming calls and SMS messages, and has many other features.
Device or Android Virtual Device ("http://www.woodmann.com/guide/developing/devices/index.html"):
Your application must run in a device or in an AVD so that it can be debugged. An adb device daemon runs on the device or emulator and provides a means for the adb host daemon to communicate with the device or emulator.
JDWP debugger: The Dalvik VM (Virtual Machine) supports the JDWP protocol to allow debuggers to attach to a VM. Each application runs in a VM and exposes a unique port that you can attach a debugger to via DDMS. If you want to debug multiple applications, attaching to each port might become tedious, so DDMS provides a port forwarding feature that can forward a specific VM's debugging port to port 8700. You can switch freely from application to application by highlighting it in the Devices tab of DDMS. DDMS forwards the appropriate port to port 8700. Most modern Java IDEs include a JDWP debugger, or you can use a command line debugger such as jdb.

There's much more information on the site and it may lead to other information which would be useful. If it interests you, check it out.

Happy Reversing.

Regards,

rendari
April 25th, 2012, 02:08
Hi Uridium,

I've been doing a lot of Android native debugging lately, with the IDA Pro server. I originally had the same problem you did, but then it just went away The only thing I can think of is I am using Android 2.2 emulator. Maybe it does things differently than other devices/emulators?

All I know is, now I can pause debugging whenever I want, and Android doesn't automatically kill the process for hanging. Instead, it pops up a dialog asking the user if he wants to kill the idle process. If the user never clicks yes, the application resumes correctly when I let the debugger resume the process, or detach.

Hope this helps somehow, sorry that I can't be more specific.

-rendari

Uridium
April 25th, 2012, 13:48
@JMI: Thx, but i guess i'm over most of that already. This is more or less the standard toolchain for Android development.

@rendari:
That's interesting. I will check this out. What Android base do you actually run, 2.3.3 or 4.0? Even though i have the emulator set up and running i have preferred debugging on real hardware so far (2.3.7 cyanogen). Would be great if the solution is that simple...

rendari
April 25th, 2012, 18:03
Android 2.3.3 on my device (2.2 on emulator), just like the real world. No one runs 4.0. Also be aware that Android LVL does not run correctly on Android Emulator 2.3, so avoid it if you're doing cracking stuff

Woodmann
April 25th, 2012, 21:58
Good things to know.

Mine is upgradable to 2.3.5.
Will the emulator still work on that ?

Woodmann

rendari
April 25th, 2012, 22:38
Don't understand question Emulator runs on computer, and it's trivial to pick versions on it. If you mean you have 2.3.5 on your device, that should be fine. I can't guarantee anything.

I personally do all my reversing on the emulator. People say it bothers them due to the lag/inconsistencies, but I don't notice it or care.

-rendari

Uridium
April 26th, 2012, 16:35
I tried the emulator (2.3.3) but gives same results. Application respawns after some seconds. Not sure if 2.2 is the solution here. Will try that next. Edit: No change on 2.2.

Are you using IDA 6.1 as well?
http://www.abload.de/img/android-virtual-devicjlk58.png

FrankRizzo
April 26th, 2012, 18:30
Quote:
[Originally Posted by Uridium;92383]Hallo,
i'm debugging an android target with IDA (native code, shared object exchanging messages with dalvik code). I can connect to the native code (ARM), let it run, step through the code and so on. The problem is if i halt the code the host app (dalvik code) waits for an answer and if it doesn't get one in time the OS kills the app (Timeout executing service, Process (pid 7896) has died, Scheduling restart of crashed service in 5000ms) so i only have maybe 10 seconds to work with IDA. If i don't continue the process in that time it will be killed.

Anyone know how to solve that?


If it were ME? I'd grep the source tree for the "Timeout executing service" message, see where it comes from, and if it's a "watchdog" app keeping an eye on things, just kill it before you start debugging. If it turns out to be an integral part of Android, check the source for where that's done, and see if there is a provision for exceptions to the rule.

That's how I'd attack that.

rendari
April 26th, 2012, 21:47
Quote:
[Originally Posted by Uridium;92394]I tried the emulator (2.3.3) but gives same results. Application respawns after some seconds. Not sure if 2.2 is the solution here. Will try that next. Edit: No change on 2.2.

Are you using IDA 6.1 as well?
http://www.abload.de/img/android-virtual-devicjlk58.png
I'm using IDA 6.2, but I don't think that should change anything. sorry it didn't work for you

-rendari

Uridium
April 26th, 2012, 23:22
I guess the reason it doesn't throw an ANR ("http://developer.android.com/guide/practices/design/responsiveness.html") (Application not responding) is it has been explicitly defined in the app itself. I'll look up some APIs (onStart(), onBind()..) and AndroidManifest.xml options.

Uridium
May 27th, 2012, 15:41
I could solve the problem...

The IDA 6.1 server (android_server) has problems with the Android 2.3.7 linker (system/bin/linker) so it could only hook to the Android Virtual Machine itself (Zygote) not to the linux native code thus the native code continued to run and didn't halt. Responsible for that is 'system/bin/app_process'. I replaced the binary with an Android 2.2 (Froyo) release and it worked properly then. The only downside is there is no debugger yet that provides hardware breakpoints so you cannot break at data access. You can create memory watches and break regularly to pinpoint the responsible code though.

balint
June 4th, 2012, 11:19
Could you please give a detailed step-by-step description on how to fix this issue?
I have just started playing with Android and Eclipse, and am miles away from having the sort of understanding of the internals of the debugger you seem to have...

Thanks a lot!

Uridium
June 4th, 2012, 14:58
This is an IDA specific issue. You won't encounter it with Eclipse.