Simple Frida script to assist in debugging and bypassing deliberate application crashes by listing the modules and offsets of pointers present in system registers at the time of a crash. Tested on Android.
The crash handler will periodically log the currently loaded modules in the application, once the crash occurs, the registers will be extracted from the Frida crash report and compared against the most recent list of loaded modules.
The output of the script will be the original crash report as well as a list of each register which has been matched to a module, alongside the module it was located in and the offset of the value in the register from the base address of the module.
Example:
Register: x17, Module: libc.so, Offset: 0x57940
Register: x23, Module: main.so, Offset: 0x6460840
Register: x27, Module: main.so, Offset: 0x64b6a20
Ensure Frida is running and your device is connected.
python crash-handler.py package_name [-s SCRIPTS]
Example package name: com.company.appname
The optional --scripts parameter allows you to inject other scripts at the same time as the crash-handler script. This is useful if there are some conditions that cause the crash to occur. For example, the application may only crash when a function is intercepted by Frida. The provided example.js script gives an example of a simple native code interceptor. To use this script you would add an offset to the script and run the crash handler like this:
python crash-handler.py com.company.appname -s ./example.js
Note that any additional scripts run with the -s / --scripts switch will not share a context and will not be able to see any variables located inside of each other, or the crash-handler.js file.
Locating the cause of a deliberate crash within an application with limited/obsfucated/no symbol data can be incredibly tedious. This tool can help to illuminate relevant regions of the assembly.
Using the output from this tool, one can check each output offset in the appropriate file using a tool like Ghidra or IDA. For example, given this line from the example output:
Register: x23, Module: main.so, Offset: 0x6460840
We open main.so in Ghidra and jumpt to offset 0x6460840, there we find some kind of type info. Since standard Ghidra analysis has been run on this file already, there are references here to the functions which seem to use this type data. It is likely that one of these functions is related to the crash.