[Official] Android reverse engineering tool focused on dynamic instrumentation automation leveraging Frida. It disassembles dex, analyzes it statically, generates hooks, discovers reflected methods, stores intercepted data and does new things from it. Its aim is to be an all-in-one Android reverse engineering platform.
I added a try and catch in the Analyser, since it crashed after analysing a Dex File which was not compiled with the same target SDK as Dexcalibur is/was using. I am not quite sure what the implications are, but in my case it was working and I could browse the decompiled newly loaded dex class. I guess it just does not overwrite the graph tree of the android SDK, so one might get wrong results, when one is heavily relying on SDK functions in the dynamically loaded Dex.
In any case, it should not crash, but probably warn the user better than it is done now (I did not quite look into error reporting, I just print the stack trace to the logs)
On another note, I corrected a spelling mistake in my previous pull request (frid-server -> frida-server)
Furthermore, I noticed that the code for copying the newly compiled Dex File over was reading every single Byte. In my case it took forever to copy a 2MB Dex file. So I was playing around with different other possibilities. I found that reading the file in a buffer first and then add it to the array shows slight performance increase, although I did not do any benchmarks. So could as well be placebo. Nevertheless one should focus more on this issue I think, since it is not practical to have to wait for 3 minutes to copy a 2 MB file :-D
Anyways, your Project is awesome! And I hope you continue the great work!
P.S. Have you considered including a Debugger? I was fiddling around with the JDWP stuff and Smalidea and I think it could be a real nice addition to allow debugging.
On another note, have you looked into the InMemoryDexClassLoader? Because the current Hooks don't include it, and I wasn't able to add a Hook for it (since it cannot find the signature, I guess since it was introduced in API Level 26?).
I added a try and catch in the Analyser, since it crashed after analysing a Dex File which was not compiled with the same target SDK as Dexcalibur is/was using. I am not quite sure what the implications are, but in my case it was working and I could browse the decompiled newly loaded dex class. I guess it just does not overwrite the graph tree of the android SDK, so one might get wrong results, when one is heavily relying on SDK functions in the dynamically loaded Dex.
In any case, it should not crash, but probably warn the user better than it is done now (I did not quite look into error reporting, I just print the stack trace to the logs)
On another note, I corrected a spelling mistake in my previous pull request (frid-server -> frida-server)
Furthermore, I noticed that the code for copying the newly compiled Dex File over was reading every single Byte. In my case it took forever to copy a 2MB Dex file. So I was playing around with different other possibilities. I found that reading the file in a buffer first and then add it to the array shows slight performance increase, although I did not do any benchmarks. So could as well be placebo. Nevertheless one should focus more on this issue I think, since it is not practical to have to wait for 3 minutes to copy a 2 MB file :-D
Anyways, your Project is awesome! And I hope you continue the great work!
P.S. Have you considered including a Debugger? I was fiddling around with the JDWP stuff and Smalidea and I think it could be a real nice addition to allow debugging.
On another note, have you looked into the InMemoryDexClassLoader? Because the current Hooks don't include it, and I wasn't able to add a Hook for it (since it cannot find the signature, I guess since it was introduced in API Level 26?).