8

Problem: We want to be able to tell with some certainty that specific versions of internal libraries are being used by a program. For example, if a software uses old, deprecated libraries internally. Also, we would like to be able to tell what shared libraries it is using on the host system.

What we have done so far: we used strings2 to look at UNICODE and ASCII strings in the executable. Manual analysis of these strings may provide library versions being used internally some times. As you can imagine, this is an inefficient method and not very reliable. We also looked at 'Dependency Walker' to build a tree of all dependencies. This doesn't allow us to know if outdated libraries are being used internally though. We also read two research papers around the subject:

Question: Is there a better way or an approach to be able to determine if an executable is using outdated libraries internally? For example, looking at strings is one possible way but is there a way to automate this? Because otherwise, looking at 1000s of lines of ASCII and UNICODE strings can get time consuming.

perror
  • 19,083
  • 29
  • 87
  • 150
learnerX
  • 233
  • 3
  • 9

1 Answers1

1

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 diffing tools out there with different versions of various libraries.

NirIzr
  • 11,765
  • 1
  • 37
  • 87
  • "...you can probably detect version information and library automatically in the strings you find..." That's what we were thinking as well. Is there a tool that already does something similar or do we need to write ased / awk / grep query instead? – learnerX Jul 02 '18 at 14:37
  • I'm not familiar with anything specifically for versions, but I do think that should be easy enough to do and improve as more input/data arrives. – NirIzr Jul 02 '18 at 15:08
  • IDA FLIRT will not work if a function's 'signature' does not change between library versions. – fpmurphy Jul 03 '18 at 16:22
  • @fpmurphy1 You can manually edit the autogenerated flirt signature to be more precise. – NirIzr Jul 03 '18 at 16:23
  • @NirIzr Are you saying a FLIRT signature can be manually edited to differentiate function versions even if the first 32 bytes match? – fpmurphy Jul 03 '18 at 16:30
  • @fpmurphy1 IIRC FLIRT signatures are only limited to 32 bytes by the tool generating the textual representation. I think you can make a longer signature by appending additional bytes to a specific signature. – NirIzr Jul 03 '18 at 16:32
  • 1
    @NirIzr. Just checked the FLIRT toolset. You can use the -p## switch with pct, plb, etc., to specify a length other than the default 32 bytes. And, yes, you can manually sppend additional byes to a specific signature. – fpmurphy Jul 03 '18 at 18:17
  • Cool. Thanks for going through that and letting us know :) – NirIzr Jul 03 '18 at 18:19