CryptDecode con modificatore CRYPT_ARCH_ZIP - Come usare? - pagina 8

Nuovo commento
 
Mikalas:
Ho provato - non funziona :(

Ho capito che CryptDecode usa CRC32? - Se è così, potete prendere l'hash CRC32 dall'archivio e infilarlo alla fine dell'array compresso:

struct ZIP_HEADER
{
  ...
  ushort last_mod_date;
  uint   crc_32;            // Берем это число и помещаем его в конец массива, который нужно распаковать
  uchar  ll_crc;
  ...
};
Z.I. Ora ho letto che l'hash è un attributo opzionale e in alcuni casi può essere riempito di zeri.
 

No, non CRC32, Adler32

(hanno corretto il testo, e l'hanno corretto e io l'ho corretto - rileggete )

Ho scritto, non funziona!!!!!

 
Mikalas:

No, non CRC32, ma Adler32

(hanno corretto il testo, rileggilo)

Ho scritto, non funziona!!!!!

Giusto:

Mikalas:

... e CRC32 dall'archivio ZIP che ho incollato - non si scompatta :(

 
Mikalas:

Grazie.

ZIP senza 4 byte e CRC32 dall'archivio ZIP non viene scompattato :(

Vasily, la nostra idea non funzionerà.

A meno che, naturalmente, i ragazzi di MQ non ci vengano incontro a metà strada e aggiungano una bandiera in

funzioneCryptDecode(CRYPT_ARCH_ZIP, dati, chiave, risultato,NO_READ_CRC) ;

o prendere CRC32 dal file ZIP:

CryptDecode(CRYPT_ARCH_ZIP, dati, chiave, risultato,USE_CRC_FROM_ZIP) ;

Non è necessario aggiungere una bandiera. È sufficiente cambiare CryptDecode in modo che accetti il codice CRC, se esiste. Se manca e il campo del codice è riempito di zeri, non viene usato alcun codice CRC, tutto qui. Inoltre non tutti gli archivi possono contenere hash:

A volte è impossibile calcolare i dati al momento di scrivereLocalFileHeader, allora si scrivono deglizeri acrc32,compressedSize euncompressedSize, ilterzo bit ingeneralPurposeBitFlag è impostato a uno e dopoLocalFileHeader si aggiunge una struttura comeData descriptor.

http://blog2k.ru/archives/3391

 
C-4:

Non c'è bisogno di aggiungere una bandiera. Basta cambiare CryptDecode in modo che accetti il codice CRC, se ce n'è uno. Se non esiste e il campo del codice è riempito di zeri, il codice CRC non viene utilizzato, tutto qui. Inoltre non tutti gli archivi possono contenere hash:

Non so come MQ abbia implementato la funzione, quindi ho dato alcuni suggerimenti

(forse con una bandiera sarà più facile per loro fare)

 
Caro MQ! Per favore, ci dia una risposta. Si potrebbe rendere facoltativo l'abbinamento dell'hash?
 

Sarebbe molto bello.

Accesso rapido a un gran numero di file in un archivio ZIP!

Un piccolo database con accesso rapido ai file - super!

Aprire ZIP - fare una tabella di corrispondenza e "correre" attraverso gli offset.

 

... Staranno pensando.

Devono essere sorpresi che gli artigiani locali trovino un uso così inaspettato perCRYPT_ARCH_ZIP.

Mikalas:

Sarebbe molto bello.
Accesso rapido a un gran numero di file in un archivio ZIP!
Piccolo DB con accesso veloce ai file - super!
Aprire ZIP - fare una tabella delle corrispondenze e "correre" attraverso gli offset.

+100 L'archiviazione è molto utile. Con la piena conservazione del controllo dei contenuti da parte di MQ, naturalmente.

 
C-4:

... Staranno pensando.

Devono essere sorpresi che gli artigiani locali trovino un uso così inaspettato perCRYPT_ARCH_ZIP.

+100 L'archiviazione è molto utile. Con la piena conservazione del controllo dei contenuti di MQ, naturalmente. Nessun exe e file eseguibile all'interno dell'archivio dovrebbe essere.

Vasiliy!

Non importa se c'è un EXE o no!

Posso "costruire" un eseguibile da file apparentemente irrilevanti,

aggiungendo o modificando dei byte.

Non c'è bisogno di usare ZIP per farlo!

Finché possiamo scaricare e salvare i file, fare un EXE è un gioco da ragazzi!

 
Mikalas:

Vasiliy!

Non importa se c'è un EXE o no!

Posso "costruire" un file eseguibile da file apparentemente irrilevanti!

Non c'è bisogno di usare ZIP per questo!

In effetti, sì. È possibile criptare un file eseguibile in modo che non sia diverso da un insieme casuale di byte.
12345678910
Nuovo commento
Motivazione: