Extract embedded files

It starts at every offset where a known signature matched, and it ends at the next such offset or at the end of the file. That is the honest ceiling of a signature scan with no per-format parser: real end markers such as a PNG IEND chunk, a ZIP end-of-central-directory record or a JPEG FFD9 are not looked for. A carved segment can therefore run long, carrying padding or unrelated bytes after the real file.

The source name, the start offset in hex, and the signature type, all joined with dashes and ending in .bin. A ZIP found at 0x2a1c inside photo.jpg comes out as photo.jpg-0x2a1c-zip-archive.bin. Every segment gets .bin regardless of what it holds, so rename it before opening it in the application that reads that format.

Because it found at most one signature. With none, the message says no signature was found; with one, it says only one signature, the file's own header, was found. Either way there is no second boundary to cut at, so nothing separate exists to extract. Run Scan for embedded files first to see the full match list before assuming a file is clean.

Because short signatures match by chance. Two-byte patterns like BM and 1f 8b appear constantly inside compressed data and images, and each one becomes a carve boundary. Check each segment with Detect file type before treating it as a find, and discard the ones that do not identify.

Only if the bytes are still in the file you dropped and still start with a signature this table knows. There is no filesystem parsing, no slack space handling and no repair of a damaged header. A segment carved from the middle of a file is a best-effort copy of a byte range, not a verified recovery.

Scan for embedded files, which lists every signature offset without producing any files. Once you know what is where, either carve everything here or cut one exact range with Take bytes, which is the more precise option when you know where the payload ends.