Hello, I am working on reversing the protection of winzip 8.1 and am curious has anyone else worked on it recently?...what interests me is not really the protection but the manner in which they tried to hide it (really it was funny, it is different from previous versions where routines where out in the open). I have begun to trace it (ollydbg And Ida should marry)?

Any comments would be greatly appreciated

Int21hex

Hello int21hex !

Here's my comment. What is so special about this version of WinZIP? The serial I generated sometime for version 7.0 is still working and I could not find any protection/packer used on it.

What's new in this release? Is the calculated serial destroyed before it's compared with the entered one?

I'm not laughing at you, I just don't see the point in what you're telling us.

The key generation is seemingly the same but what is of interest is that the routines themselves are not there in "plaintext"..have you tried a string search for the normal winzip strings...ie "incomplete or incorrect information" there not there...That is what i meant by the serial routine itself is not of interest...It looks like the code is actually polymorhpic...which i find hard to believe of winzip...this was the reason i wondered if anyone had worked on the latest version to confirm or deny this, I am by no mean anything other than a newbie but still this looks polymorphic to me...The hex dump of the file itself was being rewritten i so i think...I will look at it some more..(at one point it pointed itself to the dosstub and popped that up as a return address.

Hello int21hex !

I looked a bit closer on the english WinZIP v8.1. The problem you have is that the text who tells you that you're using a evaluation version is "plain" ASCII text. You can search for it and use references to it to find locations where the text is somehow used, for example, pushed onto the stack to be displayed in a message box.

But the "Incomplete or incorrect information" text is stored in the the resource section. Therefore it is stored as UNICODE, which means that there is a hexadecimal "0" (00h) between the letters. So if you search for the text you will not find anything because the text is not there in the form you're searching for.

If you use Hex Workshop you can search for UNICODE text and will find the error message. Unfortunately, data from the resource section is not refered by memory addresses, but by Resource IDs. So I suggest you to find a resource editor like Resource Workshop or Studio.

With this tools you can look for the InvalidSerial text and get it's Resource ID. It is a 16-bit positive number. If you are lucky, it is something like 46519 (=B5B7h). Then you can search for a "Push 0000B5B7h" and it's likely that you found the location where the text to be shown in a message box is.

But if you have no luck, the Resource ID is 0, ..., 10 or equally bad. I think you can imagine how often a program uses "Push 000000000h" or similar in the code segment.

If this happens you cannot look for for the InvalidSerial text this way and you should think of an other way to find the right location, maybe by searching for other relevant text or by setting breakpoints in you favourite debugger on APIs used to get text from text-fields, like GetWindowTextA or GetDlgItemTextA. If you look at the API reference you'll find some more of these kind.

I did find the serial routines ...but i will have to take a closer look at how resources are loaded for indeed that would be what has confused me. Thank you greatly for taking the time to verify the statement of a stupid newbie.