Free Rainbow Tables | Forum

Home of the Distributed Generator and Cracker
It is currently 18 Apr 2014, 20:18

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: 01 Nov 2010, 00:45 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
blazerx wrote:
i think i accidentally deleted the indexes for the CP437 tables, so i'll grab tham later, but what i did was convert the LM_ALph_num 7 set and when i tired to rcracki them i got the "A solution needs to be found for this problem" message. So i think maybe rcracki doesn't have LM RTI2 implementation or something


I've hit this before as well and I can't remember if it was because I was overly aggressive or underly aggressive on -eptl. Well, actually I worked around it by changing -eptl to pack it differently as it didn't solve the underlying problem but let me bypass it.


Top
 Profile  
 
 Post subject:
Posted: 01 Nov 2010, 01:35 


Top
  
 
PostPosted: 01 Nov 2010, 01:35 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
PowerBlade wrote:
Can we have some volunteers to test out this build of rcracki_mt for the RTI2 issues listed above?

quel:
The issue was the following:
Code:
   pReader->ReadChains(nDataRead, pChain);
   nDataRead *= 8; // Convert from chains read to bytes



A few lines down:
Code:
   int nRainbowChainCountRead = nDataRead / 16;


So all of the chains are read into memory, but only half of them are used :)


I'm assuming the fix was: int nRainbowChainCountRead = nDataRead / 8;

It seems to give me the same numbers for rti2 as for rti - will push out a new rcracki_mt release.

Also, saw this
Code:
   nDataToRead = nAllocatedSize / 16;
   nDataRead = nDataToRead;
   pReader->ReadChains(nDataRead, pChain);
   nDataRead *= 8; // Convert from chains read to bytes


Should that 16 also be 8?


Top
 Profile  
 
PostPosted: 01 Nov 2010, 23:10 
Offline
Site Admin

Joined: 11 Oct 2007, 21:17
Posts: 1618
Location: Copenhagen, Denmark
blazerx wrote:
oh ok

The NTLM loweralpha 9 doesn't seem to want to pack with 43 13, but needs 43 21 so seems like only the index is saved on space goin down to 300kb index files.

I shall collect the index files for CP437 and the indxes for the new MD5 lcase 10 tables tonight and see how things go tomorrow since i have most of those table files.


Blazerx, could you try with these tablesets? They are the only tables that are sequentially generated:

lm_lm-frt-cp437-850#1-7
ntlm_mixalpha-numeric#1-8
halflmchall_all-space#1-7
mysqlsha1_numeric#1-12
mysqlsha1_loweralpha-numeric-space#1-8
md5_loweralpha#1-10

If any of those fails, please make a bug report in this thread.


Top
 Profile  
 
PostPosted: 02 Nov 2010, 06:17 
Offline
Rainbow Table

Joined: 04 Jun 2008, 06:26
Posts: 439
ok i don't have every single table yet but i picked out a few and tested

Tested various files from the LM CP437-850 set with different index so far looks good Works with rcracki (-sptl=37 -eptl=19 used)

Small problem found with the converter though

ntlm_loweralpha-numeric-space#1-8
(-sptl=42 -eptl=14)

ntlm_loweralpha-numeric-space#1-8_1_10000x55962559_distrrtgen[p][i]_9.rti
ntlm_loweralpha-numeric-space#1-8_1_10000x67108864_distrrtgen[p][i]_0.rti

during the transition from file 9 -> 0 the converter crashed.

However if the files are placed separately in directories the conversion works fine.

Edit: Forgot to add index 0 and 2 works fine with no crash
Downloaded the wrong index files for the new MD5 tables accidently dled 1 instead of 0 so haven't had a chance to test it yet.

_________________
Image


Top
 Profile  
 
PostPosted: 02 Nov 2010, 08:16 
Offline
Site Admin

