File change detection utility for Win 9X/ME

  • Thread starter Thread starter null
  • Start date Start date
Zvi said:
What is the point in dumb checksumming in an AV scenario?
Click to expand...

file integrity checking is used for intrusion detection usually. TDS-3
also uses it as a virus "tripwire."

i personally wrote my own script with perl and cygwin that hashes files.

michael
 
There is no checksumming. What was the point of your dumb post?
Click to expand...

ordinary checksumming will detect viruses for obvious reasons. for
intrusion detection and file / system integrity verification, you really
need cryptographic hashing and secure storage of the hashes.

tripwire is good.

michael
 
Gnome de Plume said:
ordinary checksumming will detect viruses for obvious reasons. for
intrusion detection and file / system integrity verification, you really
need cryptographic hashing and secure storage of the hashes.
Click to expand...

Art's program isn't an integrity checker. All it does is report alterations in
files' time-date stamp, and in size. Even dumber than what I first thought.

Regards
 
Gnome de Plume said:
file integrity checking is used for intrusion detection usually. TDS-3
also uses it as a virus "tripwire."
Click to expand...

Adapted file integrity checking, not to confuse with dumb integrity checking, is
used for virus detection in several products.
i personally wrote my own script with perl and cygwin that hashes files.
Click to expand...

Back in '90, I wrote and presented to the AV industry the first integrity
checker for virus detection (and recovery from). The method was implemented
later on in Symantec's NAV, Thunderbyte's Tbclean, and Eliashim's PIC. The very
same method is still in current use in Real Time Integrity Monitoring of today's
InVircible.

Regards, Zvi
 
Zvi said:
Art's program isn't an integrity checker. All it does is report alterations in
files' time-date stamp, and in size. Even dumber than what I first thought.
Click to expand...

Due to the fact that I'm busy surfing porn and reading 3 books, i hadn't
checked Art's page until now. In some ways, the aforementioned program
may be more valuable than a checksummer, due to the types of malware a
home user would encounter.

SIV (system integrity verifier) and FIV (file IV) come in handy on
servers. Often app-level rootkits replace legit binaries with
trojanized versions. obviously, if the hashes are stored securely, it
serves as a tripwire. certain ring 0 rootkits can defeat this though.

In the Route 66 (ISP) rooting, the admins had stored the hashes on a
writeable medium. So HFG (hacking for girlies) found and modified them
so the box passed the hash test. this is an example of right idea,
wrong implementation.

michael
 
So is this: http://xrl.us/dicj
Click to expand...

MD5 is slow, though I may take another look at it now that PCs have
speeded up considerably.

I've had some fun playing with the idea of generating a list of paths
to new files to be used by the McAfee command line scanner. Say you
have generated a file named SCANTHIS with a version of my F-Comp
program. Then the command line:

SCAN /CHECKLIST SCANTHIS

will result in the scanning of only files written to the disk after a
selected date, or modified after a selected date.

This does reduce by an order of magnitude or two the time required to
scan a drive on-demand ... as you might imagine. The whole thing is
done in less than a minute. What's the point of scanning the same
files over and over again?


Art
http://www.epix.net/~artnpeg
 
Bart said:
In Message-ID:<[email protected]> posted on
Sat, 16 Oct 2004 20:05:15 GMT, (e-mail address removed) wrote: Begin




Speed versus hash collision related thread:
http://www.webmasterworld.com/forum88/5061.htm
Click to expand...

the main difference is CRC is cyclic redundancy check, which is a form
of checksumming. MD5sums uses MD5 to make a cryptographic hash. CRC is
easily reversed, MD5 is generally one way only.

obviously there have been some attacks on MD5 and SHA to make collisions
or pseudo-collisions. nevertheless, modifying a binary file to make a
collision would be virtually impossible.

michael
 
the main difference is CRC is cyclic redundancy check, which is a form
of checksumming. MD5sums uses MD5 to make a cryptographic hash. CRC is
easily reversed, MD5 is generally one way only.

obviously there have been some attacks on MD5 and SHA to make collisions
or pseudo-collisions. nevertheless, modifying a binary file to make a
collision would be virtually impossible.

michael
Click to expand...

Quick example of a CRC collision:
http://www.nattyware.com/bin/crc32fake.zip
 
Gnome de Plume said:
the main difference is CRC is cyclic redundancy check, which is a form
of checksumming. MD5sums uses MD5 to make a cryptographic hash. CRC is
easily reversed, MD5 is generally one way only.
Click to expand...

You should be a little more precise in your choice of language...

