{"id":4031,"date":"2021-03-22T09:51:13","date_gmt":"2021-03-22T17:51:13","guid":{"rendered":"https:\/\/www.pnfsoftware.com\/blog\/?p=4031"},"modified":"2021-03-22T09:51:13","modified_gmt":"2021-03-22T17:51:13","slug":"jeb-codeless-native-signatures","status":"publish","type":"post","link":"https:\/\/www.pnfsoftware.com\/blog\/jeb-codeless-native-signatures\/","title":{"rendered":"Using Codeless Native Signatures"},"content":{"rendered":"\n

One of the new exciting features coming with JEB 4.0 is a set of signatures to identify common native libraries in a compiler-agnostic fashion<\/strong>.<\/p>\n\n\n\n

These “codeless” signatures were built to tackle an old reverse-engineering problem: the identification of common open-source libraries in executables. Because such libraries are compiled by the developers themselves, traditional code-based signatures — like our own SigLib<\/a> — need to be re-generated with the same <\/em>compiler setup than the developers, otherwise the signatures won’t match because the code differs. <\/p>\n\n\n\n

Therefore, identifying open-source libraries with code-based signatures is a lots of effort for a small return, because each set of signatures only matches one<\/em> compiler setup (compiler’s version, optimization level…), and there is a vast number of them!<\/p>\n\n\n\n

We developed codeless signatures to identify open-source libraries without the burden of signatures re-generation for each compiler setup. We are currently shipping signatures for the following libraries:<\/p>\n\n\n\n