There are a lot of assumptions baked into your question, so I don't think a general answer is possible, but I'll try to explore it a little.
I assume you have encrypted the archive using the standard "password-protected" mode that's built-in to zip tools. I'm not an expert on the zip file format, but it looks like there is no standard for which cipher to use;
RC4 (stream cipher) and
AES (block ciphers) are all common choices. To answer this question, we'll need to explore how encryption ciphers work.
RC4 is a stream cipher, which according to wikipedia, works like this:
A stream cipher makes use of a much smaller and more convenient key such as 128 bits. Based on this key, it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the one-time pad.
I have never studied
RC4, but my understanding is that encryption is done one byte at a time by XOR'ing one byte of the keystream with one byte of the plaintext.
This means that, assuming you know the key, the 5 bytes you've mangled will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine.
Block ciphers work totally differently from stream ciphers. It's a bit harder to explain, but we can look at the most common mode: cipher block chaining with this image from wikepedia:
The important thing to note is that cipher text for a given block depends on the cipher text of that block and the block before it. So this largely behaves the same as stream ciphers in that the bytes you mangled (and one block after it) will decrypt mangled and be unrecoverable, but all bytes before it and all bytes after it will decrypt fine. (thanks @dave_thompson_085)
Brute-forcing the password
So generally speaking, unless you reverse the mangling, the bytes you mangled will be unrecoverable, but the bytes before and after will decrypt fine (whether the bytes after decompress fine is a different story, thanks @dave_thompson_085, but since compression is not designed for security, I'm sure a good forensic analyst could get information out of it).
In the context of an attacker brute-forcing the encryption key (ie the password), encrypting the zip header actually makes their job easier: all they need to do is try decrypting with random passwords until the first few bytes decrypt to a valid zip header (or the file header of the first file in the archive decrypts to a valid file header).
What problem are you trying to solve?
The XY Problem
Going back a step, it sounds like you want to enhance ZIP's password-based encryption and possibly add plausible deniability by inventing an obfuscation technique - or if you want to be able to reverse it, by inventing an encryption technique.
As @TTT colourfully put in a comment, I'm not sure you're going to be able to convincingly hack plausible deniability onto ZIP's encryption system.
As for enhancing it, why not just use
AES and throw away (or don't throw away) the key? Or, why not skip using ZIP's terrible password-based encryption altogether, and just run the
.zip file through
openssl or some other better more modern tool that supports public-key encryption? (hint: native zip encryption was a badly-done hack when it was written, and now it's out-of-date hack. If you want proper security, then run your zip file through a proper tool rather than trying to salvage the hack).