Developing #13 revealed there is a race condition in the engine where the engine exits before receiving a correct password from a producer, despite it eventually sending one.
Running
env LOG_LEVEL=info cargo run --release -- --filename examples/datetime-15012000.pdf date 1900 2000
does not successfully crack the PDF, while
env LOG_LEVEL=info cargo run --release -- --filename examples/datetime-15012000.pdf date 1900 2001
succeeds despite this generator sending passwords inclusively. I suspect there is a bug somewhere else that will need to be investigated
Adding debug logging to the DateProducer next() function shows the correct password is being sent but not recognized.
2023-12-03T21:34:13.151Z DEBUG pdfrip::core::production::dates > Sending 15012000 from DateProducer
This means there is a race condition somewhere. Likely in engine.rs.
I imagine the bruteforcer should be simplified since it is currently complex, clunky, inefficent and annoying.
Developing #13 revealed there is a race condition in the engine where the engine exits before receiving a correct password from a producer, despite it eventually sending one.
I imagine the bruteforcer should be simplified since it is currently complex, clunky, inefficent and annoying.