S
ScaredyKat
That was sarcasm, by the way. I don't know where you people get this stuff about me.
S
Sammi More
Zvi Netiv said:
Which of Raid's viruses did not preserve the host? AFAIK, They store
the original data at the host tail and restore it before they run
it... That's what I've read anyway. Perhaps you are still angry over
the Krile Vs invircible incident? It did embarrass you afterall. HOw
did your threats go with Juha's publisher? Anything ever come of it?
Not true. At one point you made the claim that those IV's files could
restore virus infected files; And to a very limited extint, they
could, I grant you this. However, the ToadAV method was better ONLY
because it stored more bytes.
It depends. If The beginning 8k and only 8k of the PE is damaged, the
file can be saved; Fully intact, all bytes present. Surely this is
worth doing.
None of Raid's viruses were based off someone elses code. Nobody in
either AV nor Vx circles ever accused him of such a thing; and I'm
sure had it been otherwise, someone would have pointed that out.
Raid mentioned a virus known as CIH by name, and explained that the
virus could not be removed by his program, due to the method CIH used
to infect files; I fail to see where he showed ignorance by saying
this. CIH infects empty space inside the PE executable; ToadAV Was not
designed to deal with this, and your header orentied recovery method
wouldn't work either...
IV fails to disinfect more files then ToadAV, So perhaps he did know
what he was doing after all. Remember the Krile Incident, IV couldn't
even restore the files, even tho it claimed as such. And Krile was a
true prepending virus, not an overwriter as you claim.
IV fails to restore files of even the simplest problems. I believe
Raid and others took IV apart and studied the file format; IV doesn't
retain enough useful data to restore from much.
I see, because I do not claim IV is allah; I am ignorant? Sorry Zvi,
but only you believe such nonsense.
Indeed. Petty.
S
Sammi More
Zvi Netiv said:
Really? Like this then:
The databases consist of collections of 66-byte records - thus
their file size is always a multiple of 66. Each such record has
the following format:
Offset: Contents:
------- ---------
00 - 01 Record identifier. Can be 'MZ', 'PK', or 0xEA60.
02 Length of the name of the file.
03 - 0E File name, format "NAME.EXT", right-padded with zeroes.
0F - 3D File data.
3E - 3F Partial file checksum.
3F - 41 Record checksum.
The file name field is "encrypted" using the following algorithm:
for (i = 0; i < record [2]; i++)
record [i + 3] ^= 0xFF;
The contents of the file data field depends on the type of the
file and is different for COM and for EXE files. (The file type is
determined by the first two bytes of the file's contents; not by
its extension.) Its format for both file types is as follows (the
offsets are for convenience given from the beginning of the record;
not from the beginning of the data field):
COM-type files:
===============
Offset: Contents:
------- ---------
0F - 2A Stores the 0x1C (28 decimal) bytes from the file between
offsets 0x00-0x1B.
2B - 30 Stores the last 6 bytes of the file.
31 - 34 Stores the length of the file. Clearly, two bytes are wasted.
35 - 36 Stores the time of last modification of the file.
37 - 38 Stores the data of last modification of the file.
39 - 3B If the file begins with a JMP Near, the 3 bytes of the file
where this JMP points to are stored in this area. The field
is unused if the file does not begin with a JMP Near.
Instructions like JMP Short or CALL Near are not handled.
3C - 3D Unknown.
EXE-type files:
===============
Offset: Contents:
------- ---------
0F - 28 Stores the 0x1A (26 decimal) bytes from the file between
offsets 0x02-0x1B.
29 - 2A Stores the 2 bytes after the EXE header (i.e., the two bytes
at [file [8] * 0x10].
2B - 2E Stores the length of the file.
2F - 30 Stores the time of last modification of the file.
31 - 32 Stores the date of last modification of the file.
33 - 3D Unknown. The contents of those bytes does not seem to depend
on the contents of the file.
The whole file data field is "encrypted" using the following
algorithm:
for (sum = 0, i = 2; i < 14; i++)
sum += record + 1;
key = ((sum + 16) & 0xFF) % 7;
for (i = 0xF; i < 0x3E; i++) {
record ^= key++;
key %= 7;
}
The partial file checksum is computed using the following algorithm:
for <i = 0x20; i < 0x1020; i += 2)
file_chksum += * (unsigned *) (file + i);
That is, the words from offset 0x20 to 0x1020 of the file are
simply added together. First of all, this checksum algorithm is
astonishingly insecure from the cryptographic point of view. It
would be trivial for a virus to infect the file without modifying
its checksum - all it has to do is to overwrite the file, compute
the checksum of the overwritten part, subtract from it the checksum
of the virus body, and use the complement of this number in the
last word of its body.
Second, an "add-them-together" checksum is much less likely to
detect random corruptions than, say, a CRC. Furthermore, one and
the same area of the file is checksummed, independent of the file
type. For EXE files this often means that only the relocation items
area of the header is checksummed and no part of the actual code is
covered by the checksum.
Finally, the record checksum is computed using the following
algorithm:
for (rec_chksum = sum, i = 0x12; i < 0x40; i += 2)
rec_chksum += sum ^ (* (unsigned *) (record + i));
Here 'sum' is the same number computed from the encrypted file
name field that was used to compute the initial value of the key
used to encrypt the file data field. This checksum algorithm is
slightly (only very slightly!) more elaborated, but does not cover
the first 4 bytes of the file data field. It also has to be noted
that this checksum is computed after the file data field has been
encrypted.
Note that the original attributes of the file are not saved in the
database. Also, it is very important to note that the database does
not contain a checksum of the whole file. This means that the file
restoration capabilities of the registered version of the program
cannot be reliable - because the program has no information that
would allow it to verify whether the file has been entirely
restored to its original contents.
-- Now, Unless you have changed the IVB.NTZ file format extensively,
it would appear sir, That YOUR format; and not Raid's! Is inferior if
one is to recover his or her file. I'm sure your familiar with this
lengthy disection of your format.
R
Roger Wilco
parasitic file infectors (reference to sub-thread) is a given and so wouldn't have been necessary to state.
File infectors are a type of virus. A virus only has to create a viable copy of itself (as an overwriter does) to be considered
a virus. The copy can exist as a file, in a file, in a program, in a process, - whatever. Overwriters may not be sophisticated
viruses, but they are viruses.
How so? If you execute the copy (the now overwritten file) the virus runs again and can overwrite yet another file. It is the
failed parasitic infector that falls short of replicability, not the overwriter. You first qualified your statement about "virus" by
saying that you were talking within the confines of this part of the thread (recovery) and not about viruses generally, and
now you are back to saying that overwriters are not viruses. Program code that copies itself to a place where it can in turn
execute at some point in time is a virus, it doesn't have to parasitically infect files or guarantee that it will in turn execute.
calling other subtypes like 'overwriters', non-viruses.
I'm not. You have every right to expound misinformation, and since this is unmoderated it is obvious that no person
can stop another from doing so. I was just trying to state my opinion about your opinion. You have written software
to help people deal with malware and yet you don't seem to know what a virus is.
parasitic modification. This is an aid to the success of virally modified program files, but it is not a 'must do' thing for a
program to be considered a virus.
Hindering how? Do you mean preventing, or just making difficult. If the method doesn't prevent (recursive) replication, then
it is still a virus. So, what "strict definition of a virus" do you propose that this previous definition of a virus stems from? As
far as I have seen, there is no restriction on where a virus writes itself to other than to say that it can't corrupt the original
by overlapping.
Overwriting in this sense usually refers to malware payloads that overwrite to corrupt data and has little to
do with an overwriting virus although from a recovery standpoint they may be identical. If a program were
written called 1.com which created a file called 2.com with the exact same contents - and in turn when it
was executed created 3.com ... etc...it is a virus even if it at some point in time overwrites a preexisting
##.com file. Just because the ##.com file is non-recoverable by software doesn't mean the program is
not a virus.
A contribution of misinformation can be done without imo.
File infectors are a type of virus. A virus only has to create a viable copy of itself (as an overwriter does) to be considered
a virus. The copy can exist as a file, in a file, in a program, in a process, - whatever. Overwriters may not be sophisticated
viruses, but they are viruses.
How so? If you execute the copy (the now overwritten file) the virus runs again and can overwrite yet another file. It is the
failed parasitic infector that falls short of replicability, not the overwriter. You first qualified your statement about "virus" by
saying that you were talking within the confines of this part of the thread (recovery) and not about viruses generally, and
now you are back to saying that overwriters are not viruses. Program code that copies itself to a place where it can in turn
execute at some point in time is a virus, it doesn't have to parasitically infect files or guarantee that it will in turn execute.
calling other subtypes like 'overwriters', non-viruses.
I'm not. You have every right to expound misinformation, and since this is unmoderated it is obvious that no person
can stop another from doing so. I was just trying to state my opinion about your opinion. You have written software
to help people deal with malware and yet you don't seem to know what a virus is.
parasitic modification. This is an aid to the success of virally modified program files, but it is not a 'must do' thing for a
program to be considered a virus.
Hindering how? Do you mean preventing, or just making difficult. If the method doesn't prevent (recursive) replication, then
it is still a virus. So, what "strict definition of a virus" do you propose that this previous definition of a virus stems from? As
far as I have seen, there is no restriction on where a virus writes itself to other than to say that it can't corrupt the original
by overlapping.
Overwriting in this sense usually refers to malware payloads that overwrite to corrupt data and has little to
do with an overwriting virus although from a recovery standpoint they may be identical. If a program were
written called 1.com which created a file called 2.com with the exact same contents - and in turn when it
was executed created 3.com ... etc...it is a virus even if it at some point in time overwrites a preexisting
##.com file. Just because the ##.com file is non-recoverable by software doesn't mean the program is
not a virus.
This is just an appearance.Maybe because unlike yourself, I do not insist
on posting when I have nothing worth saying, or contribute to the discussion.
A contribution of misinformation can be done without imo.
Z
Zvi Netiv
Roger Wilco said:
The second generation of an overwriter may be called a Trojan, at best, but not
a virus. Which is why they are excluded from 'official' virus test suits.
Regards, Zvi
S
Sammi More
Zvi Netiv said:
Why is this? As far as I understand things, A virus need only
replicate itself; So long as it meets that critera, it is a virus.
Overwriting viruses, indeed continue to replicate even though the host
is destroyed in the process of infection by the virus's very nature.
You are the only antivirus person I know of which claims an
overwriting virus is not a virus; By what definition does it become a
trojan instead of a virus? It still replicates viably even after
second generation...
Please explain your reasoning for this, It contradicts what I've read.
As it were!
R
Roger Wilco
Zvi Netiv said:
There is a difference between 'calling' something a virus, and that something 'being' a virus. Opaserv.k's payload is
an overwriting virus, it overwrites data on disk, corrupting structures like the partition table, while also overwriting
program code in a way that allows it to run in turn. Granted it may not be included in official tests, but it is a virus
and will recurse if the affected disk is booted from with accessible virgin drives present. It causes too much destruction
of data to go unnoticed and is very unlikely to survive on its own. If it weren't for the worm we never would have
seen it at all, but it qualifies as a virus because it copies its replicative code to other locations on the machine it is
running on. As a bonus it even adds a valid boot code signature to increase its chances of recursion although this
is not strictly necessary to qualify it as a virus. I know realise that 'good' virus tests require recursion as prerequisite
behaviour, but they don't state flatly that those that don't recurse aren't viruses at all by definition - only that they
would 'muddy the waters' of the test set so to speak.
http://search.yahoo.com/search?p=ov...i=UTF-8&fr=FP-tab-web-t&cop=mss&tab=&toggle=1
brings up many hits for overwriting virus for instance
http://hq.mcafeeasap.com/dispVirus.asp?virus_k=1424
which states:
Virus Name Risk Assessment Type SubType
Yukon Low Virus File Infector*
Virus Characteristics
Yukon is an overwriting, file infecting virus. It does not become memory resident. It infects .COM files, including COMMAND.COM.
Each time an infected file is executed, the virus infects all .COM files in the current directory.
==========
* I'm reasonably sure that if it were a "parasitic file infector" then that 'SubType' would have been listed - so what
happens to your assertion that "There is no parasitic file infector "subtype", all file infectors are parasitic by definition."?
This clearly is a non-parasitic file infector.
Z
Zvi Netiv
Roger Wilco said:
Not only that it's nonsense, but it's also irrelevant to file infectors.
[ ... ]
Proves just nothing, or more exactly, that you have no clue.
Yukon is one of the many collection samples that AV producers and researchers
used to exchange between them in the early days of AV (the Yukon page is from
1991). The only "useful" purpose of that junk was to artificially beef up virus
lists and let AV producers claim that their product detect large numbers of
viruses. During my short lived membership with the NCSA I was several times
offered to subscribe to these junk samples, which I never did for obvious
reasons. Yukon is not a virus, for the same reason that Leprosy isn't one, nor
Raid's overwriters and I very much doubt that any self respecting AV producer
would add similar crap to their lists today.
Collection viruses, as well as dumb overwriters do not participate anymore in
virus test suits, because they do not qualify for virus, in the strict sense.
Period.
You should check your own assertions before crying ignorance so loud. Searching
google for "parasitic file infector" brings up 451 hits. If you further refine
the search and restrict it to single domains (to remove unprofessional
references, like reviews) then you find 30 hits for McAfee (NAI.COM) and just
one occasional hit for Symantec.
Try now searching for "non-parasitic file infector", which returns zero hits.
If "parasitic" was a sub-type as you claim, then it would be mentioned at least
once, out of the tens of thousands of info pages about file infectors.
Obviously, the only explanation to the absence of "non-parasitic file infector"
is because none exists Specifying "parasitic file infector" is the same as
"file infector" plain, and the parasitic and non-parasitic sub-types are the
fruit of your ignorance.
I believe that I wasted enough time on your trolling. You'll excuse me now if I
ignore your further trolling in this thread. Respectfully, I have better things
to do with my time than wasting it on your pointless sophistry.
Regards, Zvi
S
Screaming Radish
Zvi said:
I said AV companies were padding the virus counts years back when NuKE
was still active. Funny thing was at the time no AV developer or
researcher would admut it
I reverse engineered a number of the virusscanners of the day and found the number of viruses they scanned for
just didn't match the number of search strings in the code. McAfee had a
discrepancy of over 400 in one version of their scanner.
Screaming Radish
N
Norman L. DeForest
[some reformatting for line length]
So the Junkie virus is only a virus *some* of the time?
It doesn't preserve the functionality of *.co_ files that it
infects as the signature bytes at the start of a compressed *.co_
file are essential to its functionality (that of being capable
of being uncompressed by EXPAND.EXE).
[snip]
So the Junkie virus is only a virus *some* of the time?
It doesn't preserve the functionality of *.co_ files that it
infects as the signature bytes at the start of a compressed *.co_
file are essential to its functionality (that of being capable
of being uncompressed by EXPAND.EXE).
Z
Zvi Netiv
Norman L. DeForest said:
Why speaking of CO_ files and involving EXPAND, when you could simply state that
Junkie corrupts EXE files when renamed to COM?
Read my analysis on Junkie (I was the first one to isolate and report it) in
http://groups.google.com/[email protected]
(note that Bontchev pretends having received that analysis from me. ;-) The
truth is that I never sent it to him, but posted it on FIDO, where he got the
sheet from).
Your above statement proves at best that viruses aren't bug free. Junkie is a
COM file infector and multipartite that was fairly common in the DOS days and it
almost completely disappeared with the introduction of Windows 32 because it
hung the PC from first boot after having booted of an affected MBR. The reason:
Junkie's author opted to infect COM files on base of their extension name,
rather than checking the file structure. The problem was that from Windows 95
and on, COMMAND.COM is a renamed EXE file, not a true COM because its size
exceeded the 64 K segment size limit, and that file was the first one to become
infected (actually corrupted) when the OS attempted to load, and hung the PC.
Junkie is a virus since it qualifies to the definition in full, at least for 16
bit DOS. Junkie's anomaly doesn't change that, and the example contributes
nothing new to the discussion.
Regards, Zvi
N
Norman L. DeForest
Because Junkie infects any file with an extension that begins with "CO",
including *.CO_ files that are compressed .COM files. If EXPAND.EXE
doesn't see a proper signature, in the *.CO_ file, it generates no error
message whatsoever but just assumes that the file was not compressed and
copies the file as-is to the destination *.COM file. You now have an
unusable and non-functional but infectious *.COM file.
I don't think I need to. I ended up cleaning a whole pile of copies of
Junkie out of someone's system (and out of his master system disks with
dozens of *.CO_ files) using just DEBUG. This was over a Christmas
holiday week when every computer store in the city had closed for the
holidays and no antivirus software was available. I had to disassemble
some of the non-working files to find out that they were infected and to
find out how to clean them.
Actually, the virus only checked the first two characters of the
extension so it infected *.CO? files, only some of which were the
presumed intended target. *.COM, *.CO_, *.COW,
I was just asking. Your insistance that "maintaining the original
functionality of the host program or file" was a necessity to qualify
as a virus appeared to me to disqualify Junkie from being called a virus
since it *did* destroy the functionality of *.CO_ files that it infected.
I just wanted clarification on that.
Norman "going off to sulk and eat worms" De Forest
Z
Zvi Netiv
Norman L. DeForest said:
Doesn't change much of my follow-up.
You could spare yourself that effort by copying all *.CO_ files to a dedicated
directory, rename them to *.COM (some cleaners won't process *.CO_ files) and
clean them with any cleaner (even IVSCAN - IV's 16 bit cleaner - would clean
them from Junkie), restore the .CO_ extension, and overwrite the bad files with
the clean ones.
I stand corrected then.
I see. Yet there is a minor logical flaw in that presentation: Exceptions to
the rule do not imply that the rule is wrong, just that there are exceptions.
Regards, Zvi
B
Bart Bailey
Depending on the number of exceptions,
a "rule" might become a mere generalization.
Z
Zvi Netiv
Bart Bailey said:
It's interesting to note that in Hebrew, both terms stem from the same root
(rule is the noun "klal", and generalization is "haklala", i.e. making a "klal",
actually formulating a rule).
I think that the use of "exception" indicates that the deviation from the rule
are in minority.
Regards, Zvi
R
Roger Wilco
It qualifies because of the successful infections, the failures don't detract from the fact. The failed infections are
corruptions, but because there are successes it qualifies (although care must be taken to remove the failures
from any test set you may be creating). I was saying that the only thing that must be able to execute in an infected
program file is the virus code - maintaining the original program's function is a plus but is not a requirement for
the virus to qualify as a virus. Zvi is using a definition for virus that excludes any virus that does not retain the
original program's functions, and I disagree with that. There are examples of overwriting viruses that I posted
search results for and he took one of them and stated that it was only used to beef up the number of viruses
that some AV programs could claim detection for, and ignored the rest. Maybe they are not a threat, maybe
they are so lame that they aren't even being created anymore, but that does not mean they are not viruses. If
they replicate recursively due to code they contain, then they are viruses.
F
fluidly unsure
Roger said:
How would you categorize a 'companion virus'? (HLLC in Symantecs
dictionary.) It doesn't infect a file (per se) and some of them don't
even replicate. It looks to me like most of them qualify more as
rootkits than viruses since all they do is alter a core OS function.
Is this just another case of fuzzy definitions like confusing
virus/worm, spyware/adware, or hacker/cracker.
R
Roger Wilco
fluidly unsure said:
The Turing Machine virus model doesn't cover this scheme, but you can see they are so much like overwriters in that
they assume a preexisting file's name yet the contents have been replaced. If the virus passes execution to a copy of
the original it is parasitic (original funtion is maintained), but only if the copy is available - either way the virus can
"infect" a file in the sense that the host file or its environment is modified to make the new virus function execute when
the "host" filename is invoked. The Turing Machine model had no file system, only the fact that the symbol set, when
processed according to an instruction set, resulted in the set being written again to the tape without damage to the first
symbol set. This implies that for a given instruction set, the symbols themselves are responsible for the resulting copy.
Another implication is that the new copy could in turn be processed (recursion), and the Turing Machine model makes
no guarantee that this will or will not happen. "Infection" is not implied nor is parasitic modification of programs, their
files, or the environment.
To bring this to a modern systems level, you would have to configure the tape to simulate the information space as
it exists in a modern system. Still, if a symbol set copy is created in the computing devices information space as a
direct result of the symbol set/instruction set pair - it is a virus.
Some are only worm function (or even non-replicating malware) guardians or guerrilla tactic reinfestation schemes.
If it really was a failed virus infection, than it isn't a virus - but its daddy was (no guarantee of recursion) and if it
was not an only child and some were viable then daddy had proof. In fact this is part an parcel to the way virus
sample sets are maintained - they like the sample they use to be proven capable of viable offspring.
http://www.virusbtn.com/old/OtherPapers/VirLib/virlib.txt
I agree, but if it all works together to replicate as a result of its own actions it is a virus (and/or a worm).
They get fuzzy by way of misinformation and that is why I attempted to provoke Zvi to add substance to his statement.
When writing about "modern computer viruses" I can see his point in not classifying simple overwriters as such, but
to state outright that they are not viruses at all is misleading.
His condescending attitude coupled with ad-hominem remarks did little to bolster his side of the discussion. I thought
he would be more capable than that.
Z
Zvi Netiv
fluidly unsure said:
The term "companion virus" was coined exactly because the term "virus" plain
didn't fit. A true companion virus is one that qualifies for virus, but for the
entire set of files, host and companion.
What's fuzzy in there?
Regards, Zvi
Z
Zvi Netiv
Roger Wilco said:
[ Pseudo-learned jabber snipped ]
Then they do not even begin to qualify for "companion virus".
I am not one of Bontchev's admirers but since you brought his paper about
maintaining a virus collection, then let's examine what it says about
non-viruses and replication. The quoted text below is from that paper:
Implementation: REGEDIT, when "infected" by an overwriter becomes a Trojan by
the name of REGEDIT, by definition. When the REGEDIT Trojan is run, then it
will create further Trojans, by overwriting other programs, that will become
Trojan on their own, say WORDPAD, or MSCONFIG, and so on ... Each generation on
its turn qualifies to the definition of Trojan, and is therefore a non-virus by
Bontchev's own definition, since it's a Trojan. But wait, there is more to it,
coming next.
Note the phrasing *attach itself to other programs*. The above is interesting,
because what it actually says is exactly the same as the last part of the
definition that I use, i.e. "The infected hosts inherit the replication ability
of the affecting virus, in addition to maintaining the original functionality of
the host program or file." Bontchev further explains what he means in the
above, as follows ...
This is the same as in my formulation, but in less comprehensible language to
the layman.
To summarize it for you: Overwriters aren't viruses by Bontchev's standards
because a) they are Trojans and can't simultaneously be both, and b) They do not
attach themselves properly to the attacked files.
Therefore, in order for computer code to qualify for "virus" it musts be able to
produce functional copies of itself into host files, an infected file must
inherit the replication ability of the parent infector, and it must preserve the
original functionality of the host. QED.
Who is misleading / misinforming now? ;-)
Zvi