Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Integrity Checker of Win9x/XP DLLs

- - - - -

  • Please log in to reply
27 replies to this topic

#1
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag
I am looking for a tool to easily and quickly check the integrity of Win9x/XP DLLs.

UltraISO and WinISO, for example, can quickly create a good-looking .iso from a bad CD (e.g. in UltraISO with -> Tools -> Make CD/DVD Image), without displaying a message that a bad sector was encountered on the CD during read-in. Bad sectors on the CD are usually stored in an .iso image as zeroes. As a result, files extracted from such an .iso may contain "holes" filled with zeroes, as displayed by Beyond Compare/Hex Viewer when compared against a good file.

Ideally the tool should be able to go quickly thru all the dll files in a mounted .iso and flag those which are corrupt. I have 100+ .iso images, which I would like to check whether they contain corrupt DLLs.

Ideally the tool should also identify corrupt CAB files (e.g. .DL_, .EX_ and .IN_) in a mounted .iso, and flag corrupt DLLs inside a CAB file in a .iso

Any suggestions?


How to remove advertisement from MSFN

#2
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag
Well, uncorrupted exe and dll files usually contain rather big areas of themselves filled with zeros (which is a part of why exe compression is often so efficient) so I don't think you can do anything along the lines of what you're looking for as you'd yeld countless false positives IMO.

However what you may want to do in the future is use some synchronization utility that uses checksuming, crc32 or other, and compare the content of the CD and the ISO image with it immediately after creating the latter.

Edited by loblo, 12 May 2012 - 04:36 PM.


#3
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

However what you may want to do in the future is use some synchronization utility that uses checksuming, crc32 or other, and compare the content of the CD and the ISO image with it immediately after creating the latter.

Hi loblo,
ImgBurn, for examle, displays a message when it creates a .iso file and encounters a bad sector during read-in. So creating a good .iso file with ImgBurn in the future is no problem, but what should I do with the 100+ .iso files created over the years with UltraISO? Maybe only 5% of these .iso files contain zeroed-out bad sectors, but which .iso files are the bad ones, i.e. which of my CD/DVD backups are bad?

A safe way to verify that a .iso was created correctly is to mount the .iso and make a binary compare with Beyond Compare of the files on the CD vs the mounted .iso image, although this does not verify the content of the boot sector on the CD, if the CD is bootable. With old, nearly-bad CDs this compare might become a nightmare.

Also, how can one know that a downloaded .iso file doesn't contain corrupt .DLL files?

MiTeC EXE Explorer can somewhat analyse the integrity of a DLL, e.g. if I open a .DLL file with MiTeC EXE Explorer, and it
- indicates a good .exe type, and
- under the Resource tab -> BITMAP section, all entries greater 1x1 display good images in the bottom window of MiTeC
the .DLL may be Ok, but there is no guarantee.

Using MiTeC EXE Explorer would be feasible for checking a few individual DLL files, but not for checking 100+ .iso files. Another solution may be to re-create the 100+ iso files from the CDs with ImgBurn, but this is very time-consuming and some CDs may have gone bad since the time the previous .iso files were created with UltraISO. Any other suggestions?

Edited by Multibooter, 12 May 2012 - 05:45 PM.


#4
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag
If a few bytes or even a single bit of code has been corrupted, Mitec or any other PE analyzer will show you what appears to be a valid file when in fact it is not.

There is no way you can be certain of the integrity of those files unless they've been checksumed, either individually or the ISO itself and you can then verify the integrity

But you knew all that already, didn't you?

#5
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

If a few bytes or even a single bit of code has been corrupted, Mitec or any other PE analyzer will show you what appears to be a valid file when in fact it is not.

Thanks loblo.
With a .really badly damaged DLL file MiTeC displayed "File is not in supported format". With another badly damaged file MiTeC only displayed the Hex View tab, not the other tabs like Header, Section, Directories etc.

Damaged files from CDs most likely don't differ from good files by just a few bytes, but rather contain zeroed-out sector-size "holes" [about 2k, http://en.wikipedia.org/wiki/CD-ROM , multiplied by the number of contiguous bad sectors], so damaged files from a bad CD have a quite distinct look in Beyond Compare/Hex Viewer when compared to the good file, and can be immediately recognized as damaged.

I am not interested in the authenticity of files (e.g. from MS), but in the integrity, there may be quite a few patched files in these 100+ .isos.

There is no way you can be certain of the integrity of those files unless they've been checksumed, either individually or the ISO itself and you can then verify the integrity

Sad to hear this. I had thought that there could be a reverse-engineering tool which de-compiles, de-links or whatever and then comes up with a message like "success" or "failure" of the process, and thereby identifies the corrupt files.

