[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <555CBD54.1070000@gmail.com>
Date: Wed, 20 May 2015 18:59:00 +0200
From: Marek Wrzosek <marek.wrzosek@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Advise on best approach (truecrypt pw based on pdf
file)
Hi Demian
What version of truecrypt did you use on windows?
W dniu 20.05.2015 o 07:43, Demian Smith pisze:
> Hi magnum,
>
> thank you for looking into it for me - the plausible deniability (?) is
> a nice feature and I believe it's one that it is good to have.
>
> In the last weeks I did run with the --format option, as I think I would
> not have changed the defaults. Which - on my linux machine - are ripemd
> and aes. I hope they would have been the same on a win machine, but
> can't verify, as I don't have an old truecrypt copy lying around.
>
> So, I have removed the hidden-container lines from the file (I know
> there's no hidden volume) and am now back to running the wordfile onto
> it and then incremental... Will keep my finger's crossed though =)
>
> Cheers,
> Demian
>
> ★ On 15/05/20 01:12 a.m. Magnum wrote ★
>> The hash_nopart one from sdb has entries with mostly nulls so is not
>> likely correct. I just made some quick tests and reviewed the code.
>> Unfortunately, truecrypt_volume2john doesn't recognize any signature or
>> magic, so you can feed it ANY data and as long as it's at least 512
>> bytes it will happily produce six different hashes: One for each of the
>> three algorithms, plus another set of three for possible hidden volumes.
>> I believe there's no way to make it any better - truecrypt is designed
>> to be plausably deniable. Of the six ones always produced, I believe
>> only one is ever correct (if any) and often you won't know which.
>>
>> I tried running truecrypt_volume2john on some actual truecrypt container
>> (file) I had lying around. Obviously it "found" six hashes in it too.
>> When trying with the correct password, the correct one was cracked
>> (apparently it was a RIPEMD_160 one) while the other ones are bogus
>> random data that can't ever be cracked.
>>
>> So, if last weeks attempts were made using the file from sbd1, and
>> without using the --format option no narrow down to a particular algo, I
>> think you did correct. If you did narrow it down to eg.
>> --format=tc_ripemd160, I hope that's because you KNOW that is the algo
>> used.
>>
>> magnum
>>
>>
>> On 2015-05-19 23:23, Demian Smith wrote:
>>> Not all hope is lost, so?
>>>
>>> So, what I did was:
>>>
>>> attach the external device to usb and verify it's "path" via lsblk
>>> and/or truecryp. This led to
>>> sdb 8:16 0 465.7G 0 disk
>>> └─sdb1 8:17 0 465.7G 0 part
>>>
>>> I than do:
>>> [demian@...nymous:~/.bin/JtR/run]$ ./truecrypt_volume2john /dev/sdb1 >
>>> ~/hash
>>>
>>> which results in the attached hash file.
>>>
>>> I had tried the same on a usb key, as well running truecrypt2john versus
>>> the partition on sdb1, which then had been "cracked"...
>>>
>>> If I create a hashfile on /dev/sdb instead, I get
>>>
>>> john --session=wl --wordlist=/home/wpd_for_mark_second.txt ~/no_partition
>>> ASCII -> ASCII -> ASCII
>>> Warning: detected hash type "tc_aes_xts", but the string is also
>>> recognized as "tc_ripemd160"
>>> Use the "--format=tc_ripemd160" option to force loading these as that
>>> type instead
>>> Loaded 6 password hashes with 6 different salts (tc_aes_xts, TrueCrypt
>>> AES256_XTS [SHA512 128/128 SSE4.1 2x /RIPEMD160/WHIRLPOOL])
>>> Loaded hashes with cost 1 (hash algorithm [1:SHA512 2:RIPEMD160
>>> 3:Whirlpool]) varying from 1 to 3
>>> Will run 4 OpenMP threads
>>>
>>> If I force ripemd w/ --format=tc_ripemd160:
>>> initUnicode(UNICODE,ASCII/ASCII)
>>>
>>>
>>> ASCII->ASCII->ASCII
>>>
>>>
>>> Loaded 2 password hashes with 2 different salts (tc_ripemd160, TrueCrypt
>>> AES256_XTS [RIPEMD160 32/64])
>>>
>>> Will run 4 OpenMP threads
>>>
>>> while the hashfile itself looks different ...
>>>
>>> i did look into the doc folder but could not spot anything related to
>>> truecrypt, I hope I did not just miss it...
>>>
>>> Also, I hope I just made a mistake somewhere on the lines of generating
>>> the hashes, maybe ...
>>>
>>> Thanks for keeping my hopes up,
>>> D
>>> --
>>> 'It's no measure of mental health to be well adjusted
>>> to a profoundly sick society.'
>>>
>>> Sinéad O'Connor
>>>
>>> ★ On 15/05/19 09:00 p.m. Magnum wrote ★
>>>> On 2015-05-19 20:35, Demian Smith wrote:
>>>>> I right now run the two filters on the first txt file I create from the
>>>>> suspect pdf and will then go back to incremental, as the Markov mode -
>>>>> in my case - does not appear to be producing useful candidates.
>>>>>
>>>>> Thanks again for all the effort, I'm pretty sure this is a layer 8
>>>>> issue
>>>>> right now :s
>>>>
>>>> Maybe we should revert to verifying your truerypt_volume2john
>>>> invocation/results.
>>>>
>>>> Please recap what you had, what you did and what you got. Were you
>>>> feeding truecrypt_volume2john a file or a device special node? Was there
>>>> any output on stderr? How does your "hash" file look? I still wonder why
>>>> you got two "hashes".
>>>>
>>>> magnum
>>>>
>>>>
>>
>>
>>
--
Marek Wrzosek
marek.wrzosek@...il.com
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
