Integrity Checker of Win9x/XP DLLs

[Multibooter]

However, as your initial post mentions specifically DLLs, I do have a partial solution

Hi dencorso,

Great job! During a preliminary check with VRFYPE of the DLLs on a MS WinXP and a MS Win98SE installation CD, I identified DLLs where the checksums don't match.

Unfortunately, I have already deleted all the bad DLLs and the bad .iso mentioned in my posting #1, since I have re-created a good .iso from the CD in the mean time. I still have the original bad CD, and I'll try to re-create a bad .iso with bad dlls from the CD, so that I have some material (i.e. bad DLLs) for further testing of VRFYPE.

It should be possible to create a tool to check the integrity of DLLs. For mp3s, for example, I am using 3 tools to check out mp3s:

- MP3Test

- EncSpot, which displays ther encoding used in the mp3

- mp3 Viewer in Beyond Compare, to compare similar mp3s, identifying mp3s which have identical content, but different headers

[dencorso]

Win 2k and Win XP use Win32 (= Portable Executables aka PE files) for almost all system files and applications (*.DLL, *.TLB, *.SCR, *.OCX, *.SYS, *.CPL, *.EXE, *.AX, etc.), and most of them *are* checksummed, so that for those (and latter NT-Family) OSes, VRFYPE does a pretty comprehensive job. Taking the C:\WINDOWS\SYSTEM32 folder of my Win XPSP3 as a sample, there there are just 64 in 2770 files that are Win16. Of course, most of the files in C:\WINDOWS\SYSTEM are Win16, too, so that adds more 26 in 33 files. So, in SYSTEM and SYSTEM32 together my machine has 90 in 2803 files that are Win16 (*.DLL, *.DRV, *.TLB, *.EXE, etc.): that's 3.2%. And there are also a handful of DOS (Real Mode) executables... All in all, I think it's safe to affirm that 90+% files in a Win 2k or Win XP machine are PE Files, and more than that for Vista+ machines.

The situation for Win 9x/ME is much less bright than that. Even so, if I were able to produce a companion VRFYNE, to cater for the Win16 files, it'd be possible to even the field somewhat, and it apparently is possible because they should be checksummed too (there is a checksum field in their headers) and MS aparently documents the algorithm of their checksum in KB071971. However, finding actually checksummed NE files (i.e.: those that have a value different from 00000000 in the correct header field) is quite unusual, and, by using those few that are checksummed and bona-fide as a test for my implementation of the algorithm in KB071971, I found out that either I did some gross mistake I cannot yet find or the published implementation of the algorithm *is not the right one*, because it consistently calculates values different than those present in the test NE files' headers.

output of vrfyne *.* 
lzexpand.dll Header Chksum: 80377b2a Real Chksum: db651403
lanman.drv Header Chksum: 2702481c Real Chksum: f1dcd01a
mciseq.drv Header Chksum: 7141695e Real Chksum: 3448c449
mciwave.drv Header Chksum: 7cda4a3c Real Chksum: 256b0a7e
olecli.dll Header Chksum: d51e6641 Real Chksum: 98cb4cda
pmspl.dll Header Chksum: 4959782e Real Chksum: 93dbfb5d
sysedit.exe Header Chksum: 5bb2317e Real Chksum: 475db7ca
ver.dll Header Chksum: 9539a529 Real Chksum: 2253e723

output of filever /a *.*
W16    DRV ENU        2.10.0.1 shp    221,600 08-23-2001 lanman.drv
W16    DLL ENU      3.10.0.103 shp      9,936 08-23-2001 lzexpand.dll
W16    DRV ENU      3.10.0.103 shp     25,264 08-23-2001 mciseq.drv
W16    DRV ENU      3.10.0.103 shp     28,160 08-23-2001 mciwave.drv
W16    DLL ENU        1.32.0.0 shp     82,944 08-23-2001 olecli.dll
W16    DLL ENU        2.10.0.1 shp     46,592 08-23-2001 pmspl.dll
W16    APP ENU      3.10.0.103 shp     18,896 08-23-2001 sysedit.exe
W16    DLL ENU      3.10.0.103 shp      9,008 08-23-2001 ver.dll

