I tried to find out how RuntimeException works internally in cs.android.com so I can understand how to prevent crashes but didn't find anything useful and I have no clue how to analyze components-related JDK in perspective of reverse engineering, I'm curious what's going on behind RuntimeException so I can prevent crashes

I tried with this Frida script but no luck

Java.perform(function() {
    var RuntimeException = Java.use('java.lang.RuntimeException');
    RuntimeException.$init.overload().implementation = function(){
        console.log("hits .overload()")
    RuntimeException.$init.overload('java.lang.String').implementation = function(arg1){
        console.log("hits .overload('java.lang.String')")
    RuntimeException.$init.overload('java.lang.Throwable').implementation = function(arg1){
        console.log("hits .overload('java.lang.Throwable')")
    RuntimeException.$init.overload('java.lang.String', 'java.lang.Throwable').implementation = function(arg1,arg2){
        console.log("hits .overload('java.lang.String', 'java.lang.Throwable')")
    RuntimeException.$init.overload('java.lang.String', 'java.lang.Throwable', 'boolean', 'boolean').implementation = function(arg1,arg2,arg3,arg4){
        console.log("hits .overload('java.lang.String', 'java.lang.Throwable', 'boolean', 'boolean')")
  • @Robert then why when we try to patch RuntimeException calls the app is still crash when it calls RuntimeException ? is there someting happening internally ?
    – IVs
    Commented Feb 2 at 10:09

1 Answer 1


RuntimeException is an Exception class like all the others, the only difference is that developers are not forced to catch RuntimeException and its child classes. And there is no special relation between RuntimeException and "native calls" (JNI calls).

Your problems are independent of the RuntimeException instead they are located in your Frida hooking code:

When hooking an Java/Android method (or constructor) the Frida hook replaces the original function. So if you just want to log method/constructor calls you always have to manually execute the original method inside the hook.

At the moment you don't call the original constructor of RuntimeException and return nothing, which means if Android tries to create an instance of RuntimeException no exception instance is created. This can never happen in compiled Java code and in the end the app crashes.

Therefore you have to modify your hooking code to call the original constructor and return the created RuntimeException instance:

let RuntimeException = Java.use('java.lang.RuntimeException');
let RTctor1 = RuntimeException.$init.overload();
RTctor1.implementation = function() {
    console.log("hits .overload()");
    return RTctor1.call(this);
let RTctor2 = RuntimeException.$init.overload('java.lang.String');
RTctor2.implementation = function(arg0) {
    console.log("hits .overload('java.lang.String')");
    return RTctor2.call(this, arg0);
  • thank you Robert, but your hook code is only logging - actually it just makes the crash easier -, "you don't call the original constructor of RuntimeException and return nothing" -> this is the point to prevent RuntimeException-based crashes. are these cases are not possible with RuntimeException ? and if not, why ?
    – IVs
    Commented Feb 2 at 13:05
  • 2
    @IVs OK, now I really understand what you are trying to do. But that can and will not work. If the app is crashing because of a RuntimeException that you can only try to hook the code and modify values/arguments in a way so that the exception is never thrown. If the app tries to throw an Exception it is already too late. Catching in exceptions in Frida e.g. by hooking a method that throws an Exception is also not that easy to my experience.
    – Robert
    Commented Feb 2 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.