add new 'ipport' output format for IP:PORT pairs

[mehdirzfx]

Summary

This PR introduces a new output format called ipport to Masscan, which provides a simple list of IP:PORT pairs for open ports. This format is useful for quick parsing and integration with other tools that expect minimal, structured output.

Changes Made

• New Output Format: Added Output_IPPort enum value in masscan.h.
• Output Implementation: Implemented ipport_output functions in src/out-ipport.c (new file) and registered it in output.c and output.h.
• Command Line Support: Added -oI shortcut and ipport option to --output-format in main-conf.c.
• Documentation: Updated README.md and doc/masscan.8.markdown to document the new format.
• Build Files: Added out-ipport.c to Visual Studio project files (vs10/masscan.vcxproj and vs10/masscan.vcxproj.filters).
• Version Bump: Incremented version to 1.4.0-integration in masscan-version.h.

Usage Example

masscan -p80,443 192.168.1.0/24 --output-format ipport --output-filename results.txt
# Or shorthand:
masscan -p80,443 192.168.1.0/24 -oI results.txt

Output format:

192.168.1.1:80
192.168.1.2:443

Testing

• Verified compilation on Windows (Visual Studio).
• Tested output generation with sample scans.
• No breaking changes to existing formats.

This enhances Masscan's flexibility for output customization. Please review and merge if approved.

[Frky]

Thank you for the contribution.

I think we should keep the information of the layer 4 protocol for which an open port has been found (tcp or udp).
For instance, the format could be <ip>:<tcp|udp>/<port>? I understand that the main goal is to have an easily parsable text output, so feel free to come with another suggestion.

[mehdirzfx]

Thank you for the contribution.

I think we should keep the information of the layer 4 protocol for which an open port has been found (tcp or udp).
For instance, the format could be <ip>:<tcp|udp>/<port>? I understand that the main goal is to have an easily parsable text output, so feel free to come with another suggestion.

I agree with you, the purpose of adding this feature was that most of the software I saw was compatible with the IP:Port format and the type of connection can be customizable. Because it's already in the app's source.

[Frky]

What do you mean by "it's already in the app's source"?

What's the conclusion then? Should you edit your PR to add the protocol in the output?

[mehdirzfx]

What do you mean by "it's already in the app's source"?

What's the conclusion then? Should you edit your PR to add the protocol in the output?

Thanks for the review, Frky. I think there might be a slight misunderstanding about the main goal of this PR.

The purpose of adding the ipport format is to provide a minimal and clean list of IP:Port pairs that can be directly consumed by many existing command-line tools and scripts. These tools expect exactly the IP:Port format (one per line) without any extra information like protocol.

If a user needs protocol information (tcp/udp), they can already use the existing grepable (-oG) output format, which includes all those details. Adding tcp: or udp: to this format would break compatibility with many simple parsers and defeat the simplicity goal of this PR.

So I believe ipport should remain strictly IP:Port for maximum compatibility, and users who need protocol info can simply choose grepable instead. Thanks for understanding!