|
Post by ELiTE on Mar 28, 2005 9:10:12 GMT -5
Thankx a lot man, you're gr8 i'll try it and post what i'll find here. Regards, PD
|
|
|
Post by mIKE on Mar 30, 2005 13:03:15 GMT -5
Kevin:
Thanks for your fine product.... I guess I should upgrade from 221. Please let me know if you think this would help eliminate the following problem.
I downloaded your brute-force password program, and it exhibits the same odd problem I have in a program I wrote. That is, it generates an error dialog with "zip error" in the titlebar, but no other information.
This happens with one file I'm trying to decrypt. It happens right away when it tries to test with your machine-generated passwords, and it also happens every time when I try to test FileIsOK with one particular password: ThiSISTheEnd1234..
Note that I can change any one character of that password test and it behaves fine. It also tests without a problem when I use many different similar passwords for the test.
Note that I can test a different ZIP file and use the "problem" password, but it doesn't exhibit the error-message symptom when I'm testing that other ZIP file.
The ZIP file that exhibits the problem has only one file in it, and that file was encrypted. As I recall, the key is 14-characters long, but in the course of my testing, I was using the 18-character key mentioned above.
Also, when I'm running your brute-force program and I get this error, I tried just closing the error-dialog but it comes up continuously. I tried hitting the stop button, but it doesn't get me out of the problem. I also tried closing the form, but that's what caused the program to actually start processing. The only way I could get it to actually stop was to use CTRL-F2 in the IDE. Right now, it's been running my test for keys from lengths 13-16 and ASCII values 46-115. It's been going for 8 hours on this 1.8Ghz machine and it's still on the length-13 tests. I'm also going to start it on a 3.4Ghz machine shortly. I started the test with 13-character keys in case the reason I can't seem to decrypt the file is that I accidentally missed a character.
While the brute-force program is processing, my stop button is disabled.
I'm concerned that there are mouse-clicks pending, and then if it does find the password, these mouse-clicks could be processed and I'll be blown out of the program without seeing the recovered password. Maybe adding a simple dialog with the recovered password would prevent that from happening when the program gets confused.
mIKE
|
|
|
Post by Kevin on Mar 31, 2005 10:55:22 GMT -5
I have not seen this before. Are you saying that this particular password causes the error for one particular zip file, but for all other zip files the same password works?
Also, as for the stop button being disabled, be sure you have the DoProcessMessages property for VCLZip set to True.
Kevin
|
|
|
Post by mIKE on Mar 31, 2005 11:21:43 GMT -5
Kevin:
Yes, testing this particular password against this particular ZIP file causes the "Zip Error" dialog to appear, whereas the same password doesn't cause the problem when testing any other ZIP file that I tried.
And I did not change the DoProcessMessages value from its True state when I compiled your BruteForce program, so the STOP button IS enabled when I start the program. It's just that when I click on it to try to get out of the error loop, it then becomes disabled, so by the time I try to close the form (which is what finally triggers the testing process to begin), the button is no longer available.
Also, after about 9 hours and something like 40 billion tests, my machine crashed hard. A blue screen with the following message appeared:
*** STOP: 0x0000001E (0xC000001D),0x80CE180F,0xF5790248,0x831F95CA KMODE_EXCEPTION_NOT_HANDLED
Beginning dump of physical memory
This machine has 1.5GB of RAM, but I had not been watching the W2K performance monitor to see if usage had been creeping up.
mIKE
|
|
|
Post by Kevin on Mar 31, 2005 12:48:22 GMT -5
I would start by upgrading to VCLZip 2.23, or, VCLZip Pro. If you are a registered user of VCLZip 2.22, then 2.23 is free at least. Also, if the zip file that is causing the problem isn't too big, you could send it to me and I'll see if I can see anything strange about it. Kevin
|
|
|
Post by mIKE on Apr 1, 2005 3:13:10 GMT -5
Kevin:
Well, I'm inclined to just upgrade to 3x Pro now anyway, so it will be interesting to see if that makes any difference.
The file I'm working with is 1.3M, so maybe I'll send it to you so you can have a peek. It's not actually a valueable file, and I can re-create it if needed, so the only reason that it's crucial to solve this is that it impacts both your bruteforcer and my cracker too.
Until I can make both your program and mine work without error (even of they don't crack the code), I will remain concerend.
I should add that when I first encrypted this file abuot a week ago, I immediately tested to see if I could extract it and it worked fine at that time. So I blew away the original file and just kept the ZIP.
And the file was created with PKZip Pro 4.5, which has always worked fine in the past, even for input files larger than 10GB and output files that span CDs.
Trying to extract the file using PKZip Pro 4.5 and 5.0 don't show any problem using the password that causes an error in my version of VCLZip. No error is reported, but the file is not extracted either. (as expected, since I apparently don't know the code.)
I'll let you know next week once I have tested your program and mine with the newer version of VCLZip.
mIKE
|
|
|
Post by Kevin on Apr 1, 2005 12:06:45 GMT -5
Mike,
You say the file was created with PKZip? That brings up a few questions...
1) What compression level did you use? If you used deflate64, VCLZip doesn't support that.
2) Did you encrypt with PKZip, or did you encrypt it prior to zipping it? If the former, did you use PKZip 2.0 compatible encryption? That's the only encryption VCLZip supports. If you encrypted first and then zipped then the file is just data and VCLZip should be ok with that.
3) You say you can re-create the problem file. Does PKZip unzip that problem file without a problem? Be sure VCLZip can't unzip the same file
Kevin
|
|
|
Post by ELiTE on Apr 18, 2005 12:07:11 GMT -5
Hello Kevin, i'm sorry to be late... i have tried your prog, and the one that i have made... they work only If you have made the archive using WinZip with the following : - compression : NONE. - Encryption Method : Zip 2.0 compatible encryption (portable). Otherwise it gives more than one (bad) password. Not to forget that i used winrar to compress an archive (.zip of course) , but no luck it again gave me the same as Otherwise. these what i found... what do you think Kevin.
|
|
|
Post by Kevin on Apr 19, 2005 13:39:25 GMT -5
Try, downloading VCLZip 3.05 at www.vclzip.net/src30532.zipIt has a lot of WinZip compatibility mods. It might work. Is it working for you if you create the zip with VCLZip? Kevin
|
|
|
Post by ELiTE on Apr 20, 2005 0:58:14 GMT -5
Is it working for you if you create the zip with VCLZip? Did'nt tried it yet, i'll check and post here. ;D seems to need a Pass. (is it free or...) PD.
|
|
|
Post by Kevin on Apr 20, 2005 13:26:10 GMT -5
Its the same password as for VCLZip 3.04, I haven't changed it.
Kevin
|
|
|
Post by mIKE on Apr 21, 2005 18:03:48 GMT -5
Mike, You say the file was created with PKZip? That brings up a few questions... 1) What compression level did you use? If you used deflate64, VCLZip doesn't support that. 2) Did you encrypt with PKZip, or did you encrypt it prior to zipping it? If the former, did you use PKZip 2.0 compatible encryption? That's the only encryption VCLZip supports. If you encrypted first and then zipped then the file is just data and VCLZip should be ok with that. 3) You say you can re-create the problem file. Does PKZip unzip that problem file without a problem? Be sure VCLZip can't unzip the same file Kevin 1] I've never deliberately changed my PKZIP configuration to specify anything other than plain deflate, so I don' think that's it. 2] The file was not encrypted before zipping it with PKZIP. And again, I never changed my PKZIP configuration from the setting identified as "Traditional PKWARE Encryption" (NOT "Strong Encryption"). 3] The file I can recreate is "equivalent" of the original in that its contents have the same value to me as the one I cannot decrypt. Unfortunately, that doesn't mean that the file is exactly the same, so encrypting it again won't prove much. Note that all of the files that I have successfully decrypted with VCLZip 2.2x where encrypted with PKZIP using the same settings I use all the time. If it weren't for the fact that I was even able to decrypt the "problem" file in PKZIP immediately after creating it makes me think that the file is intrinsically okay. I just bought the upgrade to 3.x on ShareIt, so now I'll see what happens with your "brute-forcer" and my "elegant-guesser" program. Your program was reporting some errors, as noted in earlier messages, and my program was reporting the same errors when testing passwords against the "problem" file. Note that, compared to your program, my program tries a tiny number of passwords, but since the passwords are built from combinations of "password elements" that the user (me), has been known to use, I'm hoping to get lucky. It's worked great with some other files that I encrypted with PKZIP, but no luck on the "problem" file yet.
|
|
|
Post by Kevin on Apr 22, 2005 6:06:08 GMT -5
|
|
|
Post by mIKE on Apr 22, 2005 12:48:34 GMT -5
I tested with 3.04 and found no changes in the behavior of my apps. Then I downloaded 3.05 and when I compile it as a part of the install into D5, I get these errors: [Error] kpSStrm.pas(60): Invalid compiler directive: 'WARN' [Error] kpSStrm.pas(61): Invalid compiler directive: 'WARN' [Fatal Error] kpSStrm.pas(150): Could not compile used unit 'kpSHuge.pas' I didn't see any references in the accompanying text files that deal with this. mIKE
|
|
|
Post by Kevin on Apr 22, 2005 12:51:49 GMT -5
Oh yeah, in my next release I have changed that, you must be using something like Delphi 5? Just remove those lines and it should be ok.
Kevin
|
|