jtrace - augmented, Linux/Android aware strace with plugin architecture

The jtrace tool is another one of my tools that started in order to address a shortcoming - in this case, the lack of strace(1) for ARM64. This was (somewhat) rectified with Google's finally providing one in their emulator image (which they finally produced as part of M), but the implementation is still buggy and falls short of the true power of system call tracing. So I decided to write my own. As in other cases, the tool evolved and actually became useful by its own right, so I'm releasing it. (I also feel bad about forgetting to give my Androidevotee followers a present like the one I gave the Applytes)

This tool is provided as one of the free downloads provided for the "Android Internals" book (http://NewAndroidBook.com/). You are welcome to use it even if you don't buy the book (though naturally you're even more welcome to buy the book :-). I used it extensively in my research, and provide plenty of use cases as experiments and examples in Volume II (especially for dealing with Binder).

The tool's latest version, as a tar file with binaries - presently ARM64 and x86_64 , can always be obtained at this page right here. An older version did support ARM32, but it doesn't make sense to support it anymore

jtrace offers several significant advantages over strace(1):

For updates, you might want to check out the RSS feed, or follow my company's feed, @Technologeeks, which (aside from the occasional OS X/iOS related stuff) tweets about updates to this and other tools.

Examples

jtrace is designed to be as compatible with strace(1) as possible.

If you're not too familiar with strace(1), you ought to be - no native level developer, on any Linux or Android - can afford to remain unaware of this amazingly powerful piece of work. I myself owe a fair deal of my knowledge to countless hours spent using this tool to trace all sorts of binaries to figure out how things really work, without reading any source code (which often didn't exist openly).

As is usual, running it with no arguments will produce a usage message.

Usage: /data/local/tmp/jtrace64 [arguments] -p ....
             or
       /data/local/tmp/jtrace64 [arguments] /path/to/executable

strace(1) compatible options:
   -f       :  follow forks (or attach to all threads)
   -i:         print instruction pointer at time of syscall
   -o _file_:  output to _file
   -p _pid_/name:   specify PID to trace. May also be a thread, or a process name
   -q:  suppress syscalls without handlers (but warn)    -qq: suppress and don't warn
   -t:   absolute timestamp      -tt: with usecs
   -T:          print time spent in each syscall
   -v: verbose mode   -y: print paths associated with file descriptor arguments
    --maxlen _len_: Truncate buffers/strings printed at _len


jtrace specific (that is, not found in strace)
   --color:    (because life is better with color!)
               Can also export/setenv JCOLOR=1 to make default
   --thread _name_: Attach to a process or thread with specific _name_
   --plugin:   Load a plugin (from $JTRACE_EXT_PATH). If not specified, all plugins load.
   --tests:    Run internal test suite. J uses this. If this should fail for you, let him know

Interactive keys: (Use when traced process is running)
-----------------
 M - insert Mark in output
 F/T - Freeze/Thaw process (not yet!)

This is jtrace (64-bit) compiled on Sep  9 2018
jtrace shares no code with strace, or any other open source.
Latest version always available for free at http://NewAndroidBook.com/tools/jtrace.html
Please visit http://NewAndroidBook.com/tools/counter?jtrace so I know you're using it :-)

Tracing property operations

All property set operations have to go through init - so to get those, just attach to it!

As you can see above, jtrace will show you the full operation involved - from getting the socket request, through checking SELinux, and the setting of the properties. But grep(1) is your friend if you just want to get the properties being set.

(you won't be able to trace property get operations - not due to a jtrace limitation, but because these are performed in-memory and do not involve syscalls)

Tracing input

Using --thread you can attach to system_server's InputReader thread (without needing to dig up its PID), and jtrace will be smart enough to figure when input events are involved, and decode them for you!

Tracing BINDER!

Binder, only the most critical and least comprehensible IPC/RPC mechanism in Android, is slowly yielding before jtrace! New version A) doesn't crash on it and B) already supports quite a few interfaces! You can isolate Binder messages by grep Method:

Note the use of -f to auto-attach to threads - since Binder spawns a thread pool (might crash in rare cases, I got that bug). I'm also working on deep message tracing (i.e. with arguments, like it does for servicemanager). If AIDL finally does cpp, this will make my life easier. Expect more soon.

12/14/2016

Note: Yes, you can probably do this and more with Frida. (I say this because @FridRE enthusiasts were quick to shout out their tool is better, and perfect, and perfect with some crazy javascript one-liners). But IMHO there should be more than one way of doing it, and certainly one which does not use code injection.

Example Plugin Usage

JTrace now auto-loads plugins. Drop your plugin into the JTrace directory (specified by JTRACE_DIR JTRACE_EXT_PATH or in /data/local/tmp by default). With Android's ever-changing interfaces, this really makes sense. Take, for example, init's setprop feature. This has changed in Oreo to the setprop v2 format. Although jtrace innately supports v1, without a plugin v2 would look like this:

But with the plugin, it looks soooo much better:

Another example, for lmkd:



Get the source of the sample plugin for init
Get the source of the sample plugin for lmkd
Get the jtraceAPI.h (latest)

etc

  • I'm giving up supporting 32-bit, since Google won't support it either as of Oreo and later
  • Android Internals - Volume II - is not dead. Just put on the backburner because of MOXiI - but I'm just about done with that trilogy and OSes for good. So I'll be back.
  • As is usual, jtrace shares no code with any other sources, open or closed, strace's, Android's, Google's or otherwise, save for a couple of BINDER ioctl(2) codes, and the Binder Data structures.
  • If you find this useful, pointing your browser to http://NewAndroidBook.com/tools/counter?jtrace - if I can ask you to cut/paste this (so bots don't auto-follow and I get a human count :-). would be appreciated.
  • jtrace is so darn useful (it's helping me write Volume II) that I decided to write a guide on debugging in Android using it. But not before Volume II of Android is done..