A Flutter/Dart network scanner for Android and Windows that ranks CDN and Cloudflare edge IPs by measured download speed, latency and throttle behavior in authorized testing workflows.
| Tool | mwhammadrezss/midonescanner-android — Flutter-based CDN/Cloudflare IP scanner with real-bandwidth testing and throttle detection |
| Category | Network measurement / IP qualification scanner (Android + Windows desktop) |
| Primary Use | Ranking CDN and Cloudflare edge IPs by actual TLS 1.2/1.3 throughput, latency, packet loss and throttle percentage during authorized connectivity assessments |
| Safe Use | Intended for network engineers, researchers and authorized testers benchmarking connectivity and ISP throttling behavior on networks they are permitted to analyze; not for unauthorized probing of third-party systems. |
| Telemetry Note | Generates up to 20 concurrent TCP:443 connections with repeated TLS handshakes and HTTP/2 requests per candidate IP — visible to CDN operators as probing traffic and measurable in NetFlow/edge logs; leaves no persistence on any remote host. |
MidONe Scanner (mwhammadrezss/midonescanner-android) is a network measurement tool built in Flutter/Dart that ships for both Android 5.0+ and Windows 10/11. Its core thesis is stated bluntly in the README: most IP scanning tools just fire a ping and report a number that has no correlation with the throughput you would actually experience on a real connection. Instead of relying on ICMP round-trip times, this tool establishes full TCP connections, performs TLS 1.2/1.3 handshakes over TCP:443, issues HTTP/2 requests and measures genuine download performance — a methodology that produces results an operator can actually act on when qualifying edge IPs in an authorized environment.
The README, which mixes Persian and English sections, documents four distinct scan pipelines. The first is the CDN Smart Scan, which comes in two flavors. The Normal Engine walks through TCP Connect, TLS Handshake, HTTP/2 Request, Response Validation, Latency Measurement, Candidate Scoring and finally Ranking — a classic probe-and-score loop that filters candidates quickly. The Deep Scan Engine is more interesting: it holds an HTTP/2 Keep-Alive connection for a 25s long-connection test, runs DPI Detection, performs Stability Analysis and a Packet Loss Check, then computes a final score. That keep-alive duration is a deliberate design choice, because transient IPs that pass a short probe often degrade under sustained load, and only a long-lived stream exposes that.
The second pipeline is a dedicated Cloudflare scanner. Beyond the standard TCP and TLS setup it performs Cloudflare Verification and Colo Detection, identifying which data center the connection lands in by airport code — the README lists FRA, AMS and LHR as examples. It then escalates the test from plain HTTP/2 to a WebSocket Upgrade Test and a WebSocket Stability Check before latency measurement and scoring. This is a meaningfully different test surface than raw HTTP: WebSocket persistence exercises connection lifetime behavior that a single request-response cycle never touches, and for anyone analyzing Cloudflare edge behavior from an authorized vantage point, colo identification is the detail that makes results reproducible.
The third pipeline, Range, is the high-throughput mode. It takes a CIDR Range, generates candidate IPs, fires Concurrent TCP Probes, strips dead IPs, filters candidates, queues survivors for the deep-scan engine, verifies stability, and feeds a Live Ranking Engine that emits final results. The fourth is the DNS Benchmark Engine, which resolves against candidate resolvers and measures Average Latency, checks NXDOMAIN handling, runs Burst Performance and Jitter Measurement, tests DoH Support, and computes a Reliability Score before ranking. The README also mentions a Freedom Verification step in that pipeline — language that, together with the tool's framing around "clean IPs," situates it in the censorship-measurement space where users verify which resolver or endpoint combinations remain unfiltered on their network.
The feature set around the engines is pragmatic rather than flashy. Simple Mode does a fast scan with a fixed SNI, while Auto-SNI Mode performs automatic CDN detection and optimal SNI selection — the difference matters because edge IPs frequently behave differently depending on the server name presented in the TLS ClientHello, and hardcoding one SNI gives an incomplete picture. Results-handling features include Copy Top 5, Save to File for full export to device storage, a Throttle Badge that shows the per-IP speed drop percentage, and an S/A/B/C/D Grade System for ranking. The UI is a dark Forest Green theme, a small but telling detail that the project treats operator ergonomics as part of the product.
The technical specification table is unusually candid about the tool's resource footprint. It runs 20 parallel threads, retries each IP 5× for reliability, spends up to 5 seconds testing per IP, and applies a hard-coded throttle threshold: a 40%+ speed drop flags the IP as Throttled. That threshold definition is the most analytically useful number in the README, because it tells you exactly how the tool distinguishes "slow" from "deliberately degraded" — the difference between an underprovisioned edge and an intermediary actively shaping traffic on that path. Anyone reproducing the tool's results independently needs to replicate both the 25-second deep-scan window and the 40% drop rule to get comparable numbers.
From a defender's perspective, the telemetry this tool produces is straightforward to characterize. Each scan cycle manifests as up to twenty concurrent TCP:443 connections, repeated TLS handshakes, sustained HTTP/2 keep-alives and WebSocket upgrade attempts against a single provider's edge range, with five retries per candidate IP. CDN-side fraud and abuse systems will see this as low-and-slow probing rather than volumetric attack traffic; on the local network, an observer between the client and the edge sees exactly the pattern the tool is designed to expose — which endpoints get full throughput and which get clipped. Nothing persists on any remote host; the tool is purely a client-side measurement instrument.
The distribution model deserves the usual caution. The project distributes a prebuilt APK (v8.1.0 at time of writing) via GitHub Releases, and the Windows build instructs users to bypass a Windows Defender warning with More info → Run anyway. A closed-binary security tool with a Defender flag and a Telegram channel (t.me/mmdrlx) as the primary update channel is a profile that warrants sandboxing before use on any sensitive network — standard practice for any third-party binary, and doubly so for one that makes outbound connections by design. The repository itself is Dart source on the main branch with 33 stars and no license file, so reuse rights are formally undefined.
Where this tool fits in a professional workflow is narrow but real: benchmarking CDN edge performance from a specific vantage point, validating whether an ISP throttles particular endpoints, comparing Cloudflare colos for latency, and qualifying DNS resolvers including DoH support — all on networks you are authorized to test. It is not a vulnerability scanner, an exploit framework, or anything that touches confidentiality or integrity of remote systems; it is a measurement instrument. The value for the security community is largely documentary: it shows how throughput-based scoring, SNI-aware probing, DPI detection heuristics and colo fingerprinting combine into a single client, and its openly published thresholds and pipeline diagrams make it a useful reference design for anyone building their own network measurement tooling.
mwhammadrezss/midonescanner-android.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.