exclude/tag strings referenced by library functions (identified by FLIRT)

[williballenthin]

No description provided.

[symbolicvoid]

Hello @williballenthin, I have a question about this issue. Doesn't FLOSS already recognize library functions using viv-utils? Can we use that to tag strings used by these? I guess we could use the addresses to see if the strings are used within the functions, but not sure about arguments etc. though..

[mr-tz]

Exactly, for recognized functions we can mark associated strings up accordingly. This markup doesn't happen currently and we would also have to discuss and/or change the rendering of identified library-related strings.

[williballenthin]

yeah! this is just what we want to explore. seems like the data is there and shouldn’t be too hard, but we’d like to try it out and see if the idea works. then there’s additional research to be done to improve library detection, especially when the signatures don’t match well.

[williballenthin]

Ah sorry @mr-tz beat me too it (and by a lot, sorry, im just traveling back home today).

[symbolicvoid]

Thank you for the replies! Also it does seem like FLOSS can sometimes not recognize library functions.. For example, this is a C program that I used (compiled by GCC):

#include<stdio.h>

int main(){
    printf("Hello World");
    return 0;
}

Just a simple hello world program. However, FLOSS seems to be picking up multiple functions and decoded strings:

I assume those are added by the compiler, but is there something we can do to mark these functions aswell?

[mr-tz]

We don't have any signatures for GCC currently. We could try with the rizin libs (https://github.com/rizinorg/sigdb).

[symbolicvoid]

Oh I see. I can test around with this issue and see if I can do something about it.

[symbolicvoid]

Is there any data I can use to test the code? Something that has library functions with strings that can be recognized by FLOSS. @mr-tz @williballenthin

[williballenthin]

i dont think we have any binaries handy right night, but using something statically linked with OpenSSL or zlib should provide a good starting point, since those strings are fairly obvious and easy to correlate with the source code, and FLIRT signatures should work reasonably well against them.

[mr-tz]

Plus Microsoft Visual Studio CRT functions from many versions (see https://github.com/mandiant/siglib/); when using the default signatures. I'd recommend to find a file, e.g., from https://github.com/mandiant/capa-testfiles that has many library function identifications and start from there.

[symbolicvoid]

Plus Microsoft Visual Studio CRT functions from many versions (see https://github.com/mandiant/siglib/); when using the default signatures. I'd recommend to find a file, e.g., from https://github.com/mandiant/capa-testfiles that has many library function identifications and start from there.

@mr-tz Sorry I don't understand what you mean. Could you please explain more?

[mr-tz]

Sorry for being unclear. My comment was meant as an addition to Willi's comment above it.

Our signatures should also pick up standard run-time (library) functions used by MS Visual Studio compiled binaries.