Key Takeaways
Block Hash Scan is a feature of MD-LIVE, an on-site triage solution that determines whether illegal files are present on a device without full data imaging.
Block Hash Scan divides a file into blocks and compares the hashes block by block. Because it reads only the blocks it needs, it can identify illegal files without reading the entire file.
The scan runs in two steps: a quick scan that picks out suspicious files, followed by a full scan that checks only those files in depth. Within the active hash set and the scan areas the product supports, suspicious files are not missed.
Introduction
The decision cannot wait for the lab
In digital forensics, investigators have to judge quickly whether a device is relevant to a case. In practice, the analysis results needed for that judgment become available only after the device is seized, imaged, and reviewed in the lab. This creates a gap between the moment a decision is needed and the moment the answer arrives.
Smartphone storage now exceeds 512GB, and a single device can hold tens of thousands of photos and videos. Imaging takes considerable time, and the wait time increases with every additional device. This leads to situations where devices of unclear relevance are seized in the field, increasing the burden on the examiners who handle them.
If an investigator could confirm at the scene, with the device connected, whether the target files are present, the decision-making process would change. Devices with a clear link to the case could be prioritized, and only those devices would go forward for analysis.
The limits of existing approaches in the field
Full-file hash comparison
The most common approach is to build a list of MD5 or SHA hash values and compare it against the hashes of the files on the device. The principle is simple, but a full-file hash requires reading every byte of a file from beginning to end, which is hard to sustain in the field.
For example, to calculate the MD5 hash of a 4GB video, the entire 4GB must be read. If a device contains 300GB of media files, it essentially means reading the full 300GB. This data is transferred from a smartphone connected via USB. Consequently, the scanning time increases in proportion to the amount of data stored on the device. Ultimately, it is a structure where all files must be read just to find a single target file.
Manual review
Another approach is to open the gallery and review the photos and videos by eye. With 12,000 photos, even one second per image adds up to 3 hours and 20 minutes, and the chance of missing something rises with the volume of material. When the material is illegally filmed content, viewing it is itself a burden on the investigator, and repeated manual review compounds that burden.
Identify without reading full file
The Block Hash Scan feature in MD-LIVE addresses the limits of these traditional methods. Instead of assigning one hash value to one file, Block Hash Scan divides a file into fixed-size blocks and calculates a hash for each block. Confirming whether a file is a target file therefore does not require reading the file in full. The scan reads the necessary blocks and compares them against a hash set prepared in advance.
As a result, identifying a 4GB video requires reading almost the same amount of data as a 40GB video. The primary advantage of the block hash approach is that the verification cost doesn't scale up linearly as files get larger.
How to use Block Hash in MD-LIVE
Connect, wait, and export results
To use Block Hash Scan, run MD-LIVE. The overall workflow consists of three steps: Connect Device, Scan Device, and Check Results.
Step | Screen | What investigator does | What MD-LIVE does |
|---|---|---|---|
Step 1 | Connect Device | Selects the operating system (OS) and connects the device over USB | Detects the device, checks the active hash set, and moves to the next step once the connection succeeds |
Step 2 | Scan Device | Monitors progress and stops the scan if needed | File collection → Detect suspicious files → Check suspicious files in depth, and displays progress |
Step 3 | Check Results | Reviews the detected results and exports | Reports the number of files examined, the number of files detected, the elapsed time, and the file list |
The scan starts automatically once the device is connected. While it runs, the number of files examined and the number of detections update in real time. Even if the investigator stops the scan or if the cable is disconnected and the task is interrupted, the list of files detected up to that point is retained.
When the scan finishes, summary cards show the number of files examined, the number of files detected, and the elapsed time. The detection list also becomes available for review. Reports can be exported in the following two formats:
Report (PDF, Excel): Saves the scan results as a document for the investigation record.
File list (MBR): Saves the detection list as a
.mbrfile. Re-importing that file into MD-LIVE carries the selection made in the field straight into detailed analysis.
Because the list does not have to be rebuilt between the scene and the lab, the triage result carries into the follow-up analysis.
Prepare block hash set before deployment
The scan uses a block hash set with the .mbh extension as its reference. Designate the folder containing illegal files as the ‘Scan folder path’, and set the destination folder for the calculated block hashes as the ‘Block hash set save path’. Clicking [Block Hash Set Creation] computes the block hash for each file in the scanned folder and generates a .mbh file in the specified save path. Once registered in MD-LIVE, investigators can select only the items relevant to the case.
Field environments assume offline use with no internet connection. Because hash sets cannot be downloaded or updated on-site, investigators need to prepare the required reference files before deployment.
How Block Hash scan works
For an on-site triage tool to be effective, several conditions must be met at the same time. It must rapidly identify large files, efficiently scan the entire storage, avoid missing target files, and preserve the original data without modifications. Block Hash Scan satisfies these requirements as follows:
It does not read the entire file
When identifying illegal files by comparing full hashes, the primary factor determining scan time is total data volume. Inspecting 100 videos of 4GB each requires reading 400GB of data. In an architecture where a single hash is assigned per file, the hash value can only be calculated after reading every file down to its final byte.
With block hashing, the verification cost does not increase as file sizes grow. Because hashes are managed by dividing the file into multiple blocks, MD-LIVE only needs to read the specific blocks required to verify a target file. As file sizes increase, the performance gap between this method and full-hash scanning becomes significantly wider.
Detect suspicious files first, then Check suspicious files in depth
Block Hash Scan operates in two steps: ‘Detect suspicious files’ and ‘check suspicious files in depth'. First, detect suspicious files searches the storage area and picks out suspicious files. Then, check suspicious files in depth checks those files in depth.
By running the detailed scan only on suspicious files instead of the entire drive, overall processing costs are kept low. This sequential workflow, where check suspicious files in depth follows detect suspicious files, is also reflected in the progress bar.
Detect suspicious files applies broader evaluation criteria to establish a wide candidate pool for suspicious files. Files excluded at this first step are not examined again later, so files that match only in part are still passed to the next step. The purpose is to keep processing costs down without dropping target files.
False positives can occur. False negatives do not.
In a structure that reads only select blocks rather than the entire file, the verification criteria become relatively lenient. Block Hash Scan permits any resulting margin of error in only one direction.
Type | Occurrence | How to read the result |
|---|---|---|
False positive: A file that is not a target is detected | Can occur | The detection list is treated as suspicious files that require follow-up review |
False negative: A target file is not detected | Does not occur by design | Zero detections means no such file exists under those criteria |
A file may appear suspicious because one of its blocks coincidentally matches a block in the hash set, but a target file is not missed. If a file is registered in the hash set, the blocks read from it match, so the file is not omitted from the detection list. The structure removes the possibility of omission at the cost of reviewing additional files that are not targets.
This is not merely a statistical tendency toward high detection rates, but a structural characteristic stemming from the comparison logic itself. Consequently, using the same hash set and scan scope will consistently lead to identical conclusions, regardless of when the inspection is performed.
In a field triage tool, this asymmetry holds significant practical importance. False positives can be filtered out during the investigator's manual review. False negatives, however, cannot even be detected. Once a device is ruled out from an investigation, it is unlikely to be re-examined. To trust a result that reports no suspicious files, detection reliability matters.
However, the boundary within which this premise holds must be clearly defined. The results are strictly based on the files registered in the active hash set, as well as the scan areas and file formats supported by the software. It does not imply that unlisted files or data outside the scan scope do not exist. The same applies if a scan is interrupted.
The overall reliability of a field triage result therefore depends not only on the method but on the hash set’s recency, its coverage, and whether the scan completed successfully.
The original data on the device is not altered
Original device data is not altered during the scanning process. While Android and iOS access device data through different mechanisms, the underlying principle remains the same: reading necessary files for identification.
MD-LIVE does not copy original detected files to the investigator's PC either. Instead, it gathers only the metadata needed for analysis, such as file paths and sizes. Because no separate copy of illegal files is created, there are no additional copies to manage, and the field output is the triage result alone.
Checklists in practice
Before deployment
Create the block hash sets required for the case in advance and add them in MD-LIVE.
Keep
.mbhfiles separated by case type so that only the hash set needed can be activated quickly.Confirm before scanning that the intended hash set is active.
At the scene
Confirm that the connected device matches the OS selected in MD-LIVE.
Check the supported OS versions (Android: 12 or later / iOS: all versions) and the device connection requirements beforehand.
On iOS devices, check the auto-lock setting so that the device does not lock or lose the connection during the scan.
Keep the USB connection stable until the scan finishes.
If a scan is interrupted, the results up to that point remain available for review and export. A partial result should be interpreted separately from the result of a completed scan.
When reviewing results
The detection list should be treated as a subject for review rather than a final conclusion. Exporting the list as an .mbr file and continuing subsequent analysis in MD-LIVE offers the most efficient workflow.
Even when the detection count is zero, retaining a formal report is recommended. Because false negatives do not occur by design, a result of zero items can be used as a finding that no target files existed within the stated inspection criteria. Documenting the target device alongside the active hash set, scan scope, and completion status clearly substantiates 'what criteria were used for the inspection and what results were obtained.'
Conclusion
Block Hash Scan brings the decision earlier
With Block Hash Scan, investigators no longer need to image the full data of a 512GB smartphone and wait for analysis results simply to verify the presence of specific files. Block Hash Scan triages files by reading only the necessary blocks rather than entire files, performing detailed verification exclusively on those selected as suspicious.
The workflow from device connection to result export proceeds through three steps, ‘Connect Device’, ‘Scan Device’, and ‘Check Results’, preserving original device data without modification throughout the process. Results generated on-site can be saved as an .mbr file to continue follow-up analysis in the forensic lab.
Beyond simply reducing scan times, Block Hash Scan holds significance by enabling decisions previously restricted to the forensic lab to be made directly in the field. Investigators can triage targets based on concrete evidence, allowing forensic labs to allocate resources strictly to devices requiring actual review. Furthermore, it enables preliminary triage without requiring investigators to manually view psychologically burdensome materials, such as illegally filmed content.
Field triage goes beyond merely identifying a large volume of files. It empowers investigators to prioritize which devices require analysis within time constraints, backed by reliable evidence. Because target files are not missed within the stated scan criteria, both detection and non-detection results carry weight in the decision. Block Hash Scan is the technology built to execute these decisions faster and with greater consistency.