Ignoring suggested potential weaknesses in MD5, it is much more accurate
to say that MD5 is feasibly one way. That is, unlike with CRCs there are
no better (i.e. computationally less expensive) ways of finding collisions
than launching a brute-force attack. Clearly MD5 cannot be one-way unless
you are inclined to believe the totally preposterous notion that all
possible strings of all possible lengths can be uniquely represented
within the address-space of MD5's 128-bit digest.

The important thing about "secure hashes" (as MD5 was hoped to be) is not
that they are one-way, but that they are _effectively_ one-way -- that is,
that there is no faster mechanism for finding collisions than a brute-
force attack _AND_ that such a brute-force attack is unfeasibly expensive
for extant equipment _AND_ the sensitivity of the material (e.g. a "weak"
hash that can be broken in days or weeks may still be strong enough if the
system employing it can only be attacked with bogus, "matching" input if
that input must be supplied within a few seconds).
obviously there have been some attacks on MD5 and SHA to make collisions
or pseudo-collisions. nevertheless, modifying a binary file to make a
collision would be virtually impossible.
Click to expand...

_At present_.

One concern is that, as the weaknesses that led to the discoveries of
these (partial) collisions are better understood, so attacks utilizing
them may be able to be made much more efficient (of course, without
improving the technique at all, the attacks will always get faster thanks
to Moore's Law...).
 
Helps to read the info doesn't it? :)
Click to expand...

Yes, it helps, if such info was available without needing to make special
efforts. My default system is XP and I had to mount Win 98 to read your info
(correct there "a earlier" to "an earlier"). No wonder that I assumed F-comp is
an integrity verifier, as did other readers of this thread. If you weren't such
dummkopf then you could have added the info as text file to the program's ZIP.
In one mode that's all it does. In the other mode it reports files
that have been either written or modified after a selected date.


You are even dumber than I thought!
Click to expand...

For your information, "dumb checksum" is a technical term to distinguish between
simple forms of checksumming / hashing, compared to more elaborate forms of
integrity checking, implemented in several AV products. For that matter, both
MD5 and CRC are "dumb" integrity verification methods, the term has nothing to
do with your program's amateurishness.

After having played with your program, here are some of my comments:

From the general appearance of the program, its GUI, and its declared purpose,
the program is a DOS one. Therefore, it makes no sense at all why you chose to
compile it to run in a DOS box under Windows 9x/ME, uniquely. It won't run in a
W2K/XP DOS box, nor pure DOS, and exits with the message "this program should
run in Windows" (as if XP isn't Windows!).

If it had any value at all, then it should be able to run under plain DOS, after
external booting. Going to the other end of the OS spectrum, your program
doesn't run under NT based OS (NT / W2K / XP). What's the logic in that?

The GUI: F-comp responds to mouse commands only, no keyboard inputs. If the
mouse doesn't function then you are stuck.

Report files: F-comp creates 8 reference and report files which it stores in
its own directory. Additional files are created on every run/query to F-comp.
There is no choice where to put those files except in the program's own
directory. This has several drawbacks. I put the program on my desktop to see
what it does, and had my desktop cluttered in no time with loads of unidentified
files. The major drawback of this behavior is that you can't use F-comp from
protected media, like CD, or write-protected floppy, as it hangs since it cannot
write to its own directory.

Functionality: Alteration detection based on time-date stamp change and file
size has little to no use in AV, unless supported by "smart" integrity checking
(opposed to "dumb" integrity checksumming, which is what I assumed you were
doing, until you clarified that F-comp isn't doing even that). As mentioned by
Michael, and myself in <[email protected]>, current
malware is capable to conceal processes, services, directories and even files.
Therefore, it's a must that your program should be able to run from plain DOS,
and of protected media, to have any value at all.

I don't know for sure the reason for which you chose to implement F-comp the way
you did, but I suspect that the true one is simply because you have no clue how
to do it otherwise.

To users that are interested in the functionality that F-comp claims to provide,
may I add that there exist AV optimized products that do it properly and
effectively.

Bottom line: F-comp is a pathetic and amateurish implementation of an immature
concept.

Regards, Zvi
 
Nick said:
Ignoring suggested potential weaknesses in MD5, it is much more accurate
to say that MD5 is feasibly one way. That is, unlike with CRCs there are
no better (i.e. computationally less expensive) ways of finding collisions
than launching a brute-force attack. Clearly MD5 cannot be one-way unless
you are inclined to believe the totally preposterous notion that all
possible strings of all possible lengths can be uniquely represented
within the address-space of MD5's 128-bit digest.
Click to expand...

"A one-way hash function has many names: compression function,
contraction function, message digest, fingerprint, cryptographic
checksum, message integrity check (MIC), and manipulation detection code
(MDC). Whatever you call it, it is central to modern cryptography."

"MD4 is a one-way hash function"

"MD5 is an improved version of MD4" [1]

michael

[1] applied cryptography by schneier
 
Yes, it helps, if such info was available without needing to make special
efforts. My default system is XP and I had to mount Win 98 to read your info
(correct there "a earlier" to "an earlier").
Click to expand...

If you had brains enough to read the subject of this thread you would
have seen that it says "File change detection utility for Win 9X/ME".
No wonder that I assumed F-comp is
an integrity verifier, as did other readers of this thread.
Click to expand...

Don't ASSume that others are as dumb as you are. Some may be astute
enough to understand that one mode of F-comp is indeed a type of
integrity checker. The other mode is not.
If you weren't such
dummkopf then you could have added the info as text file to the program's ZIP.
Click to expand...

That's the old fashioned and dumb way. Far better to include Help or
Info pages right in the program.
For your information, "dumb checksum" is a technical term
Click to expand...

For your information, formal technical terminology NEVER users such
terms as "dumb". At least in my day, such amateurish and derogatory
terms were frowned on.
to distinguish between
simple forms of checksumming / hashing, compared to more elaborate forms of
integrity checking, implemented in several AV products. For that matter, both
MD5 and CRC are "dumb" integrity verification methods, the term has nothing to
do with your program's amateurishness.

After having played with your program, here are some of my comments:

From the general appearance of the program, its GUI, and its declared purpose,
the program is a DOS one.
Click to expand...

It's a 16 bit DOS program written in QB 4.5 mixed with assembly
language.
Therefore, it makes no sense at all why you chose to
compile it to run in a DOS box under Windows 9x/ME, uniquely.
Click to expand...

It makes perfect sense if you have a clue. The interrupt services I
use to get the required detailed multiple file date information and
LFN info are not available in pure DOS.
It won't run in a
W2K/XP DOS box, nor pure DOS, and exits with the message "this program should
run in Windows" (as if XP isn't Windows!).
Click to expand...

Good. That's what it's designed to do in the case of DOS. For those
who don't read subjects of threads like you, I'll probably add a
simple Windows version check as well.
If it had any value at all, then it should be able to run under plain DOS
Click to expand...

So according to Zvi, apps that don't run in plain DOS don't have any
value. Whatta clown :)
, after
external booting. Going to the other end of the OS spectrum, your program
doesn't run under NT based OS (NT / W2K / XP). What's the logic in that?
Click to expand...

What's the "logic" of any program not designed for NT based OS? What
kind of a dumb question is that?
The GUI: F-comp responds to mouse commands only, no keyboard inputs. If the
mouse doesn't function then you are stuck.
Click to expand...

Windows allows you to kill DOS windows simply and easily, so you're
never "stuck". So fix your goddam mouse problem then :)
Report files: F-comp creates 8 reference and report files which it stores in
its own directory. Additional files are created on every run/query to F-comp.
Click to expand...

Additional files? The number of files created is limited by the number
of file extensions chosen to check. Once both modes are used, there is
no further increase in the number of files created.
There is no choice where to put those files except in the program's own
directory.
Correct.

This has several drawbacks. I put the program on my desktop to see
what it does, and had my desktop cluttered in no time with loads of unidentified
files. The major drawback of this behavior is that you can't use F-comp from
protected media, like CD, or write-protected floppy, as it hangs since it cannot
write to its own directory.
Click to expand...

Not indended to be used in those ways. Period.
Functionality: Alteration detection based on time-date stamp change and file
size has little to no use in AV, unless supported by "smart" integrity checking
(oppsed to "dumb" integrity checksumming, which is what I assumed you were
doing, until you clarified that F-comp isn't doing even that). As mentioned by
Michael, and myself in <[email protected]>, current
malware is capable to conceal processes, services, directories and even files.
Therefore, it's a must that your program should be able to run from plain DOS,
and of protected media, to have any value at all.
Click to expand...

Hey, you're the clown that was not that long ago in here pushing
informal Windows scanning methodology for NT based OS. I'll throw your
argument right back at you. If something works most of the time or at
least some of the time, then it's not valueless.
I don't know for sure the reason for which you chose to implement F-comp the way
you did, but I suspect that the true one is simply because you have no clue how
to do it otherwise.
Click to expand...

You finally got something right. I'm too old to be interested in
Wndows GUI programming and keeping up wirth the rat race. Been there
and done that.
To users that are interested in the functionality that F-comp claims to provide,
may I add that there exist AV optimized products that do it properly and
effectively.
Click to expand...

LOL! You don't have in mind your own products, Im sure :)
Bottom line: F-comp is a pathetic and amateurish implementation of an immature
concept.
Click to expand...

Odd, but that's exactly the way your products always struck me. Maybe
we should both quit fooling around :)


Art
http://www.epix.net/~artnpeg
 
Back
Top