11-30-2022, 09:20 PM
I think I should say something more about my idea.
Qlocker has encoded some important data for me, so I have to wait for the solution or try to do something myself. I know... with a 32 character password it is a waste of time, but there are also winners in the lottery, so my idea... try random passwords.
The first problem was, how to save already checked random passwords???. The Lehmer algorithm is the solution. This algorithm with an appropriate Increment parameter is able to generate unique passwords. In addition, algorithm allows resume session, and divide the entire pool of passwords into many smaller ones to run decoder on several machines, without fear of checking the same passwords again.
Here another problem appeared, very large numbers, in the case of 32 character password it is 62^32 = 2272657884496751345355241563627544170162852933518655225855 :-)
This is far above the Decimal variable accuracy. In addition, the calculations at Decimal are slow, so I had to get around it in some other way.
I wrote a calculator that transforms the string-number into a Long list, performs something like the Written Method Calculations, then the Long list (result) turns into a string. In this way I am able to perform accurate calculations on numbers to the maximum length of the string chain. In the next step the result is transformed into a password.
In other words, the password is the number (Password-Number) generated by Lehmer algorithm and transformed into a N-system, depending on the number of characters in the password, in my case decimal to 62-system. So...
0 is 00000000000000000000000000000000 and
2272657884496751345355241563627544170162852933518655225855 is zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
The program can transform passwords into the number and numbers into the password, and this was used in the generator test mode to check if all functions give correct results.
Only in the 7z mode, the generated passwords go directly to the command line, for HashCat and JohnTheRipper, dictionaries are created, which size can be set for HC and JTR separately. In addition, after starting HC or JTR, new dictionary is created, this way there are no breaks between HC/JTR sessions. The last checked iteration is saved in the SessionProgress.txt file, where maximum iteration for a given pool is also determined.
To set Increment, I used the power function, in my case Base = 3, Power = 108 (3381391913522726342930221472392241170198527451848561) this way next password is very different from the previous one, but then Iteration !=Password-Number. However, both parameters can be set to 1, passwords will be generated in normal order (0000, 0001, 0002 a.s.o), and then Iteration == Password-Number.
Knowing Iteration and Increment, you can always count the last Password-Number, which is seed for the next Password-Number.
To make the generator faster, almost all calculations are performed on the List<long>, I skipped unnecessary conversions string <-> List<long>.
I think it is worth to test, whether in the case of shorter passwords, the random method will be faster than classic. I think it should, especially if the password is at the end of the pool.
Qlocker has encoded some important data for me, so I have to wait for the solution or try to do something myself. I know... with a 32 character password it is a waste of time, but there are also winners in the lottery, so my idea... try random passwords.
The first problem was, how to save already checked random passwords???. The Lehmer algorithm is the solution. This algorithm with an appropriate Increment parameter is able to generate unique passwords. In addition, algorithm allows resume session, and divide the entire pool of passwords into many smaller ones to run decoder on several machines, without fear of checking the same passwords again.
Here another problem appeared, very large numbers, in the case of 32 character password it is 62^32 = 2272657884496751345355241563627544170162852933518655225855 :-)
This is far above the Decimal variable accuracy. In addition, the calculations at Decimal are slow, so I had to get around it in some other way.
I wrote a calculator that transforms the string-number into a Long list, performs something like the Written Method Calculations, then the Long list (result) turns into a string. In this way I am able to perform accurate calculations on numbers to the maximum length of the string chain. In the next step the result is transformed into a password.
In other words, the password is the number (Password-Number) generated by Lehmer algorithm and transformed into a N-system, depending on the number of characters in the password, in my case decimal to 62-system. So...
0 is 00000000000000000000000000000000 and
2272657884496751345355241563627544170162852933518655225855 is zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
The program can transform passwords into the number and numbers into the password, and this was used in the generator test mode to check if all functions give correct results.
Only in the 7z mode, the generated passwords go directly to the command line, for HashCat and JohnTheRipper, dictionaries are created, which size can be set for HC and JTR separately. In addition, after starting HC or JTR, new dictionary is created, this way there are no breaks between HC/JTR sessions. The last checked iteration is saved in the SessionProgress.txt file, where maximum iteration for a given pool is also determined.
To set Increment, I used the power function, in my case Base = 3, Power = 108 (3381391913522726342930221472392241170198527451848561) this way next password is very different from the previous one, but then Iteration !=Password-Number. However, both parameters can be set to 1, passwords will be generated in normal order (0000, 0001, 0002 a.s.o), and then Iteration == Password-Number.
Knowing Iteration and Increment, you can always count the last Password-Number, which is seed for the next Password-Number.
To make the generator faster, almost all calculations are performed on the List<long>, I skipped unnecessary conversions string <-> List<long>.
I think it is worth to test, whether in the case of shorter passwords, the random method will be faster than classic. I think it should, especially if the password is at the end of the pool.