I will do that, thank you ----- Original Message ----- From: "karl voss" <wootski@...> To: <john-users@...> Sent: Monday, October 31, 2005 7:59 AM Subject: Re: [john-users] Using JTR Hey Robert, you might also want to get the latest version of JTR (1.6.39) as it runs MUCH faster than the old versions. -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
Greetings, The Oracle encryption algorithm is described in "An Assessment of the Oracle Password Hashing Algorithm" by Joshua Wright, SANS Institute & Carlos Cid, University of London (see http://www.sans.org/rr/special.php). Do you think it would be interesting to extend JTR to also support this algorithm? Cheers, Lionel -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
On Wed, 2 Nov 2005 10:10:24 +0100 Lionel Cons <lionel.cons@...> wrote: > Greetings, > > The Oracle encryption algorithm is described in "An Assessment of the > Oracle Password Hashing Algorithm" by Joshua Wright, SANS Institute & > Carlos Cid, University of London (see http://www.sans.org/rr/special.php). > > Do you think it would be interesting to extend JTR to also support > this algorithm? > > Cheers, > > Lionel You could have an working implementation serval years ago if somebody would have asked the THC-Group. THey knew about the algorithm for some time... BUt they'll also reject any requests.(Continue reading)Would it be interesting? Yes Even cracking ZIP-Archives with John would be interesting. But like everything wich would be interesting: It's not implemented yet.
Lionel Cons wrote: > Do you think it would be interesting to extend JTR to also support > this algorithm? I did it in a ugly way in my "big patch". You'll find my latest tree in http://virtual2.bandecon.com/misc/myjohn.tgz. It would be better if someone did it "right" but this works for me. -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
Hi, to speed things up for cracking "standard-passwords) i'd like to have john list every generated hash (along with the corresponding source-pw) to stdout - i already tried to hack my way through cracker.c, but my c is too lousy to get things right. could anybody give me a clue (or path??) where i have to put the print(%s) to get all tested hashes printed to stdout? -- thomas.springer@... [nach mir der synflood.] -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
thomas springer wrote: > Hi, > > to speed things up for cracking "standard-passwords) i'd like to have > john list every generated hash (along with the corresponding > source-pw) to stdout - i already tried to hack my way through > cracker.c, but my c is too lousy to get things right. > > could anybody give me a clue (or path??) where i have to put the > print(%s) to get all tested hashes printed to stdout? Hashes are generated by crypt_all. Depending on the cipher they are stored in different ways so i guess the best thing to do is to alter the crypt_all function in every cipher that you're interested in. -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
On Thu, Nov 10, 2005 at 03:23:36PM +0100, thomas springer wrote: > to speed things up for cracking "standard-passwords) i'd like to have > john list every generated hash (along with the corresponding > source-pw) to stdout - i already tried to hack my way through > cracker.c, but my c is too lousy to get things right. Why do you think that would let you speed things up? Precomputation? It doesn't work like that. If you're really interested, you can have a look at QCrack, but it is impractical to use it these days. > could anybody give me a clue (or path??) where i have to put the > print(%s) to get all tested hashes printed to stdout? It's not as simple as that. John does not produce the ASCII-encoded strings for the hashes it generates. In fact, it does not even include code to do that. Instead, it decodes the hashes it loads from your password files and does its comparisons on binary representations of hashes (or sometimes even "indirect" comparisons of partial hashes). Simon has correctly suggested that crypt_all() for your desired hash type is one place where you can obtain whatever hashes (or partial hashes) are computed for the candidate passwords John generates and for salts of your loaded password hashes. These won't be in a format that is convenient to use elsewhere, though. For example, for DES-based hashes, the internal representation that John uses differs between processor architectures and it never has the DES final permutation applied (instead, the final permutation is undone on hashes loaded from password files to crack).(Continue reading)
> Why do you think that would let you speed things up? Precomputation? > It doesn't work like that. jup, precomputation, rainbowtables for the poor, if you like. i'd like to have a few million "standard"-hashes with fixed salts, eg. lm-hashes ready for lookup. > It's not as simple as that. John does not produce the ASCII-encoded yea, i should have known that it's not that simple! > The good news is that you _really_ shouldn't need those hashes.(Continue reading)i'm short on processor-time... i recovered the ancient ntcrack to compute and list lm-hashes - it worked, slower, but fine! now I'm goin to compare the processorload for a lookup with john -wordlost... :) thanks for the reply -- thomas.springer@... [nach mir der synflood.] -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
thomas springer wrote: >>Why do you think that would let you speed things up? Precomputation? >>It doesn't work like that. > > > jup, precomputation, rainbowtables for the poor, if you like. > i'd like to have a few million "standard"-hashes with fixed salts, eg. > lm-hashes ready for lookup. Then you really should use rainbowcrack, or ophcrack (http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/) which comes bundled with a rainbow table. If you feel inclined to have a time/memory tradeoff, you should have an efficient one. And if you really want to calculate hashes, i suggest you use something like a quick'n'dirty perl script, that will be slower but all in all i think it will save you a lot of time. -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
Simon, i'm doing exactly this now: create a worlist with john -stdout, feed the wordlist to a perlscript that calls the modified ntcrack, crypt and mysql to create the hashes and feed all this again into a mysql-table. > If you feel inclined to have a time/memory tradeoff, you should have an > efficient one. i'd love to dig deeper into the rainbow-tables - but digging into this would take a lamer like me days and weeks to understand and modifay - i'm into the "quick and dirty-solution" right know. thanks for all the help and a great peace of software! -- thomas.springer@... [nach mir der synflood.] -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
RSS Feed66 | |
|---|---|
72 | |
63 | |
146 | |
104 | |
138 | |
177 | |
78 | |
109 | |
168 | |
177 | |
175 | |
103 | |
150 | |
106 | |
87 | |
122 | |
90 | |
74 | |
47 | |
119 | |
186 | |
121 | |
56 | |
90 | |
53 | |
112 | |
129 | |
58 | |
50 | |
51 | |
53 | |
98 | |
94 | |
52 | |
47 | |
26 | |
39 | |
160 | |
99 | |
29 | |
70 | |
20 | |
38 | |
75 | |
52 | |
114 | |
49 | |
10 | |
14 | |
13 | |
43 | |
37 | |
19 | |
21 | |
54 | |
34 | |
36 | |
42 | |
46 | |
22 | |
37 | |
31 | |
51 | |
68 | |
10 | |
35 | |
10 | |
47 | |
10 | |
25 | |
19 | |
30 | |
39 | |
65 | |
38 | |
56 | |
47 | |
10 | |
55 | |
34 | |
40 | |
40 | |
82 | |
125 | |
148 | |
76 | |
80 | |
56 | |
52 | |
38 | |
41 | |
46 | |
42 | |
11 | |
47 | |
36 | |
2 | |
1 |
