The program ldd is wrong for a few reasons.
First, ldd is not meant to be accurate for determining load addresses. Use the environment variable LD_TRACE_LOADED_OBJECTS.
Second, ldd will never be correct with ASLR enabled as Guntram showed. You can disable this pretty trivially if you have sudo access.
$ LD_TRACE_LOADED_OBJECTS=1 /bin/bash | grep ...
The first tool is IDA decompiler (a plugin for IDA).
As far as I know for now IDA has decompilers for x86, x64, ARM32, ARM64, PPC, PPC64, and MIPS (see here for more details, each of them costs additional money and should be purchased separately).
The second is hopper which has much weaker decompiler and claims to be able to decompile arm64.
There is also a ...
There can be multiple reasons.
the FLIRT signatures which have been loaded automatically do not have a pattern for this specific function. You can check which signatures have been applied and try loading additional ones via Signatures view (Shift-F5).
the function pattern was conflicting with another function(s) and has been dropped from the final signature ...
I'm sorry to have to correct you, but VCRUNTIME140.dll is for example no known DLL (checked on Windows 7). "Known DLLs" is in fact a term that refers to a well-defined subset and the NT object manager is exactly the way to find out about which ones are known DLLs.
But that's likely not what you're asking. Instead you might want to try out the Dependency ...
This appears to be fairly typical virtual function call where the pointer to the virtual function table is stored in the object at offset 0000 and the call is to the function pointed to at offset 0028 in the table.
The object's virtual function table pointer (at offset 0000) is initialized in the class constructor. Since the constructor will be in the ...
I haven't touched Android in almost a year but IIRC:
All JNI libraries need to be loaded from Java side first e.g.
which translates to invoke-virtual in compiled Java.
Also, IDA Pro identifies fully qualified names in .sos it decompiles, so you will be able to figure out Java names for those JNI functions. See also http://...
First, ASLR will load the library at a (slightly) different address with each invocation, to help protect against malware. This is why the addresses between ldd and gdb are different, and why they may be even different each time you run gdb.
If i just grep for the libc executable segment on my system (64 bit, as i didn't have a 32 bit system handy):
$ grep ...
The required shared libraries are stored as DT_NEEDED entries in the dynamic section of the executable. This entry, in turn, points into the dynamic string table. So, to add another library, you will need to do something like this:
Parse the list of program headers and find the PT_DYNAMIC entry
Map its p_vaddr back to a file offset using the other PT_LOAD ...
I'd recommend loading the dll file into PE Explorer (View->Export), which will undecorate the names for you and show you the corresponding parameters/return value/calling convention.
You may also want to check out this question.
Those are C++ name decorations.
Name decoration usually refers to C++ naming conventions, but can apply to a number of C cases as well. By default, C++ uses the function name, parameters, and return type to create a linker name for the function.
See Name Decoration on MSDN for more info.
Question 2: Ordinals are just another way of making exports. You ...
There are many ways, but I'll cite two. Usually, a binary file, if not stripped, contains symbols (function names, variable names, ...). These symbols are usually used to ease debugging and are stored using a certain format, DWARF for example.
The first method is to disassemble the binary and look for specific threading libraries related symbols. For ...
There is no perfect answer for this, it will greatly depend on your tolerance to false positives. Though there are three answers that come to mind depending on you level of effort you're willing to put in. The options are listed from easiest/least work to hardest/most work - if each one is done correctly - the risk of FP also should go down as well.
It's been a while, but there should be a static code block with the .so they are calling. I would need to disassemble a file using a shared library.
It will resemble:
To the best of my knowledge theoretically most obfuscation techniques are also applicable to libraries, but there are considerable downsides: Slowdown and increased support-difficulties. Please note if a program does something, there is always a way to find out how it archived it when you control the execution environment.
I'd advise you to keep any ...
You are actually asking multiple different questions here :
[Regarding static linking only a few functions of a library]
Are there any general reasons why this is not a good idea or impossible?
Well it could be possible if it's your code and you know what you are doing (basically making a new library that is a subpart of the first one), but ...
There are two different ways to define JNI methods. The easiest way is to just give the functions special names like in the examples you've seen.
However, this is not necessary. JNI methods can also be registered dynamically with the RegisterNatives method. This is typically done in a function named JNI_OnLoad, which will automatically be called when the ...
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 ...
You can either press Ctrl+G and type LoadLibraryA to land at this function address, or if you want to list all the functions from kernel32.dll you can go to the Symbols tab like this:
From there you can view the function address or just double-click "LoadLibraryA" to follow it in disassembler.
goto the address, press d to decompile. if it looks like sensible code, then press F to make it a function. This is common for function pointers, windows COM, callbacks etc.
If your on an embedded system, you might need to check your memory map to tell the compiler to look in the correct regions of memory to find code. For example the call could be from ...
It's very likely that Ghidra doesn't know how to read the symbols from the dyld_shared_cache. You can try to use a different tool like IDA PRO, Rizin or radare2 or Cutter, etc.
But, which binary are you trying to reverse? Do you know which functions do you want to trace?
You can use the tool jtool, read more on jtool - Taking the O out of otool(1), and so ...
This is not true for all functions in kernel32.dll, but for specific functions that are imported from other dlls. You have to find out where the function is imported from and then look at the disassembly of the required dll.
Your disassembler might show you where the functions are imported from, kernel32.dll imports a lot of functions from the api-ms-*.dlls ...
If you have stripped binaries there's little you can do regardless of the platform you're on.
To view disassembled code on Linux, os you would with Otool on Mac, you can use objDump:
objdump --disassemble-all thebinary
if they are Microsoft dlls you are interested to know about
then ms normally provides a concise description of its dlls functionality in it FileVersion information
also other legitimate dlls do provide this information
(malware dlls or unknown authors dlls may not have it or may be faked up so it is just an indicator that can be trusted with a ...
I can see two paths for moving forward.
First, following your current approach, you can probably detect version information and library automatically in the strings you find. This is not a bulletproof solution but will save you the time of manually reading thousands of strings.
Go through the task of creating FLIRT, or one of the many function level binary ...
I think all anti-debug and anti-reversing techniques are also applicable to shared and static libraries. Shared libraries are still code, just placed in a different file format. I guess people don't talk much about anti-reversing techniques in library codes since the techniques are the same.
I know it's not a direct answer to your question, but would something like LD_PRELOAD mechanism allow you to achieve what you want?
With LD_PRELOAD you can specify your library which is to be loaded and functions from that library will be used instead of ones in the original library. This is a common and simple way of doing function hooking on Linux systems....