WinXP + Zip AES = not supported?

[MaxX]

Just noticed today with my TC 10 and Win XP.

Todo:

{A}
1. Pack any zip (internal TC's function) with any AES encryption on PC with Win8.1.
2. Try to unpack zip on PC with WinXP
3. See message "Pack method not supported...."

{B}
1. Select any file (on PC with WinXP), Alt+F5
2. Select ZIP with any AES
3. See message: "Error creating ZIP! Function not supported!"

Is that a bug, or TC needs any absent in XP function?

[Usher]

Works for me in Windows XP.

[petermad]

Same here, both (A) and (B) works fine for me under Windows XP sp3 32bit (Home Edition).

2MaxX
Check that you have the correct WCMZIP32.DLL (md5 = 0f907654c10f3f624e0677691c46578c)

[MaxX]

2petermad
Tested on both 10.0 and 10.5 beta7 from original installer by defaults. Clear XP on VirtualBox with disk nudo. Still reproducible.

[sqa_wizard]

Just a hit in the dark to determine your difference: Do you use unicode filenames?
Check your settings at wincmd.ini

ZipUnicode=0 Determines how to pack Unicode names to ZIP archives:
0: Ask every time a Unicode name is encountered
1: Store Unicode names as UTF-8 (Pkzip 4.5/Winzip 11.2 method)
2: All as UTF-8 if at least one contains Unicode
3: All as UTF-8 if at least one contains non-English characters
4: Store Unicode name in extra field (Info-Zip method)
5: Store all names containing non-English in extra field
6: Store Unicode characters as '?'

[MaxX]

Just with blank wincmd.ini, fresh install TC on clear XP. Looks like a problem with used encryption dll's or elsewhere.
The same clear fresh TC in Win 8.1 or Win 10 works fine.

[Dalai]

Which Service Pack does your XP use?

Regards
Dalai

[MaxX]

Last available clear XP Pro SP3 x86 Rus without any updates.

[Dalai]

2MaxX
Did you test files that have only ASCII characters in their name?

Regards
Dalai

[MaxX]

And 8.3 too. No difference.

[Usher]

Last available clear XP Pro SP3 x86 Rus without any updates.

No updates - no AES.
I suppose that TC uses system cryptography libs. Support for AES was added to XP only in 2015 (optional update KB3055973), and fixed in 2016 (security update KB3081320). Later MS added support for TLS 1.2 in Windows XP POSReady/Embedded.

[Dalai]

2Usher
I just created an AES-256 encrypted ZIP archive with TC (8.52a and 10.0) in an XP SP3 VM without any further updates, and it worked without any issues.

Apart from that, TC's history.txt tells us the following:

Code: Select all

28.06.16 Fixed: AES encryption in ZIP not working on Windows NT/2000 because the certificate of the wcmzip32.dll couldn't be verified any more (SHA256) (32)
25.06.08  Added: Use only old ZIP2.0 encryption and do not support AES if old ZIP crypto dll present
15.06.08  Added: Built AES-CBC encryption+decryption into wcmzip32.dll in preparation for TC 7.5
28.05.08  Added: Internal AES encryption in ZIP files (compatible with WinZIP 9.0 and newer)

TC doesn't need any external DLLs to create or unpack AES encrypted ZIP archives because it ships with the DLL required for it. And it also works on Windows 2000 to create such archives (also just tested this successfully). So, the question is, why it doesn't work in MaxX's case.

2MaxX
I suggest to pack the C:\boot.ini file to an archive on the local disk with a simple password like "a" or "foobar". For me this works. If TC would ship with a checksum file containing the checksums for its files, a verification of these files would be really easy. Well, checking the signature of TC's setup file and WCMZIP32.zip is a start, I guess.

Regards
Dalai

[ghisler(Author)]

Total Commander uses the file wcmzip32.dll to encrypt/decrypt with AES. Since the password is sent to the dll, Total Commander verifies the signature of the file wcmzip32.dll before loading it to prevent password stealing by an injected dll.

There may be something wrong with your certificate store, so TC cannot verify the signature of wcmzip32.dll.
Please try this:
1. Go to the Total Commander directory
2. Press Alt+Enter on wcmzip32.dll
3. Click on the tab "Digital signatures"
4. Double click on the name of signer (Ghisler Software GmbH)
-> It should show "The digital signature is OK"
5. Click on "View Certificate", then "Certification path"
-> it should show the following certificates:
Verisign
--Verisign Class 3 Code Signing 2010 CA
----Ghisler Software GmbH

You should see there if anything is wrong.

[MaxX]

23e3b9e5b63cf0f34e7b3242acea3e5b01fa8e0b *WCMZIP32.DLL
just original from 10.0 installer version.

https://i.ibb.co/HYV0wsm/Virtual-Box-XP-30-05-2022-16-53-30.png
https://i.ibb.co/RPjnL2H/Virtual-Box-XP-30-05-2022-16-53-48.png

[Dalai]

The end certificate might be valid, but I guess that TC or the system must be able to validate the whole certificate chain. On my systems this is the case. You might want install the Root certificates provided by Microsoft's own rootsupd.exe. Since MS long removed this update file from their servers, you need to download it from a different location, e.g. this one: http://woshub.com/updating-trusted-root-certificates-in-windows-10/#h2_7

Note that executing this file doesn't provide any feedback, but you can see its effect in Windows certificate store (certmgr.msc). Also note that the file isn't signed in any way, but I have successfully compared it to a file on my drive (which is known to be from MS).

If you don't trust the download, or don't want to flood your certificate store with unnecessary certificates (rootsupd.exe contains a LOT of certs), you can also try to find the VeriSign Class 3 Public Primary Certification Authority - G5 certificate and just manually install that one certificate into the certificate store.
Possible download locations (I prefer the first one): https://success.trendmicro.com/dcx/s/solution/1104241-Updating-the-VeriSign-DigiCert-USERTrust-RSA-certificate-on-Deep-Security-and-Cloud-One-Workload-Security?language=en_US
https://ssl-tools.net/subjects/b9e9b287028503f8eca5fb42e13e0f49c72426e2

Regards
Dalai