Threat Razor

This tool was inspired by ThreatCheck. The difference here is I had a need for a tool that could test other, non-Defender AV solutions so I needed an agnostic tool. This came with the tradeoff that automated scanning isn't guaranteed since the AV isn't known. The tool relies on the user manually checking for scan results and giving the answers back to the tool.

If you are just testing the binary against Defender, use ThreatCheck. Although Threat Razor can test against Defender, ThreatCheck is designed with Defender in mind so scanning is significantly faster.

Usage

Use -h for the small help menu.

./threatrazor -s [source] -d [destination]

-or-

.\threatrazor.exe -s [source] -d [destionation]

Explanation

This tool helps dissect binaries on a byte level and places the slices in a directory of the users choosing.

The user then checks to see if that slice is flagged by whatever AV tool they are wanting to test against either by automatic scanning, real time scanning, or by manually initiating a targetted scan, whatever is appropriate for the tool.

The source binary needs to be placed in an excluded directory to prevent conflicts when scanning.

Phase 1: Slicing

When the tool is intially kicked off, it will cut the target binary in half and begin testing halves. It'll ask the user if the section was flagged by whatever AV tool they have chosen. If the half was not flagged, the tool will flip to the other half and test again. If the current half was flagged, the tool will cut the current slice in half again and retest.

After the user answers no twice, meaning neither of the two current halves have been caught, the tool will take the last caught total slice and move into Phase 2.

Phase 2: Refinement

This phase takes a bit longer. It will continue to ask the user if different slices are caught but instead of cutting in half, it will now start cutting smaller and smaller increments of bytes off the end of slice. Refining down until, ideally, the exact byte that ends the signature is flagged.

Complete

Once the last byte is identified from the refinement phase, a hexdump is produced of the flagged section including the preceding 256 bytes. The hex and offset can be used in a decompiler like Ghidra to find the section of source code that caused the alert.

Notes

The tool will only flag one alert at a time so this process must be repeated after modifying the source code.

Non-AI Disclosure

No AI was used in any way shape or form during the creation of this software with the caveat that I cannot speak for any of the third party crates this project uses. I guarantee that I did not use any AI for any of the code I wrote.