After some testing, it appears to be from a function that pauses/resumes findcrcs.exe. Normally a front end would wait for the tool to finish and process the resulting console-output.  But if findcrcs is scanning for a track that is all 00s, it will often return thousands of hits and take forever to finish. To overcome this long wait, my frontend monitors findcrcs output, when some results have been found, pauses findcrcs, tests the result's MD5, and it there is a match, terminates findcrcs, or if there is no match, resumes findcrcs and continues to wait.

This 'pause exe' function is built into Windows, you'll find it near the bottom of the source code as  'Func _ProcessSuspend()' and 'Func _ProcessResume()'. Apparently the virus scanners think using it means you're up to no good. I 'commented out' these two functions and VirusTotal went down to 2 no-name positives.

It's rather heavy handed for virus scanners to alert on anything using the pause function, but anyways, I'm submitting a false positive notice to a few of the bigger name companies. We'll see what happens.

This tool is written in Autoit language. Autoit doesn't compile the script into machine code, but stores it internally in an executable wrapper. Since all Autoit scripts share the same wrapper, it's fairly common for the language to produce false positives. You can read about it HERE. I have Comodo anti-virus, and for whatever reason, it alerts every now and then when I'm compiling one of my AutoIt scripts.

I know we live in an age when people can't really be trusted, but for what it's worth, I give my word that I wouldn't produce anything like a virus.

On a side note, after I made this front end, I found that someone else had already made a similar tool HERE. If you're still worried about the false-positive, it's a very good alternative. I prefer the smaller footprint of my version, but the built in tools in the other front-end are very nice too.

As far as changes in the GUI, I tested on about 30 BINs from my garbage folder of bad dumps and fixed several bugs, some significant, some only triggering on rare random factors. Hopefully it'll be useful to someone.

The v0.3 findcrcs appears to have bugs (not the GUI but findcrcs itself). I confirmed that t doesn't detect CRCs in some files as it should. It will not detect Track1 of the game HERE , but v2 does.

The frontend currently seems to work with track-info copied from Firefox, Midori and Opera v12.18.

By the way, I am neither the author nor did I change comething in the code of findcrcs. It just happened that the link to v2 was unavailable for some time, so I searched the www for the file and found the updated source on github. I couldn't get it to compile under Windows and in the end I used Ubuntu with Win64 target settings.

EDIT See post 15 for GUI

@rosewood I tried your build on some larger ISOs. It rejects some large windows with a message, but runs on some ~4GB images and incorrectly lists no matching CRCs. It would be better to add a limit message to my GUI that have it erroneously report ' no match'. Do you know what the size cap for an accurate scan is?

I use findcrcs mostly to extract the split-tracks from a multi-track game that I dumped into a single image. Its easy to make a frontend to search for one track at a time from user input size/CRC, but it's miserable to enter all that information for a game with 40 tracks. So the question is how to automatically parse a game listing, automatically extracting size/crc, in a way that's compatible all the listings here. I've used my fromend for PS1 game listing extensively with no problems.

The upgrades in your v3 are quite useful.

So I compiled v3 of findcrcs for win64, you can download it here: findcrcs-0.3-bin-win64.7z
This new Version also supports extract from the command line:

Usage: findcrcs [OPTION]... [--] <FILE> <WINDOWSIZE> <CRC> [MD5] [CRC [MD5]...]

Find the offset of CRCs in FILE with a window size of WINDOWSIZE.
Outputs the crc, offset and md5 of a found segment.
If an MD5 is given, it will only output or extract on a matching md5 hash.

  -e              extract the found segments with the md5 hash as filename
  -f EXTRACTFILE  use EXTRACTFILE as file to extract to
                  implies -e and -q
  -p PADDING      use PADDING amount of zero bytes around the input file
                  this can result in a negative offset in the results
                  if used with -s only an end padding will be added
  -q              quit processing after finding a match and optionally
                  extracting that match
  -s SEEDFILE     get an initial crc from SEEDFILE
                  if used with -e, the SEEDFILE will be joined with the found
                  segment

In case it helps anyone else, it is HERE. Source code (Autoit) included.

EDIT Link Updated to v7

Agree with pablogm123: match finding is very fast.

This is the test I have performed:

I have extracted, using IsoBuster (no offset correction, no error detection for audio...), a full image of this audio disc I dumped in the past. Then, I have run findcrcs.exe "image.bin" 95020800 dd0e562e. After 10-11 seconds (I own a budget CPU), findcrcs has found two fragments with matching CRC32 (I assume due to hashes collisions), the second one with the expected MD5 hash.

G:\>findcrcs.exe "image.bin" 95020800 dd0e562e
120031802  dd0e562e  87ac7985fcc46286efc5c0876f723e5e
619521696  dd0e562e  8855ffc1921ec4e5d7536272ced3d989

Is there any chance of adding an option to output any found fragments to a new file(s)?
e.g.