Software audit - how to?

You could look at Hashsets.net. That's another site to get hashes from. The person that runs it actually installs the OS's (in a clean environment) and then hashes the files. I've used it in combination with the NSRL files in testing and have seen a small, but notable increase in the amount of files I can exclude because they are "known".

Tom

So far I was using NSRL/Hashkeeper hashes for that purpose but the problem with these hash sets is that they recognize quite low amount of the files found (about 20-40%), especially when it comes to localized versions of the software files (European region).

I'm not sure you can use these to identify software to 100%. Files, yes. Even possible sources of files. But software? In most cases, it's may be reasonably safe to go on product name, but when you only get a 'collected software'-type of CD hash match, how do you know what software the hash comes from?

NSRL hashes were originally designed only to provide a list of known hashes, so that 'known files' could be dropped from the investigation, and so help the examiner to concentrate on unknown files. Using that kind of database to a reverse purpose may not be safe.

The software audit tools I've seen so far tend to go for 'installed software', i.e. more or less what you can see in the 'Add or Remove Programs' applet in the Windows Control Panel.

… but what about deleted/lost files etc.? And what if a disk/partition is corrupted?

Most software audit packages are not created for this. Their purpose is only to help in verifying that all software on a computer is licensed, and perhaps also not on some kind of company black-list.

How do you deal with this problem? What are you using for software recognition/software audit?

I use a handwritten program to extract the version information from executable Windows files – as far as I recall, it uses Windows built-in routines for getting at this info. (I wrote it in Delphi, but it could probably be done with Perl.) It extracts the same information that is displayed by right-click | Properties | Version, and puts it in an Excel file for further processing. Finding the file paths is easy enough, though I tend to rely more on file(1) than on EnCase file identification.

However, my purpose is almost always to be able to report software found on the examined computer a) without to much manual effort, and b) without spending more than a couple of minutes on analyzing the result. The customer typically wants to know if the computer contains any software that is not on an 'approved' list, but is not interested in paying a whole lot for it. That is, it's tailored to a particular need, and a particular cost-benefit evaluation. (I produce the list and look it over for obvious weirdness, they do any further checking.)

Same thing with software audit tools – they're usually tailored to identify active commercial software, which almost always is installed using MS Installer framework. And they are required to do so with minimal effort and intrusion – it's rarely acceptable to lock people out of their computers to perform an audit.

CdtDelta thanks for the response, but my goal wasn't to exclude more files from the examination. And even if it was, I can't - for purposes of a forensic statement within a criminal investigation - exclude some files based just on information provided by some "Limited Liability Company". A lawyer from the defendant side could very easily destroy my whole forensic testimony at the court as being incomplete/inadequate/insecure etc., you know, all that kind of stuff.

athulin that's a very interesting idea, thanks for that! That would be definitely a step forward.

So I would first have to export all files found by FTK and then run some little tool against them.

The tool would process recursively all the files and for each file does 2 things
1) try to extract the version information from a file
2) calculate SHA1 hash

Output would be written into a .csv table to keep it simple (can't use excel format because it has a limitation of 65535 lines, and we usually work with millions of files).

Then the only last simple step would be to merge this .csv table with previously created Files.mdb database, thus in fact I will add a few new columns which is exactly what I wanted.

I guess I will just take some already existing opensource win32 tool capable of making SHA1 hashes and just implement there those 3 Windows functions (GetFileVersionInfoSize/GetFileVersionInfo/VerQueryValue) and a simple csv output.

Really cool idea, just pity FTK doesn't do this very simple thing on its own.

Ok, so the tool is finished, working like a charm, and you can download it here.

I named it Forensic VersionInfo Investigator, or simply FVI 8)

Ok, so the tool is finished, working like a charm, and you can download it here.

I named it Forensic VersionInfo Investigator, or simply FVI 8)

Howdy Smithy,

Nice to see someone take a mear idea and turn it into something that could be pretty useful. Might be an idea to MD5 your exe and publish this on our site aswell so as I can validate the download once done.

Ronan

Hi Ronan,

I've made a couple of bugfixes in the meantime (check the homepage) and there might be some further improvements in the near future. Currently the latest version is 1.02.

I added the "fvi 1.02.zip" to the downloads section on this site as well. The filesize of the zip file is 33197 bytes and the MD5 is 7b0b57e18e139356410238d54659e8f9.

Enjoy wink

Hi everyone,

I just implemented the magic library into my FVI tool.

The magic library is many years used on the unix platform to detect file type based on various tests, most notable on magic values. Magic values are basically various signatures which you can define yourself in the magic dababase file. A signature in this sense doesn't need to be just a few bytes, it can be quite very complicated definitions, including the regular expressions.
This library as well as the database file is continuously maintained and, well, it can detect quite a lot. Besides the basic information about the file type it can also dig some additional metadata informations, like codecs used in video files, resolutions used in pictures etc. etc.
From the practical point of view, all this new information is represented as a single new column in the FVI's CSV output.

The magic library can be activated using the -v command line parameter. Check out the website for more info and download. The tool is FREEWARE.

What is actually cool about this is
- it's optional so you can keep using the standard mode
- since the most time is spent on the checksum calculations, the magic library time allocation is quite unnoticeable
- FVI uses this library as a DLL, so you can just replace it with a newer version when it's released without having to recompile the FVI
- and the most importantly - you can change, add and/or remove any definition in the magic database so you can adjust it to your purposes. There is the documentation included with the syntax description.

I originally wanted to just add information from PE section of executable files, in particular whether a file is a GUI or a console application. Then I thought i would add also this and also that,.. and at the end I just ended with using the external library D

John,

Good work on your project. Leveraging the UNIX/Linux File command has expanded your ability to identify lots of different types of files.

We have a tool that provides similar output with extremely high accuracy. We've been working on it for over a decade. If anyone would like to try it out, feel free to download a trial version (http//www.forensicinnovations.com/fitools.html). I am particularly interested in what features you would want to see added to this product. The included FIWDIR.EXE command line tool provides for comma delimited output, SHA-1, etc.. I would recommend trying FIWDIR.EXE c\*.* /V10=0/V11=39/V104=40/S/C/HC1/ST7 >OUTPUT.TXT for output like John's. Except, this solution would tell you what applications created the data files found, as opposed to what applications the executables belonged to.

Rob