CryptDecode with modifier CRYPT_ARCH_ZIP - How to use? - page 8

New comment
 
Mikalas:
I've tried it - it doesn't work :(

I understand that CryptDecode uses CRC32? - If so, you can take the CRC32 hash from the archive and slip it into the end of the packed array:

struct ZIP_HEADER
{
  ...
  ushort last_mod_date;
  uint   crc_32;            // Берем это число и помещаем его в конец массива, который нужно распаковать
  uchar  ll_crc;
  ...
};
Z.I. Now I read that hash is an optional attribute and in some cases can be filled with zeros.
 

No, not CRC32, Adler32

(they corrected the text, and they corrected it and I corrected it - reread )

I wrote, it doesn't work!!!!!

 
Mikalas:

No, not CRC32, Adler32

(they've corrected the text, re-read it)

I wrote, it doesn't work!!!!!

Right:

Mikalas:

... and CRC32 from ZIP archive I pasted - it doesn't unpack :(

 
Mikalas:

Thank you.

ZIP without 4 bytes and CRC32 from ZIP archive is not unpacked :(

Vasily, our idea will not work.

Unless, of course, the guys from MQ will meet us halfway and add a flag in

functionCryptDecode(CRYPT_ARCH_ZIP, data, key, result,NO_READ_CRC) ;

or take CRC32 from the ZIP file:

CryptDecode(CRYPT_ARCH_ZIP, data, key, result,USE_CRC_FROM_ZIP) ;

You don't have to add a flag. It's enough to change CryptDecode so that it accepts the CRC code, if it exists. If it's missing and the code field is filled with zeros, no CRC code is used, that's it. Also not every archive can contain hash:

Sometimes it is impossible to calculate data at the time of writingLocalFileHeader, thenzeros are written tocrc32,compressedSize anduncompressedSize, thethird bit ingeneralPurposeBitFlag is set to one and afterLocalFileHeader is added a structure likeData descriptor.

http://blog2k.ru/archives/3391

 
C-4:

There is no need to add a flag. Simply change CryptDecode so that it accepts the CRC code, if there is one. If it does not exist and the code field is filled with zeros, the CRC code is not used, that's it. Also not every archive can contain hash:

I do not know how MQ implemented the function, so I made a few suggestions

( maybe with a flag it will be easier for them to do)

 
Dear MQ! Please give us an answer. Could you make hash matching optional?
 

That would be very nice.

Quick access to a large number of files in a ZIP archive!

A small database with quick access to files - super!

Open ZIP - make a correspondence table and "race" through the offsets.

 

... They must be thinking.

They must be surprised, that local craftsmen will find such unexpected use forCRYPT_ARCH_ZIP.

Mikalas:

That would be very nice.
Quick access to a large number of files in a ZIP archive!
Small DB with fast access to files - super!
Open ZIP - make a table of matches and "race" through the offsets.

+100 Archiving is very useful. With full preservation of content control by MQ, of course.

 
C-4:

... They must be thinking.

They must be surprised, that local craftsmen will find such unexpected use forCRYPT_ARCH_ZIP.

+100 Archiving is very useful. With full preservation of MQ's content control, of course. No exe and executable files inside the archive should be.

Vasiliy!

It doesn't matter if there is an EXE or not!

I can "build" an executable from seemingly unremarkable files,

by adding or modifying bytes.

You don't have to use ZIP to do that!

As long as we can download and save files, making an EXE is a piece of cake!

 
Mikalas:

Vasiliy!

It doesn't matter if there is an EXE or not!

I can "build" an executable file from seemingly unremarkable files!

You don't have to use ZIP for that!

As a matter of fact, yes. It is possible to encrypt an executable file so that it is no different from a random set of bytes.
12345678910
New comment
Reason: