An workable solution. But difficult. Wednesday, 10-Feb-99 16:05:05
Hi, Here is a little tutorial to hopefully clear up a few things about 1 way hash functions. The scenario ----->> 1.) Suppose you have a 'password' and all it`s character values added up together came to total of '456'. Now imagine that this value is then added or multiplied or xored etc.. with a magic number '1234' (part of winzip) and produces a result of 5000. This number is then used to encrypt the zip file (And itself '5000' stored somewhere in the zip file). 2.) Knowing the magic number doesn`t help us to decrypt the zip file because the original password is not known. 3.) The original password is not stored anywhere. 4.) The zip file can not be decrypted until the value '5000' has been reached, and it`s impossible to know that '5000' is the value we need to reach in the first place. Using s-ice here is also no good as it is only comparing encypted data with more encrypted data. 5.) So how do we tackle it ??? Well, here goes,..... We implement something that is called a plaintext attack, and it goes something like this : We need to know the first 13 bytes or so from one of the files in the zip. If there is an exe file in the zip, then we`re in luck. If there is only a text file in the zip then we`re stuffed because we have no reference to see if what we are decrypting is correct or not. But supposing we know the first 13 bytes in the file,... what do we do with them ? Well,... first we compress them with the same algorithm that pkzip uses. This helps us determine what result we looking for when the bytes are decryping. We then type an incorrect password into the box and break on hmemcpy. The routine that follows then takes the password and puts it through the same function that was used to generate the passworded zip in the first place. This function has altered the default magic number and that magic number is then used to decrypt the file. The function on the magic number is the one WE are interested in. We need to pass it a magic number that when put through this function produces the first byte of the unencrypted BUT compressed file. Guessing this number (or BRUTE FORCING as it is more commonly known) is the current method used in some recent pkunzip pw crackers. However,.. it is possible to reverse our tracks, as we know what the result we need to achive is, and produce modified magic numbers.This is NOT easy. These modified numbers are all we then need to produce the rest of the decryption. You might ask the question : Why do we need 13 bytes of data ?? Well, there are lots of possible solutions to gain a magic number that will decrypt the first byte (or even more bytes) when passed through the function but the rest of the data will not be decrypted. Therefore if you have at least 13 bytes worth of information you can be pretty sure that the magic number you have produced is the one you need. Princess would probably have the patience to carry out this amount of backtrace. Unless we all club together, this could take some time. L8R Mushy!! Mushy |
The Mushy thread (mushy) (09-Feb-99 16:31:15) |