Results 1 to 17 of 17

Thread: Idea: Combine Compression & Encryption

  1. #1
    Member
    Join Date
    Feb 2009
    Location
    M?nchen, Germany
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Idea: Combine Compression & Encryption

    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

  2. #2
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    Strong algorithms like CM with a custom model (probably designed for encryption) for sure will make decryption not possible...

  3. #3
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    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.

  4. #4
    Member
    Join Date
    Feb 2009
    Location
    M?nchen, Germany
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by m^2 View Post
    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

    Quote Originally Posted by m^2 View Post
    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.

  5. #5
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by dirks View Post
    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.

  6. #6
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.

  7. #7
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by encode View Post
    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.

  8. #8
    Member
    Join Date
    Feb 2009
    Location
    M?nchen, Germany
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts
    (Somehow derailed thread - well, anyway: )

    Quote Originally Posted by encode View Post
    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.

    Quote Originally Posted by m^2 View Post
    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.
    Last edited by dirks; 10th February 2009 at 21:40. Reason: Quoted too much

  9. #9
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by dirks View Post
    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...


    Quote Originally Posted by dirks View Post
    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.

  10. #10
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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...

  11. #11
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    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

  12. #12
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by Shelwien View Post
    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.

  13. #13
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    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

  14. #14
    Member
    Join Date
    Feb 2009
    Location
    M?nchen, Germany
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by Shelwien View Post
    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?

    Quote Originally Posted by Shelwien View Post
    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.

  15. #15
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts
    > 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.

  16. #16
    Member biject.bwts's Avatar
    Join Date
    Jun 2008
    Location
    texas
    Posts
    449
    Thanks
    23
    Thanked 14 Times in 10 Posts
    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.

  17. #17
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Quote Originally Posted by biject.bwts View Post
    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.

Similar Threads

  1. Idea for raising compression efficiency on disk images
    By Mexxi in forum Data Compression
    Replies: 10
    Last Post: 18th February 2010, 05:56
  2. Compression idea: Base conversion
    By Nightgunner5 in forum Data Compression
    Replies: 8
    Last Post: 30th October 2009, 07:58
  3. Idea to make new site about data compression
    By Piotr Tarsa in forum Data Compression
    Replies: 1
    Last Post: 14th August 2009, 20:22
  4. XOR encryption
    By encode in forum Data Compression
    Replies: 12
    Last Post: 16th March 2009, 10:49
  5. Swap Encryption
    By encode in forum Data Compression
    Replies: 4
    Last Post: 28th October 2008, 16:55

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •