Access violation when adding/editing file in zip file

[bcool]

Cannot post links to reproduce, will try in second post.

[HolgerK]

<Ctrl+C> when the focus is in the error dialog.
<Ctrl+V> directly as text in your post.

Would be nice if you add some details: TC-version, OS-Version, used editor,...

Regards,
Holger

[bcool]

I did all that, made screenshots, steps to reproduce, added example zip file. Then I was unable to post because I'm a new member and not allowed to post links. So I sent it to tc support email address instead.

Copy/paste in error dialog does not work by the way.
tc version = 7.04a, os = winxp sp2, editor = notepad, zipcreator = sharpziplib with zip64 extensions enabled.

[HolgerK]

Copy/paste in error dialog does not work by the way.

Should normally works always with the standard error dialogs used by TC when an exception is caught.

Sample:

Code: Select all

---------------------------
Total Commander
---------------------------
Access violation at address 00000000. Read of address 00000000.
Please report this error to the Author,
with a description of what you were doing when this error occured!
Continue execution?
---------------------------
Yes   No   
---------------------------

So, may be the error dialog is not from TC?


BTW: searching the forum for zip64 I found this:
http://ghisler.ch/board/viewtopic.php?p=146079#146079

The ZIP64 header read function sometimes reads beyond the allocated header buffer and causes an access violation, but this isn't a security problem. I will fix that in TC 7.5

Regards,
Holger

[bcool]

Yes I get the dialog you are describing, however its a standard message box, no copyable text field in it.

Anyway, this discussion is pointless as my hands are tight to provide repro info and details because of annoying forum limitations. This frustrates me, so I will not reply in the next 3 days anymore until I have some decent permissions.

Have a nice day.

[ghisler(Author)]

Unfortunately your bug description is very vague, can't you describe the problem with plain text, please? Address 00000 means that TC tried to call a function which isn't there. Maybe you replaced the new wcmzip32.dll with an older one? The current one should be slightly larger than 81 kBytes.

[HolgerK]

Unfortunately your bug description is very vague, can't you describe the problem with plain text, please? Address 00000 means that TC ...

Sorry, if I maybe mixed up this thread.
My posted Sample was not a reproduction of bcool's problem.

Or did you refer to the description he send by e-mail:

I did all that, made screenshots, steps to reproduce, added example zip file. Then I was unable to post because I'm a new member and not allowed to post links. So I sent it to tc support email address instead.

Regards,
Holger

[ghisler(Author)]

Sorry, I thought that the error dialog which you posted was posted by bcool. I can't say what the error is from his description.

2bcool
Please report your bug by e-mail to support at ghisler dot com. Thanks.

[sqa_wizard]

2bcool: As HolgerK already said: If the error dialog appears, just press Ctrl-C (no text selection needed) and paste it into a text document, thats all ...

[ghisler(Author)]

He has sent me the sample file. The crash is caused by a very unusual file composition, and is present also in older versions of TC. Fortunately there is no data loss, both the old and the updated zip files are there after the crash, and both are readable. The zip was created with a special zip library. I will try to address the problem in a future version.

[ghisler(Author)]

This should actually be fixed now:

20.08.08 Fixed: Access violation (not critical) when trying to modify ZIP archives created with SharpZipLib (due to invalid ZIP64 headers)

[karlchen]

Hello, Christian.

How do we get hold of such a ZIP file having a broken ZIP64 header in order to verify the fix?

Tried to download ZIP files here assuming they should offer ZIP files created using their own SharpZipLib library.

Yet, maybe this assumption was incorrect.

At minimum, neither using T.C. 7.04a, nor using T.C. 7.50 pb5 I have been able to create a nice crash or at least an error message when editing files inside the downloaded ZIP files and repacking them.

Kind regards,
Karl

[ghisler(Author)]

Please get this sample file:
https://plugins.ghisler.com/beta/sample_unicode.zip

When you add ANY file to it with TC 7.5 beta 1-4, the file ú.txt within the archive can no longer be unpacked.

When you add ANY file with TC 7.5 beta 5, ú.txt should still be accessible.

The password is: abcd1234

Note that beta 5 cannot unpack the damaged fil once it's damaged by beta 1-4. If someone has such a damaged zip with data which cannot be recovered, he needs to contact me by e-mail for a solution. It's just the AES header which is missing in the damaged file, so the unpackers do not know the used AES strength (128, 192 or 256) and pack method (deflated, stored).

[karlchen]

Hello, Christian.

Please get this sample file: https://plugins.ghisler.com/beta/sample_unicode.zip

Thanks for providing a testing file. (All tests were carried out on copies of the downloaded file which itself has not been changed at all.)

When you add ANY file to it with TC 7.5 beta 1-4, the file ú.txt within the archive can no longer be unpacked.

Used T.C. 7.5 PB3 and added an (AES256) encrypted file: Problem confirmed.
Neither T.C. 7.50 PB3, nor T.C. 7.50 PB5 could read the file ú.txt any longer.
Adding uncrypted files would not have the desired effect.
No access violation affecting T.C. 7.50 pb3 was experienced, though.
After removing the added AES256 encrypted file from the ZIP archive, the copy was no longer identical to the downloaded original file.

When you add ANY file with TC 7.5 beta 5, ú.txt should still be accessible.

Used T.C. 7.5 PB5 and added an (AES256) encrypted file: No problem occurred accessing the file ú.txt.
T.C. 7.50 pb3 as well as T.C. 7.50 pb5 could access the file.
After removing the added AES256 encrypted file from the ZIP archive, the copy was identical to the downloaded original file again.

This suggests that T.C. 7.50 pb5 works around the corrupted header successfully and that the problem has been fixed.

Kind regards,
Karl

[ghisler(Author)]

Thanks for testing! The original poster has confirmed the fix by e-mail, so I'm moving this to fixed bugs now.