Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto1_bs parallel instances #6

Open
sibero80 opened this issue Oct 29, 2018 · 2 comments
Open

crypto1_bs parallel instances #6

sibero80 opened this issue Oct 29, 2018 · 2 comments

Comments

@sibero80
Copy link

sibero80 commented Oct 29, 2018

Hello everyone. I'm by no means a programmer, but I think I've discovered a way to improve miLazyCracker's speed.

  • unkernet has a crypto1_bs fork that uses nonce appending and storing.
  • Cracking using crypto1_bs method is slow, so meanwhile the intensive CPU cracking is happening, parallel instances of crypto1_bs can happen only to collect nonces.
  • Rate of cracking speed and nonce collection could be calculated to dynamically set the nonce collection thereshold in order to reduce complexity as much as possible but also to be able to capture as much sector data as possible for when CPU power is available.

I've been doing this manually (Running crypto1_bs instances in parallel) with great results.

Too crazy?

@doegox
Copy link
Member

doegox commented Oct 29, 2018

Can you elaborate how to automate this approach?
From what I understand, nonce collection is pretty fast compared to cracking a limited number of nonces so, yes, you could start cracking as soon as you've e.g. a complexity of O(2^43) and continue collecting nonces meanwhile but then, what do you do once you've O(2^37) a few minutes later? Drop all current computations and start over? I'm looking for scenarios where it's on average substantially faster to do something else than waiting O(2^37) then running the CPU-intensive part.
BTW the Proxmark implementation is apparently today faster and a better way to improve speed would be probably to lift it off and reuse it with libnfc.

@sibero80
Copy link
Author

Sure thing:

Mi pn532_uart collects around 15-20 nonces/sec, and once the complexity is around O(2^37) it takes at least 10-15 minutes to try cracking a key. If complexity is lower it can even take around 5 minutes. (I'm on a VM machine running over a i7-3230qm. Not the fastest, nor the slowest.)

So the automation would go something like this:

  1. Run first instance of crypto1_bs and start collecting nonces. (crypto1_bs_instance_1)
  2. When crypto1_bs_instance_1 nonce collection stops and cracking starts, then another crypto1_bs instance (crypto1_bs_instance_2) is launched for the next sector.
  3. If nonce collection on crypto1_bs_instance_2 gets the complexity to O(2^37), then stop collection nonces for current sector and start collecting nonces for next sector. LOOP.
  4. If crypto1_bs_instance_1 cracking is successful, then, crack next sector with nonces already collected (here there wold be necessary to modify crypto1_bs, because even if nonces are stored, it tries to collect a couple hundred more before trying to crack, this would collide with crypto1_bs_instance_2 nonces collecting).
  5. if crypto1_bs_instance_2 finishes collecting nonces for all sectors up to a complexity of O(2^37), then check if crypto1_bs_instance_1 is not collecting nonces, and then start to collect more nonces for remaining sectores to bring the complexity down even more and speed up cracking.

Sometimes, I got distracted and the second crypto1_bs instance began cracking, and by some reason, the second instance finished cracking faster than the first crypto1_bs instance that was running.

I hope I provided enough clarity.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants