CryptDecode com modificador CRYPT_ARCH_ZIP - Como usar? - página 8

 
Mikalas:
Eu tentei - não funciona :(

Entendo que o CryptDecode usa CRC32? - Se for o caso, você pode pegar o hash CRC32 do arquivo e colocá-lo no final do conjunto embalado:

struct ZIP_HEADER
{
  ...
  ushort last_mod_date;
  uint   crc_32;            // Берем это число и помещаем его в конец массива, который нужно распаковать
  uchar  ll_crc;
  ...
};
Z.I. Agora eu li que o hash é um atributo opcional e em alguns casos pode ser preenchido com zeros.
 

Não, não CRC32, Adler32

(eles corrigiram o texto, e eles corrigiram e eu corrigi - reler )

Eu escrevi, não funciona!!!!!

 
Mikalas:

Não, não CRC32, Adler32

(eles corrigiram o texto, releram-no)

Eu escrevi, não funciona!!!!!

Certo:

Mikalas:

... e CRC32 do arquivo ZIP I colado - não desembala :(

 
Mikalas:

Obrigado.

ZIP sem 4 bytes e CRC32 do arquivo ZIP não é desempacotado :(

Vasily, nossa idéia não vai funcionar.

A menos, é claro, que os caras da MQ nos encontrem na metade do caminho e acrescentem uma bandeira em

funçãoCryptDecode(CRYPT_ARCH_ZIP, dados, chave, resultado,NO_READ_CRC) ;

ou tirar CRC32 do arquivo ZIP:

CryptDecode(CRYPT_ARCH_ZIP, dados, chave, resultado,USE_CRC_FROM_ZIP) ;

Não é necessário acrescentar uma bandeira. Basta mudar o CryptDecode para que ele aceite o código CRC, se ele existir. Se estiver faltando e o campo de código estiver preenchido com zeros, nenhum código CRC é usado, é só isso. Também nem todo arquivo pode conter hash:

Às vezes é impossível calcular os dados no momento de escreverLocalFileHeader, entãoos zeros são escritos emcrc32,compressedSize euncompressedSize, oterceiro bit emgeneralPurposeBitFlag é definido como um e depois deLocalFileHeader é adicionada uma estrutura comoData descriptor.

http://blog2k.ru/archives/3391

 
C-4:

Não há necessidade de acrescentar uma bandeira. Basta mudar o CryptDecode para que ele aceite o código CRC, se houver um. Se não existir e o campo de código for preenchido com zeros, o código CRC não é usado, é isso. Também nem todo arquivo pode conter hash:

Não sei como a MQ implementou a função, por isso fiz algumas sugestões

(talvez com uma bandeira seja mais fácil para eles)

 
Prezado MQ! Por favor, dê-nos uma resposta. Você poderia tornar a combinação de haxixe opcional?
 

Isso seria muito bom.

Acesso rápido a um grande número de arquivos em um arquivo ZIP!

Um pequeno banco de dados com acesso rápido aos arquivos - super!

ZIP aberto - fazer uma tabela de correspondência e "corrida" através dos offsets.

 

... Eles devem estar pensando.

Eles devem estar surpresos, que os artesãos locais encontrem tal uso inesperado para oCRYPT_ARCH_ZIP.

Mikalas:

Isso seria muito bom.
Acesso rápido a um grande número de arquivos em um arquivo ZIP!
Pequeno DB com acesso rápido a arquivos - super!
ZIP aberto - faça uma tabela de fósforos e "faça uma corrida" através dos offsets.

O Arquivamento +100 é muito útil. Com total preservação do controle de conteúdo pela MQ, é claro.

 
C-4:

... Eles devem estar pensando.

Eles devem estar surpresos, que os artesãos locais encontrem tal uso inesperado para oCRYPT_ARCH_ZIP.

O Arquivamento +100 é muito útil. Com total preservação do controle de conteúdo da MQ, é claro. Nenhum arquivo exe e executável dentro do arquivo deve ser.

Vasiliy!

Não importa se existe ou não um EXE!

Eu posso "construir" um executável a partir de arquivos aparentemente não notáveis,

adicionando ou modificando bytes.

Você não precisa usar o ZIP para fazer isso!

Desde que possamos baixar e salvar arquivos, fazer um EXE é canja!

 
Mikalas:

Vasiliy!

Não importa se existe ou não um EXE!

Eu posso "construir" um arquivo executável a partir de arquivos aparentemente não notáveis!

Você não tem que usar ZIP para isso!

De fato, sim. É possível codificar um arquivo executável para que ele não seja diferente de um conjunto aleatório de bytes.
Razão: