Re: Why not a changeling?

[11a () GMX NET (Bluefish)]

> > In case 2, the code can be written so that it will be somewhat close to
> > what some "legal" software does. Therefor, new virusscanners often rely on
> > decoding the virus and then checking the contest of the encrypted
> > software.
>   By this I guess that you mean that the virusscanner have the ability to
> decode jumptables and chained jumps to a sequntial code and then do the
> final pattern matching?

As it's an pre-defined algorithm, it's obviously not foolproof. I did some
research [for *school*, I don't code viruses] regardning virusscanners
abilities to detect viruses. This was 2 years or more back, so the facts
may have changed now.

What I did was to access memory in a *very* undocumented way, which AFAIK
never has been used by any virus in the wild (chances is that now has
been, because I excanged ideas with a real viruscoder, it would be hard
to get all the information you need for such research otherwise)...

Anyway, I found out that simply doing memory access in a new way is enough
to break almost every virusscanner. I could actually use NOT(x) encryption
to fool virusscanners, as long as I didn't use a standarized way to get
data.  *But* this was not enough to fool Dr. Solomon, so it obviously is
coded to be able to deal with methods not priviously known. However, it's
heauristics search is weak, or rather *very* weak, so it is (or at least
was) very easily fooled anyway.

To sum up, it took about a day to take a virus and make it undetectable
with all existing virusscanners. That was from someone with quite little
prior experince of such coding. Since I learned it was *that* easy to fool
them, I do not feel that AV tools provide any security. And given the
speed of e-mail worms we've seen, unless your virusscanner is updated
twice a day it won't help much.

The 'problem' is it is easy to make the encryption polymorphic. But to
make things like memory access polymorphic is hard (basicly because there
are less ways to do it). And to make generic decryptor for virusscanners
isn't hard either. So the trick must be determin if you have found a
decryptor within the binary. My researched proved that a little
inventivness can overcome this, but fortunatly AV will be able to support
a new algorithm a few day after they learned about it.

>   Once again, please forgive me for missing this out. In my defence I
> would like to point out that the latest MS virus, AFAIK, rendered havoc
> with a static payload which had the ability to change the subject and mime
> header "randomly". Compared to a totally morphing virus this is childs
> play.

Uhm. Yes. But todays trend is that the problem is email viruses, and an
advanced morphing executable is pointless, a normal executable will do
nicely. As long as it is written in a highlevel language (C, Pascal,
Basic) it is not likely to be found by any generic virusscanner.

A morphing scriptvirus would be intresting. Then we would most likely end
up seeing generic searches for scripts as well.

>   If this is the case, then it's maybe time to revoke some of the old
> techniques just to prove that fighting the symptoms of the problem isn't
> the right approach, but rather to cure the problems.

Agree.

But what is the cure? To ban insecure usage (such as sending executables
via email, and keeping executables writable by others than administrators)
is a great idea. But companies doesn't seem to use the available controls
enough, and users seems to happily ignore security policies.

And AV tools... *argh*. Easily fooled, thus must be updated all the time
to have any chance to defeat the email viruses.

..:::::::::::::::::::::::::::::::::::::::::::::::::..
     http://www.11a.nu || http://bluefish.11a.nu
    eleventh alliance development & security team