使用 ltrace 分析 Android 应用程序
我需要分析 Android 应用程序的动态库调用，并决定为此目的使用“ltrace”工具进行分析。我将“ltrace”工具合并到android包中，然后一起编译成功。它与 shell 程序一起工作得很好，就像通常的 Linux 控制台应用程序一样。
但是，我无法正确分析从“Zygote”进程分叉的 Android 应用程序。我尝试将 ltrace 附加到“Zygote”进程以跟踪它的子进程，但我只收到 SIGCHLD 和 SIGSTOP 信号并异常终止，显示以下错误。
意外指令 0xffffffff at 0xffff0508
我只是想知道是否有人在 Android 系统上尝试过这种分析。任何简短的评论都对我很有帮助。
先感谢您。
I need to profile dynamic library calls of android application and have decided to profile using "ltrace" tool for this purpose. I combined "ltrace" tool into android package, then compiled together successfully. It works fine with shell program just like usual linux console application.
However, I cannot properly profile android applications, which are forked from "Zygote" process. I tried attaching ltrace to "Zygote" process to follow child processes of it, but I only got SIGCHLD and SIGSTOP signals and terminated abnormally, showing the following errors.
unexpected instruction 0xffffffff at 0xffff0508
I'm just wondering if anyone has ever tried this kind of profiling on android system. Any short comments can be very helpful for me.
Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在从 zygote 分叉后，尝试将 ltrace 附加到 Android 应用程序的进程中。您将需要一个为 android 的仿生 libc 构建的 ltrace，并且需要一个能够合理处理线程的 ltrace。
有一种方法可以设置可调试的 Android 应用程序等待 java 调试器的连接，您可以使用它，连接 ltrace，然后连接和断开 java 调试器以再次启动它。这应该捕获您自己的大部分逻辑，但不是整个启动过程。
IIRC 您在连接并再次启动的时间限制内，否则它可能会自行恢复以避免触发应用程序不响应的情况。
您可能会通过使用 java 调试器来了解发生了什么，然后阅读源代码以了解其在本机端是如何实现的，从而了解更多信息。
Try attaching ltrace to your android application's process after it is it forked off zygote. You will need an ltrace built for android's bionic libc, and one that has reasonable handling of threads.
There is a way to set a debuggable android app to wait for connection of the java debugger, you could use that, connect ltrace, and then connect and disconnect the java debugger to start it going again. This should capture most of your own logic, though not the entirety of the startup.
IIRC you are under a time limit to connect and get it going again, otherwise it may resume on its own to avoid triggering an application not responding situation.
It may be that you will learn more by using the java debugger to see what is going on, and then reading the source to see how that is implemented on the native side.
克里斯·斯特拉顿先生的方法一定会奏效。
LoadLibrary()是调试 jni 时需要打破的另一个点。Mr. Chris Stratton's way will work.
LoadLibrary()is another point to break for debbuging jni.