The VRFYNE used for those tests is an "as is" implemetation of the code in KB071971... I just tweaked the final output string format. So, in fact, I had to use a FOR command to obtain the results, because that VRFYNE doesn't know what to do with "*.*", but I've omited that in the report above for simplicity.

In any case, the practical use of VRFYNE would be limited, because MS seems to have eventually abandoned the checksums both for plain DOS .EXEs (which I hadn't mentioned up to this point, its the "16-bit checksum" in the quotation below) and for Win16 (that's the "32-bit checksum" below), around the time it moved on to Win32 for good:

Microsoft LINK version 5.3 and later do not compute a 16-bit or 32-bit checksum. The reserved bytes in the .EXE header are set to zero.

So I decided to relase VRFYPE, while VRFYNE remains on hold, pending I find a way to calculate de novo the NE checksum. But, by now, I really doubt that much will ever happen.

[jds]

When other approaches leave behind files of unknown integrity, calculate their MD5 and search the web for this. In most cases, the MD5 of executable files including DLL's will be recorded somewhere on the 'net, either from some site offering them for download, or some site that has performed a scan for malware on them. If the MD5 shows up, either someone has the exact same corrupt file (extremely unlikely) or it's good.

Joe.

[Multibooter]

Hi dencorso,

I first may have to possibly correct myself regarding UltaISO/WinISO creating files with zero-filled holes when creating an .iso from a CD with bad sectors. When I tried with UltraISO to recreate an .iso from the same bad CD as used before in my posting #1, but this time with a different burner, an Asus BW-12B1ST blu-ray burner, UltraISO terminated with a message that it encountered a bad sector. If I remember right, I had used a Pioneer BDR-203 blu-ray burner for the result in posting #1, so possibly the .iso with the zero-filled holes may have been caused by the hardware/firmware of the Pioneer. I currently don't have the Pioneer available, so unfortunately I cannot confirm this.

In any case I recreated with the Asus BW-12B1ST blu-ray burner a .iso of the CD with the bad sectors by selecting in UltraISO -> Tools -> Make CD/DVD Image -> select Skip Bad Sectors. The burner was reading the bad CD for about 7 hours, until the .iso image was finished. I subsequently copied 135 .dll files from this .iso containing files with "holes" to a separate folder and then checked these 135 files with VRFYPE. VRFYPE correctly identified 134 DLLs as Ok, and correctly identified a single DLL as bad, with the message "Chksums do not match".

Comparing with Beyond Compare the files of the mounted bad .iso against the good reconstructed .iso gave the same results: The zero-filled "hole" in the identidied bad DLL was displayed by the Hex Viewer of Beyond Compare. So VRFYPE did correctly flag the single bad .dll

I subsequently made a second test of VRFYPE. I copied all 1651 .DL_ files from the bad iso to a separate folder and then extracted these .DL_ files (they are CAB archives) with 7-zip into another folder, giving 1596 .dll files. 7-zip gave a lot of error messages during the extraction, probably also for the 55 missing dll files. The folder with the 1596 dll files extracted from the .DL_ files then served as a test collection for testing VRFYPE. When I ran VRFYPE, about 200 .dlls were flagged as bad (i.e. non-zero Chksums did not match), and about 1400 were flagged as Ok (non-zero Chksums are the same).

Because a lot of messages are generated by VRFYPE, I have sent the screen output to a file and then printed it: VRFYPE *.dll > summary.txt

Here some suggestions for adding some finishing touches to VRFYPE:

1) By default (i.e. when no parameters are entered) VRFYPE could be a utility to flag errors, i.e. only display messages when the Header checksum is not zero and differs from the Real checksum,

e.g. \WINNTBBU.DLL Checksums: Header: 12345678 Calculated: 23456789 ERROR BAD FILE

2) a parameter /Z(ERO) could display only messages for files with a zero header

3) a parameter /V(ERBOSE) could display messages for all files, as currently in v1.0