But let me re-phrase my question: Is there a tool which can identify a DLL as corrupt? This would help a lot, because it would tell me which isos of the 100+ would have to be re-created from the CDs. Even a tool which can identify some bad DLLs would be of help, because the flagging of just 1 bad DLL would be sufficient as a flag for a bad .iso/bad CD.

Well, as I am thinking about it, maybe it's easier to extract flat all cab files (DL_, EX_, IN_) from a .iso image, and then test extract these CAB files. A bad CAB file would flag a bad .iso just as well as a bad DLL. But there must be a more elegant solution, with 100+ .isos. Maybe a CAB repair tool could flag bad cab files in a mounted .iso, I'll be checking.

Edited by Multibooter, 12 May 2012 - 08:44 PM.


#6
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • Joined 12-May 07
  • OS:none specified
  • Country: Country Flag
@Multibooter,

There is no way you can be certain of the integrity of those files unless they've been checksumed, either individually or the ISO itself and you can then verify the integrity


This is the ONLY way to guarantee that ANY type of file has not been damaged, corrupted, changed, edited, modified, enhanced, or any other type of change you can possibly think of to ask about. PERIOD And that would of had to of been done before you ever copied the iso or files off the CD/DVD to begin with. But you are welcome to keep looking for an alternate solution.

Cheers and Regards

Posted Image


#7
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

This is the ONLY way to guarantee that ANY type of file has not been damaged, corrupted, changed, edited, modified, enhanced, or any other type of change you can possibly think of to ask about. PERIOD

Hi bphlpt,
I disagree with you for philosophical reasons. For me there are many roads which lead to Rome, so I haven't given up yet.

1. Test with Advanced CAB Repair v1.2:
- I extracted all files from the bad .iso into a folder. The bad .iso contains about 130 corrupt files with zeroed-out "holes" in them
- I renamed about 4500 files in this folder from*.??_ to *.CAB (e.g. .EX_, .DL_, .IN_). Advanced CAB Repair v1.2 only works on files with the .CAB extension
- I made a Batch Repair of these 4500 CAB files
- unfortunately, Advance CAB Repair repaired all except 2 .CAB files (the good ones and the corrupt ones), and did not display a message which CAB files were good, and which ones were bad.
The actually corrupt CAB files contained after the repair corrupt DLLs, severely truncated in size. I checked just 1 dll files in a "repaired" cab: the extracted .DLL was 64KB, compared to 1092KB of the DLL extracted from a corresponding good CAB file. Advanced CAB Repair could neither flag corrupt CAB files, nor repair corrupt CAB files in this test, although MiTeC Explorer did display several tabs for the truncated DLL extracted from the corrupt/repairedCAB.

2. Test with 7-Zip:
- I extracted again all files from the mounted bad .iso into a folder
- without renaming any files I selected everything in that folder and had 7-Zip extract everything to another folder. Files which were not archives (e.g. boot.bmp) were displayed in the message window as "Can not open file xxx as archive". And here the amazing result of this experiment:
- the corrupt CAB files were displayed in the message window like:
K:\junk\I386\TRACERT6.EX_
Data error in 'tracert6.exe'. File is broken

7-Zip can apparently identify all broken CAB files and many other broken archive files in a .iso (.CH_, .DL_, .EX_, .JP_, .. TS_, .TT_, ., .EN_, .FR, .IT_, .CAB, .EXE, .CHM, etc)
You simply have to:
1 - mount the .iso
2 - copy everything from the mounted .iso on the virtual drive to an empty folder
3 - select everything in this folder -> right-click and drag to another empty folder -> select 7-Zip -> select Extract Here
The extraction may take 2-3 minutes. If no msg "File is broken" is displayed in the 7-Zip message window, the .iso contains no broken archives and the .iso is most likely Ok
If there are broken archives in the .iso, 7-Zip will display them with the message "File is broken" Such isos have to be re-created, from the original bad CD.

I have just tested in the manner described above a reconstructed .iso, which I had created from a really badly damaged CD. 7-Zip did not detect any broken archives in the .iso, so the recovery of this bad CD seems to have been successful. :)

I am quite optimistic that there is a way to quickly identify corrupt DLLs, and hope that somebody else will pick up from here.

Edited by Multibooter, 13 May 2012 - 03:41 AM.


#8
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,798 posts
  • Joined 12-May 07
  • OS:none specified
  • Country: Country Flag

I disagree with you for philosophical reasons. For me there are many roads which lead to Rome, so I haven't given up yet.


