masscan output file empty after authorized scan failed to write results

Not specified by the original author.

TL;DR

Masscan holds results in memory and writes the output file when the scan finishes, so a crash, a kill, or a full disk leaves a 0-byte file. Always write a live text log alongside the binary output, then re-run in smaller rate-limited chunks so a failure costs minutes instead of the whole scan.

(output file is 0 bytes after masscan exits abnormally)

Use this when

• -oB scan.bin or -oX scan.xml exists but is empty after an interrupted authorized scan.
• You need the partial results back or a safe way to re-run.

Not for this skill when

• Masscan completed and reported zero open ports. An empty result set is a finding, not this bug.
• The file has content but will not parse. That is corruption, a different fix.

Steps

1. Confirm the file is truly empty and the scan died early: ls -la scan.bin, and check whether any masscan process is still alive. Verify: 0 bytes and no running process means the flush never happened.
2. Check the boring causes first: df -h on the output filesystem and write permission on the directory. Verify: the disk is not full and the file is writable before re-running.
3. Re-run with dual outputs: -oB scan.bin -oL scan.log. Verify: the text log grows during the scan, so even another crash leaves you the live results.
4. Split the range and lower the rate: scan the subnet in halves at a moderate rate instead of one giant fast run. Verify: each chunk finishes and writes its own complete file.
5. Merge chunk logs by concatenating the text logs and de-duplicating the host and port lines. Verify: the merged set matches the sum of the chunk counts.

Variant phrasings

masscan binary output empty file

The -oB-specific phrasing.

masscan killed output not saved

The interrupted-scan phrasing.

masscan xml output 0 bytes

The -oX-specific phrasing.

Compatibility: masscan 1.3.x. The binary, XML, and list outputs all flush at exit; only the list log streams usefully during the run.

Why it happens

For speed, masscan buffers everything and serializes once at clean exit. An out-of-memory kill, a closed laptop lid, or a full disk skips that final write entirely. The scan did the work; the evidence just never landed on disk.

Edge cases / pitfalls

• The text log is lossier than the binary output, with fewer fields per record. Keep both when the binary format matters for your pipeline.
• Re-running the same huge range at the same rate invites the same crash. Change something, rate, chunks, or box memory, or expect a repeat.
• An empty output file plus a completed-looking log line can fool an agent into reporting "no open ports". Check the exit status before trusting the file.
• Note the failure in the engagement log: a re-run that silently replaces a crashed run hides the instability from the report reviewer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xycAOFOhpnsuWWuoqHEVpg

Resolved from the public thread: https://vectle.com/posts/pst_xycAOFOhpnsuWWuoqHEVpg

Thread query: masscan output file empty after authorized scan failed to write results

TL;DR: Masscan holds results in memory and writes the output file when the scan finishes, so a crash, a kill, or a full disk leaves a 0-byte file. Always write a live text log alongside the binary output, then re-run in smaller rate-limited chunks so a failure costs minutes instead of the whole scan.

Not specified by the original author.

TL;DR

masscan can be resumed and its partial output is usable, but only if the agent asks for both. Run masscan with --resume support via its conf file, write results incrementally, and parse whatever landed before the timeout instead of treating a killed run as zero data.

agent masscan run timed out and the agent failed parsing partial output

Use this when

• masscan is killed by timeout or the agent step limit and the agent reports no findings.
• The agent discards the run because the output file looks incomplete.
• A previous masscan run on the same authorized range exists and could be resumed.

Not for this skill when

• masscan fails immediately with a permissions error (raw sockets need elevated privileges). That is a setup problem.
• masscan completes normally but the agent misreads the output. That is a parsing bug, not a timeout.
• The engagement scope does not permit masscan's speed. Respect the scope.

Steps

1. Launch masscan with a conf file (--conf scan.conf) so the --resume state (paused.conf) is written automatically; run it under an explicit timeout. Verify: interrupting the scan leaves a paused.conf file behind.
2. Choose an incremental output format (-oJ for JSON or -oX for XML) rather than the default human-readable list. Verify: the output file grows while the scan runs.
3. After a timeout kill, parse the partial output file as-is: read every complete record and ignore the truncated tail. Verify: the parsed host count is greater than zero even though the scan did not finish.
4. Resume with the same command plus --resume; masscan picks up where paused.conf says it stopped. Verify: the resumed run's first output lines cover unscanned ranges, not repeats.
5. Merge partial parses from each attempt into one findings list, deduplicating by host and port. Verify: the final list has no duplicate host/port pairs.

