In short, the difference is in the format into which Java and native code are compiled and executed. Compilation into native code formats eliminates from resulting executable a lot of information that Java code keeps by design, including, but not limited to the following list:
Properties names and types
The obfuscator probably used the '\u0000' "exploit".
This character is known as NUL terminator and its used for terminate the length of a character string in C/C++.
All renamed classes will contain that character, this will confuse tools like 7Zip, WinRar etc..
Original file names:
You can use JByteMod to edit your class bytecode.
You can also create new methods, delete methods, fields and change accesses.
Its pretty easy to use, just load the jar and select the class you want to edit.
I know few ways to prevent resources extraction/reading:
Encrypt your resources and dinamically decrypt them in runtime without writing temp files
Load the resources from the internet (require internet conntection)
Corrupt the CRC32 of the resources files, this will make winzip or winrar unable to extract your resources
Set \u0000 (\x0) as file name ...
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 ...
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 ...
I gave it my shot at this question but the output is still very obfuscated code you will need to re-run it a few passes through some more deobfuscators the code has alot of goto's code and math, you can do it all by hand but it will take months!.
It seems it contains classes to
Which means this jar file ...
It's very likely you need to access the .value of the object. Alternatively you could also "stringfy" this which is an easy was to understand all the properties of the Object. Also, you do not need to perform an overload inside of your overload, just call the method directly using this.decryptAesCipherText()
You can do all of the above with the fix ...
At first thats not obfuscated but just packed.
BIS Guard is pretty useless at all.
There are two ways to retrieve the encrypted classes:
Decompile your jar and reverse the main class of BisGuard (which is deobfuscated)
Empty the LDC "-XX:+DisableAttachMechanism" and attach an agent to dump the classes (https://github.com/karim789/class-dumper-...
There is a ghidra_script that current does this, see https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Features/Base/ghidra_scripts/MarkCallOtherPcode.java
op = getInstructionAt(toAddr(0x1b034)).getPcode()
Maybe. If the Source File of the Classes are present you can reverse the Class names.
Unfortunatly there are no ways to retrieve Methods and Fields names. The only thing that you can do for that is renaming the fields and methods with unique names to make the code more readable.