Reverse-engineering with GLIMPS-Audit
Reverse-engineering with GLIMPS-Audit
What could be more tedious, when starting the reverse engineering of a binary, whether for a vulnerability search or a malware scan for example, to have to start by finding the known code?
In some firmwares, where there are no debug symbols and the OS is proprietary, one can spend several months just to identify the essential functions (memcpy, print to uart…).
GLIMPS-Audit allows to pass this step in a few seconds. A binary pushed is immediately compared to millions of libraries and other binaries that we have collected and for which we have the symbols. In a few seconds, we see which code is included in the binary, and we can repatriate the documentation to our new analysis.
In our example, we have an elf with 14000 functions, of which only 2 are identified by IDA: “_init_proc” and “_term_proc”. Under normal circumstances, it looks like it’s going to be a long day…
The following screenshot shows the situation:
Now let’s run the binary in GLIMPS-Audit. We get the following list of nearby libraries:
- libgcrypt.so.20.2.4
- libsqlite3.so.0.8.6
- glxtrace.so
- RSQLite.so
- libsqlcipher.so.0.8.6
- libxml2.so.2.9.4
- egltrace.so
- libssl.so.1.1
- libgnutls.so.30.23.2
- libc-2.28.so
- libinproctrace.so
- libgcrypt.so.20.2.5
- libgcrypt.so.20.1.6
- libicuuc.so.63.2
- libcrypto.so.1.1
- libcrypto.so.1.0.0
- libstdc++.so.6.0.25
- libaria2.so.0.0.0
Now we know a little bit more about our binary ! The libc is present, the crypto, the xml, the sqlite, and the libaria2 We generate an idc for our binary. By applying the script, 5592 functions are immediately renamed among our 14000 functions. Of course, you still have some work to do, but with already named functions, as you can see below, it will be easier. Admit that you have gained a few weeks!
