Solve a riddle, guess a 4 char password and add 10 BTC to your xmas... SOLVED!!

[K1773R]

The next hint will be a little more specific about the equation change - let me know how soon you think you need this hint (if no other consensus then I will be giving it at a 200 confirmations).

I can obviously only speak for myself, but I simply see too many possibilities to brute force at the moment. Or rather that I see no good way of automating the guessing of the equation modification.
Replacing the "=" and "at least" with ">=" was the only logical change I could come up with.
Next up is a ton of "two times %s..." etc.

i already ran it with >= as single symbol.

@BkkCoins il have to test that, didnt knew its alread working.

EDIT: how did u get --format=gpg-opencl to run? i compiled the gpu john but it dosnt know this format :S
EDIT2: nvm a make clean helped.

[CIYAM]

I can obviously only speak for myself, but I simply see too many possibilities to brute force at the moment. Or rather that I see no good way of automating the guessing of the equation modification.
Replacing the "=" and "at least" with ">=" was the only logical change I could come up with.
Next up is a ton of "two times %s..." etc.

Indeed - I could have easily changed it to something like: etothei$password (which I didn't so don't bother with that one) and am pretty certain that the next hint will help clarify things.

[phr33]

Reporting in on GPU performance with John.

So I wrote up my own pwd gen which outputs new pwds to stdout and can be piped into John.
I run like this,

mkpwds | john --stdin --format=gpg-opencl ciyam.hash

... give some output like this...

Compilation log:
Warning: gpg kernel has register spilling. Lower performance is expected.

Loaded 1 password hash (OpenPGP / GnuPG Secret Key [OpenCL])

and after letting it do about 4 million pwds this way (drum roll) I get about 30,000 c/s reported.

This is on 1x 5830. Not that much more than a fast CPU I guess but then I do have 3 available. I just haven't played with running multiple instances yet. I have to turn mining off on 1 GPU to get that. Otherwise, while mining, it gets about <20,000 c/s. This is on a low end Athlon cpu typical for mining.

So at 30,000 c/s it should take roughly 8 minutes to do a salt pattern. Or 2.5 if I can get all 3 GPUs going and manage to split the pwd stream.

Interesting! Thanks for the update 

I can imagine there's more benefit from the GPU when the whole password generation thing can be put inside the GPU as well...

[BkkCoins]

Interesting! Thanks for the update 

I can imagine there's more benefit from the GPU when the whole password generation thing can be put inside the GPU as well...

Not sure about that but maybe. My mkpwds works pretty fast but I didn't time it. It generated a file of all 62^4 pwds in a minute or so. I should have timed it. But then when I saw the file was 960MB I deleted it and decided to use piping instead.

It doesn't appear to slow down the GPU performance as the mkpwds runs on the CPU and feeds John using the GPU.

I may add some code to allow starting mkpwds at given start values so that I can split the range easily.

[K1773R]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

EDIT:
35 seconds for FULL scan
brute forcing is faster than creating the wordlist, awesome

[phr33]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

Nice work!

That should put you in the range were you can brute force quite a number of equation modifications. Have at it!

[K1773R]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

Nice work!

That should put you in the range were you can brute force quite a number of equation modifications. Have at it!

just in case i find the privkey for the 10BTC, i gonna share a piece of it to the guys who helped.

[CIYAM]

Actually only noticed for the first time that blockchain.info doesn't show the # of confirmations for an address when it gets above 100.

So rather than a confirmation # I will pick a time in (UTC) so unless there is a consensus to give it out sooner the next hint will be at 2012-12-27 04:00 (I will be going to sleep in another 5 or 6 hours at the most so I won't be available from around 2012-12-26 10:00 until 2012-12-26 20:00).

[CIYAM]

just in case i find the privkey for the 10BTC, i gonna share a piece of it to the guys who helped.

Very honourable - I also have pledged to provide some extra bounties for all the great testing being done here.

[phr33]

Actually only noticed for the first time that blockchain.info doesn't show the # of confirmations for an address when it gets above 100.

So rather than a confirmation # I will pick a time in (UTC) so unless there is a consensus to give it out sooner the next hint will be at 2012-12-27 04:00 (I will be going to sleep in another 5 or 6 hours at the most so I won't be available from around 2012-12-26 10:00 until 2012-12-26 20:00).

But you can see the number when looking at the transaction! Here:
http://blockchain.info/tx/56bb0f9038b6402a548795d15a22450b040efbeacdea56269baef34a68a0b5bd

[cedivad]

I was using a production server with 32 AMD CPU to do this.. however i had to stop:

last pid:  6144;  load averages: 72.31, 37.84, 24.09

I was DDOSing my own website

Anyway i really enjoyed what i learned!

Here is a pastebin to some (stupid but working) code if you want to use it:

http://pastebin.com/03vSGwwD

[phr33]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

EDIT:
35 seconds for FULL scan
brute forcing is faster than creating the wordlist, awesome

Those GPU sure can run!  

The issue I mentioned before was regarding the "trying: xxx" output. There is none in your new dump so I don't know if you fixed the problem or not. It looked like it only tried with half of the hash.

[CIYAM]

But you can see the number when looking at the transaction! Here:
http://blockchain.info/tx/56bb0f9038b6402a548795d15a22450b040efbeacdea56269baef34a68a0b5bd

Aha - nice spot - well I think by average calculations confirmation # 200 should occur around the time I had given (or maybe an hour either side) - but if it makes it more interesting to keep using confirmation #'s then no problem!

[K1773R]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

EDIT:
35 seconds for FULL scan
brute forcing is faster than creating the wordlist, awesome

Those GPU sure can run!  

The issue I mentioned before was regarding the "trying: xxx" output. There is none in your new dump so I don't know if you fixed the problem or not. It looked like it only tried with half of the hash.

just checked it, its the same for the GPU, do not ask me why! the wordlist hashes are right but the output isnt, did you run into this problem too? for the GPU it "looks" crazy too:

Code:

guesses: 0  time: 0:00:00:35 DONE (Wed Dec 26 11:42:23 2012)  c/s: 414364  trying: 7277b9b8b5034fc - eea8eca3d152537

and the hash from the hashfile is 7277b9b8b5034fc4e715be0e9e61bf3aac30cce46396a30b5272d89e19418a61, ah dammit!

[cedivad]

Has anyone tried to use c to create the dictionary?

[K1773R]

Has anyone tried to use c to create the dictionary?

i do it in java with JNI mixed.

[cedivad]

Has anyone tried to use c to create the dictionary?

i do it in java with JNI mixed.

What's your speed? It would take me something like 1 day to write the 14 million combinations there are...

[phr33]

Python for the win!

Code:

import itertools
import hashlib

group = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'

for passw in list(itertools.product(group, repeat=4)) :
  pas = ''.join(passw)
  # Modify next line!
  final = "%s+%s=%s%s@L3AsT\n" % (pas, pas, pas, pas)
  m = hashlib.sha256()
  m.update(final)
  print  "%s" %(m.hexdigest())

Code:

$ time python run.py > dict.txt

real    0m37.305s
user    0m35.162s
sys     0m1.200s

[K1773R]

Has anyone tried to use c to create the dictionary?

i do it in java with JNI mixed.

What's your speed? It would take me something like 1 day to write the 14 million combinations there are...

2 seconds to create the wordlist (4 chars)
17 seconds to create all sha256 sums
1.5 seconds to write it down to disk (916MB)

[phr33]

Code:

k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw:	91247 c/s real, 92160 c/s virtual

now thats a NICE improvement

EDIT:
35 seconds for FULL scan
brute forcing is faster than creating the wordlist, awesome

Those GPU sure can run!  

The issue I mentioned before was regarding the "trying: xxx" output. There is none in your new dump so I don't know if you fixed the problem or not. It looked like it only tried with half of the hash.

just checked it, its the same for the GPU, do not ask me why! the wordlist hashes are right but the output isnt, did you run into this problem too? for the GPU it "looks" crazy too:

Code:

guesses: 0  time: 0:00:00:35 DONE (Wed Dec 26 11:42:23 2012)  c/s: 414364  trying: 7277b9b8b5034fc - eea8eca3d152537

and the hash from the hashfile is 7277b9b8b5034fc4e715be0e9e61bf3aac30cce46396a30b5272d89e19418a61, ah dammit!

Yes - you need to modify jtr to use this long passwords