4) messages could be briefer, so that they don't wrap around to another screen line in case of long paths

5) A summary could be displayed, xxx files checked, yyy files had zero headers, zzz bad files (with non-matching, non-zero headers).

There may be a bug in VRFYPE: running the check on the 1596 dlls, 339MB, took about 1 second, but when I sent the screen output to a .txt file, Textpad counted only 1556 lines minus 4 lines for the title, i.e. no message line was contained in the output text file for 1596-1552 = 44 files. No idea whether there is a bug or some other error.

I noticed one peculiarity about VRFYPE: I ran VRFYPE on my dual core desktop, both under Win98 and under WinXP. The desktop has a bfg 7800 GS graphics card, which starts to whistle when the power supply doesn't provide enough current (this whistling problem was solved on another identical desktop by replacing a 450 Watts power supply with an 800-Watts power supply, but on the desktop used for testing VRFYPE I still have a 550-Watts power supply, which hasn't had this issue before). When I ran VRFYPE on the 1596 dlls, while a lot of other stuff was running, the bfg7800 GS card whistled for a fraction of a second, indicating perhaps that the CPU drew a lot of current.

Edited July 4, 2012 by Multibooter

[dencorso]

Hi, Multibooter!

Thanks for testing VRFYPE, your results are very encouraging. I'll try to provide a next version incorporating the suggested improvements soon.

There may be a bug in VRFYPE: running the check on the 1596 dlls, 339MB, took about 1 second, but when I sent the screen output to a .txt file, Textpad counted only 1556 lines minus 4 lines for the title, i.e. no message line was contained in the output text file for 1596-1552 = 44 files. No idea whether there is a bug or some other error.

I don't think so. I bet those 44 DLLs are NE files, which VRFYPE is ste to ignore. Please do check it: if they turn out to be PE files, then we have a bug, unless they are PE files damaged so as not to be recognisable as such (unlikely, put still possible).

[tomasz86]

@Multibooter

It's not exactly related to the topic but Watts are not the only factor when it comes to power supplies. Much more important is the quality of components it is made from. You may have a 1000W power supply but if it's made of bad (crappy) components it may be just unstable, no matter how many Watts it has got. A good 300W power supply may be better than a bad 500W one. Power supply is something you shouldn't try to save money on

http://www.thinkdigit.com/forum/power-supply-cabinets-mods/147389-power-supply-blacklist-thread-newbies.html

[Multibooter]

I don't think so. I bet those 44 DLLs are NE files, which VRFYPE is ste to ignore. Please do check it: if they turn out to be PE files, then we have a bug, unless they are PE files damaged so as not to be recognisable as such (unlikely, put still possible).

The bad CD contained 44 .DL_ files containing the following 44 files, which were not checked by VRFYPE:

Modification date, bytes, file name and New Executable (Win3.1) version:

07/21/2001 02:30 PM 69,584 avicap.dll

07/21/2001 02:30 PM 109,456 avifile.dll

08/17/2001 01:36 PM 32,816 commdlg.dll

08/17/2001 12:20 PM 30,160 compobj.dll Linker v5.3

07/21/2001 02:15 PM 27,200 ctl3dv2.dll

08/17/2001 01:36 PM 39,424 ddeml.dll

07/17/2004 11:36 AM 4,656 ds16gt.dll

07/21/2001 07:04 PM 3,440,660 gm.dls NOTE: is a .DLS file, not a .DLL file, even if extracted from GM.DL_

07/21/2001 02:15 PM 9,936 lzexpand.dll Linker v5.2

08/17/2001 01:36 PM 8,192 mciole16.dll

08/03/2004 10:51 PM 68,768 mmsystem.dll

07/21/2001 02:30 PM 61,168 msacm.dll

07/21/2001 02:30 PM 126,912 msvideo.dll

07/21/2001 02:29 PM 34,816 mwci.dll Linker v6.1

07/21/2001 02:15 PM 108,464 netapi.dll Linker v5.3

07/17/2004 11:36 AM 26,224 odbc16gt.dll

08/17/2001 12:21 PM 39,744 ole2.dll Linker v5.3

07/21/2001 06:35 PM 169,520 ole2disp.dll

07/21/2001 06:36 PM 153,008 ole2nls.dll

07/21/2001 02:15 PM 82,944 olecli.dll Linker v5.1

08/17/2001 01:36 PM 24,064 olesvr.dll

07/21/2001 02:15 PM 46,592 pmspl.dll Linker v5.1

08/17/2001 01:36 PM 5,120 shell.dll

08/17/2001 12:20 PM 4,208 storage.dll

08/17/2001 01:25 PM 19,200 tapi.dll

08/17/2001 01:36 PM 13,888 toolhelp.dll

07/21/2001 07:45 PM 94,784 twain.dll

07/21/2001 06:36 PM 177,856 typelib.dll

07/21/2001 02:15 PM 9,008 ver.dll Linker v5.2

08/04/2004 12:56 AM 363,520 w3svc.dll empty file, contains only zeroes

08/04/2004 12:56 AM 32,768 wabfind.dll empty file, contains only zeroes

08/04/2004 12:56 AM 49,152 wdigest.dll empty file, contains only zeroes

08/17/2001 10:36 PM 40,448 webhits.dll empty file, contains only zeroes

08/04/2004 12:56 AM 135,680 webvw.dll empty file, contains only zeroes

08/04/2004 12:56 AM 463,360 wiadefui.dll empty file, contains only zeroes

08/04/2004 12:56 AM 589,312 wiashext.dll empty file, contains only zeroes

08/17/2001 01:37 PM 9,216 wifeman.dll

07/21/2001 02:15 PM 13,312 win87em.dll Linker v5.3

08/04/2004 12:56 AM 32,768 winipsec.dll empty file, contains only zeroes

08/04/2004 12:56 AM 176,128 winmm.dll empty file, contains only zeroes

08/04/2004 12:56 AM 99,328 winscard.dll empty file, contains only zeroes

03/17/2007 04:45 PM 292,864 winsrv.dll empty file, contains only zeroes

01/17/2007 09:26 PM 314,880 wmpdxm.dll empty file, contains only zeroes

07/21/2001 06:38 PM 10,080 xcci20.dll

The bad CD was a specially modified WinXP SP2 CD, so not corrupt versions of the above files could probably be obtained also from a regular WinXP SP2 CD.

gm.dls, extracted from gm.dl_, is not a .dll file, so there are not 44, but only 43 dll files in the folder which VRFYPE did not check. This shows how important it is to indicate in the summary how many dll files VRFYPE checked.

31 out of the 43 DLL files were New Executable (Win 3.1), as indicated by MiTeC EXE Explorer, all using Linker version 5.6 unless noted otherwise above.

BTW, MiTec released a new version v1.3.0 of MiTeC EXE Explorer on 8-Jun-2012 http://www.mitec.cz/exe.html

12 out of the 43 DLL files not flagged by VRFYPE were corrupt: they were empty and had only zeroes in them (e.g. wiashext.dll had 589.312 bytes of zeroes), i.e. VRFYPE did not report corrupt files which had just a .dll extension, but were filled with zeroes.

When 7-zip extracted, for example, winipsec.dl_ it displayed :"Data error in 'winipsec.dll'. File is broken." and the file winipsec.dll was created by 7-zip with zeroes as placeholders. UniExtract v1.6.1.61 (gora mod, build 1377 of 3Jun2012) extracts from the bad winipsec.dl_ an identical winipsec.dll filled with zeroes, but without displaying an error message.

If a dll file is of a type which VRFYPE cannot check, VRFYPE should display a message like "Not PE type". Ideally, however, a CHECKDLL should be able to check New Executables also, but this could be a major project. I am not sure whether there are similarities between checking mp3s and checking dlls. EncSpot v2.2 beta 2, for example, http://web.archive.org/web/20070708091424/http://www.guerillasoft.co.uk/encspot/encspotpro2.2beta2.zip can look into the content of an mp3 file and identify the Encoder, bitrate, etc and is most of the time (maybe 90%) correct, at least with older mp3s http://web.archive.org/web/20080218014539/http://www.guerillasoft.co.uk/encspot/index.html