I admire your spirit, and do not in any way want to dampen your enthusiasm or discourage your search. Many wonderful discoveries have been made in all fields when people did not accept "It can't be done". But I stand by my statement. Your method does seem to pick up some files that have specific types of errors. But note that I said "changed, edited, modified, enhanced" as well. if you substitute an old version of a file for a newer one, or take any type of archived file and rename it as another, say take NOTEPAD.EX_ and rename it as TRACERT6.EX_, your method will not find that to be a problem at all. Also, not all files on an iso are stored as compressed files, and as you found out, 7-Zip will not be able to help with anything that is not an archive. Not to mention that in essentially all cases 7-Zip can only identify and not repair those errors it finds. And what about missing files? As a result, your assumption that -- 'If no msg "File is broken" is displayed in the 7-Zip message window, the .iso contains no broken archives and the .iso is most likely Ok' -- will not always be correct. But I admit that if you are only looking to identify if there is a particular type of error in certain files that your method could be of help. Continue your search! We might all learn something from your efforts.

Cheers and Regards

Posted Image


#9
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,329 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag
Hmmm... this will not "fix" them but will (maybe) help identify them (?) - IsoBuster? (and NOT the "contents" Compressed files, just the BASIC filenames).

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#10
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag

Damaged files from CDs most likely don't differ from good files by just a few bytes, but rather contain zeroed-out sector-size "holes" [about 2k, http://en.wikipedia.org/wiki/CD-ROM , multiplied by the number of contiguous bad sectors], so damaged files from a bad CD have a quite distinct look in Beyond Compare/Hex Viewer when compared to the good file, and can be immediately recognized as damaged.


As I have already mentioned, most (all?) uncompressed (and uncorrupted) executable files have many such 2k+ "holes" in them so i am not sure how easily if at all your tools will let you see which of those "holes" are due to corruption and which are not.

Anyway, here is a nice little hex editor you may find interesting/useful, it's called BZ and it's got the rare feature of being able of displaying a bitmap image of the opened file (with zeros represented as white) and it is very easy to identify visually (and jump to) the location of various thing in executables with it, large areas consisting of zeros being the easiest to spot.

http://download.fore...ditbz/bz162.zip

#11
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

Anyway, here is a nice little hex editor you may find interesting/useful, it's called BZ and it's got the rare feature of being able of displaying a bitmap image of the opened file (with zeros represented as white) and it is very easy to identify visually (and jump to) the location of various thing in executables with it, large areas consisting of zeros being the easiest to spot.
http://download.fore...ditbz/bz162.zip

Good idea, definitely useful for inspecting individual files.

It could perhaps also be done in Beyond Compare/Hex Viewer by creating a blank file containing only zeroes, and then comparing various DLLs against this blank file. On the left side of the Beyond Compare/Hex Viewer window is a sliding bar window, with lines or rectangles, depending on the size of the file and the size of the matching/differing sections.

BTW, the mass-extraction with 7-zip of DLLs etc from the CAB files in .iso images or on CDs, indicated above, could perhaps be used to build a huge archive/repository of various versions of MS etc. DLLs. I still have among the stuff I got from a garage sale, for about $10, a binder filled with maybe 100 MS Technet Plus subscription CDs, Sept.1999 to July 2000, from a guy who was a MS certified something until the bust of the internet boom, and who then became a real estate agent, until the bust of the real estate boom. Would this be just a backup of stuff of an age gone by, or could such a pile of various DLL versions still be useful?

Edited by Multibooter, 13 May 2012 - 03:24 PM.


#12
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Well... it's my understanding you'd like to be able to check the integrity of every file in a CD/DVD or a CD/DVD image.
I have no solution for that, sorry!
However, as your initial post mentions specifically DLLs, I do have a partial solution for that, that may be of interest. Let's see its limitations:
Not all files are executables, and for non-executables this won't work. Not all executables are PE files (i.e.: files in the Portable Executable format), and for non-PE files this won't work. Not all PE files are checksummed (i.e.: there are PE files with the header checksum set to zero, when the true checksum is not zero), and for non-checksummed PE files this won't work. But it works for all checksummed PE files! :w00t:
Now, the bad news is Win 9x/ME does not care about the checksum, so non-checksummed PE files are more common for those OSes than for those of the NT-family. In any case I've done some quick statistics using my C:\WINDOWS\SYSTEM folder as a reasonable enough sample to see how useful my method might be, and here're the results:
Of 2232 files, 1574 (70% of the total files) are PE files.
Of these: 1111 (70% of all PE files) have matching checksums, 451 (29% of all PE files) have zero checksum on the header and 12 (1% of all PE files) have wrong checksums (those are sloppily patched files, which checksum was not corrected, in this case).
So, all in all, I was able to confirm that 49% of the total files are not corrupt, and had to investigate just 12 files... Seems good enough for me! :D
The method consists in calculating de novo the true checksum of a PE file and comparing it to the checksum present in the Optional Header: when both match, the file can be assumed to be non-corrupted. The exceptions to this rule are some files that chip with a wrong checksum in the header... I found out that QuickTime.cpl is an example of such a file (three different versions of it straight from the distribution package came with wrong checksum set in the header). I've thrown a little console app together, which I call VRFYPE (attached to this post), to perform the checksum test on any number of files. It accepts "*.*" as a filespec and proceeds to check each of the files, ignoring the non-PE files, and providing three possible veredicts on the PE files it finds: checksums match, or do not match or the header checksum is zero, returning all info for any given file in a single line, together with the filename, so as to be convenient for filtering with FIND or related DOS filters.
Please do test VRFYPE, and let me know of any bugs you find.

