I have developed an Excel spreadsheet to compare lists of SHA-512 hashes from two separate drives. One drive is the source data drive on a Windows machine. The other is a backup of that drive, connected to a Linux machine. I obtain the hashes on Windows using DirHash, and I obtain the hashes on Linux using rhash.

The purpose of this comparison is to identify differences between files presently on the data drive and files that were previously on the data drive, as reflected in the backup. The spreadsheet uses the hash lists, plus a DIR list of files, to identify file names, paths, dates, and other information that may help the user to decide whether there is a good reason why an old file (listed on the backup) no longer exists on the data drive, or why a new file (listed on the data drive) did not exist in the backup.

The idea underlying this comparison is that the predominant form of ransomware encrypts a file and then decrypts it on the fly, to make it available to the user, without alerting the user that the file could be permanently encrypted at any moment, as decided by the ransomware or its creator. Presumably the hash values capture the difference, between the user's original file and the file as modified by ransomware; presumably the air gap between these Linux and Windows machines (imperfect though it be) makes it difficult for ransomware to prevent the spreadsheet from highlighting that difference.

Those thoughts may be flawed. I welcome feedback on them. I mention them because this concept has the great drawback that calculating hashes for large numbers of files takes a lot of machine time, during which access to the data drive is inhibited; and then it takes a lot of user time to work through the spreadsheet, wait for Excel to run its lookups and other formulas, sort the results, and arrive at conclusions.

So we come to my question. While researching and writing up this solution, I encountered indications that PowerShell may have the ability to detect changes to files within a folder in real time, without requiring a full rehashing of every file in the folder or on the drive. Possibly other tools have a similar ability.

Ideally, such an ability would greatly improve detection of changed hash values. Instead of a cumbersome, spreadsheet-based, full-drive hashing procedure that the user can only bear to run once a week, the user might be automatically notified of files whose hash values have changed within the past hour, or at least within the past 24 hours - using, in that case, the previous hash values on the source (Windows) drive, without requiring constant reference to the (Linux) backup drive.

My question: assuming the concept makes sense, is there an existing tool or method that could automate or at least speed up comparison of hash values from two different drives, for purposes of ransomware detection? The question obviously excludes using (say) a Windows program to directly compare the source drive and its backup, lest ransomware on the Windows system corrupt the backup.

  • 3
    "[the ransomware] decrypts it on the fly, to make it available to the user". This will of course also happen when you read the file to recalculate the hash. The hash won't tell you when the ransomware has encrypted your files.
    – Jeff
    Feb 18 at 16:06
  • Do I feel foolish. Well, I'm glad I asked. Now it seems I may be asking several different questions - but let me make sure they make sense: (1) Is there a tool that detects changes to specific files within a folder in real time, regardless of hashing? (2) Does on-the-fly decryption impose a detectable delay, such that hashing some substantial number of files is recognizably slower with vs. without ransomware? (3) How does hashing work in the case of an encrypted file whose contents are not available to be read? Feb 19 at 20:00
  • I have broken out that third question in a separate Stack Exchange entry. Answers to it so far seem to say that Jeff's comment is incorrect. A very real alternative possibility is that I am still not understanding this clearly. See separate question: crypto.stackexchange.com/questions/98731/… Feb 21 at 13:20


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.