CryptDecode con modificador CRYPT_ARCH_ZIP - ¿Cómo utilizarlo? - página 7

[Mikhail Filimonov]

¡Vasiliy!

¿Obtuviste una respuesta?

[Vasiliy Sokolov]

Todavía no. Creo que leerán este hilo y responderán aquí mismo. Esperando.

[Ilyas]

Por favor, forme una lista clara de preguntas.

La función trabaja con un búfer de datos separado, no con ficheros de archivo.
Se utiliza el algoritmo deflate, y la función fue introducida para ser utilizada en WebRequest, en caso de que la respuesta sea cosechada por el servidor.

El parámetro clave no se utiliza.

[Mikhail Filimonov]

mql5:
Por favor, forme una lista clara de preguntas.

La función trabaja con el búfer de datos individual, no con los ficheros de archivo.
Se utiliza el algoritmo deflate, y la función fue introducida para ser utilizada en WebRequest, en caso de que la respuesta sea frita por el servidor.

El parámetro clave no se utiliza.

¡Buenas tardes!

Una pregunta, ¿qué significan los 4 bytes al final deCryptEncode() con el parámetro CRYPT_ARCH_ZIP?

Si se utiliza el algoritmodeflate, también se pueden descomprimir archivos ZIP sabiendo cómo se obtienen esos 4 bytes.

( Ejemplo de descompilador ZIP en la página 6)

[Ilyas]

Mikalas:

¡Buenas tardes!

Una pregunta, ¿qué significan los 4 bytes al final deCryptEncode() con el parámetro CRYPT_ARCH_ZIP?

Esto es para el control de integridad, ADLER32 o CRC32 (depende de los parámetros de archivo (Adler32 se utiliza siempre en MQL) y puede faltar) de los datos de origen

[Alexandr Bryzgalov]

¿y los 2 primeros bytes?

[Mikhail Filimonov]

sanyooooook:
¿pero los primeros 2 bytes?

Lo más probable es que sí:

0x78 - signo de los datos empaquetados

0x5E - método de compresión

Estos bytes no cambian (lo he comprobado)

[Mikhail Filimonov]

mql5:
Esto es para el control de integridad, ADLER32 o CRC32 (puede no existir) de los datos de origen

Gracias.

ZIP sin 4 bytes y CRC32 del archivo ZIP no se descompone :(

Vasiliy, nuestra empresa no funcionará

A menos que, por supuesto, los chicos de MQ se encuentren con nosotros a mitad de camino y añadan una bandera a

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

o tomar el CRC32 del archivo ZIP:

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

struct ZIP_HEADER
{
  uint   sign;
  ushort a_version;
  ushort bit_flag;
  ushort comp_method;
  ushort last_mod_time;
  ushort last_mod_date;
  //uint   crc_32;
  uchar  ll_crc;
  uchar  lh_crc;
  uchar  hl_crc;
  uchar  hh_crc;
  uint   pack_size;
  uint   unpack_size;
  ushort fn_len;
  ushort extr_field_len;
};

[Vasiliy Sokolov]

Mikalas:

Gracias.

ZIP sin 4 bytes y CRC32 del archivo ZIP no se descompone :(

Vasily, nuestra idea no funcionará.

A menos que, por supuesto, los chicos de MQ se encuentren con nosotros a mitad de camino y añadan una bandera en

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

¿Podemos tratar de introducir cuatro bytes vacíos?

mql5:
Esto es para el control de la integridad, ADLER32 o CRC32 (depende de los parámetros de archivo (MQL siempre utiliza Adler32) y puede que no) de los datos de origen

[Mikhail Filimonov]

C-4:

¿Tal vez intentar deslizar un cuatro bytes vacío?

He probado sin los últimos 4 bytes y con los últimos 4 bytes "0" - no funciona :(