Joined: 11 Oct 2007, 21:17
Posts: 1618
Location: Copenhagen, Denmark
blazerx wrote:
ntlm_loweralpha-numeric-space#1-8
(-sptl=42 -eptl=14)

ntlm_loweralpha-numeric-space#1-8_1_10000x55962559_distrrtgen[p][i]_9.rti
ntlm_loweralpha-numeric-space#1-8_1_10000x67108864_distrrtgen[p][i]_0.rti

during the transition from file 9 -> 0 the converter crashed.


See my post above. You should only try to convert the sequentially generated tables I listed above


Top
 Profile  
 
PostPosted: 02 Nov 2010, 09:10 
Offline
Rainbow Table

Joined: 04 Jun 2008, 06:26
Posts: 439
oops sorry, mis read the mix alpha as lower

_________________
Image


Top
 Profile  
 
PostPosted: 02 Nov 2010, 11:04 
Offline
Site Admin

Joined: 11 Oct 2007, 21:17
Posts: 1618
Location: Copenhagen, Denmark
Notice the difference.
The lm_lm-frt-cp437-850#1-7 set has a keyspace of almost 2^48 but has a max sptl of 38.
the ntlm_loweralpha-numeric-space#1-8 set has a keyspace of 2 ^ 41.7152 and has a max sptl of 42..


Top
 Profile  
 
PostPosted: 02 Nov 2010, 11:48 
Offline
Rainbow Table

Joined: 04 Jun 2008, 06:26
Posts: 439
yea definately great love how the sequentially ones convert flawlessly, just tested on 2x indexes from the ntml mixalpha num 1-8.

The lowered max stpl definately allows better space saving.
458 + 2mb compared to 512 + 200 gotta love it.

_________________
Image


Top
 Profile  
 
PostPosted: 07 Nov 2010, 04:27 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
I've finally gotten to merging changes and pushed out rcracki_mt_0.6.5.2 (rcracki.sourceforge.net.) Mainly this is rti2 fixes.

Also, PowerBlade's converti2 changes so you can go rti -> rti2 without the rto step are in gitorious (http://gitorious.org/freerainbowtables- ... nbowtables) and *nix users can just grab it and run make. Windows binary builds of any tools besides rcracki_mt harass PB for :P

The first set that I picked from the list of sequentially generated tables proved interesting: mysqlsha1_numeric#1-12_*

I did the usual converti2 -d and found my start point for the conversion of 33 bits from mysqlsha1_numeric#1-12_0 and just used that for the 5 tables in the set. Apparently this set is even weirder than I remembered when it was created. The first tip off was seeing "this file is not sorted." When I ran -d across all the table chunks here is what I came up with:

Code:
mysqlsha1_numeric#1-12_[012]
   -sptl=33 -eptl=23 - at rcracki_mt run FATAL: m_indexrowsizebytes > 1: 2
   -sptl=33 -eptl=15
mysqlsha1_numeric#1-12_3
   -sptl=31 -eptl=25 - at rcracki_mt run FATAL: m_indexrowsizebytes > 1: 2
   -sptl=31 -eptl=17
mysqlsha1_numeric#1-12_4
   -sptl=33 -eptl=15 - for every file in the table "this file is not sorted"
   -sptl=35 -eptl=21 - at rcracki_mt run FATAL: m_indexrowsizebytes > 1: 2
   -sptl=35 -eptl=13

This last table is where it got very weird even tho I get 35 from -d for all the tables it didn't seem to work for _0 and _1 at crack time:
Code:
      mysqlsha1_numeric#1-12_4_6000x67108864_distrrtgen[p][i]_0.rti2:
      536870912 bytes read, disk access time: 2.99 s
      verifying the file...
      this file is not sorted

      mysqlsha1_numeric#1-12_4_6000x67108864_distrrtgen[p][i]_1.rti2:
      536870912 bytes read, disk access time: 2.87 s
      verifying the file...
      this file is not sorted

For those 2 table chunks I used: -sptl 36 -eptl 12

The end result is that both my rti and rti2 runs produced the same stats except minor time variance.

Code:
./rcracki_mt -t 4 -h 1604DD3A95B8AE90462F4BCEE373FC5697582B65 /mnt/rainbow_tables/freerainbowtables/mysqlsha1/mysqlsha1_numeric#1-12_?/*.rti
./rcracki_mt -t 4 -h 1604DD3A95B8AE90462F4BCEE373FC5697582B65 /mnt/rainbow_tables/freerainbowtables/mysqlsha1/mysqlsha1_numeric#1-12_?/*.rti2


Code:
statistics
-------------------------------------------------------
plaintext found:            0 of 1 (0.00%)
total disk access time:     90.56 s
total cryptanalysis time:   6.48 s
total pre-calculation time: 13.49 s
total chain walk step:      89955005
total false alarm:          19014
total chain walk step due to false alarm: 42227888


Top
 Profile  
 
PostPosted: 07 Nov 2010, 05:41 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
I think this is the complete set of start points for the sequential tables PB listed (and some newer ones):

33 mysqlsha1_numeric#1-12_[012]
31 mysqlsha1_numeric#1-12_3
35 mysqlsha1_numeric#1-12_4

34 halflmchall_all-space#1-7_0
33 halflmchall_all-space#1-7_[123]

38 lm_lm-frt-cp437-850#1-7_0
37 lm_lm-frt-cp437-850#1-7_[123]

unique chain min (for 99.9% for the set): 6,338,391,198
md5_loweralpha#1-10_3: 67108864*95+1479350 = 6,376,821,430

36 md5_loweralpha#1-10_[0123] with 1 exception:
md5_loweralpha#1-10_3_40000x1479350_distrrtgen[p][i]_95.rti:
38 - 1
39 - 3
40 - 1
41 - 1
42 - 1
43 - 3

34 mysqlsha1_loweralpha-numeric-space#1-8_0
33 mysqlsha1_loweralpha-numeric-space#1-8_[123]

37 ntlm_mixalpha-numeric#1-8_[0123]

unique chain min (for 99.9% for the set): 3,047,005,299
ntlm_mixalpha-numeric-all-space#1-7_1: 67108864*45+39127566 = 3,059,026,446
ntlm_mixalpha-numeric-all-space#1-7_2: 67108864*45+39141984 = 3,059,040,864
ntlm_mixalpha-numeric-all-space#1-7_3: 67108864*45+38980523 = 3,058,879,403

35 ntlm_mixalpha-numeric-all-space#1-7_[0123] with 3 exceptions
ntlm_mixalpha-numeric-all-space#1-7_1_40000x39127566_distrrtgen[p][i]_45.rti
40 - 62
45 - 6
46 - 13
ntlm_mixalpha-numeric-all-space#1-7_2_40000x39141984_distrrtgen[p][i]_45.rti
36 - 900
37 - 151
47 - 35
40 - 4
48 - 10
ntlm_mixalpha-numeric-all-space#1-7_3_40000x38980523_distrrtgen[p][i]_45.rti
36 - 971
37 - 295
46 - 33

35 md5_mixalpha-numeric-all-space#1-7_[0123]

The small number of start points that exceed the highest number of bits of the rest of the table and fall in the last file are something we'll need to deal with. We purposefully over-generate the number of chains required for our expectedSuccessRate so that in cases like this, after the math is checked, it is likely safe to discard some chains. This sort of computation of if it is safe to drop some chains as well as the code to do so will have to be something we integrate into converti2. In theory the client, validator, assimilator, perfecter, etc. should all be checking and discarding these in the first place but that's also TBD.


Last edited by quel on 29 Dec 2010, 07:17, edited 1 time in total.

Top
 Profile  
 
PostPosted: 07 Nov 2010, 22:24 
Offline
Dictionary

Joined: 05 Jul 2009, 08:21
Posts: 92
Hi quel,

thanks for all the work around rcracki_mt!

I tried to make converti2 on my Debian Version Lenny amd64, but I get an error:

Code:
g++ -Wall -m32 -ansi -I../../Common/rt\ api -O3 -c  ../../Common/rt\ api/MemoryPool.cpp
In file included from /usr/include/features.h:354,
                 from /usr/include/stdio.h:28,
                 from ../../Common/rt api/Public.h:27,
                 from ../../Common/rt api/MemoryPool.cpp:28:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: Datei oder Verzeichnis nicht gefunden
make: *** [MemoryPool.o] Fehler 1


Can't find any "stubs"-Library in the standard Debianrepositorys. So my question is: "Where to find this Library?" Could you give some hints to all the Debian users out there?


Top
 Profile  
 
PostPosted: 07 Nov 2010, 22:39 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
LordAlien wrote:
I tried to make converti2 on my Debian Version Lenny amd64, but I get an error:

A sound choice of OS as that's what I'm using ;)

[quel@paranoia ~] dlocate /usr/include/gnu/stubs-32.h
libc6-dev-i386: /usr/include/gnu/stubs-32.h

You can always search package contents at: http://www.debian.org/distrib/packages#search_contents

http://packages.debian.org/search?searc ... e&arch=any

Right now it forces 32-bit compilation (the -m32) as there are bugs in the 64-bit version. I cleaned up most of them and the 64-bit version does at least produce rti2 tables that match but the .rti2.index files are completely broken.


Top
 Profile  
 
PostPosted: 07 Nov 2010, 22:51 
Offline
Dictionary

Joined: 05 Jul 2009, 08:21
Posts: 92
Thanks for those useful links and the explanation.

Hopefully you will fix those 64Bit problems. :P

I want to store the new MD5-Table on my 2TB RAID1 next to all the other tables, but it will only fit if I convert some tables from rti to rti2.

/edit: Damn it, another error:
Code:
g++ -Wall -m32 -ansi -I../../Common/rt\ api -O3  MemoryPool.o Public.o RTI2Reader.o RTIReader.o RTReader.o  converti2.cpp -o converti2
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [converti2] Fehler 1

I have installed following packets matching libstdc++:
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii libstdc++6-4.3-dev 4.3.2-1.1 The GNU Standard C++ Library v3 (development
Never had such an error, so I have no idea what to do against that. Any hints?


Top
 Profile  
 
PostPosted: 07 Nov 2010, 23:05 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
LordAlien wrote:
Code:
g++ -Wall -m32 -ansi -I../../Common/rt\ api -O3  MemoryPool.o Public.o RTI2Reader.o RTIReader.o RTReader.o  converti2.cpp -o converti2
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.2/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [converti2] Fehler 1

I have installed following packets matching libstdc++:
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
ii libstdc++6-4.3-dev 4.3.2-1.1 The GNU Standard C++ Library v3 (development
Never had such an error, so I have no idea what to do against that. Any hints?


You had me scratching my head as well with this one until I noted /usr/lib/gcc/x86_64-linux-gnu and wondered if it was yet another 32-bit compat package you lacked. I believe it's this one: lib32stdc++6.

Just to be safe here is the list of '*32*' packages I have installed:
ia32-libs
lib32gcc1
lib32stdc++6


Top
 Profile  
 
PostPosted: 07 Nov 2010, 23:10 
Offline
Total Hash Enlightenment

Joined: 15 Jul 2009, 22:38
Posts: 1483
Location: Dallas, TX, USA
Ok just this time I've created a static build of converti2 for linux x86/x86_64 that also has a static libgcc. This is the same method we use to created distrrtgen clients. If all else fails anyone wishing on linux to try converti2 and running into compilation difficulties can try this binary. Though, documenting the required libraries is probably a good idea too :P


Attachments:
File comment: converti2 statically compiled for linux x86/x86_64
converti2_linux.zip [309.39 KiB]
Downloaded 283 times
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group