Idea: Combine Compression & Encryption

[dirks]

Hi all,

I got this rough idea by observing this forum: To combine compression & encryption to counter cryptoanalysis, esp. watermarking attacks.

This would be based on encryption on filesystem (or device) level, not file level.

When you put a file on such a filesystem, it is first compressed, even if the result is bigger than the original, and then encrypted. This should throw all watermarking attacks out of the window, given that the compressing stage can deal with big files: Even if the result is bigger, the compression changes the data and (more important) moves all offsets within the file, so the encryption stage gets input data that is not repeating itself at certain distances that can be aligned to filesystem blocks borders. In the best case, the poisened file would be shrunk to something that is not recognizable anymore even before the encrytion stage comes into play.

With such an underlying compression stage, simple algorithms for initialization vectors like "IV= block number" would be safe.

Can anybody see a flaw in here?

Best regards
dirks

[encode]

Strong algorithms like CM with a custom model (probably designed for encryption) for sure will make decryption not possible...

[m^2]

Yeah, some time ago I've been thinking about it as a possible way to hide a virus:
Step 1. Make a generic exe packer with PAQ8-like speed.
Step 2. Make people use it. If it's popular enough, AVs won't flag all your executables as viruses. This part is hard.
Step 3. It's too time consuming for AVs to unpack files inside=>put whatever you want in there.

[dirks]

Step 2. Make people use it. If it's popular enough, AVs won't flag all your executables as viruses. This part is hard.

Indeed... Making people use a strong but slow compressor might be the hard(est) part

Step 3. It's too time consuming for AVs to unpack files inside=>put whatever you want in there.

Hmm, they don't need to care, It's the user's PC that must do the hard work of unpacking --> the user will define an exception for these files or swith off a whole AV stuff.

[m^2]

Indeed... Making people use a strong but slow compressor might be the hard(est) part


Hmm, they don't need to care, It's the user's PC that must do the hard work of unpacking --> the user will define an exception for these files or swith off a whole AV stuff.

AV A makes a full scan in one hour. AV B needs a week straight. Which one would you choose?
Possibly it would get optional support, but definitely off by default.

But anyway...I guess that 2) is the showstopper. And I think it's good, really I'm not a fan of crapware.

[encode]

Actually it is possible to fool AV by:
1. Some hardware related stuff. i.e. the decryption key generation is done using some extra CPU instructions, unknown to AV.
2. Expensive decryption key generation. Some AV may cancel such complex task, some may not.

[m^2]

Actually it is possible to fool AV by:
1. Some hardware related stuff. i.e. the decryption key generation is done using some extra CPU instructions, unknown to AV.
2. Expensive decryption key generation. Some AV may cancel such complex task, some may not.

You have to make your compressor / encryptor popular, otherwise they'll just block your stub and mark positive after a millisecond.
If you'll succeed with making it popular, AV makers will add a specific unpacker in case 1); 2) is not significantly different from using slow CM.

[dirks]

(Somehow derailed thread - well, anyway: )

Actually it is possible to fool AV by:
1. Some hardware related stuff. i.e. the decryption key generation is done using some extra CPU instructions, unknown to AV.
2. Expensive decryption key generation. Some AV may cancel such complex task, some may not.

Hmm, what if the SFX simply asks for a password? And uses the PW to decrypt the rest of its payload, including the virus...
PW-protected RAR-archives are rather common on e.g. rap!dshare.

You have to make your compressor / encryptor popular, otherwise they'll just block your stub and mark positive after a millisecond.

I would remove an AV immediately if it behaves like that. I mean, it could be a commercial SFX with a key that only customers can have, or so.

There was a case in the good ol' usenet days: Someone posted some files with a strange extension, maybe .vio or something similar. Of course nobody could open it. When questions came up, he promised to post a viewer. The next day he did, only that the viewer was a trojan and/or installed a virus.

[m^2]

Hmm, what if the SFX simply asks for a password? And uses the PW to decrypt the rest of its payload, including the virus...
PW-protected RAR-archives are rather common on e.g. rap!dshare.

Yes, people are stupid enough to open such archives and it works.
Some use Thinstall, crapware is very hard to detect inside, program looks like it's clean, but in background it installs something...

I would remove an AV immediately if it behaves like that. I mean, it could be a commercial SFX with a key that only customers can have, or so.

If a stub is used only by a single virus, then it goes to database instantly and that's correct IMO. That's why I said that it needs popularity first.

[encode]

Some time ago I did my own EXE-packer/protector. In one day it was added to AV databases. So I drop an idea about writing such stuff...

[Shelwien]