Edited July 5, 2012 by Multibooter

[dencorso]

Thank you, Multibooter, for the swift feedback!

Well, the reason I called the program VRFYPE was exactly this: if it manages to identify a file as a PE file and that file bears a checksum, it can verify whether it matches the true checksum or not.

One reason for non-matching checksums is file corruption, but another one is sloppy file-patching... and that's why I had VRFYPE say the checksums don't match, not "FILE IS CORRUPT"... that conclusion may or may not be warranted, since a sloppily patched file may work all right (the patcher having just forgotten - or overlooked - to fix the checksum after patching). I had VRFYPE in mind sometime before the start of this thread, but I only actually had a good reason for writing it because of this thread. However, it's not quite a "CHEKDLL": it's less beacuse it cannot check NE DLLs, but it's also more, because it can check EXEs, TLBs, OCXs, SYSs, MPDs and even files having other extensions, provided they are files in PE format.

Now, before anyone can create a true "CHEKDLL", it's necessary to find out how the NE checksums are actually calculated, since MS documentation of this point isn't reliable... and then, there still will remain the unsolvable case of non-checksummed files.

In any case, I'll incorporate a tally of how many PE files were checked in the next version. But I think that to cause it to print the name of every file it ignores because of not being a PE file not a good idea, at least not by default, because it'll create too much output, defeating any advantage accrued from supressing the output for non-checksummed and matching checksum files. I think it should report just the mismatching checksum files and a tally of files checked, unless the "verbose" switch is used. To find out how many non-PE files are there, it's just a matter of subtracting the tally it'll provide from the total file number as reported by DIR.

[Multibooter]

One reason for non-matching checksums is file corruption, but another one is sloppy file-patching

The exe-infector virus Tenga also modified/marked 2 bytes near the beginning of Tenga-infected .exe files. Tenga-infected files could be identified by these 2 modified bytes and by the current file modification date. "New Executable files (Win 3.1)" were not infected by Tenga, only PE files.

If you add a switch to verify files in subfolders, VRFYPE could be used to check large HDDs for possibly unidentified remnants of this exe-infector, which were not identified by Kaspersky.

VRFYPE ... can check EXEs, TLBs, OCXs, SYSs, MPDs and even files having other extensions, provided they are files in PE format. Now, before anyone can create a true "CHEKDLL", it's necessary to find out how the NE checksums are actually calculated, since MS documentation of this point isn't reliable... and then, there still will remain the unsolvable case of non-checksummed files.

Eventually you may look beyond checksums, but a project of a more-or-less known magnitude may then turn into an open-ended major project.

With mp3s, for example, MP3Test http://www.shivi.de/MP3Test.html does a lot of processing on each individual file; the MP3Viewer in Beyond Compare compares tag information; and EncSpot also does a lot of processing, trying to identify the encoder, number of frames, etc. With picture files, the Picture Viewer of Beyond Compare 3, for example, helps to identify corrupt picture files by displaying images and their viewed differences next to each other for individual visual inspection.

[dencorso]

New version!

No tally yet, but a better output:

If no command-line switches are given, only the non-matching checsums files are listed.

For the various alternatives use /? or -?.

Please test.

VRFYPE2.7z

[Multibooter]

New version! ... Please test.

Great

I have tested up to now only without any switches, e.g. >VRFYPE *.dll

Here some comments:

1) all files which generated the message "Chksums do not match" with the previous version of VRFYPE, were displayed Ok,

i.e. out of a test collection of 1595 good and bad dlls, all 25 dlls, which were reported before as having non-zero AND non-matching checksums, were listed

2) in this test collection there were quite a few files which had the file extension .dll, but contained just zeroes. These files were bad dlls, but not listed since VRFYPE is about checksums.

3) Initially I was looking for an integrity checker of dlls. Maybe this objective is too difficult or even impossible, so I am reformulating my question: Is there software which can identify (some) bad dlls? The new version of VRFYPE does flag very nicely Portable Executable dlls which have non-zero AND non-matching checksums.

