A 40-bit exhaustive search takes several hours depending on hardware. If the app is closed mid-run — intentionally or not — all progress is lost and the search has to restart from key 0. This was raised by a user in #20.
The idea is to periodically write the current search offset to a small sidecar file next to the loaded .bin (e.g. mypayloads.bin.progress), and on next launch, if that file exists and the config matches (same .bin, same key range), offer to resume from where it left off rather than starting over.
The file only needs to store the last committed offset — the engine already tracks keys_tested and start_key, so it's just a matter of flushing that to disk every N seconds and reading it back on start.
Where to look: src/bruteforce.cu — the cuda_launcher_thread and CPU worker loop for the write side. src/gui.c — the start-search handler for the read/prompt side. A simple text file with offset=<uint64> is enough; no binary format needed.
A 40-bit exhaustive search takes several hours depending on hardware. If the app is closed mid-run — intentionally or not — all progress is lost and the search has to restart from key 0. This was raised by a user in #20.
The idea is to periodically write the current search offset to a small sidecar file next to the loaded
.bin(e.g.mypayloads.bin.progress), and on next launch, if that file exists and the config matches (same.bin, same key range), offer to resume from where it left off rather than starting over.The file only needs to store the last committed offset — the engine already tracks
keys_testedandstart_key, so it's just a matter of flushing that to disk every N seconds and reading it back on start.Where to look:
src/bruteforce.cu— thecuda_launcher_threadand CPU worker loop for the write side.src/gui.c— the start-search handler for the read/prompt side. A simple text file withoffset=<uint64>is enough; no binary format needed.