The solution against AVs is known since long time ago,
and its metamorphism (a virus should be able to compile
a randomized version of itself - its rather easy as there're
many ways of doing the same things with different instructions).
But people became lazy these days, and nobody gives them
a metamorphic compiler component for VB, so they need new
exe-compressors for their trojans

[m^2]

The solution against AVs is known since long time ago,
and its metamorphism (a virus should be able to compile
a randomized version of itself - its rather easy as there're
many ways of doing the same things with different instructions).
But people became lazy these days, and nobody gives them
a metamorphic compiler component for VB, so they need new
exe-compressors for their trojans

Sounds cool. But there are 2 kinds of people who write crapware nowadays:
- script kiddies, it's too hard for them
- businessmen. It's too costly to be worth the investment.

[Shelwien]

Well, there's actually one kinda metamorphic compiler available - IntelC.
It has plenty of options affecting the generated code, and then there're
profiling files, stats in which can be generated randomly.
Alas, its kinda too big and slow for a virus

[dirks]

Well, there's actually one kinda metamorphic compiler available - IntelC.
It has plenty of options affecting the generated code, and then there're
profiling files, stats in which can be generated randomly.

Wouldn't there still be certain pieces of code in common that could be used for signatures?

Alas, its kinda too big and slow for a virus

Indeed... Hmm, how about this: The virus looks if IntelC is installed, if yes, it recompiles itself and spreads the new version. If not, it tries to contact the server of it's creator (taking the opportunity to submit credit card numbers and passwords) and tries to download a new copy from there.

Another idea: Every 2nd command is JMP and skips a few bytes. These bytes are filled up by random data. This would make the virus several times bigger than needed and somewhat slower, but much less than including a full compiler. Hard chance to find signatures, short of an unusually high amount of JMPs...


By the way, I vaguely remember that some some security expert once demonstrated that it's quite easy to put some code in the source of GCC that makes a GCC that is compiled from this source so that every execuable created by it contains a virus/trojan/whatever.

[Shelwien]

> Wouldn't there still be certain pieces of code in common
> that could be used for signatures?

Yes, but that can be considerably improved by not using CRT,
and in this case, there's a lot of apps compiled the same way

> Alas, its kinda too big and slow for a virus

> Indeed... Hmm, how about this: The virus looks if IntelC
> is installed, if yes, it recompiles itself and spreads the
> new version.

Well, finding a specific version of IntelC installed on a
compromised machine is highly unlikely (and "any" IntelC version
may not be able to properly compile a non-trivial program - there's
a lot of bugs).
Also, a minimal IntelC rip would take at least 2M in archive,
and it would be very problematic to run it in background unnoticed.

> Another idea: Every 2nd command is JMP and skips a few
> bytes. These bytes are filled up by random data. This
> would make the virus several times bigger than needed and
> somewhat slower, but much less than including a full
> compiler. Hard chance to find signatures, short of an
> unusually high amount of JMPs...

That's trivial and won't work even against the existing AVs,
which look for a trace patterns.
And polymorphism (when random decryptor is generated for
each instance, but main part after decryption is static)
doesn't work anymore either.
But there's no solution for real metamorphism, where
any fixed patterns are intentionally avoided, in code or data.
http://en.wikipedia.org/wiki/Metamorphic_code

> By the way, I vaguely remember that some some security
> expert once demonstrated that it's quite easy to put some
> code in the source of GCC that makes a GCC that is
> compiled from this source so that every execuable created
> by it contains a virus/trojan/whatever.

Its easy enough to do the same with any compiler, even availability
of its source is not necessary.
But there's not much sense to target developers only.
And anyway these days real viruses (which infect a lot of executables)
are not fashionable or something.

[biject.bwts]

I think a lot of stuff that checks for viruses is junk. Some day they will no longer search for viruses. To get your code used you may have to submit it to some agency where they will create hash that virus checkers use. If the program not in the data base or the length and hash don't match it will be assumed to be a virus

Even stuff I wrote years ago is be flagged as a virus

http://spywarefiles.prevx.com/RRDHJE...TT19U.EXE.html

Its just my old encryption program.

[m^2]

I think a lot of stuff that checks for viruses is junk. Some day they will no longer search for viruses. To get your code used you may have to submit it to some agency where they will create hash that virus checkers use. If the program not in the data base or the length and hash don't match it will be assumed to be a virus

Even stuff I wrote years ago is be flagged as a virus

http://spywarefiles.prevx.com/RRDHJE...TT19U.EXE.html

Its just my old encryption program.

One of my programs reached 80% @ Virustotal.
And I can tell you that usually customer support in AV companies is even worse than the junk they make.