4) I copied the new version of VRFYPE to \WINDOWSXP\SYSTEM32\ of a Farsi modification of WinXP, and ran VRFYPE without any switches. 3 files were flagged: rasapi32.dll, msxml.dll and kbdfa.dll. kbdfa.dll is the Farsi Keyboard Layout. kbda2.dll, for example, which is the Arabic_2 Keyboard Layout, did not generate a checksum error. kbdfa.dll may have been patched with no harmful intention, and I do not suspect a targeted modification to facilitate stuff like Stuxnet. No idea whether a non-matching checksum of a country-specific keyboard file could be used as a malware trigger to select targets in a hypothetical cyber war. It would be interesting to check whether VRFYPE can flag infected .dlls or .exes. VRFYPE as a tool to identify infections by not yet identified malware? VRFYPE as a tool to clean up after an infection?

5) VRFYPE seems to be able to identify some .exe etc files which were patched, etc. An inventory of patched applications?

Maybe VRFYPE can help distinguish original files from patched files, if there is no digital signature.

6) The 25 .dll files flagged by VRFYPE (and the bad .dlls containing just zeroes) did not display a Version tab in their Property sheets, and when hovering over them in an Explorer window, no version information was displayed.

7) A switch to also check sub-directories would be quite useful

A little program which has great potential

Edited July 30, 2012 by Multibooter

[dencorso]

Thank you, Multibooter, for testing VRFYPE!

The previous version had just the help switches, but the new one has some new ones.

"a" gives an output similar, although, I hope, more meaningful and shorter than the one produced by the original version.

Here are the contents of the help screen:

 Usage: VrfyPE <filespec> </option>
 where:  ? or h = this help;
         0 or z = checksum not set only;
         g = matching checksums only;
         a = all files with checksums;
         non-matching checksums is the default;

Fully zeroed files do not have the PE headers, so they are ignored as non-PE files.

PE files with block of zeroes below the headers will be duly flagged as having bad checksums... So it's important to look each of the flagged files to find out why does it have a bad checksum. One of the things I always do is to submit them to VirusTotal.

And there surely are some files the publishers release with bad checksums... two cases-in-point are:

QuickTime.cpl (v. 7.66.71.0) => Cheksums: Header = 0013644A Real = 001840F0 (a bona-fide file from Apple)

mpg4c32.dll => VirusTotal Report (please scroll down and click on "Additional Information": it is indeed a bona-fide file from MS)

[dencorso]

7) A switch to also check sub-directories would be quite useful

While I don't find time to add such a feature, there's a good workaround for it (warning: NT-family OSes only, sorry... the for command in 9x/ME does not do it). Try:

For /R "C:\Program Files" %1 in (*.*) do vrfype "%1" | find /v /i "dencorso" >> D:\TEMP\vrf2test.txt

...and you'll see it traversing all subdirectories of "C:\Program Files"... of course, if you use "C:\" it'll do it over the whole C: drive.

Now, "D:\TEMP\" must exist before issuing the above command, but vrf2test.txt need not: if it does not exist, it'll be created.

vrf2test.txt will contain a blank line for each file tested, and a blank line plus a line containing the fully qualified name of the file for those files having non-matching checksums... Of course, that's too many blank lines. But you can remove them using my yanklines script:

yanklines vrf2test.txt vrf2clean.txt

... if run from the folder vrf2test.txt is inside... or from anywhere, if using fully qualified filenames.

Or you can get any of the many DOS or Win32 sed ports, maybe also with the companion unix2dos port for correcting for the different unix and DOS end-line conventions, and run:

sed "/^$/d" < vrf2test.txt | unix2dos -D > vrf2new.txt

...bear in mind some sed ports require double quotation marks <"> while others prefer single quotation marks <'> for containing sed regular expressions.

Both alternatives produce almost the same result, but that sed command will remove all blank lines, while yanklines will let a single blank line remain (because it was created to remove duplicate or multiplicate lines).

Of course, all this can also be automated in a .cmd script.