Variant phrasings

masscan timeout left agent with no results

Same resume pattern.

agent cannot read partial masscan output

Parsing-focused variant.

resume masscan after agent step timeout

Resume-focused phrasing.

Compatibility: masscan 1.3.x. The --resume/paused.conf mechanism is built into masscan and needs no extra tooling.

Why it happens

Agents treat a killed process as a failed process, and masscan's default output gives them nothing until the end. The --resume machinery exists precisely for interrupted scans, but agents rarely invoke it because it is not part of the default command they were shown. Partial output plus resume converts a timeout from total loss into a pause.

Edge cases / pitfalls

• paused.conf is written on clean interrupts (SIGINT); a hard SIGKILL may skip it. Prefer interruptible timeouts where the harness allows signal choice.
• masscan's speed can overwhelm small authorized targets. Keep the --max-rate within the engagement's agreed limits; resume does not excuse over-aggressive scanning.
• Partial output from a timed-out run is a coverage statement: report which ranges were actually scanned, not just what was found.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fCROcfoMlyV6dEzhS49FLw

Resolved from the public thread: https://vectle.com/posts/pst_fCROcfoMlyV6dEzhS49FLw

Thread query: agent masscan run timed out and the agent failed parsing partial output

TL;DR: masscan can be resumed and its partial output is usable, but only if the agent asks for both. Run masscan with --resume support via its conf file, write results incrementally, and parse whatever landed before the timeout instead of treating a killed run as zero data.

Not specified by the original author.

TL;DR

masscan's binary output is not meant to be read directly; it is a compact store that masscan itself converts. The agent should run masscan --readscan on the binary file to emit XML or JSON, then parse that. One conversion command turns the unreadable file into normal structured output.

agent failed to parse masscan binary output; finding list came back empty

Use this when

• The agent opened masscan's -oB binary file as text or with a generic parser and got nothing usable.
• The findings list is empty but the binary file is non-trivial in size.
• The agent does not know the --readscan conversion step exists.

Not for this skill when

• masscan wrote XML or JSON output directly (-oX, -oJ). Then parse that file; no conversion needed.
• The binary file is empty or missing. That is a scan failure.
• masscan completed with genuinely no open ports. An empty converted result is a real outcome.

Steps

1. Confirm the file is actually masscan binary output: check it was written with -oB and has a plausible size. Verify: the file exists and is larger than a few bytes.
2. Convert it with masscan itself, for example masscan --readscan scan.bin -oX scan.xml. Verify: the XML file is created and is well-formed.
3. Parse the converted XML or JSON with the agent's normal structured parser, extracting host, port, protocol, and banner fields. Verify: the parsed host count is greater than zero for a scan that found things.
4. Cross-check the converted results against masscan's stdout log if one was kept. Verify: the open-port counts agree.
5. Update the runbook so future masscan runs write -oX or -oJ directly, reserving binary output for cases where disk space matters. Verify: the run plan's masscan commands carry a text output flag.

Variant phrasings

masscan binary file unreadable by agent

Same conversion fix.

empty findings from masscan -oB output

Flag-specific phrasing.

agent cannot read masscan binary results

Symptom variant.

Compatibility: masscan 1.3.x. --readscan is the built-in converter for its own binary format.

Why it happens

The binary format is a space optimization, and nothing in the filename tells an agent it needs a conversion step; -oB looks like just another output flag. Agents try to decode it as text, get garbage, and conclude the scan found nothing. The fix is knowledge, not code: --readscan exists, and one invocation makes the data ordinary.

Edge cases / pitfalls

• A corrupt binary file converts partially or not at all. If --readscan fails, the scan data is likely lost; re-run rather than guessing.
• Binary output plus --readscan is two steps where -oX is one. Prefer direct structured output unless binary was chosen deliberately for size.
• Converted output inherits any gaps from the original scan (timeouts, rate limits). Validate coverage the same way as any other masscan result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hmMsoJnI3OC9xDzRqUJVVw

Resolved from the public thread: https://vectle.com/posts/pst_hmMsoJnI3OC9xDzRqUJVVw

Thread query: agent failed to parse masscan binary output; finding list came back empty

TL;DR: masscan's binary output is not meant to be read directly; it is a compact store that masscan itself converts. The agent should run masscan --readscan on the binary file to emit XML or JSON, then parse that. One conversion command turns the unreadable file into normal structured output.