Add new scanner mechanic based on unbound tech code we wrote

[voidr3aper-anon]

No description provided.

[Copilot]

Pull Request Overview

This PR introduces a comprehensive scanner mechanic for finding optimal Cloudflare WARP endpoints with enhanced IPv4/IPv6 support. The implementation adds a multi-stage pipeline architecture with ICMP, TCP, and WARP handshake filtering stages.

Key Changes:

• New strategic scanning pipeline with concurrent multi-stage IP filtering (ICMP → TCP → WARP)
• Enhanced endpoint parsing supporting CIDRs, IP ranges, domains, and custom ports
• Added lwip/tun2socks integration for Android VPN functionality
• Expanded ping implementations (ICMP, TCP, TLS, HTTP) beyond the original WARP-only approach
• Refactored IP generation with subnet-aware sampling (IPv4 /24 and IPv6 /120 buckets)

Reviewed Changes

Copilot reviewed 21 out of 22 changed files in this pull request and generated 26 comments.

Show a summary per file

File	Description
wiresocks/scanner_test.go	New test suite for endpoint parsing validation
wiresocks/scanner.go	Enhanced scanner with flexible endpoint configuration and improved error handling
warp/endpoint.go	Added compatibility alias GetWarpPorts() for the existing WarpPorts() function
lwip/lwip.go	New tun2socks integration for Android platform support
ipscanner/statute/statute.go	Expanded scanner options with HTTP/TLS configuration and multi-stage ping controls
ipscanner/statute/ping.go	Added TLS version utility function
ipscanner/statute/default.go	Extracted Cloudflare IP ranges to separate file
ipscanner/scanner.go	Major refactor with dialer customization, endpoint resolution, and port testing
ipscanner/ping/*.go	New ping implementations for ICMP, TCP, TLS, and HTTP protocols
ipscanner/iterator/iterator.go	Rewritten IP generation with subnet bucketing and .0/.255 filtering for IPv4
ipscanner/example/*/main.go	Updated examples demonstrating new scanner features
ipscanner/engine/queue.go	Simplified queue with sorted insertion
ipscanner/engine/engine.go	Refactored to streaming pipeline architecture with concurrent filter stages
go.mod/go.sum	Added tun2socks and related dependencies
cmd/warp-scan/main.go	Complete CLI rewrite with rich configuration options and multiple scan modes

Comments suppressed due to low confidence (2)

lwip/lwip.go:110

• proxyAddr may be nil at this dereference because err may not have been checked.

	proxyHost := proxyAddr.IP.String()

lwip/lwip.go:111

• proxyAddr may be nil at this dereference because err may not have been checked.

	proxyPort := uint16(proxyAddr.Port)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The IPv4 ICMP reply parsing assumes a fixed 20-byte IP header (line 129), but IP headers can have options that make them longer (up to 60 bytes). The correct approach is to check the IHL (Internet Header Length) field in the first byte of the reply to determine the actual header size. This bug could cause the code to misinterpret ICMP replies from packets with IP options.

Suggested change

	// For IPv4, the reply starts after the 20-byte IP header
	if n < 20+8 {
	return &IcmpPingResult{Addr: p.ip, Err: errors.New("invalid ICMP reply: too short")}
	}
	replyType = reply[20]
	if replyType != 0 { // Echo Reply
	return &IcmpPingResult{Addr: p.ip, Err: fmt.Errorf("not an echo reply, type: %d", replyType)}
	}
	} else { // IPv6
	// For IPv4, the reply starts after the IP header, whose length is given by the IHL field
	ihl := int(reply[0]&0x0F) * 4
	if n < ihl+8 {
	return &IcmpPingResult{Addr: p.ip, Err: errors.New("invalid ICMP reply: too short")}
	}
	replyType = reply[ihl]
	if replyType != 0 { // Echo Reply
	return &IcmpPingResult{Addr: p.ip, Err: fmt.Errorf("not an echo reply, type: %d", replyType)}
	}

[Copilot]

[nitpick] The queue implementation inserts items while holding a lock (lines 26-40), which is correct. However, the insertion uses append followed by copy to shift elements. For a queue that could grow to 65535 items (as configured in scanner.go:54), this O(n) insertion could become a performance bottleneck. Consider using a data structure optimized for sorted insertions, such as a heap or a linked list, especially if high insertion rates are expected.

[Copilot]

[nitpick] Setting IPQueueSize to 0xFFFF (65535) as "effectively unlimited" may cause memory issues if the scanner finds many IPs. Consider either documenting this as a potential concern or implementing actual unbounded behavior (e.g., using 0 to mean unlimited and handling it specially in the queue implementation).

Suggested change

	IPQueueSize: 0xFFFF, // Effectively unlimited to collect all results.
	IPQueueSize: 0, // 0 means unlimited; be aware this may cause high memory usage if many IPs are found.

[Copilot]

[nitpick] The comment says "Test logic that configures the scanner" but this is incomplete or unclear. Consider revising to: "This test validates that the endpoint string parsing within RunScan behaves correctly."

Suggested change

	// Test logic that configures the scanner.
	// This test validates that the endpoint string parsing within RunScan behaves correctly.

[TGIR0]

درود
میتونم اینو به جای هسته فعلی oblivion بزارم اسمشم برای یاد شما میزارم VOblivion

[TGIR0]

این روی نسخه اندروید میخوام بزارم چون کلا هسته اش از کار افتاده ولی روی خود پروژه کار کردم فقط هسته اش ضعیفه