Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Sep 2017 02:41:30 +0000
From: Glen B <lucky0106@....com>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: Custom Windows build 1.8.0.9 - What happened to
 zip2john?

Well, this feels kind of embarrassing. I changed the encoding via 
Notepad++ to UTF-8 straight. I saved it, then ran john with just the 
filename of the hash. Out came the password, in less than a millisecond 
if I'm reading the output correctly. It was a super simple password, too...

I guess the lesson here is; all file input must be UTF-8!

Glen


On 9/26/2017 7:30 PM, Glen B wrote:
> Pretty much confirming what you said, I've found some documentation on
> Cygwin <https://cygwin.com/cygwin-ug-net/using-specialnames.html> in the
> POSIX devices section saying that the /dev/shm directory is very
> important for some programs. Additionally, there appears to be an
> unanswered thread here on john-dev
> <http://www.openwall.com/lists/john-dev/2014/06/06/3> talking about this
> message in particular. Sounds like there may be a bug here?
>
> About the non-UTF8, I just opened the output file in Notepad++, which
> says it's encoded in UCS-2 LE. (I don't think I've heard of that one
> before!) I'm running these commands from Windows PowerShell, perhaps
> that's screwing with things?
>
> I wouldn't mind sharing the hash with a developer although I would like
> it to remain private, if there is a developer available to accept this file?
>
> Running the command without show:
>
> .\run\john.exe .\zip.hash
> Warning: '/dev/shm' does not exists or is not a directory.
>
> POSIX shared memory objects require the existance of this directory.
> Create the directory '/dev/shm' and set the permissions to 01777.
> For instance on the command line: mkdir -m 01777 /dev/shm
> Warning: invalid UTF-8 seen reading .\zip.hash
> Using default input encoding: UTF-8
> No password hashes loaded (see FAQ)
>
> Glen
>
> On 9/26/2017 5:04 PM, Rich Rumble wrote:
>> On Tue, Sep 26, 2017 at 6:57 PM, Glen B <lucky0106@....com> wrote:
>>
>>> Hi Robert et. al.,
>>>
>>> Sorry for taking so long to respond - I've downloaded the updated
>>> September build of 1.8.0.9. I'm happy to see that zip2john.exe is back!
>>> Running it on my zip file produces the following ouput:
>>>
>>> ver 2.0 Labs.zip->Labs.pdf PKZIP Encr: cmplen=1838962, decmplen=2008077,
>>> crc=7830B902
>>>
>>> So that seems to be working well? The output hash is kind of odd - the
>>> file I saved it to is 7,184KB in size, but the output format seems
>>> normal enough? When I run john, however...
>>>
>>> .\run\john.exe --show .\zip.hash
>>> Warning: '/dev/shm' does not exists or is not a directory.
>>>
>> I've had that error before, seems to be an environment issue, meaning if
>> you run John from a Cygwin environment the issue I believe goes away.
>> Otherwise there may have to be something done to the code to fix that
>> issue. I don't think it's a hard error, JtR should just move past it.
>>
>>> POSIX shared memory objects require the existance of this directory.
>>> Create the directory '/dev/shm' and set the permissions to 01777.
>>> For instance on the command line: mkdir -m 01777 /dev/shm
>>>
>> This is the real problem
>>
>>> Warning: invalid UTF-8 seen reading .\zip.hash
>>> 0 password hashes cracked, 0 left
>>>
>> The file seems to contain a non-UTF-8 string inside it, but again JtR
>> should move past that... The hash may not be correct, is it possible to
>> post it, perhaps privately to one of the developers (not me :)
>> Try the command without the SHOW.
>>
>>> It seems like john is having trouble reading the output of zip2john?
>>>
>>> Glen
>>>
>>> On 9/2/2017 6:52 PM, rs904c@...scape.net wrote:
>>>> The symbolic link issue mentioned below in Cygwin is still broken, if you
>>>> configure with:
>>>>     "--enable-ln-s ", which  Use ln -s vs symlink.c wrappers (Cygwin only)
>>>>
>>>> So, I tested my configure without this, and all executables are working
>>> now.
>>>> I'm almost done with my testing and I'm about the release a new version
>>> for
>>>> Windows x64 on the custom build site.
>>>>
>>>> -Robert B. Harris from VA
>>>>
>>>> -----Original Message-----
>>>> From: rs904c@...scape.net [mailto:rs904c@...scape.net]
>>>> Sent: Friday, August 25, 2017 11:24 PM
>>>> To: john-users@...ts.openwall.com
>>>> Subject: RE: [john-users] Custom Windows build 1.8.0.9 - What happened to
>>>> zip2john?
>>>>
>>>> So seeing how this problem was just discovered,  I'd like to hear that
>>>> someone has either worked on the code to fix it, or they believe it is no
>>>> longer a problem with the code.
>>>>
>>>> Then I'll compile a new bleeding for Windows, test this to confirm or
>>> deny
>>>> the problem's current status.  Once the new version is confirmed fixed,
>>> I'll
>>>> put on the custom build site.
>>>>
>>>> --Robert B. Harris
>>>>
>>>> -----Original Message-----
>>>> From: Glen B [mailto:lucky0106@....com]
>>>> Sent: Thursday, August 24, 2017 10:22 PM
>>>> To: john-users@...ts.openwall.com
>>>> Subject: Re: [john-users] Custom Windows build 1.8.0.9 - What happened to
>>>> zip2john?
>>>>
>>>> Hey Robert,
>>>>
>>>> I can confirm what you've found, the earlier build did have the proper
>>>> executables. I hope I can test a build from you soon if you won't mind!
>>>>
>>>> Glen
>>>>
>>>> On 8/24/2017 6:53 PM, rs904c@...scape.net wrote:
>>>>> Hey, I'm Robert and the one who contributes almost all of the builds
>>>>> on the custom build site.
>>>>>
>>>>> I think there was something definitely wrong with the bleeding version
>>>>> in March 2017, and possibly now, when building with cygwin.
>>>>>
>>>>> See below for more details.
>>>>>
>>>>> I tested all of the symbolic link files in the Windows build from
>>>>> March 2017 that I did and I can confirm there seems to be a problem
>>>>> with
>>>> them.
>>>>> These all fail to run:
>>>>>
>>>>> base64conv
>>>>> gpg2john
>>>>> hccap2john
>>>>> keepass2john
>>>>> putty2john
>>>>> racf2john
>>>>> rar2john
>>>>> unafs
>>>>> undrop
>>>>> unique
>>>>> unshadow
>>>>>
>>>>> I then checked the previous version I made
>>>>> "John-the-Ripper-v1.8.0-jumbo-1-Win-64".
>>>>> In this version there are no files that are symbolic links.  These all
>>>>> run fine.
>>>>>
>>>>> base64conv.exe
>>>>> calc_stat.exe
>>>>> cprepair.exe
>>>>> dmg2john.exe
>>>>> genmkvpwd.exe
>>>>> gpg2john.exe
>>>>> hccap2john.exe
>>>>> john.exe
>>>>> keepass2john.exe
>>>>> keychain2john.exe
>>>>> keyring2john.exe
>>>>> keystore2john.exe
>>>>> kwallet2john.exe
>>>>> luks2john.exe
>>>>> mkvcalcproba.exe
>>>>> pfx2john.exe
>>>>> putty2john.exe
>>>>> pwsafe2john.exe
>>>>> racf2john.exe
>>>>> rar2john.exe
>>>>> raw2dyna.exe
>>>>> ssh2john.exe
>>>>> tgtsnarf.exe
>>>>> truecrypt_volume2john.exe
>>>>> uaf2john.exe
>>>>> unafs.exe
>>>>> undrop.exe
>>>>> unique.exe
>>>>> unshadow.exe
>>>>> wpapcap2john.exe
>>>>> zip2john.exe
>>>>>
>>>>> -- Robert B. Harris from VA
>>>>>
>>>>> -----Original Message-----
>>>>> From: Solar Designer [mailto:solar@...nwall.com]
>>>>> Sent: Friday, August 18, 2017 3:55 PM
>>>>> To: john-users@...ts.openwall.com
>>>>> Subject: Re: [john-users] Custom Windows build 1.8.0.9 - What happened
>>>>> to zip2john?
>>>>>
>>>>> On Fri, Aug 18, 2017 at 07:16:03PM +0000, Glen B wrote:
>>>>>> I really liked the earlier versions of JtR that were self-contained
>>>>>> and
>>>>> didn't require downloading anything else to be honest.
>>>>>
>>>>> This build wasn't meant to require anything extra either.  According
>>>>> to what you said, it's just a bug.
>>>>>
>>>>>> If this is just a symlink though, what is it symlink-ing to? The john
>>>>> binary? If so, couldn't I just run john directly?
>>>>>
>>>>> Yes.  You could run "john" directly if you copy or rename it so that
>>>>> it'd be called "zip2john".
>>>>>
>>>>> Alexander
>>>>>
>>>>>
>>>>> ---
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> https://www.avast.com/antivirus
>>>>>

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