Function signatures are very useful when analyzing programs, especially when the program links some libraries.
However, if the object being analyzed is a statically linked ELF program, then a considerable portion of the code in the ELF program consists of library functions.
For instance, if a program statically links glibc, at this point, it is necessary to manually create the function signature of that glibc. However, the function signature seems to only support the calculation and import of a single file. If only the so file of this glibc is calculated and imported, then even if the functions other than the exported function in glibc are successfully matched, their function names will be meaningless. Therefore, only the function name of the exported function exists in this so file.
So, is there a way to directly calculate the function signature of a static library, that is, libc.a? If imported directly in Batch mode, the libc.a is actually split into multiple.o files for analysis and calculation. This is not only difficult to operate but also makes it impossible to map them to the static library itself.
I have found that WARP actually supports direct analysis and calculation of libc.a. However, as far as I know, WARP is a rather strict matching mechanism. Many times, we do not have the original static library of the static link program, so we can only look for some alternative and similar static libraries. And they may cause the WARP GUID to be inconsistent due to external conditions such as the compiler.
Function signatures are very useful when analyzing programs, especially when the program links some libraries.
However, if the object being analyzed is a statically linked ELF program, then a considerable portion of the code in the ELF program consists of library functions.
For instance, if a program statically links glibc, at this point, it is necessary to manually create the function signature of that glibc. However, the function signature seems to only support the calculation and import of a single file. If only the so file of this glibc is calculated and imported, then even if the functions other than the exported function in glibc are successfully matched, their function names will be meaningless. Therefore, only the function name of the exported function exists in this so file.
So, is there a way to directly calculate the function signature of a static library, that is, libc.a? If imported directly in Batch mode, the libc.a is actually split into multiple.o files for analysis and calculation. This is not only difficult to operate but also makes it impossible to map them to the static library itself.
I have found that WARP actually supports direct analysis and calculation of libc.a. However, as far as I know, WARP is a rather strict matching mechanism. Many times, we do not have the original static library of the static link program, so we can only look for some alternative and similar static libraries. And they may cause the WARP GUID to be inconsistent due to external conditions such as the compiler.