I was playing around with WinZIP today and noticed something and wanted to write it down before I forgot to document it. I still need to do some analysis, but wanted to make it known if it wasn't already.
This has to do with the following WinZIP registry entry: Software Nico Mak ComputingWinZipmruarchives most recently used registry entry.
While writing a new plugin for my python-regparse tool that I released and blogged about yesterday I noticed that my old plugins were not parsing the data correctly. Then I ran a few more well known tools and in one case didn't see some of the entries at all, and in another case saw the entries, but no context was provided.
Here is what a sample entry looks like within:
SoftwareNico Mak ComputingWinZipmruarchives
You will see in the image the MRUList.
01 00 00 00 = The order in, which I did my test was: 01 and 00 with 01 being the second entry, or the "most recently used" one, which would then inherit the last write time of SoftwareNico Mak ComputingWinZipmruarchives (03/08/2015 21:56:56.804 UTC).
Testing MRU entries start getting overwritten when they reach 15 (0 - 14).
Let's look at the following:
0 - REG_SZ C:UsersLabDesktopParent.zip
Then you will see the corresponding xd name (xd0). Let's break it down:
0|ChildFolder1:ChildText1.txt:ChildText2.txt:ChildText3.txt:EXEforsize509440Bytes.exe|5|234285:509440||
0 - Unsure - It's not a 1:1 mapping based on names. ChildFolder1 - Folder I added for reference. ChildText1.txt - File I added for reference. ChildText2.txt - File I added for reference. ChildText3.txt - File I added for reference. EXEforsize509440Bytes.exe - File I added for size reference. 5 - Five files within the Parent.zip 234285 - Unsure what this is. It doesn't match the archived size of Parent.zip. The size of Parent.zip archived is 234,933 bytes (648 byte difference). It doesn't match the unarchived size either. 509440 - Over all size of the files within the Parent.zip unzipped. You will see that it matches the EXE reference, with all other files being 0 Bytes.
0|Parent.zip|1|234933:234933||
0 - Unsure Parent.zip - Name of file 1 - One file. 234933 - Here the sizes match, but in our previous example these two numbers didn't match. There was a 648 byte difference. I'll need to do some more testing to figure this one out. 234933 - Size of Parent.zip
7z gave different results.
0|509440Bytes.exe:ChildText1.txt:ChildText2.txt:ChildText3.txt:ChildFolder_:Paren|6|180814:509440||
0 - Unsure EXEforsize509440Bytes.exe - File for reference ChildText1.txt - File for reference ChildText2.txt - File for reference ChildText3.txt - File for reference ChildFolder - File for reference, but truncated. Paren - Parent.zip (the parent folder) 6 - This time it shows 6. It appears to have counted the Parent folder and also truncated it to Paren. So Parent.zip -> Parent 180814 - Unsure size doesn't match anything (better compression vs. WinZip though) 509440 - Unarchived size
Obviously more testing is necessary.
Anyway, I just wanted to jot this down. If you're simply relying on the output of a tool you're possibly missing some good information. This was a very quick analysis. I hope to get some more time in the next few days to do a more thorough check. Feel free to shoot me an email if you (or know of another source) that has done some of this already. I more or less ignored Google on this one.