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.

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..

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:

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.

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.

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

I have installed following packets matching libstdc++:ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3ii libstdc++6-4.3-dev 4.3.2-1.1 The GNU Standard C++ Library v3 (developmentNever 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-libslib32gcc1lib32stdc++6

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

Who is online

Users browsing this forum: No registered users and 1 guest

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