Display cracking progress in solve_bs and port to OS X

[unkernet]

In OS X there is no malloc.h, sysinfo.h and futex.h, so I have made some changes. Also I have add progress display to solve_bs like in libnfc_crypto1_crack.

[aczid]

Wow, this is some great help! Thanks a lot, I don't have a mac myself. Unfortunately you violated craptev1's license by lifting that readnonces function. Its 4-word license states "No redistribution. No modifications.". This was the reason for the awkward solve.so construction. If you either a) re-implement the function from scratch b) reintroduce solve.so or c) find a better way to link it in from solve.c, I will definitely merge this!

[unkernet]

Are you sure that the license applies to the readnonces function? It's almost the same to the solve_piwi implementation.

[aczid]

I'm sure, the author is adamant about this. The other function is my own code I wrote from scratch. You're free to use it as a template. Sorry to get nitpicky about this but I want to respect the license.

[unkernet]

OK, I've re-implement it.

[aczid]

Thank you, that's great. However I can't build it on my linux without adding -lm to the build line for the solve_bs/solve_piwi_bs binaries. BTW, what do you mean by the comment Fix a "1000000% bug". Looks like here is a problem with OS X gcc? In particular, what led you to conclude it's a compiler issue?

[unkernet]

Yep, you are right.

In some cases there is very large value in bucket_size[block_idx]. At the same time, condition (block_idx == 0 && bucket_size[block_idx] != bucket_size[0]) can become true. So I think this is can be a bug and I can't find another way to fix it.

[aczid]

I don't really understand what is happening on your end, but the fix looks a bit shady to me. Could you try to resolve the issue by patching the bucket sizes when they go into bucket_size rather than when they come out? Would at least avoid mixing that workaround logic with the counting logic, and looks to be more concise.

[unkernet]

There is no issue when values are come in. I could write bucket_size[bitsliced_blocks] =MAX_BITSLICES and get same issue while counting. On the other hand, when I trying to write if (bucket_size[block_idx] > MAX_BITSLICES) bucket_size[block_idx] = MAX_BITSLICES; I've got an segmentation fault error. Believe me, I spent a lot of time trying to figure it out.

OK, here is another solution. I could write bucket_size[block_idx + 1] everywhere and it will be also a working solution. Do you like it better? 😉

[aczid]

Well I just meant that, rather than applying a fix for the (sometimes) bad data you get out of bucket_size elements, you apply that fix a few lines beforehand so as to avoid cluttering the code there with this problem, and it looks like you'll only need one instance of that ternary operator in the workaround. I do believe this was hard to debug, and I appreciate the effort!

[unkernet]

Well, I think I understand you. Not it looks better.

[aczid]

That'll do. Thanks for working on it a bit more. I think it's time to merge this.