Closed jonathanferreiras closed 2 months ago
Gentlemen, I found something that I'm confused about.
When looking for challenge 10, it is in the 200:3ff range, but when using the command:
./keyhunt -m address -f tests/10.txt -b 10 -l compress -R -q -s 10 -t 11
the same is not found.
Now if I change to 9 bit. The range is wrong and you can find it.
How did you find an out of reach key? And why is it giving an error in the right lane?
Thanks.
Well, even one processor thread captures a larger range than is specified for search! Would you also conduct experiments in the 5-bit range with a 96-core processor))
I believe I was confused. The number of bits would not be the challenge number, but rather how many bits are left to find? Example, in challenge 66 I would put how many bits? And how would you know the number of bits of the next challenges?
Default subrange thread is 0x100000000 so every thread start from your initial range to that value plus 32 bits. Let's to said 0x100 to 0x100000100 -1 First thread Second thread is from 0x100000100 to 0x200000100 - 1 Etc..... Minimum sub range value is 0x400 This is -n 0x400 or -n 1024
Any value lower than it it's inefficient. So in your case you should chose values larger than 32 bits or set your -n value to 0x400 and you minimum range from 0x100 to 0x500 and number of threads to 1 -t 1 or not -t at all defual thread number is 1.
About the -b 9 or -b 10 you should tell us what address you targeted to check if the range is 9 or 10 bits
Thank you my friend. Now I understand. Congratulations on the project.
Gentlemen, I found something that I'm confused about.
When looking for challenge 10, it is in the 200:3ff range, but when using the command:
./keyhunt -m address -f tests/10.txt -b 10 -l compress -R -q -s 10 -t 11
the same is not found.
Now if I change to 9 bit. The range is wrong and you can find it.
How did you find an out of reach key? And why is it giving an error in the right lane?
Thanks.