You can't analyze native functions with a standard decompiler because native functions are not implemented in the Java Bytecode (The Java Native Keyword and Methods).
You have to use common x86 disassemblers (Like IDA, JEB) to analyze the native functions.
At first, search for System.loadLibrary calls, to see which native library gets loaded (should be in a ...
Generally, if the native libraries are distributed (in the apk) without debug symbols (which is quite common, and along with that, the apk was also made non-debuggable), you would not be able to find those debug symbols unless you are the developer or you are able to obtain the libraries with debug symbols from the developer.
Therefore, even though you can ...
The reason why your code is slow is not Frida but your code. Your code would be also slow when executed in plain J2SE Java.
The simple reason is because you are reading the file byte by byte using an unbuffered FileInputStream which is the worst way you can read a file. Typically IO operations work on blocks of at least 4096 bytes (a typical block site in a ...
You can try:
jclass toast = (*env)->FindClass(env, "android/widget/Toast"); // get the class you need (need to be already loaded otherwise you have to define it first)
jmethodID methodToCall = env->GetStaticMethodID(toast, "makeText", "(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;"); // get ...
It is a bit unclear what do you mean by "library being called". If you want to know when the library is loaded, you may look for references to System.loadLibrary(string) or System.load(string) java functions. You might for example hook it using Frida.
If you want to see when particular functions exported by the libusbhost.so are called, you also ...
By reverse engineering Google Play Store app some projects has been created that support the unofficial protobuf based API that is also used by Google Play Store app itself. Using this API it is possible to retrieve meta data of an app not installed.
However as the API is designed for being used on a device you will get only get results "filtered" ...
As far as I know the Dalvik cache does not contain plain dex files, but instead contains optimized (odex) files.
Odex files use an extended op code set and I would assume the dex-to-smali decompiler you have used doe snot support those extended op codes and simply ignores them. That is the reason the virtual invocations are not present in the Smali code ...
The thing that is unclear to me is what happens in the code block from 00088868 to 00088898. In a plausible scenario, the flow should continue from 000888BE. In that case, this is a TEA encryption function, as can be seen from the 0x9E3779B9 signature, characteristic of the TEA cipher and its modifications like XTEA, and the code at 000888E0, which is ...
Since Android 10.0, it has move some of its important library into different path ( including libc.so )
so IDA can't automatically found where it is like it used to.
You need to execute export IDA_LIBC_PATH=/apex/com.android.runtime/lib/bionic/libc.so to tell IDA where libc.so can be found.
I'm going to guess this is MPEG Streaming of some manner.
Here's what file run at various byte offsets into the first 10k bytes of the file produces:
598 /dev/stdin: MPEG-4 LOAS, 4 or more streams, 8 or more streams
838 /dev/stdin: MPEG-4 LOAS
1232 /dev/stdin: MPEG-4 LOAS
1696 /dev/stdin: MPEG sequence, H.264 video, baseline @ L 31
3204 /dev/stdin: MPEG ADTS,...
See your emulator, your ADB communication probably failed, open your terminal and check that your emulator is displayed with an ADB device, generate a new RSA certificate and try again, I recently had the same problem with debugger from IDA and its competitor JEB, and that was the solution that worked for me.
See also how to properly configure the ADB for ...
You have two possible approaches in here:
Analyze the APK of the device, reverse engineer it and try to make sense of how it communicates with the USB device.
Connect the USB device to a computer, sniff the USB packets, and try to make sense of how it communicates with the host.
I believe the former would be straightforward and simpler than the latter, not ...
It's possible that the kernel is not actually gzip compressed but uses another algorithm. I would recommend using vmlinux-to-elf which can not only automatically detect the compressed stream, uncompress, and convert to an ELF but also parse the kallsyms tables and symbolize the image.
The app could be checking if its signature matches the signature of the key used to sign it.
Refer to this SO post on how an android app can perform such a check.
One way you may try to bypass the signature is to replace the reference signature in the apk with that of your key, after doing some reverse engineering of the apk. You may get information related ...
Ok, I've started to look into this one by connecting to the PCB's RX/TX.
Baudrate is 921600 (8N1) and I get this output:
usb host begin
USBHALHost init begin
musb change to bdevice after usbc reset
usb connect 0x10
mark ip 1