Attached Files



#13
tomasz86

tomasz86

    www.windows2000.tk

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,520 posts
  • Joined 27-November 10
  • OS:XP Pro x86
  • Country: Country Flag
Thanks dencorso. I'll definitely find your tool very useful. I'm just wondering whether it would be possible to have a switch to list only files which have wrong checksum. What I mean is something like this:

vrfype.exe /x folder\*.*
and the output would be a list of files with wrong checksum (with no additional info).

It would be possible to do this:

FOR /F %%I IN ('vrfype.exe /x folder\*.*') DO modifype.exe "%%I" -c

Edited by tomasz86, 29 June 2012 - 02:37 AM.

Posted Image
Unofficial Service Pack 5.2 for MS Windows 2000 <- use this topic if you need help with UURollup, Update Rollup 2 and other unofficial packages

#14
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

You may try:

vrfype folder\*.* | find /I "match"
if that does not solve it, let me know, and I'll implement the required switch.

Just a heads up: modifype.exe is not a good idea anymore, since it refuses to work right under Vista and 7. n7Epsilon's PEChecksum.exe should be used instead, in all cases.



#15
tomasz86

tomasz86

    www.windows2000.tk

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,520 posts
  • Joined 27-November 10
  • OS:XP Pro x86
  • Country: Country Flag
It works! I guess I need to learn more about using "|" in batch scripts.

This works to get a full path of the file:

FOR /F "tokens=1,2 delims=:" %%I IN ('vrfype.exe *.* ^| FIND /I "match"') DO ECHO %%I:%%J
I'll check PEChecksum.exe.

Edit: It seems to be a little bit tricky. The above script will work only if you use a full path, ex:

FOR /F "tokens=1,2 delims=:" %%I IN ('vrfype.exe %systemroot%\system32\*.* ^| FIND /I "match"') DO ECHO %%I:%%J
It doesn't work if you use it in a folder with *.* because the output looks like this:

1) when using a full path (%systemroot%\system32):
C:\WINNT\system32\file.dll: Header Chksum: 000136D1 Real Chksum: 0000D181 Chksums do not match! <img src='http://www.msfn.org/board/public/style_emoticons/<#EMO_DIR#>/sad.gif' class='bbc_emoticon' alt=':(' />
2) when using "*.*":
.\file.dll: Header Chksum: 000136D1 Real Chksum: 0000D181 Chksums do not match! <img src='http://www.msfn.org/board/public/style_emoticons/<#EMO_DIR#>/sad.gif' class='bbc_emoticon' alt=':(' />
so it must be this for "*.*":

FOR /F "tokens=2 delims=\:" %%I IN ('vrfype.exe *.* ^| FIND /I "match"') DO ECHO %%I
The output file be just the filename.extension, ex. file1.dll, file2.dll, etc.

Edited by tomasz86, 29 June 2012 - 05:23 AM.

Posted Image
Unofficial Service Pack 5.2 for MS Windows 2000 <- use this topic if you need help with UURollup, Update Rollup 2 and other unofficial packages

#16
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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

Hi dencorso,
Great job! :thumbup 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

#17
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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. :yes:
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. :(

#18
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag
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.

#19
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag
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 :thumbup

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 by Multibooter, 04 July 2012 - 04:59 PM.


#20
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

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).

#21
tomasz86

tomasz86

    www.windows2000.tk

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,520 posts
  • Joined 27-November 10
  • OS:XP Pro x86
  • Country: Country Flag
@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 :whistle:

http://www.thinkdigit.com/forum/power-supply-cabinets-mods/147389-power-supply-blacklist-thread-newbies.html
Posted Image
Unofficial Service Pack 5.2 for MS Windows 2000 <- use this topic if you need help with UURollup, Update Rollup 2 and other unofficial packages

#22
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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.o...pro2.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.o...spot/index.html

Edited by Multibooter, 05 July 2012 - 02:28 AM.


#23
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Thank you, Multibooter, for the swift feedback! :thumbup
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.

#24
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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.

#25
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,946 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

:hello: New version! :w00t:

No tally yet, but a better output: :yes:
If no command-line switches are given, only the non-matching checsums files are listed.
For the various alternatives use /? or -?.
Please test.

Attached Files






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users